Pre-provisioning hybrid join fails when a policy needs a domain controller (0x800706FD)

A technician runs the Autopilot pre-provisioning flow on a hybrid join device from a depot or home office, and it ends on the red failure screen. The event log on the device shows a policy merge failing with 0x800706FD, "The trust relationship between this workstation and the primary domain failed". In September 2026 Microsoft documented this as a known limitation of pre-provisioning with Microsoft Entra hybrid join. In this post I'll explain what the official entry says, how to find the policies that trigger it, and how to re-scope them so the technician flow succeeds.

Symptoms#

• The deployment uses pre-provisioning (the technician flow started with the Windows key pressed five times at the first OOBE screen) and the Autopilot profile joins devices as Microsoft Entra hybrid joined.
• The technician flow fails instead of reaching the green status screen with the Reseal button.
• The device's Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin event log contains an entry similar to the example Microsoft gives:

MDM PolicyManager: Merge string, Area: (UserRights), Policy: (DenyLocalLogOn), Result:(0x800706FD) The trust relationship between this workstation and the primary domain failed.

• The same profile and policies deploy fine when the technician flow runs inside the office on a network with a domain controller, or when the device goes through a plain user-driven hybrid flow.

Why it happens#

Microsoft's explanation is short and worth reading precisely. During pre-provisioning, an assigned policy can require the client device management (DM) stack to resolve a policy conflict by contacting an Active Directory domain controller. In the technician flow the device has no line of sight to a domain controller, so that resolution fails. In off-premises scenarios that depend on a bring-your-own (BYO) VPN, the VPN isn't available during the technician flow either, so the device can't resolve the policy state. The hybrid join documentation separately states that BYO VPN configurations aren't supported during pre-provisioning at all.

Three details help when you read the event:

• 0x800706FD is the HRESULT form of Win32 error 1789, ERROR_TRUSTED_RELATIONSHIP_FAILURE. In a pre-provisioned device the offline domain join blob has been applied but the device hasn't yet talked to a domain controller, so any operation that needs the domain trust fails with exactly this error.
• Area and Policy name the Policy CSP area and setting involved. Microsoft's example is UserRights/DenyLocalLogOn, the "Deny log on locally" user right.
• "Merge string" tells you the client was combining string-list values for the same setting from more than one source, which is what Microsoft means by conflict resolution. In my reading, user rights are the obvious candidate because their values are lists of accounts and groups, but Microsoft doesn't publish a list of affected settings, so treat anything beyond the documented example as something to verify in your own logs.

How to fix it#

Microsoft offers two ways out: don't assign policies that require domain controller connectivity during the technician flow, or pre-provision on a network that has line of sight to a domain controller. Here is how I'd work through it.

1. Collect the evidence from the failed device. On the red screen, press Shift+F10 and run mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\autopilot.cab, the command Microsoft documents for pre-provisioning. Open the DeviceManagement-Enterprise-Diagnostics-Provider Admin log from the cab and filter for Merge and 0x800706FD. Note every Area/Policy pair you find.
2. Map each pair to the Intune profile that sets it. User rights come from three places: the settings catalog category User Rights, security baselines that include a User Rights section, and custom OMA-URI profiles targeting ./Device/Vendor/MSFT/Policy/Config/UserRights/<setting>. Search your configuration profiles for the setting name, and remember that a baseline can set the same right as a settings catalog profile.
3. Remove the conflict where you can. Microsoft's wording points at conflict resolution, so if two profiles define the same user right, consolidate them into one profile with the full list of accounts. One source means nothing to merge. Device status for both profiles under Devices › Configuration will show Conflict on existing devices if this is your situation.
4. Keep the remaining policies out of the technician flow. The technician flow only delivers device-targeted configuration, because no user exists yet. Assigning the User Rights profile to the user group instead of the device group means it arrives in the user flow, when the person signs in on-premises or over the VPN and the device can reach a domain controller. The LAPS entry on the same known issues page follows the same pattern: LAPS policy isn't applied until the user phase begins.
5. If the profile must stay device-targeted (for example a baseline you don't want to split), exclude the off-site hybrid devices from it. A dynamic device group on the Autopilot group tag, (device.devicePhysicalIds -any _ -eq "[OrderID]:<tag>"), is an easy way to identify them. Then cover those devices with a separate, user-assigned profile that holds the same user rights, so they still end up with the setting after the user flow.
6. Or move the technician step on-premises. If the policy really has to land during the technician flow, run pre-provisioning on a wired network segment with a domain controller reachable. Microsoft lists this as the alternative fix.

Verify the fix#

• Run the technician flow again off-site. It should end on the green status screen, and Reseal should be available.
• Pull a fresh mdmdiagnosticstool.exe cab and confirm there are no Merge events with 0x800706FD in the Admin log.
• After the user flow completes on-premises or over VPN, check the user right applied: on the device run secedit /export /cfg C:\secpol.cfg and look at the SeDenyInteractiveLogonRight line (the constant behind "Deny log on locally"), or check the profile's device status in Intune, which should show Succeeded.
• In the Windows Autopilot deployment report under Devices › Monitor, the deployment should show as successful with no failed technician attempt.

Prevent it next time#

• Before you add any User Rights setting to a baseline or settings catalog profile, ask whether it's assigned to devices that are pre-provisioned off-site. If yes, assign it to users or to a post-deployment group.
• Keep a single owner profile for each user right. Overlapping baselines and settings catalog profiles create exactly the merge work that this limitation trips over.
• Remember that the hybrid join documentation doesn't support BYO VPN during pre-provisioning. If your technician flow depends on a VPN client being up, it was never a supported design.
• Microsoft recommends new devices be deployed as cloud-native Microsoft Entra joined. The fewer hybrid pre-provisioning flows you run, the fewer of these domain-dependent edge cases you'll meet.

References#

• Windows Autopilot known issues
• Policy CSP - UserRights
• Deploy Microsoft Entra hybrid joined devices by using Intune and Windows Autopilot