I’ve been playing around with Windows Autopilot recently and so I decided to do another video showing you a run through of the process involved in using this new technology from Microsoft.
There are a few pre-requisites you will need in place before you can fly with this (sorry 
)
- Microsoft Windows 10 1703 or higher
- A device with Windows 10 installed – I used a VM in this demo
- Microsoft Azure Premium (P1 or P2)
- Microsoft Intune
- Windows Store for Business
You will of course need an admin account in your Azure Portal to make the necessary configuration and an end user account which can be a simple domain user however must have an EMS/Intune licence assigned to the user with your Azure Active Directory.
A couple of link I used in the video are here:
- Paul Winstanley’s blog post via Microsoft TechNet UK – https://blogs.technet.microsoft.com/uktechnet/2017/09/26/implementing-windows-autopilot-the-future-of-device-deployment/
- Error messages for Windows AutoPilot – https://docs.microsoft.com/en-us/microsoft-store/add-profile-to-devices#autopilot-device-information-file-error-messages
- Microsoft (Michael Niehaus) link for PowerShell – https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo/1.1/DisplayScript
The PowerShell used is:
wmic bios get serialnumber
Get-ItemPropertyValue "hklm:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DefaultProductKey\" "ProductId"
$wmi = Get-WMIObject -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'" $wmi.DeviceHardwareData | Out-File "($env:COMPUTERNAME).txt"
Also, these are the manufacturers that have so far signed up to the AutoPilot scheme and should be able to provide you the necessary information to import into AutoPilot:
- Lenovo
- Panasonic
- Toshiba
- Microsoft Surface
- HP
- Fujitsu
- HP
- Dell
Click the picture to play the demo video. Enjoy!
More than patches 
Pete; my hero.
I’ve been playing with this and got everything working except I sysprep’d the device, rather than ‘reset’. This creates a new hardware id and ruins EVERYTHING.
LikeLiked by 1 person
Glad it was useful mate. Hope you’re well.
LikeLike
Ok. I give in.
I followed your video word for word. I’ve followed the blogs you mention word for word.
Everytime I boot the autopilot device, the oobe isn’t branded. What gives?
LikeLike
Do you have the company branding configured in your Azure AD? That’s the bit that where the company name etc is pulled from. Just some basic info in there is enough.
LikeLike
Believe so. the branding pulls through into the login prompts etc.
Aside from branding, it also doesn’t prevent local admin creation (which is the actual requirement), so I don’t think it’s doing autopilot at all?!
LikeLike
Ok… One final re-test and it is working with no local admin creation. Branding isn’t there but meh.
This is the darkest of the dark arts.
Thanks for the post. Keep it up :-)
LikeLike
Does the device join AAD and Intune once it’s done?
LikeLike
Yeah, but then it did that even before I considered using Autopilot.
The only issue with that method was that the user was granted local admin permission.
LikeLike
Hi,
For Windows 10 AutoPilot, I would like to ask two questions:
Q1: Will hardware hash changes if we re-install or upgrade OS or run Sysprep /generalize ?
Q2: If devices are not in OOBE state, and already reached to desktop, a local account is created, will these devices still get enrolled via Auto Pilot, or we must run the Sysprep to get OOBE?
LikeLike
Q1 – hardware hash is the same unless a major component changes in the machine.
Q2 – Once the device reaches desktop you will need to perform the reset to use AutoPilot as it is OOBE. You can enroll with MDM and Azure AD from desktop though.
LikeLike
Hi and thanks for the reply.
For Q1, is it documented somewhere ..?
For Q2, which I forgot to mention, what will happen with the installation ID, if we perform a reset? Either new OS install or Sysprep, will installation ID will change?
If hardware has remain constant, and serial number is also static, can we conclude that CSV file imported before the OS reset / upgrade will still be accepted?
LikeLike
Pingback: Windows Autopilot Links | More than patches
Hi Peter,
Thank you for posting your video and blog, it was helpful to see everything in action. After watching, I had a couple of questions based on the goals I’d like to accomplish with AutoPilot, which are: a) prohibit users from installing unapproved software, b) allow Windows updates and company approved software updates/patches to be applied automatically without prompting for UAC elevation, and c) enable remote HelpDesk access with Administrator credentials.
1) In the video, you installed the user as NonAdmin. How would the user then install Office365 or any other “company approved” software like Adobe Acrobat as NonAdmin? Wouldn’t the user need Administrative rights? Or could these software installs be made part of the AutoPilot deployment? Or could a remote Administrator login and install these?
2) If the user was remote and needed some sort of support, would a HelpDesk agent be able to remote into the machine with Administrator credentials in order to “fix” any problems?
3) If the hard drive died and is replaced with a factory image from one of the AutoPilot vendors, Dell for example, it seems like the hardware hash would change. If that user is remote, then it seems like they would not be able to get AutoPilot to work due to the hash change, is that right?
LikeLike
I think I found the answer to #3 – “When the Windows Autopilot Deployment Service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully.” https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/add-devices
LikeLike