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

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 http://portal.azure.com 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