Intune

Guide for Managing Windows Updates via Intune

The entire demonstration of this post which illustrates a deep dive on Windows Update Management via Intune can be found below-

Understanding Windows-as-a-Service:

• Starting with Windows 10, Microsoft introduced a new servicing model known as “Windows as a Service” (WaaS), which means that instead of getting a new version around every three years, we now receive incremental updates.
• Prior to Windows 10, Microsoft released new versions of Windows every few years. This imposed a training burden on users because the feature revisions were often significant and had to wait long periods without new features.  
• Windows as a Service will deliver smaller feature updates two times per year, around March and September, to help address these issues.
• As a result of this new servicing model, we now have two types of updates: “Feature updates” and “Quality updates.” Both are equally important, but each one delivers a different set of improvements at different times.
• Feature updates add new functionality | Quality updates provide security and reliability fixes.

UNDERSTANDING WUfB:

• The Windows Update for Business deployment service is a free cloud service from Microsoft available to enterprise and education customers to manage and control the delivery and behavior of Windows Update. This free service (WUfB) deployment service is available for all premium editions, including Windows 10 and Windows 11 Enterprise, Pro for Workstation, and Education editions.

• We can use Group Policy or Mobile Device Management (MDM) solutions such as Microsoft Intune to configure the Windows Update for Business settings that control how and when devices are updated.

• By using Windows Update for Business, we can control -> Which types of Windows Updates are offered to devices in your ecosystem + When updates are applied + Deployment to devices in our organization in waves + control when updates are applied(By using Deferrals) + Pause the installation of updates

• The following are the updates that can be managed and controlled through WUfB.
• Feature updates
• Quality updates
• Driver updates/Firmware Updates
• Microsoft product updates

Comparison WSUS vs WUfB

Lets do a quick comparison between WSUS and WUfB in the table below-

WSUS	WUFB
Is a Windows Server role	Is a “cloud” solution
Can be managed from SCCM	Can be managed via GPOs or Intune
Clients scan against WSUS(cab file)	Devices communicate directly with Windows Update servers and requests for applicable updates
Administrators can manually approve updates	Administrators cannot approve selective updates
Provides more granularity	Easy to setup and use
Supports both-Windows Client and Server OS	Supports only Windows Clients

Windows update management approaches via Intune

The below diagram explains the various approaches by which we can manage Windows Updates from Intune

Now we will take a closer look into all the above listed approaches

Understanding Quality updates and managing them via Intune

• Quality updates/ Cumulative Updates/Cumulative quality updates are the mandatory updates that our computer downloads and installs automatically every month(on “Patch Tuesday”) through Windows Update.
• They are maintenance updates meant to fix bugs, errors, patch security vulnerabilities, and improve reliability with the current version of Windows .
• Quality updates download and install faster than feature updates because they’re smaller packages, and they don’t require a complete reinstallation. It’s not necessary to create a backup before installing them.

Quality Updates contain-

• Cumulative Update | On Patch Tuesday, the “YYYY-MM Cumulative Update for ” update is released with new security fixes.
• Cumulative Update Preview | Around the third Tuesday of the month, the “YYYY-MM Cumulative Update Preview for ” update is released with new non-security fixes.
• .NET Framework cumulative updates | .NET Framework is serviced separately, as “YYYY-MM Cumulative Update for .NET Framework 3.5 and 4.8 for ” updates on Patch Tuesday
• Servicing Stack (SSU) updates | they service the OS servicing stack (the thing that installs updates) itself.
• Update Stack Package | The Update Stack Package ensures that our PC has the highest likelihood of successfully installing new updates with the best and least disruptive experience available.

Understanding the background flow behind delivery of Quality Update via Intune:

We are going to reference the below diagram to understand the flow behind working of a Quality Update

As we can see in the above diagram, the flow can be broken down into 4 steps as explained below-

• 1- The first step is making the Update Ring policy in the Intune portal and deploying it to a device
• 2- The policy is delivered to the device via the MDM channel over a sync session. This can be tracked in the following logs at the device’s end.

SyncML logs
MDM Diag Logs
Event Viewer Logs
Policy Manager Registry

• Once the policy has been delivered, Intune’s job is done and Windows component in the OS takes over. The OS now follows the UUP model which determines the next sequencing.

Unified Update Platform (UUP) is a scan and download model for all types of OS updates which contains the below components-

Update UI – The user interface to initiate Windows Update check and history. Available under Settings> Update & Security> Windows Update. This manages the user experience.
Update Session Orchestrator (USO)– A Windows OS component that orchestrates the sequence of downloading and installing various update types from Windows Update. There is a service which runs for this component and it does the update scheduling

