Or as we say in the north of Germany: "Moin Moin!"
I wrote a frequently asked questions document about the report solution I created some years ago. Mainly because I still receive questions about the report solution and how to deal with update related errors. If you haven’t seen my ConfigMgr report solution yet, here is the link: “Mastering Configuration Manager Patch Compliance Reporting”
Hopefully the Q&A list will help others to reach 100% patch compliance.
If that’s even possible ;)
If you spend a lot of time dealing with update related issues or processes for client operating systems, have a look at “Windows Autopatch” HERE and let Microsoft deal with that.
For server operating systems, on-premises or in the cloud have a look at “Azure Update Manager” and "A Staged Patching Solution with Azure Update Manager".
The section: “Some key facts and prerequisites” of the blog mentioned earlier covers the basics of the report solution and should answer some questions already.
Everything else is hopefully covered by the list below.
So, lets jump in…
This can mean two things.
There is no data for the system found in the ConfigMgr database when a value of 999 is shown.
Before a system is able to install updates, it needs to scan against the WSUS server to be able to report missing updates. If that scan fails, an error will be shown in the report.
In that case, other update information might be also missing and such an error should be fixed before any other update related analysis.
The ConfigMgr client tries to set a local policy to point to WSUS client to the WSUS server of the ConfigMgr infrastructure. That process fails in case a group policy tries to do the same with a different WSUS server name.
Remove the GPO for those systems to resolve the error.
The ConfigMgr client tries to set a local policy to point the WSUS client to the WSUS server of the ConfigMgr infrastructure. That process results in a policy entry in: “C:\Windows\system32\grouppolicy\Machine\Registry.pol”
If the file cannot be accessed the WSUS entry cannot be set and the process fails.
Delete the file in that case and run “gpupdate /force” as an administrator.
IMPORTANT: Local group policy settings made manually or via ConfigMgr task sequence need to be set again if the file has been deleted.
NOTE: To avoid any other policy problems (with Defender settings for example) it is best to re-install the ConfigMgr client after the file has been re-created.
This typically happens when a system proxy is set and the WSUS agent tries to connect to the WSUS server via that proxy and fails.
You can do the following:
As soon as possible. A pending reboot might be pending from another source than just software update installations like a normal application or server role installation and might prevent security update installations.
This can happen if older update deployments exist and have no compliance changes over a longer period of time. Systems in that state are typically shown as “unknown” in the ConfigMgr console under “Deployments”.
Do one of the following to resolve that:
All actions will result in a re-evaluation of the deployment.
The system is not a member of a collection with update deployments applied and is therefore not able to install updates. Make sure the system is part of an update deployment collection.
“Missing Updates All” are ALL updates missing for a system whether deployed or not.
“Missing Updates Approved” are just the updates which are approved, deployed, or assigned (depending on the term you use) to a system and still missing. “Missing Updates Approved” should be zero at the end of your patch cycle, while “Missing Updates All” can always have a value other than zero.
There can be multiple reasons for that.
This is visible in the report: “Software Updates Compliance – Per device deployments”. Which can be opened individually or by clicking on the number in column: “Deployments Non Compliant” in any of the list views of the report solution.
The earliest deadline for a specific update and device is visible in the report: “Software Updates Compliance – Per device” or when clicked on the number of column: “Missing Updates Approved”.
For example, if an update has a timeout of two hours configured and the maintenance window is set to two hours, installation of the update will NOT be triggered.
Start “cleanmgr.exe” as admin an delete unused files.
This can either be a reporting delay or a problem with update compliance state messages.
In that case, run the following PowerShell line locally on the affected machines to re-send update compliance state messages
(New-Object -ComObject "Microsoft.CCM.UpdatesStore").RefreshServerComplianceState
If the CBS store is marked corrupt no security updates can be installed and the store needs to be fixed.
the following articles describe the process in more detail:
HERE and HERE
The CBS log is located under: “C:\Windows\Logs\CBS\CBS.log”.
The large log file size sometimes causes issues when parsing the file for the correct log entry.
In addition to that, older logfiles are stored as CAB-files and can also be quite large in size.
The following script can be used to parse even very large files and related CAB-files for store corruption entries.
Get-CBSLogState.ps1
Yes, the following articles can help further troubleshoot update related issues:
Troubleshoot software update management
Troubleshoot software update synchronization
Troubleshoot software update scan failures
Troubleshoot software update deployments
Deprecation of Microsoft Support Diagnostic Tool (MSDT) and MSDT Troubleshooters - Microsoft Support
This is an non exhaustive list of actions which can help to positively impact software update compliance:
Start “cleanmgr.exe” as admin and delete unused files for example.
While the aim is to get to 100% fully patched systems, this goal can be quite hard in some situations. Some of the reasons behind bad patch compliance come from technical issues like the ones mentioned above under: “What can I do to increase my update compliance percentage?”. But other factors include the device delivery process for example. If you put ready to go systems on a shelf for a longer period, those devices will decrease overall patch compliance percentage.
To reach a high compliance percentage, know your workforce and know your update processes.
Reduce the blind spot and make sure each actively used system does not fall out of management due to errors, misconfigurations, or simply bad monitoring. Keep those devices on the shelf in mind and exclude them from compliance reporting for the duration of inactivity.
That’s it!
I hope you enjoyed reading this blog post. Stay safe!
Jonas Ohmsen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.