테넌트 간 사서함 마이그레이션(미리 보기)
일반적으로 병합 또는 분할 중에 사용자의 Exchange Online 사서함을 새 테넌트로 이동하는 기능이 필요합니다. 테넌트 간 사서함 마이그레이션을 통해 테넌트 관리자는 Exchange Online PowerShell 및 MRS와 같은 잘 알려진 인터페이스를 사용하여 사용자를 새 조직으로 전환할 수 있습니다.
관리자는 사서함 이동 관리 역할을 통해 사용할 수 있는 New-MigrationBatch cmdlet을 사용하여 테넌트 간 이동을 실행할 수 있습니다.
마이그레이션하는 사용자는 대상 테넌트 Exchange Online 시스템에 MailUsers로 있어야 하며, 테넌트 간 이동을 사용하도록 설정하려면 특정 특성으로 표시되어야 합니다. 대상 테넌트에서 제대로 설정되지 않은 사용자에 대한 시스템 이동이 실패합니다.
이동이 완료되면 원본 사용자 사서함이 MailUser로 변환되고 targetAddress(Exchange에서 ExternalEmailAddress로 표시됨)는 대상 테넌트에 대한 라우팅 주소로 스탬프됩니다. 이 프로세스는 레거시 MailUser를 원본 테넌트에 두고 공존 및 메일 라우팅을 허용합니다. 비즈니스 프로세스가 허용하는 경우 원본 테넌트는 원본 MailUser를 제거하거나 메일 연락처로 변환할 수 있습니다.
테넌트 간 Exchange 사서함 마이그레이션은 하이브리드 또는 클라우드의 테넌트에만 지원되거나 이 둘의 조합에 대해 지원됩니다.
이 문서에서는 테넌트 간 사서함 이동 프로세스를 설명하고 Exchange Online 사서함 콘텐츠 이동에 대한 원본 및 대상 테넌트 준비 방법에 대한 지침을 제공합니다.
참고
Azure Key Vault가 더 이상 필요하지 않게 테넌트 간 사서함 마이그레이션을 사용하도록 설정 단계를 최근에 업데이트했습니다. 이 미리 보기에 처음 온보딩하는 경우 아무 작업도 필요하지 않으며 이 문서에 자세히 설명된 단계를 진행할 수 있습니다. 이전 AKV 메서드를 사용하여 테넌트 구성을 시작한 경우 이 새 메서드 사용을 시작하려면 해당 구성을 중지하거나 제거하는 것이 좋습니다. 이전 AKV 방법으로 사서함 마이그레이션이 진행 중인 경우 기존 마이그레이션이 완료될 때까지 기다렸다가 아래 단계에 따라 새로운 간소화된 방법을 사용하도록 설정하세요. Azure Key Vault 필수 설정 단계는 보관되지만 참조를 위해 여기에서 찾을 수 있습니다.
원본 및 대상 테넌트 준비
원본 및 대상 테넌트에 대한 필수 구성 요소
시작하기 전에 Azure에서 사서함 이동 애플리케이션, EXO 마이그레이션 엔드포인트 및 EXO 조직 관계를 구성하는 데 필요한 권한이 있는지 확인하세요.
또한 원본 테넌트에 메일 사용이 가능한 보안 그룹이 하나 이상 필요합니다. 이러한 그룹은 원본(또는 리소스라고도 함) 테넌트에서 대상 테넌트로 이동할 수 있는 사서함 목록의 범위를 지정하는 데 사용됩니다. 이렇게 하면 원본 테넌트 관리자가 이동해야 하는 특정 사서함 집합을 제한하거나 범위를 지정하여 의도하지 않은 사용자가 마이그레이션되지 않도록 할 수 있습니다. 중첩 그룹은 지원되지 않습니다.
또한 Microsoft 365 테넌트 ID를 얻으려면 신뢰할 수 있는 파트너 회사(사서함을 이동할 대상)와 통신해야 합니다. 이 테넌트 ID는 조직 관계 DomainName 필드에 사용됩니다.
구독의 테넌트 ID를 가져오려면 Microsoft 365 관리 센터 로그인하고 .https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties 테넌트 ID 속성의 복사 아이콘을 클릭하여 클립보드에 복사합니다.
테넌트 간 사서함 마이그레이션을 사용하도록 설정하는 구성 단계
참고
먼저 대상(대상)을 구성해야 합니다. 이러한 단계를 완료하려면 원본 및 대상 테넌트 모두에 대한 테넌트 관리자 자격 증명을 가지고 있거나 알 필요가 없습니다. 다른 관리자가 각 테넌트에 대해 단계를 개별적으로 수행할 수 있습니다.
마이그레이션 애플리케이션 및 암호를 생성하여 대상(대상) 테넌트 준비
대상 테넌트 관리자 자격 증명을 사용하여 Azure AD 포털(https://portal.azure.com)에 로그인합니다.
Azure Active Directory 관리에서 보기를 클릭합니다.
왼쪽 탐색 모음에서 앱 등록을 선택합니다.
새 등록 선택
애플리케이션 등록 페이지의 지원되는 계정 유형에서 모든 조직 디렉터리의 계정을 선택합니다(모든 Azure AD 디렉터리 - 다중 테넌트). 그런 다음 리디렉션 URI(선택 사항)에서 웹을 선택하고 입력 https://office.com합니다. 마지막으로 등록을 선택합니다.
페이지의 오른쪽 위 모서리에 앱이 성공적으로 생성되었음을 나타내는 알림 팝업이 표시됩니다.
홈, Azure Active Directory로 돌아가서 앱 등록을 클릭합니다.
소유 애플리케이션에서 만든 앱을 찾아 클릭합니다.
^Essentials에서 애플리케이션(클라이언트) ID는 나중에 대상 테넌트에 대한 URL을 만드는 데 필요하므로 복사해야 합니다.
이제 왼쪽 탐색 모음에서 API 권한을 클릭하여 앱에 할당된 권한을 봅니다.
기본적으로 User입니다. 읽기 권한은 사용자가 만든 앱에 할당되지만 사서함 마이그레이션에는 필요하지 않으므로 해당 권한을 제거할 수 있습니다.
이제 사서함 마이그레이션에 대한 권한을 추가해야 합니다. 권한 추가를 선택합니다.
요청 API 권한 창에서 조직에서 사용하는 API를 선택하고, Office 365 Exchange Online 검색하고, 선택합니다.
다음으로, 애플리케이션 사용 권한을 선택합니다.
그런 다음, 사용 권한 선택에서 사서함을 확장하고, Mailbox.Migration을 선택하고, 화면 아래쪽에 있는 사용 권한을 추가합니다.
이제 애플리케이션의 왼쪽 탐색 모음에서 인증서 & 비밀을 선택합니다.
클라이언트 비밀에서 새 클라이언트 비밀을 선택합니다.
클라이언트 비밀 추가 창에서 설명을 입력하고 원하는 만료 설정을 구성합니다.
참고
마이그레이션 엔드포인트를 만들 때 사용되는 암호입니다. 이 암호를 클립보드에 복사하거나 이 암호를 복사하여 안전한/비밀 암호 안전한 위치에 복사하는 것이 매우 중요합니다. 이 암호를 볼 수 있는 유일한 시간입니다! 어떻게든 손실되거나 다시 설정해야 하는 경우 Azure Portal에 다시 로그인하고, 앱 등록으로 이동하고, 마이그레이션 앱을 찾고, 비밀 & 인증서를 선택하고, 앱에 대한 새 비밀을 만들 수 있습니다.
마이그레이션 애플리케이션과 시크릿을 성공적으로 생성했으므로 애플리케이션에 동의해야 합니다. 애플리케이션에 동의하려면 Azure Active Directory 방문 페이지로 돌아가서 왼쪽 탐색 영역에서 엔터프라이즈 애플리케이션을 클릭하고, 만든 마이그레이션 앱을 찾고, 선택하고, 왼쪽 탐색에서 사용 권한을 선택합니다.
[테넌트]에 대한 관리자 동의 부여 단추를 클릭합니다.
새 브라우저 창이 열리고 수락을 선택합니다.
포털 창으로 돌아가서 새로 고침을 선택하여 수락을 확인할 수 있습니다.
신뢰할 수 있는 파트너(원본 테넌트 관리자)에게 보낼 URL을 공식화하여 사서함 마이그레이션을 활성화하는 응용 프로그램을 수락할 수도 있습니다. 다음은 생성한 앱의 애플리케이션 ID가 필요한 URL의 예입니다.
https://login.microsoftonline.com/sourcetenant.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com참고
방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID가 필요합니다.
위의 예제에서 sourcetenant.onmicrosoft.com 올바른 onmicrosoft.com 이름을 원본 테넌트로 바꿔야 합니다.
또한 [application_id_of_the_app_you_just_created]을 방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID로 바꿔야 합니다.
Exchange Online 마이그레이션 엔드포인트 및 조직 관계를 만들어 대상 테넌트 준비
대상 Exchange Online 테넌트에서 Exchange Online PowerShell에 연결합니다.
테넌트 간 사서함 이동에 대한 새 마이그레이션 엔드포인트 만들기
참고
방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID와 이 프로세스 중에 구성한 암호(비밀)가 필요합니다. 또한 엔드포인트를 사용하는 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 "sourcetenant.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/sourcetenant.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com참고
방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID가 필요합니다. 위의 예제에서 sourcetenant.onmicrosoft.com 올바른 onmicrosoft.com 이름을 원본 테넌트로 바꿔야 합니다. 또한 [application_id_of_the_app_you_just_created]을 방금 만든 사서함 마이그레이션 앱의 애플리케이션 ID로 바꿔야 합니다.
팝업이 표시되면 애플리케이션을 수락합니다. Azure Active Directory 포털에 로그인하여 엔터프라이즈 애플리케이션에서 애플리케이션을 찾을 수도 있습니다.
새 조직 관계를 만들거나 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]" $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로 입력하는 테넌트 ID는 테넌트 도메인 이름이 아닌 GUID입니다. 테넌트 ID의 예 및 테넌트 ID 찾기에 대한 정보는 Microsoft 365 테넌트 ID 찾기를 참조하세요.
작동 여부는 어떻게 확인합니까?
대상 테넌트에서 만든 교차 테넌트 마이그레이션 엔드포인트에 대해 Test-MigrationServerAvailability cmdlet을 실행하여 교차 테넌트 사서함 마이그레이션 구성을 확인할 수 있습니다.
Test-MigrationServerAvailability -EndPoint "Migration endpoint for cross-tenant mailbox moves" - TestMailbox "Primary SMTP of MailUser object in target tenant"
사서함을 원래 원본으로 다시 이동
사서함이 원래 원본 테넌트로 다시 이동해야 하는 경우 새 원본 및 새 대상 테넌트 모두에서 동일한 단계 및 스크립트 집합을 실행해야 합니다. 기존 조직 관계 개체가 다시 만들어지지 않고 업데이트되거나 추가됩니다.
마이그레이션을 위한 대상 사용자 개체 준비
마이그레이션하는 사용자는 대상 테넌트 및 Exchange Online 시스템(MailUsers)에 있어야 특정 특성으로 표시되어 테넌트 간 이동을 사용할 수 있습니다. 대상 테넌트에서 제대로 설정되지 않은 사용자에 대한 시스템 이동이 실패합니다. 다음 섹션에서는 대상 테넌트에 대한 MailUser 개체 요구 사항을 자세히 설명합니다.
대상 사용자 개체에 대한 필수 구성 요소
대상 조직에 다음 개체 및 특성이 설정되어 있는지 확인합니다.
원본 조직에서 이동하는 사서함의 경우 대상 조직에서 MailUser 개체를 프로비전해야 합니다.
대상 MailUser에는 원본 사서함의 이러한 특성이 있거나 새 User 개체와 함께 할당되어야 합니다.
- ExchangeGUID(원본에서 대상으로의 직접 흐름): 사서함 GUID가 일치해야 합니다. 대상 개체에 없는 경우 이동 프로세스가 진행되지 않습니다.
- ArchiveGUID(원본에서 대상으로의 직접 흐름): 보관 GUID가 일치해야 합니다. 대상 개체에 없는 경우 이동 프로세스가 진행되지 않습니다. 원본 사서함을 보관할 수 있는 경우에만 필요합니다.
- LegacyExchangeDN(proxyAddress로 흐름, "x500:<LegacyExchangeDN>"): LegacyExchangeDN은 대상 MailUser에 x500: proxyAddress로 있어야 합니다. 또한 원본 사서함의 모든 x500 주소를 대상 메일 사용자에게 복사해야 합니다. 대상 개체에 없는 경우 이동 프로세스가 진행되지 않습니다.
- UserPrincipalName: UPN은 사용자의 새 ID 또는 대상 회사(예: user@northwindtraders.onmicrosoft.com)에 맞춥니다.
- 기본 SMTPAddress: 기본 SMTP 주소는 사용자의 새 회사(예: user@northwind.com)에 맞춰집니다.
- TargetAddress/ExternalEmailAddress: MailUser는 원본 테넌트에서 호스트되는 사용자의 현재 사서함을 참조합니다(예: user@contoso.onmicrosoft.com). 이 값을 할당할 때 PrimarySMTPAddress를 할당하고 있는지 확인하거나 이 값이 PrimarySMTPAddress를 설정하여 이동 오류가 발생하는지 확인합니다.
- 원본 사서함에서 대상 MailUser에 레거시 smtp 프록시 주소를 추가할 수 없습니다. 예를 들어 fabrikam.onmicrosoft.com 테넌트 개체)의 MEU에서 contoso.com 유지할 수 없습니다. 도메인은 하나의 Azure AD 또는 Exchange Online 테넌트에만 연결됩니다.
대상 MailUser 개체 예제:
특성 값 별칭 LaraN RecipientType MailUser RecipientTypeDetails MailUser UserPrincipalName LaraN@northwintraders.onmicrosoft.com PrimarySmtpAddress Lara.Newton@northwind.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=74e5385fce4b46d19006876949855035Lara EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c8190 7273f1f9-Lara smtp:LaraN@northwindtraders.onmicrosoft.com SMTP:Lara.Newton@northwind.com 예제 원본 사서함 개체:
특성 값 별칭 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=d11ec1a2cacd4f81858c81907273f1f9Lara EmailAddresses smtp:LaraN@contoso.onmicrosoft.com SMTP:Lara.Newton@contoso.com 추가 특성은 Exchange 하이브리드 쓰기 저장에 이미 포함될 수 있습니다. 그렇지 않은 경우 포함해야 합니다.
msExchBlockedSendersHash – 클라이언트에서 온-프레미스 Active Directory로 온라인 안전 및 차단된 보낸 사람 데이터를 다시 씁니다.
msExchSafeRecipientsHash – 클라이언트에서 온-프레미스 Active Directory로 안전한 온라인 및 차단된 보낸 사람 데이터를 다시 씁니다.
msExchSafeSendersHash – 클라이언트에서 온-프레미스 Active Directory로 안전한 온라인 및 차단된 보낸 사람 데이터를 다시 씁니다.
원본 사서함이 LitigationHold에 있고 원본 사서함 복구 가능한 항목 크기가 데이터베이스 기본값(30GB)보다 큰 경우 대상 할당량이 원본 사서함 크기보다 작기 때문에 이동이 진행되지 않습니다. 대상 MailUser 개체를 업데이트하여 ELC 사서함 플래그를 원본 환경에서 대상으로 전환할 수 있습니다. 그러면 대상 시스템이 MailUser의 할당량을 100GB로 확장하여 대상으로 이동할 수 있습니다. 이러한 지침은 ELC 플래그를 스탬프하는 명령이 테넌트 관리자에게 노출되지 않으므로 Azure AD Connect를 실행하는 하이브리드 ID에 대해서만 작동합니다.
참고
샘플 – 있는 그대로, 보증 없음
이 스크립트는 원본 사서함(원본 값을 가져오기 위해)과 대상 온-프레미스 Active Directory(ADUser 개체 스탬프)에 대한 연결을 가정합니다. 원본에 소송 또는 단일 항목 복구가 사용하도록 설정된 경우 대상 계정에서 설정합니다. 이렇게 하면 대상 계정의 쓰레기통 크기가 100GB로 증가합니다.
$ELCValue = 0 if ($source.LitigationHoldEnabled) {$ELCValue = $ELCValue + 8} if ($source.SingleItemRecoveryEnabled) {$ELCValue = $ELCValue + 16} if ($ELCValue -gt 0) {Set-ADUser -Server $domainController -Identity $destination.SamAccountName -Replace @{msExchELCMailboxFlags=$ELCValue}}비 하이브리드 대상 테넌트는 다음 명령을 실행하여 MailUser 개체에서 소송 보존을 사용하도록 설정하고 할당량을 100GB로 늘려 마이그레이션 전에 MailUsers에 대한 복구 가능한 항목 폴더의 할당량을 수정할 수 있습니다.
Set-MailUser -Identity <MailUserIdentity> -EnableLitigationHoldForMigration하이브리드의 테넌트에는 작동하지 않습니다.
대상 조직의 사용자는 조직에 적용할 수 있는 적절한 Exchange Online 구독의 라이선스가 있어야 합니다. 사서함 이동 전에 라이선스를 적용할 수 있지만 대상 MailUser가 ExchangeGUID 및 프록시 주소로 올바르게 설정된 경우에만 적용할 수 있습니다. ExchangeGUID가 적용되기 전에 라이선스를 적용하면 대상 조직에 새 사서함이 프로비전됩니다.
참고
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
사서함 마이그레이션 수행
테넌트 간 Exchange 사서함 마이그레이션은 대상 테넌트에서 마이그레이션 일괄 처리로 시작됩니다. 이는 Exchange 온-프레미스에서 Microsoft 365로 마이그레이션할 때 온보딩 마이그레이션 일괄 처리가 작동하는 방식과 같습니다.
마이그레이션 일괄 처리 만들기
다음은 이동을 시작하기 위한 마이그레이션 일괄 처리 cmdlet의 예입니다.
New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain target.onmicrosoft.com
Identity Status Type TotalCount
-------- ------ ---- ----------
T2Tbatch Syncing ExchangeRemoteMove 1
마이그레이션 일괄 처리 제출은 테넌트 간 옵션을 선택할 때 새 Exchange 관리 센터에서 도 지원됩니다.
온-프레미스 MailUsers 업데이트
사서함이 원본에서 대상으로 이동하면 원본과 대상 모두에서 온-프레미스 메일 사용자가 새 targetAddress로 업데이트되도록 해야 합니다. 예제에서 이동에 사용되는 targetDeliveryDomain은 contoso.onmicrosoft.com. 이 targetAddress로 메일 사용자를 업데이트합니다.
자주하는 질문
이동 후 원본 온-프레미스에서 RemoteMailboxes를 업데이트해야 합니까?
예, 원본 테넌트 사서함이 대상 테넌트로 이동할 때 원본 온-프레미스 사용자의 targetAddress(RemoteRoutingAddress/ExternalEmailAddress)를 업데이트해야 합니다. 메일 라우팅은 서로 다른 targetAddresses를 사용하는 여러 메일 사용자에 대한 추천을 따를 수 있지만 메일 사용자에 대한 약속 있음/없음 조회는 사서함 사용자의 위치를 대상으로 해야 합니다. 약속 있음/없음 조회는 여러 리디렉션을 추적하지 않습니다.
Teams 모임이 테넌트 간 마이그레이션을 수행합니까?
모임이 이동되지만 항목이 테넌트 간 마이그레이션 시 Teams 모임 URL이 업데이트되지 않습니다. 대상 테넌트에서 URL이 유효하지 않으므로 Teams 모임을 제거하고 다시 만들어야 합니다.
Teams 채팅 폴더 콘텐츠가 테넌트 간을 마이그레이션하나요?
아니요, Teams 채팅 폴더 콘텐츠는 테넌트 간을 마이그레이션하지 않습니다.
온보딩 및 오프보딩 이동이 아닌 테넌트 간 이동인 이동만 보려면 어떻게 해야 하나요?
Flags 매개 변수를 사용합니다. 예를 들면 다음과 같습니다.
Get-MoveRequest -Flags "CrossTenant"
테스트에 사용되는 특성을 복사하기 위한 예제 스크립트를 제공할 수 있나요?
참고
SAMPLE – AS IS, NO WARRANTY 이 스크립트는 원본 사서함(원본 값을 가져오기 위해) 및 대상 온-프레미스 چارند لړلیک شپول پالنې(ADUser 개체 스탬프)에 대한 연결을 가정합니다. 원본에 소송 또는 단일 항목 복구가 사용하도록 설정된 경우 대상 계정에서 설정합니다. 이렇게 하면 대상 계정의 쓰레기통 크기가 100GB로 증가합니다.
# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the Northwind org 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
$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
add-type -AssemblyName System.Web
foreach ($m in $mailboxes) {
$organization = "@contoso.onmicrosoft.com"
$mosi = $m.Alias+$organization
$Password = [System.Web.Security.Membership]::GeneratePassword(16,4) | ConvertTo-SecureString -AsPlainText -Force
$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 | ?{$_ -match "x500"}
$tmpx500 | %{Set-MailUser $m.Alias -EmailAddresses @{add="$_"}}
}
# Now sync 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 역할은 무엇인가요?
사서함 이동을 실행할 때 위임된 의무를 가정하여 역할 행렬이 있습니다. 현재 두 가지 역할이 필요합니다.
첫 번째 역할은 테넌트/조직 경계로 또는 외부로 콘텐츠를 이동하는 권한 부여를 설정하는 일회성 설정 작업에 대한 것입니다. 조직 제어에서 데이터를 이동하는 것은 모든 회사에 중요한 문제이므로 조직 관리자(OrgAdmin)의 가장 높은 할당된 역할을 선택했습니다. 이 역할은 원격 조직과의 -MailboxMoveCapability를 정의하는 새 OrganizationRelationship을 변경하거나 설정해야 합니다. OrgAdmin만 MailboxMoveCapability 설정을 변경할 수 있으며, OrganizationRelationship의 다른 특성은 페더레이션된 공유 관리자가 관리할 수 있습니다.
실제 이동 명령을 실행하는 역할은 하위 수준 함수에 위임할 수 있습니다. 이동 사서함의 역할은 조직 내/외부로 사서함을 이동하는 기능에 할당됩니다.
변환된 사서함에서 targetAddress(TargetDeliveryDomain)에 대해 선택한 SMTP 주소를 MailUser 변환으로 지정하려면 어떻게 해야 할까요?
Exchange 사서함은 대상 개체의 전자 메일 주소(proxyAddress)를 일치시켜 MailUser로 변환할 때 원래 원본 사서함에서 MRS를 사용하여 targetAddress를 만듭니다. 이 프로세스는 이동 명령에 전달된 -TargetDeliveryDomain 값을 취한 다음 대상 쪽에서 해당 도메인에 대해 일치하는 프록시를 확인합니다. 일치 항목을 찾으면 일치하는 proxyAddress를 사용하여 변환된 사서함(현재 MailUser) 개체에 ExternalEmailAddress(targetAddress)를 설정합니다.
사서함 권한은 어떻게 전환하나요?
사서함 권한에는 대신 보내기 및 사서함 액세스가 포함됩니다.
대신 보내기(AD:publicDelegates)는 사용자의 사서함에 대한 액세스 권한이 있는 받는 사람의 DN을 대리인으로 저장합니다. 이 값은 Active Directory에 저장되며 현재 사서함 전환의 일부로 이동하지 않습니다. 원본 사서함에 publicDelegates가 설정된 경우 MEU를 실행하여 대상 환경에서
Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>사서함으로의 변환이 완료되면 대상 사서함에 publicDelegates를 다시 설치해야 합니다.주체와 대리인이 모두 대상 시스템으로 이동되면 사서함에 저장된 사서함 사용 권한이 사서함과 함께 이동합니다. 예를 들어 사용자 TestUser_7 테넌트 SourceCompany.onmicrosoft.com 사서함 TestUser_8 FullAccess가 부여됩니다. 사서함 이동이 TargetCompany.onmicrosoft.com 완료되면 대상 디렉터리에 동일한 권한이 설정됩니다. 원본 및 대상 테넌트 모두에서 TestUser_7 Get-MailboxPermission 을 사용하는 예제는 다음과 같습니다. Exchange cmdlet에는 그에 따라 원본 및 대상이 접두사로 추가됩니다.
다음은 이동하기 전에 사서함 사용 권한의 출력 예입니다.
Get-SourceMailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny
User AccessRights IsInherited Deny
---- ------------ ----------- ----
NT AUTHORITY\SELF {FullAccess, ReadPermission} False False
TestUser_8@SourceCompany.onmicrosoft.com {FullAccess} False False
다음은 이동 후 사서함 권한 출력의 예입니다.
Get-TargetMailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny
User AccessRights IsInherited Deny
---- ------------ ----------- ----
NT AUTHORITY\SELF {FullAccess, ReadPermission} False False
TestUser_8@TargetCompany.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 프록시를 복사해야 합니다.
원본 및 대상 테넌트가 동일한 도메인 이름을 활용할 수 있나요?
아니요. 원본 및 대상 테넌트 도메인 이름은 고유해야 합니다. 예를 들어 contoso.com 원본 도메인 및 fourthcoffee.com 대상 도메인입니다.
공유 사서함이 이동하고 계속 작동합니까?
예, 그러나 다음 문서에 설명된 대로 저장소 권한만 유지합니다.
일괄 처리에 대한 권장 사항이 있나요?
일괄 처리당 사서함 2000개를 초과하지 마세요. 동기화 중에 최종 사용자에게 영향을 주지 않으므로 컷오버 날짜 2주 전에 일괄 처리를 제출하는 것이 좋습니다. 50,000개가 넘는 사서함 수량에 대한 지침이 필요한 경우 crosstenantmigrationpreview@service.microsoft.com 엔지니어링 피드백 배포 목록에 문의할 수 있습니다.
고객 키로 서비스 암호화를 사용하는 경우 어떻게 하나요?
사서함은 이동하기 전에 암호 해독됩니다. 고객 키가 여전히 필요한 경우 대상 테넌트에 구성되어 있는지 확인합니다. 자세한 내용은 여기 를 참조하세요.
예상 마이그레이션 시간은 얼마인가요?
마이그레이션을 계획하는 데 도움이 되도록 여기에 제시된 표에는 대량 사서함 마이그레이션 또는 개별 마이그레이션이 완료되는 경우에 대한 지침이 표시됩니다. 이러한 추정치는 이전 고객 마이그레이션의 데이터 분석을 기반으로 합니다. 모든 환경이 고유하기 때문에 정확한 마이그레이션 속도는 다를 수 있습니다.
이 기능은 현재 미리 보기 및 SLA에 있으며, 해당 서비스 수준은 이 기능의 미리 보기 상태 동안 성능 또는 가용성 문제에 적용되지 않습니다.
대상 테넌트에서 사용자가 사용할 수 있는 원본 테넌트에서 문서 보호.**
테넌트 간 마이그레이션은 사서함 데이터만 마이그레이션하고 다른 것은 마이그레이션하지 않습니다. 도움이 될 수 있는 다음 블로그 게시물에 설명된 여러 가지 다른 옵션이 있습니다. https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455
조직 간의 맞춤에 따라 마이그레이션된 사용자에 대한 유일한 레이블 집합 또는 추가 레이블 집합으로 원본 테넌트에 있는 것과 동일한 레이블을 대상 테넌트에 사용할 수 있나요.**
테넌트 간 마이그레이션은 레이블을 내보내지 않으며 테넌트 간에 레이블을 공유할 방법이 없으므로 대상 테넌트에서 레이블을 다시 만들어야만 수행할 수 있습니다.
Microsoft 365 그룹 이동을 지원합니까?
현재 테넌트 간 사서함 마이그레이션 기능은 Microsoft 365 그룹 마이그레이션을 지원하지 않습니다.
사서함이 새/대상 테넌트에 마이그레이션된 후 원본 테넌트 관리자가 사서함에 대해 eDiscovery 검색을 수행할 수 있나요?
아니요, 테넌트 간 사서함 마이그레이션 후 원본에서 마이그레이션된 사용자의 사서함에 대한 eDiscovery가 작동하지 않습니다. 사서함이 대상 테넌트에 마이그레이션되어 이제 대상 테넌트에 속하므로 검색할 사서함이 원본에 더 이상 없기 때문입니다. eDiscovery, 사서함 후 마이그레이션은 대상 테넌트(현재 사서함이 있는 위치)에서만 수행할 수 있습니다. 마이그레이션 후 원본 사서함의 복사본을 원본 테넌트에 유지해야 하는 경우 원본의 관리자는 향후 eDiscovery 작업을 위해 대체 사서함 사전 마이그레이션에 콘텐츠를 복사할 수 있습니다.
어느 시점에서 대상 MailUser가 대상 사서함으로 변환되고 원본 사서함이 원본 MailUser로 변환되나요?
이러한 변환은 마이그레이션 프로세스 중에 자동으로 수행됩니다. 수동 단계는 필요하지 않습니다.
대상 MailUsers에 Exchange Online 라이선스를 할당해야 하는 단계는 무엇인가요?
마이그레이션이 완료되기 전에 이 작업을 수행할 수 있지만 ExchangeGuid 특성을 스탬핑하기 전에 라이선스를 할당하지 않아야 합니다. 그렇지 않으면 MailUser 개체를 사서함으로 변환하지 못하고 대신 새 사서함이 만들어집니다. 이러한 위험을 완화하려면 마이그레이션이 완료될 때까지 기다렸다가 30일 유예 기간 동안 라이선스를 할당하는 것이 가장 좋습니다.
알려진 문제
문제: 원본 테넌트에서 마이그레이션 후 Teams 기능이 제한됩니다. 사서함이 대상 테넌트로 마이그레이션되면 원본 테넌트의 Teams는 더 이상 사용자의 사서함에 액세스할 수 없습니다. 따라서 사용자가 원본 테넌트 자격 증명을 사용하여 Teams에 로그인하는 경우 프로필 사진을 업데이트할 수 없음, 일정 응용 프로그램 없음, 공용 팀을 검색하고 참가할 수 없는 등의 기능이 손실됩니다.
문제: 자동 확장된 보관 파일을 마이그레이션할 수 없습니다. 테넌트 간 마이그레이션 기능은 특정 사용자에 대한 기본 사서함 및 보관 사서함의 마이그레이션을 지원합니다. 그러나 원본의 사용자에게 자동 확장된 보관함(둘 이상의 보관 사서함)이 있는 경우 이 기능은 추가 보관 파일을 마이그레이션할 수 없으므로 실패해야 합니다.
문제: 소유되지 않은 smtp proxyAddress 블록 MRS가 있는 Cloud MailUsers는 배경을 이동합니다. 대상 테넌트 MailUser 개체를 만들 때 모든 SMTP 프록시 주소가 대상 테넌트 조직에 속하는지 확인해야 합니다. 로컬 테넌트에 속하지 않는 대상 메일 사용자에 SMTP proxyAddress가 있는 경우 MailUser를 사서함으로 변환할 수 없습니다. 이는 사서함 개체가 테넌트가 신뢰할 수 있는 도메인(테넌트가 주장하는 도메인)에서만 메일을 보낼 수 있다는 보장 때문입니다.
Azure AD Connect를 사용하여 온-프레미스에서 사용자를 동기화하는 경우 사서함이 있는 원본 테넌트를 가리키는 ExternalEmailAddress를 사용하여 온-프레미스 MailUser 개체를 프로비전하고(LaraN@contoso.onmicrosoft.com) PrimarySMTPAddress를 대상 테넌트(Lara.Newton@northwind.com)에 있는 도메인으로 스탬프합니다. 이러한 값은 테넌트에 동기화되고 적절한 메일 사용자가 프로비전되어 마이그레이션할 준비가 된 것입니다. 예제 개체는 여기에 나와 있습니다.
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses ExternalEmailAddress EmailAddresses -------------------- -------------- SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwind.com}
참고
contoso.onmicrosoft.com 주소가 EmailAddresses/proxyAddresses 배열에 없습니다.
문제: "외부" 기본 SMTP 주소가 있는 MailUser 개체가 수정/"내부" 회사 클레임 도메인으로 다시 설정됨
MailUser 개체는 로컬이 아닌 사서함에 대한 포인터입니다. 테넌트 간 사서함 마이그레이션의 경우 MailUser 개체를 사용하여 원본 사서함(대상 조직의 관점에서) 또는 대상 사서함(원본 조직의 관점에서)을 나타냅니다. MailUsers에는 디렉터리에 있는 사서함 사용자의 표시된 SMTP 주소를 나타내는 실제 사서함(ProxyTest@fabrikam.onmicrosoft.com)의 smtp 주소와 primarySMTP 주소를 가리키는 ExternalEmailAddress(targetAddress)가 있습니다. 일부 조직에서는 기본 SMTP 주소를 로컬 테넌트가 소유/확인한 주소가 아닌 외부 SMTP 주소로 표시하도록 선택합니다(예: contoso.com 아닌 fabrikam.com). 그러나 라이선스 작업을 통해 Exchange 서비스 계획 개체가 MailUser에 적용되면 기본 SMTP 주소가 로컬 조직(contoso.com)에서 확인한 도메인으로 표시되도록 수정됩니다. 두 가지 잠재적인 이유가 있습니다.
Exchange 서비스 계획이 MailUser에 적용되면 Azure AD 프로세스는 로컬 조직에서 다른 테넌트로부터 메일, 스푸핑 또는 메일을 보낼 수 없도록 프록시 스크러빙을 적용하기 시작합니다. 이러한 서비스 계획이 있는 받는 사람 개체의 모든 SMTP 주소는 로컬 조직에서 주소를 확인하지 않으면 제거됩니다. 예제의 경우와 마찬가지로 Fabikam.com 도메인은 contoso.onmicrosoft.com 테넌트에서 확인되지 않으므로 스크러빙을 통해 해당 fabrikam.com 도메인이 제거됩니다. 마이그레이션 전이나 마이그레이션 후에 MailUser에서 이러한 외부 도메인을 유지하려면 이동이 완료된 후 또는 이동 전에 라이선스를 제거하도록 마이그레이션 프로세스를 변경하여 사용자에게 예상되는 외부 브랜딩이 적용되도록 해야 합니다. 사서함 개체가 메일 서비스에 영향을 미치지 않도록 라이선스가 제대로 부여되었는지 확인해야 합니다.
contoso.onmicrosoft.com 테넌트에서 MailUser에서 서비스 계획을 제거하는 예제 스크립트가 여기에 나와 있습니다.
$LO = New-MsolLicenseOptions -AccountSkuId "contoso:ENTERPRISEPREMIUM" DisabledPlans "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" Set-MsolUserLicense -UserPrincipalName ProxyTest@contoso.com LicenseOptions $lo할당된 ServicePlans 집합의 결과가 여기에 표시됩니다.
(Get-MsolUser -UserPrincipalName ProxyTest@contoso.com).licenses | Select-Object -ExpandProperty ServiceStatus |sort ProvisioningStatus -Descending ServicePlan ProvisioningStatus ----------- ------------------ ATP_ENTERPRISE PendingProvisioning MICROSOFT_SEARCH PendingProvisioning INTUNE_O365 PendingActivation PAM_ENTERPRISE Disabled EXCHANGE_ANALYTICS Disabled EQUIVIO_ANALYTICS Disabled THREAT_INTELLIGENCE Disabled LOCKBOX_ENTERPRISE Disabled PREMIUM_ENCRYPTION Disabled EXCHANGE_S_ENTERPRISE Disabled INFORMATION_BARRIERS Disabled MYANALYTICS_P2 Disabled MIP_S_CLP1 Disabled MIP_S_CLP2 Disabled ADALLOM_S_O365 PendingInput RMS_S_ENTERPRISE Success YAMMER_ENTERPRISE Success PROJECTWORKMANAGEMENT Success BI_AZURE_P2 Success WHITEBOARD_PLAN3 Success SHAREPOINTENTERPRISE Success SHAREPOINTWAC Success KAIZALA_STANDALONE Success OFFICESUBSCRIPTION Success MCOSTANDARD Success Deskless Success STREAM_O365_E5 Success FLOW_O365_P3 Success POWERAPPS_O365_P3 Success TEAMS1 Success MCOEV Success MCOMEETADV Success BPOS_S_TODO_3 Success FORMS_PLAN_E5 Success SWAY Success사용자의 PrimarySMTPAddress가 더 이상 스크러빙되지 않습니다. fabrikam.com 도메인은 contoso.onmicrosoft.com 테넌트가 소유하지 않으며 디렉터리에 표시된 기본 SMTP 주소로 유지됩니다.
예를 들면 다음과 같습니다.
Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId UserPrincipalName PrimarySmtpAddress ExternalEmailAddress ExternalDirectoryObjectId ----------------- ------------------ -------------------- ------------------------- ProxyTest@fabrikam.com ProxyTest@fabrikam.com SMTP:ProxyTest@fabrikam.com e2513482-1d5b-4066-936a-cbc7f8f6f817msExchRemoteRecipientType이 8(DeprovisionMailbox)로 설정된 경우 대상 테넌트로 마이그레이션되는 온-프레미스 MailUsers의 경우 Azure의 프록시 스크러빙 논리는 비소유 도메인을 제거하고 primarySMTP를 소유 도메인으로 다시 설정합니다. 온-프레미스 MailUser에서 msExchRemoteRecipientType을 지우면 프록시 스크럽 논리가 더 이상 적용되지 않습니다.
다음은 Exchange Online 포함하는 현재 서비스 계획의 전체 집합입니다.
이름 eDiscovery(프리미엄) 스토리지(500GB) 고객 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 정보 보호 - 프리미엄 Office 365 정보 보호 - 표준 MyAnalytics의 인사이트 Microsoft Purview 감사(프리미엄) Microsoft Bookings Microsoft Business Center Microsoft MyAnalytics(전체) Office 365 eDiscovery(프리미엄) Office 365용 Microsoft Defender(계획 1) Office 365용 Microsoft Defender(계획 2) 권한 있는 액세스 관리 Office 365 Office 365 프리미엄 암호화