• 3- As per the policy received from Intune, which is now merged in the machine’s registry- the Orchestrator schedules the scan, verifies admin policies for download, starts the download. There are 4 components in the Operating System take over the proceedings from here, i.e. Update Agent, Windows Update Arbiter, Windows Update client and Orchestrator.

Update Agent, which is a component of the OS(a DLL) is downloaded when an update is applicable. It generates a list of payloads that are to be downloaded by the machine.

Windows Update Arbiter works as a deployment manager that calls different installers. The arbiter evaluates the manifest and tells the Windows Update client to download files.

Windows Update client reaches out to the cloud service and downloads files in a temporary folder.

Orchestrator starts the installation and restarts the machine(as per policy if applicable).

• 4- Once the update is done successfully at the device end, the Intune service is notified of the same.

More details on this section can be found in our official documentation https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-overview

Troubleshooting- Quality Updates using logs and Registry

If we have encountered any issue while delivering Quality update via Intune, then we can use the below block diagram as a troubleshooting approach.

Now lets use the above block diagram as a reference and look at the troubleshooting approach.

• The first step of troubleshooting is to verify the status of the policy delivery from the Intune console as shown below

• Now if we take a SyncML trace at the device end, we can see the policy getting delivered via Intune as shown below

• We see that the settings in the policy correspond with the settings that is getting delivered to the device(in the SyncML trace)

• We will also be able to see ‘Updates’ as a managed workload in settings under the Device Management section.

• As per the settings in the policy, we should see a message stating that the update settings in the device is being managed and the option to Pause an update should be blocked(if selected in the policy)

The UI also shows the specific settings related to Windows Update which are being managed by the MDM

• We can also see the settings as per the policy in the MDM diag logs to confirm that the same has been delivered to the device successfully.

• Now the next place to check while troubleshooting is the registry. All the policies delivered from Intune reside in the ‘Policy Manager’ node, hence as shown below we are going to check the entries in the ‘update’ hive which should correspond with the settings in the policy

• Now the next part of troubleshooting is checking the eventviewer logs. All the policies deployed from Intune are going to be logged in which has been referenced below

• If an update has been successfully installed in the device via Intune, it will show in the ‘Update History’ section of the UI

• The next place for logging is the Windows update logs present in C:\WINDOWS\Logs\WindowsUpdate which contains all the update logs in form of .etl

• As shown below, in the .etl file we can see the download request creation for the download of the update, update getting downloaded from Windows Update endpoint in the cloud, the total size of the file downloaded etc

Understanding Feature updates and managing them via Intune

Background of Feature Updates:

• On Windows, features updates are technically new versions of the OS, which are available twice a year. These updates typically include new features/visual improvements.
• Feature updates are bigger in size than quality updates. The download size can be close to 3GB, depending upon the OS version and hence they take longer to apply

• Intune supports setting a feature level to any version that remains in support at the time we create the policy and the device updates to the version of Windows specified in the policy.
• A device that already runs a later version of Windows remains at its current version. By freezing the version, the devices feature set remains stable during the duration of the policy.
• A device won’t install an update when it has a safeguard hold for that Windows version.
• While the feature version remains static, devices can continue to install quality and security updates that are available for their feature version.

The feature updates policy brings devices to a specified Windows version and freezes it. This means, even if the device might be eligible to update to the next OS version, the same will be blocked. So essentially with Feature updates policy we can select the Windows feature update version that you want devices to remain at, in our organization

Requirement:

Editions:

• Windows 10/11 Pro | Enterprise | Education
• Have Telemetry turned on, with a minimum setting of Required.

License:

Telemetry:

• One of the other requirement for Feature update to work is setting up of the Telemetry in the device. The telemetry in the device should be Turned ON and set to Required so that the device can send the relevant data to DSS. The telemetry can be turned ON by sending a Device Config policy from Intune or a CSP as documented below-
• https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-feature-updates
• https://learn.microsoft.com/en-us/mem/intune/configuration/device-restrictions-windows-10#reporting-and-telemetry

Microsoft Account Sign-In Assistant (wlidsvc):

• The Microsoft Account Sign-In Assistant (wlidsvc) must be able to run. By default, the service is set to Manual (Trigger Start), which allows it to run when needed.

Understanding the background flow behind delivery of Feature Update via Intune:

Now we are going to reference the below diagram to understand the flow behind working of a Feature Update policy via Intune.

As we can see in the above diagram, the flow can be broken down into 7 steps as explained below-

