Using the Enrolment Status Page with Autopilot

In my previous article (here) we looked at Autopilot, what the benefits are for an organisation and how to configure it.

In this article we are going to look at the additional feature of the Enrollment Status Page (ESP) and how that enhances the default Autopilot for both the end user and IT administrators.

What is The Enrollment Status Page

What you may have noticed when we were performing our Autopilot Enrollment in the previous lab was that the end user was delivered to their desktop before the Intune Enrollment process was complete, and therefore before the compliance policies and applications that were targeted the the device or user were enforced. This is may seem like a trivial issue on the surface, and waiting for the policies to arrive is the resolution, but what if this did cause an issue.

What if an end user started to use the system before all of the applications that he/she needs are fully installed and configured? Chances are that they will open a ticket with the service desk with all of the overheads that entails. What if the user starts to browse the internet before your corporate security policies have been enforced? Then you are playing catchup in a security context, which is always bound to lead to some vulnerabilities.

The fact is end users, and IT professionals, expect devices to be ‘working’ when they are delivered.

To address this is Microsoft have introduced an Enrollment Status Page feature into Intune to allow the on boarding process to be controlled, and administrators have the ability to ‘lock’ the device until it has been deemed ready for end users to start using it.

Creating a User Group

Firstly, it is only possible to deploy any ESP profiles to user groups present within AzureAD. Therefore, we need to either select an existing group that contains out demo user(s) or create a new group. In this demonstration we will create a new group for this purpose.

Open the Azure Portal and navigate to Azure Active Directory > Groups and select New Group

Input the Group Type, Group Name, Group Description, Membership type and selected a single user account and click Create

Now we have a suitable group we can can now proceed to creating our custom ESP profile

Configuring the Enrollment Status Page

Like all Autopilot and Intune polices we first new to logon to the Azure portal, then navigate to Intune > Device Enrollment > Windows Enrollment > Enrollment Status Page

Here we can see that there is already a Default policy which is assigned to ‘All users and all devices’. This policy is created on all Intune tenants and as you can see by the description and configuration it is not configured to show the progress of the apps and profile installation.

We will therefore create our own Profile to configure the end user experience of the ESP exactly as we wish

Firstly, navigate to Intune > Device Enrolment > Windows Enrolment > Enrolment Status Page and select Create Profile

We will then complete the Name and Description of the Profile and clicking on Settings opens the settings of the Profile. Here, we can configure the ESP exactly as we wish. In my example I have enabled the features ‘Show apps and profiles installation progress‘, ‘Block device until all apps and profiles are installed‘ and selected my Office 365 app as an app that we have to wait for installation to complete

Then click ‘Save‘ to close the Settings blade, and ‘Create‘ to create the profile.

Now we have created our new profile we need to deploy it to the group that we created earlier. To do this click on the ‘Assign‘ button

Then click Select Groups, select the ‘ESP demo’ group we created earlier and click Select

And click Save to commit the changes

We have now completed the setup of the ESP and are now ready to commence testing of the End User experience

Enrollment Status Page experience

To test the ESP experience we need to first start a Windows 10 workstation that is registered in Autopilot and has been reset. I will not go through the details of how to set this up as I would be repeating my previous article.

Firstly, boot the workstation into the OOBE wizard and select the region

Select a keyboard layout

Select an additional keyboard if required

Now, because the device is registered for Autopilot the standard Autopilot experience will take over and prompt the user for credentials

Now we start to see our new ESP controlling the setup experience

This process can take some time because as we talked about at the start of this article the propose of the ESP is to ensure that all enrolment and deployment configuration is completed before the user is delivered to their desktop. Also, in this example we assigned Office 365 as an enforced app which, due to its size, can take some time to download/install depending on bandwidth and workstation performance.

Eventually though, we see that the users desktop is loaded, complete with Teams as Office 365 has been successfully installed.

And that concludes the demo of the Enrollment Status Page

Configuring Microsoft Autopilot

Hi All,

Today I am going to walk you through the setup of an Autopilot demonstration scenario that I recently set up for a customer.

What is Autopilot?

OK, so firstly let’s cover off the basic question of ‘What is Autopilot and why would I want to use it?’

Autopilot was first introduced in Windows 10 1703 and is a new deployment methodology from Microsoft that allows Organisations to make use of Azure Active Directory and Microsoft Intune to take ownership of -and fully configure-, the Windows 10 installation that comes pre-loaded onto new hardware by the OEM manufacturer. The benefit of this is that Organisations no longer have to purchase hardware, have it shipped to the IT department, wipe the existing OS and load a custom Windows image.

The wipe-and-reload methodology has been around for the last few decades and has worked well for Organisations. Nonetheless, it does come with downsides such as:

  • Creating the custom image
  • Deploying technology (such as MDT or SCCM) to deliver the image
  • Additional workload for IT to perform the wipe-and-reload process
  • Maintaining a driver catalogue each time new hardware types are procured
  • Maintaining Operating System updates within the custom image
  • Maintaining the custom applications installed within the custom image
  • Delay between purchase of hardware and delivery to end-user

