Every Security Check Passed. OneDrive Still Wouldn't Sync. Here's the Layer Nobody Checks.

The easy stuff, solved in an afternoon

Helpdesk's first round of reports looked like a standard Autopilot punch list. No local admin, by design, fixed with a Local User Group Membership policy so IT staff elevate under their own identity, no shared account.

Couldn't join the domain, also by design, these devices are Entra-joined only, and Kerberos cloud trust covered file shares, the intranet, and printing once we set a device-side DNS suffix policy.

A VPN client silently refused to install because a previous engineer had assigned it to a device group under “Available,” an assignment type that only works with user groups. Reassigned as Required, fixed instantly.

All satisfying. All solved by lunch. Then OneDrive broke, and it stayed broken.

The mystery: everything checks out, nothing works

Every new device hit the same dead end the moment OneDrive tried to set itself up: “Sorry, OneDrive can't add your folder right now.” No error code, no detail.

I went through the entire standard checklist and struck out on every item. Licensing was full E5 with SharePoint Online. Site provisioning worked fine on the web. Client version was current. The Intune-pushed silent sign-in and Known Folder Move policies were landing correctly on the device, the setting was there, it just wasn't doing anything. Devices showed fully Compliant in Intune.

And Conditional Access showed “Not applicable” on every single policy against the affected sign-in events. Nothing was blocking at that layer. At least, that's what it looked like.

I knew the real cause was somewhere I hadn't looked yet.

The breakthrough, and the near-miss that came right after it
OneDrive's client-side sync logs are binary trace files, not something you casually read in Notepad. But binary files still hold plain-text fragments, and a simple string extraction against the log turned up the actual server response, buried in the noise: MachineIsNotAllowedToSync. A real, named SharePoint Online error. The sync client was being rejected by the server before it ever got far enough to attempt anything else.

That led to a legacy tenant setting, Set-SPOTenantSyncClientRestriction, a feature that restricts OneDrive sync to an approved allow-list of domain GUIDs. Meridian had configured it years earlier, a reasonable security control at the time.

Get-SPOTenantSyncClientRestriction | Select-Object TenantRestrictionEnabled, AllowedDomainList
TenantRestrictionEnabled : True
AllowedDomainList : {a1b2c3d4-5678-90ab-cdef-1234567890ab}

The first instinct was that the GUID was stale, some leftover from a migration nobody remembered. It was queried as an Entra tenant ID and got back “tenant not found,” which seemed to confirm it. Almost ready to overwrite it.

I got involved; glad I checked one more time first, because they were wrong, and it would have been a genuinely dangerous mistake. That GUID wasn't an orphaned tenant ID. It was the on-premises Active Directory domain's own objectGuid, confirmed with a quick Get-ADDomain on a domain controller. The setting doesn't understand Entra tenant IDs at all, only on-prem AD domain GUIDs, which is exactly why the query came back “not found.” It had been configured correctly, years ago, for a hybrid-joined fleet that always presents a valid domain GUID at sync time.

The real gap: this feature has no concept of Entra-joined-only devices. Our new Autopilot machines had no on-prem domain membership to present, nothing to check against the allow-list, so SharePoint Online rejected them outright, before authentication, before Conditional Access ever got a chance to evaluate anything. That's why every CA check came back “Not applicable.” The block was happening a layer below where CA even lives.

The fix: layered, not a replacement
Microsoft's own guidance says this restriction feature doesn't apply to Entra-joined devices and recommends Conditional Access instead for that case. So, I implemented both, deliberately.

First, a registry value on each device asserting the Entra tenant ID in the field the client uses to identify domain membership:

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\OneDrive" `
-Name "AADJMachineDomainGuid" -Value "" -Force

Second, the SPO allow-list updated to include both GUIDs, the original AD domain GUID, untouched, still protecting the existing hybrid fleet, plus the Entra tenant ID:
Set-SPOTenantSyncClientRestriction -Enable `
-DomainGuids "a1b2c3d4-5678-90ab-cdef-1234567890ab; "

Third, a Conditional Access policy requiring device compliance, scoped narrowly to SharePoint Online and filtered to Autopilot-enrolled devices, a second independent layer, not a substitute for the first fix.

Deployed the registry piece as an Intune Platform Script targeting the Autopilot device group, so every future device gets it automatically, no manual step required.

Tested end to end on a clean device. OneDrive completed setup cleanly, and the sign-in logs showed the new Conditional Access policy firing with an actual “Success” result against the right sign-in event, the first time we'd seen that policy evaluate at all in days of testing.

What I'd want another engineer to know before they hit this
“Not applicable” in Conditional Access logs doesn't mean nothing is blocking you. It can mean the block is happening at a layer below CA entirely, and CA never got the chance to weigh in.

A GUID that looks stale might not be. An Entra tenant ID and an on-prem AD domain GUID look identical and query completely differently. Getting that backwards would have broken sync for the entire existing fleet, not just the new pilot devices.

And legacy security settings often predate the architectural decisions made years after them. A perfectly reasonable domain-restriction policy, correct for a domain-joined world, becomes an invisible landmine the moment you introduce Entra-joined-only devices, and nothing warns you it's coming.

If you're running a hybrid AD and Entra environment and are about to pilot Autopilot for the first time, check your Set-SPOTenantSyncClientRestriction configuration before your first Entra-only device ever tries to sync. It'll save you the two weeks it cost us.

If you found this useful, hit the Subscribe button below to get more articles like this delivered straight to your inbox.

Want to see what our AI agents do with a ticket like this? Start a free trial and throw your trickiest hybrid-identity issue at them.

What's the legacy setting that turned into a landmine in your environment? Tell me in the comments.