• 1- DSS service(Deployment Scheduling Service) is a cloud service that runs in the backend. We must first configure the telemetry using CSPs or policies in the Windows devices. Device leverages its AAD deviceid and establishes a relationship with DSS so that it can send all its update related data to DSS.
• Once the client has been enabled to do that, device will start sending all its windows update related data to DSS.DSS and the Device become friends!

• 2- Now in the 2nd step the Intune admin creates a Feature Update policy at the Intune portal

• 3- Intune has the ability of talking to the DSS service. Intune gives the feature update policy(made by the Intune admin) with policyid to DSS
• Creating a Feature Update Policy in Intune creates an equivalent DSS Policy – for every Feature Update Policy ID, there should be a DSS Policy ID.
• Intune will take the policy data + device ID and hand it over to DSS. We can check and confirm that the AAD Device ID has been added to the DSS Policy assignment list, thus offering the update to the device
• The policy given by Intune service to DSS contains all the relevant information- like the feature to which the device should be blocked the update behavior etc

• 4- DSS recognizes the device as DSS and device are already friends from earlier!.

• 5- Now when the device talks to DSS, DSS can monitor and administer the update progress of the device as per the policy it has already received. The device requests for updates from the DSS service barring the safeguard holds

• 6- DSS will offer the applicable feature updates as per the policy body it had already received from Intune.

• 7- it will download/install the relevant feature update applicable from DSS along with post installation behavior which the device is to follow

• 8- The device will upload the relevant data to DSS. And DSS will forward that data to Intune for reporting. The major heavy lifting is done by DSS and not Intune

Important
Feature Updates(unlike the Update Ring policy,) does not deploy PolicyCSP towards the device.
We will not see anything in the Eventviewer/SyncML/MDM Diag logs at the device’s end.
We will not see registry keys in the ‘policy’ node being updated while using Feature Updates.
The communication happens between Intune and Windows Update Service
The Feature Update policy needs to be deployed to Device Groups (and not User Groups)

Troubleshooting- Feature Updates using logs and Registry

Now we are going to reference the below diagram while troubleshooting any Feature Update related issues via Intune

• The first step is to check the status of the policy for Telemetry as viewed in the Intune portal. This is a pre-requisite

• If the above policy for turning on the Telemetry is delivered to the device, the below registry gets updated accordingly.

• The next step is to ensure that the Microsoft Account Sign-In Assistant service is running in the device.

• The deferral period in the Update ring policy should be set to 0 days. The same should reflect in the registry as shown below

Note- The above value is set in the Windows Update ring policy

• We have to check and make sure that the value of ‘GStatus’ should be non-zero

• The next step is to check for any safeguard hold in the operating system

We can run the below Powershell commands while troubleshooting a client for Safeguard holds.

Install-Module –Name FU.WhyAmIBlocked

Import-Module FU.WhyAmIBlocked

Get-FUBlocks

https://www.asquaredozen.com/2020/07/26/demystifying-windows-10-feature-update-blocks/

• Even though its not recommended, the below official doc shows how we can opt out of Safeguard Holds from a device.

• Now need to enable Windows Health Monitoring and in its scope add Windows updates

• The next place to check is the device side ‘System’ logs which is going to capture any events for Feature Update installation

• The last place to check for, is the Windows Update report for the relevant Feature Update policy.

• If the device got the correct Feature Update delivered but the installation failed, along with the Windows update logs, we can also see the same in the below UI

Windows Update + Autopilot

• During an Autopilot deployment, only critical driver updates and Windows Zero Day updates get installed during OOBE. Feature updates cannot be applied during the Autopilot out of box experience (OOBE).
• The policies apply at the first Windows Update scan after a device has finished provisioning, which is typically a day.

The below documentation explains some more background on this topic.

Installing Windows updates during a Windows Autopilot deployment

Windows Update + Co-management

• In case of Co-managed scenarios, feature updates policies might not immediately take effect on devices when we newly configure the Windows Update policies workload to Intune. This delay is temporary but can initially result in devices updating to a later feature update version than is configured in the policy.
• Monitor the report for the policy. To do so, go to Reports > Windows Updates > Reports Tab > Feature Updates report. Select the policy you created and then generate the report.

• Devices that have a state of ‘OfferReady’ or later, are enrolled for feature updates and protected from updating to anything newer than the update we specified in the policy.
• With devices enrolled for updates and protected, we can safely change the Windows Update policies workload from Configuration Manager to Intune

• The official document from Microsoft explains the above scenario in detail
• https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-feature-updates#limitations-for-feature-updates-for-windows-10-and-later-policy

Removing a Feature Update

