Introduction

This is not a traditional walk through of a specific technical topic. It’s rather a story about setting up my new Surface Pro X device, making it work with AutoPilot, Intune and ConfigMgr in a Hybrid AAD Join deployment.

You don’t per say have to own a Surface Pro X device in order to benefit from the content in this post. However, as the Surface Pro X ships with an ARM processor, it makes for some unique situations and experiences.

During the post, I will deep dive some of the technical aspects of Hybrid AAD joining the device, as this has a lot of moving parts and dependencies in order to work.

Additionally, this process was not completely without obstacles. I’m not sure if these obstacles are working as intended or not, but I failed to get Co-management work loads to work properly, as well as I was seeing weird things happening if applying the Security Baseline for Windows. More on that throughout the post. 🙂

Hybrid AAD Join

This is a feature which released back in November 2018. Back then I did a post on the initial setup required. Find that post here: https://www.imab.dk/how-to-join-windows-autopilot-devices-to-on-premise-ad-active-directory/

I’m skipping all of that initial setting up with the Intune Connector, permissions in AD etc., and instead just touching base with what’s really interesting (from my point of view). 🙂

Groups for Assignments

This particular topic, groups used for assignments, has proven really important. Especially if you intent to Reset or Refresh the device at some point. I’ll explain a long the lines:

• Log into the Microsoft Endpoint Manager admin center: https://devicemanagement.microsoft.com
• Create a new group used for assignments related to the Hybrid AAD Join
  • In my scenario I named it: Intune_AutoPilot_HybridAADJoin

The interesting and important parts of the group, are the Dynamic membership rules.

I’m using membership rules which caters for a lot of things. The first initial deployment is picked up by the OrderID (more on that later). The enrollmentProfileName picks up the device once the Deployment Profile has been assigned, and finally to cater for all weird scenarios, I’m picking up the device prefix which is used in the Deployment profile (also explained later).

I’m not a true fan of using the device name prefix like this in the membership rules, but I have sometimes been pulling my hair, finding that the device is no longer member of the group, resulting in a failed deployment.

When that happened, I took a closer look on the device via the Graph Explorer at https://developer.microsoft.com/en-us/graph/graph-explorer and found that the OrderID was no longer applied. I fail to properly explain this part, but it’s not something I see every time and during making this post, I found the OrderID to apply to both objects each and every time.

Note: Michael Niehaus has some explaining on this part here which I suggest you to read: https://oofhours.com/2020/01/20/the-first-day-in-the-life-of-a-hybrid-azure-ad-joined-device.

Below is the AzureAD object with the OrderId applied:

And the same device, now looking at the Hybrid AAD Joined object still with the OrderId applied:

Deployment Profile

The deployment profile used in this scenario is straightforward. The important parts here are the assignments, and making sure not to apply a device name template.

The assignment and the group used here is important, as you want to make sure you never have overlapping assignments. In other word, having multiple Deployment Profiles which targets the same devices will be a mess.

In this case, the group explained above make sure of that (unless someone potentially renames their devices to the same prefix, and then we have troubles. I’ll worry when that time comes). 🙂

Hybrid AAD Domain Join Profile

The Hybrid AAD Domain Join profile is straightforward as well.

The prefix is important, as this is used in the membership rule in the group explained above, and the assignment has to be targeted the very same group as the Deployment Profile – also explained above.

Adding Device to AutoPilot

For now, I only have this one Surface Pro X device and I’m just adding it myself. At scale, it’s properly better to have someone else adding it into AutoPilot, like the reseller.

I’m covering the topic regardless, because of the importance of verifying that the device being properly imported and having a Deployment Profile assigned.

To import a single device, I just recommend gathering the hardware hash yourself using the Get-WindowsAutoPilotInfo Powershell script: https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo/1.6

Explained in more details here: https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/add-devices#collecting-the-hardware-id-from-existing-devices-using-powershell

I’m also adding the Group tag manually directly via the interface. Once I do that, the group explained above will pick up the device and assign the Deployment Profile automatically.

Configuration via Intune

There are obviously endless options in which to configure the Surface Pro X, and these are not exclusive to the Surface Pro X device. However, I have chosen to explain a few regardless, as they make sense in this context.

Software Update Rings

I have created a separate Software Update ring specifically for the Surface Pro X devic. I have done that, because I want the Surface Pro X to receive updates for any drivers that may be released by Microsoft (and I don’t want that to happen on any other devices).

That means I have excluded my Surface Pro X devices from the regular Software Update Production Ring, like so:

And assigned a separate Software Update ring just for the Surface Pro X device:

The Surface Pro X device can be separated in their own group, by creating a group with following membership rule:

Configuration Manager

My intentions was to Co-manage my Surface Pro X device. While I was able to install the ConfigMgr client without issues, working with the different Co-management work loads turned out to be an obstacle. I’m not sure if this is intended, as the device indeed is Co-managed, but deciding which work loads goes where didn’t work. I will elaborate later.

