Skip to content

February 15, 2017

Windows Sysprepped Machine Fails to Automatically Register with Azure

Beginning with Windows 10 1511, Windows based computers will attempt to automatically register with Azure Active Directory. For this to succeed some configuration is required (I won’t go into this detail, but you can find official steps here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup).

I found that even when following these steps, the DRS process still wasn’t working for me. To diagnostic this, you can look at the Windows Event Log at: Application and Services\Microsoft\Windows\User Device Registration\Admin. In my logs was this error: Automatic registration failed at join phase.  Exit code: Keyset does not exist. Server error: empty.
Note: You can also diagnose this by running a command prompt as SYSTEM account (use psexec -i -s cmd.exe) and running dsregcmd /debug and dsregcmd /status.

During troubleshooting, we found that any machine that had a TPM or a machine that was built directly off the Windows 10 ISO worked. Any machine that was a VM (or physical with no TPM), that was imaged using SCCM failed with the above error.

After some great support from the MS product team, we discovered the reason for this error. When there is no TPM present, Crypto files are stored here: C:\ProgramData\Microsoft\Crypto\Keys. There is a special key that is used by Azure DRS, it always begins with: f9890073e78468741a6bc490ab388f59_<unique GUID here>. What we discovered is that there is an issue with the sysprep process not clearing these crypto keys like it is supposed to, and this causes Azure DRS to fail.

Fortunately, until MS is able to fix the sysprep bug, the fix/workaround is fairly simple. Simply delete the Crypto key that begins with “f9890073e78468741a6bc490ab388f59“. Once deleted, the next time Azure DRS runs, a new key file will be created (as well as others) and DRS will succeed.
Note: To force DRS, you can simply log out and log back in and wait 1 minute, or you can run the Automatic-Device-Join scheduled task in the Workplace join folder, or you can use a SYSTEM command prompt to run dsregcmd /join.
Note 2: In order for user state DRS to complete, machine DRS must first be completed; then the machine must be locked and unlocked at least once to trigger user DRS with Azure.
Note 3: You can validate this from a regular user command prompt and running dsregcmd /status. For machine registration, look for AzureAdJoined set to Yes. For user registration look for WamDefaultSet set to Yes and AzureAdPrt set to Yes. If all this is true, then Azure DRS should be completed successfully.

In my case, I had several images and hundreds of machines affected by this issue. To fix , I first repaired my images. This can be done by using dism tool to mount the image, delete the bad Crypto file, then commit changes to the WIM. Details steps can be found here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/mount-and-modify-a-windows-image-using-dism.  Secondly, to fix my existing machines, I used a simple PowerShell script, that I executed with SCCM, to find the bad key file and delete it. Here is the script for your convenience. (Note: The date check in the script is used to protect from deleting good keys from working machines. I matched the date time to the bad keys in the sysprepped image that was used to deploy these machines).

# Set Variables
$DateToCheck = Get-Date -Month 12 -Day 1 -Year 2016
Set-Location “C:\ProgramData\Microsoft\Crypto\Keys”

# Find File
$DRSCryptoFile = Get-Item * | where { $_.Name -like “f9890073e78468741a6bc490ab388f59_*” }

 # If File found and old, then remove (system will regenerate)
if (($DRSCryptoFile -ne $null) -and ($DRSCryptoFile.LastWriteTime -lt $DateToCheck))
{
    Remove-Item $DRSCryptoFile -Force -Confirm:$false
}

Note: When using SCCM to deploy, I had to use SysNative path for PowerShell for the script to run properly (needed x64 context): %systemroot%\sysnative\windowspowershell\v1.0\powershell.exe -NoProfile -File “Script.ps1”

Share your thoughts, post a comment.

(required)
(required)

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments