Hybrid Deployment (The Transition Path)

Architecture Overview

Windows Hello for Business GPO

Windows Hello for Business deployed by GPO allows the background Intune enrollment process to still meet the MFA requirements of an "all resources" MFA Conditional Access policy.

Entra Hybrid Join & Coexistence With Entra Join

Best practice is Entra Hybrid Join for existing machines where we want to preserve user profiles. New machines get new profiles anyway so can start to employ Entra Join. Once all users have gone through their hardware refresh cycle, the company is 100% Entra Joined.

Intune Enrollment GPO

Hybrid Entra Joined machines are directed to enroll in Intune by an AD GPO (Entra Joined machines enroll in Intune directly).

Conditional Access for Hybrid Join

Since we are deploying Windows Hello for Business before Intune enrollment, we don't need to create an exception in our MFA Conditional Access policies for the Microsoft Intune Enrollment app.

Implementation Checklist

Microsoft endpoint management tends to be asynchronous. Machine checks in, something happens, machine checks in again, the next step happens. This leads to latency in policy application. Two approaches to these latencies are illustrated below. I tend to be the guy on the left and want to see my changes right away. This deployment and troubleshooting is written from that perspective - providing the commands to push the process along. Once initial deployments are complete, a more relaxed approach can make sense.

Phase 1: Address Third Party Software

Third party encryption and antivirus can interfere with BitLocker and Defender for Endpoint.

[ ] Third Party Encryption:
- Decrypt third party encrypted disks and uninstall third party encryption software.
- Otherwise, exclude this machine from BitLocker encryption to avoid double encryption.
[ ] Third Party Antivirus:
- Uninstall third party antivirus software.
- Otherwise, Defender for Endpoint in passive mode can coexist with third party antivirus.
  - Windows 10 & 11 (Automatic): Defender automatically flips to Passive Mode.
  - Windows Server (Manual): Set registry to force Passive Mode before MDE onboarding.
    - Path: HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection
    - Name: ForceDefenderPassiveMode
    - Type: REG_DWORD
    - Value: 1

Phase 2: Create DNS Discovery Records

Before a device can enroll in Intune, it needs to know where to find your specific Intune cloud environment. It does this by asking the public internet for directions using your company's domain name (e.g., user@contoso.com).

You must create two CNAME (Canonical Name) records in the public (and private) DNS settings for your domain (usually managed wherever you bought your domain, like GoDaddy, Cloudflare, or Network Solutions).

You must create these two records for every email domain your users sign in with (e.g., if users sign in with @contoso.com and @contoso.net, you need to create these records on both domains).

First DNS Record: Entra Hybrid Join

Entra Hybrid Join requires the device to receive instructions from an authoritative source in Active Directory. This either takes the form of a Group Policy Object (GPO) or a Service Connection Point (SCP). This conveys the intention of a trusted admin to manage settings on this device.

Host Name	`enterpriseregistration`.[yourdomain.com]
Record Type	CNAME
Value	`enterpriseregistration.windows.net`
Purpose	Tells the device where to register its identity in Entra ID.

Second DNS Record: Intune Autoenrollment

Why Clients Fail Here

If these CNAME records are missing, Phase 3 (joining the domain) might succeed, but Phase 5 (Intune Enrollment) will silently fail. The device will be joined to the network, but it will be "blind" to the Intune management servers.

GCC High
Commercial

Host Name	`enterpriseenrollment`.[yourdomain.com]
Record Type	CNAME
Value	`enterpriseenrollment-s.manage.microsoft.us`
Purpose	Tells the device where the GCC High Intune enrollment server is located.

Host Name	`enterpriseenrollment`.[yourdomain.com]
Record Type	CNAME
Value	`enterpriseenrollment-s.manage.microsoft.com`
Purpose	Tells the device where the Commercial Intune enrollment server is located.

Phase 3: Entra Hybrid Join

Entra Hybrid Join takes several steps and line-of-sight to a domain controller (may need VPN).

[ ] Entra Hybrid Join Targeted Deployment:
- GPOs allow you to create a targeted Entra Hybrid Join deployment.
- gpupdate /force to sync GPOs to this device
- gpresult /r /scope computer to see what GPOs have been applied to this device
- These are the registry keys applied by this GPO:
  - HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD\TenantId
  - HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD\TenantName
