Cross-tenant synchronization is a critical identity governance feature in Microsoft Entra ID that enables automated, scalable provisioning of B2B collaboration users across Azure AD tenants. For the AZ-104 exam, this topic appears in approximately 5–10% of questions under objective 1.1 (Manage identities in Microsoft Entra ID), focusing on its configuration, behavior, and integration with entitlement management. This chapter provides a deep dive into the mechanism, step-by-step setup, and exam-specific traps to ensure you can confidently answer any cross-tenant sync question.
Jump to a section
Imagine two companies, Contoso and Fabrikam, that merge but keep separate offices. Each office has its own HR system (Microsoft Entra ID tenant) listing employees and their access badges. To collaborate, they need a shared mailroom where Fabrikam employees can pick up packages at Contoso's office. Cross-tenant synchronization works like setting up a secure, one-way mail slot between the two mailrooms. Contoso's mailroom manager (the source tenant admin) creates a list of Fabrikam employees that should have access—like a distribution list (synchronization schema) defining which attributes (name, department, email) are allowed through. They also set rules (attribute mapping) for how Fabrikam's employee records map to Contoso's badge format. Then they configure a scheduled job (synchronization job) that runs every 40 minutes by default, copying those records from Fabrikam's HR system (via a provisioning agent or directly from the target tenant's directory) into Contoso's mailroom as external guest users (B2B collaboration users). The mail slot is one-way: changes in Fabrikam (new hires, departures, attribute updates) are replicated to Contoso, but nothing flows back. Contoso's own employees never appear in Fabrikam's system. The mailroom manager can also set up automatic cleanup (soft-delete threshold) to remove badges of employees who left Fabrikam after 30 days. This avoids manual guest user creation, ensures compliance with least-privilege access, and scales to thousands of users across tenants.
What Is Cross-Tenant Synchronization and Why Does It Exist?
Cross-tenant synchronization is a feature of Microsoft Entra ID (formerly Azure AD) that automates the creation, update, and removal of B2B collaboration users across Azure AD tenants. It allows an organization to synchronize user identities from a source tenant (where users are defined) to a target tenant (where they need access to resources like apps, SharePoint sites, or Teams). This eliminates the need for manual guest user creation, reduces administrative overhead, and ensures consistent access control across multi-tenant environments.
Why does it exist? In modern enterprises, mergers, acquisitions, and multi-tenant strategies (e.g., separating production from development) are common. Without cross-tenant sync, administrators would have to manually invite each guest user via the Azure portal or PowerShell, which doesn't scale. Moreover, manual processes lead to stale accounts when users leave the source tenant. Cross-tenant sync solves this by providing a one-way, attribute-based provisioning engine that mirrors user lifecycles from source to target.
How It Works Internally – Step Through the Mechanism
Cross-tenant synchronization is built on the Microsoft Entra provisioning service, the same engine used for HR-driven provisioning (Workday/SuccessFactors) and app provisioning (SaaS apps). The mechanism involves the following components:
Source Tenant: The tenant that contains the user identities to be synchronized. This tenant must have Microsoft Entra ID P1 or P2 licenses for the users being synced.
Target Tenant: The tenant that receives the B2B guest users. The target tenant does not require P1/P2 licenses for the guest users themselves, but the administrator configuring sync needs a P1/P2 license in the source tenant.
Provisioning Agent: For on-premises users synced via Azure AD Connect, the provisioning agent in the source tenant reads the directory and pushes changes to the target tenant. For cloud-only users, the provisioning service works directly against the Microsoft Graph API.
Synchronization Schema: Defines which user attributes are mapped between tenants. By default, core attributes like displayName, userPrincipalName, mail, and department are included.
Attribute Mapping: Rules that transform source attributes to target attributes. For example, you can map department to a custom extension attribute in the target tenant.
Scoping Filters: Rules that determine which users are synchronized (e.g., only users in the Sales department).
Synchronization Job: A recurring job that runs every 40 minutes by default (configurable between 5 minutes and 24 hours). The job performs a delta sync after an initial full sync.
Soft-Delete Threshold: If a user is deleted in the source tenant, the corresponding guest user in the target tenant is soft-deleted (disabled) after a configurable threshold (default 30 days). After the threshold, the guest user is permanently deleted.
Here's the step-by-step flow:
Configuration: In the source tenant, an administrator navigates to Microsoft Entra ID > Cross-tenant synchronization > Configurations. They create a new configuration, specify the target tenant ID (domain name or tenant ID), and define scoping filters and attribute mappings.
Consent: The target tenant administrator must grant consent for the source tenant to write guest users. This is done via a consent link generated during configuration.
Initial Sync: After consent, the provisioning service performs a full sync, reading all users in scope from the source tenant and creating corresponding B2B guest user objects in the target tenant. Each guest user is assigned a UserPrincipalName in the format user_sourceTenantDomain#EXT#@targetTenantDomain.onmicrosoft.com.
Delta Sync: Subsequent syncs occur every 40 minutes (by default), processing changes (new users, attribute updates, deletions) in the source tenant and applying them to the target.
Lifecycle Management: When a user is deleted in the source tenant, the guest user in the target tenant is soft-deleted (disabled) immediately. After the soft-delete threshold (default 30 days), the guest user is permanently removed. If the user is restored in the source tenant within the threshold, the guest user is re-enabled.
Key Components, Values, Defaults, and Timers
Sync Interval: Default 40 minutes. Can be changed via PowerShell (Set-AzureADMSProvisioningJob -ScheduleInterval). Minimum 5 minutes, maximum 24 hours.
Soft-Delete Threshold: Default 30 days. Configurable in the provisioning settings (0–365 days). Setting it to 0 disables soft-delete and immediately hard-deletes the guest user.
Scoping Filters: Use attribute-based rules (e.g., user.department -eq "Sales") or group-based scoping (sync only members of a specific security group).
Attribute Mapping: Supports direct mapping, constant values, and expression mapping using the Microsoft Identity Manager (MIM) expression language. For example, Switch([IsSoftDeleted], , "False", "True", "True", "False") to map the isSoftDeleted attribute.
Required Licenses: Source tenant users must have Microsoft Entra ID P1 or P2. Target tenant does not require licenses for guest users, but administrators need P1/P2 in the source tenant.
Maximum Users per Sync: Up to 300,000 users per configuration.
Cross-Tenant Access Settings: To allow B2B collaboration, the target tenant must have inbound B2B collaboration enabled (default is enabled). Additionally, cross-tenant access settings can be configured to trust MFA and device claims from the source tenant.
Configuration and Verification Commands
Configuration is primarily done in the Azure portal, but key PowerShell cmdlets are useful for automation and exam scenarios:
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "CrossTenantUserProfileSharing.ReadWrite.All", "User.Read.All"
# Create a new cross-tenant synchronization configuration
$config = New-MgCrossTenantUserProfileSharingConfiguration -DisplayName "Contoso-Fabrikam Sync" -TargetTenantId "fabrikam.onmicrosoft.com"
# Add attribute mapping
$mapping = @{
sourceAttribute = "userPrincipalName"
targetAttribute = "userPrincipalName"
mappingType = "Direct"
}
New-MgCrossTenantUserProfileSharingConfigurationAttributeMapping -CrossTenantUserProfileSharingConfigurationId $config.Id -BodyParameter $mapping
# Trigger a manual sync
Start-MgCrossTenantUserProfileSharingConfigurationSync -CrossTenantUserProfileSharingConfigurationId $config.Id
# Check provisioning status
Get-MgCrossTenantUserProfileSharingConfigurationJob -CrossTenantUserProfileSharingConfigurationId $config.Id | flIn the portal, you can verify sync status under Cross-tenant synchronization > Configurations > [Your Config] > Provisioning logs. Look for success/failure counts and error details.
How It Interacts with Related Technologies
Entitlement Management: Cross-tenant sync can be integrated with entitlement management catalogs. You can create access packages that include resources from the target tenant and automatically assign them to synced guest users. This enables automated access reviews and expiration.
Conditional Access: The target tenant can enforce Conditional Access policies on guest users, such as requiring MFA or compliant devices. Cross-tenant access settings allow the target tenant to trust MFA and device claims from the source tenant, avoiding re-prompting.
Azure AD B2B: Cross-tenant sync creates standard B2B guest users. These users are subject to the same B2B policies (e.g., redemption process, external identities settings). The target tenant must have B2B collaboration enabled.
Azure AD Connect: If the source tenant synchronizes on-premises AD users via Azure AD Connect, those users can also be included in cross-tenant sync. The sync will replicate the cloud user objects to the target tenant. Note: The provisioning agent is not required for cloud-only users.
Microsoft 365 Groups and Teams: Synced guest users can be added to Microsoft 365 groups and Teams in the target tenant, but cross-tenant sync does not directly provision group membership. You must use separate group-based scoping or entitlement management.
Exam-Relevant Details
The AZ-104 exam focuses on the following aspects: - Prerequisites: Both tenants must have Microsoft Entra ID P1/P2 licenses for the source users. The target tenant must enable B2B collaboration. - Consent Flow: The target tenant admin must consent via a generated link. Without consent, sync fails. - User Type: Synced users appear as "Member" or "Guest" depending on the target tenant's external collaboration settings. By default, they are Guests. - Soft-Delete Behavior: Understand the difference between soft-delete (disabled user, still recoverable) and hard-delete (permanent removal). The default threshold is 30 days. - Scoping Filters: The exam may test group-based scoping vs. attribute-based scoping. Group-based scoping is simpler but less flexible. - Sync Interval: The default is 40 minutes, but you can set it as low as 5 minutes. The exam might ask about the minimum interval. - Troubleshooting: Common issues include missing licenses, consent not granted, scoping filters excluding all users, and attribute mapping errors (e.g., duplicate UPNs).
Common Exam Traps
Trap: Confusing cross-tenant sync with Azure AD Connect. Azure AD Connect syncs on-premises AD to a single Azure AD tenant. Cross-tenant sync syncs between two Azure AD tenants.
Trap: Thinking that cross-tenant sync requires Azure AD Connect in the target tenant. It does not. The provisioning service works entirely in the cloud.
Trap: Assuming that synced users inherit the same roles in the target tenant. They are guest users with no roles by default. Role assignment is separate.
Trap: Forgetting that the source tenant must have P1/P2 licenses for the synced users. Without proper licensing, the provisioning service will fail or be throttled.
Trap: Believing that sync is bidirectional. It is strictly one-way from source to target.
Edge Cases and Exceptions
User Already Exists in Target Tenant: If a user with the same UPN already exists (either as a member or guest), the sync will fail for that user with a duplicate attribute error. You must resolve the conflict manually (e.g., rename the existing user).
Soft-Delete Threshold Set to 0: This immediately hard-deletes guest users when the source user is deleted. Useful for temporary workers but risky for permanent staff.
Cross-Tenant Access Settings Blocking Sync: If the target tenant has inbound B2B collaboration disabled or has a cross-tenant access policy that blocks the source tenant, sync will fail. Check cross-tenant access settings under External Identities.
Provisioning Agent Requirement: For syncing users that originate from on-premises AD, the source tenant must have the provisioning agent installed and configured. Cloud-only users do not need the agent.
Summary of Key Exam Points
Cross-tenant sync automates B2B guest user provisioning between Azure AD tenants.
It is one-way, attribute-based, and runs every 40 minutes by default.
Requires Microsoft Entra ID P1/P2 licenses in the source tenant.
Soft-delete threshold is 30 days by default.
Consent from the target tenant is mandatory.
Group-based and attribute-based scoping are supported.
Synced users are Guests or Members depending on external collaboration settings.
Integration with entitlement management allows automated access package assignment.
Common exam questions test licensing, consent, scoping, and troubleshooting.
Create a new synchronization configuration
In the source tenant, navigate to Microsoft Entra ID > Cross-tenant synchronization > Configurations. Click 'New configuration'. Enter a display name (e.g., 'Contoso-Fabrikam Sync') and specify the target tenant's domain name or tenant ID. You must be a Global Administrator or Identity Governance Administrator in the source tenant. The configuration is stored as a cross-tenant user profile sharing configuration object in the source tenant's directory. This step creates the container for all sync settings, including scoping, attribute mapping, and provisioning schedule.
Define scoping filters
Under the configuration, go to 'Provisioning' > 'Scoping filters'. You can choose group-based scoping (sync only members of one or more security groups) or attribute-based scoping (e.g., sync users where department equals 'Sales'). Group-based scoping is easier to manage but requires maintaining group membership. Attribute-based scoping is more flexible but requires consistent attribute values. If you use group-based scoping, the source tenant must have Microsoft Entra ID P1/P2 licenses for all group members. The scoping filter is evaluated during each sync cycle.
Configure attribute mappings
Go to 'Provisioning' > 'Attribute mapping'. By default, core attributes like displayName, userPrincipalName, mail, and department are mapped directly. You can modify mappings or add custom expressions. For example, to map the source department to an extension attribute in the target, use an expression like `Switch([department], "Other", "Sales", "EXT_Sales", "Engineering", "EXT_Eng")`. Each mapping has a source attribute, target attribute, and mapping type (Direct, Constant, Expression). You can also set default values if the source attribute is null. Incorrect mappings can cause sync failures, so test with a small scope first.
Obtain consent from the target tenant
After configuring mappings, go to 'Provisioning' > 'Consent'. Click 'Generate consent link'. This link must be sent to a Global Administrator in the target tenant. The target admin opens the link, reviews the permissions requested (typically 'Create and manage guest users'), and grants consent. Consent is stored as a service principal in the target tenant, representing the source tenant's provisioning application. Without consent, the sync job cannot write users to the target tenant. Consent is valid until revoked or the configuration is deleted.
Start the synchronization job
Once consent is granted, go to 'Provisioning' > 'On-demand provisioning' or simply wait for the next automatic sync (default every 40 minutes). To trigger an immediate full sync, click 'On-demand provisioning' and select 'Sync all users'. This initial sync processes all users in scope and creates guest users in the target tenant. The sync job runs as a background process; you can monitor progress in the provisioning logs. After the initial sync, delta syncs occur automatically every 40 minutes. You can change the interval via PowerShell.
Monitor and verify provisioning
Go to 'Provisioning' > 'Provisioning logs' to view detailed records of each sync cycle. Logs show the number of successes, failures, and skipped users. For each user, you can see the action (Create, Update, Delete), the source and target objects, and any error messages. Common errors include 'Duplicate attribute' (user already exists in target), 'Missing license', or 'Consent not granted'. Use the logs to troubleshoot and adjust scoping or mappings. You can also export logs to a storage account for long-term analysis.
Enterprise Scenario 1: Merger of Two Companies
Contoso has acquired Fabrikam, and both companies operate separate Azure AD tenants. Contoso needs Fabrikam employees to access a shared SharePoint site and a custom SaaS application hosted in Contoso's tenant. Without cross-tenant sync, Contoso's IT team would have to manually invite each Fabrikam employee as a guest user and update the list whenever someone joins or leaves Fabrikam. This is unsustainable for 5,000 users. By configuring cross-tenant sync from Fabrikam (source) to Contoso (target), Contoso automates guest user provisioning. They use group-based scoping to sync only Fabrikam employees in the 'Contoso Collaboration' group. Attribute mappings ensure that the userPrincipalName is preserved, and the department attribute is mapped to a custom extension attribute for access control. The sync runs every 40 minutes, so new hires are granted access within an hour. When an employee leaves Fabrikam, the guest user is soft-deleted in Contoso after 30 days. This scenario requires both tenants to have Microsoft Entra ID P1 licenses for the synced users. In production, Contoso also configures cross-tenant access settings to trust Fabrikam's MFA, so users don't get prompted again.
Enterprise Scenario 2: Multi-Tenant Strategy for Development and Production
A large enterprise uses separate tenants for development, staging, and production to isolate resources. Developers in the dev tenant need occasional access to production databases for troubleshooting. Cross-tenant sync is configured from the dev tenant (source) to the production tenant (target), but with attribute-based scoping that only syncs users whose 'accessLevel' attribute is set to 'ProdSupport'. This ensures only authorized developers are provisioned. The sync interval is set to 5 minutes (the minimum) to quickly grant access during incidents. The soft-delete threshold is reduced to 7 days because access should be revoked quickly when a developer leaves the project. The target tenant's cross-tenant access settings block all other inbound B2B invitations except from the dev tenant, enforcing security. This setup reduces the attack surface and simplifies access management.
Common Pitfalls in Production
License Overlook: The most common mistake is forgetting that the source tenant must have P1/P2 licenses for all synced users. Without licenses, the provisioning service either fails or throttles. Always verify licensing before enabling sync.
Consent Expiration: Consent links can expire if not used within a few days. Regenerate the link if the target admin delays. Also, if the target tenant revokes consent (e.g., by deleting the service principal), sync stops immediately.
Duplicate UPN Conflicts: If a user with the same UPN already exists in the target tenant (even as a deleted user in the recycle bin), the sync fails for that user. Before configuring sync, clean up duplicate or stale guest users in the target tenant.
Scoping Too Broad: Syncing all users from the source tenant can create thousands of guest users, many of whom may not need access. Use group-based or attribute-based scoping to limit the scope. Over-provisioning increases administrative overhead and security risk.
Attribute Mapping Errors: Incorrect expressions can cause sync failures. Always test with a small pilot group first. Use the provisioning logs to identify mapping errors.
Performance and Scale Considerations
Cross-tenant sync can handle up to 300,000 users per configuration. For larger populations, consider splitting into multiple configurations with different scopes. The sync job is throttled by Microsoft Graph API limits (e.g., 2000 writes per minute per app). For very large syncs (e.g., 100,000 users), the initial full sync may take several hours. Plan accordingly and avoid making changes to the configuration during the initial sync. Use the provisioning logs to monitor progress and identify bottlenecks.
What the AZ-104 Exam Tests
The AZ-104 exam covers cross-tenant synchronization under objective 1.1 (Manage identities in Microsoft Entra ID). Specifically, you should know:
How to configure cross-tenant sync (portal steps, prerequisites).
Licensing requirements (Microsoft Entra ID P1/P2 in source tenant).
The consent flow and why it's needed.
The default sync interval (40 minutes) and minimum interval (5 minutes).
The soft-delete threshold (30 days) and its configurable range.
Scoping options: group-based vs. attribute-based.
The difference between cross-tenant sync and Azure AD Connect.
Integration with entitlement management and conditional access.
Top 4 Wrong Answers and Why Candidates Choose Them
1. Wrong: 'Cross-tenant sync requires Azure AD Connect in both tenants.' Candidates confuse cross-tenant sync with Azure AD Connect. Azure AD Connect syncs on-premises AD to a single Azure AD tenant. Cross-tenant sync is cloud-to-cloud and does not require Azure AD Connect in either tenant. The correct answer is that it uses the Microsoft Entra provisioning service.
2. Wrong: 'Synced users become Members in the target tenant by default.' Candidates think that because sync is automated, users get Member privileges. In reality, the user type (Guest or Member) depends on the target tenant's external collaboration settings. By default, B2B users are Guests. You must change the 'Guest user access level' in the target tenant's external identities settings to make them Members.
3. Wrong: 'You need Microsoft Entra ID P1/P2 licenses in the target tenant for the synced users.' This is a common trap. The licensing requirement is on the source tenant, not the target. The target tenant only needs P1/P2 for the administrator configuring sync, but guest users themselves do not require licenses. However, if you assign premium features (e.g., conditional access) to guest users, you may need additional licenses.
4. Wrong: 'Cross-tenant sync can synchronize groups and group memberships.' Candidates assume that since you can scope by group, the group itself is synced. Cross-tenant sync only provisions user objects, not groups. To manage group membership, you must either use group-based scoping (which syncs members but not the group object) or use entitlement management access packages.
Specific Numbers and Terms That Appear on the Exam
Default sync interval: 40 minutes
Minimum sync interval: 5 minutes
Default soft-delete threshold: 30 days
Maximum users per configuration: 300,000
Required license: Microsoft Entra ID P1 or P2 (source tenant)
Consent is granted by a Global Administrator in the target tenant.
The provisioning service uses the Microsoft Graph API.
Synced user UPN format: user_sourceTenantDomain#EXT#@targetTenantDomain.onmicrosoft.com
Edge Cases and Exceptions the Exam Loves
What happens if the target tenant has B2B collaboration disabled? Sync fails. You must enable inbound B2B collaboration under External Identities > External collaboration settings.
What if a user is deleted in the source tenant but restored within 30 days? The guest user in the target tenant is re-enabled (soft-delete reversed).
Can you sync users from multiple source tenants to one target tenant? Yes, you can create multiple configurations, each with a different source tenant.
Does cross-tenant sync work with Azure AD B2C tenants? No, it only works with Azure AD (Microsoft Entra ID) tenants.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see a question about cross-tenant sync, remember the core mechanism: it's a one-way provisioning engine that creates B2B guest users. If an answer implies bidirectional sync, group sync, or automatic role assignment, it's likely wrong. Also, always check the licensing direction: source tenant pays, target tenant benefits. If an answer says the target tenant needs licenses for guest users, eliminate it. Use the default values (40 min, 30 days) as anchors to reject answers that mention different numbers without justification.
Cross-tenant synchronization automates B2B guest user provisioning between Azure AD tenants, one-way from source to target.
Default sync interval is 40 minutes; minimum is 5 minutes.
Soft-delete threshold is 30 days by default; configurable from 0 to 365 days.
Source tenant must have Microsoft Entra ID P1 or P2 licenses for all synced users.
Target tenant must have inbound B2B collaboration enabled and grant consent via a generated link.
Synced users are Guests by default; user type depends on target tenant's external collaboration settings.
Scoping can be group-based (members of a security group) or attribute-based (e.g., department equals 'Sales').
Cross-tenant sync does not synchronize groups, roles, or group memberships.
Integration with entitlement management allows automated access package assignment to synced users.
Cross-tenant access settings can trust MFA and device claims from the source tenant.
Maximum 300,000 users per configuration.
Common failures: missing licenses, consent not granted, duplicate UPNs, scoping filters excluding all users.
These come up on the exam all the time. Here's how to tell them apart.
Cross-Tenant Synchronization
Synchronizes users between two Azure AD tenants
One-way from source to target tenant
Creates B2B guest users in the target tenant
Uses Microsoft Entra provisioning service (cloud)
Requires Microsoft Entra ID P1/P2 in source tenant
Azure AD Connect
Synchronizes on-premises Active Directory to a single Azure AD tenant
Bidirectional for password hash sync (optional writeback)
Creates member users (not guests) in Azure AD
Requires a server running Azure AD Connect software
Requires Azure AD P1/P2 for advanced features like password writeback
Mistake
Cross-tenant sync can synchronize on-premises Active Directory users directly to another tenant.
Correct
Cross-tenant sync operates between Azure AD tenants. To sync on-premises users, you must first synchronize them to the source Azure AD tenant using Azure AD Connect or Azure AD Connect cloud sync. Then cross-tenant sync replicates the cloud user objects to the target tenant.
Mistake
Synced users automatically get the same roles and permissions as in the source tenant.
Correct
Cross-tenant sync only creates guest user objects. It does not assign any roles, group memberships, or resource access. You must manually grant access via group membership, direct assignment, or entitlement management in the target tenant.
Mistake
You need Microsoft Entra ID P1 or P2 licenses in both tenants for cross-tenant sync to work.
Correct
Licensing is required only in the source tenant for the users being synced. The target tenant does not need P1/P2 licenses for guest users. However, the target tenant admin configuring sync needs a P1/P2 license in the source tenant.
Mistake
Cross-tenant sync can synchronize users from multiple source tenants into a single target tenant in one configuration.
Correct
Each cross-tenant sync configuration supports only one source tenant and one target tenant. To sync multiple source tenants, you must create separate configurations for each source-target pair.
Mistake
If you delete a user in the source tenant, the guest user in the target tenant is immediately and permanently deleted.
Correct
By default, the guest user is soft-deleted (disabled) immediately and permanently removed after 30 days (configurable). The soft-delete allows recovery if the source user is restored within the threshold.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The source tenant must have Microsoft Entra ID P1 or P2 licenses for every user being synchronized. The target tenant does not require licenses for the guest users, but the administrator configuring the sync needs a P1/P2 license in the source tenant. If you use group-based scoping, all group members must be licensed. Without proper licensing, the provisioning service may fail or be throttled.
In the source tenant, under the sync configuration, go to 'Provisioning' > 'Consent' and click 'Generate consent link'. Send this link to a Global Administrator in the target tenant. The target admin opens the link, reviews the requested permissions (typically to create and manage guest users), and grants consent. Consent is valid until revoked or the configuration is deleted. Without consent, the sync cannot write users to the target tenant.
No, cross-tenant sync only provisions user objects (guest users). It does not create groups or synchronize group memberships. However, you can use group-based scoping to sync only the members of a specific security group. To manage group membership in the target tenant, use entitlement management access packages or manual assignment.
The corresponding guest user in the target tenant is soft-deleted (disabled) immediately. After the soft-delete threshold (default 30 days), the guest user is permanently deleted. If the user is restored in the source tenant within the threshold, the guest user is re-enabled. You can change the threshold from 0 (immediate hard-delete) to 365 days.
The default sync interval is 40 minutes. You can change it using PowerShell (Set-AzureADMSProvisioningJob -ScheduleInterval) to any value between 5 minutes and 24 hours. The minimum interval is 5 minutes. Changing the interval affects how quickly changes in the source tenant are reflected in the target tenant.
Yes, you can create multiple cross-tenant synchronization configurations, each with a different source tenant. Each configuration is independent and has its own scoping, attribute mappings, and consent. The target tenant can receive guest users from multiple sources.
Check the provisioning logs under the sync configuration in the source tenant. Logs show success, failure, and skipped records with error details. Common issues include: missing licenses, consent not granted, duplicate UPNs (user already exists in target), scoping filters excluding all users, and attribute mapping errors. Also verify that the target tenant has inbound B2B collaboration enabled.
You've just covered Cross-Tenant Synchronization — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?