교차 테넌트 사서함 마이그레이션

아티클
03/07/2024

병합 또는 분석 중에 사용자의 Exchange Online 사서함을 새 테넌트로 이동하는 기능이 필요할 수 있습니다. 테넌트 간 사서함 마이그레이션을 사용하면 테넌트 관리자가 Exchange Online PowerShell 및 MRS와 같은 잘 알려진 인터페이스를 사용하여 사용자를 새 organization 전환할 수 있습니다.

관리자는 사서함 이동 관리 역할을 통해 사용할 수 있는 New-MigrationBatch cmdlet을 사용하여 테넌트 간 이동을 실행할 수 있습니다.

마이그레이션하는 사용자는 대상 테넌트 Exchange Online 시스템에 MailUser로 있어야 하며, 테넌트 간 이동을 사용하도록 설정하려면 특정 특성으로 표시됩니다. 시스템이 대상 테넌트에서 제대로 설정되지 않은 사용자를 이동하지 못합니다.

이동이 완료되면 원본 사용자 사서함이 로 변환 MailUser되고 targetAddress (Exchange에서 ExternalEmailAddress 로 표시됨) 대상 테넌트에 대한 라우팅 주소가 스탬프됩니다. 이 프로세스는 원본 테넌트에 레거시 MailUser 를 남기고 공존 및 메일 라우팅을 허용합니다. 비즈니스 프로세스가 허용하는 경우 원본 테넌트는 원본 MailUser를 제거하거나 메일 연락처로 변환할 수 있습니다.

테넌트 간 Exchange 사서함 마이그레이션은 하이브리드 또는 클라우드의 테넌트 또는 둘의 조합에 대해서만 지원됩니다.

이 문서에서는 테넌트 간 사서함 이동 프로세스를 설명하고 Exchange Online 사서함 콘텐츠 이동에 대한 원본 및 대상 테넌트 준비 방법에 대한 지침을 제공합니다.

중요

모든 유형의 보류에 있는 사서함은 마이그레이션되지 않으며 해당 사서함의 이동이 차단됩니다.

사서함이 이 기능을 사용하여 테넌트 간으로 마이그레이션되면 사서함의 사용자 표시 콘텐츠(이메일, 연락처, 일정, 작업 및 메모)만 대상(대상 테넌트)으로 마이그레이션됩니다. 마이그레이션에 성공하면 원본 사서함이 삭제됩니다. 이 삭제는 마이그레이션 후에 원본 테넌트에서 사용 가능하거나 검색 가능하거나 액세스할 수 있는 원본 사서함이 없는 경우를 의미합니다.

라이선싱

중요

2022년 11월부터 테넌트 간 사용자 데이터 마이그레이션은 기업계약 고객을 위한 다음 Microsoft 365 구독 플랜에 대한 추가 기능으로 사용할 수 있으며 테넌트 간 마이그레이션에 필요합니다. 사용자 라이선스는 마이그레이션당(일회성 요금)이며 원본 또는 대상 사용자 개체에 할당할 수 있습니다. 이 라이선스는 비즈니스용 OneDrive 마이그레이션도 다룹니다. 자세한 내용은 Microsoft 계정 팀에 문의하세요.

테넌트 간 사용자 데이터 마이그레이션 추가 기능은 Microsoft 365 Business Basic, 표준 및 프리미엄에 대해 별도의 구매로 사용할 수 있습니다. 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 조직 관계에서 사서함 이동 애플리케이션을 구성하는 데 필요한 권한이 있는지 확인합니다.

또한 원본 테넌트에 메일 사용이 가능한 보안 그룹이 하나 이상 필요합니다. 이러한 그룹은 원본 테넌트(또는 리소스라고도 함)에서 대상 테넌트로 이동할 수 있는 사서함 목록을 scope 데 사용됩니다. 이 범위 지정을 사용하면 원본 테넌트 관리자가 이동해야 하는 특정 사서함 집합을 제한하거나 scope 의도하지 않은 사용자가 마이그레이션되지 않도록 할 수 있습니다.

10,000명 이상의 사용자를 마이그레이션하는 경우 최상의 성능을 위해 사용자 목록을 포함하도록 여러 그룹을 만드는 것이 좋습니다. 중첩된 그룹은 지원되지만 권장되지 않습니다.

또한 신뢰할 수 있는 파트너 회사(사서함을 이동할 대상)와 통신하여 Microsoft 365 테넌트 ID를 가져와야 합니다. 이 테넌트 ID는 조직 관계 DomainName 필드에 사용됩니다.

구독의 테넌트 ID를 가져오려면 Microsoft 365 관리 센터 로그인하고 로 https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView이동합니다. 테넌트 ID 속성의 복사 아이콘을 선택하여 클립보드에 복사합니다.

원본 및 대상 조직의 모든 사용자는 적절한 Exchange Online 구독으로 라이선스를 부여해야 합니다. 또한 대상 쪽으로 마이그레이션될 모든 사용자에게 테넌트 간 사용자 데이터 마이그레이션 라이선스를 적용해야 합니다.

테넌트 간 사서함 마이그레이션을 사용하도록 설정하는 구성 단계

참고

먼저 대상(대상)을 구성해야 합니다. 이러한 단계를 완료하려면 원본 및 대상 테넌트 모두에 대한 테넌트 관리자 자격 증명을 가지고 있거나 알 필요가 없습니다. 다른 관리자가 각 테넌트에 대해 단계를 개별적으로 수행할 수 있습니다.

마이그레이션 애플리케이션 및 암호를 생성하여 대상(대상) 테넌트 준비