Installing ConfigMgr client via AutoPilot and Azure Authentication

I’m installing the Configuration Manager client via my Cloud Management Gateway and Azure AD authentication. This is done by following few steps:

• Grab the ccmsetup.msi file from your ConfigMgr site server: <ConfigMgr installation directory>\bin\i386\ccmsetup.msi
• Upload it into Microsoft Intune as a Windows MSI line-of-business app
• Command-line arguments: CCMSETUPCMD=”CCMHOSTNAME=CMG.YOURDOMAIN.COM/CCM_Proxy_MutualAuth/72057594037927940 SMSSiteCode=PRI AADRESOURCEURI=https://ConfigMgrService AADCLIENTAPPID=733ce3ec-9568-4c59-9bd4-f549456f66f2 SMSMP=http://MP1.YOURDOMAIN.COM”

A direct copy of my ConfigMgr 1910 Client in Microsoft Intune below. Excuse the obfuscation, but the command-line arguments are from production and therefore sensitive.

The command-line arguments are obviously the most important part here. This is where you specify your Cloud Management Gateway and relevant details in order to authenticate with Azure AD.

Parts of the command-line used can be found in your Configuration Manager console in the Administration work space in the Cloud Services node:

What’s not inserted for you automatically, are following properties:

• AADCLIENTAPPID (Not needed if running ConfigMgr 1810 or later)
• AADRESOURCEURI (Not needed if running ConfigMgr 1810 or later)
• SMSMP (Needed if the client is expected to roam back to the Intranet)

Once installed, in this scenario via an available assignment in the Company Portal, you hopefully find a successful installation:

Hybrid AAD Join in Progress

The process in which the devices are being Hybrid AAD Joined is quite interesting.  There are tons of moving parts and I understand why it can be difficult to troubleshoot if something goes wrong.

I have taken a closer look on what’s happening, from the device is being imported into Windows AutoPilot, to the device is fully deployed.

• When importing the hardware hash into Windows AutoPilot, the device is initially added with the serial number as the name. You can then look up the device using this name via Powershell.
  • Notice the ObjectId which stays the same once the computer is being renamed for the first time.

• When you sign into the Graph Explorer via https://developer.microsoft.com/en-us/graph/graph-explorer, you have the option to take a closer look on the device directly via Microsoft Graph.
  • In this scenario, you use the ObjectId found via Powershell and insert that into the query in Graph Explorer:

• The response preview will be similar to below illustration:

• When the device has initiated the Windows AutoPilot deployment, the device is being renamed for the first time into the generic name DESKTOP-XXXXXXX.
  • Notice that the ObjectId stays the same:

• Also indicated directly in Microsoft Graph:

• Some time down the process, the device reboots again in order to rename the device. This time using the prefix you configured in the Hybrid AAD Join profile in Intune. What also happens, is that the Intune AD Connector generates an offline domain join blob. This is where the new object is created in your on-premises Active Directory.

• What’s probably happening  in your end by now, is that Windows AutoPilot is trying to register the device with Azure AD and waits for AD Connect to sync back the hybrid joined object.
  • This is happening every 30 minutes by default (or if manually forcing a delta sync using Start-ADSyncSyncCycle Delta)
  • Once this successfully has happened, you can find an entry in the AD Connect tool similar to the one highlighted below:

• And the new object will also be visible via Microsoft Graph:

• From this stage on and after succesful Intune enrollment, you will have duplicate objects in Azure AD. This is expected.

Gotchas

I will update these findings as I have them available. I need to reproduce them in order to do proper screenshots and have the correct details.

For now, I’m going to leave you with these in headlines:

Co-management work loads

While Co-management indeed is possible by installing the Configuration Manager client as documented above, I failed to get the work loads that I’m currently managing with Intune, to switch back to Intune.

All the Configuration Items yields Not Applicable indicating that this is not intended to work, though I’m simply guessing here. I need confirmation from Microsoft on this one. 🙂

Windows Security Baseline

If applying the Windows Security Baseline as it ships default in Intune to my Surface Pro X device, I was unable to launch any Office applications. I suspect Exploit Guard in this instance is the bad guy and doing something it’s not supposed to do. I confirmed that through the Windows Defender event logs, but why this is happening only for Surface Pro X is still a mystery. Also need confirmation from Microsoft on this. 🙂

Surface Recovery Media

If you for whatever reason needs to restore the Surface Pro X back to factory defaults, you need a Surface Recovery Media. Fun part is, you are supposed to create a bootable USB, but the Surface Pro X doesn’t have any USB ports. You need to acquire a USB to USB-C converter. I had to do that, as I during my insane testing ended in a situation where I needed to start fresh (not enrolled into Intune NOR Azure anymore).

Stay tuned – I will update this post with more details 🙂