2

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.

Charlie Dobson
  • 193
  • 1
  • 11
  • Just try to set `ProcessStartInfo.Verb` to `RunAs`. You can run your proces with admins privileges using this option. Unfortunately, you cannot use `Verb` and `RedirectStandardOutput` together, [see](https://stackoverflow.com/a/3596354) – George Alexandria Jul 06 '17 at 22:40
  • Wouldn't that pop-up a window asking for credentials then? I'm OK with not using `RedirectStandardOutput`, it was a troubleshooting step anyway to find out why `SFC` wasn't launching. – Charlie Dobson Jul 07 '17 at 13:45
  • You can set credential to `ProcessStartInfo.Password` and `ProcessStartInfo.UserName`, so it wouldn't ask you for credential, but it can ask you to confirm start process with admin privileges. If you want to run process as admin without confirmation you can to lower UAC permissions – George Alexandria Jul 07 '17 at 22:29
  • I tried sfc scannow with the system account using psexec and it worked so in general it should be possible despite the system account. Some other posts regarding this topic suggest enabling the trusted installer service "net start trustedinstaller" did you already try that? Are users logged in on the systems where you tried this or not? – Syberdoor Jul 10 '17 at 08:11
  • I don't think lowering UAC permissions is the right way to go. Yes, users will be logged into these systems. The idea is to run these common remediation steps to fix update health while they're in the office without having to interrupt their day and take 30+ minutes to fix. Thanks for the info about it being possible and confirming this should work with the System account. I'll script in starting the trusted installer service before calling `SFC /scannow` and see how that goes. Thanks! – Charlie Dobson Jul 11 '17 at 12:26
  • So I added in `$TrustedInstaller = Get-Service -Name "TrustedInstaller" -ErrorAction SilentlyContinue | Where { $_.Status -eq "Stopped" } | Start-Service` and re-ran the script on a test machine where I'm logged in with a user that doesn't have Admin rights and manually re-ran the deployed script and it failed to run `SFC /SCANNOW`. To continue troubleshooting, I kept the line with the -RedirectStandardOut, and the resulting file still reads "Windows Resource Protection could not start the repair service." I'll see if I can find a list of prerequisite services for SFC. – Charlie Dobson Jul 11 '17 at 12:42
  • I think I found a solution. When I ran `Start-Process` with the `-Wait` switch, I was expecting to see `SFC.EXE /SCANNOW` take a long time to complete and to show up in Task Manager, instead it was exiting and not working. However, if I use `& "sfc.exe" "/scannow"`, I still see `SFC.EXE` exit, but `TiWorker.exe` runs and consumes CPU cycles. A search reveals `TiWorker.exe` is part of the TrustedInstaller process. Also, checking CBS.log indicates that activity is happening, so I think it is working with `&`. – Charlie Dobson Jul 11 '17 at 13:39
  • `& "sfc.exe" "/scannow"` doesn't work for me. I use `Start-Transcript` to log output and I get "Windows Resource Protection could not start the repair service." – JPX May 25 '22 at 08:28

5 Answers5

0

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.

user1749682
  • 1
0

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

1BilliumDollars
  • 149
  • 1
  • 3
  • 12
0

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
Mike
  • 1
0

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.

Shunya
  • 2,344
  • 4
  • 16
  • 28
XAdmin
  • 1
0

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.

Charlie Dobson
  • 193
  • 1
  • 11