• When a device is no longer assigned to any feature update policies, Intune waits 90 days to unenroll that device from feature update management and to unenroll that device from the deployment service.
• This delay allows time to assign the device to a different policy and ensure that in the meantime the device doesn’t receive a feature update that wasn’t intended.

Understanding Expedited updates and managing them via Intune

• By using expedited updates, we can speed installation of quality updates(like an out-of-band security update for a zero-day flaw.) This is the ‘Fast Lane’ – extremely useful if you want to deploy a hotfix quickly. We might expedite a specific update to mitigate a security threat when your normal update process wouldn’t deploy the update for some time.
• Not all updates can be expedited. Only Windows 10/11 security updates that can be expedited are available to deploy with Quality updates policy.
• To speed installation, expedite updates uses available services, like WNS and push notification channels, to deliver the message to devices that there’s an expedited update to install.
• This process enables devices to start the download and install of an expedited update as soon as possible, without having to wait for the device to check in for updates.
• When a restart is required to complete installation of the update, the policy helps to manage the restart.
• In the policy, we can configure a period that users must restart a device before the policy forces an automatic restart.

Only devices that need the update, receive the expedited update. Windows Update evaluates the build and architecture of each device, and then delivers the version of the update that applies.

Expedite update policies ignore and override any quality update deferral periods for the update version we deploy

Understanding the background flow behind delivery of Expedited Update via Intune:

• We are going to reference the below flow diagram to understand the background behind working of an Expedited update.

As we can see in the above diagram, the flow can be broken down into 6 steps as explained below-

• 1- Intune Admin creates/assigns the Expedited update profile
• 2- Intune service talks to WUfB service and updates about the policy/device. This communication can be tracked in the service side logs
• 3-WNS sends a Push Notification to deliver the message to devices that there’s an expedited update to install, instead of waiting for the regular Windows Update client sync. The Microsoft Update Health Tools receives the policy
• 4- The Windows Update Client service(running in the device) reaches out to Windows Update service in cloud and requests for the selected/applicable update
• 5-Windows Update evaluates the build and architecture of each device, and then delivers the version of the update that applies which is in accordance with the policy created by the admin. The update is downloaded and installed in the machine
• 6-Microsoft Update Health Tools sends the status back via telemetry which is provided to the Intune service for reporting

Troubleshooting- Expedited Updates using logs and Registry

• The first thing to check while troubleshooting is the Update Ring policy at the portal. The Notification Level should be set to default and it should NOT be Turned Off

• The Windows update Health Tool should be installed in the machine
• We can view from it from the control panel and check its version from Powershell. We have to also ensure that its corresponding service should also be running in the device as shown below

• If the Windows Update Health Tool is not present in the machine, we have an option of deploying the same from Intune. We can download it from our official website as shown below

• The above downloaded tool is in the format of .msi, so it can be deployed from Intune as a LOB app.

• Alternatively, we can also deploy the below Powershell script which is going to install the relevant module and download the kb for Windows Update Health Tool

• We should also check and ensure that the registry which enables the device to send its Telemetry to Windows Service is also set correctly as shown below

• The next thing to check is the ‘UHS.SERVERNAME’ key in the below registry key, which should point to the relevant Microsoft endpoint.

• The next location to check for is the Windows Update logs which is going to capture the download and installation of the Expedited Updates

• The last thing to check for, is the reporting for the policy that we have created in the portal.

Key Pointers:

• Enabling and Configuring Health Monitoring/Telemetry and making sure the Update Health Tools are installed.
• Making sure that the Update notification settings are Not disabled
• Making sure that the user has all the needed License in place (Intune and Windows)
• We should ensure that there are no legacy old gpo’s interfering and the device is not pointing to WSUS like an example

Deploying an Update (specific patch/kb) as Win32app

• If we wish to deploy a specific kb to a device via Intune, we have the option of deploying it as a Win 32 app.
• We would have to Download the kb(in .msi/.msu format)>Convert it into .intunewin format>Deploy the same from the portal

• Once the same is deployed, we can check the IME logs and track its flow of installation, as shown below

• We can use the below PowerShell script for reference, (in the Detection logic) while deploying the kb in form of win32 app

Managing Windows Updates using CSPs:

• If there is any setting that is not present in the Intune UI, we always have the option of directly targeting the setting which is exposed in form of CSP by the operating system via OMA-URIs
• The below list shows the CSPs related to Windows Update which can be targeted.

Official documentation for the same can be found below-

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update

More information on this topic can be found https://www.petervanderwoude.nl/post/managing-windows-update-for-business-on-windows-10-via-oma-dm/

