Windows Update Baseline joins the Security Compliance Toolkit

Published Jan 26 2021 09:07 AM 13.8K Views


We are excited to announce the Update Baseline is now a part of the Security Compliance Toolkit! The Update Baseline is a new security baseline to ensure devices on your network get the latest Windows security updates on time while also providing a great end user experience through the update process.  


The Update Baseline covers Windows Update policies as well as some additional Power and Delivery Optimization policies to improve the update process and ensure devices stay secure. 


Why do I need the Update Baseline? 


We recommend using the Update Baseline to improve your patch compliance and keep devices on your network up to date and secure. The Update Baseline is Microsoft’s set of recommended policy configurations for Windows Updates to ensure devices on your network receive the monthly security update in a timely manner. Devices that are configured for the Update Baseline reach on average a compliance rate between 80-90% within 28 days. 


What is included in the Update Baseline? 


For Windows Update policies, the Update Baseline ensures: 

  • Setting deadlinesDeadlines are the most powerful tool in the IT administrator’s arsenal for ensuring devices get updated on time. 
  • Downloading and installing updates in the background without disturbing end users. This also removes bottlenecks from the update process. 
  • A great end user experience. Users don’t have to approve updates, but they get notified when an update requires a restart. 
  • Accommodating low activity devices (which tend to be some of the hardest to update) to ensure the best-possible user experience while respecting compliance goals. 





Learn more about common policy configuration mistakes for managing Windows updates and what you can do to avoid them to improve update adoption and provide a great user experience. 


How do I apply the Update Baseline? 

If you manage your devices via Group Policy, you can apply the Update Baseline using the familiar Security Compliance Toolkit framework. With a single PowerShell command, the Update Baseline Group Policy Object (GPO) can be loaded into Group Policy Management Center (GPMC).  




The MSFT Windows Update GPO that implements the Update Baseline is added to GPMC with a single command. 




You will then be able to view the Update Baseline GPO (MSFT Windows Update) in GPMC. 


That’s it! It’s that simple. 


Other cool tidbitsThe Update Baseline will continue to be updated and improved as needed, and a Microsoft Endpoint Manager solution to apply the Update Baseline is coming soon! Let us know your thoughts and leave a comment below. 

New Contributor

@Rick_Munck Wouldn't the 'Allow standby states (S1-S3) when sleeping (on battery)' and 'Allow standby states (S1-S3) when sleeping (plugged in)' directly conflict with the intended values from the BitLocker baseline policy (referencing the latest 'MSFT Windows 10 20H2 - BitLocker', but they have been recommended that way for many baselines now)? Perhaps the intention is that if one is using BitLocker, we favor those settings, but if the Update Baseline is intended to be used in tandem with the other baselines, it just seems a little bit odd that we would have conflicting settings.


In addition, aren't a number of the configured settings functionally enforcing defaults? I am assuming that is probably fully intentional, as perhaps the team believes these are settings that would be misconfigured by an unaware admin, but as there has been a push in the recent past to reduce the number of unnecessarily configured settings (meaning we are enforcing the same state as 'Not Configured'), I just wanted to double check.


@Alex Entringer Great callouts! Both of your statements are correct.


Thanks for your feedback. The Update Baseline is meant for admins really focused specifically on update velocity and calling the potential of policies for that goal. We know not everyone uses the BitLocker GPO just like not everyone uses the Update Baseline so like you said it's based on the needs of each unique organization. 


Yes, we absolutely recommend that default is best (i.e. leaving policies as 'Not Configured' or enforcing the same state as 'Not Configured'). The purpose of the Update Baseline was to help admins clean up their misconfigured policies and get to a known good state. Hence the policy configurations mirror the default experience of when the policies are left as 'Not Configured.'

Regular Visitor

Regarding the Endpoint Manager solution.

  • Will it be a GPO managed solution or a Endpoint manager baseline?
  • Can you share your thoughts how to control the baseline if a company has decided only to deploy a subset of available updates.
    • e.g. only security updates

Looking forward to see the final work




Hi @Rene_kierstein,

The current solution that is out is for GPO. We are working on an intune solution to come this year. :)


For your second question--how can we adjust the baseline if a company only wants to deploy a subset of available updates (such as security updates)? The majority of policies that are configured in the Update Baseline are around user experience (e.g. notifications, access to features, etc) which is applicable to any type of update you are deploying to devices. To ensure your devices only get specific updates--for the sake of this example I will use security updates as the only type of update you are looking to deploy--I would check the following:

  • Make sure all drivers and Microsoft product updates are turned off
    • "Do not include drivers with Windows Updates" - Set this to Enabled.
    • "Configure Automatic Updates" - Make sure "Install updates for other Microsoft products" is not selected.
  • If you are not deploying Feature Updates via Windows Update, is your device configured to connect to a WSUS server?
    • "Specify intranet Microsoft update service location."
  • I'd also double check Deadlines/offering policies (such as deferrals and pause) which also affect when the Feature Update vs Quality Updates are offered.
