When I start the powershell with Credential parameter that uses domain credentials from the domain computer, the keyboard stops working:
start powershell -Credential $DomainUser
If I start cmd keyboard works, and when I start powershell from cmd it stops again.
If I use
start powershell -Credential $DomainUser -ArgumentList "1+1; sleep 2"
I can see the commands executed normally and this is the only way I can execute them.
If I run
start powershell -Credential $DomainUser -ArgumentList '-NoExit -Command "pause"'
I can type the letters while pause is in effect, after it finishes no typing again.
If I shift + context menu and run powershell as domain user via Run as different user option it works.
It happens on multiple Windows 8 and 10 OSes and Posh 4+.
Anybody knows what is going on ?
Related
I'm trying to run invoke-command to launch a powershell script in a powershell file on a remote computer. I'm using the credentials for a user with Administrator privilege. The command needs to be executed by running powershell as an administrator. There are licensing issues with the application that i'm trying to invoke using the powershell script, so i cannot change the credentials to Administrator but need to run with that particular user itself. I have tried using -RunAsAdministrator at the end of the Invoke-Command, but i got an error saying:
Invoke-Command : Parameter set cannot be resolved using the specified named parameters.
$command = {
cd Folder
C:\Folder\build.ps1
}
Invoke-Command -ComputerName $RemoteSystemIP -ScriptBlock $command -credential $Credentials1 -ErrorAction Stop -AsJob
I'm trying to execute this as a background job that's why i added the -AsJob parameter.
Its been several days and i haven't found a solution yet.
tl;dr
The only way to get a remote PowerShell session to execute elevated (with admin privileges) is to connect with a user account (either implicitly or via -Credential) that has admin privileges on the target machine.
With such an account, the session automatically and invariably runs elevated.
The Invoke-Command's -RunAsAdministrator switch can only be used with (virtualization) containers (-ContainerId parameter), not regular remoting (-ComputerName parameter).
You cannot elevate on demand in a remote session (the way you can locally, interactively with Start-Process -Verb RunAs).[1]
Instead, you must make sure that the credentials you're passing to Invoke-Command -Credential to connect to the remote machine with refer to a user account that (also) has administrative privileges on the target machine, in which case the remote session automatically and invariably runs elevated (with admin privileges).[2]
If you cannot pass such credentials, I think you're out of luck.
To test if the current user has administrative privileges:
# Returns $true if elevated, otherwise $false.
[Security.Principal.WindowsPrincipal]::new(
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
Separately, here's a simple test you can run from inside a session to determine whether it is running with elevation:
# Returns $true if elevated, otherwise $false.
[bool] (net session 2>$null)
[1] Unless the session at already is elevated, -Verb RunAs presents a pop-up UAC dialog that a user must confirm interactively, which is not supported in a remote session.
[2] The same applies if you use "loopback remoting", i.e. if you target the local machine via remoting, using Invoke-Command -ComputerName ., for instance, with additional restrictions, however: You cannot use a user that is authorized for remoting but isn't part of the local Administrators group, and if you use the current user (whether or not with explicit credentials), the calling session must itself be elevated.
I think you should do this:
$command = {
Start-Process "powershell" -Verb runas -Workingdirectory "C:\Folder\" -ArgumentList "build.ps1"
}
Invoke-Command -ComputerName $RemoteSystemIP -ScriptBlock $command -credential $Credentials1 -ErrorAction Stop -AsJob
I'm using a simple script to run another script as admin that will need to change the location of files in areas that are otherwise restricted. I've tried literally every method I could find on stackoverflow for running a script as administrator to no avail.
My 'admin' version of powershell closes instantly when I call it from another script. All I want is to be able to run a script that has adminitrative rights without the thing closing on me instantly when I gave it a script to execute.
Start-Process powershell -Verb runAs
start-process powershell -argument "C:\Scripts\Backup.ps1 TestBackup" -Verb runAs
and the next 6 answers on this page:
PowerShell: Running a command as Administrator
I expected to be able to run the passed script as admin, but instead admin powershell pops up and instantly closes.
I've had issues with relaunching a script as admin, due to execution policy, so I ended up encoding the command and running it that way:
$Code = ". 'C:\Scripts\Backup.ps1' TestBackup"
$Encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($code))
# Indicate that the process should be elevated
Start-Process PowerShell.exe -Verb RunAs -ArgumentList "-EncodedCommand",$Encoded
not sure if I'm overcomplicating this, I just want to call another script as local admin and have it run.
The command below opens powershell, and in the new window I get an error and then the window closes too fast for me to be able to see it.
start powershell -verb runas -ArgumentList {Invoke-Expression -Command "C:\Script.ps1"}
If you want to stay native powershell use the start-process cmdlet and you can specify the filepath (process to run) as powershell.exe and the -ArgumentList parameters as conditions for your new session. In my example below i'm setting ExecutionPolicy so you don't have to rely on the system level policy, NoProfile will make your script a bit more resiilent by not loading any customized profile on a system.
$Cred = (Get-Credential)
$ScriptLocation = "C:\Temp\TestScript.ps1"
Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File $ScriptLocation" -Credential $Cred
You can see in the script getting a credential object (which you'll probably want to provide so the script will just run) then specifying the script location and executing.
As vonPryz mentioned, you can always troubleshoot by adding -NoExit to your Argument list so the window stays open after executing the script but keep in mind if that if the script location doesn't exist you'll still see the powershell host appear and close right away.
You can also add -WindowStyle Hidden to your argument list to hide any window from appearing at all.
Turned out to be an execution policy issue. This was a device that was non-standard in our environment and didn't have that GPO pushed.
I have an RDS environment with an epos application that runs fine under the user that initially installed it but requires any other user to specifically right click the exe and select 'run as administrator' I have a local admin that I would like to use in a script to automate that action and applies the creds for the user.
I have tried the following.
# Construct the credentials object
$username = "svr-rds\xxx"
$password = ConvertTo-SecureString "xxx" -AsPlainText -Force
$cred = New-Object PSCredential -argumentlist $username, $password
Start-Process powershell.exe -Credential $cred -WindowStyle Hidden `
'-noprofile -command "Start-Process C:\Montana\Montana.exe /k -Verb RunAs"'
I have found though that the runas command no matter how you use it opens the application as an empty application frame, if I've researched right, the runas command is not the same as specifically elevating to admin.
is there a solution to this?
Note you stated...
epos application that runs fine under the user that initially
installed it...
Then to install and app, you need to be Admin on the box or use Admin creds when prompted. So, the app is installed as an Admin and global to all users and that app is associated with the user initial user identity only. So, when another user logs on to this what appears to be a shared workstation, that app is never associated with any other user profile. So, one must use the installer identity.
PoSH notwithstanding. RunAs has never meant 'Run Elevated'. It's always meant run with the supplied identity.
Suggestion:
Why not just create a shortcut to the .exe and set it's properties to run as admin?
You can just use that to launch the app with the shortcut settings.
invoke-item 'AppName.lnk'
Example, I run an a regular use all the time, my PoSH host environment is set to restricted. Yet, because I do all things admin in PoSH, I start PoSH as admin and elevated this way:
# Shortcut properties for the ISE
C:\Windows\System32\runas.exe /user:contoso\Administrator "%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy UnRestricted PowerShell_ISE.exe"
# Shortcut properties for the Console Host
C:\Windows\System32\runas.exe /user:contoso\Administrator "%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Unrestricted"
Or just create a shortcut and set the 'Run as administrator' checkbox under the advanced tab of the shortcut properties. if you don't need the extra ExecutionPolicy step as above. Then the whole invoke step.
I need to run a PowerShell script from another PowerShell script as different user and hidden window.
What do I have so far:
Start-Process powershell '& C:\test.ps1' -WindowStyle Hidden -Credential $cred
where $cred is a PSCredential object. The test.ps1 script is for testing purposes one line with Remove-Item. As I can still see the file not being removed I can tell that the script is not being run.
EDIT
My original intention is to run regedit script but when I was implementing Start-Job answer (below) I've got this error:
Start-Job : The value of the FilePath parameter must be a Windows PowerShell script file. Enter th
e path to a file with a .ps1 file name extension and try the command again.
You could use jobs for this. As the Powershell documentation says
A Windows PowerShell background job runs a command without interacting
with the current session.
PS> $myJob = Start-Job -FilePath C:\test.ps1 -Credential $cred
To get the result/output of the job, use Receive-Job
PS> $myJob | Receive-Job -Keep
You can run the PowerShell scripts through task scheduler. I'm not sure if it is your goal, but it will let you execute PowerShell scripts on a user's session using their credentials.
I'll let you Google the how to, to fit your needs.