MSEndpointMgr
Home » Azure » Windows Update Settings Compliance

Windows Update Settings Compliance

In this post I will show you how to use Proactive Remediations and Log Analytics, together, to ensure Windows Update Settings are Optimal and Compliant on your devices. This post comes on the back of a session both Aria Carley and I presented at #MMSMOA this year – Fun times!

MMSMOA 2022

Background

I was working with a customer recently and we were having a conversation around the optimal settings to ensure a great experience when delivering Windows Update policy using Intune. It had occurred to me to mention that I had previously seen environments where legacy policy was either “breaking” updates completely or adversely affecting the update experience for the end users.

At around the same time, Aria had published a fantastic article on the Microsoft Tech community blog Why you shouldn’t set these 25 Windows policies

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/why-you-shouldn-t-set-these-25-windows-policies/ba-p/3066178

In the post Aria explains which settings will give your users a “sub optimal” experience with Windows Updates and which settings have absolutely no effect.

Excerpt from the Aria’s post

Previous experience taught me that there are also some legacy settings that will “absolutely break” the Windows Update experience for users – especially when the Windows Update workload is moved from ConfigMgr to Intune.

What are these bad settings you speak of?

NoAutoUpdate was a policy some ConfigMgr admins used to set back in the day. It was a way that some used to control duplicate Windows Update balloon notifications from appearing on Windows 7 devices. Largely, it is not used today but I still find this registry key tattooed on some of my customers devices.

NoAutoUpdate

DisableDualScan is another policy setting that can adversely affect the delivery of Windows Updates when you move workloads to Intune in a Co-management scenario. ConfigMgr will set DisableDualScan to 1 when the Windows Update workload is with ConfigMgr/WSUS. When you move the workload to Intune, ConfigMgr will change this value to 0 to allow the client to Dual Scan (against both the Windows Update Service and WSUS). If we run rsop.msc on the client we can see this policy enforced by Local Group Policy (ConfigMgr)

DisableDualScan Enabled

Once we move the workload to Intune, DisableDualScan is disabled

DisableDualScan Disabled

If you Disable Dual Scan using GPP/Script/CI then this value can be overwritten and cause issues when the workload is move to Intune. When the workload is with ConfigMgr, this setting is OK. When I move the workload to Intune, I expect the settings to stop being enforced (and not be overwritten).

Another “breaking” policy setting, if present when the Windows Update workload is moved to Intune, is DoNotConnectToWindowsUpdateInternetLocations (Thanks @mauriced)

DoNotConnectToWindowsUpdateInternetLocations

You guessed it, this setting will stop the client reaching out to the internet for Windows Updates. Not a setting you want to see enabled if you move your Windows Update workload to Intune/WUfB.

As well as the 3 settings above, Aria also calls out the Legacy policy settings in her post that will either cause a non-optimal Windows Update experience or actually have no affect on Windows Updates at all – once the Windows Update workload is move to the Windows Update Service.

I have listed the registry keys below that will either cause issues, a sub-optimal experience or have no impact at all.

Service Breaking Settings

Registry KeyRegistry Setting
Software\Policies\Microsoft\Windows\WindowsUpdateDisableDualScan
Software\Policies\Microsoft\Windows\WindowsUpdateDoNotConnectToWindowsUpdateInternetLocations
Software\Policies\Microsoft\Windows\WindowsUpdate\AUNoAutoUpdate

Service Affecting Settings

