Before we begin, here are some notes about persistent and non-persistent VDI that will likely give you nightmares:
- Intune doesn’t support non-persistent VDI
- Azure Active Directory only supports Hybrid Azure AD Join for non-persistent VDI
- ConfigMgr recommends limiting client functionality on non-persistent VDI but there is no mention about the impact of Co-Management on these devices.
- Whatever you do, don’t Hybrid Join then Co-Manage your VDI Master Image or you’re in for a bad time!!
| |
What have we done??
Today’s problem was discovered when our VDI master images were built and updated using ConfigMgr in an environment where Hybrid Azure AD Join and Co-Management is enabled for all devices (which automatically Intune Enrolls devices). When the master image is cloned to create new worker VMs (persistent or non-persistent), the new VMs all share the same Azure AD and Intune device IDs. Within Azure and Intune, if you search for a specific Device by ID a single device record is returned which changes randomly depending on which device checked in last.
We now run the script linked below along with BISF scripts and many other custom steps to clean up the master image and we disable the ConfigMgr client so that it doesn’t launch on the non-persistent devices, which prevents Co-Management from kicking in and re-enrolling into Intune. For persistent VDI cloned from master images, we re-enable ConfigMgr and manage the devices as regular worksations.
Take the Good with the Bad
If you have ever used a device which has not been Hybrid Azure AD joined to access any Microsoft cloud resources, you’ve likely been prompted numerous times to enter your Azure AD credentials. This can be overcome by hybrid joining your device to Azure AD. This has a huge user experience benefit but when used on cloned devices can really cause some issues. If you want the device to be Hybrid Azure AD Joined, then you will need to prepare your master image properly before cloning.
Take your Pick
The best part about this issue when using ConfigMgr is that it’s super easy to find devices with duplicate Azure AD Device IDs. The quickest way is to add the Azure Active Directory Device ID column to the ConfigMgr console. You can even group by the column to make is easier to find devices sharing the same ID.
Another alternative is to create a collection to help quickly determine how many devices are using duplicate IDs. I’ve uploaded a MOF file to my repo that you can import to create a new collection. Duplicate Azure AD Device ID.MOF
Too Much of a Good Thing
While searching for a solution to this problem, I frequently ran across solutions for handling Azure AD and ConfigMgr but nothing much related to Intune and Co-Management. When Co-Management is enabled, the Enablement tab has an option for Automatic enrollment in Intune which can target a pilot collection or all devices.
Unfortunately, All means just that. The moment a device is (Hybrid) Azure AD Joined it will trigger the Co-Management handler service which immediately triggers the Intune enrollment process for the device. You can watch CoManagementHandler.log on a client to see this in action.
Co-Management isn’t great on a master image.
If We Could Turn Back Time
Once a master image has been enrolled in Intune, you can’t just use DSREGCMD /LEAVE in the cleanup script before re-sealing it - each clone will still think that it is Intune enrolled and it will continue to re-register in Azure AD with the same device ID as the master.
The first step here is going to be un-enrolling the device from Intune. Unfortunately, that’s not really a feature that exists natively so we have to cleanup the client so that it no longer thinks that it’s enrolled in Intune so that we can disjoin and rejoin Azure AD.
Un-Enrolling - Just like Enrolling, only Backwards
To reverse the process, we need to delete everything listed below.
Scheduled Tasks
- Task Scheduler Library > Microsoft > Windows > EnterpriseMgmt
- New GUID folder created. This is the key to the rest of the puzzle.
Registry Keys
- Several keys get created, but only these need to be deleted
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\Status<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Logger<ScheduledTaskGUID>
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions<ScheduledTaskGUID>
Certificates
- 2 certificates will be created. One for Azure and one for MDM. Delete both.
- Note that the GUID in Issued To for the certs will match the Intune and Azure AD Device IDs
- Issued By Microsoft Intune MDM Device CA
- Issued By MS-Organization-Access
- Issued By MS-Organization-P2P-Access
Once you delete all of the items listed above, you can safely disjoin from Azure AD using DSREGCMD /LEAVE. But wait, there’s an easier way!
One Script to UnEnroll them All
Ok so I took you through all of the manual goodness because, just like GI JOE always says “Knowing is half the battle!”. The other half is hoping you don’t run out of broken VMs to test the script on before you get it working!
The script is written to be run in ConfigMgr. Instead of posting the script content here, I’m just going to link my repo so that any changes are updated there. Check out the comments in the code for more details and for updates.
If you continue to have issues with re-joining, you may need to delete the AAD, Intune and Autopilot device objects from your tentant then wait for Azure AD Connect to re-sync.
Note - This has only been tested for Hybrid Azure AD Joined Devices. https://github.com/AdamGrossTX/Toolbox/blob/master/Intune/Intune-UnHybridJoin.ps1
Parting Thoughts
One question comment I’m sure I’ll get is around Co-Management and using pilot collections instead of deploying to all devices. One major reason not to leave Co-Management in pilot mode is because it targets a collection. That collection will need to be populated and updated when a new device is built and that takes time. Targeting all devices allows a device to immediately become Co-Managed as soon as the client pulls down policies. That seems like a better experience than using pilot to work around this.