Therefore, the ability to simply make use of the OEM image without having to perform the functions listed above has the potential to allow for new hardware to be delivered directly to end users, saving time and money. Additionally, the initial setup of the device could also be performed by the end user, totally removing the overheads for the IT department.

So, now that the purpose and advantages of Autopilot is more clear, let’s start to create a demo lab so we can test the functionality…


In order to proceed with this lab you will need the following:

  • A single Windows 10 workstation (can be physical or virtual),
    • Build 1703 or above (I will be using 1903 for this demo), LTSC 2019 also supported
    • Professional, Education or Enterprise edition
  • Existing Azure Tennant with demo users
  • One of the following licenses assigned to demo users
    • Microsoft 365 E3
    • EMS E3
    • Azure Active Directory P1 & Intune

Obtaining the Hardware ID

The first thing you should know when testing Autopilot is that when a Windows 10 workstation is booted for the first time during the OOBE (Out Of Box Experience) the setup process contacts Intune to see if the workstation has been registered for this functionality. This process is performed every time a Windows 10 workstation is booted for the first time. Note that if the hardware ID is not registered (or the workstation cannot contact Intune due to lack of internet connectivity) then the OOBE silently continues with user interaction. However, if the hardware ID has been registered for Autopilot then the OOBE branches into that process.

In a production environment this registration will be performed by the OEM who will provide Microsoft with a list of hardware IDs for the workstations being purchased and the Azure Tennant ID that the workstation should be assigned to. Obviously you will need to have provided your Tennant ID to the OEM at the time of purchase.

However, in our lab we are not purchasing new hardware but using a VM that has been created specifically for the purpose of testing Autopilot, so we need to manually complete this hardware ID registration by performing the following process:

  • Install Windows 10 on workstation from Microsoft installation media
    • Complete the standard Windows Setup experience using the default options as below
    • Complete the OOBE experience by simply creating ‘user1’ with a temporary password
  • Run the following PowerShell script which will generate the hardware ID for the test workstation and export it to a .CSV file
md c:\HWID
Set-Location c:\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
$env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
Get-WindowsAutopilotInfo.ps1 -OutputFile AutopilotHWID.csv

Noteu – I did find on my vanilla workstation that I had to modify the execution policy to allow scripts to be run and also accept the installation of the NuGet provider

Copy the .csv created in c:\HWID to location that can be accessed from a seperate workstation where the Azure portal will be used to make the configuration changes.

Reset the VM

Now that we have the Hardware ID extracted from our test machine we can reset the workstation so that it will perform the OOBE and we can simulate the end user experience.

To do this open Settings > Update & Security > Recovery and click on Get started under Reset this PC. Select Remove everything and Just remove my files. Finally, click on Reset.

This process will take some time and the workstation will restart several times during this process, so we can move on to the next steps while this is processing.

Importing the Hardware ID file

Now we have the .csv file containing the hardware ID we need to upload this into the Intune portal so Autopilot knows the ID. To do this simply open the Azure portal and navigate to the blade Microsoft Intune – Device Enrollment – Windows Enrollment – Devices

You can see the option to Import at the top of the page. Click this and navigate to the .csv file that was previously created.

This process will eventually complete and you will see the device listed.

You will also note that if you browse to Azure Active Directory – Devices you will see the device we have just imported. Note though that the device is only listed by its serial number as it does not yet have a name (at least not one that is known to AzureAD).

Preparing AzureAD

We now need to configure our environment appropriately to allow Autopilot to function.

Firstly navigate to Azure Active Directory – Devices – Device Settings and enable the option to allow users to register devices in Azure Active Directory. In this demo I am allowing all users to register devices, but you may want to limit this to a test group.

Then we need to set Intune as the MDM authority so that systems that join AzureAD are automatically registered and managed with Intune. We set this in Azure Active Directory – ‘Mobility (MDM and MAM)’

Now we need to create an AzureAD group that we can assign our Autopilot profile to and to make our test workstation a member of the group. To do this we navigate to Azure Active Directory – Groups and click on New Group

We can then name the group as shown below, including making our test machine a member of the group (remember at this stage we are still having to manage the workstation by serial number).

Note – Its important to highlight that for the purpose of this demo we are only adding a single device to the group, but we could make this a dynamic group that automatically contains all devices

We now have everything we need configured in Azure AD and are ready to configure Intune

Configuring Intune

Now we need to create a new Autopilot profile within Intune. To do this navigate to Intune – Device Enrollment – Windows Enrollment – Deployment Profiles and Select Create Profile

We then give the profile a name

Configure the options we want our devices to display to the end-user

Define your desired tags