대상 테넌트 관리자 자격 증명을 사용하여 Microsoft Entra 관리 센터(https://portal.azure.com)에 로그인합니다.
Microsoft Entra ID 관리에서 보기를 선택합니다.
탐색 창에서 앱 등록 선택합니다.
새 등록을 선택합니다.
애플리케이션 등록 페이지의 지원되는 계정 유형에서 모든 조직 디렉터리의 계정(모든 Microsoft Entra 디렉터리 - 다중 테넌트)을 선택합니다. 그런 다음 리디렉션 URI(선택 사항)에서 웹을 선택한 다음 를 입력합니다 https://office.com. 그런 다음 등록을 선택합니다.

페이지의 오른쪽 위 모서리에서 앱이 성공적으로 생성되었음을 나타내는 알림 대화 상자를 참조하세요.
홈페이지로 돌아가기 Microsoft Entra ID 이동한 다음, 앱 등록 선택합니다.
소유 애플리케이션에서 만든 앱을 찾은 다음 선택합니다.
Essentials 애플리케이션(클라이언트) ID를 복사합니다. 대상 테넌트의 URL을 만들려면 나중에 이 정보가 필요합니다.
탐색 창에서 API 권한을 선택하여 앱에 할당된 권한을 확인합니다.
기본적으로 User.Read 권한은 사용자가 만든 앱에 할당되지만 사서함 마이그레이션에는 이러한 권한이 필요하지 않습니다. 이러한 사용 권한을 제거할 수 있습니다.
편지함 마이그레이션에 대한 권한을 추가하려면 권한 추가를 선택합니다.
API 권한 요청 창에서 organization 사용하는 API를 선택하고 를 검색한 Office 365 Exchange Online다음 선택합니다.
애플리케이션 권한을 선택합니다.
권한 선택에서 사서함을 확장하고 Mailbox.Migration을 선택한 다음 화면 아래쪽에서 권한 추가를 선택합니다.
이제 애플리케이션의 탐색 창에서 인증서 & 비밀을 선택합니다.
클라이언트 비밀에서 새 클라이언트 암호를 선택합니다.
클라이언트 비밀 추가 창에서 설명을 입력한 다음 만료 설정을 구성합니다.

참고

암호는 마이그레이션 엔드포인트를 만들 때 사용됩니다. 이 암호를 클립보드 및/또는 보안/비밀 암호 안전한 위치에 복사하는 것이 매우 중요합니다. 비밀 만들기 단계는 이 암호를 볼 수 있는 유일한 시간입니다! 어떻게든 손실되거나 다시 설정해야 하는 경우 Azure Portal 다시 로그인하고, 앱 등록 이동하고, 마이그레이션 앱을 찾고, 비밀 & 인증서를 선택한 다음, 앱에 대한 새 비밀을 만들 수 있습니다.

마이그레이션 애플리케이션 및 비밀을 성공적으로 만들었으므로 다음 단계는 애플리케이션에 동의하는 것입니다.

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

참고

방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID가 필요합니다. 위의 예제에서 contoso.onmicrosoft.com 원본 테넌트의 올바른 onmicrosoft.com 이름으로 바꿔야 합니다. 또한 [application_id_of_the_app_you_just_created]을 방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID로 바꿔야 합니다.

Exchange Online 마이그레이션 엔드포인트 및 조직 관계를 만들어 대상 테넌트 준비

대상 Exchange Online 테넌트에서 Exchange Online PowerShell에 연결합니다.

테넌트 간 사서함 이동에 대한 새 마이그레이션 엔드포인트를 만듭니다.

참고

방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID와 마이그레이션 애플리케이션 및 비밀을 만들어 대상(대상) 테넌트 준비에서 구성한 암호(비밀)가 필요합니다. 사용하는 Microsoft 365 클라우드 instance 따라 엔드포인트가 다를 수 있습니다. Microsoft 365 엔드포인트 페이지를 참조하세요. 테넌트에서 올바른 instance 선택한 다음 Exchange Online 최적화/필수 주소를 검토하고 적절하게 바꿉니다.

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

새 organization 관계 개체를 만들거나 기존 organization 관계 개체를 원본 테넌트로 편집합니다.

$sourceTenantId = "[tenant ID of your trusted partner, where the source mailboxes are]"
$orgrelname = "[name of your new organization relationship]"
$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 $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

마이그레이션 애플리케이션을 수락하고 organization 관계를 구성하여 원본(현재 사서함 위치) 테넌트 준비

브라우저를 사용하여 신뢰할 수 있는 파트너가 제공한 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

참고

방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID가 필요합니다. 이전 예제에서 를 원본 테넌트의 onmicrosoft.com URL로 바꿔 contoso.onmicrosoft.com 야 합니다. 또한 [application_id_of_the_app_you_just_created]을 방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID로 바꿔야 합니다.
팝업이 표시되면 애플리케이션을 수락합니다. Microsoft Entra 관리 센터 로그인하고 엔터프라이즈 애플리케이션에서 애플리케이션을 찾을 수도 있습니다.
원본 Exchange Online 테넌트에서 Exchange Online PowerShell에 연결합니다.

새 organization 관계 개체를 만들거나 기존 organization 관계 개체를 Exchange Online PowerShell의 대상(대상) 테넌트로 편집합니다.

$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]"
$orgrelname = "[name of your new organization relationship]"
# Enable customization if tenant is dehydrated
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host "Group already exists." }
$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 $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

참고

$sourceTenantId 및 $targetTenantId로 입력하는 테넌트 ID는 테넌트 도메인 이름이 아닌 GUID입니다. 테넌트 ID의 예 및 테넌트 ID 찾기에 대한 정보는 Microsoft 365 테넌트 ID 찾기를 참조하세요.

마이그레이션을 위한 대상 사용자 개체 준비

마이그레이션하는 사용자는 테넌트 간 이동을 사용하도록 설정하려면 특정 특성으로 표시된 대상 테넌트 및 Exchange Online 시스템(MailUser)에 있어야 합니다. 시스템이 대상 테넌트에서 제대로 설정되지 않은 사용자를 이동하지 못합니다. 대상 사용자 개체에 대한 필수 구성 요소 섹션에서는 대상 테넌트에 대한 MailUser 개체 요구 사항을 자세히 설명합니다.

대상 사용자 개체에 대한 필수 구성 요소

대상 organization 다음 개체 및 특성이 설정되어 있는지 확인합니다.

팁

Microsoft는 많은 특성을 설정하는 보안 자동화된 방법을 제공하는 기능을 개발하고 있습니다(이 섹션에서는 아래에 지정됨). 테넌트 간 ID 매핑이라는 이 기능은 현재 소규모 프라이빗 미리 보기에 참여하려는 고객을 찾고 있습니다. 이 시험판 기능과 테넌트 간 마이그레이션 프로세스를 간소화하는 방법에 대한 자세한 내용은 테넌트 간 ID 매핑을 참조하세요.

원본 organization 이동하는 사서함의 경우 대상 organization MailUser 개체를 프로비전해야 합니다.

대상 MailUser에는 원본 사서함의 이러한 특성이 있거나 새 User 개체와 함께 할당되어야 합니다.

ExchangeGUID(원본에서 대상으로의 직접 흐름): 사서함 GUID가 일치해야 합니다. 이 특성이 대상 개체에 없는 경우 이동 프로세스가 진행되지 않습니다.
ArchiveGUID(원본에서 대상으로의 직접 흐름): 보관 GUID가 일치해야 합니다. 이 특성이 대상 개체에 없는 경우 이동 프로세스가 진행되지 않습니다. (이 특성은 원본 사서함이 보관을 사용하도록 설정된 경우에만 필요합니다.)
LegacyExchangeDN(flow as proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN은 대상 MailUser에 x500: proxyAddress로 있어야 합니다. 또한 원본 사서함의 모든 x500 주소를 대상 메일 사용자에게 복사해야 합니다. 이러한 x500 주소가 대상 개체에 없으면 이동 프로세스가 진행되지 않습니다. 또한 이 단계는 마이그레이션 전에 전송된 전자 메일에 대한 회신 기능을 사용하도록 설정하는 데 중요합니다. 각 전자 메일 항목의 보낸 사람/받는 사람 주소와 Microsoft Outlook 및 OWA(Microsoft Outlook Web App)의 자동 완성 캐시는 LegacyExchangeDN 특성의 값을 사용합니다. LegacyExchangeDN 값을 사용하여 사용자를 배치할 수 없는 경우 전자 메일 메시지 배달이 5.1.1 NDR로 실패할 수 있습니다.
UserPrincipalName: UPN은 사용자의 NEW ID 또는 대상 회사(예: user@northwindtraders.onmicrosoft.com)에 맞춰집니다.
기본 SMTPAddress: 기본 SMTP 주소는 사용자의 NEW 회사(예: user@northwindtraders.com)에 맞춰집니다.
TargetAddress/ExternalEmailAddress: MailUser는 원본 테넌트에서 호스트되는 사용자의 현재 사서함을 참조합니다(예: user@contoso.onmicrosoft.com). 이 값이 할당되는 경우 PrimarySMTPAddress를 할당하고 있는지 확인합니다. 그렇지 않으면 이 값은 PrimarySMTPAddress를 설정하므로 이동 오류가 발생합니다.

원본 사서함에서 대상 MailUser에 레거시 smtp 프록시 주소를 추가할 수 없습니다. 예를 들어 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

예제 원본 사서함 개체:

특성	값
별칭	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 및 프록시 주소로 올바르게 설정된 경우에만 적용할 수 있습니다. ExchangeGUID가 적용되기 전에 라이선스를 적용하면 대상 organization 새 사서함이 프로비전됩니다. 테넌트 간 사용자 데이터 마이그레이션 라이선스도 적용해야 합니다. 그렇지 않으면 일시적인 오류 읽기에 승인이 필요한 것으로 표시될 수 있으며, 이 오류는 이동 보고서에서 라이선스가 대상 사용자에게 적용되지 않았다는 경고를 보고합니다.

참고

Mailbox 또는 MailUser 개체에 라이선스를 적용하면 모든 SMTP 형식 proxyAddresses가 삭제되어 확인된 도메인만 Exchange EmailAddresses 배열에 포함되도록 합니다.
대상 MailUser에 원본 ExchangeGUID와 일치하지 않는 이전 ExchangeGUID가 없는지 확인해야 합니다. 대상 MEU가 이전에 Exchange Online 대한 라이선스를 부여하고 사서함을 프로비전한 경우 이 불일치가 발생할 수 있습니다. 대상 MailUser에 대해 이전에 라이선스가 부여되었거나 원본 ExchangeGUID와 일치하지 않는 ExchangeGUID가 있는 경우 클라우드 MEU 정리를 수행해야 합니다. 이러한 클라우드 MEU의 경우 를 실행할 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로 업데이트합니다.

마이그레이션 후 엔드포인트 및 organization 관계 제거

마이그레이션이 완료된 후 Remove-MigrationEndpoint cmdlet을 사용하여 원본 또는 대상 서버에 대한 기존 마이그레이션 엔드포인트를 제거합니다.

마이그레이션이 완료된 후 Remove-OrganizationRelationship cmdlet을 사용하여 원본 또는 대상 서버에 대한 기존 organization 관계를 제거합니다.

질문과 대답

이동 후 원본 온-프레미스 테넌트에서 RemoteMailboxes를 업데이트해야 하나요?

원본 Exchange 조직

원본 테넌트 사서함이 대상 테넌트로 이동할 때 각 원본 온-프레미스 사용자의 targetAddress(RemoteRoutingAddress/ExternalEmailAddress)를 업데이트해야 합니다. 메일 라우팅은 다른 targetAddresses를 사용하는 여러 메일 사용자의 추천을 따를 수 있지만 메일 사용자에 대한 약속 있음/없음 조회는 사서함 사용자의 위치를 대상으로 해야 합니다 .

대상 Exchange 조직

하이브리드 organization 마이그레이션이 완료되면 사용자가 온-프레미스에 원격 사서함을 포함하도록 하려면 다음 PowerShell 명령을 실행합니다.

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

Teams 모임이 테넌트 간을 마이그레이션합니까?

Teams 모임이 이동하는 동안 항목이 테넌트 간을 마이그레이션할 때 모임 URL이 업데이트되지 않습니다. 대상 테넌트에서 URL이 잘못되었으므로 Teams 모임을 제거하고 다시 만들어야 합니다.

마이그레이션된 테넌트 간 콘텐츠는 무엇인가요?

이 기능을 사용하여 테넌트 간 사서함을 마이그레이션하는 경우 정보 저장소의 최상위(전자 메일, 연락처, 일정, 작업 및 메모)라고도 하는 사서함의 사용자 표시 콘텐츠만 마이그레이션되고 복구 가능한 항목 폴더 삭제, 버전 및 제거가 마이그레이션됩니다.

아웃박스의 항목이 테넌트 간 마이그레이션을 받나요?

이 폴더는 Outlook 클라이언트와 관련된 클라이언트 기반 폴더이므로 Outbox의 항목은 테넌트 간 마이그레이션되지 않습니다. 아웃박스의 항목은 로컬로 저장되고 클라우드와 동기화되지 않습니다.

Teams 채팅 폴더 콘텐츠가 테넌트 간을 마이그레이션하나요?

아니요, Teams 채팅 폴더 콘텐츠는 테넌트 간을 마이그레이션하지 않습니다. 그러나 사서함이 테넌트 간 마이그레이션되면 원본 테넌트 관리자가 콘텐츠 검색을 사용하여 검색하고 내보낼 수 있도록 Teams 채팅 폴더 콘텐츠를 사용할 수 있습니다.

온보딩 및 오프보딩 이동이 아닌 테넌트 간 이동인 이동만 보려면 어떻게 해야 하나요?

Flags 매개 변수를 사용합니다.

Get-MoveRequest -Flags "CrossTenant"

테스트에 사용되는 특성을 복사하기 위한 예제 스크립트를 제공할 수 있나요?

참고

SAMPLE – AS IS, NO WARRANTY 이 스크립트는 원본 사서함(원본 값을 가져오기 위해) 및 대상 온-프레미스 Active Directory Domain Services(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 역할은 무엇인가요?

사서함 이동을 실행할 때 위임된 의무의 가정에 따라 역할 행렬이 있습니다. 현재 두 가지 역할이 필요합니다.

첫 번째 역할은 테넌트/조직 경계로 또는 외부로 콘텐츠를 이동하는 권한 부여를 설정하는 일회성 설정 작업에 대한 것입니다. 모든 회사에서 조직 제어에서 데이터를 이동하는 것이 중요한 문제이므로 조직 관리자의 가장 높은 할당된 역할을 선택했습니다. 이 역할은 원격 organization 사용하여 설정을 정의하는 -MailboxMoveCapability 새 OrganizationRelationship을 변경하거나 설정해야 합니다. organization 관리자만 설정을 변경할 -MailboxMoveCapability 수 있지만 OrganizationRelationship의 다른 특성은 페더레이션 공유 관리자가 관리할 수 있습니다.
실제 이동 명령을 실행하는 역할은 하위 수준 함수에 위임할 수 있습니다. 사서함 이동의 역할은 사서함을 organization 안팎으로 이동하는 기능에 할당됩니다.

변환된 사서함(MailUser 변환)에서 targetAddress(TargetDeliveryDomain)에 대해 선택된 SMTP 주소를 대상으로 지정하려면 어떻게 해야 할까요?

Exchange 사서함은 대상 개체의 전자 메일 주소(proxyAddress)를 일치시켜 MailUser로 변환할 때 MRS를 사용하여 원래 원본 사서함에서 targetAddress를 만듭니다. 프로세스는 명령에 전달된 값을 취한 -TargetDeliveryDomain 다음 대상 쪽에서 해당 도메인에 대한 일치하는 프록시를 확인합니다. 일치 항목을 찾으면 일치하는 proxyAddress를 사용하여 변환된 사서함(현재 MailUser) 개체에서 ExternalEmailAddress(targetAddress)를 설정합니다.

마이그레이션 후 메일 흐름은 어떻게 작동하나요?

마이그레이션 후 테넌트 간 메일 흐름은 Exchange 하이브리드 메일 흐름과 유사하게 작동합니다. 마이그레이션된 각 사서함에는 원본 테넌트에서 대상 테넌트 사서함으로 들어오는 메일을 전달하기 위해 올바른 대상 주소가 있는 원본 MailUser가 필요합니다. 전송 규칙, 보안 및 규정 준수 기능은 메일이 흐르는 각 테넌트에서 구성된 대로 실행됩니다. 따라서 인바운드 메일의 경우 스팸 방지, 맬웨어 방지, 격리, 전송 규칙 및 저널링 규칙과 같은 기능이 먼저 원본 테넌트에서 실행된 다음 대상 테넌트에서 실행됩니다.

사서함 권한은 어떻게 전환합니까?

사서함 권한에는 대신 보내기 및 사서함 액세스가 포함됩니다.

대신 보내기(AD:publicDelegates)는 사용자의 사서함에 대한 액세스 권한이 있는 받는 사람의 DN을 대리인으로 저장합니다. 이 값은 Active Directory에 저장되며 현재 사서함 전환의 일부로 이동하지 않습니다. 원본 사서함에 publicDelegates가 설정된 경우 를 실행 Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>하여 대상 사서함에 대한 MEU 변환이 완료되면 대상 사서함에 publicDelegates를 다시 설치해야 합니다.
사서함에 저장된 사서함 사용 권한은 보안 주체와 대리자 모두 대상 시스템으로 이동하면 사서함과 함께 이동합니다. 예를 들어 테넌트 SourceCompany.onmicrosoft.com 사서함 TestUser_8 TestUser 7 사용자에게 FullAccess가 부여됩니다. 사서함이 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

참고

테넌트 간 사서함 및 일정 권한은 지원되지 않습니다. 이러한 연결된 사서함이 원본 테넌트에서 동시에 전환되도록 보안 주체와 대리자를 통합 이동 일괄 처리로 구성해야 합니다.

마이그레이션을 사용하도록 설정하려면 대상 MailUser 프록시 주소에 어떤 X500 프록시를 추가해야 하나요?

테넌트 간 사서함 마이그레이션을 수행하려면 원본 사서함 개체의 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 프록시 외에도 원본의 사서함에서 대상의 사서함으로 모든 X500 프록시를 복사해야 합니다. 드물지만 사서함의 X400 프록시 주소에서 실행할 수도 있지만 이동이 완료되기 위한 요구 사항은 아니지만 대상 메일 사용자 개체에 이 주소를 스탬프하는 것이 좋습니다.

원본 및 대상 테넌트가 동일한 도메인 이름을 활용할 수 있나요?

아니요, 원본 테넌트 및 대상 테넌트 도메인 이름은 고유해야 합니다(예: contoso.com 원본 도메인 및 northwindtraders.com 대상 도메인).

공유 사서함이 이동하고 계속 작동합니까?

예. 그러나 이 문서에 설명된 대로 저장소 권한만 유지합니다.

Exchange Online 받는 사람에 대한 권한 관리

일괄 처리에 대한 권장 사항이 있나요?

일괄 처리당 2,000개의 사서함을 초과하지 마세요. 동기화 중에 최종 사용자에게 영향을 주지 않으므로 컷오버 날짜 2주 전에 일괄 처리를 제출하는 것이 좋습니다. 50,000개가 넘는 사서함 수량에 대한 지침이 필요한 경우 CSAM 문의하거나 지원 요청을 열 수 있습니다.

Microsoft Purview 고객 키와 함께 서비스 암호화를 사용하는 경우 어떻게 해야 하나요?

사서함은 이동하기 전에 암호가 해독됩니다. 고객 키가 여전히 필요한 경우 대상 테넌트에서 구성되었는지 확인합니다. 자세한 내용은 여기를 참조 하세요.

예상 마이그레이션 시간은 얼마인가요?

마이그레이션을 계획하는 데 도움이 되도록 여기에 표시된 표에는 대량 사서함 마이그레이션 또는 개별 마이그레이션이 완료되는 시기를 예상하는 방법에 대한 지침이 표시됩니다. 이러한 추정치는 이전 고객 마이그레이션의 데이터 분석을 기반으로 합니다. 모든 환경이 고유하기 때문에 정확한 마이그레이션 속도는 다를 수 있습니다.

대상 테넌트에서 사용자가 사용할 수 있는 원본 테넌트에서 문서 보호.**

테넌트 간 마이그레이션은 사서함 데이터만 마이그레이션하고 다른 것은 마이그레이션하지 않습니다. 도움이 될 수 있는 다음 블로그 게시물에 설명된 여러 가지 다른 옵션이 있습니다.

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

원본 테넌트에서와 동일한 레이블을 원본 테넌트에서 사용할 수 있나요?

테넌트 간 마이그레이션은 레이블을 내보내지 않으며 테넌트 간에 레이블을 공유할 방법이 없으므로 대상 테넌트에서 레이블을 다시 만들어서만 이 목표를 달성할 수 있습니다.

Microsoft 365 그룹 이동을 지원합니까?

현재 테넌트 간 사서함 마이그레이션 기능은 Microsoft 365 그룹 마이그레이션을 지원하지 않습니다.

원본 테넌트 관리자가 사서함을 새/대상 테넌트로 마이그레이션한 후 사서함에 대해 eDiscovery 검색을 수행할 수 있나요?

아니요, 테넌트 간 사서함 마이그레이션 후 원본에서 마이그레이션된 사용자의 사서함에 대한 eDiscovery가 작동하지 않습니다. 이 eDiscovery 실패는 사서함이 대상 테넌트로 마이그레이션되고 이제 대상 테넌트에 속하므로 검색할 사서함이 원본에 더 이상 없기 때문입니다. 사서함 마이그레이션 후 eDiscovery는 대상 테넌트(현재 사서함이 있는 위치)에서만 수행할 수 있습니다. 마이그레이션 후 원본 사서함의 복사본을 원본 테넌트에 유지해야 하는 경우 원본 테넌트의 관리자는 향후 데이터에 대한 eDiscovery 작업을 위해 대체 사서함 사전 마이그레이션에 콘텐츠를 복사할 수 있습니다.

대상 MailUser는 어느 시점에서 대상 사서함으로 변환되고 원본 사서함은 원본 MailUser로 변환되나요?

이러한 변환은 마이그레이션 프로세스 중에 자동으로 수행됩니다. 수동 단계는 필요하지 않습니다.

대상 MailUsers에 Exchange Online 라이선스를 할당해야 하는 단계는 무엇입니까?

이 라이선스 할당은 마이그레이션이 완료되기 전에 수행할 수 있지만 ExchangeGUID 특성을 스탬핑하기 전에 라이선스를 할당하면 안 됩니다. 그렇지 않으면 MailUser 개체를 사서함으로 변환하지 못하고 대신 새 사서함이 만들어집니다. 이러한 위험을 완화하려면 마이그레이션이 완료될 때까지 기다렸다가 30일 유예 기간 동안 라이선스를 할당하는 것이 가장 좋습니다.

온-프레미스 Active Directory 유지하는 경우 Microsoft Entra Connect를 사용하여 사용자를 새 테넌트로 동기화할 수 있나요?

예. Microsoft Entra Connect의 두 인스턴스가 서로 다른 테넌트와 동기화되도록 할 수 있습니다. 그러나 알아야 할 몇 가지 사항이 있습니다.

이 문서에 제공된 스크립트를 사용하여 사용자의 계정을 미리 프로비전하면 안 됩니다. 대신 마이그레이션에 대한 scope 사용자의 선택적 OU 동기화를 수행하여 대상 테넌트 채우기를 수행할 수 있습니다. Microsoft Entra Connect 구성 중에 UPN이 일치하지 않는다는 경고가 표시됩니다.
하이브리드 Exchange의 현재 상태에 따라 온-프레미스 디렉터리 개체에 다른 테넌트와 동기화하기 전에 필요한 특성(예: msExchMailboxGUID 및 proxyAddresses)이 올바르게 채워져 있는지 확인해야 합니다. 그렇지 않으면 이중 사서함 및 마이그레이션 실패와 관련된 문제가 발생합니다.
UPN 전환을 관리하려면 몇 가지 추가 단계를 수행해야 하며, 컷오버 마이그레이션 중에 사용자 지정 도메인을 이동하지 않는 한 사용자에 대한 마이그레이션이 완료되면 온-프레미스에서 변경해야 합니다.

할당량에 가깝거나 할당량을 초과한 사서함을 처리하려면 어떻게 해야 하나요?

마이그레이션 전에 할당량에 근접한 사서함은 실제 마이그레이션 전이나 중에 할당량을 초과할 수 있습니다. 이 경우 이러한 사서함은 마이그레이션에 실패하며 수정 및 다시 시작해야 합니다. 이를 완화하려면 원본 테넌트 관리자가 마이그레이션 전에 또는 할당량에 가까운 사서함을 식별하고 사서함 크기를 줄이거나, 기본 보관 파일을 프로비전하거나, 경우에 따라 사용자의 사서함에 대한 자동 확장 보관을 사용하도록 설정하는 데 필요한 단계를 수행하는 것이 좋습니다.

참고

사용자에 대해 보관 또는 자동 확장 보관을 사용하도록 설정하면 올바른 보관 정책이 사용자에게 적용되고 프로세스가 실행되어 사서함 데이터를 새 위치로 이동하고 공간을 확보합니다.

자동 확장된 보관 사서함이 이동합니까?

문제: 자동 확장된 보관 파일을 마이그레이션할 수 없습니다. 예, 원본의 사용자가 자동 확장 보관을 사용하도록 설정하고 추가 보조 보관 파일이 있는 경우 테넌트 간 사서함 마이그레이션이 작동합니다. 보조 보관 사서함이 12개 이하인 사용자를 이동할 수 있습니다. 또한 대규모 기본, 대규모 기본 보관 및 대규모 보조 보관 사서함이 있는 사용자는 동기화하는 데 추가 시간이 필요하며 컷오버 날짜 전에 제출해야 합니다. 사서함 마이그레이션 프로세스 중에 원본 사서함이 확장되면 새 보조 보관 파일이 원본에 만들어지지만 대상에는 만들어지지 않으므로 마이그레이션이 실패합니다. 이 경우 일괄 처리에서 사용자를 제거하고 다시 제출해야 합니다.

클라우드 간 테넌트 간 마이그레이션을 수행할 수 있나요?

클라우드 테넌트 간 마이그레이션은 지원되지 않습니다. 예제 시나리오는 Office 365 Worldwide에서 Office 365 Government Cloud로 이동하는 것입니다.

음성 메일이 테넌트 간에 마이그레이션되었나요?

예, 음성 메일은 테넌트 간에 마이그레이션됩니다.

대상 사서함에서 첨부 파일로 전자 메일로 받은 음성 메일을 사용할 수 있습니다.
수신된 음성 메일은 음성 메일을 호출하고 저장된 메시지를 수신 대기하는 경우 Teams에서 사용할 수 있습니다. (원본에서 받은 VM은 저장된 메시지로 사용할 수 있음)
수신된 음성 메일은 마이그레이션 후 대상의 Teams 클라이언트 UI에서 사용할 수 없습니다.
음성 메일 인사말도 대상으로 마이그레이션됩니다.

사서함 서명이 테넌트 간에 마이그레이션되었나요?

사서함 서명은 테넌트 간에 마이그레이션되지 않으며 다시 만들어야 합니다.

알려진 문제

원본 테넌트에서 마이그레이션 후 Teams 기능은 제한됩니다. 사서함이 대상 테넌트로 마이그레이션된 후 원본 테넌트의 Teams는 더 이상 사용자의 사서함에 액세스할 수 없습니다. 사용자가 원본 테넌트 자격 증명을 사용하여 Teams에 로그인하는 경우 프로필 사진을 업데이트할 수 없음, 일정 애플리케이션 없음, 공용 팀을 검색하고 참가할 수 없는 기능 등의 기능이 손실됩니다.
소유되지 않은 smtp 프록시가 있는 클라우드 MailUsersAddress 블록 MRS 이동 대상 테넌트 MailUser 개체를 만들 때 모든 SMTP 프록시 주소가 대상 테넌트 organization 속하는지 확인해야 합니다. 로컬 테넌트에 속하지 않는 대상 메일 사용자에 SMTP proxyAddress가 있는 경우 MailUser를 사서함으로 변환할 수 없습니다. 이 방지는 사서함 개체가 테넌트가 신뢰할 수 있는 도메인(테넌트가 주장하는 도메인)에서만 메일을 보낼 수 있다는 보장 때문입니다.
대상 테넌트에서 Microsoft Entra Connect를 사용하여 온-프레미스에서 사용자를 동기화하는 경우 사서함이 있는 원본 테넌트를 가리키는 ExternalEmailAddress를 사용하여 온-프레미스 MailUser 개체를 프로비전하고 PrimarySMTPAddressLaraN@contoso.onmicrosoft.com를 대상 테넌트에 있는 도메인(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 개체를 사용하여 원본 사서함(대상 organization 관점에서) 또는 대상 사서함(원본 organization 관점에서)을 나타냅니다. MailUsers에는 디렉터리에 있는 사서함 사용자의 표시된 SMTP 주소를 나타내는 실제 사서함() 및 기본SMTP 주소의 smtp 주소를 가리키는 ExternalEmailAddress(ProxyTest@northwindtraders.onmicrosoft.comtargetAddress)가 있습니다. 일부 조직에서는 기본 SMTP 주소를 로컬 테넌트가 소유/확인한 주소가 아닌 외부 SMTP 주소로 표시하도록 선택합니다(예: contoso.com 아닌 northwindtraders.com). 그러나 라이선스 작업을 통해 Exchange 서비스 계획 개체가 MailUser에 적용되면 기본 SMTP 주소가 로컬 organization(contoso.com)에서 확인된 도메인으로 표시되도록 수정됩니다. 다음과 같은 두 가지 잠재적인 이유가 있습니다.
Exchange 서비스 계획이 MailUser에 적용되면 Microsoft Entra ID 프로세스는 로컬 organization 다른 테넌트에서 메일, 스푸핑 또는 메일을 보낼 수 없도록 프록시 스크러빙을 적용하기 시작합니다. 이러한 서비스 계획이 있는 수신자 개체의 모든 SMTP 주소는 로컬 organization 주소를 확인하지 않으면 제거됩니다. 예제의 경우와 마찬가지로 northwindtraders.com 도메인은 contoso.onmicrosoft.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

가 8(DeprovisionMailbox)으로 설정된 경우 msExchRemoteRecipientType 대상 테넌트로 마이그레이션되는 온-프레미스 MailUsers의 경우 Azure의 프록시 스크러빙 논리는 비소유 도메인을 제거하고 primarySMTP를 소유 도메인으로 다시 설정합니다. 온-프레미스 MailUser의 msExchRemoteRecipientType이 지워지면 프록시 스크럽 논리가 더 이상 적용되지 않습니다.

다음은 Exchange Online 포함하는 현재 서비스 계획의 전체 집합입니다.

이름
eDiscovery(프리미엄) 스토리지(500GB)
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 Archiving
Exchange Server용 Exchange Online Archiving
비활성 사용자 추가 기능 Exchange Online
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online 요금제 1
Exchange Online POP
Exchange Online Protection
인덱스를 사용하여 그래프 커넥터 검색
정보 장벽
Office 365 대한 Information Protection - 프리미엄
Office 365 Information Protection - 표준
MyAnalytics의 인사이트
Microsoft 정보 거버넌스
Microsoft Purview 감사(프리미엄)
Microsoft Bookings
Microsoft Business Center
Microsoft 데이터 조사
Microsoft MyAnalytics(전체)
Microsoft 통신 규정 준수
Microsoft Communications DLP
Microsoft 고객 키
Microsoft 365 고급 감사
Microsoft 레코드 관리
Office 365 eDiscovery(프리미엄)
Office 365 고급 eDiscovery
Office 365용 Microsoft Defender(계획 1)
Office 365용 Microsoft Defender(플랜 2)
권한 있는 액세스 관리 Office 365
Office 365 프리미엄 암호화

마이그레이션 실패

MailboxNotInCrossTenantMigrationScopeException

마이그레이션 scope 원본 테넌트에서 올바르게 설정되고 MailboxMovesPublishedScopes가 대상 테넌트와의 organization 관계에서 설정되었는지 확인합니다.
마이그레이션할 사서함이 원본 테넌트에서 보안 그룹에 추가되었는지 확인합니다.
사용자를 추가하여 보안 그룹을 수정한 후 마이그레이션 일괄 처리를 다시 시작합니다.
AuxArchiveNotFoundInTargetRecipientException

이 오류는 일괄 처리가 시작되고 사용자가 원본에 AuxArchive가 있을 때 마이그레이션 scope 사용자가 아니었기 때문입니다.
원본 대상의 올바른 보안 그룹에 사용자를 추가합니다.
일괄 처리에서 마이그레이션 사용자를 제거합니다.
다음 명령을 사용하여 사용자를 제거합니다.
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
새 일괄 처리에 사용자를 추가합니다.
MailboxIsNotInExpectedDBException

이 오류는 내부 Microsoft 유지 관리 때문입니다.
일괄 처리에서 마이그레이션 사용자를 제거합니다.
다음 명령을 사용하여 사용자를 제거합니다.
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
새 일괄 처리에 사용자를 추가합니다.
NotAcceptedDomainException

대상 사용자에게 스탬프가 찍된 잘못된 프록시 주소가 있습니다. 예를 들어 contoso.onmicrosoft.com 사용자가 원본 테넌트인 fabrikam.onmicrosoft.com 프록시 주소가 있는 경우입니다.
다음 명령을 사용하여 잘못된 프록시 주소를 제거합니다.
```
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

사용자에게 이전에 사용하지 않도록 설정된 보관 사서함이 있었습니다. 다음 두 가지 옵션 중 하나를 선택하여 이 문제를 resolve.
비활성화된 보관 사서함을 영구적으로 삭제합니다. 이는 복구할 수 없습니다. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
다음 명령을 사용하여 비활성화된 보관 사서함을 다시 사용하도록 설정합니다.
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
비활성화된 보관 사서함을 다시 사용하도록 설정하는 경우 대상 mailuser 개체의 보관 GUID를 업데이트해야 합니다.
마이그레이션 일괄 처리를 다시 시작합니다.

참고 항목

PowerShell로 Microsoft 365 관리
Microsoft Graph PowerShell SDK 시작하기
[https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]

다음을 통해 공유

교차 테넌트 사서함 마이그레이션

라이선싱

원본 및 대상 테넌트 준비

원본 및 대상 테넌트에 대한 필수 구성 요소

테넌트 간 사서함 마이그레이션을 사용하도록 설정하는 구성 단계

마이그레이션 애플리케이션 및 암호를 생성하여 대상(대상) 테넌트 준비

애플리케이션에 동의 부여

Exchange Online 마이그레이션 엔드포인트 및 조직 관계를 만들어 대상 테넌트 준비

마이그레이션 애플리케이션을 수락하고 organization 관계를 구성하여 원본(현재 사서함 위치) 테넌트 준비

마이그레이션을 위한 대상 사용자 개체 준비

대상 사용자 개체에 대한 필수 구성 요소

작동 여부는 어떻게 확인합니까?

사서함을 원래 원본으로 다시 이동

사서함 마이그레이션 수행

마이그레이션 일괄 처리 만들기

온-프레미스 MailUsers 업데이트

마이그레이션 후 엔드포인트 및 organization 관계 제거

질문과 대답

이동 후 원본 온-프레미스 테넌트에서 RemoteMailboxes를 업데이트해야 하나요?

원본 Exchange 조직

대상 Exchange 조직

Teams 모임이 테넌트 간을 마이그레이션합니까?

마이그레이션된 테넌트 간 콘텐츠는 무엇인가요?

아웃박스의 항목이 테넌트 간 마이그레이션을 받나요?

Teams 채팅 폴더 콘텐츠가 테넌트 간을 마이그레이션하나요?

온보딩 및 오프보딩 이동이 아닌 테넌트 간 이동인 이동만 보려면 어떻게 해야 하나요?

테스트에 사용되는 특성을 복사하기 위한 예제 스크립트를 제공할 수 있나요?

사용자 사서함을 이동한 후 1일째에 Outlook에 액세스하려면 어떻게 해야 할까요?

테넌트 간 이동을 설정하거나 완료하기 위해 멤버여야 하는 Exchange RBAC 역할은 무엇인가요?

변환된 사서함(MailUser 변환)에서 targetAddress(TargetDeliveryDomain)에 대해 선택된 SMTP 주소를 대상으로 지정하려면 어떻게 해야 할까요?

마이그레이션 후 메일 흐름은 어떻게 작동하나요?

사서함 권한은 어떻게 전환합니까?

마이그레이션을 사용하도록 설정하려면 대상 MailUser 프록시 주소에 어떤 X500 프록시를 추가해야 하나요?

원본 및 대상 테넌트가 동일한 도메인 이름을 활용할 수 있나요?

공유 사서함이 이동하고 계속 작동합니까?

일괄 처리에 대한 권장 사항이 있나요?

Microsoft Purview 고객 키와 함께 서비스 암호화를 사용하는 경우 어떻게 해야 하나요?

예상 마이그레이션 시간은 얼마인가요?

대상 테넌트에서 사용자가 사용할 수 있는 원본 테넌트에서 문서 보호.**

원본 테넌트에서와 동일한 레이블을 원본 테넌트에서 사용할 수 있나요?

Microsoft 365 그룹 이동을 지원합니까?

원본 테넌트 관리자가 사서함을 새/대상 테넌트로 마이그레이션한 후 사서함에 대해 eDiscovery 검색을 수행할 수 있나요?

대상 MailUser는 어느 시점에서 대상 사서함으로 변환되고 원본 사서함은 원본 MailUser로 변환되나요?

대상 MailUsers에 Exchange Online 라이선스를 할당해야 하는 단계는 무엇입니까?

온-프레미스 Active Directory 유지하는 경우 Microsoft Entra Connect를 사용하여 사용자를 새 테넌트로 동기화할 수 있나요?

할당량에 가깝거나 할당량을 초과한 사서함을 처리하려면 어떻게 해야 하나요?

자동 확장된 보관 사서함이 이동합니까?

클라우드 간 테넌트 간 마이그레이션을 수행할 수 있나요?

음성 메일이 테넌트 간에 마이그레이션되었나요?

사서함 서명이 테넌트 간에 마이그레이션되었나요?

알려진 문제

마이그레이션 실패

참고 항목

피드백

추가 리소스