A helpdesk-grade playbook for fixing Microsoft Entra cross-tenant synchronization: quarantine recovery, scoping filters, mail attribute conflicts, on-demand provisioning, and Graph API restart commands for 2026.
Microsoft Entra cross-tenant synchronization (CTS) is a push-based provisioning feature that automates the creation, update, and soft-deletion of B2B collaboration users from a source Entra tenant into a target tenant, so you can stop hand-inviting guests during mergers, acquisitions, and multi-tenant reorgs. When CTS breaks in 2026, honestly, the culprit is almost always one of three things: a scoping filter that silently excludes the user, an attribute-mapping conflict on mail or proxyAddresses, or a quarantined provisioning job that has stopped syncing entirely. This guide walks helpdesk engineers through every common failure mode with concrete PowerShell, Graph, and portal fixes I've used on real tickets.
CTS runs on the Microsoft Entra provisioning engine and cycles roughly every 40 minutes after the initial full sync completes.
All configuration lives in the source tenant. The target tenant only opts in via cross-tenant access settings and inbound sync permissions.
Only internal member users can be provisioned. Internal guests, external users, and SMS-sign-in accounts are blocked by design.
Quarantine is triggered by escrow accrual (typically four consecutive failed cycles). Restart via the portal, or use the Graph endpoint synchronization/jobs/{id}/restart.
An Exchange license on the target user prevents mail updates. Remove the license, update, then reassign.
Enable automatic invitation redemption in both tenants to suppress consent prompts and prevent the "Guest invitations not allowed" error.
What is Microsoft Entra cross-tenant synchronization?
Cross-tenant synchronization is an inbound-only, source-driven configuration inside the Microsoft Entra provisioning service. It copies user objects from one Entra tenant into another as B2B collaboration users. It's the automated alternative to manual guest invitations, PowerShell scripts, or third-party identity brokers. Under the hood it uses the same SCIM-style engine that drives enterprise application provisioning, which is why the troubleshooting language (escrows, quarantine, watermarks, on-demand provisioning) feels familiar to anyone who has debugged Workday-to-Entra or ServiceNow-to-Entra jobs.
CTS matters most in three scenarios. First: a merger, where User A in tenant Contoso needs same-day access to Fabrikam Teams and SharePoint. Second: a global enterprise that has intentionally split business units into separate tenants for data residency. Third: a Multi-Tenant Organization (MTO) using shared channels in Teams. In each case, the goal is a single source of truth (the source tenant's HR-fed identity) that flows silently into every collaborating tenant. The provisioning job runs an initial full cycle, which can take hours for tens of thousands of users, and then incremental cycles roughly every 40 minutes for the life of the configuration.
What CTS is not: it does not sync groups (as of late 2026, group sync GA is limited to same-cloud scenarios and members only), does not sync devices, does not sync contacts, and does not sync across sovereign clouds. It also does not modify Exchange Online mailboxes directly. That boundary is the source of most "why won't mail update?" tickets covered later.
Preflight: cross-tenant access and trust settings
Before you configure a single attribute mapping, both tenants have to agree to the sync. In the target tenant, open Entra ID → External Identities → Cross-tenant access settings → Organizational settings, add the source tenant, and edit the Inbound access defaults. Under Cross-tenant sync, enable Allow users sync into this tenant. Under Trust settings, decide whether to trust the source's MFA claims, compliant device claims, and Entra hybrid-joined device claims. Untrusted claims force the synced user to re-satisfy Conditional Access from scratch, which is a common cause of MFA-loop tickets after go-live.
In the source tenant, mirror the organizational setting for the target and turn on Automatic redemption on both sides. When automatic redemption is enabled in both directions, the B2B user account is created silently, without the "Review permissions" consent screen. In my experience that's the single biggest reduction in helpdesk volume during a CTS rollout. Skipping it on either side produces the classic "Guest invitations not allowed for your company" failure in the provisioning log, because the target tenant defaults to the most restrictive external collaboration setting.
Verify with PowerShell before you build the sync job. The snippet below uses the Microsoft Graph PowerShell SDK to confirm inbound sync and auto-redemption are set correctly in the target:
Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.CrossTenantAccess"
$sourceTenantId = "<source-tenant-guid>"
$policy = Get-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId $sourceTenantId
$policy.IdentitySynchronization
# Expected: UserSyncInbound.IsSyncAllowed = True
$policy.InboundTrust
# Verify MFA and compliant-device claims are trusted if you rely on Conditional Access parity
Why is my cross-tenant sync failing? Top provisioning errors
When a user shows as Skipped or Failed in the provisioning log, click through to the entry and read the SkipReason or StatusInfo.ErrorCode field. It maps directly to a fixable root cause. In our 2026 helpdesk data, these six errors account for roughly 85% of tickets:
AlreadySoftDeleteEntry. The target already contains a soft-deleted user with a matching alternativeSecurityIds value. Restore the deleted user from the Entra recycle bin (30-day window), or hard-delete it, then trigger on-demand provisioning to recreate a clean object.
Duplicate mail in source. Two source users share the same primary SMTP, so CTS refuses to create two target objects with the same anchor. Fix the duplicate mail in the source tenant. Don't "solve" this by editing the attribute mapping.
Verified domain conflict. The source user's email domain is a verified domain in the target tenant, so Entra refuses to convert an "internal-looking" address into a B2B guest. Add the user manually as a member, or exclude that domain from scope.
Guest invitations not allowed for your company. The target's cross-tenant access setting is at the most restrictive tier. Fix in the target's Inbound access → B2B collaboration → External users and groups pane.
AzureDirectoryServiceAuthorizationFailed quarantine. The target tenant is missing the Microsoft-owned service principal (MS-PIM / Microsoft.Azure.SyncFabric) that CTS uses to write objects. Run New-MgServicePrincipal -AppId "00000014-0000-0000-c000-000000000000" in the target to re-create it.
Unsupported user type. The source object is an existing B2B guest, an external user, or an SMS-sign-in user. None of these can be re-synced across tenants and must be filtered out via a scoping expression such as userType eq "Member".
The 2026 provisioning log adds a Modified properties tab that shows exactly which attribute update was rejected. Use it before assuming the error is a permissions issue. Ninety percent of the time it's a data problem, not an authorization problem.
How do I fix a quarantined CTS provisioning job?
Quarantine is Entra's circuit breaker. When the provisioning service records four consecutive incremental cycles with a critical-level failure (401 Unauthorized, 403 Forbidden, or a persistent 5xx from Microsoft Graph), it accrues an escrow. Four full escrows and the job flips to Quarantine. No new users are provisioned, no updates flow, and the badge in the portal turns yellow. The provisioning log stops recording new attempts once the job is quarantined, which is why "the log went silent" is often the first ticket symptom.
Recovery is a three-step process. First, identify the root cause from the last failure event before quarantine. Usually it's AzureDirectoryServiceAuthorizationFailed or an expired admin consent. Second, fix the underlying issue (re-consent the enterprise app, restore the missing service principal, reset the target's cross-tenant setting). Third, restart the job to clear escrows and quarantine.
The portal restart button clears everything at once (escrows, quarantine, and watermarks), which is destructive because it forces a full re-sync of every in-scope user. I hit this exact trap on a 40,000-user tenant and pushed the job right back into quarantine within one cycle. Prefer the Graph API for surgical restarts:
# Requires Synchronization.ReadWrite.All application permission on the source
$servicePrincipalId = "<object-id-of-CTS-enterprise-app-in-source>"
$jobId = (Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$servicePrincipalId/synchronization/jobs" `
).value[0].id
# Clear only quarantine + escrows; keep watermarks so users are NOT re-synced from scratch
$body = @{ criteria = @{ resetScope = "Quarantine, Escrows" } } | ConvertTo-Json
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$servicePrincipalId/synchronization/jobs/$jobId/restart" `
-Body $body -ContentType "application/json"
Scoping filters and attribute mapping fixes
Scope is where most "user is missing" tickets are actually solved. Under the CTS configuration, expand Manage → Scoping Filters. As of August 2026 this pane splits into a Users tab and a Groups tab. Microsoft strongly recommends picking Sync only assigned users instead of Sync all users. It dramatically shrinks the working set, reduces incremental cycle time from hours to minutes on large tenants, and limits blast radius when a bad attribute mapping is deployed.
Scoping expressions use the same syntax as SCIM filters. A common production filter that excludes disabled accounts, service accounts (identified by extension attribute), and non-member types looks like this:
Source Object Scope:
(userType EQUALS "Member") AND
(accountEnabled EQUALS True) AND
(NOT(extensionAttribute1 CONTAINS "svc-")) AND
(department EQUALS "Sales" OR department EQUALS "Engineering")
Attribute mappings are equally load-bearing. For CTS configurations created after January 2024, the manager attribute is automatically mapped, but existing pre-2024 configurations still require you to add it manually. If a user's manager reference is missing in the target, run on-demand provisioning against that specific user or restart with watermarks cleared. The sync engine won't backfill manager references on already-provisioned users on its own.
Watch out for proxyAddresses. In Microsoft Graph it's a read-only target property, so you can use it as a source input for expressions but you can't set it directly on the target user. For the same reason, if you need to hide the synced user from the global address list, map showInAddressList to False in Entra rather than trying to control HiddenFromAddressListEnabled in Exchange. CTS can't touch the Exchange attribute at all.
Two other mapping gotchas drive frequent re-opens. (1) Leaving userType at its default means every synced user stays a B2B guest forever; set the mapping to Always apply and target value Member to promote them to B2B members so they inherit member-level Conditional Access. (2) An extension attribute that exists in the source but not in the target schema causes the mapping to be silently dropped, so extend the target schema first with New-MgApplicationExtensionProperty.
Guest, hybrid, and Exchange license limitations
These constraints are not bugs and cannot be waived, so build your rollout plan around them. CTS refuses to provision three categories of source object: internal guest users, external users (accounts that originated in a third tenant), and users enabled for SMS sign-in. If any of these appear in your scope, they'll show as Skipped forever. Filter them out with a scoping expression so your success rate isn't artificially depressed by users who can't be synced by design.
Hybrid identities (accounts sourced from on-premises Active Directory via Entra Connect Sync or Cloud Sync) can't be synced and then converted to B2B users in a target where the same person already exists as a hybrid guest. This scenario shows up during a domain consolidation where Entra Connect and CTS overlap. Complete the on-premises migration first, or pause CTS for the affected accounts during the switchover to avoid a race condition between the two provisioning engines. For a deeper look at the on-prem side of the same problem, our Microsoft Entra Connect Sync troubleshooting guide covers the connector-level errors that most often surface as CTS mapping conflicts.
Exchange licensing is the single most common "the mail attribute won't update" ticket. When a target user has any Exchange Online license assigned, Exchange takes ownership of the mail-related attributes and CTS updates to mail silently no-op. The documented workaround is inconvenient but reliable:
# 1. Remove the Exchange license (Microsoft Graph PowerShell)
$user = Get-MgUser -Filter "userPrincipalName eq 'jane.doe#EXT#@target.onmicrosoft.com'"
$exchangeSku = "6fd2c87f-b296-42f0-b197-1e91e994b900" # example Office 365 E3 SKU
Set-MgUserLicense -UserId $user.Id -RemoveLicenses @($exchangeSku) -AddLicenses @()
# 2. Trigger CTS on-demand provisioning for that user (see Restart section)
# 3. Reassign the Exchange license
Set-MgUserLicense -UserId $user.Id -RemoveLicenses @() -AddLicenses @(@{ SkuId = $exchangeSku })
Restart, on-demand provisioning, and Graph commands
On-demand provisioning is the fastest diagnostic tool in the CTS toolbox. It bypasses the 40-minute incremental schedule and processes a single named user immediately, returning a step-by-step trace of every rule evaluation, scope check, and Graph write. If a user should be in scope but isn't syncing, on-demand will tell you exactly which scoping predicate excluded them or which attribute mapping errored.
From the portal: open the CTS configuration, click Provision on demand, enter the source user's UPN, then click Provision. Read the results pane carefully. The Determine if user is in scope section explains scoping decisions, and the Perform action section shows the exact Graph call and its response. From the CLI, the Graph endpoint is:
You can retrieve the ruleId by reading the synchronization schema (GET /synchronization/jobs/{jobId}/schema) and looking under synchronizationRules[].id. The full restart, by contrast, takes an optional criteria.resetScope that accepts a comma-separated combination of Escrows, Quarantine, and Watermarks. Restarting with only Watermarks re-evaluates every in-scope user without clearing the quarantine flag, which is useful when a mapping change needs to be back-applied but the job is currently healthy.
Monitoring, provisioning logs, and alerts
A CTS job that goes silent is worse than one that fails loudly, so bake monitoring in from day one. Enable email notifications on the provisioning configuration and set the recipient to a monitored distribution list, not an individual admin. Add a diagnostic setting to stream ProvisioningLogs and AuditLogs to a Log Analytics workspace so you can build an alert rule for quarantine transitions. A minimal KQL query that catches quarantine within 10 minutes:
AuditLogs
| where OperationName == "Update ServicePrincipal"
| where TargetResources has "Cross-tenant sync"
| where Result == "success"
| extend qState = tostring(parse_json(tostring(TargetResources[0].modifiedProperties))
[0].newValue)
| where qState has "quarantine"
| project TimeGenerated, InitiatedBy, qState
Pair the quarantine alert with a health-cycle heartbeat. Query ProvisioningLogs and alert if no successful cycle has been recorded in the last 90 minutes (roughly 2.25 expected cycles). Together the two rules catch both hard failures (quarantine) and soft failures (throttling, silent stalls) before end-users notice broken access. Layer these on top of the standard identity signals covered in our Microsoft Entra ID Conditional Access admin guide, since a CTS failure often shows up to users as a CA-driven access denial rather than a missing account.
What is the difference between cross-tenant synchronization and Microsoft Entra Connect?
Entra Connect synchronizes identities from an on-premises Active Directory into a single Entra tenant. Cross-tenant synchronization synchronizes cloud identities from one Entra tenant into another as B2B collaboration users. They solve different problems and can coexist, but CTS can't re-sync objects that a target has already received as hybrid users from Entra Connect.
Can you sync security groups across tenants with CTS?
Group synchronization in CTS is limited to same-cloud scenarios and only syncs member relationships for groups explicitly assigned to the configuration. Group nesting, dynamic membership rules, and cross-cloud group sync aren't supported as of late 2026. Plan to recreate mail-enabled and dynamic groups natively in the target tenant.
How long does a cross-tenant synchronization cycle take?
The initial full cycle depends on scope size and can take from minutes (a few hundred users) to several hours (tens of thousands of users). After the initial cycle completes, incremental cycles run approximately every 40 minutes as long as the provisioning service is running and the job is not in quarantine.
Why is my synced user still a B2B guest instead of a member?
By default the userType attribute mapping only applies on object creation, so existing B2B guests remain guests forever. Change the mapping's Apply this mapping setting to Always with a constant value of Member, then restart with watermarks cleared to force re-evaluation.
How do I remove a user provisioned by CTS?
Remove the source user from the configuration's scope. Unassign them, remove them from an assigned group, or change an attribute so a scoping filter excludes them. CTS then soft-deletes the target user on the next incremental cycle. If the source user is blocked from sign-in, the target account is blocked rather than deleted.
Troubleshoot Intune Remote Help licensing, RBAC scopes, EPM elevation, and session errors. Real KQL, PowerShell, and network fixes from a helpdesk lead.
Fix Windows Server 2025 hotpatch failures the way I do in production: Azure Arc enrollment checks, baseline drift diagnostics, WSUS/WUfB conflicts, and clean rollback steps with PowerShell and CBS.log queries.
Close AVD tickets faster in 2026 with PowerShell, KQL, and portal steps for session host registration, RDP Shortpath, Entra ID join, FSLogix, App Attach, and autoscale plans.
