0x800706FD DenyLocalLogOn: Hybrid Pre-Provisioning Fails

0x800706FD DenyLocalLogOn: Hybrid Pre-Provisioning Fails

The technician flow of a Windows Autopilot pre-provisioned deployment for Microsoft Entra hybrid join fails, and the MDM event log has this line:

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

The message text suggests a broken computer account. The Windows Autopilot known issues page, which added this entry on September 1, 2026, gives a different cause: an assigned policy needed the client device management (DM) stack to resolve a policy conflict by contacting an Active Directory domain controller, and the device had no line of sight to one. That entry is the match for 0x800706FD DenyLocalLogOn in your log.

Microsoft offers two ways out, and both are design choices: keep policies that need a domain controller out of the technician flow, or run the technician flow on a network that can reach a domain controller.

Quick Fix checklist

1. Confirm the device failed in the pre-provisioning technician flow with a Microsoft Entra hybrid join profile. Microsoft’s known issue covers the pre-provisioning technician flow.
2. Before you press Reset, collect logs from the failure screen. In Windows 11, press CTRL+SHIFT+D and select Export Logs. In Windows 10, select View diagnostics.
3. Find the exact line in Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin. Note the Area and Policy values.
4. In the Intune admin center, open the device under Devices > All devices > Device configuration and look for a Conflict state. Select the row to see every profile that sets the conflicting setting.
5. Decide where the technician flow runs. If you can run it on a network with line of sight to a domain controller, do that and retry. If you can’t (OEM, reseller, or a remote bench), take the UserRights policy that needs a domain controller out of the device-targeted assignments for pre-provisioned devices.
6. Don’t count on a bring-your-own (BYO) VPN to fix this. Microsoft says the BYO VPN connection isn’t available during the technician flow.
7. Reset the device and run the technician flow again. Collect the same log on the next run to confirm the line is gone.

What the error means in Microsoft’s words

From the Windows Autopilot known issues page, under “Pre-provisioning fails for Microsoft Entra hybrid join when policy conflict resolution requires domain controller connectivity”:

During Windows Autopilot pre-provisioning for Microsoft Entra hybrid join, the technician flow might fail when an assigned policy requires the client device management (DM) stack to resolve a policy conflict by contacting an Active Directory domain controller.

Microsoft then says:

This behavior is expected when the device doesn’t have line-of-sight to a domain controller during pre-provisioning. In off-premises scenarios that use a bring-your-own (BYO) VPN, the VPN connection isn’t available during the technician flow, so the device can’t resolve the policy state.

And the workaround:

This scenario is a known limitation of using pre-provisioning with Microsoft Entra hybrid join when assigned policies require conflict resolution in the client DM stack. To avoid the failure, don’t assign policies that require domain controller connectivity during the technician flow, or pre-provision the device on a network that has line-of-sight to a domain controller.

Microsoft calls this a limitation and lists no fixed build or hotfix, so I treat it as a design rule for hybrid pre-provisioning assignments.

Decoding 0x800706FD

0x800706FD is a Win32 error wrapped in an HRESULT. The HRESULT_FROM_WIN32 macro keeps the low 16 bits of the system error code and adds the Win32 facility and failure bit. The low bits here are 0x6FD, which Microsoft’s system error code list defines as:

• 1789 (0x6FD) ERROR_TRUST_FAILURE: “The trust relationship between this workstation and the primary domain failed.”

That’s where the alarming text comes from. It’s the generic message for the Win32 code. In this known issue, Microsoft ties it to the missing domain controller, not to the computer account.

What DenyLocalLogOn is

DenyLocalLogOn is a setting in the UserRights Policy CSP at ./Device/Vendor/MSFT/Policy/Config/UserRights/DenyLocalLogOn. Microsoft describes it as the setting that “determines which users are prevented from logging on to the computer”, and maps it to the Group Policy setting Deny log on locally under Windows Settings > Security Settings > Local Policies > User Rights Assignment. The CSP scope is device only. The value is a list of users or groups, as SIDs or as strings, separated by 0xF000.

The Deny log on locally reference adds one warning worth repeating: if you apply it to the Everyone group, no one can sign in locally.

Why the obvious diagnosis can be wrong

“Trust relationship failed” normally sends an admin to the computer account: reset it, rejoin the domain, check the secure channel. In the technician flow, that’s the wrong place to look.

Microsoft’s pre-provisioning overview says the process “doesn’t require access to an end-user’s on-prem domain infrastructure”, and that the device is resealed before the time when connectivity to a domain controller is expected. The hybrid technician flow tutorial is just as direct: the technician flow only requires Internet connectivity, and domain controller connectivity for the on-premises domain join isn’t needed until the user flow.