[ ] Entra Connect:
- Entra Connect needs to be configured for Entra Hybrid Join.
- Synchronization Service Manager provides a real-time view of adds, updates, and deletes.
[ ] Entra Hybrid Join Process:
- A: User sign-in triggers Automatic Device Join task.
  - Task Scheduler Library > Microsoft > Windows > Workplace Join
  - Right-click the task named Automatic-Device-Join and select Run.
  - Alternatively, you can type dsregcmd /join.
  - You can see the results in Event Viewer
    - Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin
    - Event ID 304 ("The registration of the device was successful").
    - Event ID 305 (Registration failed). ex: 0x801c001d (SCP missing)
- B: Task queries AD for service connection point (or registry for our targeted deployment).
  - CRITICAL: May fail if VPN/Line-of-Sight is missing.
  - CRITICAL: Fails if device can't resolve enterpriseregistration.windows.net via public DNS.
```
# If using SCP (and not a targeted deployment) run this to see what your computers see in AD.
$scp = Get-ADObject -Filter 'objectClass -eq "serviceConnectionPoint" -and name -eq "62a0ff2e-97b9-4513-943f-0d221bd30080"' -SearchBase (Get-ADRootDSE).configurationNamingContext -Properties keywords
$scp.keywords
```
- C: Task creates a self-signed certificate and writes it to the computer object in AD.
- D: Entra Connect detects and writes certificate to Azure DRS which (eventually) writes to Entra.
  - Synchronization Service Manager will display the computer object being sync'd to Entra.
  - The device will now show as "Pending" in the Entra Portal.
    
    Devices Stuck In Pending
    There is a common issue where an old "Entra Registered" (BYOD) record exists for the same machine.
    Suggestion: If a device is stuck in "Pending," the admin should check for a duplicate "Entra Registered" record with the same name. If one exists, it can sometimes block the "Hybrid Joined" record from completing the handshake. Run dsregcmd /debug /leave as SYSTEM to clear the local state before retrying.
- E: Task keeps retrying until step D is complete and Entra issues an ID token to the computer.
- F&G: Task processes ID token and sends cert request to DRS which returns cert and updates Entra.
  - The device status in the Entra Portal will now change from "Pending" to a joined date and time.
- H: Device registration completed and task exits.
  
  Once the background registration tasks finish, you must verify that the device has not only joined the directory but has also successfully "discovered" the Intune management endpoints.
  1. Run the Verification Command: Open a Command Prompt and type: dsregcmd /status
  2. Verify Identity & Auth State: In the Device State and User State sections, confirm the following:
    - AzureAdJoined : YES — The device has a unique identity in Entra ID.
    - DomainJoined : YES — The device maintains its anchor to your local Active Directory.
    - AzureAdPrt : YES — CRITICAL. This "Primary Refresh Token" is the secret sauce. Without a YES here, the "Silent" Intune enrollment in Phase 5 will fail because the device cannot authenticate to the service without prompting the user.
  3. Verify Discovery & GCC High Endpoints: Scroll down to the Tenant Details section. This is where you verify that the device "sees" your sovereign cloud tenant:
    - GCC High
    - Commercial
    MdmUrl: Must point to https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
    
    MdmTouUrl: Must point to https://portal.manage.microsoft.us/TermsofUse.aspx
    
    Critical Sovereign Check
    If MdmUrl points to a .com address, the machine is attempting to enroll in Commercial.
  4. Troubleshooting Discovery (The DNS Link):
    - If the MDM URLs are blank: The device identity is registered, but it is "blind" to the Intune service.
    - The Check: Verify your Public DNS (and Internal DNS if split-brain) contains the following CNAME record for every UPN suffix in use:
      GCC High
      Commercial
      Host Name enterpriseenrollment.[yourdomain.com]
      Record Type CNAME
      Value enterpriseenrollment-s.manage.microsoft.us
      Purpose Tells the device where the GCC High Intune enrollment server is located.
    - The Scope: Ensure the user's account is included in the MDM User Scope under Entra ID > Mobility (MDM and MAM) > Microsoft Intune.
  5. Success Indicator (Entra Portal): In the Entra Admin Center, the device record should move from a "Pending" status to displaying a specific Join Type (Microsoft Entra hybrid joined) with a valid Registered date and time.

