Reenrol devices without wipe

Enrolled Intune devices occasionally face trust issues due to MDM or Microsoft Azure certificate problems, among other factors. While wiping and re-enrolling is a standard fix, it’s straightforward for regular devices, with minimal data loss thanks to services like OneDrive. However, this process is more complex for specialized field devices, particularly those with custom configurations and vendor-installed software, especially if the vendor not longer exists. Creative strategies are essential in these cases. This blog post delves into an experimental approach to seamlessly bring such devices back under management.

Important note before you start

This process is an experimental process and should not consider as Standard. It is not guarantied that this will always work and it is outside of the support.

Scope

This procedure is designed to address various issues related to MDM and Microsoft Azure certificates that are otherwise challenging to troubleshoot. These issues may include, but are not limited to:

Missing or corrupted MS-Organization-Access certificates.
Missing or corrupted PK key files.
Persistent, unusual authentication failures in IME, winget, or MSStore, unresponsive to standard troubleshooting methods.

The method involves an undocumented shortcut in the CEH, utilizing a function call in dsreg.dll. This approach differs in user experience and outcomes under varying system conditions. It’s a streamlined adaptation of the original manual device reintegration process, carrying similar risks to the previously high-risk method. It’s also considered as a ‘last resort’ option.

A significant update in this process is its simplified execution, especially beneficial when remotely accessing devices in the field.

Prerequisites

The prerequisites for this process are:

Physical or remote access to the device
Access to an account with local administrative rights
Imported device hash
User with user credentials including 2^nd factor

Concept

This process enables client-side triggered re-enrollment without disrupting an active Entra ID user session. It involves self-destruction of the existing MDM profile and re-creation of the Intune identity of the device, along with the re-enrollment of all relevant certificates (MDM, MSOrga).

Regions of Interest: Look for signs of inconsistent states in the following areas:

Accounts > Access Work or School
Accounts > Access Work or School > Info > Device sync status
Windows Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentID} and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin

Output of Dsregcmd.exe /status

Certificate Manager (Certlm.msc)

Entra ID and User Device Registration Event logs

Procces

Run START+R and run “ms-cxh://NTH/AADRECOVERY” or execute PowerShell and run “start-process ms-cxh://NTH/AADRECOVERY” in AAD user context

What follows is a windowed version of the CEH. Here you have to enter your credentials analog to the WHfB enrollment.

Now you get the loading window that your device will be setuped

If you have not local admin permissions it could be that an UAC prompt will be spawned in the taskbar

Finaly the re-enrollment is done. You will get the windows to setup/change WHfB. Click Finish.

While testing it never became necessary to re-enroll WHfB. However, depending on the profile state and the NGC container prior to re-enrollment, it may become necessary. My recommendation here would be to NOT enroll WHfB using this screen, instead, the WHfB enrollment should be done after reboot by the user if prompted for through policy evaluation.

Post Steps

The EnrollmentID has now changed.

What we have to do prevent that the user get into the ESP of the Autopilot user flow after reboot. To do this we have to switch to the FirstSync key under the EnrollmentID.