Modernizing Endpoints - Installing CM Client on AADJ Device

Introduction:

In this blog we will discuss a specific use case that I came across while working with a Community College. The college wanted to simplify their Windows provisioning. They had a lot of apps built in their ConfigMgr environment. This is when we took advantage of the co-management capability offered by Windows Autopilot in connecting a pure Azure AD joined PC with ConfigMgr without using Cloud Management Gateway (CMG) or Hybrid Domain Join.

 

The other reason I wanted to write this blog is, searching the internet for Autopilot and co-management, brings results using CMG. Here I wanted to share the experience of implementing the solution without using CMG. Of course, this comes with its own caveats. Since we are not using CMG, the clients connecting to ConfigMgr must be within the network with line of sight to your Domain Controller and ConfigMgr site systems.

 

Other unsupported scenarios that are common for with/without CMG:

• Hybrid Azure AD Join
• Only supports User driven scenario, does not support self-deploying & Pre-provisioning.

 

The benefits of using this method:

• If you have a task sequence with a list of apps that you want to install in a specific order. You can take advantage of this method and add it as one of the apps during Autopilot process.
• This method can also be useful when you have a lot of apps already built on ConfigMgr and you want to use them during Autopilot and do not want to rebuild them on Intune immediately.
• You also get to use all the rich reporting you are already using in ConfigMgr.

 

Pre-requisites:

• Windows 11 or at least Windows 10 20H2 (with latest CU)
• Configuration Manager with co-management enabled.

 

Implementation Steps:

Having discussed the use cases, benefits, and unsupported scenarios, let us see how to implement it.

 

• First, we start building a co-management authority profile within the Intune portal.

              Devices > Windows > Windows Enrollment > Co-management authority

 

• Give a name for the profile.

 

• Add the command line.

 

 

Format: CCMSETUPCMD="/mp:<<FQDN name>> SMSSITECODE=RTL SMSMP=<<FQDN name>> DNSSUFFIX=<<Domain name>>"

 

You can get command line from a couple of places, depending on your ConfigMgr setup.

 

Option 1: Use Cloud Attach properties.

ConfigMgr console > Administration > Overview > Cloud Services > Cloud Attach > Enablement tab.

You can use this option if you have configured CMG. In my case, I have not configured CMG, so the command line is not visible here.

 

Option 2: Use Client installation properties

ConfigMgr Console > Administration > Site Configuration > Sites > Settings > Client Push Installation Properties > Installation Properties

 

Note: Additionally, you can also include the parameter “PROVISIONTS” for starting a task sequence after installing the ConfigMgr client.

 

You can find more details on client installation properties here,

https://learn.microsoft.com/en-us/mem/configmgr/core/clients/deploy/about-client-installation-properties

 

• Coming back to the Co-management Authority profile settings page. Now you must choose the option under advanced settings whether to “Override co-management policy and use Intune for all workloads”

 

If you choose “Yes” then all the workloads that you opted for will be controlled by Intune.

 

Note: Even with the toggle switch set to ON and Intune controls all the workloads. ConfigMgr & Intune apps can still be deployed to the devices in parallel.

Note: Don't change this setting after device provisioning. It will apply to existing devices in the assigned group, not just new devices running the Autopilot process. Because of policy synchronization timing, the behavior of the policy change is non-deterministic, thus should be avoided.

 

• Next make sure to deploy this to a device group.

Note: Similarly, deploy Enrollment Status Page with the option to “Show app and profile configuration progress” and Autopilot user driven profile to the device group that this device is part of instead of user group.

 

• When you start the Autopilot setup process on the device, in the Device Setup phase in ConfigMgr client gets installed using the specified parameter.

 

• On the ConfigMgr console, the client PC shows up as Workgroup computer. Because of that, typically ConfigMgr admin is required to approve the device.

 

There are 2 ways you can approve this,

 

Option 1: Manually

By right clicking on the device and selecting “Approve”

 

Option 2: Automatically

ConfigMgr Console > Administration > Site Configuration > Sites > Hierarchy Settings > Client Approval & Conflicting Records.

Here you will have the option to approve workgroup computers manually or automatically.

 

Once the client is approved, it becomes active in ConfigMgr console.

 

On the Intune portal, you can see that ConfigMgr agent is healthy.

 

On the Azure AD portal, you can see that the device is Azure AD joined.

 

 

• These devices may not be part of the ConfigMgr boundaries that you have already configured.

Configure a boundary such that the AAD joined PC subnets or IP range is part of a ConfigMgr boundary and assign them to a boundary group.

 

Now you get the benefit of both worlds (ConfigMgr & Intune) on an Azure AD joined PC.

Hope the information is useful!!!

 

References:

https://learn.microsoft.com/en-us/mem/configmgr/comanage/quickstart-autopilot

https://learn.microsoft.com/en-us/mem/configmgr/comanage/autopilot-enrollment?source=recommendations

https://learn.microsoft.com/en-us/mem/configmgr/comanage/autopilot-enrollment