If you’re starting out from scratch with Intune’s Autopilot, this run through should help get the key elements established so that you get a build result to look over, and a platform rigged for further exploration.
Some things needed:
- Azure Premium
- Windows automatic enrolment
Go get an EMS E5 evaluation\trial, and get your tenant up and running, handle the DNS (CName), and if you want, use AD Connect to join it to an existing lab-based on-premise AD.
Let’s get going.
Retrieve the VM for AutoPilot information
I chose Windows 10 Build 1809 used for this run through.
Build yourself a VM with enough CPU cores assigned, and 2GB of memory as a minimum.
Let it boot off your Windows 10 ISO and push through setup.
You have to choose to domain join, then let it go through the setup of a local administrator account.
Once you’re at the desktop you can run the Get-AutoPilotInformation PowerShell script authored by Michal Niehaus. The script captures the Device Serial Number and Hardware Hash needed by Intune to identify the VM (device) when it calls in, more properties can be supplied such as Order ID and Purchase Order ID, but these two are all we need for testing with our own VM’s (Product ID is obsolete as noted by Michael in the comments on the scripts download page).
To ease the pain when introducing new Windows 10 VM’s to AutoPilot, I jotted down the steps I need to go through to run the script, so that I can copy\paste them into the VM when needed.
I paste this little lot into a bat file and run it in an administratively elevated command prompt:
Powershell.exe
Set-ExecutionPolicy Bypass
Net use Z: \\<IP of device where script resides>\<drive letter where script resides>$
/user:<IP>\administrator <Password>MkDir C:\Temp
Copy Z:\*.ps1
C:\TtempCD C:\Temp
.\Get-WindowsAutoPilotInfo.ps1
-OutputFile ($(Get-WmiObject Win32_Computersystem).name + “.csv”)Copy
($(Get-WmiObject Win32_Computersystem).name + “.csv”) Z:\Net use Z: /D
The steps are to map a network drive, and then copy and execute locally the information gathering script from Michael Niehaus which can be found here.
When run on a VM we get the CSV needed for import into Intune’s AutoPilot:
That CSV file needs to be available for a browser file dialog to select, so make sure you copy it to wherever that is.
Import the device information into Intune AutoPilot
To link the device to the service, we need to import that CSV containing the Device Serial Number and the Hardware Hash.
When OOBE runs on a device and you’ve chose the region and keyboard, it will call back to the Intune service. All Windows 10 devices performing a build will try to talk to Microsoft, this is so that they can verify if they are registered with Autopilot and initiate the work-flow if needed. If a user is assigned to the device, they will be welcomed and prompted for their password, otherwise a prompt for their username will show.
To import this device, visit the Azure portal and navigate your way to Intune.
Once there, navigate into Device Enrollment, Windows Enrollment, then click on Devices:
The ribbon should show the Import option, select it:
Choose the CSV obtained from the VM.
If it passes the verification check you’ll get a green tick, click Import:
Onboarding devices into Intune splits between setting up for new devices and setting up for existing devices.
For existing devices, you can as just one option hybrid join them to Azure AD, which automatically enrols them into Intune, and then put those devices into an Intune security group, so that Intune automatically converts them to AutoPilot enabled devices.
If you don’t want to enrol the devices into Azure AD first, and instead want to reset them so that their workflow ends up joining them to AAD and enrolling into Intune, then you’re going to need to retrieve identity information from all those existing devices, and perform the import of that meta into Intune manually.
For new devices you can hand crank the import process yourself if you have devices shipped to the local talent before delivery to users, or, you can get your box shifter to crank the handle for you.
Note the 175 device limit for CSV import. You’ll have to batch things when onboarding new devices into the production environment.
So, new devices coming in will need to have their identity extracted by the onsite talent, or if you have a box shifter providing you with equipment they can hand over this CSV whenever kit is allocated to you, and the local talent imports into Intune, or whoever sells you the devices can import the CSV directly into your tenant if you have that relationship setup with them.
If the local talent isn’t doing it, it all costs money, not much per device, and from what I hear most customers are happy adding the additional cost on for this service.
Quite a lot of small to medium sized businesses have already outsourced the maintenance\management and delivery of client devices to their users, from the big boys like HP, Dell, IBM and Microsoft (Surfaces) down to smaller resellers providing a managed service.
These resellers and OEM’s are pretty much prepared for Intune AutoPilot, if not then they are seriously lagging behind the wave of technological progress taking place right now.
Once you click Import it will notify you that the device is being imported:
Behind the scenes your Azure Tenant has a dedicated Hamster ready to begin processing any workloads assigned to the tenant, this is my one, its responsible for all the magic taking place for my configmgr2012.com tenant:
The breed and size of your tenants hamster depends on what level of service you are paying for, EMS E3 or E5 for example bring forth the Mongolian hamster that comes in either small (E3) or large (E5) varieties with the larger obviously producing more bang for your buck.
Like McDonalds, there’s an under-the-counter menu so to speak, if you contact your Azure rep and ask them to swap out the Hamster for a small Tasmanian Devil, you’ll see performance shoot through the roof, they do not have many thus you have to specifically prompt them to upgrade your tenants bio-ware.
Give it a few moments and refresh, the hamsters might be taking a drink\nap\social break, spinning that wheel all day makes for thirsty work:
The device should now show up.
We can also at this point assign a user to the device directly, to do this select the tick box for the device and then select Assign User:
It should pop out a Select user pane allowing you to select off a user to assign to the device:
Choose the user and click on the Select button and then Save.
As you can see TestUser1 has been assigned to this device, and a personalised message will be shown to that user when they log in.
The final step which can be performed before you assign a user, is to perform a Sync to make Intune recognise the device.
It’d be nice if this was automatically done when the devices are imported, but I figure the delay is there so that you can clean up any erroneous devices before committing, and to break-up the work-load being put onto Intune:
That is all that is needed to make this device AutoPilot ready.
If we reset this device and return to OOBE, then log in with TestUser1 from the tenant, AutoPilot won’t yet kick in though.
Park up, as there is more configuration to be carried out before you kick off a reset.
Configure Intune for AutoPilot
Before you reset the VM, there’s a few more things that should be taken care of.
The first thing to do, and it is a prerequisite, is to make sure you have Automatic Enrollment configured (Device Enrollment – Windows Enrollment), so that any device enrolled into Azure Active Directory is then automatically enrolled into Intune.
Head to Device Enrollment, Windows Enrollment and select Automatic Enrollment:
Save any changes you make.
Next up will be creating an Azure AD Group that becomes the focal point for assignments, device Compliance and Device Configuration policy, and if you so choose, the target for a custom policy to drift away from the default policy for the Enrollment Status Page.
Create an Azure AD Group
Head to Azure Active Directory and visit Groups.
Hit the New Group button.
Select Security for Group Type
Call the group anything you want, AutoPilotDevices will do for this walk through.
For Membership type select Dynamic Device then click on Add Dynamic Query.
Select the Advanced Rule option and enter the following:
(device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
It should look like this:
Commit the changes by clicking Add query and then Create.
All our AutoPilot devices will show up in this new group, there are a few other query examples here in the Enroll Windows devices in Intune by using the Windows Autopilot guide on Microsoft Docs.
An ultra-brief momentary opportunity to prepare some tea and biscuits, with a refresh a little while later thrown in, and the newly imported AutoPilot ready device shows:
Configure an Enrollment Status Page Profile
The Enrollment Status Page is legendary.
You cannot live without it when deploying with AutoPilot really.
It gives the provisioning process to the user a little bit more polish, but most importantly holds back a device so that all the policies are laid down, applications installed etc before setup releases back to the user.
Without it, the user will get to the desktop and wonder at the lack of marvel and wonders, and most likely start seeing a bunch of notifications of things happening, while silent and very magical things occur as the provisioning process continues to wade its way through pools of success towards the finish line.
You can either create your own ESP Profile or configure the default, in my lab tenant I want all users and devices to see the ESP with no difference in configuration, so I skipped creating a new profile and edited the default profile (almost criminal!):
Feel free to knock up a new profile as an override to the default profile, and assign it to the AutoPilotDevices group, Oooo I nearly said Collection then!
Next up we will configure an AutoPilot Deployment profile, this will enable AutoPilot.
Create an AutoPilot Deployment Profile
An AutoPilot Deployment profile doesn’t offer up much in terms of configuration, its pretty light in this respect, with a few options needed to turn the service on for devices in an Azure group that the profile is deployed too.
Go visit Device enrollment, Windows enrollment, and under Windows AutoPilot Deployment Program select Deployment Profiles,and then click Create profile:
Give the profile a suitable name for testing, I will use AutoPilotDeploymentProfile for this walk through.
Select Yes to Convert all targeted devices to Autopilot.
Any devices in this security group will have an Autopilot record automatically created for them. Handy.
For Deployment mode select User-driven, the other option is self-Deploying, a preview option and a workflow I won’t cover in this walk through.
Click on Out-of-box experience (OOBE) to wake up the OOBE pane.
Configure as in the screenshot above, hide the EULA, hide privacy settings, hide change account options, user account type I’ve set to Administrator, and Apply device name template is configured as AP-%SERIAL%.
We’ve configured Autopilot, so now click Create to make the magic happen.
You’ll see the profile appear, visit the profile and assign it to the AutoPilotDevices AAD Group.
You now have the lights switched on for Autopilot in your tenant, with no bells and whistles, and any member of that Azure group AutoPilotDevices, as long as they have been registered in Intune Autopilot, will participate in Autopilot.
Technically I could boot that VM up now and once OOBE runs I’ll be prompted with a welcome message and the username pre-populated, this is assuming that like me you assigned a user to the device first.
Before we do a test, we should create some more policy, for Device Compliance and Device Configuration, as well as introduce a couple of Apps, an MSI and Office 365, with Office 365 being an on-the-rails experience built-into Intune as you will see later on.
Create a Device Compliance Policy
Nothing fancy, some simple compliance policy just so that there is some.
Visit Intune, Device Compliance and create a new Policy:
I’ve called mine CP1 and made some very basic not-worth-shooting changes, do the same, do not switch on everything or go for exotic and complex options, keep it simple for testing and grow out from there as you touch on more Intune features.
Once the policy is configured, head to Assignments and assign it to the AutoPilotDevices Azure group:
Next up the Device configuration Policy.
Create a Device Configuration Policy
Again nothing fancy, we just want a compliance policy enforced against the Autopilot enabled devices.
Visit Intune, Device Configuration, Profiles, select Create Profile:
Real simple, a few options selected, enough for compliance to be met, not made complex, kept simple for testing, expand on this later on, do not be tempted to toggle almost everything on for your first go. Select OK and then Save.
Click on the profile and select Assignments, assign it to the AutoPilotDevices Azure group:
If kept simple, creating device compliance and configuration profiles and assigning them to the test Azure security group shouldn’t take more than a few minutes.
Now the applications.
Deploy Office 365 and a generic Win32 App to new AutoPilot devices
Office is a big bag of complexity being made simpler, in Intune we can deploy Office 365 as an App, and we do not have to handle the source files, its an interesting workflow which we will explore in a moment.
But first we will introduce a basic off-the-shelf Win32 application wrapped in MSI goodness and upload it to Intune, so that we can deploy it to our target audience.
The work-flow is pretty well described in the MS Docs here for creating and deploying a Win32 application.
There are some basic prerequisites which shouldn’t be a problem if you are enrolling a device to Azure, and we need to convert an MSI into a new file format called IntuneWin.
The conversion tool can be found here, and with the living docs to the side you should be able to easily convert your MSI without me stepping you through it.
Once you’ve converted your MSI you will need to upload it to Intune, and the work-flow for this is well-described in the MS Docs which I will link to again for you to follow, there really is no point rehashing what MS has written down, its quite comprehensive and covers the process end-to-end.
As you can see below, I’ve brought in the PatchMaster MSI and assigned it to the AutoPilotDevices Azure security group:
You can use any MSI you want, I’ve got another that I use for testing, LogLauncher which can be found here.
Neither are signed, Intune is fine with them.
Now let’s create the Office 356 application, its a cinch.
Visit Intune, Client Apps, Apps, and select Add.
In the drop down for App Type there is the Office 365 Suite, select Windows 10.
Now step through the required configuration, select App Suite Information:
Figure out what you want set, set it.
Once done select OK.
Now select Configure App Suite:
Again configure to your needs, keep it simple.
Once done select OK.
Now select App Suite Settings:
Configure as you desire.
Select OK, then select Add.
Select the new Office 365 application you just created:
Select Assignments and assign it to the AutoPilotDevices Azure security group:
Select Save and we’re done.
Time to reset that VM.
When we do, we’ll expect the following experience and results:
- Autopilot will kick in immediately and welcome TestUser1 and prompt for that accounts password
- The Enrollment Status Page will show
- We’ll see the device progressing through the setup stages
- We will see two applications installed
- The machine will be released to TestUser1 once the Autopilot provisioning has completed
- The device will be named AP- with its serial number suffixed
- The device will be Azure AD joined and enrolled into Intune
Resetting the VM and experiencing Autopilot
We’ll cover this in the next part, which you can find over here.