Microsoft MD-102: Co-management and Hybrid Environments — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Part of the Microsoft Endpoint Administrator Associate MD-102 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Co-management and hybrid environments let you combine Configuration Manager (ConfigMgr) with Microsoft Intune to modernize Windows management at your own pace. Co-management enables workload-by-workload transition, while hybrid Azure AD join creates a unified device identity in both on-premises Active Directory and Azure AD. Azure AD Connect synchronizes identities and devices, and Cloud Attach features such as the Cloud Management Gateway (CMG) and tenant attach extend ConfigMgr to the cloud and Intune admin center for internet management and a unified console. Planning must address prerequisites, identity, synchronization, policy precedence between Group Policy and Intune MDM, and staged workload switching to avoid conflicts.

Co-management architecture and enrollment

Co-management integrates the ConfigMgr client with Intune MDM on Windows 10/11. It requires ConfigMgr current branch (1710+; use a supported recent release), an Intune subscription with MDM authority set to Microsoft Intune, an Azure AD tenant linked to your ConfigMgr site, and Windows 10 version 1709 or later or Windows 11. Devices should be hybrid Azure AD–joined or Azure AD–joined so the ConfigMgr client can acquire Azure AD tokens.

Enrollment flow for existing ConfigMgr clients uses the co-management wizard in the ConfigMgr console to connect the site to your Azure AD tenant and configure automatic MDM enrollment for a target collection. The client receives policy with the tenant information, uses its Azure AD device identity to request an MDM enrollment token, and enrolls into Intune without user interaction. This auto-enrollment supports devices with or without user affinity; it does not require the end user to trigger enrollment. Ensure:

Azure AD Connect is synchronizing device objects and user identities as appropriate.
Automatic MDM enrollment is configured in Azure AD mobility settings and Intune licenses are assigned.
The device has line-of-sight to domain controllers at least once to complete hybrid Azure AD join, or is Azure AD–joined via provisioning.

After enrollment, the device has two management channels: the ConfigMgr client and the Intune MDM channel. You control which feature areas (workloads) are managed by which service. Use pilot collections to validate before switching all devices. Keep a clear configuration ownership model to avoid duplicate enforcement.

CMG and tenant attach are complementary but independent. CMG provides internet-based client connectivity for ConfigMgr, while tenant attach uploads ConfigMgr device metadata to the cloud and exposes real-time actions in the Intune admin center. Both are part of a cloud-attach posture that reduces dependency on on-premises network reachability.

Workloads, switching strategy, and policy domains

Workloads represent management domains that can be controlled by ConfigMgr or Intune. You can set each workload to:

ConfigMgr: ConfigMgr is the owner and enforces policy.
Pilot Intune: A defined pilot collection is managed by Intune; others remain with ConfigMgr.
Intune: All co-managed devices are managed by Intune for that workload.

Key workloads and guidance:

Compliance policies: Switch this workload early to Intune so device compliance is evaluated in Intune and can be used with Azure AD Conditional Access. Define compliance settings (e.g., PIN, encryption, OS version) and remediation via Intune. Do not configure overlapping compliance baselines in ConfigMgr for the same conditions.
Device configuration: This covers MDM profiles such as device restrictions, VPN, Wi-Fi, certificates, and ADMX-backed settings. When switching to Intune, remove or disable overlapping ConfigMgr configuration baselines for pilot devices to avoid churn. Use Settings Catalog or Templates in Intune and prefer Endpoint security profiles for security controls.
Endpoint protection: Coordinates Windows Defender Antivirus, Firewall, SmartScreen, and BitLocker. Use Intune Endpoint security policies when the workload is with Intune. If ConfigMgr previously deployed Endpoint Protection or BitLocker management, retire those policies for pilot devices and confirm there is a single authority per control.
Client apps (Win32) and Microsoft 365 Apps: If you move Win32 app deployment to Intune, ensure the Intune Management Extension is present and use app requirements and dependencies to control order. Avoid dual-targeting the same app from both ConfigMgr and Intune. For Microsoft 365 Apps, manage installation and update configuration from a single authority to prevent channel conflicts.
Software updates and Windows Update policies: If Software Updates stay with ConfigMgr, the client continues to scan against WSUS/SUP and can use CMG on the internet. If switching to Intune, configure Windows Update for Business (WUfB) policies in Intune and disable ConfigMgr Software Updates for those devices. Do not mix ConfigMgr updates with WUfB on the same device.
Resource access: VPN, Wi-Fi, email profiles should be owned by one system. Intune is usually preferred for cloud-first, identity-based provisioning of resource profiles.