Finally, we need to deploy the profile. Choose which groups we want to include (or exclude). In the example below, we will select the group we have created specifically for this purpose

This then completes the Intune configuration and we are ready to test out new Autopilot experience.

Autopilot Experience

Now change back to the test workstation. It should now be displaying at the region selection screen. This is the start of the user experience as they would see it if Autopilot was enabled for them.

First the standard Windows 10 setup prompts. Select the Region

Select the keyboard layout

Add any additional keyboards layouts

Now for the different experience with Autopilot. The user will then be prompted to enter their username (remember they should utilise the format Please note that the device already knows that it is managed by our Organisation.

And then their password

After the user profile creation process has completed and we arrive at the user’s desktop we can then see in Settings > Accounts that the device is registered to the correct AzureAD tenant.

Also, we can see in Intune that the device is registered and compliant with policies

So that concludes our demonstration of Autopilot. The user was only prompted for the standard Windows 10 setup questions along with their Username and Password and they now have a fully AzureAD and Intune registered workstation ready for management.

Connecting SCCM to Upgrade Analytics

In my last post I detailed the process for deploying Upgrade Analytics and how to use SCCM to configure workstations to upload their telemetry data for processing in Upgrade Analytics.

Now we have this data available to us in Upgrade Analytics I am going to walk through the process of connecting SCCM to import the available Upgrade Analytics data back into the SCCM console. Doing so enables administrators to create SCCM collections based on the Upgrade Analytics data, and then in turn create deployments to remediate issues that have been identified with apps/drivers etc. that are currently blocking in-place upgrades of Windows 10 to the desired build.

Obviously a pre-requisite to following this guide is to have fully deployed Upgrade Analytics according to my previous blog post.

Create Azure AD Web Application

The first stage of connecting SCCM to our existing Upgrade Analytics instance is to create an Azure AD Web Application which will then, in turn, be used to grant SCCM read permissions to the instance.

Firstly, navigate to and logon with your Azure AD credentials. Then navigate to the exiting Azure Active Directory instance and select ‘App registrations’.

Now click ‘New Application Registration’ and complete the details as below:

  • Name – Free text but call this something easily identifiable
  • Application Type – Select Web app / API
  • Sign-on URL – Does not need to be a valid URL (as we won’t be redirecting users to this address), but must be in a valid URL format with http:// or https:// as a prefix

And click ‘Create’

The Application will then be created and the details presented in the console

Now click ‘Settings’ then ‘Keys’ to be prompted to create a new Key. Complete the name of a new key (maximum 16 characters) and select the length of duration for the key.

Click ‘Save’

Important – At this stage you will now be presented with the key in the form of a 43 character text string. I have deliberately not screenshotted my key, but this is the only time you will be able to read the key so ensure you copy this key now and store in a secure manner. Also, note the Expiry date (although this can be retrieved later).

Also collect the Application ID and App ID URL from the key properties screen.

Grant the New Application permissions to Upgrade Analytics

Now we have successfully created our Azure AD application we need to grant to the required permissions so it can access the data stored in Upgrade Analytics.

To perform this, within the Azure Portal browse to Resource Groups and select the Resource Group that contains the Upgrade Analytics solution

Under ‘Add a role assignment’ select ‘Add’ and complete the presented screen as below, then click ‘Save’.

Note: It is required to assign the permissions at the Resource Group level as later in the process SCCM will need to create a

Configuring SCCM to connect to Upgrade Analytics

Now we have created our new Azure AD app and granted it the correct permissions we are ready to connect SCCM to Upgrade Analytics.

In the SCCM Console browse to Administration-Cloud Services-Azure Services.

Then right-click on ‘Azure Services’ and select ‘Configure Azure Services’. Complete the presented wizard as shown below.

Then ensure ‘AzurePublicCloud’ is selected and click ‘Import’

You will then need to complete the presented screen with all of the details listed below and click ‘Verify’

  • Azure AD Tenant Name – Free text field but name it something easily identifiable
  • Azure AD Tennant ID – This is the directory ID of your Azure AD instance. This can be found by browsing the properties screen of Azure AD
  • Application Name – Free text field but name it something easily identifiable
  • Client ID – This is the App ID previously obtained
  • Secret Key – This is the Key previously obtained
  • Secret Key Expiry – Ensure the same date is selected as the key expires
  • APP ID URL – This is the previously collected value

Provided everything verifies successfully click ‘OK’ and then ‘Next’ in the wizard

Ensure that the correct Subscription, Resource Group and Windows Analytics workspace are selected and click ‘Next’

Review the settings and click ‘Next’

Once the wizard completes click ‘Close’. We can now see that the Upgrade Analytics Connecter is listed in Azure Services

Now if we switch to the Monitoring – Upgrade Readiness node in the SCCM console we can see the data is displayed

This completes the configuration of connecting SCCM to Upgrade Analytics