跨租用戶信箱移轉

發行項
03/07/2024

在合併或合併期間，您可能需要能夠將使用者的 Exchange Online 信箱移至新的租使用者。跨租使用者信箱移轉可讓租用戶系統管理員使用 Exchange Online PowerShell 和 MRS 等已知介面，將用戶轉換到其新組織。

系統管理員可以使用可透過移動信箱管理角色取得的 New-MigrationBatch Cmdlet 來執行跨租用戶移動。

移轉的用戶必須以 MailUser 的身分出現在目標租使用者 Exchange Online 系統中，並標示特定屬性，才能啟用跨租用戶移動。系統無法移動目標租使用者中未正確設定的使用者。

移動完成之後，來源使用者信箱會轉換成 MailUser，而 targetAddress Exchange) 中顯示為 ExternalEmailAddress 的 (會加上目的地租使用者的路由位址。此程式會將舊 MailUser 版保留在來源租使用者中，並允許共存和郵件路由。當商務程式允許時，來源租使用者可以移除來源 MailUser，或將其轉換成郵件聯繫人。

跨租使用者 Exchange 信箱移轉僅支援混合式或雲端中的租使用者，或兩者的組合。

本文說明跨租使用者信箱移動的程式，並提供如何針對 Exchange Online 信箱內容移動準備來源和目標租使用者的指引。

重要事項

任何保留類型的信箱不會移轉，而且會封鎖這些信箱的移動。

使用這項功能跨租使用者移轉信箱時，只有信箱中用戶可見的內容 (電子郵件、聯繫人、行事歷、工作和記事) 會移轉至目標 (目的地租使用者) 。成功移轉之後，會刪除來源信箱。此刪除表示在移轉之後，來源租用戶中沒有任何可用、可探索或可存取的來源信箱。

授權

重要事項

自 2022 年 11 月起， 跨租使用者用戶數據遷移 可作為 Enterprise 合約客戶下列 Microsoft 365 訂閱方案的附加元件，且跨租使用者移轉是必要的。用戶授權是每個移轉 (一次性費用) ，而且可以在來源或目標用戶物件上指派。此授權也涵蓋商務用 OneDrive 移轉。如需詳細資訊，請連絡您的 Microsoft 帳戶小組。

跨租用戶用戶數據遷移附加元件是以 Microsoft 365 商務基本版、標準版和進階版的個別購買方式提供;Microsoft 365 F1/F3/E3/E5/;Office 365 F3/E1/E3/E5;Exchange Online;SharePoint Online;和商務用 OneDrive。

警告

在後續步驟之前，您必須先購買或驗證是否可以購買跨租使用者用戶數據遷移授權。如果此步驟尚未完成，移轉就會失敗。 Microsoft 不會針對此授權需求提供例外狀況。

如果您未將適當的授權指派給正在移轉的使用者，則移轉會失敗，而且您會收到類似下列的錯誤：

Error: CrossTenantMigrationWithoutLicensePermanentException: No license was found for the source recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87', or the target recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87'. A Cross-tenant User Data Migration license is required to move a mailbox between tenants.

準備來源和目標租使用者

來源和目標租使用者的必要條件

開始之前，請確定您具有在 Azure 中設定移動信箱應用程式、EXO 移轉端點和 EXO 組織關聯性的必要許可權。

此外，來源租使用者中至少需要一個啟用郵件功能的安全性群組。這些群組可用來設定信箱清單的範圍，這些信箱可以從來源租使用者移 (或有時稱為資源) 至目標租使用者。此範圍可讓來源租用戶系統管理員限制或限定需要移動的特定信箱集合，以防止非預期的使用者移轉。

如果您要移轉超過10,000位使用者，建議您建立多個群組來包含使用者清單，以獲得最佳效能。雖然支援巢狀群組，但不建議使用這些群組。

您也需要與信任的合作夥伴公司 (通訊，您會將信箱移) 以取得其 Microsoft 365 租使用者識別碼。此租使用者識別碼用於 [ 組織關聯性網域名稱] 欄 位。

若要取得訂用帳戶的租使用者標識碼，請登入 Microsoft 365 系統管理中心並移至 https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties。選取 [租使用者標識符] 屬性的複製圖示，將它複製到剪貼簿。

來源和目標組織中的所有用戶都必須獲得適當的 Exchange Online 訂用帳戶授權。此外，請確定您將跨租使用者用戶數據遷移授權套用至所有將移轉至目標端的使用者。

啟用租用戶進行跨租使用者信箱移轉的設定步驟

注意事項

您必須先設定目標 (目的地)。若要完成這些步驟，您不需要同時擁有或知道來源和目標租使用者的租用戶系統管理員認證。不同系統管理員可以針對每個租使用者個別執行步驟。

建立移移應用程式和密碼以準備目標 (目的地) 租使用者

使用目標租用戶系統管理員認證 (https://portal.azure.com) 登入您的 Microsoft Entra 系統管理中心。
在 [管理 Microsoft Entra ID] 底下，選取 [ 檢視]。
在瀏覽窗格中，選取 [ 應用程式註冊]。
選取 [新增註冊]。
在 [ 註冊應用程式] 頁面的 [ 支持的帳戶類型] 底下，選 取 [任何組織目錄中的帳戶 (任何 Microsoft Entra 目錄 - 多租使用者) 。然後，在 [ 重新導向 URI] 下 (選擇性) ，選取 [Web]，然後輸入 https://office.com。然後，選取 [ 註冊]。

在頁面右上角，查看指出應用程式已成功建立的通知對話方塊。
返回首頁，移至 [Microsoft Entra ID]，然後選取 [ 應用程式註冊]。
在 [ 擁有的應用程式] 底下，尋找您建立的應用程式，然後選取它。
在 [基本資訊] 底下，複製 [應用程式 (用戶端) 標識符。您稍後將需要這項資訊，才能建立目標租使用者的URL。
在瀏覽窗格中，選取 [API 許可權] 以檢視指派給您應用程式的許可權。
根據預設， User.Read 許可權會指派給您建立的應用程式，但信箱移轉不需要這些許可權。您可以移除這些許可權。
若要新增信箱移轉的許可權，請選取 新增許可權。
在 [ 要求 API 許可權 ] 視窗中，選取 [我的組織使用的 API]、搜尋 Office 365 Exchange Online，然後選取它。
選取 應用程式權限。
在 [ 選取許可權] 下，展開 [信箱 ]，然後選取 [Mailbox.Migration]，然後選取畫面底部的 [ 新增許可權]。
現在，在應用程式的瀏覽窗格中選 取 [憑證 & 秘密 ]。
在 [用戶端秘密] 底下，選取 [新增客戶端密碼]。
在 [ 新增客戶端密碼 ] 視窗中，輸入描述，然後設定您的到期設定。

注意事項

建立移轉端點時會使用密碼。請務必將此密碼複製到剪貼簿和/或安全/秘密密碼安全位置。秘密建立階段是您唯一可以看到此密碼的時間！如果您不知怎麼遺失或需要重設它，您可以重新登入 Azure 入口網站、移至 [應用程式註冊]、尋找您的移轉應用程式、選取 [ 秘密 & 憑證]，然後為您的應用程式建立新的秘密。

既然您已成功建立移轉應用程式和秘密，下一個步驟是同意應用程式。

在 [Microsoft Entra ID] 登陸頁面的瀏覽窗格中，選取 [企業應用程式 ];然後尋找您建立的移轉應用程式、加以選取，然後選取 [API 許可權]。
選 取 [授與 [您的租使用者] 的管理員同意。新的瀏覽器視窗隨即開啟。
選取 [接受]。
返回入口網站視窗，然後選取 [ 重新整理] 以確認接受。
制訂 URL 以傳送至信任的合作夥伴 (來源租使用者系統管理員) ，讓他們也可以接受應用程式來啟用信箱移轉。

以下是要提供給它們的 URL 範例：

https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

注意事項

您需要您剛才建立的信箱移轉應用程式的應用程式識別碼。您必須將上述範例中的 contoso.onmicrosoft.com 取代為來源租用戶的正確 onmicrosoft.com 名稱。您也必須將 [application_id_of_the_app_you_just_created] 取代為您剛才建立的信箱移轉應用程式的應用程式識別碼。

建立 Exchange Online 移轉端點和組織關係，以準備目標租使用者

聯機到目標 Exchange Online 租使用者中的 Exchange Online PowerShell 。

建立跨租使用者信箱移動的新移轉端點。

注意事項

您需要您剛建立的信箱移轉應用程式的應用程式識別碼，以及您在建立移轉應用程式和) 秘密來準備目標 (目的地) 租使用者中設定的密碼 (密碼。視您使用的 Microsoft 365 雲端實例而定，您的端點可能會不同。請參閱 Microsoft 365 端點頁面;為您的租用戶選取正確的實例;然後檢閱 Exchange Online 優化/必要 位址，並適當地取代。

# Enable customization if tenant is dehydrated
$dehydrated=Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$AppId = "[Guid copied from the migrations app]"
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the 
previous steps]" -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId

建立新的組織關聯性物件，或編輯來源租用戶的現有組織關聯性物件。

$sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]"
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

接受移轉應用程式並設定組織關係，) 租用戶準備目前信箱位置的來源 (

使用您的瀏覽器，移至受信任合作夥伴所提供的URL連結，以同意信箱移轉應用程式。 URL 看起來應該像這樣：

https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

注意事項

您需要您剛才建立的信箱移轉應用程式的應用程式識別碼。您必須將上一個範例中的取代 contoso.onmicrosoft.com 為來源租使用者的 onmicrosoft.com URL。您也必須將 [application_id_of_the_app_you_just_created] 取代為您剛才建立的信箱移轉應用程式的應用程式識別碼。
彈出窗口出現時接受應用程式。您也可以登入 Microsoft Entra 系統管理中心，並在 [企業應用程式] 底下尋找應用程式。
聯機到來源 Exchange Online 租使用者上的 Exchange Online PowerShell 。

在 Exchange Online PowerShell 中建立新的組織關聯性物件，或將現有的組織關聯性物件編輯到目標 (目的地) 租使用者：

# Enable customization if tenant is dehydrated
$dehydrated=Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]"
$appId="[application id of the mailbox migration app you consented to]"
$scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]"
New-DistributionGroup -Type Security -Name $scope
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId 
-OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

注意事項

您輸入做為租使用者和 $sourceTenantId$targetTenantId 識別碼是 GUID，而不是租使用者網域名稱。有關租使用者識別碼的範例，以及尋找租使用者識別碼的資訊，請參閱尋找您的 Microsoft 365 租使用者識別碼。

準備目標用戶物件以進行移轉

移轉的用戶必須出現在目標租使用者和 Exchange Online 系統 (為 MailUser) 標示特定屬性，才能啟用跨租用戶移動。系統將無法移動目標租使用者中未正確設定的使用者。目標用戶物件的必要條件一節詳細說明目標租使用者的MailUser物件需求。

目標用戶物件的必要條件

請確定已在目標組織中設定下列物件和屬性：

提示

Microsoft 正在開發一項功能，以提供安全的自動化方法來設定以下指定的許多屬性 (，本節) 。這項名為「跨租使用者身分識別對應」的功能目前正在尋找願意參與小型私人預覽版的客戶。如需此發行前版本功能及其如何簡化跨租使用者移轉程式的詳細資訊，請參閱跨租使用者身分識別對應。

對於從來源組織移動的任何信箱，您必須在目標組織中布建 MailUser 物件：

目標 MailUser 必須具有來源信箱中的這些屬性，或使用新的 User 物件指派這些屬性：

ExchangeGUID (從來源到目標的直接流程) ：信箱 GUID 必須相符。如果目標對象上沒有這個屬性，移動程式將不會繼續進行。
ArchiveGUID (從來源到目標) 的直接流程：封存 GUID 必須相符。如果目標對象上沒有這個屬性，移動程式將不會繼續進行。 (只有當來源信箱已啟用封存) 時，才需要此屬性。
LegacyExchangeDN (流程為 proxyAddress，“x500：<LegacyExchangeDN>”) ：LegacyExchangeDN 必須以 x500： proxyAddress 格式出現在目標 MailUser 上。 此外，您也需要將所有 x500 位址從來源信箱複製到目標郵件使用者。 如果目標對象上沒有這些 x500 位址，行動程式將不會繼續進行。此外，此步驟對於在移轉之前傳送的電子郵件啟用回復能力也很重要。每個電子郵件專案中的發件者/收件者位址，以及 Microsoft Outlook 和 Microsoft Outlook Web App 中自動完成快取 (OWA) 使用 LegacyExchangeDN 屬性的值。如果找不到使用 LegacyExchangeDN 值的使用者，電子郵件訊息的傳遞可能會因為 5.1.1 NDR 而失敗。
UserPrincipalName：UPN 會對齊使用者的新身分識別或目標公司 (例如 user@northwindtraders.onmicrosoft.com ，) 。
主要 SMTPAddress：主要 SMTP 位址會對齊使用者的新公司 (例如 user@northwindtraders.com ，) 。
TargetAddress/ExternalEmailAddress：MailUser 會參考裝載於來源租使用者中的使用者目前信箱 (例如 user@contoso.onmicrosoft.com) 。指派此值時，請確認您已/也指派 PrimarySMTPAddress;否則，此值會設定 PrimarySMTPAddress，這會導致移動失敗。

您無法從來源信箱將舊版 smtp Proxy 位址新增至目標 MailUser。例如，您無法在 northwindtraders.onmicrosoft.com 租用戶物件的MEU上維護 contoso.com。網域只會與一個 Microsoft Entra ID 或 Exchange Online 租使用者相關聯。

以 MailUser 物件為目標的範例：

屬性	值
別名	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 管理群組 (FYDIBOHF23SPDLT) /cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara
EmailAddresses	x500：/o=First Organization/ou=Exchange 管理群組 (FYDIBOHF23SPDLT) /cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
	Smtp：LaraN@northwindtraders.onmicrosoft.com
	Smtp：Lara.Newton@northwindtraders.com
	X500：/o=ExchangeLabs/ou=Exchange 系統管理群組 (FYDIBOHF23SPDLT) /cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

範例來源 Mailbox 物件：

屬性	值
別名	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 管理群組 (FYDIBOHF23SPDLT) /cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
EmailAddresses	Smtp：LaraN@contoso.onmicrosoft.com
	Smtp：Lara.Newton@contoso.com
	X500：/o=ExchangeLabs/ou=Exchange 系統管理群組 (FYDIBOHF23SPDLT) /cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

其他屬性可能已包含在 Exchange 混合式回寫中。如果沒有，則應該包含它們。
1. msExchBlockedSendersHash – 將在線封鎖的寄件者數據從用戶端寫回內部部署 Active Directory。
2. msExchSafeRecipientsHash – 將在線安全收件者數據從用戶端寫回內部部署 Active Directory。
3. msExchSafeSendersHash – 將在線安全傳送者數據從用戶端寫回內部部署 Active Directory。
目標群組織中的使用者必須獲得適用於組織的適當 Exchange Online 訂用帳戶授權。您可以在信箱移動之前套用授權，但只有在目標 MailUser 使用 ExchangeGUID 和 Proxy 位址正確設定之後。在套用 ExchangeGUID 之前套用授權，將會在目標組織中布建新的信箱。您也必須套用跨租用戶用戶數據遷移授權;否則，您可能會看到暫時性錯誤讀取 需要核准，這會在移動報告中回報授權尚未套用至目標使用者的警告。

注意事項

當您在 Mailbox 或 MailUser 物件上套用授權時，會清除所有 SMTP 類型 proxyAddresses，以確保只有已驗證的網域包含在 Exchange EmailAddresses 陣列中。
您必須確定目標 MailUser 沒有先前與來源 ExchangeGUID 不相符的 ExchangeGUID。如果目標 MEU 先前已授權 Exchange Online 並布建信箱，則可能會發生此不符的情況。如果目標 MailUser 先前已獲得授權，或具有不符合來源 ExchangeGUID 的 ExchangeGUID，您必須執行雲端 MEU 的清除。針對這些雲端 MEUS，您可以執行 Set-User <identity> -PermanentlyClearPreviousMailboxInfo。

注意

此流程無法復原。如果物件有 softDeleted 信箱，則無法在此時間點之後還原。不過，清除之後，您可以將正確的 ExchangeGUID 同步至目標物件，MRS 會將來源信箱連線到新建立的目標信箱。 (新參數上的參考 EHLO 部落格。)

使用下列命令尋找先前信箱的物件：

Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize

以下為範例:

Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize

Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
----       ---------------------------- ------------- --------------------
John       UserMailbox                  MailUser      MailUser

使用下列命令清除虛刪除的信箱：

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

以下為範例:

Set-User John@northwindtraders.com -PermanentlyClearPreviousMailboxInfo -Confirm

Are you sure you want to perform this action?
Delete all existing information about user "John@northwindtraders.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY.
Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y

如何知道這是否正常運作？

您可以針對您在目標租使用者上建立的跨租使用者移轉端點執行 Test-MigrationServerAvailability Cmdlet，以驗證跨租使用者信箱移轉設定。從目標租用戶執行下列 Cmdlet：

Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"

注意事項

此外，您可能想要利用跨租使用者信箱移轉驗證腳本，這可讓您驗證組織之間是否已正確設定，以及您打算從一個租使用者移轉至另一個租用戶的物件。此腳本可協助識別所有物件上可能同時出現的任何不一致，因此會減少在初始階段所花費的時間。

將信箱移回原始來源

如果需要信箱才能移回原始來源租使用者，則必須在新的來源和新的目標租用戶中執行相同的步驟和腳本集，而且有一些差異。

請勿執行提供來建立 OrganizationRelationship 的範例腳本。

在每個租使用者中建立的現有 OrganizationRelationship 中更新下列值：

MailboxMovesCapability 應具有輸入、RemoteOutbound 作為來源和目標租使用者中的功能。
在新的來源租使用者中，使用新來源租使用者中新建立應用程式的值來更新 OAuthApplicationId 值。
在新的來源租使用者中，使用新來源租使用者中新建立的安全組來更新MailboxMovePublishedScopes值。

執行信箱移轉

跨租使用者 Exchange 信箱移轉會從目標租使用者起始為移轉批次。此程式類似於從 Exchange 內部部署移轉至 Microsoft 365 時，上架移轉批次的運作方式。

建立移轉批次

以下是起始批次移轉的範例命令：

New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com

Identity                   Status  Type               TotalCount
--------                   ------  ----               ----------
T2Tbatch                   Syncing ExchangeRemoteMove 1

注意事項

CSV 檔案中的電子郵件地址必須是目標租使用者中指定的電子郵件地址 (例如， userA@northwindtraders.onmicrosoft.com) ，而不是來源租使用者中指定的電子郵件位址。如需 Cmdlet 的詳細資訊，請按兩下這裡如需 CSV 檔案資訊的一些範例，請按兩下這裡

CSV 檔案的最小範例是：

EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com

選取跨租用戶選項時，新的 Exchange 系統管理中心也支援移轉批次提交。

更新內部部署MailUsers

一旦信箱從來源移至目標，您應該確定來源和目標中的內部部署郵件使用者都已使用新的 targetAddress 更新。在範例中，移動中使用的 targetDeliveryDomain 是 northwindtraders.onmicrosoft.com。使用此 targetAddress 更新郵件使用者。

移轉後移除端點和組織關係

移轉完成之後，使用 Remove-MigrationEndpoint Cmdlet 移除來源或目的地伺服器的現有移轉端點。

移轉完成後，使用 Remove-OrganizationRelationship Cmdlet 移除來源或目的地伺服器的現有組織關聯性。

常見問題集

移動之後，是否需要更新來源內部部署租使用者中的 RemoteMailboxes？

來源交換組織

當來源租使用者信箱移至目標租使用者時，您應該更新每個來源內部部署使用者的 targetAddress (RemoteRoutingAddress/ExternalEmailAddress) 。雖然郵件路由可以追蹤具有不同 targetAddresses 之多個郵件用戶的轉介，但郵件使用者的空閒/忙碌查閱必須以信箱使用者的位置為目標。

目標 Exchange 組織

在混合式組織中完成移轉之後，如果您想要讓使用者在內部部署有遠端信箱，請執行下列 PowerShell 命令：

Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox

Teams 會議是否移轉跨租使用者？

移動Teams會議時，當專案跨租使用者移轉時，不會更新會議URL。由於目標租使用者中的 URL 無效，因此您必須移除並重新建立 Teams 會議。

跨租用戶移轉哪些內容？

使用這項功能跨租使用者移轉信箱時，只會移轉信箱中使用者可見的內容，也稱為資訊存放區頂端 (電子郵件、聯繫人、行事歷、工作和記事) ，以及可復原的專案資料夾刪除、版本和清除。

Outbox 中的專案是否已跨租使用者移轉？

Outbox 中的專案不會跨租使用者移轉，因為此資料夾是 Outlook 用戶端專屬的用戶端式資料夾。 Outbox 中的專案會儲存在本機，且不會同步至雲端。

Teams 聊天資料夾內容是否跨租使用者移轉？

否，Teams 聊天資料夾內容不會移轉跨租使用者。不過，一旦跨租使用者移轉信箱，來源租用戶系統管理員就可以使用內容搜尋來搜尋和導出Teams聊天資料夾內容。

如何只看到跨租用戶移動的移動，而不是我的上線和離線移動？

使用 Flags 參數：

Get-MoveRequest -Flags "CrossTenant"

您可以提供範例腳本來複製測試中使用的屬性嗎？

注意事項

SAMPLE – AS IS， NO WARRANTY 此腳本會假設來源信箱 (連線，以取得來源值) ，而目標內部部署 Active Directory 網域服務 (以將 ADUser 物件) 。

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the northwindtraders tenant
$outFileUsers = "$home\desktop\UsersToMigrate.txt"
$outFileUsersXML = "$home\desktop\UsersToMigrate.xml"
Get-Mailbox -Filter "CustomAttribute1 -like 'Cross-Tenant-Project'" -ResultSize Unlimited | Select-Object -ExpandProperty  Alias | Out-File $outFileUsers
$mailboxes = Get-Content $outFileUsers
$mailboxes | ForEach-Object {Get-Mailbox $_} | Select-Object PrimarySMTPAddress,Alias,SamAccountName,FirstName,LastName,DisplayName,Name,ExchangeGuid,ArchiveGuid,LegacyExchangeDn,EmailAddresses | Export-Clixml $outFileUsersXML

# Copy the file $outfile to the desktop of the target on-premises then run the below to create MEU in Target
$symbols = '!@#$%^&*'.ToCharArray()
$characterList = @([char[]]([char]'a'..[char]'z'), [char[]]([char]'A'..[char]'Z'), [char[]]([char]'0'..[char]'9') + $symbols)

function GeneratePassword {
    param(
        [ValidateRange(12, 256)]
        [int]
        $length = 16
    )

    do {
        $password = -join (0..$length | ForEach-Object { $characterList | Get-Random })
        [int]$hasLowerChar = $password -cmatch '[a-z]'
        [int]$hasUpperChar = $password -cmatch '[A-Z]'
        [int]$hasDigit = $password -match '[0-9]'
        [int]$hasSymbol = $password.IndexOfAny($symbols) -ne -1

    }
    until (($hasLowerChar + $hasUpperChar + $hasDigit + $hasSymbol) -ge 3)

    $password | ConvertTo-SecureString -AsPlainText
}

$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
foreach ($m in $mailboxes) {
    $organization = "@contoso.onmicrosoft.com"
    $mosi = $m.Alias + $organization
    $Password = GeneratePassword
    $x500 = "x500:" + $m.LegacyExchangeDn
    $tmpUser = New-MailUser -MicrosoftOnlineServicesID $mosi -PrimarySmtpAddress $mosi -ExternalEmailAddress $m.PrimarySmtpAddress -FirstName $m.FirstName -LastName $m.LastName -Name $m.Name -DisplayName $m.DisplayName -Alias $m.Alias -Password $Password
    $tmpUser | Set-MailUser -EmailAddresses @{add = $x500 } -ExchangeGuid $m.ExchangeGuid -ArchiveGuid $m.ArchiveGuid -CustomAttribute1 "Cross-Tenant-Project"
    $tmpx500 = $m.EmailAddresses | Where-Object { $_ -match "x500" }
    $tmpx500 | ForEach-Object { Set-MailUser $m.Alias -EmailAddresses @{add = "$_" } }
}

# Now synchronize the changes from On-Premises to Azure and Exchange Online in the target tenant
# This action should create the target mail enabled users (MEUs) in the Target tenant
Start-ADSyncSyncCycle

如何在移動使用者信箱之後，於第 1 天存取 Outlook？

由於只有一個租使用者可以擁有網域，因此當信箱移動完成時，先前的主要 SMTPAddress 將不會與目標租使用者中的使用者相關聯;只有與新租用戶相關聯的網域。 Outlook 會使用使用者的新 UPN 向服務進行驗證，而 Outlook 配置檔預期會尋找舊版主要 SMTPAddress，以符合目標系統中的信箱。由於舊版位址不在目標系統中，因此 Outlook 配置檔將無法連線以尋找新移動的信箱。

在此初始部署中，用戶必須使用新的UPN、主要SMTP位址和重新同步 OST內容來重建其配置檔。

注意事項

當您批處理使用者以完成時，請據此規劃。建立 Outlook 用戶端設定檔並將後續的 OST 和 OAB 檔案下載至用戶端時，您必須考慮網路使用率和容量。

我需要屬於哪些 Exchange RBAC 角色，才能設定或完成跨租用戶移動？

執行信箱移動時，根據委派職責的假設，有角色的矩陣。目前需要兩個角色：

第一個角色適用於一次性設定工作，該工作會建立將內容移入或移出租使用者/組織界限的授權。由於將數據移出組織控制是所有公司的重要考慮，因此我們選擇最高指派的 組織系統管理員角色。此角色必須改變或設定新的 OrganizationRelationship，以定義 -MailboxMoveCapability 與遠端組織的設定。只有組織系統管理員可以變更 -MailboxMoveCapability 設定，而 OrganizationRelationship 上的其他屬性則可由同盟共用系統管理員管理。
執行實際移動命令的角色可以委派給較低層級的函式。 移動信箱的角色會指派給將信箱移入或移出組織的功能。

如何針對已轉換信箱上的 targetAddress (TargetDeliveryDomain) 選取哪個 SMTP 位址， (轉換為 MailUser 轉換) ？

Exchange 信箱會在轉換成 MailUser 時，使用 MRS 在原始來源信箱上製作 targetAddress 來移動，方法是比對目標物件上 proxyAddress) (電子郵件位址。此程式會接受 -TargetDeliveryDomain 傳遞至命令的值，然後在目標端檢查該網域的相符 Proxy。當我們找到相符專案時，會使用相符的 proxyAddress 來設定已轉換信箱上的 ExternalEmailAddress (targetAddress) ，現在 (MailUser) 物件。

郵件流程在移轉后如何運作？

移轉后的跨租使用者郵件流程運作方式類似於 Exchange 混合式郵件流程。每個移轉的信箱都需要具有正確目標位址的來源 MailUser，以將來源租使用者的內送郵件轉寄至目標租使用者中的信箱。傳輸規則、安全性與合規性功能會在郵件流經的每個租用戶中執行。因此，針對輸入郵件，反垃圾郵件、反惡意代碼、隔離、傳輸規則和日誌規則等功能會先在來源租用戶中執行，然後在目標租用戶中執行。

信箱許可權如何轉換？

信箱許可權包括代表傳送和信箱存取：

代表 (AD：publicDelegates 傳送) 以委派身分儲存具有使用者信箱存取權的收件者 DN。此值會儲存在Active Directory中，而且目前不會在信箱轉換過程中移動。如果來源信箱已設定 publicDelegates，則一旦 MEU 到信箱轉換在目標環境中 Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>執行完成，您就必須在目標信箱上重新安裝 publicDelegates。
當主體和委派都移至目標系統時，信箱中儲存的信箱許可權會隨著信箱移動。例如，使用者 TestUser 7 會將 FullAccess 授與租使用者 SourceCompany.onmicrosoft.com 中的信箱TestUser_8。信箱移至 TargetCompany.onmicrosoft.com 之後，會在目標目錄中設定相同的許可權。針對來源和目標租使用者中的TestUser_7使用 _Get-MailboxPermission 的範例如下所示。 Exchange Cmdlet 會依序加上來源和目標。

以下是從來源端移動之前，信箱許可權輸出的範例：

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, is Inherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@contoso.onmicrosoft.com               {FullAccess}                         False       False

以下是從目標端移動之後，信箱許可權輸出的範例：

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@northwindtraders.onmicrosoft.com      {FullAccess}                         False       False

注意事項

不支援跨租使用者信箱和行事曆許可權。您必須將主體和委派組織成合併移動批次，以便從來源租用戶同時轉換這些連線的信箱。

應該將哪些 X500 Proxy 新增至目標 MailUser Proxy 位址以啟用移轉？

跨租使用者信箱移轉需要將來源信箱物件的 LegacyExchangeDN 值加上戳記為目標 MailUser 物件上的 x500 電子郵件位址。

例如:

LegacyExchangeDN value on source mailbox is:
/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara

so, the x500 email address to be added to target MailUser object would be:
x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara

注意事項

除了這個 X500 Proxy 之外，您還需要將所有 X500 Proxy 從來源的信箱複製到目標中的信箱。雖然很罕見，但您也可以在信箱上執行 X400 Proxy 位址，但並非完成移動的需求，但建議您也要在目標郵件用戶物件上標記此位址。

來源和目標租使用者是否可以使用相同的功能變數名稱？

否，來源租用戶和目標租使用者功能變數名稱必須是唯一的，例如，contoso.com 的來源網域和 northwindtraders.com 的目標網域。

共用信箱會移動並仍可運作嗎？

是。不過，我們只保留儲存區許可權，如本文所述：

管理 Exchange Online 中收件者的許可權

您有任何批次的建議嗎？

不要超過每個批次 2,000 個信箱。強烈建議您在截止日期前兩周提交批次，因為同步處理期間不會對終端使用者造成任何影響。如果您需要超過 50,000 個信箱數量的指引，您可以連絡 CSAM 或開啟支援要求。

如果我搭配 Microsoft Purview 客戶密鑰使用服務加密，該怎麼辦？

信箱會在移動之前解密。如果仍然需要客戶金鑰，請確定已在目標租用戶中設定客戶金鑰。如需詳細資訊，請參閱這裡。

預估的移轉時間為何？

為了協助您規劃移轉，此處的表格顯示何時預期大量信箱移轉或個別移轉完成的指導方針。這些估計值是以先前客戶移轉的數據分析為基礎。由於每個環境都是唯一的，因此您的確切移轉速度可能會有所不同。

保護目的地租用戶中使用者可取用來源租使用者中的檔。**

跨租使用者移轉只會移轉信箱數據，而不會移轉任何其他數據。下列部落格文章中有多個其他選項可提供協助：

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

我是否可以在目的地租用戶中擁有與您在來源租使用者中相同的標籤，根據組織之間的一致性，作為唯一的標籤或一組額外的標籤給已移轉的使用者。**

由於跨租使用者移轉不會匯出標籤，而且無法在租用戶之間共用標籤，因此您只能藉由在目的地租使用者中重新建立標籤來達成此目標。

您是否支援移動 Microsoft 365 群組？

目前跨租使用者信箱移轉功能不支援 Microsoft 365 群組的移轉。

來源租用戶系統管理員是否可以在信箱移轉至新的/目標租用戶之後，對信箱執行電子檔探索搜尋？

否，跨租使用者信箱移轉之後，針對來源中已移轉使用者信箱的電子檔探索無法運作。此電子檔探索失敗是因為來源中不再有信箱可供搜尋，因為信箱已移轉至目標租使用者，且現在屬於目標租使用者。信箱移轉之後的電子檔探索只能在信箱存在的目標租使用者 () 完成。如果來源信箱的複本需要在移轉后保存在來源租使用者中，來源租使用者中的系統管理員可以將內容複製到替代信箱，以便日後針對數據進行電子檔探索作業。

此時，目的地 MailUser 會轉換成目的地信箱，而來源信箱會轉換成來源 MailUser？

這些轉換會在移轉程式期間自動進行。不需要手動步驟。

我應該在哪個步驟將 Exchange Online 授權指派給目的地 MailUsers？

此授權指派可以在移轉完成之前完成，但您不應該在戳記 ExchangeGUID 屬性之前指派授權;else，將 MailUser 物件轉換成信箱將會失敗，並改為建立新的信箱。若要降低此風險，最好等到移轉完成，並在 30 天的寬限期內指派授權。

如果我保留內部部署 Active Directory，可以使用 Microsoft Entra Connect 將使用者同步至新的租使用者嗎？

是的。 Microsoft Entra Connect 的兩個實例可以同步處理至不同的租使用者。不過，您需要注意一些事項：

不應使用本文中提供的腳本預先布建用戶的帳戶。相反地，可以執行移轉範圍內用戶的選擇性 OU 同步處理，以填入目標租使用者。您會在 Microsoft Entra Connect 設定期間收到 UPN 不相符的警告。
根據您目前的混合式 Exchange 狀態，您必須確認內部部署目錄物件 (如 msExchMailboxGUID 和 proxyAddresses 等必要屬性) 正確填入，然後再嘗試同步至另一個租使用者;否則，您會遇到雙信箱和移轉失敗的問題。
您必須採取一些額外的步驟來管理 UPN 轉換，並在使用者完成移轉後變更內部部署，除非您也在完全移轉期間移動自定義網域。

我應該如何處理接近或超過配額的信箱。

在移轉之前接近其配額的信箱最終可能會超過實際移轉之前或期間的配額。如果發生這種情況，這些信箱將無法移轉，而且必須進行補救並重新啟動。若要減輕此問題，建議來源租用戶系統管理員在移轉之前識別位於或接近配額的信箱，並採取必要步驟來減少信箱大小、布建主要封存，或在某些情況下啟用使用者信箱的自動擴充封存。

注意事項

啟用使用者的封存或自動展開封存之後，請確定已將正確的封存原則套用至使用者，並執行此程式以將信箱數據移至其新位置並釋出空間。

自動展開的封存信箱是否移動？

問題：無法移轉自動展開的封存。 是，如果來源中的使用者已啟用自動展開封存，並具有額外的輔助封存，跨租使用者信箱移轉將會運作。我們支持移動不超過12個輔助封存信箱的使用者。此外，具有大型主要、大型主要封存和大型輔助封存信箱的使用者將需要額外的時間來同步處理，而且應該在截止日期之前提交。如果來源信箱在信箱移轉程式期間展開，移轉將會失敗，因為新的輔助封存會在來源中建立，但不會在目標中建立。在此情況下，您必須從批次中移除使用者並重新提交使用者。

我可以執行跨雲端租使用者到租用戶的移轉嗎？

不支援跨雲端租使用者到租用戶移轉。範例案例是從全球 Office 365 移至 Office 365 政府雲端。

語音信箱是否跨租使用者移轉？

是，語音信箱會跨租用戶移轉。

已收到電子郵件中的語音信箱，因為附件可在目標信箱中使用。
如果您呼叫語音信箱並接聽已儲存的訊息，則 Teams 中可使用已接收的語音信箱。在來源中收到 (VM 可作為已儲存的訊息)
在目標移轉后，Teams 用戶端 UI 中無法使用收到的語音信箱。
語音信箱問候語也會移轉至目標。

信箱簽章是否跨租用戶移轉？

信箱簽章不會跨租用戶移轉，而且必須重新建立。

已知問題

來源租使用者中的移轉后 Teams 功能將會受到限制。將信箱移轉至目標租用戶之後，來源租使用者中的Teams就無法再存取使用者的信箱。如果使用者使用來源租使用者認證登入 Teams，則會遺失功能，例如無法更新其配置檔圖片、沒有行事曆應用程式，以及無法搜尋和加入公用小組。
Cloud MailUsers 搭配非擁有的 smtp proxyAddress 區塊 MRS 移動。建立目標租使用者 MailUser 物件時，您必須確定所有 SMTP Proxy 位址都屬於目標租用戶組織。如果 SMTP ProxyAddress 存在於不屬於本機租用戶的目標郵件使用者上，則會防止將 MailUser 轉換成信箱。這項預防是因為我們保證信箱物件只能從租使用者所宣告的網域傳送郵件，租使用者 (宣告的網域) 。
如果您在目標租使用者中使用 Microsoft Entra Connect 同步處理內部部署使用者，則可以使用 ExternalEmailAddress 來布建內部部署 MailUser 物件，指向信箱所在的來源租使用者 () LaraN@contoso.onmicrosoft.com ，並將 PrimarySMTPAddress 戳記為位於目標租使用者 (Lara.Newton@northwindtraders.com) 的網域。這些值會向下同步至租使用者，並布建適當的郵件使用者，並準備好進行移轉。範例物件如下所示。
```
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

ExternalEmailAddress               EmailAddresses
--------------------               --------------
SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}
```
注意事項

contoso.onmicrosoft.com 位址不存在於 EmailAddresses/proxyAddresses 陣列中。
具有「外部」主要 SMTP 位址的 MailUser 物件會修改/重設為「內部」公司宣告的網域。

MailUser 對像是非本機信箱的指標。在跨租使用者信箱移轉的案例中，我們會使用MailUser物件來代表來源信箱 (，從目標組織的觀點來看，) 或從來源組織的觀點) (目標信箱。 MailUsers 會有 ExternalEmailAddress (targetAddress) ，指向實際信箱 (ProxyTest@northwindtraders.onmicrosoft.com) 和 primarySMTP 位址的 smtp 位址，代表目錄中信箱用戶顯示的 SMTP 位址。例如，某些組織選擇將主要 SMTP 位址顯示為外部 SMTP 位址，而不是本機租使用者 (擁有/驗證的位址，northwindtraders.com 而非 contoso.com) 。不過，一旦 Exchange 服務方案物件透過授權作業套用至 MailUser，主要 SMTP 位址就會被修改，以顯示為本機組織 (contoso.com) 驗證的網域。有兩個可能的原因：
當任何 Exchange 服務方案套用至 MailUser 時，Microsoft Entra ID 程式會開始強制執行 Proxy 清除，以確保本機組織無法從另一個租使用者傳送郵件、詐騙或郵件。如果本機組織未驗證位址，則會移除具有這些服務方案之收件者物件上的任何 SMTP 位址。如同範例中的情況，contoso.onmicrosoft.com 租使用者不會驗證 northwindtraders.com 網域;因此，清除會移除 northwindtraders.com 網域。如果您想要在移轉之前或之後將這些外部網域保存在 MailUser 上，您需要在移動完成後或移動之前變更移轉程式以移除授權，以確保使用者已套用預期的外部商標。您必須確定信箱對象已獲得適當授權，才能不影響郵件服務。此處顯示一個範例腳本，可移除 contoso.onmicrosoft.com 租使用者中MailUser上的服務方案。

注意事項

下列腳本使用 Microsoft Graph Powershell。如需詳細資訊，請參閱 Microsoft Graph PowerShell 概觀。

如需如何在自動腳本中使用不同方法進行驗證 Connect-Graph 的資訊，請參閱 Microsoft Graph PowerShell 中的驗證模組 Cmdlet 一文。

# Connect to Microsoft Graph
Connect-Graph -Scopes User.ReadWrite.All, Organization.Read.All

# Get licensing plans and include disabled plans
$EmsSku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'ENTERPRISEPREMIUM'
$User = Get-MgUser -UserId LaraN@contoso.onmicrosoft.com
$userLicense = Get-MgUserLicenseDetail -UserId $User.Id

$userDisabledPlans = $userLicense.ServicePlans |
  Where ProvisioningStatus -eq "Disabled" |
  Select -ExpandProperty ServicePlanId

$newDisabledPlans = $EmsSku.ServicePlans |
  Where ServicePlanName -in ("LOCKBOX_ENTERPRISE","EXCHANGE_S_ENTERPRISE","INFORMATION_BARRIERS","MIP_S_CLP2","MIP_S_CLP1","MYANALYTICS_P2","EXCHANGE_ANALYTICS","EQUIVIO_ANALYTICS","THREAT_INTELLIGENCE","PAM_ENTERPRISE","PREMIUM_ENCRYPTION") |
  Select -ExpandProperty ServicePlanId

$disabledPlans = $userDisabledPlans + $newDisabledPlans | Select -Unique

$addLicenses = @(
  @{SkuId = $EmsSku.SkuId
  DisabledPlans = $disabledPlans
  }
  )

Set-MgUserLicense -UserId '38955658-c844-4f59-9430-6519430ac89b' -AddLicenses $addLicenses -RemoveLicenses @()

Id                                   DisplayName   Mail UserPrincipalName                     UserType
--                                   -----------   ---- -----------------                     --------
38955658-c844-4f59-9430-6519430ac89b Bianca Pisani      BiancaP@contoso.onmicrosoft.com       Member

指派的 ServicePlans 集合中的結果如下所示：

$order = @(
  @{ Expression = 'ProvisioningStatus'; Ascending = $true }
)
Get-MgUserLicenseDetail -UserId '38955658-c844-4f59-9430-6519430ac89b' | Select-Object -ExpandProperty ServicePlans | sort ProvisioningStatus $order

AppliesTo ProvisioningStatus  ServicePlanId                        ServicePlanName
--------- ------------------  -------------                        ---------------
User      Success             2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2 ADALLOM_S_STANDALONE
User      Success             6c6042f5-6f01-4d67-b8c1-eb99d36eed3e STREAM_O365_E5
User      Success             e212cbc7-0961-4c40-9825-01117710dcb1 FORMS_PLAN_E5
User      Success             07699545-9485-468e-95b6-2fca3738be01 FLOW_O365_P3
User      Success             9c0dab89-a30c-4117-86e7-97bda240acd2 POWERAPPS_O365_P3
User      Success             871d91ec-ec1a-452b-a83f-bd76c7d770ef WINDEFATP
User      Success             21b439ba-a0ca-424f-a6cc-52f954a5b111 WIN10_PRO_ENT_SUB
User      Success             57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
User      Success             8c7d2df8-86f0-4902-b2ed-a0458298f3b3 Deskless
User      Success             8e0c0a52-6a6c-4d40-8370-dd62790dcd70 THREAT_INTELLIGENCE
User      Success             4a51bca5-1eff-43f5-878c-177680f191af WHITEBOARD_PLAN3
User      Success             efb0351d-3b08-4503-993d-383af8de41e3 MIP_S_CLP2
User      Success             617b097b-4b93-4ede-83de-5f075bb5fb2f PREMIUM_ENCRYPTION
User      Success             8c098270-9dd4-4350-9b30-ba4703f3b36b ADALLOM_S_O365
Company   Success             94065c59-bc8e-4e8b-89e5-5138d471eaff MICROSOFT_SEARCH
User      Success             14ab5db5-e6c4-4b20-b4bc-13e36fd2227f ATA
User      Success             3fb82609-8c27-4f7b-bd51-30634711ee67 BPOS_S_TODO_3
User      Success             b1188c4c-1b36-4018-b48b-ee07604f6feb PAM_ENTERPRISE
User      Success             5136a095-5cf0-4aff-bec3-e84448b38ea5 MIP_S_CLP1
User      Success             33c4f319-9bdd-48d6-9c4d-410b750a4a5a MYANALYTICS_P2
User      Success             5689bec4-755d-4753-8b61-40975025187c RMS_S_PREMIUM2
User      Success             4828c8ec-dc2e-4779-b502-87ac9ce28ab7 MCOEV
User      Success             9f431833-0334-42de-a7dc-70aa40db46db LOCKBOX_ENTERPRISE
User      Success             3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40 MCOMEETADV
User      Success             43de0ff5-c92c-492b-9116-175376d08c38 OFFICESUBSCRIPTION
User      Success             0feaeb32-d00e-4d66-bd5a-43b5b83db82c MCOSTANDARD
User      Success             70d33638-9c74-4d01-bfd3-562de28bd4ba BI_AZURE_P2
Company   Success             f20fedf3-f3c3-43c3-8267-2bfdd51c0939 ATP_ENTERPRISE
User      Success             4de31727-a228-4ec3-a5bf-8e45b5ca48cc EQUIVIO_ANALYTICS
User      Success             efb87545-963c-4e0d-99df-69c6916d9eb0 EXCHANGE_S_ENTERPRISE
User      Success             34c0d7a0-a70f-4668-9238-47f9fc208882 EXCHANGE_ANALYTICS
User      Success             8a256a2b-b617-496d-b51b-e76466e88db0 MFA_PREMIUM
User      Success             41781fb2-bc02-4b7c-bd55-b576c07bb09d AAD_PREMIUM
User      Success             bea4c11e-220a-4e6d-8eb8-8ea15d019f90 RMS_S_ENTERPRISE
User      Success             eec0eb4f-6444-4f95-aba0-50c24d67f998 AAD_PREMIUM_P2
User      Success             6c57d4b6-3b23-47a5-9bc9-69f17b4947b3 RMS_S_PREMIUM
User      Success             5dbe027f-2339-4123-9542-606e4d348a72 SHAREPOINTENTERPRISE
User      Success             b737dad2-2f6c-4c65-90e3-ca563267e8b9 PROJECTWORKMANAGEMENT
User      Success             e95bec33-7c88-4a70-8e19-b10bd9d0c014 SHAREPOINTWAC
User      Success             7547a3fe-08ee-4ccb-b430-5077c5041653 YAMMER_ENTERPRISE
User      Success             a23b959c-7ce8-4e57-9140-b90eb88a9e97 SWAY
User      Success             c4801e8a-cb58-4c35-aca6-f2dcc106f287 INFORMATION_BARRIERS
User      Success             b76fb638-6ba6-402a-b9f9-83d28acb3d86 VIVA_LEARNING_SEEDED
Company   Success             db4d623d-b514-490b-b7ef-8885eee514de Nucleus
Company   Success             6f23d6a9-adbf-481c-8538-b4c095654487 M365_LIGHTHOUSE_CUSTOMER_PLAN1
User      Success             a82fbf69-b4d7-49f4-83a6-915b2cf354f4 VIVAENGAGE_CORE
User      Success             9a6eeb79-0b4b-4bf0-9808-39d99a2cd5a3 Windows_Autopatch
User      Success             cd31b152-6326-4d1b-ae1b-997b625182e6 MIP_S_Exchange
User      Success             a413a9ff-720c-4822-98ef-2f37c2a21f4c MICROSOFT_COMMUNICATION_COMPLIANCE
User      Success             795f6fe0-cc4d-4773-b050-5dde4dc704c9 UNIVERSAL_PRINT_01
Company   Success             2b815d45-56e4-4e3a-b65c-66cb9175b560 ContentExplorer_Standard
User      Success             7bf960f6-2cd9-443a-8046-5dbff9558365 WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE
User      Success             3ec18638-bd4c-4d3b-8905-479ed636b83e CustomerLockboxA_Enterprise
User      Success             3efbd4ed-8958-4824-8389-1321f8730af8 MESH_AVATARS_ADDITIONAL_FOR_TEAMS
User      Success             99cd49a9-0e54-4e07-aea1-d8d9f5f704f5 Defender_for_Iot_Enterprise
User      Success             0898bdbb-73b0-471a-81e5-20f1fe4dd66e KAIZALA_STANDALONE
User      Success             c948ea65-2053-4a5a-8a62-9eaaaf11b522 PURVIEW_DISCOVERY
User      Success             a1ace008-72f3-4ea0-8dac-33b3a23a2472 CLIPCHAMP
User      Success             f6de4823-28fa-440b-b886-4783fa86ddba M365_AUDIT_PLATFORM
User      Success             0d0c0d31-fae7-41f2-b909-eaf4d7f26dba Bing_Chat_Enterprise
User      Success             dcf9d2f4-772e-4434-b757-77a453cfbc02 MESH_AVATARS_FOR_TEAMS
User      Success             c4b8c31a-fb44-4c65-9837-a21f55fcabda MICROSOFT_LOOP
User      Success             a6520331-d7d4-4276-95f5-15c0933bc757 GRAPH_CONNECTORS_SEARCH_INDEX
User      Success             e26c2fcc-ab91-4a61-b35c-03cdc8dddf66 INFO_GOVERNANCE
User      Success             46129a58-a698-46f0-aa5b-17f6586297d9 DATA_INVESTIGATIONS
User      Success             9d0c4ee5-e4a1-4625-ab39-d82b619b1a34 INSIDER_RISK_MANAGEMENT
User      Success             65cc641f-cccd-4643-97e0-a17e3045e541 RECORDS_MANAGEMENT
User      Success             d2d51368-76c9-4317-ada2-a12c004c432f ML_CLASSIFICATION
User      Success             bf6f5520-59e3-4f82-974b-7dbbc4fd27c7 SAFEDOCS
User      Success             2f442157-a11c-46b9-ae5b-6e39ff4e5849 M365_ADVANCED_AUDITING
User      Success             41fcdd7d-4733-4863-9cf4-c65b83ce2df4 COMMUNICATIONS_COMPLIANCE
User      Success             6db1f1db-2b46-403f-be40-e39395f08dbb CUSTOMER_KEY
User      Success             6dc145d6-95dd-4191-b9c3-185575ee6f6b COMMUNICATIONS_DLP
User      Success             199a5c09-e0ca-4e37-8f7c-b05d533e1ea2 MICROSOFTBOOKINGS
User      Success             ded3d325-1bdc-453e-8432-5bac26d7a014 POWER_VIRTUAL_AGENTS_O365_P3
Company   Success             d9fa6af4-e046-4c89-9226-729a0786685d Content_Explorer
User      Success             afa73018-811e-46e9-988f-f75d2b1b8430 CDS_O365_P3
User      Success             b21a6b06-1988-436e-a07b-51ec6d9f52ad PROJECT_O365_P3
User      Success             64bfac92-2b17-4482-b5e5-a0304429de3e MICROSOFTENDPOINTDLP
User      Success             bf28f719-7844-4079-9c78-c1307898e192 MTP
User      Success             28b0fa46-c39a-4188-89e2-58e979a6b014 DYN365_CDS_O365_P3
User      Success             d587c7a3-bda9-4f99-8776-9bcf59c84f75 INSIDER_RISK
User      Success             531ee2f8-b1cb-453b-9c21-d2180d014ca5 EXCEL_PREMIUM
User      PendingProvisioning f0ff6ac6-297d-49cd-be34-6dfef97f0c28 MESH_IMMERSIVE_FOR_TEAMS
User      PendingInput        c1ec4a95-1f05-45b3-a911-aa3fa01094f5 INTUNE_A
Company   PendingActivation   882e1d05-acd1-4ccb-8708-6ee03664b117 INTUNE_O365

不再清除使用者的 PrimarySMTPAddress。 northwindtraders.com 網域不是 contoso.onmicrosoft.com 租用戶所擁有，而且會保存為目錄中顯示的主要 SMTP 位址。

以下為範例:

Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
UserPrincipalName               PrimarySmtpAddress              ExternalEmailAddress                 ExternalDirectoryObjectId
-----------------               ------------------              --------------------                 -------------------------
ProxyTest@contoso.com          ProxyTest@contoso.com          SMTP:ProxyTest@contoso.com          e2513482-1d5b-4066-936a-cbc7f8f6f817

當 msExchRemoteRecipientType 設定為 8 (DeprovisionMailbox) 時，針對移轉至目標租用戶的內部部署 MailUsers，Azure 中的 Proxy 清除邏輯會移除非擁有的網域，並將 primarySMTP 重設為擁有的網域。在內部部署 MailUser 中清除 msExchRemoteRecipientType 之後，Proxy Scrub 邏輯就不再適用。

以下是包含 Exchange Online 的完整目前服務方案集：

名稱
eDiscovery (Premium) Storage (500 GB)
Customer Lockbox
資料外洩防護
Exchange Enterprise CAL Services (EOP、DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (計劃 1)
Exchange Online (計劃 2)
適用於 Exchange Online 的 Exchange Online 封存
Exchange Server 適用的 Exchange Online 封存
Exchange Online 非使用中使用者附加元件
Exchange Online Kiosk
Exchange Online 多地理位置
Exchange Online Plan 1
Exchange Online POP
Exchange Online Protection
具有索引的圖形連接器搜尋
資訊屏障
Office 365 的信息保護 - 進階版
Office 365 的信息保護 - 標準
MyAnalytics 的深入解析
Microsoft 資訊控管
Microsoft Purview 稽核 (進階版)
Microsoft Bookings
Microsoft 商務中心
Microsoft 數據調查
Microsoft MyAnalytics (完整)
Microsoft Communications Compliance
Microsoft Communications DLP
Microsoft 客戶金鑰
Microsoft 365 進階稽核
Microsoft 記錄管理
Office 365 電子檔探索 (Premium)
Office 365 進階電子文件探索
適用於 Office 365 的 Microsoft Defender (方案 1)
適用於 Office 365 的 Microsoft Defender (方案 2)
Office 365 特殊許可權存取管理
Office 365 中的進階加密

移轉失敗

MailboxNotInCrossTenantMigrationScopeException

請確定已在來源租用戶上正確設定移轉範圍，且MailboxMovesPublishedScopes已在與目標租使用者的組織關聯性中設定。
確認要移轉的信箱已新增至來源租使用者中的安全組。
將使用者新增至正確的安全組之後，請繼續移轉批次。
AuxArchiveNotFoundInTargetRecipientException

此失敗是因為啟動批次時，使用者不在移轉範圍中，且使用者在來源上具有 AuxArchive。
將使用者新增至來源目標上的正確安全組。
從批次中移除移轉使用者。
使用下列命令移除使用者：
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
將使用者新增至新的批次。
MailboxIsNotInExpectedDBException

此失敗是因為內部 Microsoft 維護所造成。
從批次中移除移轉使用者。
使用下列命令移除使用者：
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
將使用者新增至新的批次。
NotAcceptedDomainException

目標使用者上有無效的 Proxy 位址戳記。例如，contoso.onmicrosoft.com 中的使用者具有 fabrikam.onmicrosoft.com 的 Proxy 位址，也就是來源租使用者。
使用下列命令移除無效的 Proxy 位址：
```
Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
```
繼續移轉批次。
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

已在移轉期間布建新的 AuxArchive。
從批次中移除移轉使用者。
使用下列命令移除使用者：
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser 
```
將使用者新增至新的批次。
UserDuplicateInOtherBatchException

用戶已經存在於另一個批次中。
從批次中移除移轉使用者。
使用下列命令移除使用者：
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
將使用者新增至新的批次。
MissingExchangeGuidException

目標 mailuser 物件遺漏正確的 ExchangeGuid 值。
使用下列命令更新 ExchangeGuid：
```
Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8  
```
繼續移轉批次。
SourceMailboxAlreadyBeingMovedPermanentException

來源信箱已經有現有的移動要求。調查並移除現有的移動。這可能是 Microsoft 內部移動，您必須等候移動完成。
從批次中移除移轉使用者。
使用下列命令移除使用者：
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
在移除或完成原始移動之後，將使用者新增至新的批次。
UserAlreadyHasDemotedArchiveException

使用者先前已停用封存信箱。請選擇下列兩個選項之一來解決此問題。
永久刪除已停用的封存信箱，這是無法復原的。 Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
使用下列命令重新啟用已停用的封存信箱：
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
如果您重新啟用已停用的封存信箱，則必須更新目標 mailuser 物件上的封存 GUID。
繼續移轉批次。

共用方式為

跨租用戶信箱移轉

授權

準備來源和目標租使用者

來源和目標租使用者的必要條件

啟用租用戶進行跨租使用者信箱移轉的設定步驟

建立移移應用程式和密碼以準備目標 (目的地) 租使用者

授與同意給應用程式

建立 Exchange Online 移轉端點和組織關係，以準備目標租使用者

接受移轉應用程式並設定組織關係，) 租用戶準備目前信箱位置的來源 (

準備目標用戶物件以進行移轉

目標用戶物件的必要條件

如何知道這是否正常運作？

將信箱移回原始來源

執行信箱移轉

建立移轉批次

更新內部部署MailUsers

移轉後移除端點和組織關係

常見問題集

移動之後，是否需要更新來源內部部署租使用者中的 RemoteMailboxes？

來源交換組織

目標 Exchange 組織

Teams 會議是否移轉跨租使用者？

跨租用戶移轉哪些內容？

Outbox 中的專案是否已跨租使用者移轉？

Teams 聊天資料夾內容是否跨租使用者移轉？

如何只看到跨租用戶移動的移動，而不是我的上線和離線移動？

您可以提供範例腳本來複製測試中使用的屬性嗎？

如何在移動使用者信箱之後，於第 1 天存取 Outlook？

我需要屬於哪些 Exchange RBAC 角色，才能設定或完成跨租用戶移動？

如何針對已轉換信箱上的 targetAddress (TargetDeliveryDomain) 選取哪個 SMTP 位址， (轉換為 MailUser 轉換) ？

郵件流程在移轉后如何運作？

信箱許可權如何轉換？

應該將哪些 X500 Proxy 新增至目標 MailUser Proxy 位址以啟用移轉？

來源和目標租使用者是否可以使用相同的功能變數名稱？

共用信箱會移動並仍可運作嗎？

您有任何批次的建議嗎？

如果我搭配 Microsoft Purview 客戶密鑰使用服務加密，該怎麼辦？

預估的移轉時間為何？

保護目的地租用戶中使用者可取用來源租使用者中的檔。**

我是否可以在目的地租用戶中擁有與您在來源租使用者中相同的標籤，根據組織之間的一致性，作為唯一的標籤或一組額外的標籤給已移轉的使用者。**

您是否支援移動 Microsoft 365 群組？

來源租用戶系統管理員是否可以在信箱移轉至新的/目標租用戶之後，對信箱執行電子檔探索搜尋？

此時，目的地 MailUser 會轉換成目的地信箱，而來源信箱會轉換成來源 MailUser？

我應該在哪個步驟將 Exchange Online 授權指派給目的地 MailUsers？

如果我保留內部部署 Active Directory，可以使用 Microsoft Entra Connect 將使用者同步至新的租使用者嗎？

我應該如何處理接近或超過配額的信箱。

自動展開的封存信箱是否移動？

我可以執行跨雲端租使用者到租用戶的移轉嗎？

語音信箱是否跨租使用者移轉？

信箱簽章是否跨租用戶移轉？

已知問題

移轉失敗

另請參閱

意見反應

其他資源