Unless you have been hiding under a rock since Christmas, you should have heard about the new CPU vulnerability found in Intel and AMD chips: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002
Long story short, following this vulnerability Microsoft instantly made changes to their OS, requiring all AV (Antivirus) products to be compatible with these new changes.
Everything in details in this link: https://support.microsoft.com/da-dk/help/4072699
What the article also mentions is that any Windows OS won’t be offered the January Security Updates (and any subsequent) until a very specific registry key is present on the systems. This is seen, when computers in your environment doesn’t request the update when you expect it to, and when compliance reports in ConfigMgr tells you that the update show up as Not Required when you know it is.
Most AV products by this time do create the registry key already, but what if you do not use any AV (for whatever reason that may be), and what if you want to make sure the registry key is there already and always is. Use Compliance Settings in ConfigMgr. Usually for on-prem domain joined computers, I would stick to Group Policies, but for this in particular, Compliance Settings in ConfigMgr does a way better job in regards to remediation and reporting of compliance.
- Create a new Configuration Item in ConfigMgr following these snippets (Assets and Compliance tab)
- Add the newly created Configuration Item to Configuration Baseline, and deploy the baseline to selected collections.
Go to the Monitoring tab of the ConfigMgr console and expand Reporting -> Reports -> Compliance and Settings Management and find the report: Summary compliance by configuration baseline and lean back and watch how your clients are reporting back compliance. (Might take a while depending on your Client Policy Settings)