Phase 4: Windows Hello for Business

WHFB enables the background GPO Intune Enrollment process to satisfy MFA required by CA policies. This process kicks off automatically during the same login processes that push the Entra Hybrid Join process along. Given that, we should have all our Entra Hybrid Join, Windows Hello for Business, and Intune Autoenrollment ducks in a row as it will all happen during the login process.

[ ] PowerShell to Configure Cloud Kerberos Trust
- Run Set-AzureADKerberosServer on the Entra Connect server. This creates a read-only computer object in your AD that acts as a "Kerberos proxy" for Entra ID.
[ ] Windows Hello for Business GPO: set these settings
- Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business
  - Use Windows Hello for Business: Enabled
  - Use cloud Kerberos trust for on-premises authentication: Enabled
  - Use a hardware security device: Enabled
[] The Primary Diagnostic: dsregcmd /status
- Run this command from a standard command prompt as the logged-in user. Running as an elevated Administrator will retrieve the system's context instead of the user's.
- Ngc Prerequisite Check: If any of these say NO, that is the reason WHFB will not provision.
  - IsDeviceJoined: Verifies that the computer is successfully registered with Entra ID (Azure AD). It must be either "Entra ID Joined" or "Hybrid Entra ID Joined." If the device is strictly on-premises with no cloud registration, WHfB cannot link the hardware credential to the cloud directory.
  - IsUserAzureAD: Verifies that the user currently logged in has an identity that is synced to or exists in Entra ID, and that their current login session successfully obtained a Primary Refresh Token (PRT). A local-only admin account or an Active Directory user that hasn't successfully authenticated to the cloud will show "NO".
  - PolicyEnabled: Confirms that the Windows Hello for Business policy is explicitly turned ON for this machine or user. If your GPO applied but this says "NO," it means a conflicting policy (perhaps an MDM policy from Intune or a local registry key) is overriding your Domain GPO and disabling it.
  - PostLogonEnabled: Checks if the system is allowed to prompt the user to enroll immediately after they type their password and reach the desktop. Most organizations leave this enabled. If it is disabled, users must manually go into Windows Settings > Accounts > Sign-in options to set up their PIN.
  - DeviceEligible: Evaluates whether the physical hardware meets the security requirements dictated by your policy. Most commonly, this checks for a functional TPM (Trusted Platform Module) chip. If your policy is set to "Require Hardware TPM" and the machine is a VM without a virtual TPM (or has a disabled physical TPM), this will flag as "NO".
  - SessionIsNotRemote: Confirms the user is physically sitting at the console. You cannot provision Windows Hello for Business over a standard Remote Desktop Protocol (RDP) session.
  - CertEnrollment: This is highly dependent on your trust model (Key Trust, Certificate Trust, or Cloud Trust). It checks if the environment is ready to issue the necessary credential. If you are using the Certificate Trust model, it verifies that the client has a line of sight to the Certificate Authority and the permissions to request a WHfB certificate.
  - PreReqResult: This is the final verdict. It aggregates the required fields above. If everything aligns, it will say Will Provision, meaning the prompt is authorized to launch. If any critical prerequisite fails, it will say Will Not Provision.
- User State: If NgcSet says NO, the user does not currently have a WHfB container/PIN configured.
- SSO State: If AzureAdPrt : NO the users does not have a valid Primary Refresh Token (PRT) from Entra ID and provisioning will silently abort.
[] Event Viewer: User Device Registration Logs
- Windows explicitly logs exactly why WHfB provisioning decided to skip the prompt during the user's login sequence.
  - Open Event Viewer and navigate to: Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin.
  - Look for Event ID 358 (Provisioning will be launched) or Event ID 360 / 362 (Provisioning will NOT be launched).
  - Open the details of these events. The description contains a yes/no checklist of the prerequisites. Look for the "No" (e.g., "User has logged on with AAD credentials: No" or "Windows Hello for Business policy is enabled: No").