Deploying an Update using Powershell Modules:

• The below official document from Microsoft explains how we can use the PowerShell modules for managing Windows Update

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/powershell-for-the-windows-update-for-business-deployment/ba-p/2437208

Deploying an Update using Graph APIs:

• The below official document from Microsoft explains how we can use the Graph APIs for managing Windows Update

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/public-preview-of-microsoft-graph-apis-to-manage-windows-updates/ba-p/2302751

Deploying Driver and Firmware updates:

Background:

• Microsoft has released a new deployment service for driver and firmware updates, which gives us visibility into the drivers hosted in Windows Update that are a match for your enterprise devices and offering you control over both the selection of individual updates and the scheduling of update deployments to devices from Windows Update.
• IT admins can access the deployment service in Intune by creating Driver Update Policies and assigning devices to them. Once a device is under the purview of such a policy, the deployment service allows Windows Update to make its selection decisions, but the results are sent to the admin for review and action instead of simply offering the drivers to the device..

Using this policy, the admins can review available content and then make approval decisions on a per driver basis.
The Drivers are not offered by default – Only after a driver is approved by the admin, it is deployed to the device.

Understanding the background flow behind delivery of Drivers and Firmware via Intune:

• We are going to reference the below diagram to understand the delivery of firmware/drivers via Intune

As we can see in the above diagram, the flow can be broken down into 7 steps as explained below-

• 1- Intune Admin creates a Driver Update policy in the Intune portal. The same needs to be targeted to a device group
• 2- The policy is updated in Windows Update (DSS) service much like feature update policy. The policy body and deviceid is provided to DSS by Intune
• 3-The device reaches out to Windows Update service and performs a scan for Firmwares and Drivers. This is a normal scan performed by the Windows Update client in the device wherein the device is discovering the applicable firmware updates.
• 4-The scan result which contains the applicable drivers is sent to the Intune service
• 5-Intune populates available driver updates for those devices based on the data from the software update service.We can see all the drivers and firmwares that are applicable for the devices
• 6-Intune Admin approves the selected driver updates The admin can approve and schedule the deployment on pre-driver basis. The admin has the ability of select a particular driver amongst the list of applicable drivers for the machines. Intune admin approves a specific driver for device which is updated to the Windows Update service
• 7-Now when the device scans again, Windows update service knows exactly which firmwares to offer as approved already by the admin
• Other applicable drivers are not offered to the device(even though they are applicable). The device only gets the firmwares/drivers which are trusted and approved the admin
• The device installs the firmwares/drivers offered to it and the inventory is updated

Using Win32 app deployment approach for Driver updates:

• If we wish to deploy a specific driver, we can use the Win32 app approach to do the same. We would have to package the driver to .intunewin file and then we can deploy the same. The below blog sheds some light onto the process.

https://thinkdeploy.blogspot.com/2019/03/deploying-thinkpad-bios-updates-with.html

Endpoint Manager simplifies upgrades to Windows 11:

Via Intune, now the process of upgrading a device to Windows 11 is simplified. As shown in the screenshot below, the same can be selected in the Intune policy itself.

The below official document from Microsoft sheds more light into the process.

https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/endpoint-manager-simplifies-upgrades-to-windows-11/ba-p/2771886?fbclid=IwAR07_y3TGo3KUD84Ybk2QvRxNBLiwtjjaS3DY6ast-5cC082CRxh9xwbv3E

Reminder:

Intune delivers policies, not the updates.
Windows Update for Business is a separate component from Intune. Intune defines an Update schedule for Windows Updates

We dont have an option of selectively deploying patches(by creating baselines) from Intune (like we do with SCCM)

Best Practices:

• Using rings incrementally. so that if anything goes wrong with Ring1, we have the ability to pause the subsequent prod rings
• Efficient use of Deferral, Deadline and Grace period
• Using Expedite Updates when updates are to be deployed faster than normal schedule.

• Ring 1 which has zero deferral can be used for testing. This can be targeted to a small set of test devices to see the behavior of the devices post patching.
• Ring 2 with a 5 day deferral can be used for patching the local IT. This would be our pilot set of devices.
• Ring 3 with 10 days deferral can be used for patching the rest of the devices in our organization.
• Using an incremental approach of Rings like above provides us a very good control. If there is a patch released by Microsoft which causes any anomaly, we can identify the same in Ring1/Ring2 itself and pause the Ring 3 until that is remediated (internally or by Microsoft in form of a fix), hence our prod devices remain unaffected

I hope this blog was helpful in understanding the basics and background of Windows update management via Intune