Occasional Visitor

I'd recommend checking the "Don't auto-restart until end of grace period" under:

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Specify deadline for automatic updates and restarts


The reasoning is, the updates apply and the end user receives a notice their organization requires a restart in x days to apply the updates.  The user interprets this as they have x days before they'll need to restart.  Not so.  When the active hours expire, the PC reboots.  Users may lose data if they weren't expecting a reboot.  Or, change the notification to the PC will reboot anytime today after x (end of active hours) if the user is inactive/idle.

Occasional Contributor

@CaseyS In "Specify deadline for automatic updates and restarts" choose "Don't auto-restart until end of grace period" (under the "Grace period (days)" selection).

Established Member

What is the rationale behind enforcing the Power Management settings?


@Nasser_Alhamdan The reason we include power management settings is to widen the window of when your device can take an update. These small tweaks to the power settings gives additional flexibility of when end users take the update and can improve IT admins' overall adoption rates.

Senior Member



Can SCT 1.0 Policy Analyzer, do more than SCCM compliance baseline? What scan for device and report back which is non compliance?

Senior Member



I am testing the baseline for use in a higher-ed environment and I am trying to tweak the notifications to give faculty and researchers every opportunity to restart themselves before being forced.  However in testing the baseline via GPO on a Windows 10 Education 1909 VM I am noticing that I am not getting any notifications indicating that a restart will happen other than the icon in the System Tray and the change to the Shutdown/Restart options from the Start Menu.  The baseline says that it is enforcing the defaults which I understand should  be to notify before restarting, but that doesn't seem to be the case.



I notice in the Advanced settings of the update panel that the option for Update notifications seems to be defaulted to Off (this was also the case after my clean install/domain join/no policy).


I have allowed access to the pause updates option to allow faculty/researchers to pause updates to allow for any computational runs to complete before restarting, but I can't seem to find the right combination of settings in the GPO to notify users properly.


Is there some recommended settings you can suggest?

Not applicable

@Russellang - if what you're asking is whether Policy Analyzer can be automated to serve as a compliance-verification tool non-interactively, at scale, etc., no. It's designed to be an interactive tool only.


Hi @John Siewert,


We actually just resolved a similar issue around the notifications. :) I encourage you to check out this thread. Basically what happened was after they had deployed the Update Baseline, they hadn't removed the reg keys of the Not Configured policies which was causing their notifications to be blocked. Once they removed those remaining reg keys they were able to get notifications as expected.


I strongly suggest getting to the known good state according to the Update Baseline first and see if those notifications fit your users needs. There are alternate ways to produce more notifications, but we don't recommend them as they can hurt your compliance rate by creating a bottleneck around end user interaction. For your case, I'd recommend allowing the download and install to happen automatically in the background and then to start showing notifications when it's time to restart (as the Update Baseline configures so).


Let me know if you have any other questions or issues.




Senior Member

Thanks @Kay_Toma,


The VMs I have used for testing have been deployed via MDT using a custom gold image but I have the update steps in the Task Sequence disabled for these deployments.  I also don't domain join them during OSD so I can take a checkpoint of the fresh deployment and then join the domain into my test OU.  So these machines should not have any previous policy remnants getting in the way.


I changed the settings you suggested yesterday in the test policy and then deployed a new VM to test the policy.  Updates were installed yesterday and now I am just watching to see if I get any notifications before restarting.  The Start Menu Power indicates updates need a restart as does the Taskbar icon.  I haven't seen a toast notification yet though.


I have seen references to the registry key "restartnotificationsallowed2" in HKLM\Microsoft\WindowsUpdate\UX\Settings and setting the value to 1.  I have tried that and yet the option in Settings>Update & Security > Windows Update > Advanced options for "Show a notification when your PC requires a restart to finish updating"  remains Off and is unchangeable as it says it is managed by my organization.  Should that registry key be set?


- John

Senior Member

I decided to set every setting under Windows Update to Not Configured except the once I know I want configured and that got notification working as soon as the VM hit the WSUS server.  The one on the left is the new VM with the stripped back policy, and the one on the right is the one with the two settings changed back to Not Configured as you suggested yesterday.




The policy for the one that hasn't received any notifications yet has these settings, which is a slightly modified version of the baseline:

Update Baseline with ModificationsUpdate Baseline with Modifications


The one that was instantly notified has these settings:

Stripped back PolicyStripped back Policy


So in my testing it seems that even though the baseline is enforcing the defaults, something in it is preventing notifications.

Version history
Last update:
‎Jan 26 2021 09:07 AM
Updated by: