A ConfigMgr/SCCM client stuck in provisioning mode or having corrupt local group policy files (Registry.pol) are two very common and nagging issues in a Configuration Manager environment. Where it’s rather easy to use Configuration Manager to remediate the corrupt policy files, it’s another story with a SCCM client stuck in provisioning mode (the client has very limited functionality). I haven’t personally been seeing clients in provisioning mode that often, but I do occasionally see it happen following an Windows in-place upgrade .
Both scenarios will cause a drop in compliance in regards to Software Updates and general software deployments, and unless being very thorough when walking through compliance reports, clients being affected by either issues can be difficult to spot, especially in larger environments.
So I hereby give you my solution to how you can automatically remediate both issues outside of Configuration Manager using Powershell and thus increase the compliance and overall health of your environment.
This is mostly Powershell and used in combination with a scheduled task or startup script, you can have this run automatically outside of Configuration Manager.
The script is available for download on the TechNet Gallery here:
What does it do?
The script has 3 options: -TestProvMode -TestGPOFiles -SendEmail. They are all optional.
-TestProvMode will test and remediate if the Configration Manager Client is in provisioning mode. This is tested by querying a local machine registry key
-TestGPOFiles will test if the local group policy files are corrupt, and if they are, they will be deleted. New files will be created automatically
-SendEmail will send an e-mail if either of the previous options found any issues. The log file will be attached to the e-mail. The idea here is to make an admin or service desk aware of a possible issue and allow them to follow up proactively. Again, is optional 🙂
The email being sent when a client is having issues looks like this:
And the log file is in a format readable to CMtrace:
Requirements before putting the script to use
- The script requires local administrative rights to run
- Modify the SendEmail part with your own details such as SMTP server, recipient etc.
- Modify log file location if needed. It’s currently set to log to C:\Windows\SCCM-ClientHealthMonitor.log
I have configured this to run with a Scheduled Task with following settings:
- Running as SYSTEM
- Trigger: Running at log on of any user
- Action: Starting powershell.exe with argument: -ExecutionPolicy Bypass -File “\\CM01\Applications\Scripts\SCCM-ClientHealthMonitor\SCCM-ClientHealthMonitor.ps1” -TestProvMode -TestGPOFiles -SendEmail
It goes without saying, but test this thoroughly before putting to use in production. And of course, use at your own risk 🙂