This blog will focus on a recent Windows Autopilot change that was (not) announced: the Autopilot Hardware Hash Remediation change and how it seems to be getting “ditched” .
Introduction to Autopilot Hardware Hash Remediation
In one of my previous blogs, I explored Microsoft’s introduction of the Autopilot Hardware Hash Remediation feature, which has the potential to greatly benefit many customers. This feature is handy when a Windows device undergoes a significant hardware change, such as replacing a motherboard. When the desktop motherboard is replaced, the Autopilot Hardware Hash Remediation feature automatically updates the device’s hardware hash on the service side, ensuring that the device remains appropriately associated with the Tenant.
When a hardware change is detected, a scheduled task initiates the process by updating the hash, allowing the device to continue functioning seamlessly within the Autopilot deployment process. If the Intune service detects an issue, the Intune portal displays a “Fix Pending” message, indicating that the remediation process is in progress. This proactive approach simplifies the management of hardware changes and helps maintain consistency across your device fleet. At least, that was the whole idea behind it when this feature was introduced some time ago.
Autopilot Profile Status
After clicking on the Fix Pending message, it would show us that “A hardware change was detected on this device. The message would tell you that they were working on it to register the new Hardware.
The DetectHardwareChange scheduled task is central to this process. It creates a snapshot of the device’s hardware specifications and stores data in the registry and disk. This includes essential files like cachedhash.txt and cachedtpmekpub.txt in the wmansvc folder. When a hardware change is detected, this task updates the registry and generates new files, triggering a report to the Autopilot service at ztd.dds.microsoft.com.
Furthermore, the process relies on the Windows Notification Facility (WNF). This automatically detects hardware events and subsequently triggers updates. As a result, hardware changes are promptly detected and reported, maintaining the device’s configuration integrity.
Moreover, the remediation process provides significant benefits. It automates hardware change detection and updates, thus reducing the need for manual intervention and streamlining device management. Despite potential delays, this system is intended to offer a robust solution for managing hardware changes in Autopilot devices. But somehow, things changed?
Hash Remediation Recent Changes
On my birthday, Microsoft posted a small “What’s new in Windows Autopilot” announcement on Microsoft Learn.
In the announcement above, Microsoft mentions that devices are no longer re-enrolled after a motherboard change. Furthermore, Microsoft seems to be moving away from hardware hash remediation, as they decided to strike through this text when they first announced it.
Initially, when we removed the strikethrough, it stated:
“Automatically re-enroll devices where hardware components (motherboard for example)may have been replaced with Autopilot auto-remediation if the OS has not been reset.”
This is consistent with what Microsoft mentioned in “What’s new in Windows Autopilot.” Moreover, this change aims to prevent issues arising from unnecessary re-enrollment of devices after hardware changes, particularly motherboard replacements.
I guess it’s pretty obvious that this Hash remediation service is done for.
Did Microsoft change anything in the code?
When I look at a previous Autopilot.dll and compare it with the one from this year and June, I can’t spot any real differences. The code to remediate the hardware hash is still in Windows and tries to detect if a hardware change occurred.
So, I decided to test it out by moving a virtual hard disk from one VM to another. After the device booted up, the Autopilot Hash Remediation kicked in and mentioned that a change was detected and reported.
Nothing showed up when switching to the Intune portal and watching for the ” hardware change detected” notification. At first, I had the idea that Microsoft “Killed” the feature on the client side, but it seems Microsoft disabled the hardware hash remediation service on their side.
Why did Microsoft ditch this hash feature?
Why did Microsoft ditch this Autopilot Hash Remediation feature? I guess that Microsoft ran into a lot of issues with this feature. One of those issues was that vendors needed to beware of the Autopilot Marker with BIOS updates. This blog highlights how Lenovo BIOS updates can erase the Autopilot Marker, leading to hardware hash recognition issues.
This could be the first reason Microsoft decided to “kill” the Autopilot Hardware Hash remediation feature.
Another excellent reason why the Hardware Hash remediation was ditched could be the announcement of Autopilot Device Preparation. With Autopilot Device Preparation, we no longer need the hardware hash. Without the hardware hash requirement, there is also absolutely no reason why we need Hardware Hash remediation.
But still… I am pretty much wondering if there could be a third reason why this feature was ditched… Maybe we will hear more about it, maybe we won’t.
Conclusion
In my opinion, Microsoft decided to ditch the Hardware Hash remediation feature because it was causing more problems than helping to resolve hardware hash issues when a device got a motherboard replacement. I guess with this feature being shutdown, we are no longer going to experience the weird ” fix pending” issue!.. Well, that’s nice 🙂