Registry KeyRegistry Setting
Software\Policies\Microsoft\Windows\WindowsUpdate\AUAutoInstallMinorUpdates
Software\Policies\Microsoft\Windows\WindowsUpdateAutoRestartDeadlinePeriodInDays
Software\Policies\Microsoft\Windows\WindowsUpdateAutoRestartNotificationSchedule
Software\Policies\Microsoft\Windows\WindowsUpdateAutoRestartRequiredNotificationDismissal
Software\Policies\Microsoft\Windows\WindowsUpdateBranchReadinessLevel
Software\Policies\Microsoft\Windows\WindowsUpdate\AUEnableFeaturedSoftware
Software\Policies\Microsoft\Windows\WindowsUpdateEngagedRestartDeadline
Software\Policies\Microsoft\Windows\WindowsUpdateEngagedRestartSnoozeSchedule
Software\Policies\Microsoft\Windows\WindowsUpdateEngagedRestartTransitionSchedule
Software\Policies\Microsoft\Windows\WindowsUpdate\AUIncludeRecommendedUpdates
Software\Policies\Microsoft\Windows\WindowsUpdate\AUNoAUAsDefaultShutdownOption
Software\Policies\Microsoft\Windows\WindowsUpdate\AUNoAUShutdownOption
Software\Policies\Microsoft\Windows\WindowsUpdate\AUNoAutoRebootWithLoggedOnUsers
Software\Policies\Microsoft\Windows\WindowsUpdatePauseFeatureUpdatesStartTime
Software\Policies\Microsoft\Windows\WindowsUpdatePauseQualityUpdatesStartTime
Software\Policies\Microsoft\Windows\WindowsUpdate\AURebootRelaunchTimeout
Software\Policies\Microsoft\Windows\WindowsUpdate\AURebootRelaunchTimeoutEnabled
Software\Policies\Microsoft\Windows\WindowsUpdate\AURebootWarningTimeout
Software\Policies\Microsoft\Windows\WindowsUpdate\AURebootWarningTimeoutEnabled
Software\Policies\Microsoft\Windows\WindowsUpdate\AURescheduleWaitTime
Software\Policies\Microsoft\Windows\WindowsUpdate\AURescheduleWaitTimeEnabled
Software\Policies\Microsoft\Windows\WindowsUpdateScheduleImminentRestartWarning
Software\Policies\Microsoft\Windows\WindowsUpdateScheduleRestartWarning
Software\Policies\Microsoft\Windows\WindowsUpdateSetAutoRestartDeadline
Software\Policies\Microsoft\Windows\WindowsUpdateSetAutoRestartNotificationConfig
Software\Policies\Microsoft\Windows\WindowsUpdateSetAutoRestartNotificationDisable
Software\Policies\Microsoft\Windows\WindowsUpdateSetAutoRestartRequiredNotificationDismissal
Software\Policies\Microsoft\Windows\WindowsUpdateSetEDURestart
Software\Policies\Microsoft\Windows\WindowsUpdateSetEngagedRestartTransitionSchedule
Software\Policies\Microsoft\Windows\WindowsUpdateSetRestartWarningSchd

Service Settings that have no effect

Registry KeyRegistry Setting
Software\Policies\Microsoft\Windows\WindowsUpdateDeferFeatureUpdates
Software\Policies\Microsoft\Windows\WindowsUpdateDeferFeatureUpdatesPeriodInDays
Software\Policies\Microsoft\Windows\WindowsUpdateDeferQualityUpdates
Software\Policies\Microsoft\Windows\WindowsUpdateDeferQualityUpdatesPeriodInDays
Software\Policies\Microsoft\Windows\WindowsUpdateElevateNonAdmins

What Intune Reports show me if I have these bad settings in my environment?

I like your sense of humour. But seriously, there is no reporting in Intune, today, that will show us if these settings are causing adverse effects on your devices and ultimately affecting your overall Windows Update Compliance level. I personally would like to see some of this stuff come up with telemetry to Update Compliance in Log Analytics but I am not expecting to see that anytime soon.

While we wait for unicorns and rainbows in Intune, I have built my own interim solution (with the help of previous community solutions), based on my previous experience and the advice given by Aria in the Tech Community post I listed earlier.

The Solution

The solution comes on the back of other great community solutions from the MSEndpointMgr team. We have been collecting Custom Inventory for a while now (thanks to @jankeskanke @mauriced @sandy_tsang @nickolaja).

Enhance Intune Inventory data with Proactive Remediations and Log Analytics – MSEndpointMgr

Running a Proactive Remediation, to inventory client Registry/WMI information and sending the results to Log Analytics for rich reporting, is what the cool kids are doing these days. It allows us to report client state information almost instantly, without having to wait for Intune reporting to get its act together.

Whilst Intune reporting leaves something to be desired today, I know the product group are working really hard to improve this experience for all of us – so thank you for your diligent and hard work. We wait excitedly for a great reporting experience natively in Intune.

Using the same methods as we do with Custom Inventory, the solution will do the following:-

  • Inventory the Windows Update Registry Settings that are known to affect the Windows Update experience
  • Collect other useful device information such as:-
