Gathering Windows AutoPilot hardware details from existing machines


As discussed in the documentation at https://docs.microsoft.com/en-us/windows/deployment/windows-10-auto-pilot, you can harvest the hardware details from existing Windows 10 devices, then upload those to AutoPilot via the Microsoft Store for Business, the Partner Center, or Intune (coming soon).  I published a PowerShell script called Get-WindowsAutoPilotInfo to the PowerShell Gallery that helps with gathering that info and formatting it into a CSV-style file that can be uploaded.

In order to gather the hardware details, the device must be running Windows 10 1703 or later and the script needs to be run with admin rights (elevated when running locally).  It can’t run on earlier versions of Windows, nor will it run in Windows PE.

It is possible to gather hardware details remotely, accessing WMI over the network, but the remote machine still needs to be running Windows 10 1703 or later.  With the most recent script update published last week, you can optionally provide credentials for connecting to the remote machine (not supported for the local machine); just add the “-Credential” parameter (along with the -ComputerName parameter) and specify either a PSCredential object or a user ID (which would result in prompting for the password).

If you are trying to gather the hardware details remotely, you will need to make sure that the Windows Firewall enables access to WMI.  To do that, open the “Windows Defender Firewall” control panel and click on “Allow an app or feature through Windows Defender Firewall.”  Find “Windows Management Instrumentation (WMI)” in the list and enable for both Private and Public, then click OK:

clip_image001

Or you can do the same thing via Group Policy – nothing special about what the script is doing, it just needs remote WMI access to the classes that contain the details.  The script should also accept a piped-in list of computer names, so you could grab them from AD or ConfigMgr and do a whole batch at once.

Some have also asked if it’s possible to have ConfigMgr inventory these details.  Due to the length of the hardware hash (4KB), that doesn’t work.  You could use ConfigMgr to run the PowerShell script on each machine, then collect the resulting CSV files.


Comments (6)
  1. Stefan says:

    Hi Michael, how does this work when a motherboard has been replaced for a notebook ?
    As the hardware details change, my guess is that the hash changes as well.
    All of our users are remote and pc’s get repaired at their offices by Lenovo. Is there a way to get the new hash in Autopilot after servicing?

    1. Yes, a motherboard swap would result in a changed hardware hash, so you would need to redefine the machine to AutoPilot. In theory Lenovo should be able to integrate that into their repair process (re-adding the machine to AutoPilot for you), but that’s more of a “future state” comment as they are still working on the integration to add newly-purchased devices now.

      1. Stefan says:

        Ok, thanks for your quick reply !
        As Lenovo knows the hardware hash before an OS installation, it should be possible to calculate it in another way, right ? (Maybe only available for OEM vendors)
        Besides that, i’ll contact my accountmanager at Lenovo to see if they can deliver hardware hashes right after they swap the MB.

        1. Lenovo doesn’t know it *before* they manufacture the device. They run a tool *during* the manufacturing process that generates the hardware hash from information about the hardware in the machine.

          1. Stefan says:

            Ok, got it.
            Would it be an *future* option to let the machine re-register itself using the MDM client after a MB swap ? (without wiping the harddrive)

          2. We’ve talked about ways that we might be able to do something, but nothing committed at this point.

Comments are closed.

Skip to main content