Switch in stages. Start with Compliance, then Device Configuration or Endpoint Protection, then Apps and Updates. Use pilot collections and report on drift and conflicts before moving “All”.

Hybrid Azure AD Join and Azure AD Connect

Hybrid Azure AD join creates a single device identity represented in both on-premises AD and Azure AD. It is required for seamless SSO, Conditional Access device-based policies for domain-joined computers, and for co-management enrollment using device credentials. Prerequisites include:

An on-premises AD forest and an Azure AD tenant.
Azure AD Connect configured to synchronize device objects and the required device registration settings.
Network egress to Azure AD device registration endpoints and line-of-sight to a domain controller during initial registration for Windows 10/11.
Proper UPN and DNS suffix configuration so devices can authenticate to Azure AD.

Azure AD Connect is the synchronization engine between on-premises AD and Azure AD. Core configuration considerations:

Scope and filtering: Use OU or attribute-based filtering to include users, groups, and devices that must exist in Azure AD. Keep scope minimal and well-defined.
Sign-in method:
- Password hash synchronization (PHS): Hashes are synchronized at regular intervals. Azure AD validates sign-ins using the synchronized hash. This is the most resilient and lowest complexity option; it supports seamless single sign-on and provides a cloud authentication fallback if on-premises infrastructure is unavailable.
- Pass-through authentication (PTA): A lightweight agent installed on one or more servers validates passwords directly against on-premises AD in real time. Use PTA if policy prohibits storing password hashes in the cloud or if you need to enforce on-premises sign-in policies. Deploy multiple agents for high availability.
- Federation (AD FS): Use only if you require advanced claim rules or smartcard/third-party MFA scenarios not supported by PHS/PTA. It introduces more complexity and dependencies.
Device registration: In Azure AD Connect, enable the device options wizard to configure hybrid Azure AD join for your forest. Ensure service connection point (SCP) is set in AD so devices discover the Azure AD tenant. Down-level OS prerequisites are not needed for Windows 10/11.
Staging and HA: Consider staging mode for backup servers and use export/import for configuration. Monitor synchronization health via Azure AD Connect Health.

Correctly configured hybrid join ensures devices can acquire Azure AD device tokens, enabling co-management auto-enrollment and cloud-based policy enforcement.

Policy precedence: Group Policy vs Intune MDM

When Group Policy Objects (GPOs) and Intune MDM policies target the same setting, default precedence varies by setting and implementation. In general, traditional GPOs win for overlapping registry-based settings because they are applied by the Group Policy engine at refresh intervals. To support modern management, Windows 10 version 1709 and later introduced the ControlPolicyConflict policy to prefer MDM for supported Policy CSP areas.

Key practices to manage precedence and avoid conflicts:

Establish ownership per setting. Do not configure the same setting in both GPO and Intune. Migrate in blocks and decommission GPOs once equivalent MDM policies are in place.
Use the “MDM wins over GPO” control when available. Deploy the Policy CSP ControlPolicyConflict setting (MDMWinsOverGP) via Intune to instruct Windows to prefer MDM Policy CSP over GPO for supported categories. Many ADMX-backed settings exposed through Intune Administrative Templates honor this control, but not all do.
Prefer Endpoint security policies in Intune for Defender, Firewall, and BitLocker because they use supported CSPs with clear conflict handling and reporting.
Validate with diagnostics. Use the built-in MDM Diagnostic Report (ms-settings:workplace, then Export) and GPResult/Resultant Set of Policy to identify overlaps. Review the Intune per-setting report and ConfigMgr/GPO compliance baselines to detect conflicts.
Sequence the migration. Start by moving device configuration that has a 1:1 CSP mapping, enable MDM wins over GPO for those categories, verify outcome, then unlink or disable the corresponding GPOs.

For co-managed devices, also ensure ConfigMgr configuration baselines or Endpoint Protection settings are not duplicating the same controls as Intune policies. A single authoritative source per control avoids unpredictable outcomes.

Cloud attach: CMG and tenant attach

Cloud Management Gateway (CMG) allows ConfigMgr to manage internet-based clients without requiring VPN. CMG runs in Azure as a PaaS service (preferred on Virtual Machine Scale Sets) and proxies client communication to your on-premises site via the CMG connection point. Capabilities include client policy, hardware/software inventory, app deployments, scripts, CMPivot, and Software Updates when clients are configured for internet-based management. Core requirements and design points:

Azure subscription and resource group, with the ConfigMgr site linked to your Azure AD tenant.
Certificates and authentication: Use Azure AD authentication for clients when your devices are hybrid/Azure AD–joined and your site uses Enhanced HTTP. PKI client authentication certificates remain supported but increase complexity.
On-premises roles: Deploy a CMG connection point and ensure service connection point online for cloud connectivity.
Cost and capacity: Size instances for expected concurrent connections and content throughput; monitor usage to optimize costs.
Content: Use CMG for policy and update scanning. For content distribution, combine with cloud distribution points or enable content over CMG as supported by your site version.

Tenant attach surfaces ConfigMgr device inventory and actions in the Microsoft Intune admin center without requiring co-management. When you enable “Upload to Microsoft Endpoint Manager admin center,” devices appear under Devices in the Intune portal with ConfigMgr as the management authority. You can perform actions such as:

Run CMPivot queries and Scripts
View Resource Explorer–like data and device timeline
Install available applications from ConfigMgr
Initiate client actions (based on version and permissions)

Tenant attach integrates Azure AD/Intune RBAC with ConfigMgr RBAC. For internet clients, real-time actions require CMG; for intranet clients, actions flow through on-premises management points. Tenant attach complements co-management by giving a unified cloud console and enabling helpdesk tasks without granting access to the ConfigMgr console.

Practical Problem Scenario

Contoso, Ltd. has 5,000 Windows 10/11 devices managed by Configuration Manager across multiple sites. Remote work increased, and many devices rarely connect to VPN. Contoso wants to enforce Conditional Access based on device compliance, move security controls to the cloud, and manage internet-based devices without relying on VPN, while avoiding a big-bang migration.

Establish identity and device foundation

Enable hybrid Azure AD join via Azure AD Connect for all domain-joined devices and verify device objects in Azure AD. Choose Password Hash Synchronization for resilient, low-maintenance sign-in and enable Seamless SSO.
Why: Hybrid join provides Azure AD device identity and tokens needed for co-management auto-enrollment and Conditional Access. PHS simplifies operations and provides a cloud fallback.

Configure co-management with staged enrollment

In ConfigMgr, run the Co-management wizard to connect the site to the Azure AD tenant and target a pilot collection for automatic MDM enrollment into Intune.
Why: Co-management adds the Intune MDM channel without reimaging or user action, letting Contoso move workloads gradually.

Switch the Compliance policies workload to Intune (Pilot → All)

Create Intune compliance policies reflecting Contoso baselines (encryption, Defender, OS versions) and enable Conditional Access policies requiring compliant devices for Microsoft 365.
Why: Intune is the compliance authority that integrates with Azure AD Conditional Access; switching this workload enables secure access control.

Deploy Endpoint security via Intune; retire overlapping ConfigMgr EP

Create Endpoint security policies for Defender Antivirus, Firewall, and BitLocker in Intune and move the Endpoint protection workload to Intune for the pilot. Disable equivalent ConfigMgr antimalware and BitLocker settings for the pilot collection.
Why: Intune Endpoint security uses CSPs optimized for modern management and provides clear reporting and CA alignment.

Migrate device configuration to Intune with conflict control

Create Settings Catalog profiles for device restrictions, Wi-Fi, and certificates. Deploy the MDMWinsOverGP control policy where supported, validate on pilots, then unlink corresponding GPOs.
Why: Ensures a clean ownership transition and avoids policy churn from overlapping GPOs and MDM.

Implement Cloud Management Gateway

Deploy CMG using Azure AD authentication and Enhanced HTTP, and add a CMG connection point. Verify internet-based clients receive policy, inventory, and software updates.
Why: CMG provides ConfigMgr management and updates over the internet for devices that do not use VPN, maintaining continuity during migration.

Enable tenant attach for unified operations

Configure “Upload to Microsoft Endpoint Manager admin center” to surface ConfigMgr devices in the Intune portal. Grant helpdesk staff appropriate Intune roles to run CMPivot and install apps.
Why: Tenant attach consolidates day-to-day actions in a web console, reducing reliance on the full ConfigMgr console and improving remote troubleshooting.

Expand workloads and decommission legacy controls

Move Device configuration and Client apps to Intune in phases. For Windows Update, evaluate moving to Windows Update for Business or keep Software Updates in ConfigMgr where CMG suffices. Retire overlapping GPOs and ConfigMgr baselines as ownership transfers.
Why: A phased approach reduces risk, keeps devices secure throughout, and aligns with Contoso’s cloud-first goals while preserving necessary on-premises capabilities during transition.

← Identity · All domains · Windows Lifecycle and Update Management →

Practice these questions → · Timed practice on ExamRoll.io →