Recently I needed to change a couple of groupTags on existing Windows Autopilot devices. Because Windows Autopilot profiles have been assigned based on the groupTag. Of course I could have done this with the portal (check out the devicemanagement.microsoft.com portal if not done yet!) but I am definitely an automation fan when I need to do repetitive work.
Portal view and property mapping # In the Intune portal the Group Tag field on an Autopilot device maps to the Azure AD device property “OrderID”.
Dynamic Azure AD Groups to assign Autopilot profiles to devices can be built with the following membership rule:
(device.devicePhysicalIds -any _ -eq "[OrderID]:mOSD") The “Order Identifier” field on an Autopilot device maps to the Azure AD device property “PurchaseOrderId”.
Dynamic Azure AD Groups to assign Autopilot profiles to devices can be built with the following membership rule:
(device.devicePhysicalIds -any _ -eq "[PurchaseOrderId]:1234") PowerShell script to update groupTags # The following script updates the groupTag of one or multiple selected Autopilot devices. Selection is done with a PowerShell GridView.
Please note:
If you use the Enrollment Status Page (ESP) on your (Autopilot) devices in blocking mode (Block device use until all apps and profiles are installed) things can get ugly and complicated if you sign-in with another user account on that machine. So it might be better to disable the Enrollment Status Page for all users who sign-in after the initial device enrollment.
ESP behaviour # I was not aware of the fact that only one ESP gets applied to a device and the first one applied will also remain on that device nevertheless if you configure additional ESP settings for different groups of users. In addition the ESP gets displayed for every account even if the account has no Intune license assigned and causing the ESP therefore to fail.
The Enrollment Status Page can only be targeted to a user who belongs to an assigned group and the policy is set on the device at the time of enrollment for all users that use the device. https://docs.microsoft.com/en-us/intune/windows-enrollment-status
Use cases from the field # I have came past the following use cases where you would want to disable the ESP after the initial enrollment:
Recently I needed to delete a desktop machine from the Windows Autopilot service in order to use the machine in another tenant. But the problem was that the Intune and Azure AD device objects were already deleted. All attempts taken within the Microsoft 365 Device Management and Intune Portal were unsuccessful.
Issue # Usually the autopilot device shows the associated Azure AD and Intune objects but here they were shown as N/A (not available) because they were already deleted.
Every attempt to delete the device produced the following error:
Device 8CC9082ZVE deletion failed. Please delete the associated Intune device before deleting this Autopilot device record.
Solution # A quick visit to the Microsoft Store for Business resolved things because there I could delete the device without any issue. Direct URL to the Microsoft Store for Business. After a sync in the Intune Autopilot Devices pane the device had also gone from the Intune portal.
Final words # This was a rather short post but I hope it prevents headache if you want to delete an Autopilot device with stale Azure AD / Intune records.
I’m happy to share some field notes and experiences with the Windows Autopilot White Glove feature which is available with the Windows 10 1903 release. I’ve done a lot of testing and engineering for a recent project which also included this brand new feature.
First things first (requirements) # This is probably the most important information of this post. Really make sure to verify the following prerequisites for Autopilot White Glove. Because there are additional requirements compared to Autopilot enrollments.
Basic Autopilot # Make sure that a “classical” Autopilot Deployment is working properly without any issues.
Hardware and OS # Hardware with support for device Attestation (“Physical devices that support TPM 2.0 and device attestation; virtual machines are not supported.”) Physical devices with Ethernet connectivity (WiFi connectivity is not supported!) Windows 10, version 1903 with KB4505903 injected (equals OS Build 18362.267) Starting the white glove adventure # Preparing Windows 10 1903 # As mentioned by Michael Niehaus Windows multiple Autopilot issues were fixed by KB4505903. So we need to inject this cumulative update to the downloaded source. This was already the first hurdle to overcome because I’ve missed the fact that the Windows Setup (install.wim) actually contained multiple image indexes (yeah it’s kinda embarrassing). We achieve this by using dism offline servicing with PowerShell cmdlets.
While testing Autopilot White glove for a customer project my test machines always got stuck within the “Registering your device for mobile management” step and timed out after 12 minutes and returned the error “0x81036501” just before showing the White Glove Failed screen. I was doing my tests with Windows 10 1903 DE (German) with the most recent cumulative update installed, meaning OS build: 18362.267.
The Issue # As normal Autopilot enrollments were working like a charm this one had to be related to the White Glove scenario. Here’s a screen capture showing the actual behavior (unfortunately with German display language):
By pressing [shift] + [F10] i opened a command prompt and launched the event viewer (eventvwr.msc). In the “Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot” event log I found the following error popping up multiple times, including a retry attempt and limit:
Autopilot discovery failed to find a valid MDM. Confirm that the AAD tenant is properly provisioned and licensed for exactly one MDM. HRESULT = 0x81036501
AutopilotManager failed during device enrollment phase DeviceDiscovery. HRESULT = 0x81036501
On the enrollment status page the error “0x81036501” got displayed for like one second before showing the red generic Autopilot White glove error screen.