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:
- HardwareHash + ProductKey.
- HardwareHash + SerialNumber.
- HardwareHash + ProductKey + SerialNumber.
- HardwareHash only.
- ProductKey only.
- SerialNumber + OemManufacturerName + ModelName.
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 Number | Windows Product ID | Hardware Hash | Manufacturer name | Device model |
Yes | Yes | |||
Yes | Yes | |||
Yes | Yes | Yes | ||
Yes | ||||
Yes | ||||
Yes | Yes | Yes |
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 Number | Windows Product ID | Hardware Hash | Manufacturer name | Device model |
Yes | Yes | |||
Yes | Yes | |||
Yes | Yes | Yes |
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
Presumably this type of device profile would not work with a self-deploying profile, correct?
LikeLike
How a device is registered has no impact on the deployment method. Self-deploying (and all other scenarios) would work fine.
LikeLike
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?
LikeLiked by 1 person