Windows Autopilot

Windows Autopilot device registration options for partners: Using the tuple

As I discussed in a previous blog, CSP partners (who could be distributors, resellers, or service providers) are able to register devices for Windows Autopilot on behalf of customers using Partner Center, either interactively (upload a CSV file) or via the available APIs.  What I stressed in that blog is that there are multiple ways that devices can be identified:

Let me describe each of those fields:

  • HardwareHash:  The 4K string retrieved from a running Windows 10 OS on the device.  Customers use this value to register existing devices.  Partners would only have this value if they get it from the OEM (and booting up the device to get this, then putting the device back in the box is an absolute last resort – not only is it expensive, but it can cause problems for the customer later on).
  • ProductKey:  This is the Windows product ID, a.k.a. PKID, a 13-digit number that corresponds to the Windows product key that was inserted into the firmware of the device at manufacturing time (using OAv3).  Because OEMs are starting to put this value on the box itself, as a bar code, this can be useful: scan it from the box without needing to open the box.
  • SerialNumber:  This is the (supposedly unique) value assigned by the OEM to each device they manufacturer.
  • OemManufacturerName:  This is the value specified by the OEM in the SMBIOS firmware of the device, e.g. “Microsoft Corporation” or “LENOVO.”  (More on that later.)
  • ModelName:  This is the value specified by the OEM in the SMBIOS firmware of the device for the particular model, e.g. “Surface Pro 7.”

If you look at the format of the Partner Center CSV file, that effectively means that some of the fields are optional.  This is what the header looks like:

Device serial number,Windows product ID,Hardware hash,Manufacturer name,Device model

So looking at those columns in a table form, these are the valid combinations of fields:

Device serial numberWindows product IDHardware hashManufacturer nameDevice model
YesYes
YesYes
YesYesYes
Yes
Yes
YesYesYes

Interestingly, because Intune will only be able to show the serial number if it is populated in the CSV file (it won’t extract it from the hardware hash), and since providing some of these values with the hardware hash is a bit redundant (the hash by itself would always be enough) or problematic (e.g. getting the Windows Product ID from a running device), you can simplify this to three reasonable options:

Device serial numberWindows product IDHardware hashManufacturer nameDevice model
YesYes
YesYes
YesYesYes

Translating that into CSVs, each of the examples below would be valid (replacing the X’s with real values).  First, with a serial number and Windows Product ID:

Device serial number,Windows product ID,Hardware hash,Manufacturer name,Device model
X,X,,,

Next, with a serial number and hardware hash:

Device serial number,Windows product ID,Hardware hash,Manufacturer name,Device model
X,,X,,

And finally, with the serial number, manufacturer name, and device model:

Device serial number,Windows product ID,Hardware hash,Manufacturer name,Device model
X,,,X,X

For this particular blog, I want to focus a little more on that last example, which is what we call the “tuple” – three pieces of information that can be used to register the device.  Often, the serial number of the device will be known, either because it is on the box (often as a bar code) or provided electronically as part of the ordering process.  So, if you wanted to register the device (and you didn’t have the PKID value), you would then just need the other two values, the manufacturer name and the model.

But that’s where things can get interesting.  The OEMs aren’t always consistent with those values, and the values that you use to register the device need to exactly match (case-sensitive) the values that were present when the device was manufactured and the information about the device was reported to Microsoft as part of the computer build report (again, a standard part of OAv3).

So how do you find the values for those “Manufacturer name” and “Device model” columns?  Well, you could boot one device and get them from WMI (Shift-F10, start PowerShell.exe, run “gwmi Win32_BIOS” and “gwmi Win32_Baseboard”) and use that same value for every device of that model (just changing the serial number).  Or you could assume a level of consistency and guess…

That last option doesn’t sound too bad when you look at the data.  For example, here are the values for the major commercial Surface devices that we’ve shipped (and one entry for all the Hyper-V VMs):

Manufacturer name    Device model
Microsoft Corporation    Surface 3
Microsoft Corporation    Surface Book
Microsoft Corporation    Surface Book 2
Microsoft Corporation    Surface Go
Microsoft Corporation    Surface Laptop
Microsoft Corporation    Surface Laptop 2
Microsoft Corporation    Surface Laptop 3
Microsoft Corporation    Surface Pro
Microsoft Corporation    Surface Pro 2
Microsoft Corporation    Surface Pro 3
Microsoft Corporation    Surface Pro 4
Microsoft Corporation    Surface Pro 6
Microsoft Corporation    Surface Pro 7
Microsoft Corporation    Surface Pro X
Microsoft Corporation    Surface Studio
Microsoft Corporation    Surface Studio 2
Microsoft Corporation    Virtual Machine

If you look at devices from other OEMs, they are also pretty consistent.  For example, Dell always uses “Dell Inc.”  Some examples:

Dell Inc.    Latitude 7400
Dell Inc.    Latitude 5400
Dell Inc.    OptiPlex 3060

HP can get a little more interesting, with most new models just using “HP”:

HP    HP EliteBook 840 G5
HP    HP ProBook x360 11 G3 EE
HP    HP ProBook 440 G5

But older models may use “Hewlett-Packard”:

Hewlett-Packard    HP EliteBook 840 G1
Hewlett-Packard    HP EliteBook 745 G2
Hewlett-Packard    HP ProDesk 600 G1 SFF

Lenovo will always use “LENOVO” (upper case), but its models are more interesting as they can include a configuration identifier (with the first four characters typically being model-specific and the remaining identifying a particular configuration):

LENOVO    20L6S29E1T
LENOVO    81FY
LENOVO    20LNS04F00

Other OEMs are also pretty consistent.  Here’s a sampling:

Acer    Swift SF514-53T
Alienware    Alienware 13 R3
Apple Inc.    MacBookAir8,2
ASUS    All Series
ASUSTeK COMPUTER INC.    ZenBook UX461FA_UX461FA
FUJITSU    LIFEBOOK T938
GETAC    F110G4
HUAWEI    MACH-WX9
Panasonic Corporation    FZG1-4
SAMSUNG ELECTRONICS CO., LTD.    Galaxy Book2
TOSHIBA    dynabook R634/L
VAIO Corporation    VJPA11C11N

The only one that gets a little more interesting is for Intel NUCs, with newer models using “Intel(R) Client Systems” while older ones may be “Intel Corporation” or just “Intel.”

So, you certainly can build a CSV file with the needed tuple information once you know (or figure out) the right manufacturer and model details.  If that sounds like too much trouble, then fall back to the serial number and Windows product ID.  If the OEM can provide you with the hardware hash, that works too, but avoid capturing the hash yourself.

Categories: Windows Autopilot

3 replies »

  1. Using the make, model and serial, What would happen if a typo was made in the serial number in someone else’s tenant and your device was registering under theirs?

    Liked by 1 person

Leave a Reply to kencooperx (@kencooperx1) Cancel reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s