Introduction:
In recent weeks, I was working on a project to transition devices from Citrix VDI to the Azure Virtual Desktop (AVD) platform, managing all AVD devices using Microsoft Intune as the device endpoint solution. While the AVD devices had the SCCM (MECM) agent installed, I encountered a noteworthy issue with Windows Update for Business (WUfB) that led me to an interesting discovery and a solution.
WUfB Delay Issue:
Upon provisioning and enrolling AVD devices in Intune, I observed a delay in the WUfB scan, with the devices not reporting to the WUfB service (Log Analytics) for several days. Despite successful deployment of WUfB policies and verification in Intune update rings, the devices remained inactive in terms of the update scan. While the configuration profiles, applications etc that were target to devices had no issues.
Troubleshooting and Discovery:
To troubleshoot the issue, I was given a AVD device that had been idle for several days. After completing the user sign-in (Out of Box Experience or OOBE), I checked the registry to verify the update ring policies. Surprisingly, post sign-in, the device initiated the Windows Update process and began receiving updates.
User Sign-In (OOBE) Requirement:
A conversation on Twitter with Microsoft revealed that, for AVD devices (and also physical devices), the user sign-in (OOBE) is crucial for the WUfB process to complete successfully. Interestingly, Windows 365 devices do not face this issue. The implication is that AVD devices need the user to sign in and complete the OOBE experience before registering with the WUfB service for a successful deployment.
AVD Team Recommendations:
In light of this, I have advised the AVD team not to keep devices online for extended periods without user-signs. Prolonged online status can trigger Qualys scans by the security team, reporting non-compliance and affecting the overall compliance status. Alternatively, the AVD team must ensure that they use an up-to-date image each time they provision devices, a task that can become tedious.
Workaround:
After a few days, I come across a Microsoft article that addressed my issue directly. The solution involves setting registry values to allow devices to initiate background update work before the initial user sign-in.
In scenarios where initial sign-in is delayed, setting the following registry values allow devices to begin background update work before a user first signs in:
-
- Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator - DWORD value name: ScanBeforeInitialLogonAllowed
- Value data: 1
- Registry key:
Identification and Remediation:
To identify devices that have not completed the WUfB scan, a registry key check was implemented at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\OOBECompleteTimestamp. Devices lacking this key indicate a pending user sign-in and incomplete OOBE.
When the device complete the OOBE process, there will be a registry key created at registry location Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\OOBECompleteTimestamp
Using this logic, A remediation script (Remediation - WUfB initial Scan.zip) was created and uploaded to GitHub for Intune deployment. The script uses the logic described above to address the delayed WUfB scan specifically targeting AVD devices.
Is it safe method to go? I haven't seen any issues with this because,
- The scan will only be triggered when user OOBE is not done.
- Once the scan had run it will set registry ScanBeforeInitialLogonCompleted to 1 and it would not trigger scan again.
Conclusion:
While this method provides a temporary workaround, i am hoping that Microsoft will address and resolve this issue for AVD devices, similar to the seamless process seen in Windows 365.
Test the solution on test machines before deploying them to production devices, ensuring a smooth transition and update experience for AVD deployments managed through Microsoft Intune.
Reference