SCCM Client Health Monitor: Automatically remediate Provisioning Mode and corrupt local Group Policy files

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.

Powershell snippet from running the SCCM ClientHealthMonitor script

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:

Example of e-mail being sent with -SendEmail parameter

And the log file is in a format readable to CMtrace:

Log file where provisioning mode and corrupt policy file was found

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/

14 thoughts on “SCCM Client Health Monitor: Automatically remediate Provisioning Mode and corrupt local Group Policy files”

  1. 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?

    Reply
    • 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 πŸ™‚

      Reply
  2. Thanks, much appreciated! I’ve created a compliance baseline based on this to auto-remediate it. Works well. Cheers!

    Reply
      • 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

        Reply
  3. how can you find machines that actually have this issue?
    do they report specific error on client health or status message?
    Thanks

    Reply
    • Hi, that’s what the script does for you, as client affected by either issues is not so easily spotted through the console πŸ™‚

      Reply
  4. 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.

    Reply
  5. 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.

    Reply

Leave a Reply to Martin Bengtsson Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.