I am running a script that involves writing to a database only certain users have access to, so we are running the script as a different user (passing in those user credentials) on our corporate network.
Despite trying things like -NoNewWindow or -WindowStyle Hidden, it always seems to pop up in a new window. This is an issue because when we launch the script from our Jenkins builder with a powershell build step, Jenkins doesn't like the second window and really appears to need it all in the main window.
We are using Start-Process, and the script call looks similar to this (I cut some of the details out):
Start-Process -NoNewWindow powershell.exe -Credential $credential -ArgumentList “Start-Process powershell.exe 'path\script.ps1 -param1 xxx -param2 yyy' -Verb runAs”
Any ideas as to how to get this to actually run without a popup window?
Thanks!
one of these should do the trick to you
Invoke-Command -ComputerName 'Same computer Name' -Credential '(PAss Cred object here)' -ScriptBlock {'Your Scripts Here'}
Invoke-Command -ComputerName 'Same computer Name' -Credential '(PAss Cred object here)' -FilePath 'FilePAthHere'
Related
I am trying to install an application on my Windows server.
The application needs to be installed as an Active directory user/service account.
The service account as part of all the relevant user groups.
If I launch a power shell window by running it as that service account user installation works successfully.However this task need to be automated.
To achieve this I am calling the installer from the power shell script and trying to run it as that service account user.
I have tried the inward command and the start process command to call the installer but it fails.
The workflow is
Task Scheduler > Task > Powershell Script(Run as local System admin account) > Invoke-Command OR Start-Process; calling the installer as the service account.
start-process "C:/install.exe" -Wait -Credential ($ServiceAccount_Crednetials_Object)
start-process "C:/install.exe" -Wait -PassThru -verb runas /user:NTADMIN\Service_account
Invoke-Command -scriptblock { Start-Process "C:/install.exe" -ArgumentList $Using:arguments -Wait } -Credential $mycreds -ComputerName localhost
it seems like there may be a double hop issue. But I am not sure what is happening
I'm trying to create a Powershell script that will be deployed to any node that is showing bad update health to automate some of the simple tasks without having to interrupt users during their workday. The Powershell script works perfectly if ran from an elevated PS prompt. It also runs fine when the same script is deployed to a test machine via SCCM with one exception: it won't call SFC.EXE /SCANNOW.
I've tried using:
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -Wait -NoNewWindow
Start-Process -FilePath "sfc.exe" -ArgumentList '/scannow' -Wait -NoNewWindow
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -RedirectStandardOutput "C:\SFC-Out.log" -RedirectStandardError "C:\SFC-Err.log" -Wait -NoNewWindow
& "sfc.exe" "/scannow"
Invoke-Command -ScriptBlock { sfc.exe /scannow }
Again, all of these examples work exactly as intended when run from an elevated PS prompt, but fail when run from the deployed PowerShell script. When I used the -RedirectStandardOutput, I checked the file SFC-Out.log and it read:
"Windows Resource Protection could not start the repair service"
I think this is because SCCM runs programs/scripts in the SYSTEM context instead of a user context (or even an elevated user context, but SYSTEM is supposed to be higher than an elevated session).
Is there a way to accomplish this? Sorry for the bad formatting, this is my first post on this site.
A bit late but I encountered the same issue. Not sure if this is the case for you but the cause was configuring the deployment of the script with SCCM to run as a 32 bit process. The script was being deployed to 64 bit systems. When I unchecked "run as 32 bit process" in the deployment configuration SFC worked without an issue under the context of a System account.
I created a package (not an application) in SCCM and had to use the redirect using the elusive sysnative folder for x64 machines:
https://www.thewindowsclub.com/sysnative-folder-in-windows-64-bit
So it would be:
C:\Windows\Sysnative\SFC.EXE /SCANNOW
What you have will work, just missing "-Verb RunAs" to elevate permissions. So your cmdlet should read:-
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -Wait -Verb RunAs
I've been reading and searching online for this, the only answer so far is that It can't be run due to sccm using the system account. It's also the same behavior when trying to run winmgt.
Fast forward to SCCM Current Branch 2109 and I was able to solve this problem by using the new Scripts feature built into SCCM. Using & 'sfc.exe' '/scannow' works, and I can manually run this script against any device collection showing devices in error. Start-Process -FilePath "sfc.exe" -ArgumentList "/scannow" -NoNewWindow -Wait works too.
I'm writing a small PowerShell script launched from a batch file which will change a Standard User (when logged in) to a Local Administrator. It needs to be fully automated, and I know the given machine's Admin credentials. I figured that I would begin by passing the Admin credentials, but I'm having trouble getting around the Password prompt (since it requires user action). So far I have this.
Start-Process powershell.exe -Credential "Domain\Username" -NoNewWindow -ArgumentList "Start-Process powershell.exe -Verb runAs"
$wshell = New-Object -ComObject wscript.shell;
$wshell.AppActivate('Windows PowerShell Credential Request')
Sleep 1
$wshell.SendKeys('SuperSecret')
Sendkeys isn't working as far as I can tell, and neither does -Password when I try to pass it as an argument. I'm not sure if I should pursue this method or if there is other logic that will let me assume a Local Administrator without being prompted to begin with. Also, this will be run on more than one machine, however the credentials are constant since they will all be on the same network.
From my script I want to run some command in remote Windows box. So I googled a little and seems the most popular and somehow standard way to do that is to use PowerShell's Invoke-Command cmdlet which seems to use the same protocol as winrm and winrs. So, bellow are commands I've tried to call from my script (actually I've tried lots of other their modifications as well, but IMO these are enough to illustrate the problem):
PowerShell -Command "$encpass=ConvertTo-SecureString -AsPlainText mypass -Force;$cred = New-Object System.Management.Automation.PSCredential -ArgumentList myuser,$encpass; Invoke-Command -ComputerName REMOTE_COMPUTER_NAME -Credential $cred -ScriptBlock {<fullcommand>};"
PowerShell -Command "$encpass=ConvertTo-SecureString -AsPlainText mypass -Force;$cred = New-Object System.Management.Automation.PSCredential -ArgumentList myuser,$encpass; Invoke-Command -ComputerName REMOTE_COMPUTER_NAME -Credential $cred -ScriptBlock {Start-Process -FilePath <fullexepath> -ArgumentList <arguments> -Wait -NoNewWindow};"
PowerShell -Command "$encpass=ConvertTo-SecureString -AsPlainText mypass -Force;$cred = New-Object System.Management.Automation.PSCredential -ArgumentList myuser,$encpass;$session=new-PSSession -ComputerName "REMOTE_COMPUTER_NAME" -Credential $cred; Invoke-Command -Session $session -ScriptBlock {<fullcommand>};"
NOTE: The script is written in perl, but IMO here the language of the script doesn't matter, so you can suppose that I call the command from batch script, just note, that as commands should run from a script they should not require any interactive actions.
So, I have several problems with these commands, and need help to figure them out. Here they are:
Can't run processes of type configure and run daemon. Namely if I want to run configure_server.pl on remote box (<fullcommand> = "configure_server.pl <arguments>"), which should do some stuff, then run server.exe, it doesn't work, because as soon as configure_server.pl is done, full remote job is being killed including the server.exe which supposed to run as a daemon. (applies to points 1,2,3)
Get wrapped (length of each line is less or equal than 80 chars) standard output and standard error. (applies to point 1,3)
Don't get standard output and standard error. (applies to point 2)
Whew this is a tough one, your kind of all over the place so if I miss what your trying to do completely let me know.
1 . Stop trying to go the remote route. I know it seems like a great idea, but it's not. The only way you can get the process to persist is if you keep the powershell window up on the host computer. As you've probably noticed, you can create processes fine, but they're children of your powershell.exe, and are hosted by the wsmprovhost.exe process on the client computer. Once the parent is gone, all the children are killed
To fix this I suggest using a command line function : Schtasks.exe
schtasks.exe /create /sc ONCE /tn $taskName /tr $command /s $serverName /u $userName /p $pass /ru $userName /rp $pass /st $startTime
This command is going to create a scheduled task to run once and then remove itself after. It even takes computer name, so no remote-access required. You can also do a schtasks.exe /query and check the "Status" for running before you do a schtasks.exe /delete too.
2 . Use the ` (backtick) to specify carry execution to the next line in powershell
3 . I get standard output and error with this function, sometimes not output when executed in a big script, but can always use $? to capture error.
Note: You cannot pass in PSCredentials to this command. I suggest making a GUI that just prompts for userName and and password, without converting to secure string. I try to stay away from remoting in my scripts, since it always just makes everything so slow. Sometimes you do not have a choice, but in this case I believe you do.
I am running this command
Invoke-WmiMethod -ComputerName $machine -Credential $cred -Impersonation 3 -Path Win32_process -Name create -ArgumentList "powershell.exe -ExecutionPolicy Unrestricted -File C:\Windows_Updates.ps1" -Verbose
The only problem is in the remote machine, it getting created as a background process. When I open the task manager, I am able to see powershell.exe, but I have no way to identify what is going on. I have looked nearly everywhere but unable to find a solution.
Basically I need to execute the powershell file remotely. I am open to using other solutions where I can see the script running.
I dont think that is possible. Try psexec instead
http://blogs.technet.com/b/heyscriptingguy/archive/2005/09/06/how-can-i-remotely-start-an-interactive-process.aspx
sysinternals psexec
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx