Autopilot Profile causes Device Rename after ConfigMgr OSD Task Sequence and Breaks AD Domain Trust

We got some new hardware models in this week and added drivers to our ConfigMgr OSD Task Sequence (with Windows 10 1909 serviced with November 2020 updates) to test. One of the devices kept ending up with a broken domain trust relationship when you attempt to log in immediately following build completion.

The security database on the server does not have a computer account for this workstation trust relationship

One clue that we had was that something was renaming the device. We have a very basic naming convention SITE-SERIAL where SITE is 2-5 character code for the AD site/OU a device will be assigned to. The device was be in Active Directory in the right OU and properly domain joined, but at the logon screen in the username field if we typed .\ to show the device name instead of the domain name, the device name was only the SERIAL, no SITE- prefix. The smsts.log, setupact.log, unattend.xml all showed the correct device name through the entire process. Here’s the rest of the story…

Note – the serial in the screenshots doesn’t match the logs due to obfuscation of prod data

Trudging Through Logs

Like most people, I love (or is is loathe) digging through logs looking for a needle in a haystack. In this case, I needed to find evidence that showed that the device was properly named, but then was changed sometime later. I knew that it was named correctly at least until the domain join step and after digging through smsts.log, it was clear that it wasn’t being changed during or by the Task Sequence at all. It was coming afterwards. I moved to the Event Viewer and started looking for Event ID 6011 which would show that the device name had been changed and the device had been rebooted.

Once I had the base timestamp to work from, I was able to narrow my search to a specific time that this could have happened. I scrolled back in time and and found Event ID 1074 which showed that the reboot was triggered by CloudExperienceHost.

When I looked at C:\Windows\Panther\UnattendGC\setupact.log I noticed that CloudExperienceHost had failed and created a memory dump around the same time the device rename and matched up with the timestamp on the restart event.

For no real reason, I decided to check if the machine was getting an Autopilot profile. The Event Viewer showed that the device had gotten an Autopilot json file, which seemed odd since this device shouldn’t have had a profile assigned yet. I opened C:\Windows\ServiceState\Autopilot and found AutopilotDDSZTDFile.json. In here, I found the smoking gun!

Making Sense of Things

As you may know, you can only assign custom naming to Azure AD Joined devices, not Hybrid, during Autopilot. How could this be happening during OSD?

During OSD, the device is installing Windows then apps and settings and is locked out until it’s done. Once it is finished, it will reboot and is supposed to skip OOBE and go to the logon screen.

We recently removed our custom Unattend.XML file from our TS since we were specifically using it to suppress OOBE post OSD using some now deprecated settings (SkipUserOOBE & SkipMachineOOBE) that still work.

Network OOBE Screen

So it appears in the brief moment where OOBE is being shown, the device is contacting the Autopilot service and pulling down an assigned Autopilot profile.

Finding a Workaround

This next section describes the troubleshooting process that I used to validate the source of the issue.

Option 1 (supported)

The “supported” solution to this problem would be to NOT assign Autopilot profiles (specifically ones with naming templates configured) to devices that you are NOT Autopiloting. This is the cleanest option and doesn’t require adding in deprecated configurations to your unattend.xml. This SHOULDN’T be happening, but as Michael Niehaus pointed out to me after reading this post, he tried for 2 years to get this fixed and ultimately, just don’t do it (assign an Autopilot profile to a non-Autopilot device) that way.

Option 2 (unsupported)

To test my theory about OOBE, I added unattend.XML back to the Task Sequence and built the machine. The device didn’t pull down the Autopilot profile and didn’t get renamed. I then removed the deprecated lines from the unattend.xml file and built the machine again. This time it failed the same as before, confirming my suspicion.

This is my default unattend.xml.

Apply Operating System with unattend.xml

Here’s the unattend.xml after the Task Sequence Apply steps have completed just before the Setup Windows and ConfigMgr step.

As you can see on lines 6 & 7 above SkipUserOOBE and SkipMachineOOBE are included in the XML and make the issue go away.

Wrapping it all up

This was a weird one for sure and this feels like a bug. The workarounds are simple enough that this isn’t a show stopped, but trying to find the source of the bug was definitely a head scratcher. I haven’t had time to test with any other OS versions or even non-serviced versions yet but would be interested to see if they suffer the same issues. I seem to recall that the OOBE issues that required the custom unattend.xml only showed up on offline serviced or captured images, but not on OEM media.

P.S.

You may be asking yourself why I was doing OSD when I had AutoPilot assigned for AAD Join. Well, the device we were testing was a demo unit that had been registered to another company’s tenant and had THEIR Autopilot profile assigned. I had no way of deleting the device or unassigning the profile. The vendor has since resolved the issue, but it helped highlight a deficiency in their process as well, so win-win I guess.

Also, I was unable to find any Autopilot logs that actually show the device rename being triggered which also bugs me…

2 Comments

  • Reply
    Saravanan
    December 2, 2020 at 7:33 pm

    Might be meant for some other company and your hardware vendor uploaded autopilot details….. is the autopilot tenant in json belongs to your company

    • Reply
      Adam Gross
      December 2, 2020 at 7:41 pm

      No. The device was mistakenly registered to another tenant and pulled down a json file from that company – not mine. The vendor fixed the issue and removed the device from the other company’s tenant.

      Also worth noting, I was able to repro the issue by assigning profiles to test machines in my tenant and the same issue occurred on all 3 repeatedly.

    Comment

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    1,021

    Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): Guzzle in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113