SettingFunction
Script VersionTrack which script was used to collect inventory information
DeviceNameName of the Device
ManagedDeviceIDManaged Device ID in Intune. Can be useful if joining other Log Analytics tables
AzureADDeviceIDAzure AD Device ID. Can be useful if joining other Log Analytics tables
ComputerOSVersionWindows OS and Build Information
ComputerOSBuildOS Build Information
DefaultAUServiceIs the default AU Service Microsoft Update or Windows Server Update Services
CoMgmtWorkloadReturns True if the device co-management workload includes Windows Updates
CoMgmtValueWhich co-management workloads are set on the client
WSUSServerWSUS Server client is registered to
WSUSStatusServerWSUS Status Server client is registered to
  • Create a JSON payload and send the results to Log Analytics
  • Visualise the results in a Workbook for easy Compliance Reporting

With this information, we can start to understand if there are any legacy settings in our environment that are adversely affecting how we expect Windows Update to behave.

Scripts

Grab the script(s) from the MSEndpointMgr GitHub Reporting repo. One script requires you to embed the Log Analytics workspace workspace ID and shared key into the script. The other script, which is more secure, uses a Function app in Azure to authenticate your devices. It only requires you to embed the Function app URL in the script. Only devices registered in your tenant will have permission to upload to Log Analytics using the Function app (so cool).

Script Option 1 (Shared Key Embedded in Script)

Reporting/Invoke-WUInventory.ps1 at main · MSEndpointMgr/Reporting (github.com)

You need to replace CustomerID and SharedKey (Lines 27 and 30) with the correct value from your Log Analytics workspace

Get the Log Analytics Shared Key

CustomerID = Workspace ID
SharedKey = Primary Key

Script Option 2 (Function App URL Embedded in Script)

Reporting/Invoke-WUInventory_Funky.ps1 at main · MSEndpointMgr/Reporting (github.com)

Secure Inventory

As we pointed out earlier, using the Function app is a much better approach when sending data to Log Analytics because we don’t embed any secrets in the inventory script.

If you missed it, read more here about using Azure Function app to secure sending data to Log Analytics

Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr

Proactive Remediation

Either of the scripts above can be run as a Proactive Remediation. You should only set the Detection Script, there is no Remediation script required as we are simply using the detection script to send data to our Log Analytics workspace. You should also set the Proactive Remediation to run in 64 bit PowerShell.

Log Analytics

The first device to run the script will create a custom log in your Log Analytics workspace.

The log name can be changed in either of the scripts around line 30.

Log Name

If you change the log name from WUDevice_Settings, the workbook JSON that we use later will also need updating to reflect the new log name

All custom logs you create in Log Analytics will get a _CL suffix appended

Custom Log

As data starts to get uploaded, you will see a line entry each time the client sends data. We summarise multiple entries when we do reporting so we only show the latest record the client uploads. Here is an example of what the data will look like.

Example Data

Workbook

We could spend all day long writing KUSTO queries in Log Analytics – but there is a better way and someone else has done all the hard work for you. Grab the workbook source (copy as raw) from the link below so we can start to visualise the data from the logs.

Reporting/Windows Update Device Settings.workbook at main · MSEndpointMgr/Reporting (github.com)

Create a new workbook in the same Log Analytics workspace

New Workbook

Tap the advanced editor

Tap Advanced Editor

Paste in the raw data from the JSON above and tap Apply

Paste Workbook JSON

Tap the Save icon

Save

Specify a workbook name and validate the workspace settings

Validate Workbook Name and Settings

Tap Save and Done Editing

Your workbook should now start to look something like this. First we list some Windows Build Information. Remember, this is collected directly from the client and doesn’t rely on Update Compliance or Windows Telemetry data (which can be slow to update).

Dashboard Example 1

Next we show the “Service Breaking Settings”. If your devices show up here and the Windows Update workload is set to Intune/WUfB – they most probably are not getting Windows Updates!

Service Breaking Settings

Next we show you and settings on the devices that may affect the Windows Update experience i.e. it may be sub-optimal

Service Affecting Settings

Finally, on the dashboard, we show you settings that are in place that have no affect on the Windows Update experience – so why are you setting them?

Settings with no Impact