[] Event Viewer: HelloForBusiness Logs
- If provisioning starts but encounters a silent failure (hardware TPM issue, a broken container), the errors will be recorded here.
- Navigate to: Applications and Services Logs > Microsoft > Windows > HelloForBusiness > Operational.
- Look for errors, warnings, or Event ID 7055 related to container creation or TPM communication.
[] Common Silent Blockers to Verify: Even with a perfectly applied GPO, these environmental factors will prevent the screen from appearing:
- Missing MFA Registration: WHfB requires the user to perform a Multi-Factor Authentication claim during setup. If the user has not registered their security info for Entra ID MFA, the prompt will skip.
- Registry Conflict: Verify the GPO is actually writing the intended keys. Check HKLM\SOFTWARE\Policies\Microsoft\PassportForWork to ensure UsePassportForWork is set to 1. Additionally, ensure a conflicting disabled policy hasn't been written to the HKCU (Current User) path, which can override the computer policy.
- Intune/MDM Overrides: If this device is co-managed, check if an Intune policy or a default compliance setting is explicitly disabling WHfB, as MDM policies can sometimes win out over local GPOs.

Phase 5: Intune Enrollment

Entra Hybrid Join and Windows Hello for Business prepares machines for Intune enrollment.

⚡Performance Tip: Use Filters vs. Groups + Stop Waiting For Groups

When you are in the "Frenzied Deployment" phase, waiting 2-24 hours for an Entra ID Dynamic Group to calculate membership is painful.

Best Practice: Target your policies to "All Devices" and use Intune Filters (e.g., device.model -startsWith "Surface") to include/exclude machines.

Why: Filters are evaluated by the Intune engine at check-in time (milliseconds), whereas Dynamic Groups rely on the background Entra ID sync cycle (hours).

[ ] Verify Licensing:
- Does the user logging in have an Intune Plan 1 (or M365 G3/G5) license assigned active?
[ ] Entra Configuration for Intune Enrollment
- Entra ID > Mobility (MDM and MAM) > Microsoft Intune.
- MDM User Scope: Set to All (or includes the specific user).
- WIP User Scope: Set to None. (Critical! If set to All, enrollment often defaults to MAM).
[ ] Intune Enrollment GPO:
- Computer Configuration > Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Microsoft Entra credentials
- To verify GPO application: run gpresult /r /scope computer.
  - Look for policy named as above.
[ ] Task Scheduler:
- Microsoft > Windows > EnterpriseMgmt and find the MDM enrollment task
- You can check last run result for any errors
[ ] Event Viewer Error Checking:
- Check Event Viewer: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.
- Look for Event ID 76 indicating failure (Example: 0x8018002A due to missing MFA claim).
- Example Root Cause: Missing Primary Refresh Token (PRT).
- Example Fix: Ensure user has signed into Windows Hello for Business or a Microsoft 365 App (Teams/Outlook) to acquire a PRT.
[ ] Manual Intune Enrollment
- If the device shows as "Managed by MDE" in the portal, enrollment has failed.
- Force Retry Command:
```
%windir%\system32\deviceenroller.exe /c /AutoEnrollMDM
```
  - Note: This command produces no output. Check Task Manager to see deviceenroller.exe running briefly, or refresh the Event Viewer log after 30 seconds."
- Force Policy Sync (UI Method):
  - If the Info button is present (see above), click it.
  - Scroll down to Device sync status.
  - Click the Sync button.
  - Why: This forces the device to reach out to Intune immediately for the latest policies, scripts, and app installs without waiting for the scheduled background cycle.
- Success Indicators:
  - Visual Verification (The "Info" Button)
    - Open Settings > Accounts > Access work or school.
    - Click the connected domain/account (e.g., connected to contoso.com).
    - Success: You see an Info button. This confirms the device is MDM enrolled.
    - Failure: You only see a Disconnect button. This usually means the device is Entra Registered but not Intune Enrolled.
  - Run dsregcmd /status
    - User State
      - WamDefaultSet: YES
      - WamDefaultAuthority: organizations

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.

Architecture Overview​

Windows Hello for Business GPO​

Entra Hybrid Join & Coexistence With Entra Join​

Intune Enrollment GPO​

Conditional Access for Hybrid Join​

Implementation Checklist​

Phase 1: Address Third Party Software​

Phase 2: Create DNS Discovery Records​

First DNS Record: Entra Hybrid Join​

Second DNS Record: Intune Autoenrollment​

Phase 3: Entra Hybrid Join​

Phase 4: Windows Hello for Business​

Phase 5: Intune Enrollment​