Group Policy Analytics role in moving User authentication to Azure AD


When I meet with customers one of the conversations I typically have is that organisations would like to start joining new devices (either Autopilot or ConfigMgr deployed) to Azure AD joined and shift their user authentication process into the cloud. This has many benefits, not least the mitigation of having to rely on a VPN back to their on-prem domain controllers to perform the authentication. As the conversation progresses we talk through using Azure AD Connect to synchronise identities, and how that will work with NTFS file shares, then we hit a snag. Group Policies.

Its worth prefixing this post with the fact that typically I work with medium to large organisations with 500+ devices that have many years of GPOs, possibly created and deployed by admins no longer with the company and no clear understanding of what every GPOs purpose is let alone the specific settings in the GPO.

Up until now I have had to explain that these GPOs will no longer apply as the devices will not be joined (or Hybrid Joined) to the existing on-prem Active Directory, and Azure AD does not provide support for GPOs. The migration path would necessitate converting their GPOs to Intune Configuration profiles, enrolling their device to Intune and then deploying the profiles. So far so good… then the killer line “there is no way to convert GPOs to Configuration profiles and this would be a manual process”. At this point they start to estimate the effort involved in analysing these existing GPOs and deciding which ones to migrate and which are stale or no longer required, and they start to favor Hybrid joining the devices just to hang on to what they know as they see it as less effort. This means they miss out on the benefits of Azure AD joining the devices and keep the reliance on their VPN and line-of-sight connectivity to a Domain Controller.

Now we have a new tool to assist with this conversation, Group Policy Analytics in the Endpoint Manager admin center.

Group Policy Analytics allows us to export our existing GPOs to a .xml file and then upload this file to the Endpoint Manger admin center for automatic analysis of all the configuration contained with the GPO. This will then tell us which of the settings can be migrated to Configuration profiles, which are not supported and which are depreciated.

Lets see the workflow in action


Firstly, we need to connect to open Group Policy Management Console on a domain joined device and locate a GPO we would like to test for conversion. We then right-click on the policy and choose ‘Save Report’. Save the .xml file to a temporary location which is easily accessible.

Open Group Policy management and save a GPO as an XML file report.

Then in the Endpoint Manage admin center navigate to Devices > Group Policy Analytics (Preview), select Import and choose the .xml file we previously exported. For my demonstration I am choosing to import the Microsoft provided Windows 10 2004 security baseline GPOs as I know these contain multiple settings and are a good example of complex GPOs.

The admin center then processes the .xml and provides us with a report showing the migration possibility for every individual setting as well as a summary for what percentage of every policy can be migrated to Configuration profiles. We also get a summary showing the total number of settings and migration counts across all GPOs.

Clicking on the percentage column shows us the individual settings included in the GPO and which can be migrated to Configuration profiles.


This is a big step forward for simplifying the analysis of the workload required in the migration from GPOs to Configuration profiles, and with it helping companies to move to the cloud for user authentication. There would still be additional work to be performed to work through the ‘Not Supported’ and ‘Depreciated’ settings to determine what the impact would be and if any mitigations need to be put in place, but this is a much simpler process than anything that has come before.

However, there are some things still to consider:

Organizational Units to security groups – GPOs by design are deployed to OUs and a computer can only exist in a single OU. Configuration profiles are deployed to security groups. There is currently no way to map OU membership to security groups without writing custom PowerShell scripts and executing these on a regular basis.

Automatic creation of Configuration profile – After the GPO has been analysed by Endpoint Manager it is currently necessary to manually create the Configuration profile. Hopefully Microsoft will introduce a method for automatically creating the required profile with settings ready for deployment.

Intune enrollment – For the propose of this blog I have assumed the the devices in question will be enrolled in Intune and therefore will support Configuration profiles.

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.