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.
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'd like a script to be used in this situation:
gain remote access without admin privileges
remotely start Quick Assist as .\Administrator and not have a UAC dialogue.
Step 1 is usually made with Quick Assist, sometimes made with Teams screen sharing.
I'm aware that I can locate quickassist.exe in File Explorer then use Shift and the context menu to Run as a different user, however I'd like a scripted approach.
Experiment A
This works, but there's a Yes/No UAC dialogue:
$isElevated = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if ( -not $isElevated ) {
Start-Process powershell.exe -Credential Administrator -NoNewWindow -ArgumentList {
Start-Process quickassist.exe -Verb RunAs ;
} ;
}
Experiment B
I make multiple mistakes, don't know how to correct them. (I'm trying to learn PowerShell, gradually, but I'm easily confused whilst learning; slightly dyslexic.)
$isElevated = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if ( -not $isElevated ) {
Start-Process powershell.exe -Credential Administrator {
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "PromptOnSecureDesktop" -Value 0 -Force;
};
Write-Host "UAC (user account control) is weakened for a Quick Assist session …" -ForegroundColor Red;
Start-Process powershell.exe -Credential Administrator -NoNewWindow -ArgumentList {Start-Process quickassist.exe -Verb RunAs -Wait};
Write-Host "… Quick Assist session complete …" -ForegroundColor Red;
Start-Process powershell.exe -Credential Administrator {
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "PromptOnSecureDesktop" -Value 1 -Force;
};
Write-Host "… UAC is strengthened." -ForegroundColor Red;
}
the two intended changes to the registry do not occur
the third credential dialogue appears too soon – I want it to not appear until after the end of the Quick Assist session.
Also, conceptually, there's probably no need to run Quick Assist as Administrator whilst UAC is temporarily weakened.
References
https://stackoverflow.com/a/2258134/38108 (2010-02-13) I see use of -Credential with Invoke-Command but when I try to do something similar, for changes to the registry, I make a mess.
https://stackoverflow.com/a/47516161/38108 (2017-11-27) self-elevating PowerShell scripts.
https://superuser.com/a/1524960/84988 (2020-02-12) and https://serverfault.com/a/1003238/91969 (2020-02-15) are interesting – the same script in both answers – however I need something like -Credential Administrator in lieu of -ComputerName.
https://stackoverflow.com/a/60292423/38108 (2020-03-07) via https://stackoverflow.com/a/60263039/38108
PowerShell commands - PowerShell - SS64.com
https://github.com/okieselbach/Intune/blob/master/DisablePromptOnSecureDesktop.ps1 (2020-11-13) via Quick Assist the built-in Remote Control in Windows 10 – Modern IT – Cloud – Workplace
The short answer is don't. Get a real remote management tool or have someone hit the UAC yes prompt.
This is more of a windows thing than powershell, as windows explicitly denies elevating a process locally without going through UAC (and for good reason!). You used to be able to do things like this:
# Use Enter-PSSession to start a "remote" session
# This may still support elevation if you specify CredSSP and configure credential delegation):
New-PSSession MyPCName -Auth CredSSP -cred (get-credential)
# Create a scheduled task with RunAs/elevated permissions:
Register-ScheduledTask -Action $action -User .\Administrator -TaskName "Admin-Stuff" -RunLevel Highest
Which now give fat access denied messages when running locally. You also are not able to edit registry settings within HKLM: without elevation, so disabling uac temporarily is not an option.
You may be able to make use of this exploit that allows admin users to bypass uac, but I think you still have to Run-as-other-user your shell to use it.
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'
I am trying to open two instances of msftpsrvr.exe(CoreFtp) on my local system simultaneously using powershell. I have two .bat files to handle that but once i run it in a function, it overrides the earlier one.
I tried with Start-Process with -Wait but it doesn't proceed to the next step until manual intervention.
function StartSFTP
{
Start-Process -FilePath "C:\SFTP\XXX-in-Reg.bat" -Wait
Start-Process -FilePath "C:\SFTP\XXX-out-Reg.bat" -Wait
}
I tried with the workflow RunScripts(solution given on stack overflow) but to no luck.
function StartSFTP
{
Start-Process -FilePath "C:\SFTP\XXX-in-Reg.bat"
Start-Process -FilePath "C:\SFTP\XXX-out-Reg.bat"
}
Current output is it opens two windows of Coreftp having XXX-in-Reg.bat credentials(port no. and path)
I am pretty much learning this powerful language and hope I was clear in stating my problem.
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