The School for Autopilot and DeviceAddRequest

In this blog, I will focus a bit more on what Windows Autopilot is and what it is built upon. To explain the building blocks of Windows Autopilot, we need to take a closer look at the Windows Autopilot DeviceAddRequest command, which the device performs in the background when it is turned on.

1. Introduction

After I was done with my previous blogs, in which I explained how you could determine if the device is capable of fetching the Autopilot profile and how the OfflineDeviceId was used, I decided to take a closer look at the first step in the whole process.

So, I will advise you to read the blog below to understand the complete flow better.

https://call4cloud.nl/2022/12/autopilot-x-device-token-profile/

In this blog, I am going to focus a bit more on the DeviceAddRequest and where it originates from

2. DeviceAddRequest

As I mentioned in the blog post in part 1, the device first contacts login.live.com to perform the Device Authentication.

This Device Authentication will be performed by executing the DeviceAddRequest operation.

Looking at the screenshot above, you will probably wonder about the member’s name and password. To get an answer to that question, we need to focus on login.live.com and LiveIDs a bit more. When we need to know what is going on with Windows Live IDs/Microsoft Accounts, we need to start looking at the corresponding DLL file: WLIDSVC.dll (Windows Live ID Service/ Microsoft Account Sign-In Assistant service)

Looking at the wlidsvc.dll code, it pretty much looks like it was generated randomly

I almost forgot to mention that this DeviceAddRequest is also logged in the LiveID event log. As shown below, it showed me the exact same request. So we are again stuck with the good old Live ID!

When scrolling through that same WLIDSVC.DLL, we will notice that the DeviceAddRequest is mentioned a lot in the AddCredentialRequest wlidsvc.dll function…

I started searching for keywords like “DeviceInfo” in that DLL file. That search showed me how the SOAP request was built until something funny caught my eye.

The function name itself!!!! It mentions the name UpdateDeviceLicenseRequest. Again, the word License is in it and is responsible for DeviceAddRequest. Whoop, Whoop. I guess I need to mention it again: UpdateDeviceLicenseRequest.

Take one guess, from which DLL this “LicenseRequest” function is being imported? As Shown below… CLIPC!

Every time that same word is mentioned! License, License, License, License!!! Maybe that’s why we also got license information in the SOAP response?

Even Procmon showed me the same behavior when the device first connected to the Internet. ClipSvc is being mentioned a lot—and I mean a lot!

It almost can’t be a coincidence that I stumbled upon clipsvc.dll when trying to decode the OfflineDeviceID in this blog below!

Digging into the HardwareHash and the OfflineDeviceID (call4cloud.nl)

Besides the Procmon trace, at the exact same moment, the SOAP request is performed, we will notice that the ClipSVC is being started

Mmmm, ClipSVC, and again the Wlidsvc being mentioned… that rings a bell or two… Looking back at one of my earlier blogs. Windows Pro doesn’t upgrade to Enterprise with E5 license (call4cloud.nl) we will also notice the mention of the Wlidsvc and the wonderful MSA ticket in it

Let me ask you a question, did you read the part about license authentication?? Did you?

3. Windows License Activation

I guess we need to do some assuming now and start combining the “Windows License Activation” information from my own blog with the word “Autopilot”. When we do we will end up with this Microsoft article mentioning the Windows Activation Services as a hard network requirement when using Windows Autopilot

As mentioned above, Windows Autopilot “Requires” Windows Activation Services. This is what we get when using some GoogleFu ChatGPT functionality on it.

“The Windows Activation Process (WAP) will let your device generate a unique ID. That unique ID is based on its configuration. Windows will send a summary of the hardware you have installed in combination with the Windows Product Key (PKID) to the Microsoft Service. The Microsoft service will link those two in their database. This ties your particular license key to your PC, ensuring that any attempt to use that license to activate Windows on another machine will fail”

Let’s combine the information from above, with some screenshots below…..

+1 One good old Windows XP Genuine Microsoft Software Notification

With those two screenshots in the back of our minds, let’s take a look at the good old days when Windows XP needed to activate itself to become genuine

4. The good Old XP Days

In the good old XP days, when you were installing Windows XP. we also needed to perform Product Activation. This product activation could be done by using the Internet !!! WOWWW!..

To activate Windows XP, the device needs to hand over the Installation ID to Microsoft. This “Installation ID” was based upon the Hardware Hash (sounds familiar right?) and the Product ID. Let’s start with the Hardware Hash. The HH was calculated during the installation of Windows XP. This Hardware Hash was based on some components

Once you needed to perform product activation, this data (Hardware Hash) and the Product ID needed to be sent to the Microsoft Activation servers in binary format over a secure SSL connection. This activation should happen without any issue as long as you didn’t exceed the maximum number of allowed “Hardware” changes. Mmmm that does ring a bell or two doesn’t it?

*When there is a significant hardware change you couldn’t activate Windows XP.

*When there is a significant hardware change, Autopilot doesn’t work.

Conclusion

Troubleshooting Windows Autopilot is always fun, but it’s much better to understand the process It is built upon.

Windows Autopilot relies on the good old Windows Activation Process (Windows Xp Genuine Hardware) for its Hardware information. There you have it!! Boom!!!