Hi, Jonas here!
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 😉
First things first
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…
Is there a way to optimize report performance?
The underlaying SQL query might require more time in environments with a lot of managed devices.
There are three ways to increase report performance:
- Import the reports with parameter "-ForceLegacyCardinalitySQL2016SP1AndHigher" to instruct SQL to use an older execution plan mechanism. Read more about it HERE
- Enable data caching for the main dataset. Read more about it HERE
- Choose a collection with less managed devices. You can also import the reports with parameter "-DefaultCollectionID" and "-DefaultCollectionFilter" to change the default collection parameter of the report. Or use Report Builder to do the same.
The OSType field does not contain any data. What should I do?
This can mean two things.
- No ConfigMgr client is installed. In that case other fields like client version also contain no data. Install the client or use another collection without the system in it to run the report and therefore exclude the system from the report.
- The system has not send any hardware inventory data. Check the ConfigMgr client functionality.
Some fields contain a value of 999. What does that mean?
There is no data for the system found in the ConfigMgr database when a value of 999 is shown.
- “Days Since Last Online” with a value of 999 typically means that the system had no contact with ConfigMgr at all. Which either means the system has no ConfigMgr client installed or the client cannot contact any ConfigMgr management point.
- “Days Since Last AADSLogon” with a value of 999 means there is no data from AD System or Group Discovery in the ConfigMgr database for the system.
- “Days Since Last Boot” with a value of 999 means there is no hardware inventory data from WMI class win32_operatingsystem in the ConfigMgr database for the system.
- “Month Since Last Update Install” with a value of 999 means there is no hardware inventory data from WMI class win32_quickfixengineering in the ConfigMgr database for the system.
Why does the "last rollup installed" compliance drops every second Tuesday to 0%?
This can happen if you immediately expire superseded updates. In that case we have no "last rollup" anymore and the database has only information about the latest rollup. Hence the percentage drop.
Open the ConfigMgr console and go to: "\Administration\Site Configuration\Sites" mark the CAS site or single Primary and go to: "Configure Site Components" and "Configure Software Update Point". Select "Supersedence Rules" and make sure that both settings are set to at least three month (which is the default).
What does WSUS Scan error stand for?
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.
I found WSUS scan errors with a comment about a WSUS GPO
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.
I found WSUS scan errors mentioning the registry.pol file
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.
I found WSUS scan errors mentioning a proxy problem, how can I fix that?
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:
- Open a command prompt as admin and run “netsh winhhtp show proxy”
- If a proxy is present, either remove the proxy with: “netsh winhttp reset proxy”
- Or, add either the WSUS server FQDN or just the domain to the bypass list.
- Example: netsh winhttp set proxy proxy-server="proxy.domain.local:8080" bypass-list="<local>;wsus.domain.local;*.domain.local"
- Use either “wsus.domain.local” or “*.domain.local” in case your wsus is part of domain.local.
- In some cases the proxy is set for the local SYSTEM account
- Open: “regedit” as administrator
- Open: [HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections]
- Set “ProxyEnable” to “0” to disable the use of a proxy for the system account
When should I restart systems with a pending reboot?
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.
Some systems have all updates installed, but some deployments still show as non-compliant (Column: “Deployments Non Compliant”) What can I do?
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:
- Remove older updates from an update group in case they are no longer needed
- Remove the deployment completely
- Delete the deployment and create a new one.
All actions will result in a re-evaluation of the deployment.
Column “Update Collections” does not show any entries.
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.
What is the difference between “Missing Updates All” and “Missing Updates Approved”?
“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.
Some systems are shown without any WSUS scan or install error, but have still updates missing. What can I do to fix that?
There can be multiple reasons for that.
- Make sure the system is part of a collection with update deployments first
- Check the update deployment start and deadline time and if the system sees (time is past start time) and is forced to install the update (time is past deadline time)
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”.
- Make sure the system either has no maintenance window at all or a maintenance window which fits the start and deadline time.
- Make sure a maintenance window is at least 2h long to be able to install updates in it
- Also, check the timeout configured for deployed updates on each update in the ConfigMgr console.
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.
- Check the restart notification client settings. This is especially important in server environments where a logged on user might not see a restart warning and therefore might not act on it. The restart time will be added to the overall timeout of each update and could exceed the overall allowed installation time of a maintenance window
- Check the available space on drive C:\. Too little space can cause all sorts of problems.
Start “cleanmgr.exe” as admin an delete unused files.
- If nothing else worked: Reboot the system and trigger updates manually
- If nothing else worked: Re-install the ConfigMgr client
- If nothing else worked: Follow the document: “Troubleshoot issues with WSUS client agents”
Some systems are shown as uncompliant, but all updates are installed? What can I do to fix that?
This can either be a reporting delay or a problem with update compliance state messages.
- If the update installation just finished, wait at least 45 to 60 minutes. This is because the default state message send interval is set to 15 minutes and the report result is typically cached for 30 minutes.
- If the update installation time is in the past, this could be due to missing 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
Installation errors indicate an issue with the CBS store. How can this be fixed?
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
Are there any additional resources related to update compliance issues?
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
What can I do to increase my update compliance percentage?
This is an non exhaustive list of actions which can help to positively impact software update compliance:
- As mentioned before do not leave a system too long in a pending reboot state.
- As mentioned before make sure to always have enough space left on disk C:\ (~2GB+ for monthly security updates, ~10GB+ for feature updates)
Start “cleanmgr.exe” as admin and delete unused files for example.
- Make sure a system has enough uptime to be able to download and install security updates.
- If a system has limited bandwidth available it might need to stay online/active a while longer than other systems with more bandwidth available
- You also might need to consider power settings for systems running on battery
What is a realistic update compliance percentage?
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
Microsoft
