Understanding hybrid Azure AD join and co-management
Published Mar 18 2021 02:48 PM 116K Views

As we talk with our customers that are using Microsoft Endpoint Manager to deploy, manage, and secure their client devices, we often get questions regarding co-managing devices and hybrid Azure Active Directory (AD) joined devices. Many customers confuse these two topics – the first is a management option, while the second is an identity option. In this blog, I hope to clear up any confusion and give guidance and scenarios on how to use both to manage and protect your devices.

Let’s start with the basics: management

Microsoft Endpoint Manager is the combination of Configuration Manager – the on-premises management tool that you’ve been using for decades - and Microsoft Intune – the cloud-based management solution used for modern device security and management. Endpoint Manager’s goal is unifying both of your management solutions and bringing the power of the cloud to your entire endpoint estate.

To accomplish this goal, we first launched tenant attach to provide an easy and low-risk path to cloud attach your Configuration Manager infrastructure to your Intune tenant. This is an on-premises to cloud attachment like you’ve seen before when connecting your Exchange Server on-premises infrastructure to Exchange online and sync’d those mailboxes, and when you connected Active Directory to Azure Active Directory and sync’d those user accounts and other objects. Tenant attach is the same idea: attach the Configuration Manager infrastructure to Intune and sync the Windows 10 Configuration Manager managed devices to the cloud-based Intune tenant. Creating this connection brings the value of remote actions and analytics, immediately.

During or after the initial attachment, you can start moving certain workloads from Configuration Manager to Intune, either one at a time or en masse. You choose the path that’s right for you. Co-management is the act of moving workloads from Configuration Manager to Intune and telling the Windows 10 client who the management authority is for that particular workload. For example, you might move Compliance Policies and Device Configuration workloads to Intune while leaving all other workloads set to Configuration Manager. This tells the Windows 10 client to listen to Configuration Manager for app deployment and security policies, for example, while listening to Intune for compliance policies and device configuration policies.

Figure 1: Graphic representation of Microsoft Endpoint Manager, Configuration Manager, and Microsoft Intune.Figure 1: Graphic representation of Microsoft Endpoint Manager, Configuration Manager, and Microsoft Intune.

As you continue to modernize, continue moving workloads to Intune until you are managing everything in the cloud, or keep all of the workloads directed to Configuration Manager and stay on the tenant attach step. Or you can even start in Intune as cloud-native. With tenant attach and co-management, you choose the path and the end state.

Let’s start with the basics: identity

Active Directory Domain Services (AD DS) has been around since 2000, with the release of Windows 2000 Server. Traditionally, we join our Windows devices to Active Directory to take advantage of Group Policies, security settings, and even to give permissions to resources that are stored in a different Active Directory environment - either in the same Active Directory forest or a different forest. Devices can be joined to only one AD DS environment.

Like we said earlier, though, it’s possible to connect the on-premises AD DS environment to Azure Active Directory (Azure AD). When this connection is made, the devices that are joined to AD DS may then be registered in Azure AD. This connection and registration is known as hybrid Azure AD joined.

Figure 2: Diagram depicting a Hybrid Azure AD joined corporate laptop.Figure 2: Diagram depicting a Hybrid Azure AD joined corporate laptop.

Devices that are co-managed, or devices that are enrolled in in Intune, may be joined directly to Azure AD, or they may be hybrid Azure AD joined but they must have a cloud identity.

Our guidance

Not all devices in your organization need to be managed the same. Each device serves a different purpose, as such has different management and identity requirements. For example, new devices may not need to be joined to AD DS, and instead can be initially provisioned as Azure AD joined, being managed either by Intune natively or by co-management. Starting this device as hybrid Azure AD joined will introduce challenges later as you adopt more modern solutions, such as migrating user data, user profiles, and determining which group policies are assigned to the device. So before joining any new devices to AD DS and deciding on that hybrid approach, ask yourself, “Does this device need to be hybrid Azure AD joined? What are the benefits of joining this device to my AD DS environment?

Hybrid Azure AD joining a device is great for uplifting your existing AD DS joined devices, but Azure AD is the Microsoft recommended path for most new or repurposed devices, especially when using modern deployment tools like Windows Autopilot.


Many of our customers have been using AD DS for 20 years, joining client (and server) operating systems from Windows 2000, Windows XP, Windows 7, Windows 8/8.1, Windows 10, and everything in between (I’m looking at you Windows Vista!). Because of how long AD DS has been around, you may have Group Policy Objects (GPOs) that you need to leverage, or Win32 authentication, or other scenarios that will make moving to a pure Azure AD environment challenging. Let’s look at some of these scenarios and our guidance with each one.

