Introduction
Update: This post has been superseded with this: https://www.imab.dk/sccm-client-health-monitor-script/
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.
How to?
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:
>> https://gallery.technet.microsoft.com/SCCM-Client-Health-Monitor-b1189130 <<
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
Scheduled Task
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
Note
It goes without saying, but test this thoroughly before putting to use in production. And of course, use at your own risk π
References:
- https://gallery.technet.microsoft.com/scriptcenter/Write-Log-PowerShell-999c32d0
- https://itinlegal.wordpress.com/2017/09/09/psa-locating-badcorrupt-registry-pol-files/
Hi Martin,
Thanks for sharing..
You are most welcome π
Thanks Martin, can you tell me why the machine policy file content should always 8082101103? It was on my own machine, but how did you determine that will always be the value on every machine out of curiosity?
Its based on the documentation for the files. It’s documented like this:
The header contains the REGFILE_SIGNATURE expressed as 0x67655250 which is 80, 82, 101, 103 in bytes:
Cheers π
Thanks, much appreciated! I’ve created a compliance baseline based on this to auto-remediate it. Works well. Cheers!
Would you mind sharing how you created baseline with this, it will be the best approach to auto-re-mediate.
Function Test-IsRegistryPOLGood
{
[cmdletbinding()]
Param
(
[Parameter(Mandatory=$false)]
[string[]]$PathToRegistryPOLFile = $(Join-Path $env:windir ‘System32\GroupPolicy\Machine\Registry.pol’)
)
if(!(Test-Path -Path $PathToRegistryPOLFile -PathType Leaf)) { return $null }
[Byte[]]$FileHeader = Get-Content -Encoding Byte -Path $PathToRegistryPOLFile -TotalCount 4
if(($FileHeader -join ”) -eq ‘8082101103’) { return ‘Compliant’ } else { return ‘Not-Compliant’ }
}
Test-IsRegistryPOLGood
how can you find machines that actually have this issue?
do they report specific error on client health or status message?
Thanks
Hi, that’s what the script does for you, as client affected by either issues is not so easily spotted through the console π
Amazing work! My software updates were up to a year behind on effected machines. Compliance is flying high now that I implemented this a separate ADR for each Office and Windows product.
” this a plus separate ADR”
How to do set ADR is there screenshot for reference please
Above script is for Discover or remediation in Baseline
Hi Sorry to bother you .. Could you please update the link as it is not working anymore ?!
I am struggling with this corrupted Registry.pol file .. Would be nice to get this script !!
Thanks !!
G.