The other tabs will also show you some useful information

WSUS Settings and Scan Source
Co-management Information

Summary

Hopefully this post has helped you understand how awesome inventory scripts and Log Analytics are. We can manipulate the inventory scripts to collect a whole host of information from our devices.

This is Version 1 of the workbook. We have big plans on collecting more Windows Update related settings from devices and hopefully Version 2 of the workbook will TELL you which settings (GPO/GPP/CSP) that you need to change to ensure your devices are optimally configured to received updates using WUfB.

Big thanks to Aria for always being willing to share her brain and passion with the community and to my friends at MSEndpointMgr for being inspiring!

DM me on Twitter if you want further clarification around the topics listed in this post.

(8135)

Ben Whitmore

Microsoft MVP - Enterprise Mobility, Microsoft Certified Trainer and Microsoft 365 Certified: Enterprise Administrator Expert. Community driven and passionate Senior Cloud Consultant at CloudWay with 20 years experience in driving adoption and technology change within the Enterprise.

Maurice Daly

Maurice has been working in the IT industry for the past 20 years and currently working in the role of Senior Cloud Architect with CloudWay. With a focus on OS deployment through SCCM/MDT, group policies, active directory, virtualisation and office 365, Maurice has been a Windows Server MCSE since 2008 and was awarded Enterprise Mobility MVP in March 2017. Most recently his focus has been on automation of deployment tasks, creating and sharing PowerShell scripts and other content to help others streamline their deployment processes.

Jan Ketil Skanke

Jan Ketil is an Enterprise Mobility MVP since 2016 and are working as a COO and Principal Cloud Architect at CloudWay in Norway. He has been in the industry for more than 20 years working for both Microsoft Partners and Microsoft. He loves to speak about anything around Enterprise Mobility and Secure Productivity. He is also the lead for the community conference Experts Live Norway. Jan Ketil has presented at large industry conferences like Microsoft Ignite, Microsoft Ignite The Tour, Microsoft Inspire, Experts Live Europe, Techmentor HQ (3rd best session 2019) and NIC Conference in Oslo.

Sandy Zeng

Sandy is an Enterprise Mobility MVP since 2018. She is an experienced Information Technology Specialist for over 10 years. Skilled in Microsoft Endpoint Manager (ConfigMgr and Intune), Windows 10 and security. Sandy's interests are mostly related to Microsoft Technologies, she has passions learning new skill sets to improve her professional career and also as her hobbies. She uses her expertise to help customers achieve their goals and solve their issues.

Sandy founded the https://sandyzeng.com blog and is now a blogger on MSEndPointMgr.

6 comments

  • Thanks so much for posting, it’s a great article.

    I’m struggling with the last part, getting the Workbook to display the components. Each widget is showing an Error “You do not have authorization to make this request. Please check your permissions on the selected resources.”

    The Logs have been uploaded, and if I copy and paste an individual query it runs fine and returns results.

    This is probably me being stupid, but would really appreciate any guidance you can give.

  • Hi,
    Below an addition to line 93 with newest Co-Management workloads (above CM 2111)

    $CoMgmtArray = @(17, 19, 21, 23, 25, 27, 29, 31, 49, 51, 53, 55, 57, 59, 61, 63, 81, 83, 85, 87, 89, 91, 93, 95, 113, 115, 117, 119, 121, 123, 125, 127, 145, 147, 149, 151, 153, 155, 157, 159, 177, 179, 181, 183, 185, 187, 189, 191, 209, 211, 213, 215, 217, 219, 221, 223, 241, 243, 245, 247, 249, 251, 253, 255,8209, 8211, 8213, 8215, 8217, 8219, 8221, 8223, 8273, 8275, 8277, 8279, 8281, 8283, 8285, 8287, 8337, 8339, 8341, 8343, 8345, 8347, 8349, 8351, 8401, 8403, 8405, 8407, 8409, 8411, 8413, 8415, 12337, 12339, 12341, 12343, 12345, 12347, 12349, 12351, 12401, 12403, 12405, 12407, 12409, 12411, 12413, 12415, 12465, 12467, 12469, 12471, 12473, 12475, 12477, 12479, 12529, 12531, 12533, 12535, 12537, 12539, 12541, 12543)

Sponsors

Subscribe

Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.