Scenario #1: User profile migration


When a device is joined to Azure AD, it creates a new profile for the logged-on user, and does not reference any existing profiles. In a new device scenario, this won’t be an issue as there are no profiles yet on the endpoint. User profiles typically include the following local directories:

  • Local files in the Desktop, Documents, Pictures folders
  • Start menu and Taskbar customizations
  • Favorites
  • Browser settings
  • Cached credentials
  • Outlook cache and settings
  • Third-party app settings

But if the devices were previously AD DS joined or joined to its own workgroup, you may need a profile migration, as seen in the table below:

Original device state

Once joined to Azure AD

New or re-imaged/repurposed device

No profile migration needed

Local workgroup

User profiles need to be migrated

AD DS joined

User profiles need to be migrated

Table 1. User profile migration needs when joining a device to Azure AD.


Our guidance in the case where a user profile migration is needed is to:

  • Manually copy/paste to migrate profiles, or use a third-party profile migration tool
  • Re-map existing files and settings to the new profile
  • Preserve all cache settings
  • Use Enterprise State Roaming
  • Force synchronization of browser data
  • Moving your on-premises file shares to SharePoint Online
  • Use OneDrive for Business Known Folder Move

Scenario #2: Group Policy Objects


Though we are constantly adding configuration service providers (CSPs) settings that Windows supports into Intune and making configuration of settings easier for you, some of the GPOs that are configured on-premises may not have equivalent CSPs in Intune. These GPOs typically revolve around very specific user-based configurations, such as:

  • Start menu and Taskbar customizations
  • Desktop wallpaper and screensaver settings
  • Some registry settings
  • Other Group Policy Preferences


  • Run Group Policy Analytics to analyze these GPOs and determine your level of modern management support.
  • Do a thorough assessment of supported settings in MDM – do you still need them? Are there alternative technologies with higher security? Are the registry changes covered by a KB article? Is the policy still required? Do a hard rationalization with your team!
  • If you are setting Registry to configure apps, re-evaluate if the configuration is supported via ADMX (Administrative Templates).
  • Migrate those GPO settings that have equivalent CSPs to an Intune policy. For devices born in the cloud, use Security baselines to configure Windows 10 devices in Intune as these have recommended MDM configurations.
  • Re-evaluate the necessity of those GPO settings that do not have an equivalent CSP and report to us.

Scenario #3: Win32 apps and legacy authentication


Some Win32 apps have a need for some legacy form of authentication. Any apps that require AD DS machine authentication will not work.

The apps that work are the apps that support NT LAN Manager (NTLM), Modern Auth, and Kerberos TGT.


  • Once you have a better idea of who is using legacy authentication in your directory and which applications depend on it, the next step is upgrading your users to use modern authentication.
  • Migrate these apps to apps that support modern types of authentication.
  • Re-evaluate the necessity of AD DS machine authentication.
  • Get application compatibility assistance at no additional cost.

Scenario #4: Printing


Your users are using printers that are directly connected to their devices or that have a direct path in the Printer settings. And some may be using AD Printer Discovery to find the printer closest to them. Because there are many printer-type scenarios, consider the following in the table below:

Printer scenario


User has a printer directly connected

This will continue to work

User has a direct path to a printer

This will continue to work

User uses AD Printer Discovery

This will not work

Table 2. Printer scenarios when migrating a device to Azure AD.


  • Notify users of a direct printer path, when possible
  • Deploy a PowerShell script from Intune to map the printers
  • Best: Use Universal Print, our driverless cloud-based, print service


Hybrid Azure AD joining a device is a device identity scenario, which has your device joined to the on-premises AD DS domain, and registered in Azure AD. This is a good scenario when starting your identity and security migration from on-premises to the cloud.

Co-management is a device management scenario, which has your device being managed by both Configuration Manager and Microsoft Intune, with each being the management authority of specific workloads.

Consider the points in this table as our recommendations to realize the benefits of cloud management.




Cloud modernization

AD DS only

Configuration Manager + Tenant Attach

Operating System Deployment


Hybrid Azure AD joined

Tenant Attach + Co-management

Operating System Deployment


Azure AD only



Microsoft Intune

Windows Autopilot


Table 3. Recommended Windows client management strategy based on device Identity

As you start to move from your legacy AD DS and Configuration Manager environments, we’re here to help! Reach out to our FastTrack team and follow us on Twitter @IntuneSuppTeam! And bookmark the Microsoft Endpoint Manager community for more blogs and information on managing all of your devices, including iOS, iPad OS, macOS, Android, and Windows!


Version history
Last update:
‎Mar 18 2021 03:04 PM
Updated by: