Fixing Windows Update installation errors and why enabling Windows Telemetry is a good idea.

-

While attempting to upgrade my Surface device to 25H2 in my tenant, I constantly encountered issues. The error in the default Windows Update report was not really helpful.

The error just indicated that the installation was being cancelled by the user and that it needed attention. Which is quite bizarre, because I had the device kept switched on and connected to the internet for a long period of time so the error didn't make sense to me. I started investigating this and realized that I needed more information to get to the bottom of the error. That is when I realized that I hadn't configured the collection of the Windows diagnostic or telemetry data correctly. While this is not a necessity, nonetheless highly recommended. Here is why..

Windows telemetry helps in improving security and compatibility, identifying and troubleshooting issues, monitoring device performance and reliability through collection of specific data points. These are classified across -

Service-based data from Windows Update which typically includes events like alerts for a device that cannot register with Windows update. This data normally arrives in less than an hour after an event happens in the service.

Client-based data from Intune devices that are configured to send data to Intune – This data contains additional insights from the device across various installation steps. The data is typically processed in batches and refreshes every eight hours. At the time of writing this blog post, following are the alert messages that are currently available.

Source: Microsoft

For the Windows telemetry to be collected correctly against the devices managed using Intune, here are the steps that need to be carried out -

2. Go to Tenant administration > Connectors & tokens > Windows Data, and switch toggle 'On' for Enable feature that require Windows diagnostic data in process configuration.


3. Next step is to enable diagnostic collection on the Windows endpoints. Go to Devices > Configuration > Create > New Policy.
4. Select Platform as Windows 10 and later.
5. Select Profile type as Settings catalog.
6. Give a name and configure the following settings -


7. Assign to a group of relevant devices or users.

Once the policy applies, it can take some time for telemetry data to be collected and presented in reports. On my tenant it took any where from 12-24 hours. Once the telemetry data was processed, I got visibility into additional insights through alerts against Windows update for business reports.

Device monitor > Feature update failures report suggested that there was insufficient update connectivity.


This was also collaborated with the data in the Windows Update for Business workbook in Azure.



Suddenly things started to make sense. The power profile on my surface device was putting the device in sleep mode and all I had to do was to change it to ensure it stays power on for longer duration.



In conclusion, with device management workloads moving to cloud and while the configuration may seem simple and straight forward, it is still very easy to miss some of the important configuration elements that when configured correctly, can make a world of difference. Some of these settings are not flagged necessarily in the relevant places and therefore it is super important to stay on top of things. Which is why I try to capture through my blog posts that are more often than usual based on my experiences, both personal and from the field. Hope this blog post helps and possibly save you some time. Until next time.. 

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more

Removing OEM configured bookmarks from Edge

-
Image
I believe most will agree when I say that OEM branded configuration on Windows devices can be both unwanted and frustrating to remove. Especially when you provisioning devices using Autopilot and want to apply organization's configuration policies. I recently encountered an issue with Lenovo Windows 11 devices that came pre-installed and configured with things that the customer didn't want. While the procurement process gets worked out with the supplier to provide a clean image, I still needed to address these unwanted items. One of the items were pre-configured Edge bookmarks that had no place in the bookmarks that I was putting in place. It was obvious that they had to go.  The bookmarks are located under  C:\Users\<Userprofile>\AppData\Local\Microsoft\Edge\User Data\Default If you open it then you can match contents with what shows up in the favorites on Edge. Solution I created a simple 1 line script to delete the Bookmarks file as part of the Autopilot provisioning ...
Read more