+### I am active in Azure Portal, but I am logged out of other M365 Apps for inactivity. Why am I logged out?

+Azure Portal supports a similar inactivity feature, but is supported by Azure Portal only. For more information, see [Azure Portal: Signing-Out + Notification](/azure/azure-portal/set-preferences#signing-out--notifications).

+Users migrating must be present in the target tenant Exchange Online system as a _MailUser_, marked with specific attributes to enable the cross-tenant moves. The system fails to move users that aren't properly set up in the target tenant.

+After the moves are complete, the source user mailbox is converted to a `MailUser`, and the `targetAddress` (shown as _ExternalEmailAddress_ in Exchange) is stamped with the routing address to the destination tenant. This process leaves the legacy `MailUser` in the source tenant and allows for coexistence and mail routing. When business processes allow, the source tenant can remove the source MailUser or convert them to a mail contact.

+Cross-tenant Exchange mailbox migrations are supported for tenants in hybrid or cloud only, or a combination of the two.

+> Mailboxes that are on any type of hold aren't migrated, and the move for those mailboxes is blocked.

+When a mailbox is migrated cross-tenant with this feature, only user-visible content in the mailbox (email, contacts, calendar, tasks, and notes) is migrated to the target (destination tenant). After a successful migration, the source mailbox is deleted. This deletion means that after migration, under no circumstances is the source mailbox available, discoverable, or accessible in the source tenant.

+> If you are interested in previewing our new feature **Domain Sharing for email** alongside your cross-tenant mailbox migrations, complete the form at [aka.ms/domainsharingpreview](https://aka.ms/domainsharingpreview). The **Domain sharing for email** feature enables users in separate Microsoft 365 tenants to send and receive email using addresses from the same custom domain. The feature is intended to solve scenarios where users in separate tenants need to represent a common corporate brand in their email addresses. The current preview supports sharing domains indefinitely and shared domains during cross-tenant mailbox migration coexistence.

+> You must have purchased, or verified that you can purchase, cross-tenant user data migration licenses prior to the next steps. Migrations fail if this step hasn't been completed. Microsoft doesn't offer exceptions for this licensing requirement.

+Before starting, ensure that you have the necessary permissions to configure the Move Mailbox application in Azure, EXO Migration Endpoint, and the EXO Organization Relationship.

+Additionally, at least one mail-enabled security group in the source tenant is required. These groups are used to scope the list of mailboxes that can move from source tenant (or sometimes referred to as resource) to the target tenant. This scoping allows the source tenant administrator to restrict or scope the specific set of mailboxes that need to be moved, preventing unintended users from being migrated. Nested groups aren't supported.

+You also need to communicate with your trusted partner company (with whom you'll be moving mailboxes) to obtain their Microsoft 365 tenant ID. This tenant ID is used in the **Organization Relationship DomainName** field.

+To obtain the tenant ID of a subscription, sign in to the [Microsoft 365 admin center](https://go.microsoft.com/fwlink/p/?linkid=2024339) and go to [https://aad.portal.azure.com/\#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties). Select the **copy** icon for the **Tenant ID** property to copy it to the clipboard.

+All users in both the source and target organizations must be licensed with the appropriate Exchange Online subscriptions. Also, ensure that you apply Cross Tenant User Data Migration licenses to all users who will be migrated to the target side.

+> You must configure the target (destination) first. To complete these steps, you aren't required to have or know the tenant administrator credentials for both the source and target tenant. Steps can be performed individually for each tenant by different administrators.

+1. Sign in to your Azure AD portal (<https://portal.azure.com>) with your target tenant administrator credentials.

+2. Under **Manage Azure Active Directory**, select **View**.

+3. In the navigation pane, select **App registrations**.

+4. Select **New registration**.

+5. On the **Register an application** page, under **Supported account types**, select **Accounts in any organizational directory (Any Azure AD directory - Multi-tenant)**. Then, under **Redirect URI (optional)**, select **Web**, and then type `https://office.com`. Then, select **Register**.

+ On the top-right corner of the page, see the notification dialog box that states the app was successfully created.

+6. Go back to the Home page, go to **Azure Active Directory**, and then select **App registrations**.

+7. Under **Owned applications**, find the app you created, and then select it.

+8. Under **Essentials**, copy the **Application (client) ID**. You'll need this information later to create a URL for the target tenant.

+9. In the navigation pane, select **API permissions** to view permissions assigned to your app.

+10. By default, **User.Read** permissions are assigned to the app you created, but these permissions aren't required for mailbox migrations. You can remove those permissions.

+11. To add permission for mailbox migration, select **Add a permission**.

+12. In the **Request API permissions** window, select **APIs my organization uses**, search for `Office 365 Exchange Online`, and then select it.

+13. Select **Application permissions**.

+14. Under **Select permissions**, expand **Mailbox**, and check the **Mailbox.Migration** checkbox, and then select **Add permissions** at the bottom on the screen.

+15. Now select **Certificates & secrets** in the navigation pane for your application.

+16. Under **Client secrets**, select **New client secret**.

+17. In the **Add a client secret** window, type a description, and then configure your expiration settings.

+ > The password is used when creating your migration endpoint. It's extremely important that you copy this password to your clipboard and/or to a secure/secret password safe location. The secret creation stage is the only time during which you can see this password! If you do somehow lose it or need to reset it, you can sign back into the Azure portal, go to **App registrations**, find your migration app, select **Secrets & certificates**, and then create a new secret for your app.

+Now that you've successfully created the migration application and secret, the next step is to consent to the application.

+### Grant consent to the application

+1. In the Azure Active Directory landing page, select **Enterprise applications** in the navigation pane; then find your migration app you created, select it, and then select **Permissions**.

+2. Select **Grant admin consent for [your tenant]**. A new browser window opens.

+3. Select **Accept**.

+4. Go back to your portal window and select **Refresh** to confirm your acceptance.

+5. Formulate the URL to send to your trusted partner (source tenant administrator) so that they can also accept the application to enable mailbox migration.

+ Here's an example of the URL to provide to them:

+ > You'll need the application ID of the mailbox migration app you just created.

+ > You'll need to replace contoso.onmicrosoft.com in the above example with your source tenant's correct onmicrosoft.com name.

+ > You'll also need to replace [application_id_of_the_app_you_just_created] with the application ID of the mailbox migration app you just created.

+2. Create a new migration endpoint for Cross-tenant mailbox moves.

+ > You'll need the application ID of the mailbox migration app you just created and the password (secret) you configured in [Prepare the target (destination) tenant by creating the migration application and secret](#prepare-the-target-destination-tenant-by-creating-the-migration-application-and-secret). Depending on the Microsoft 365 cloud instance you use, your endpoint may be different. See the [Microsoft 365 endpoints](/microsoft-365/enterprise/microsoft-365-endpoints) page; select the correct instance for your tenant; then review the Exchange Online _Optimize/Required_ address, and replace as appropriate.

+3. Create a new organization relationship object or edit your existing organization relationship object to your source tenant.

+1. Using your browser, go to the URL link provided by your trusted partner to consent to the mailbox migration application. The URL should look like this:

+ > You'll need the application ID of the mailbox migration app you just created. You will need to replace `contoso.onmicrosoft.com` in the previous example with your source tenant's `onmicrosoft.com` URL. You'll also need to replace [application_id_of_the_app_you_just_created] with the application ID of the mailbox migration app you just created.

+2. Accept the application when the pop up appears. You can also sign in to your Azure Active Directory portal and find the application under **Enterprise applications**.

+3. [Connect to Exchange Online PowerShell](/powershell/exchange/connect-to-exchange-online-powershell) on the source Exchange Online tenant.

+4. Create a new organization relationship object or edit your existing organization relationship object to your target (destination) tenant in Exchange Online PowerShell:

+Users migrating must be present in the target tenant and Exchange Online system (as a MailUser) marked with specific attributes to enable the Cross-tenant moves. The system will fail to move users that aren't properly set up in the target tenant. The [Prerequisites for target user objects](#prerequisites-for-target-user-objects) section details the MailUser object requirements for the target tenant.

+Ensure the following objects and attributes are set in the target organization:

+> Microsoft is developing a feature to provide a secure automated method to set many of the attributes (specified below, in this section). This feature, named Cross-Tenant Identity Mapping, is currently looking for customers willing to participate in a small private preview. For more information about this pre-release feature and how it can simplify your Cross-tenant migration processes, see [Cross-Tenant Identity Mapping](cross-tenant-identity-mapping.md).

+ 1. ExchangeGUID (direct flow from source to target): The mailbox GUID must match. The move process won't proceed if this attribute isn't present on target object.

+ 2. ArchiveGUID (direct flow from source to target): The archive GUID must match. The move process won't proceed if this attribute isn't present on the target object. (This attribute is only required if the source mailbox is Archive enabled).

+ 3. LegacyExchangeDN (flow as proxyAddress, "x500:\<LegacyExchangeDN\>"): The LegacyExchangeDN must be present on target MailUser as x500: proxyAddress. **In addition, you also need to copy all x500 addresses from the source mailbox to the target mail user.** The move processes won't proceed if these x500 addresses aren't present on the target object. Also, this step is important for enabling reply ability for emails that are sent before migration. The sender/recipient address in each email item and the auto-complete cache in Microsoft Outlook and in Microsoft Outlook Web App (OWA) use the value of the LegacyExchangeDN attribute. If a user can't be located using the LegacyExchangeDN value, the delivery of email messages may fail with a 5.1.1 NDR.

+ 4. UserPrincipalName: UPN will align to the user's NEW identity or target company (for example, user@northwindtraders.onmicrosoft.com).

+ 5. Primary SMTPAddress: Primary SMTP address will align to the user's NEW company (for example, user@northwindtraders.com).

+ 6. TargetAddress/ExternalEmailAddress: MailUser will reference the user's current mailbox hosted in source tenant (for example user@contoso.onmicrosoft.com). When this value is being assigned, verify that you have/are also assigning PrimarySMTPAddress; else, this value will set the PrimarySMTPAddress, which will cause move failures.

+ 7. You can't add legacy smtp proxy addresses from source mailbox to target MailUser. For example, you can't maintain contoso.com on the MEU in northwindtraders.onmicrosoft.com tenant objects. Domains are associated with one Azure AD or Exchange Online tenant only.

+ | Attribute | Value |

+ | -- | |

+ | Alias | LaraN |

+ | RecipientType | MailUser |

+ | RecipientTypeDetails | MailUser |

+ | UserPrincipalName | LaraN@northwintraders.onmicrosoft.com |

+ | PrimarySmtpAddress | Lara.Newton@northwindtraders.com |

+ | ExternalEmailAddress | SMTP:LaraN@contoso.onmicrosoft.com |

+ | ExchangeGUID | 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8 |

+ | LegacyExchangeDN | /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara |

+ | EmailAddresses | x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara |

+ | | smtp:LaraN@northwindtraders.onmicrosoft.com |

+ | | SMTP:Lara.Newton@northwindtraders.com |

+ | | X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara |

+ Example **source** Mailbox object:

+ | Attribute | Value |

+ | -- | |

+ | Alias | LaraN |

+ | RecipientType | UserMailbox |

+ | RecipientTypeDetails | UserMailbox |

+ | UserPrincipalName | LaraN@contoso.onmicrosoft.com |

+ | PrimarySmtpAddress | Lara.Newton@contoso.com |

+ | ExchangeGUID | 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8 |

+ | LegacyExchangeDN | /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara|

+ | EmailAddresses | smtp:LaraN@contoso.onmicrosoft.com |

+ | | SMTP:Lara.Newton@contoso.com |

+ | | X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara |

+7. Other attributes may be included in Exchange hybrid write-back already. If not, they should be included.

+ 1. `msExchBlockedSendersHash` ΓÇô Writes back online safe and blocked sender data from clients to on-premises Active Directory.

+ 2. `msExchSafeRecipientsHash` ΓÇô Writes back online safe and blocked sender data from clients to on-premises Active Directory.

+ 3. `msExchSafeSendersHash` ΓÇô Writes back online safe and blocked sender data from clients to on-premises Active Directory.

+ Users in the target organization must be licensed with appropriate Exchange Online subscriptions applicable for the organization. You may apply a license in advance of a mailbox move but ONLY once the target MailUser is properly set up with ExchangeGUID and proxy addresses. Applying a license before the ExchangeGUID is applied will result in a new mailbox provisioned in target organization. You must also apply a Cross Tenant User Data Migration license; else, you may see a transient error reading **needs approval**, which will report a warning in the move report that a license hasn't been applied to the target user.

+ > [!NOTE]

+ > When you apply a license on a Mailbox or MailUser object, all SMTP type proxyAddresses are scrubbed to ensure only verified domains are included in the Exchange EmailAddresses array.

+8. You must ensure that the target MailUser has no previous ExchangeGUID that doesn't match the Source ExchangeGUID. This mismatch might occur if the target MEU was previously licensed for Exchange Online and provisioned a mailbox. If the target MailUser was previously licensed for or had an ExchangeGUID that doesn't match the Source ExchangeGUID, you need to perform a cleanup of the cloud MEU. For these cloud MEUs, you can run `Set-User <identity> -PermanentlyClearPreviousMailboxInfo`.

+> This process is irreversible. If the object has a softDeleted mailbox, it can't be restored after this point. Once cleared, however, you can synchronize the correct ExchangeGUID to the target object, and MRS will connect the source mailbox to the newly created target mailbox. (Reference EHLO blog on the new parameter.)

+Find objects that were previously mailboxes using the following command:

+Clear the soft-deleted mailbox using the following command:

+> [!NOTE]

+> Additionally, you may want to take advantage of the [Cross-tenant mailbox migration validation script](https://aka.ms/crosstenantmailboxmigrationvalidationscript), which will allow you to validate the organizations being correctly setup between them, and the objects you are planning to migrate from one tenant to another. The script will help identify any discrepancies that may be present on all objects at once, and as a result, it will reduce the time spent on the initial phase.

+If a mailbox is required to move back to the original source tenant, the same set of steps and scripts must be run in both new source and new target tenants, with some variance.

+Do not run the sample scripts provided to create the OrganizationRelationship.

+Update the following values in the existing OrganizationRelationship created in each tenant:

+- MailboxMovesCapability should have Inbound, RemoteOutbound as the capabilities in both source and target tenants.

+- In the new source tenant, update the OAuthApplicationId value with the value from the newly created application in the new source tenant.

+- In the new new source tenant, update the MailboxMovePublishedScopes value with the newly created security group in the new source tenant.

+Cross-tenant Exchange mailbox migrations are initiated from the target tenant as migration batches. This process is similar to the way on-boarding migration batches work when migrating from Exchange on-premises to Microsoft 365.

+A minimal example of a CSV file is:

+Use the [Remove-MigrationEndpoint](/PowerShell/module/exchange/remove-migrationendpoint) cmdlet to remove existing migration endpoints for source or destination servers after the migration is complete.

+Use the [Remove-OrganizationRelationship](/exchange/sharing/organization-relationships/remove-an-organization-relationship\#use-exchange-online-PowerShell-to-remove-an-organization-relationship) cmdlet to remove existing organization relationships for source or destination servers after the migration is complete.

+Items in the Outbox aren't migrated cross-tenant as this folder is a client-based folder specific to the Outlook client. Items in the Outbox are stored locally, and not synced to the cloud.

+No, the Teams chat folder content doesn't migrate cross-tenant. However, once the mailbox has been migrated cross-tenant, the Teams chat folder content will be available for source tenant administrator to search and export, using a content search.

+Since only one tenant can own a domain, the former primary SMTPAddress won't be associated to the user in the target tenant when the mailbox move completes; only those domains associated with the new tenant. Outlook uses the user's new UPN to authenticate to the service, and the Outlook profile expects to find the legacy primary SMTPAddress to match the mailbox in the target system. Since the legacy address isn't in the target system, the outlook profile won't connect to find the newly moved mailbox.

+- The first role is for a one-time setup task that establishes the authorization of moving content into or out of your tenant/organizational boundary. As moving data out of your organizational control is a critical concern for all companies, we opted for the highest assigned role of **Organization Administrator**. This role must alter or set up a new OrganizationRelationship that defines the `-MailboxMoveCapability` setting with the remote organization. Only the organization administrator can alter the `-MailboxMoveCapability` setting, while other attributes on the OrganizationRelationship can be managed by the Federated Sharing administrator.

+Exchange mailbox moves using MRS craft the targetAddress on the original source mailbox when converting to a MailUser by matching an email address (proxyAddress) on the target object. The process takes the `-TargetDeliveryDomain` value passed into the command, then checks for a matching proxy for that domain on the target side. When we find a match, the matching proxyAddress is used to set the ExternalEmailAddress (targetAddress) on the converted mailbox (now MailUser) object.

+Cross-Tenant mail flow after migration works similar to Exchange Hybrid mail flow. Each migrated mailbox needs the source MailUser with the correct target address to forward incoming mail from source tenant to mailboxes in target tenant. Transport rules, security and compliance features will run as configured in each tenant that the mail flows through. So, for inbound mail, features like anti-spam, anti-malware, quarantine, transport rules and journaling rules will run in the source tenant first, then in the target tenant.

+> Cross-tenant mailbox and calendar permissions aren't supported. You must organize principals and delegates into consolidated move batches so that these connected mailboxes are transitioned at the same time from the source tenant.

+The cross-tenant mailbox migration requires that the LegacyExchangeDN value of the source mailbox object be stamped as an x500 email address on the target MailUser object.

+> While rare, you could also run across an X400 proxy address on a mailbox, while not a requirement for the move to complete, it is recommended that you also stamp this address on the target mail user object.

+No, the source tenant and target tenant domain names must be unique, for example, a source domain of contoso.com and the target domain of northwindtraders.com.

+The mailbox is decrypted prior to moving. Ensure Customer Key is configured in the target tenant if it's still required. For more information, see [here](/microsoft-365/compliance/customer-key-overview).

+To help you plan your migration, the table present [here](/exchange/mailbox-migration/office-365-migration-best-practices#estimated-migration-times) shows the guidelines about when to expect bulk mailbox migrations or individual migrations to complete. These estimates are based on a data analysis of previous customer migrations. As every environment is unique, your exact migration velocity can vary.

+Cross-tenant migration only migrates mailbox data and nothing else. There are multiple other options, which are documented in the following blog post that may help:

+<https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455>

+Because cross-tenant migrations don't export labels and there's no way to share labels between tenants, you can only achieve this objective by recreating the labels in the destination tenant.

+No, after a cross-tenant mailbox migration, eDiscovery against the migrated user's mailbox in the source doesn't work. This eDiscovery failure is because there's no longer a mailbox in the source to search for as the mailbox has been migrated to the target tenant and now belongs to the target tenant. eDiscovery after mailbox migration can only be done in the target tenant (where the mailbox now exists). If a copy of the source mailbox needs to persist in the source tenant after migration, the administrator in the source tenant can copy the contents to an alternate mailbox pre-migration for future eDiscovery operations against the data.

+This license assignation can be done before the migration is complete, but you shouldn't assign a license prior to stamping the _ExchangeGUID_ attribute; else, the conversion of MailUser object to mailbox will fail and a new mailbox will be created instead. To mitigate this risk, it's best to wait until the migration is complete and assign licenses during the 30-day grace period.

+- Depending on your current state of hybrid Exchange, you need to verify that the on-premises directory objects have the required attributes (such as msExchMailboxGUID and proxyAddresses) populated correctly before attempting to sync to another tenant; else you'll run into issues with double mailboxes and migration failures.

+- You must take some extra steps to manage UPN transitioning, changing it on-premises once the migration has been completed for a user unless you're also moving the custom domain during a cut-over migration.

+**Issue: Auto Expanded archives cannot be migrated.** Yes, if the user in source has auto-expanding archives enabled and has additional auxiliary archives, cross-tenant mailbox migration will work. We support moving users that have no more than 12 auxiliary archive mailboxes. Additionally, users with large primary, large main archive, and large auxiliary archive mailboxes will require extra time to synchronize and should be submitted well in advance of the cut-over date. If the source mailbox is expanded during the mailbox migration process, the migration will fail as a new auxiliary archive will be created in the source, but not in the target. In this case, you'll need to remove the user from the batch and resubmit them.

+### Can I perform a cross cloud tenant to tenant migration?

+Cross cloud tenant to tenant migration is not supported. An example scenario would be moving from Office 365 Worldwide to Office 365 Government Cloud.

+### Are voicemails migrated cross tenant?

+Yes, voicemails are migrated cross tenant.

+- Received voicemails in email as attachments are available in the target mailbox.

+- Received voicemails are available in Teams if you call voicemail and listen to saved messages. (VMs received in source are available as saved messages)

+- Received voicemails are not available in Teams client UI in target post migration.

+- The voicemail greeting is also migrated to the target.

+### Are mailbox signatures migrated cross tenant?

+Mailbox signatures are not migrated cross tenant and must be recreated.

+- Post-migration Teams functionality in the source tenant will be limited. After the mailbox is migrated to the target tenant, Teams in the source tenant no longer has access to the user's mailbox. If a user signs in to Teams with the source tenant credential, there's a loss of functionality such as the inability to update their profile picture, no calendar application, and an inability to search and join public teams.

+- Cloud MailUsers with non-owned smtp proxyAddress block MRS moves. When creating target tenant MailUser objects, you must ensure that all SMTP proxy addresses belong to the target tenant organization. If an SMTP proxyAddress exists on the target mail user that doesn't belong to the local tenant, the conversion of the MailUser to a mailbox is prevented. This prevention is due to our assurance that mailbox objects can only send mail from domains for which the tenant is authoritative (domains claimed by the tenant).

+- If you synchronize users from on-premises using Azure AD Connect in the target tenant, then you can provision on-premises MailUser objects with ExternalEmailAddress pointing to the source tenant where the mailbox exists (LaraN@contoso.onmicrosoft.com), and you stamp the PrimarySMTPAddress as a domain that resides in the target tenant (Lara.Newton@northwindtraders.com). These values synchronize down to the tenant and an appropriate mail user is provisioned and is ready for migration. An example object is shown here.

+> The _contoso.onmicrosoft.com_ address is _not_ present in the EmailAddresses/proxyAddresses array.

+- MailUser objects with "external" primary SMTP addresses are modified/reset to "internal" company-claimed domains.

+ MailUser objects are pointers to non-local mailboxes. In the case for cross-tenant mailbox migrations, we use MailUser objects to represent either the source mailbox (from the target organization's perspective) or target mailbox (from the source organization's perspective). The MailUsers will have an ExternalEmailAddress (targetAddress) that points to the smtp address of the actual mailbox (ProxyTest@northwindtraders.onmicrosoft.com) and primarySMTP address that represents the displayed SMTP address of the mailbox user in the directory. Some organizations choose to display the primary SMTP address as an external SMTP address, not as an address owned/verified by the local tenant (for example, as northwindtraders.com rather than as contoso.com). However, once an Exchange service plan object is applied to the MailUser via licensing operations, the primary SMTP address is modified to show as a domain verified by the local organization (contoso.com). There are two potential reasons:

+- When any Exchange service plan is applied to a MailUser, the Azure AD process starts to enforce proxy scrubbing to ensure that the local organization isn't able to send out mail, spoof, or mail from another tenant. Any SMTP address on a recipient object with these service plans will be removed if the address isn't verified by the local organization. As is the case in the example, the northwindtraders.com domain isn't verified by the contoso.onmicrosoft.com tenant; therefore, the scrubbing removes that northwindtraders.com domain. If you wish to persist these external domains on MailUser, either before or after the migration, you need to alter your migration processes to strip licenses after the move completes or before the move to ensure that the users have the expected external branding applied. You'll need to ensure that the mailbox object is properly licensed to not affect mail service. An example script to remove the service plans on a MailUser in the contoso.onmicrosoft.com tenant is shown here.

+When `msExchRemoteRecipientType` is set to 8 (DeprovisionMailbox), for on-premises MailUsers that are migrated to the target tenant, the proxy scrubbing logic in Azure removes non-owned domains and reset the primarySMTP to an owned domain. With the msExchRemoteRecipientType in the on-premises MailUser being cleared, the proxy scrub logic no longer applies.

+ Title: Join or leave a multi-tenant organization in Microsoft 365 (Preview)

+audience: ITPro

+ms.localizationpriority: medium

+search.appverid:

+- MET150

+f1.keywords:

+- NOCSH

+description: Learn how to join or leave a multi-tenant organization in Microsoft 365.

+# Join or leave a multi-tenant organization in Microsoft 365 (Preview)

+> [!NOTE]

+> Multi-tenant organizations in Microsoft 365 is available in [targeted release](/microsoft-365/admin/manage/release-options-in-office-365).

+To join a multi-tenant organization, a global administrator in the owner organization must first add your organization to the multi-tenant organization. Once they've done that, you can join the multi-tenant organization. You'll need the tenant ID of the owner organization in order to join.

+Once you've joined, you can leave a multi-tenant organization at any time.

+#### Related settings in Azure AD

+When you join an existing multi-tenant organization, the following settings are configured in Azure Active Directory:

+- A cross-tenant synchronization configuration is added with the name *MTO_Sync_\<TenantID\>*, but no sync jobs are created yet. (If you already have a cross-tenant synchronization configuration, it remains unchanged.)

+- An organization relationship is added to the [cross-tenant access settings](/azure/active-directory/external-identities/cross-tenant-access-overview) based on the [multi-tenant organization templates](/azure/active-directory/multi-tenant-organizations/templates) for cross-tenant access and identity synchronization. (If an organizational relationship already exists, the existing one is used.)

+- The multi-tenant organization template for identity synchronization is set to allow users to sync into this tenant.

+- The multi-tenant org template for cross-tenant access will be set to automatically redeem user invitations, inbound as well as outbound.

+When you leave a multi-tenant organization, the cross-tenant access settings and cross-tenant synchronization configurations in Azure AD aren't affected.

+## Join an existing multi-tenant organization

+To join an existing multi-tenant organization in Microsoft 365

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Get started**.

+1. Select **Join an existing multitenant organization**.

+1. Enter the tenant ID of the owner organization.

+1. Select the **Allow users to sync into this tenant from the other tenants in this multitenant organization** and **Suppress consent prompts for users from the other tenant when they access apps and resources in my tenant** check boxes.

+1. Select **Next**.

+1. Select **Done**.

+It can take up to four hours for your tenant to be joined to the multi-tenant organization.

+> [!NOTE]

+> If you encounter an error when joining the multi-tenant organization, try again after two hours. If the error reoccurs, contact Microsoft support.

+The next step after you join the multi-tenant organization is to synchronize your users with the other tenants. For details, see [Synchronize users in multi-tenant orgs in Microsoft 365](sync-users-multi-tenant-orgs.md).

+## Leave a multi-tenant organization

+You can leave a multi-tenant organization as long as your tenant isn't the last owner tenant in the multi-tenant organization. You can also remove other member tenants.

+To remove a tenant from a multi-tenant organization in Microsoft 365

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select the check box next to the tenant you want to remove.

+1. Select **Remove tenant**.

+1. Read the details regarding tenant removal in the side panel, and then select **Remove tenant**.

+Removing a tenant doesn't change any user synchronization configurations or cross-tenant access settings in Azure AD. We recommend you review these settings and make any updates needed after the tenant is removed.

+#### Remove synchronized users from other tenants

+When you remove a tenant from a multi-tenant organization, you may want to stop synchronizing users between that tenant and the tenants that remain in the multi-tenant organization. This can be done by updating the cross-tenant synchronization configuration in Azure AD and removing the security groups being synchronized, then restarting the synchronization with zero users.

+Cross-tenant synchronization configurations for multi-tenant organizations that were created in the Microsoft 365 admin center are named *MTO_Sync_\<TenantID\>* in Azure AD cross-tenant synchronization.

+To remove the cross-synchronized users:

+- For the tenant that is leaving the multi-tenant organization, update the synchronization configurations for each remaining tenant in the multi-tenant organization where you're synchronizing users.

+- For each tenant that's remaining in the multi-tenant organization, update the synchronization configuration for the tenant that's leaving.

+To remove your users from other tenants in a multi-tenant organization

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as a Global administrator.

+1. Expand **Identity**, and then expand **External Identities**.

+1. Select **Cross-tenant synchronization**.

+1. Select **Configurations**.

+1. Select the link for the configuration you want to update.

+1. Select **Users and groups**

+1. Select the check boxes for the security groups that you want to remove, and then select **Remove**.

+1. Select **Overview**.

+1. Select **Restart provisioning**.

+Once the users have been removed from the other tenants' directories, you can stop provisioning for the synchronization configurations or delete them.

+#### Stop user sync and automatic invitation redemption

+Once you remove a tenant from a multi-tenant organization, you may want to stop user sync and automatic invitation redemption with the tenants that remain in the multi-tenant organization.

+To prevent user sync and automatic invitation redemption:

+- For the tenant that is leaving the multi-tenant organization, update the cross-tenant access settings for each tenant that's remaining in the multi-tenant organization.

+- For each tenant that's remaining in the multi-tenant organization, update the cross-tenant access settings for the tenant that's leaving.

+To prevent user sync and automatic invitation redemption

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as a Global administrator.

+1. Expand **Identity**, and then expand **External Identities**.

+1. Select **Cross-tenant access settings**.

+1. On the **Organizational settings** tab, select the link for the **Inbound access** settings for the tenant you want to update.

+ 1. On the **Trust settings** tab, clear the **Automatically redeem invitations with the tenant \<organization\>** check box.

+ 1. On the **Cross-tenant sync** tab, clear the **Allow users sync into this tenant** check box.

+ 1. Select **Save**.

+1. Select the link for the **Outbound access** settings for the tenant you want to update.

+ 1. On the **Trust settings** tab, clear the **Automatically redeem invitations with the tenant \<organization\>** check box.

+ 1. Select **Save**.

+For more information about cross-tenant access settings, see [Configure cross-tenant access settings for B2B collaboration](/azure/active-directory/external-identities/cross-tenant-access-settings-b2b-collaboration).

+## Related topics

+[Configure cross-tenant synchronization](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure)

+[Overview: Cross-tenant access with Azure AD External Identities](/azure/active-directory/external-identities/cross-tenant-access-overview)

+[Plan for multi-tenant organizations in Microsoft 365](plan-multi-tenant-org-overview.md)

+[Set up a multi-tenant org in Microsoft 365](set-up-multi-tenant-org.md)

+[Synchronize users in multi-tenant organizations in Microsoft 365](sync-users-multi-tenant-orgs.md)

+ Title: Plan for multi-tenant organizations in Microsoft 365 (Preview)

+audience: ITPro

+ms.localizationpriority: medium

+search.appverid:

+- MET150

+f1.keywords:

+- NOCSH

+description: Learn how to plan for multi-tenant organizations in Microsoft 365.

+# Plan for multi-tenant organizations in Microsoft 365 (Preview)

+> [!NOTE]

+> Multi-tenant organizations in Microsoft 365 is available in [targeted release](/microsoft-365/admin/manage/release-options-in-office-365).

+If your organization manages multiple Microsoft 365 tenants, you can set up a multi-tenant organization in Microsoft 365 to facilitate collaboration and resource access between tenants. Creating a multi-tenant organization and synchronizing users between tenants provides a more seamless collaboration experience between the users in different tenants when [searching for each other](/microsoft-365/enterprise/multi-tenant-people-search), using Teams and meetings, and collaborating on files.

+The tenant that creates the multi-tenant organization is known as the *owner* while other tenants that join the multi-tenant organization are known as *members*. Once the global administrator in the owner tenant creates the multi-tenant organization, they can invite member tenants. A global administrator in each member tenant can then join the multi-tenant organization.

+While you configure Microsoft 365 multi-tenant organizations in the Microsoft 365 admin center, much of the supporting infrastructure is in Azure Active Directory (Azure AD). For details about how multi-tenant organizations work in Azure AD, see [What is a multi-tenant organization in Azure Active Directory?](/azure/active-directory/multi-tenant-organizations/overview) and [Topologies for cross-tenant synchronization](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-topology).

+## User synchronization between tenants

+Multi-tenant organizations synchronize users between tenants using Azure AD B2B collaboration users. Users from your tenant are provisioned in the other tenants in the multi-tenant organization as B2B collaboration users, but with a user type of member rather than guest. (See [What are the default user permissions in Azure Active Directory?](/azure/active-directory/fundamentals/users-default-permissions) for the differences between these roles.)

+We recommend starting with a small set of users before rolling out to the entire organization. When you do the complete rollout, we highly recommend synchronizing all users across all tenants in your multi-tenant organization for the best user experience. However you can synchronize a subset of users if you need to, including different users to different tenants.

+When you configure user synchronization in the Microsoft 365 admin center, the same users and groups are synchronized to all tenants in the multi-tenant organization. Synchronizing different users to different tenants must be configured in Azure AD.

+Once user synchronization has been configured, you can adjust the synchronization settings, including user scope and attribute mapping, in Azure AD. (While you can create multiple cross-tenant synchronization configurations for a single external tenant, we recommend that you only use one for ease of administration.) For more information, see [Configure cross-tenant synchronization](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure).

+#### Existing cross-tenant synchronization configurations

+If you have existing cross-tenant synchronization configurations in Azure AD, they continue to operate after you set up a multi-tenant organization in Microsoft 365. You can continue to use these configurations to synchronize users for your Microsoft 365 multi-tenant organization. (Note that the Microsoft 365 admin center won't recognize these configurations and the outbound sync status will show as not configured.)

+You can synchronize users between tenants using the Microsoft 365 admin center. This will create new cross-tenant synchronization configurations in Azure AD. Both the new and previously existing configurations will run and synchronize the users that you've specified.

+We recommend that you only have a single configuration to synchronize users to a given tenant. If you want to synchronize the same users to every tenant, [configure synchronization in the Microsoft 365 admin center](sync-users-multi-tenant-orgs.md). If you want to synchronize different users to different tenants, [configure synchronization in Azure AD](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure).

+## Cross-tenant access settings in Azure AD

+When you create a new multi-tenant organization or join an existing one, the other organizations in the multi-tenant organization are added to the [Azure AD cross-tenant access settings](/azure/active-directory/external-identities/cross-tenant-access-overview) in your tenant.

+If you already have an organizational relationship configured in Azure AD with a tenant that you're adding to a multi-tenant organization, the existing configuration is updated as follows:

+- The inbound cross-tenant sync settings are updated to allow users to sync into your tenant.

+- The outbound trust settings are updated so users from this tenant don't have to accept the consent prompt the first time they access the other tenant using cross-tenant synchronization, B2B collaboration, or B2B direct connect (shared channels).

+We recommend that you check the B2B collaboration settings for pre-existing organizational relationships to ensure the appropriate users and apps are allowed.

+## The new Microsoft Teams desktop client

+For the best experience in multi-tenant organizations, users need [the new Microsoft Teams desktop client](/microsoftteams/new-teams-desktop-admin). With the new Teams desktop client, users can:

+- Receive real-time notifications from all the tenants in your multi-tenant organization

+- Participate in chats, meetings, and calls across all of the tenants without dropping from a call or meeting to switch tenants.

+- Set their status for each account and organization individually.

+- User profile card shows organization name and email address

+To control which users can use the new Teams desktop client, use the Teams update policies. For more information, see [Deploy the new Teams using policies](/microsoftteams/new-teams-deploy-using.-policies)

+## Trusted organizations in external access

+External access is required for chats and calls between tenants. External access for Teams and Skype for Business users in external organizations must be configured for each tenant in your multi-tenant organization and must allow the domains of all the tenants in your multi-tenant organization. Additionally, all the users that you synchronize between tenants must be enabled for external access with Teams and Skype for Business users in external organizations. For details, see [Manage external meetings and chat with people and organizations using Microsoft identities](/microsoftteams/trusted-organizations-external-meetings-chat).

+## Shared channels in multi-tenant organizations

+Using [shared channels in Teams](/microsoftteams/shared-channels) with other tenants in a multi-tenant organization works the same as using shared channels with any other external organization. While the organizational relationship in Azure AD is configured as part of multi-tenant organization configuration, you must still enable shared channels in Teams and configure the B2B direct connect settings in Azure AD. For details, see [Collaborate with external participants in a shared channel](/microsoft-365/solutions/collaborate-teams-direct-connect).

+## Limitations for multi-tenant organizations in Microsoft 365 preview

+The following are limitations of the multi-tenant organizations in Microsoft 365 preview:

+- A maximum of five tenants in the multi-tenant organization is supported.

+- A maximum of 100,000 users per tenant is supported.

+- Teams on the web, macOS, Microsoft Teams Rooms (MTR), and VDI/AVD aren't supported.

+- The ability to grant or revoke permission to receive notifications from other tenants and to switch between tenants isn't supported on mobile.

+- *People in your organization* links may not work for users from another tenant if their account had originally been a guest and they had previously accessed SharePoint resources.

+- It might take up to seven days for a user to appear in search once they've been synchronized. Contact Microsoft support if users aren't searchable after seven days.

+If you want to add more than five tenants or 100,000 users per tenant, contact Microsoft support.

+## Set up or join a multi-tenant organization

+To set up a new multi-tenant organization where your tenant is the owner, see [Set up a multi-tenant organization in Microsoft 365](set-up-multi-tenant-org.md).

+To join an existing multi-tenant organization as a member tenant, see [Join or leave a multi-tenant organization in Microsoft 365](join-leave-multi-tenant-org.md).

+## Related topics

+[Configure a multi-tenant organization using Microsoft Graph API](/azure/active-directory/multi-tenant-organizations/configure-graph)

+[Synchronize users in multi-tenant organizations in Microsoft 365](sync-users-multi-tenant-orgs.md)

+ Title: Set up a multi-tenant org in Microsoft 365 (Preview)

+audience: ITPro

+ms.localizationpriority: medium

+search.appverid:

+- MET150

+f1.keywords:

+- NOCSH

+description: Learn how to set up a multi-tenant org in Microsoft 365.

+# Set up a multi-tenant org in Microsoft 365 (Preview)

+> [!NOTE]

+> Multi-tenant organizations in Microsoft 365 is available in [targeted release](/microsoft-365/admin/manage/release-options-in-office-365).

+You can set up a multi-tenant organization or add tenants to an existing one in the Microsoft 365 admin center.

+When each external tenant accepts the invitation to join the multi-tenant organization, the following settings are configured in Azure AD:

+- A cross-tenant synchronization configuration is added with the name *MTO_Sync_\<TenantID\>*, but no sync jobs are created yet. (If you already have a cross-tenant synchronization configuration, it remains unchanged.)

+- An organization relationship is added to the [cross-tenant access settings](/azure/active-directory/external-identities/cross-tenant-access-overview) based on the [multi-tenant organization templates](/azure/active-directory/multi-tenant-organizations/templates) for cross-tenant access and identity synchronization. (If an organizational relationship already exists, the existing one is used.)

+- The multi-tenant organization template for identity synchronization is set to allow users to sync into this tenant.

+- The multi-tenant org template for cross-tenant access will be set to automatically redeem user invitations, inbound as well as outbound.

+## Set up a new multi-tenant organization

+To set up a new multi-tenant org in Microsoft 365

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Get started**.

+1. Select **Create a new multitenant organization**, and then select **Next**.

+1. Type a name and description for the multi-tenant org.

+1. Enter the tenant IDs of any tenants that you want to invite to this org.

+1. Select **Next**.

+1. Select the **Allow users to sync into this tenant from the other tenants in this multitenant organization** and **Suppress consent prompts for users from the other tenant when they access apps and resources in my tenant** check boxes.

+1. Select **Create multitenant organization**.

+1. Copy the instructions for joining the multi-tenant org and email them to a global administrator in each of the orgs you invited.

+1. Select **Done**.

+The next step after each external tenant accepts the invitation to join the multi-tenant organization is to synchronize your users with the other tenants. For details, see [Synchronize users in multi-tenant orgs in Microsoft 365](sync-users-multi-tenant-orgs.md).

+## Add a tenant to your multi-tenant organization

+To add a tenant to your multi-tenant organization

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Add new tenants**.

+1. Enter the tenant IDs of the tenants you want to add, and then select **Add tenant**.

+1. Copy the instructions for joining the multi-tenant org and email them to a global administrator in each of the orgs you invited.

+1. Select **Done**.

+The next step after each external tenant accepts the invitation to join the multi-tenant organization is to synchronize your users with the other tenants. For details, see [Synchronize users in multi-tenant orgs in Microsoft 365](sync-users-multi-tenant-orgs.md).

+## Related topics

+[Set up a multi-tenant organization using Microsoft Graph API](/azure/active-directory/multi-tenant-organizations/configure-graph#step-2-create-a-multi-tenant-organization)

+[Plan for multi-tenant organizations in Microsoft 365](plan-multi-tenant-org-overview.md)

+[Join or leave a multi-tenant organization in Microsoft 365](join-leave-multi-tenant-org.md)

+[Synchronize users in multi-tenant organizations in Microsoft 365](sync-users-multi-tenant-orgs.md)

+ Title: Synchronize users in multi-tenant organizations in Microsoft 365 (Preview)

+audience: ITPro

+ms.localizationpriority: medium

+search.appverid:

+- MET150

+f1.keywords:

+- NOCSH

+description: Learn how to manage user sync in multi-tenant organizations in Microsoft 365.

+# Synchronize users in multi-tenant organizations in Microsoft 365 (Preview)

+> [!NOTE]

+> Multi-tenant organizations in Microsoft 365 is available in [targeted release](/microsoft-365/admin/manage/release-options-in-office-365).

+For users in your tenant to be able to collaborate with those in other tenants, you must synchronize your users to the other tenants.

+We recommend that you [set up security groups in Azure AD](/azure/active-directory/fundamentals/how-to-manage-groups) and add the users that you want to synchronize. Note that users must be members of the security group - owners of the group aren't synchronized.

+There are two ways to set up user synchronization:

+- Share your users with other tenants in a multi-tenant organization by using the Microsoft 365 admin center (covered in this article)

+- [Configure user synchronization in Azure AD](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure)

+Both methods use cross-tenant synchronization in Azure AD.

+If you want to synchronize the same users with all the other tenants in a multi-tenant organization, we recommend sharing users in the Microsoft 365 admin center. This will create the necessary configurations in Azure AD for you.

+If you want to synchronize different users to different tenants, then you must configure cross-tenant synchronization directly in Azure AD.

+While you can create multiple cross-tenant synchronization configurations for a single external tenant, we recommend that you only use one for ease of administration.

+> [!NOTE]

+> It may take up to 24 hours for synced users to be available in Microsoft 365 services such as Teams and SharePoint.

+For more information about cross-tenant synchronization, see [What is cross-tenant synchronization?](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview).

+If you have issues with user synchronization check the [provisioning logs in Azure Active Directory](/azure/active-directory/reports-monitoring/concept-provisioning-logs).

+## User property synchronization

+When you set up user synchronization with another tenant in a multi-tenant organization, the following user properties are synchronized:

+|Property|Property|

+|:-|:-|

+|accountEnabled|physicalDeliveryOfficeName|

+|alternativeSecurityIds|postalCode|

+|city|preferredLanguage|

+|country|showInAddressList|

+|department|state|

+|displayName|streetAddress|

+|employeeId|surname|

+|givenName|telephoneNumber|

+|IsSoftDeleted|userPrincipalName|

+|jobTitle|UserType (member)|

+|mailNickname||

+You can change the properties that are synchronized after the synchronization has been configured. For more information, see [Configure cross-tenant synchronization](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure#step-9-review-attribute-mappings).

+## Users synchronized to your tenant from other tenants

+Users synchronized to your tenant from other tenants in your multi-tenant organization are synchronized as [Azure AD members rather than guests](/azure/active-directory/external-identities/user-properties).

+As members, people from other tenants have a more seamless collaboration experience. This includes access to files using [*people in your organization* sharable links](/sharepoint/shareable-links-anyone-specific-people-organization). (Consider using [sensitivity labels](/purview/sensitivity-labels) if you need to limit who can access a file with a *people in your organization* link.)

+If some people from the other tenant already have guest accounts in your directory, the synchronization process doesn't change their user type to member. You can change these users' user type to member by [updating the user properties in Azure AD](/azure/active-directory/fundamentals/how-to-manage-user-profile-info).

+## Set up initial user synchronization for a multi-tenant organization

+To synchronize identities to other tenants in a multi-tenant organization

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Share users**.

+1. Select **Select users and groups to share**.

+1. Choose the security group that you created, and then select **Save**.

+1. Select **Yes** to confirm.

+This creates a cross-tenant synchronization configuration in Azure AD for each tenant in your multi-tenant organization. The synchronization configurations are named *MTO_Sync_\<TenantID\>*.

+## Set up user synchronization with newly added tenants

+If you add additional tenants to your multi-tenant organization, you need to set up user synchronization with those tenants.

+To set up user synchronization with newly added tenants

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Share users**.

+1. Select **Share current user scope**.

+1. Select **Yes** to confirm.

+## Change which users are synchronized with other tenants

+You can change which users are synchronized to other tenants in your multi-tenant organization.

+To change which users are synchronized to other tenants

+1. In the Microsoft 365 admin center, expand **Settings**.

+1. Select **Org settings**.

+1. On the **Organization profile** tab, select **Multitenant collaboration**.

+1. Select **Share users**.

+1. Select **Edit shared users and groups**.

+1. Update the users and groups that you want to sync to other tenants and then select **Save**.

+1. Select **Yes** to confirm.

+This procedure updates the *MTO_Sync_\<TenantID\>* synchronization configurations in Azure AD for each tenant in your multi-tenant organization.

+## Related topics

+[Troubleshooting tips for multi-tenant organizations](/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-configure#troubleshooting-tips)

+[Known issues for provisioning in Azure Active Directory](/azure/active-directory/app-provisioning/known-issues?pivots=cross-tenant-synchronization)

+[Plan for multi-tenant organizations in Microsoft 365](plan-multi-tenant-org-overview.md)

+[Set up a multi-tenant org in Microsoft 365](set-up-multi-tenant-org.md)

+[Join or leave a multi-tenant organization in Microsoft 365](join-leave-multi-tenant-org.md)

+[Scoping users or groups to be provisioned with scoping filters](/azure/active-directory/app-provisioning/define-conditional-rules-for-provisioning-user-accounts?pivots=cross-tenant-synchronization)

+|Queue|Monitor scheduled and on-demand appointments, with status updates in real time.|

+Use this report to gain insight into overall user activity and usage per feature in your organization. This information can help you analyze trends, identify which users are using these advanced features the most, and measure business value.

+The graph provides an overview of feature usage. It changes depending on the date range you select. The table shows feature usage by individual users.

+|**3** |You can filter what you see on the chart by selecting an item. For example, select **Total Text Message Users**, **Total On-Demand Users**, or **Total Queue Users**, to see only the info related to each one. Changing this selection doesnΓÇÖt change the information in the table.|

+|**4** |This table shows detailed usage information for each user in your organization during the selected date range. <ul><li>**Primary** is the name of the user.</li><li>**Primary's email** is the email address of the user.</li><li>**Total Appointments** shows the total number of virtual appointments in which the user used an advanced feature.</li><li>**SMS** shows the total number of times the user used SMS in a virtual appointment.</li><li>**On-demand** shows the total number of times the user joined an on-demand appointment by selecting **Join** on the **Queue** tab in the Virtual Appointments app.</li><li>**Queue** shows the total number of times the user navigated to the **Queue** tab in the Virtual Appointments app.</li></ul>

+> - api-au.securitycenter.microsoft.com

+> This article explains the data storage and privacy details related to Defender for Endpoint and Defender for Business. For more information related to Defender for Endpoint and other products and services like Microsoft Defender Antivirus and Windows, see [Microsoft Privacy Statement](https://go.microsoft.com/fwlink/?linkid=827576), and also [Windows privacy FAQ](https://go.microsoft.com/fwlink/?linkid=827577).

+Microsoft Defender for Endpoint will collect information from your configured devices and store it in a customer-dedicated and segregated tenant specific to the service for administration, tracking, and reporting purposes.

+Information collected includes file data (file names, sizes, and hashes), process data (running processes, hashes), registry data, network connection data (host IPs and ports), and device details (device identifiers, names, and the operating system version).

+Microsoft doesn't use your data for advertising.

+The Defender for Endpoint service utilizes state-of-the-art data protection technologies which are based on Microsoft Azure infrastructure.

+There are various aspects relevant to data protection that our service takes care of. Encryption is one of the most critical aspects, and it includes data encryption at rest, encryption in flight, and key management with Key Vault. For more information on other technologies used by the Defender for Endpoint service, see [Azure encryption overview](/azure/security/security-azure-encryption-overview).

+Defender for Endpoint operates in the Microsoft Azure data centers in the European Union, the United Kingdom, the United States, or in Australia. Customer data collected by the service may be stored in: (a) the geo-location of the tenant as identified during provisioning or, (b) the geo-location as defined by the data storage rules of an online service if this online service is used by Defender for Endpoint to process such data. For more information, see [Where your Microsoft 365 customer data is stored](/microsoft-365/enterprise/o365-data-locations).

+Select **Need help?** in the Microsoft 365 Defender portal to contact Microsoft support about provisioning Microsoft 365 Defender in a different data center location.

+Microsoft Defender for Endpoint shares data, including customer data, among the following Microsoft products, also licensed by the customer.

+Yes, your data is isolated through access authentication and logical segregation based on customer identifier. Each customer can only access data collected from its own organization, and the generic data that Microsoft provides.

+Microsoft developers and administrators have, by design, been given sufficient privileges to carry out their assigned duties to operate and evolve the service. Microsoft deploys combinations of preventive, detective, and reactive controls including the following mechanisms to help protect against unauthorized developer and/or administrative activities:

+Access to data for services deployed in Microsoft Azure Government data centers is only granted to operating personnel who have been screened and approved to handle data that's subject to certain government regulations and requirements, such as FedRAMP, NIST 800.171 (DIB), ITAR, IRS 1075, DoD L4, and CJIS.

+No. Customer data is isolated from other customers and isn't shared. However, threat intelligence on the data resulting from Microsoft processing, and which doesn't contain any customer-specific data, might be shared with other customers. Each customer can only access data collected from its own organization and generic data that Microsoft provides.

+Data from Microsoft Defender for Endpoint is retained for 180 days, visible across the portal. However, in the advanced hunting investigation experience, it's accessible via a query for a period of 30 days.

+Microsoft provides customers with detailed information about Microsoft's security and compliance programs, including audit reports and compliance packages, to help them assess Defender for Endpoint services against their own legal and regulatory requirements. Defender for Endpoint has achieved a number of certifications including ISO, SOC, FedRAMP High, and PCI and continues to pursue additional national, regional, and industry-specific certifications.

+By providing customers with compliant, independently verified services, Microsoft makes it easier for them to achieve compliance for the infrastructure and applications they run.

+|[Corrata](https://go.microsoft.com/fwlink/?linkid=2081148)|Mobile solution - Protect your mobile devices with granular visibility and control from Corrata

+ > The current SHA256 hash of 'XMDEClientAnalyzerBinary.zip' that is downloaded from the above link is: '32f1d67448773e3eda5b26cab332ccf9686ad9740be8a9624d7d02347b0af365'

+ echo '32f1d67448773e3eda5b26cab332ccf9686ad9740be8a9624d7d02347b0af365 XMDEClientAnalyzerBinary.zip' | sha256sum -c

+ echo '78e8f2078313ff2d3314c0c992ec5af370b5940a7adf7e416a5224d31d2691e5 XMDEClientAnalyzer.zip' | sha256sum -c

+Microsoft 365 Defender operates in Microsoft Azure data centers in the European Union, the United Kingdom, the United States, and in Australia. Customer data collected by the service is stored at rest in (a) the geo-location of the tenant as identified during provisioning or, (b) the geo-location as defined by the data storage rules of an online service if this online service is used by Microsoft 365 Defender to process such data.