So a bench with Internet and no domain controller is a supported setup for the technician flow in general. This failure needs one more ingredient: an assigned policy that still needs the domain controller. A bench that works today can start failing once a profile like that is assigned to your pre-provisioned devices.

Other things that look related but aren’t the cause here:

• Skip AD connectivity check. The hybrid pre-provisioning profile tutorial sets this to Yes for off-premises VPN scenarios so the deployment doesn’t fail before the VPN connects. As documented, it covers the domain join connectivity check. Nothing on that page says it gives the policy engine a domain controller during the technician flow.
• The Intune Connector for Active Directory. Connector problems surface as offline domain join failures such as the ones in Autopilot hybrid join error 0x80070774 and Autopilot hybrid join timeout 0x80004005. The PolicyManager line points at a policy, not the connector.
• The four GPO settings that break pre-provisioning. The Autopilot troubleshooting FAQ lists Interactive logon message title and text, Require Windows Hello for Business or smart card, and the UAC credential prompt on the secure desktop as settings that stop pre-provisioning. Those are a separate known conflict. DenyLocalLogOn isn’t on that list.

Evidence to collect

Export logs from the error screen

The hybrid technician flow tutorial says that when pre-provisioning fails, you can gather diagnostic logs from the error status screen: View diagnostics in Windows 10, or CTRL+SHIFT+D then Export Logs in Windows 11. The same screen offers Retry and Reset. Export first.

If you can get a command prompt with Shift+F10 during OOBE (the troubleshooting FAQ documents Shift-F10 in OOBE), Microsoft’s Collect MDM logs page gives this command:

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip"

Inside the zip, microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx is the main MDM event log, and MDMDiagHtmlReport.html summarizes the MDM policies the device received.

Find the PolicyManager line

MDM events land in Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin. Microsoft’s known issue quotes the message text but doesn’t give an event ID, so search on the text.

This PowerShell is read-only. I haven’t run it against a failed technician flow device, so treat it as a starting point:

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' |
    Where-Object { $_.Message -match 'DenyLocalLogOn|0x800706FD' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

For an exported log on your own workstation, swap -LogName for -Path and point it at the extracted .evtx file.

What to read in the line:

• Area: (UserRights) tells you the CSP area.
• Policy: (DenyLocalLogOn) tells you the setting. Microsoft’s example uses DenyLocalLogOn. If your line names a different UserRights policy, the same reasoning applies, but you’re outside the exact example Microsoft documented.
• Merge string fits Microsoft’s description of a policy conflict the DM stack had to resolve.
• Result:(0x800706FD) is Win32 error 1789.

Find the competing profiles in Intune

The Intune device configuration monitoring page documents the per-device path: Devices > All devices > select the device > Device configuration > select a policy. If a row shows Conflict, select it to see every policy and profile name that contains the conflicting setting.

Look wider than the settings catalog. Microsoft’s policy troubleshooting FAQ points out that configuration policies come from several places, including Group Policy analytics, endpoint security and security baselines, and says configuration conflicts must be resolved manually. A custom OMA-URI profile on ./Device/Vendor/MSFT/Policy/Config/UserRights/DenyLocalLogOn counts too. For the general method, see Intune settings catalog policy conflicts.

The fix

Microsoft gives two options. Pick based on where the technician flow physically runs.

Option 1: Pre-provision with line of sight to a domain controller

If IT runs the technician flow in-house, put the bench on a network segment that can reach a domain controller. This is the second workaround in the known issue. Your policy design stays as it is, so it’s the faster fix when you control the bench.

It doesn’t help OEM or reseller pre-provisioning, which Microsoft describes as running without access to your on-premises domain. And a BYO VPN doesn’t count as line of sight here: the known issue says the VPN connection isn’t available during the technician flow, and the hybrid enrollment page says BYO VPN configurations aren’t supported in pre-provisioning mode.

Option 2: Keep DC-dependent policies out of the technician flow

If the technician flow runs anywhere without a domain controller, change what the device receives during it. The known issue’s other workaround is to not assign policies that require domain controller connectivity during the technician flow.

Steps for option 2:

1. List every profile that sets DenyLocalLogOn (or the UserRights policy in your log line) and is assigned to the device groups your pre-provisioned devices land in.
2. Remove the duplicates so one profile owns the setting. Microsoft ties the failure to conflict resolution, so cleaning up the conflict is the first thing I’d do. Microsoft doesn’t say a single, conflict-free assignment avoids the domain controller lookup, so prove it on one device before you trust it.
3. If the setting still has to stay off the technician flow, change the assignment for pre-provisioned devices. Microsoft’s pre-provisioning overview says the technician phase applies device-targeted policies, and “other user-targeted policies aren’t applied until the user signs into the device.” Microsoft uses the same approach for a different pre-provisioning problem in the troubleshooting FAQ: for security baseline password settings it suggests assigning the baseline to a user group. Microsoft doesn’t document this for DenyLocalLogOn, so test it on one pilot device first.
4. Reset the device and rerun the technician flow.

On values: the UserRights CSP accepts SIDs or names, and Microsoft recommends SIDs because string names are localized. That advice is about localization. Microsoft doesn’t say SIDs avoid this failure, so a value change alone isn’t a fix.

Which option I’d pick

If the technician bench is yours and sits on the corporate network, use option 1 and move on. If an OEM or reseller does your pre-provisioning, option 1 isn’t available, so restructure the assignments with option 2.

Microsoft’s own guidance goes further. The pre-provisioning overview and the hybrid enrollment page both say Microsoft recommends deploying new devices as cloud-native with Microsoft Entra join, and doesn’t recommend hybrid join for new devices, including through Autopilot. If this is one of several hybrid pre-provisioning workarounds you’re carrying, raise it with whoever owns the join decision.

Verify the fix

1. Run the technician flow again. On success the status screen shows the elapsed time and a Reseal button.
2. Before you reseal, collect the MDM log again and confirm the 0x800706FD UserRights line is gone.
3. Don’t treat the green screen as proof the technician flow finished. Microsoft notes the success screen validates enrollment, not that the technician flow is complete, which is one reason it recommends keeping the ESP on.
4. After handoff, confirm the UserRights setting did apply once the user signed in on the corporate network or VPN, especially if you moved it to a user group.
5. Wait at least 90 minutes after the technician flow before you run the user flow in a lab. Microsoft says this gives tokens time to refresh.

What not to waste time on

• Resetting the computer account or rejoining the domain because of the “trust relationship” text. The technician flow isn’t expected to talk to a domain controller.
• Rebuilding the Intune Connector for Active Directory. The failing component is the policy merge.
• Setting Skip AD connectivity check to Yes as the fix. It’s for VPN-based domain join, not policy resolution in the technician flow.
• Adding a BYO VPN client to get domain controller reach during the technician flow.

Prevention

• Treat any new UserRights profile aimed at pre-provisioned device groups as a change that needs one pilot technician flow first.
• Let one profile own each UserRights setting. Check the device’s Device configuration view for Conflict rows during pilot.
• Pilot every new security baseline or endpoint security policy on one pre-provisioned hybrid device before broad assignment.
• Document where your technician flow runs (corporate bench, remote bench, OEM) and which of Microsoft’s two workarounds applies to each.
• Re-check the Windows Autopilot known issues page before each hardware refresh. That’s where Microsoft documented this one.

Related ZakitPro guides:

• Windows LAPS not applying during the technician flow covers another setting that behaves differently in pre-provisioning.
• Autopilot pre-provisioning error 0x80180005 covers profile assignment and device reuse failures.
• Hybrid join error 0x801c001d covers the SCP read failure after the device reaches the domain.

Sources

• Windows Autopilot known issues: the issue text, date added, log line, BYO VPN note and both workarounds.
• Windows Autopilot for pre-provisioned deployment: no on-premises infrastructure requirement, device-targeted versus user-targeted policies in the technician phase, success screen caveat, 90-minute wait, cloud-native recommendation.
• Hybrid pre-provisioning technician flow: Internet-only requirement, error screen log export, Retry and Reset.
• Hybrid pre-provisioning Autopilot profile: Skip AD connectivity check and VPN requirements.
• Enrollment for Microsoft Entra hybrid joined devices: BYO VPN not supported in pre-provisioning mode.
• Windows Autopilot troubleshooting FAQ: Shift-F10, known policy conflicts, the four GPO settings and the baseline user-group workaround.
• UserRights Policy CSP: DenyLocalLogOn path, scope, format and value guidance.
• Deny log on locally: Group Policy location and the Everyone warning.
• System Error Codes (1700-3999): 1789 ERROR_TRUST_FAILURE.
• HRESULT_FROM_WIN32 macro: how a Win32 code maps to an HRESULT.
• Collect MDM logs: Event Viewer path, channel name, mdmdiagnosticstool command and zip contents.
• Get-WinEvent: -LogName and -Path parameters.
• See device configuration policies with Intune: per-device Conflict view.
• Questions with policies and profiles in Intune: where configuration policies come from and manual conflict resolution.