Migrace poštovní schránky mezi tenanty

Článek
03/07/2024

Během fúze nebo odprodeje možná budete potřebovat možnost přesunout Exchange Online poštovní schránky uživatelů do nového tenanta. Migrace poštovních schránek mezi tenanty umožňuje správcům tenantů převést uživatele do nové organizace pomocí známých rozhraní, jako jsou Exchange Online PowerShell a MRS.

Správci můžou k provádění přesunů mezi tenanty použít rutinu New-MigrationBatch , která je dostupná prostřednictvím role správy přesunů poštovních schránek .

Migrující uživatelé musí být v cílovém tenantovi Exchange Online systému jako MailUser označeni konkrétními atributy, aby bylo možné přesuny mezi tenanty. Systému se nepodaří přesunout uživatele, kteří nejsou v cílovém tenantovi správně nastaveni.

Po dokončení přesunů se poštovní schránka zdrojového uživatele převede na MailUsertargetAddress a objekt (zobrazený jako ExternalEmailAddress v Exchangi) se orazítkem se směrovací adresou do cílového tenanta. Tento proces ponechá starší verzi MailUser ve zdrojovém tenantovi a umožňuje koexistenci a směrování pošty. Pokud to obchodní procesy povolují, může zdrojový tenant odebrat zdrojového uživatele MailUser nebo ho převést na poštovní kontakt.

Migrace poštovních schránek Exchange mezi tenanty se podporují jenom pro tenanty v hybridním nebo cloudovém prostředí nebo jejich kombinaci.

Tento článek popisuje proces přesunů poštovních schránek mezi tenanty a poskytuje pokyny k přípravě zdrojového a cílového tenanta pro přesun obsahu poštovní schránky Exchange Online.

Důležité

Poštovní schránky, které jsou blokovány jakýmkoli typem blokování, se nemigrují a přesun těchto poštovních schránek je blokovaný.

Při migraci poštovní schránky mezi tenanty pomocí této funkce se do cíle (cílového tenanta) migruje jenom obsah v poštovní schránce viditelný uživatelem (e-maily, kontakty, kalendář, úkoly a poznámky). Po úspěšné migraci se zdrojová poštovní schránka odstraní. Toto odstranění znamená, že po migraci není zdrojová poštovní schránka za žádných okolností dostupná, zjistitelná nebo přístupná ve zdrojovém tenantovi.

Licencování

Důležité

Migrace mezi tenanty vyžadují licenci na uživatele (jednorázový poplatek) a je možné je přiřadit zdrojovému nebo cílovému objektu uživatele. Tato licence se vztahuje také na migraci OneDrive pro firmy. Migrace uživatelských dat mezi tenanty je dostupná jako doplněk k následujícím plánům předplatného Microsoftu 365: Microsoft 365 Business Basic, Standard a Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; OneDrive pro firmy a EDU.

Upozornění

Před provedením dalších kroků musíte mít zakoupené nebo ověřené, že si můžete zakoupit licence na migraci uživatelských dat mezi tenanty. Migrace selžou, pokud se tento krok nedokončil. Microsoft nenabízí výjimky pro tento licenční požadavek.

Pokud nemáte k migrovanému uživateli přiřazenou správnou licenci, migrace se nezdaří a zobrazí se chyba podobná následující:

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.

Příprava zdrojových a cílových tenantů

Požadavky na zdrojové a cílové tenanty

Než začnete, ujistěte se, že máte potřebná oprávnění ke konfiguraci aplikace Přesun poštovní schránky v Azure, koncového bodu migrace EXO a vztahu organizace EXO.

Kromě toho je vyžadována alespoň jedna skupina zabezpečení s podporou pošty ve zdrojovém tenantovi. Tyto skupiny slouží k určení rozsahu seznamu poštovních schránek, které se můžou přesunout ze zdrojového tenanta (nebo někdy označovaného jako prostředek) na cílového tenanta. Toto vymezení rozsahu umožňuje správci zdrojového tenanta omezit nebo omezit konkrétní sadu poštovních schránek, které je potřeba přesunout, a zabránit tak migraci nezamýšlených uživatelů.

Pokud migrujete více než 10 000 uživatelů, doporučujeme vytvořit několik skupin, které budou obsahovat seznam uživatelů pro zajištění nejlepšího výkonu. Vnořené skupiny se sice podporují, ale nedoporučují se.

Abyste získali ID tenanta Microsoftu 365, musíte také komunikovat s důvěryhodnou partnerskou společností (se kterou budete poštovní schránky přesouvat). Toto ID tenanta se používá v poli Název domény vztahu organizace .

Pokud chcete získat ID tenanta předplatného, přihlaste se k Centrum pro správu Microsoftu 365 a přejděte na https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Vyberte ikonu kopírování pro vlastnost ID tenanta a zkopírujte ji do schránky.

Všichni uživatelé ve zdrojové i cílové organizaci musí mít licenci s příslušnými předplatnými Exchange Online. Také se ujistěte, že jste použili licence na migraci uživatelských dat mezi tenanty na všechny uživatele, kteří se budou migrovat na cílovou stranu.

Postup konfigurace pro povolení migrace poštovních schránek mezi tenanty

Poznámka

Nejprve musíte nakonfigurovat cíl (cíl). K provedení těchto kroků nemusíte mít ani znát přihlašovací údaje správce tenanta pro zdrojového i cílového tenanta. Jednotlivé kroky můžou pro každého tenanta provádět různí správci.

Příprava cílového (cílového) tenanta vytvořením aplikace pro migraci a tajného kódu

Přihlaste se k Centrum pro správu Microsoft Entra (https://portal.azure.com) pomocí přihlašovacích údajů správce cílového tenanta.
V části Spravovat Microsoft Entra ID vyberte Zobrazit.
V navigačním podokně vyberte Registrace aplikací.
Vyberte Nová registrace.
Na stránce Zaregistrovat aplikaci v části Podporované typy účtů vyberte Účty v libovolném organizačním adresáři (libovolný adresář Microsoft Entra – více tenantů). Pak v části Identifikátor URI přesměrování (volitelné) vyberte Web a zadejte https://office.com. Pak vyberte Zaregistrovat.

V pravém horním rohu stránky se podívejte na dialogové okno s oznámením, že se aplikace úspěšně vytvořila.
Zpět na domovskou stránku, přejděte na Microsoft Entra ID a vyberte Registrace aplikací.
V části Vlastněné aplikace najděte aplikaci, kterou jste vytvořili, a vyberte ji.
V části Essentials zkopírujte ID aplikace (klienta). Tyto informace budete potřebovat později k vytvoření adresy URL pro cílového tenanta.
V navigačním podokně vyberte Oprávnění rozhraní API a zobrazte oprávnění přiřazená k vaší aplikaci.
Ve výchozím nastavení se k aplikaci, kterou jste vytvořili, přiřazují oprávnění User.Read , ale při migraci poštovních schránek se tato oprávnění nevyžadují. Tato oprávnění můžete odebrat.
Pokud chcete přidat oprávnění k migraci poštovní schránky, vyberte Přidat oprávnění.
V okně Požádat o oprávnění rozhraní API vyberte rozhraní API, která používá moje organizace, vyhledejte Office 365 Exchange Onlinea pak vyberte.
Vyberte Oprávnění aplikace.
V části Vybrat oprávnění rozbalte Poštovní schránka a vyberte Poštovní schránka.Migrace a pak v dolní části obrazovky vyberte Přidat oprávnění .
Teď vyberte Certifikáty & tajné kódy v navigačním podokně pro vaši aplikaci.
V části Tajné kódy klienta vyberte Nový tajný klíč klienta.
V okně Přidat tajný klíč klienta zadejte popis a nakonfigurujte nastavení vypršení platnosti.

Poznámka

Heslo se použije při vytváření koncového bodu migrace. Je velmi důležité, abyste si toto heslo zkopírovali do schránky nebo do bezpečného umístění se zabezpečeným/tajným heslem. Fáze vytvoření tajného kódu je jediná doba, během které můžete toto heslo zobrazit. Pokud ho nějak ztratíte nebo ho potřebujete resetovat, můžete se znovu přihlásit k Azure Portal, přejít na Registrace aplikací, najít aplikaci pro migraci, vybrat Tajné kódy & certifikáty a pak pro aplikaci vytvořit nový tajný kód.

Teď, když jste úspěšně vytvořili aplikaci pro migraci a tajný kód, je dalším krokem vyjádření souhlasu s aplikací.

Na cílové stránce Microsoft Entra ID vyberte v navigačním podokně podnikové aplikace, vyhledejte aplikaci pro migraci, kterou jste vytvořili, vyberte ji a pak vyberte Oprávnění rozhraní API.
Vyberte Udělit souhlas správce pro [vašeho tenanta]. Otevře se nové okno prohlížeče.
Vyberte Přijmout.
Zpět do okna portálu a výběrem aktualizovat potvrďte přijetí.
Vytvořte adresu URL pro odeslání důvěryhodnému partnerovi (správci zdrojového tenanta), aby také mohl přijmout aplikaci a povolit migraci poštovní schránky.

Tady je příklad adresy URL, která se jim má poskytnout:

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

Poznámka

Budete potřebovat ID aplikace pro migraci poštovní schránky, kterou jste právě vytvořili. Contoso.onmicrosoft.com ve výše uvedeném příkladu budete muset nahradit správným názvem onmicrosoft.com vašeho zdrojového tenanta. Budete také muset nahradit [application_id_of_the_app_you_just_created] ID aplikace pro migraci poštovní schránky, kterou jste právě vytvořili.

Příprava cílového tenanta vytvořením koncového bodu migrace Exchange Online a vztahu organizace

Připojte se k Exchange Online PowerShellu v cílovém tenantovi Exchange Online.

Vytvořte nový koncový bod migrace pro přesuny poštovních schránek mezi tenanty.

Poznámka

Budete potřebovat ID aplikace pro migraci poštovní schránky, kterou jste právě vytvořili, a heslo (tajný kód), které jste nakonfigurovali v části Příprava cílového (cílového) tenanta vytvořením aplikace pro migraci a tajného kódu. V závislosti na cloudové instanci Microsoftu 365, kterou používáte, se může váš koncový bod lišit. Podívejte se na stránku koncových bodů Microsoftu 365. vyberte správnou instanci pro vašeho tenanta; pak zkontrolujte Exchange Online Optimalizovat/požadovaná adresa a podle potřeby nahraďte.

$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

Poznámka

Pokud výše uvedený příkaz selže, obraťte se na správce zdrojového tenanta a ověřte, jestli aplikaci byl udělen souhlas správce.

Vytvořte nový objekt vztahu organizace nebo upravte existující objekt vztahu organizace se zdrojovým tenantem.

$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
}

Připravte zdrojového tenanta (aktuální umístění poštovní schránky) tím, že přijmete aplikaci migrace a nakonfigurujete vztah organizace.

V prohlížeči přejděte na odkaz URL od důvěryhodného partnera a vyžádejte souhlas s aplikací pro migraci poštovních schránek. Adresa URL by měla vypadat takto:

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

Poznámka

Budete potřebovat ID aplikace pro migraci poštovní schránky, kterou jste právě vytvořili. V předchozím příkladu budete muset nahradit contoso.onmicrosoft.com adresou URL vašeho zdrojového tenanta onmicrosoft.com . Budete také muset nahradit [application_id_of_the_app_you_just_created] ID aplikace pro migraci poštovní schránky, kterou jste právě vytvořili.
Když se zobrazí automaticky otevírané okno, přijměte aplikaci. Můžete se také přihlásit ke svému Centrum pro správu Microsoft Entra a najít aplikaci v části Podnikové aplikace.
Připojte se k Exchange Online PowerShellu ve zdrojovém tenantovi Exchange Online.

Vytvořte nový objekt vztahu organizace nebo upravte existující objekt vztahu organizace v cílovém (cílovém) tenantovi v Exchange Online PowerShellu:

$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
}

Poznámka

ID tenanta, které zadáte jako $sourceTenantId a $targetTenantId, je IDENTIFIKÁTOR GUID, a ne název domény tenanta. Příklad ID tenanta a informace o vyhledání ID tenanta najdete v tématu Vyhledání ID tenanta Microsoftu 365.

Příprava cílových uživatelských objektů pro migraci

Migrující uživatelé musí být přítomni v cílovém tenantovi a Exchange Online systému (jako MailUser) označeném konkrétními atributy, aby bylo možné přesuny mezi tenanty. Systému se nepodaří přesunout uživatele, kteří nejsou v cílovém tenantovi správně nastaveni. Část Požadavky pro objekty cílového uživatele podrobně popisuje požadavky na objekt MailUser pro cílového tenanta.

Požadavky na objekty cílových uživatelů

Ujistěte se, že jsou v cílové organizaci nastavené následující objekty a atributy:

Tip

Společnost Microsoft vyvíjí funkci, která poskytuje zabezpečenou automatizovanou metodu pro nastavení mnoha atributů (jak je uvedeno níže v této části). Tato funkce s názvem Mapování identit mezi tenanty v současné době hledá zákazníky, kteří jsou ochotni se zapojit do malé privátní verze Preview. Další informace o této předběžné verzi funkce a o tom, jak může zjednodušit procesy migrace mezi tenanty, najdete v tématu Mapování identit mezi tenanty.

Pro každou poštovní schránku, která přechází ze zdrojové organizace, musíte zřídit objekt MailUser v cílové organizaci:

Cílový uživatel pošty musí mít tyto atributy ze zdrojové poštovní schránky nebo musí mít přiřazený nový objekt User:

ExchangeGUID (přímý tok ze zdroje do cíle): Identifikátor GUID poštovní schránky se musí shodovat. Pokud tento atribut není v cílovém objektu, proces přesunu nepokračuje.
ArchiveGUID (přímý tok ze zdroje do cíle): Identifikátor GUID archivu se musí shodovat. Pokud se tento atribut v cílovém objektu nenachází, proces přesunu nepokračuje. (Tento atribut je povinný jenom v případě, že je u zdrojové poštovní schránky povoleno archivace.)
LegacyExchangeDN (flow as proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN musí být v cílovém mailUser přítomen jako x500: proxyAddress. Kromě toho je také nutné zkopírovat všechny adresy x500 ze zdrojové poštovní schránky cílovému uživateli pošty. Pokud se tyto adresy x500 v cílovém objektu nenacházejí, procesy přesunu nepokračují. Tento krok je také důležitý pro povolení schopnosti odpovědět na e-maily, které se odesílají před migrací. Adresa odesílatele/příjemce v každé e-mailové položce a mezipaměť automatického dokončování v aplikaci Microsoft Outlook a v Microsoft Outlook Web App (OWA) používají hodnotu atributu LegacyExchangeDN. Pokud uživatele nejde najít pomocí hodnoty LegacyExchangeDN, doručení e-mailových zpráv může selhat s oznámením o nedoručení 5.1.1.
UserPrincipalName: Hlavní název uživatele (UPN) bude odpovídat nové identitě uživatele nebo cílové společnosti (například user@northwindtraders.onmicrosoft.com).
Primární adresa SMTP: Primární adresa SMTP bude odpovídat nové společnosti uživatele (například user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: MailUser bude odkazovat na aktuální poštovní schránku uživatele hostované ve zdrojovém tenantovi (například user@contoso.onmicrosoft.com). Při přiřazování této hodnoty ověřte, že máte nebo přiřazujete také PrimarySMTPAddress; Jinak tato hodnota nastaví PrimarySMTPAddress, což způsobí selhání přesunu.

Starší adresy proxy smtp není možné přidat ze zdrojové poštovní schránky do cílového uživatele MailUser. Nemůžete například udržovat contoso.com na meu v northwindtraders.onmicrosoft.com objektech tenanta. Domény jsou přidružené pouze k jednomu tenantovi Microsoft Entra ID nebo Exchange Online.

Příklad cílového objektu MailUser:

Atribut	Hodnota
Alias	LaraN
RecipientType	MailUser
RecipientTypeDetails	MailUser
UserPrincipalName	LaraN@northwintraders.onmicrosoft.com
PrimarySmtpAddress	Lara.Newton@northwindtraders.com
ExternalEmailAddress	PROTOKOL SMTP:LaraN@contoso.onmicrosoft.com
ExchangeGUID	1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
LegacyExchangeDN	/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara
EmailAddresses	x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
	protokol smtp:LaraN@northwindtraders.onmicrosoft.com
	PROTOKOL SMTP:Lara.Newton@northwindtraders.com
	X500:/o=ExchangeLabs/ou=Skupina pro správu Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Příklad zdrojového objektu Poštovní schránka:

Atribut	Hodnota
Alias	LaraN
RecipientType	UserMailbox
RecipientTypeDetails	UserMailbox
UserPrincipalName	LaraN@contoso.onmicrosoft.com
PrimarySmtpAddress	Lara.Newton@contoso.com
ExchangeGUID	1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
LegacyExchangeDN	/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
EmailAddresses	protokol smtp:LaraN@contoso.onmicrosoft.com
	PROTOKOL SMTP:Lara.Newton@contoso.com
	X500:/o=ExchangeLabs/ou=Skupina pro správu Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

Do hybridního zpětného zápisu Exchange už můžou být zahrnuty jiné atributy. Pokud ne, měli byste je zahrnout.
1. msExchBlockedSendersHash– Zapisuje zpět online data blokovaných odesílatelů z klientů do místní Active Directory.
2. msExchSafeRecipientsHash– Zapisuje zpět online data bezpečných příjemců z klientů do místní Active Directory.
3. msExchSafeSendersHash– Zapisuje zpět online data bezpečných odesílatelů z klientů do místní Active Directory.
Uživatelé v cílové organizaci musí mít licenci s příslušnými Exchange Online předplatnými platnými pro organizaci. Licenci můžete použít před přesunutím poštovní schránky, ale POUZE pokud je cílový uživatel MailUser správně nastaven s exchangeGUID a proxy adresami. Použití licence před použitím exchangeGUID způsobí, že se v cílové organizaci zřídí nová poštovní schránka. Musíte také použít licenci na migraci uživatelských dat mezi tenanty. Jinak se může zobrazit přechodná chyba při čtení potřeby schválení, která v sestavě přesunu ohlásí upozornění, že se na cílového uživatele nepoužila licence.

Poznámka

Když použijete licenci na objekt Poštovní schránka nebo MailUser, všechny smtp typu proxyAddresses se vyčistí, aby se zajistilo, že pole Exchange EmailAddresses obsahuje jenom ověřené domény.
Musíte zajistit, aby cílový mailUser neměl žádné předchozí identifikátory ExchangeGUID, které neodpovídají zdrojovému identifikátoru ExchangeGUID. K této neshodě může dojít v případě, že cílová uživatele (MEU) byla dříve licencována pro Exchange Online a zřídila poštovní schránku. Pokud byl cílový uživatel mailuser dříve licencovaný pro exchangeguid nebo měl identifikátor ExchangeGUID, který se neshoduje se zdrojovým identifikátorem ExchangeGUID, musíte provést vyčištění cloudového uživatele (MEU). Pro tyto cloudové meu můžete spustit příkaz Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Upozornění

Tento proces je nevratný. Pokud má objekt poštovní schránku softDeleted, nedá se po tomto bodu obnovit. Po vymazání ale můžete synchronizovat správný identifikátor ExchangeGUID s cílovým objektem a mrs připojí zdrojovou poštovní schránku k nově vytvořené cílové poštovní schránce. (Odkaz na blog EHLO o novém parametru.)

Pomocí následujícího příkazu vyhledejte objekty, které byly dříve poštovními schránkami:

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

Tady je příklad:

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

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

Pomocí následujícího příkazu vymažte obnovitelně odstraněnou poštovní schránku:

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Tady je příklad:

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

Návody víte, že to fungovalo?

Konfiguraci migrace poštovních schránek mezi tenanty můžete ověřit spuštěním rutiny Test-MigrationServerAvailability pro koncový bod migrace mezi tenanty, který jste vytvořili ve svém cílovém tenantovi. Z cílového tenanta spusťte následující rutinu:

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

Poznámka

Kromě toho můžete chtít využít ověřovací skript migrace poštovních schránek mezi tenanty, který vám umožní ověřit správné nastavení organizací mezi nimi a objekty, které plánujete migrovat z jednoho tenanta do druhého. Skript vám pomůže identifikovat případné nesrovnalosti, které se můžou vyskytovat u všech objektů najednou, a v důsledku toho zkrátí čas strávený počáteční fází.

Přesunutí poštovních schránek zpět do původního zdroje

Pokud se poštovní schránka vyžaduje k přesunu zpět do původního zdrojového tenanta, musí se v novém zdrojovém i novém cílovém tenantovi spustit stejná sada kroků a skriptů s určitou odchylkou.

Nespouštět ukázkové skripty poskytnuté k vytvoření organizationRelationship.

V existujícím objektu OrganizationRelationship vytvořeném v každém tenantovi aktualizujte následující hodnoty:

Funkce MailboxMovesCapability by měla mít ve zdrojovém i cílovém tenantovi možnost Inbound, RemoteOutbound.
V novém zdrojovém tenantovi aktualizujte hodnotu OAuthApplicationId hodnotou z nově vytvořené aplikace v novém zdrojovém tenantovi.
V novém zdrojovém tenantovi aktualizujte hodnotu MailboxMovePublishedScopes na nově vytvořenou skupinu zabezpečení v novém zdrojovém tenantovi.

Provádění migrací poštovních schránek

Migrace poštovních schránek Exchange mezi tenanty se iniciují z cílového tenanta jako dávky migrace. Tento proces se podobá způsobu, jakým fungují dávky migrace při migraci z místního Exchange na Microsoft 365.

Vytvoření dávek migrace

Tady je příklad příkazu pro zahájení dávkové migrace:

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

Poznámka

E-mailová adresa v souboru CSV musí být adresa zadaná v cílovém tenantovi (například userA@northwindtraders.onmicrosoft.com), ne adresa ve zdrojovém tenantovi. Další informace o rutině získáte kliknutím sem . Pokud chcete získat některé ukázkové informace o souboru CSV, klikněte sem.

Minimální příklad souboru CSV:

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

Odesílání dávek migrace se podporuje také z nového Centra pro správu Exchange při výběru možnosti mezi tenanty.

Aktualizace místních uživatelů pošty

Jakmile se poštovní schránka přesune ze zdroje do cíle, měli byste se ujistit, že místní uživatelé pošty ve zdrojové i cílové poště budou aktualizováni novou cílovouaddress. V příkladech je targetDeliveryDomain použitá při přesunu northwindtraders.onmicrosoft.com. Aktualizujte uživatele pošty pomocí této cílové adresy.

Odebrání koncových bodů a vztahů organizace po migraci

Pomocí rutiny Remove-MigrationEndpoint odeberte existující koncové body migrace pro zdrojové nebo cílové servery po dokončení migrace.

Pomocí rutiny Remove-OrganizationRelationship odeberte existující vztahy organizace pro zdrojové nebo cílové servery po dokončení migrace.

Nejčastější dotazy

Musím po přesunu aktualizovat remotemailboxes ve zdrojovém místním tenantovi?

Organizace zdrojové exchange

Při přesunu poštovní schránky zdrojového tenanta do cílového tenanta byste měli aktualizovat targetAddress (RemoteRoutingAddress/ExternalEmailAddress) každého zdrojového místního uživatele. I když směrování pošty může sledovat referenční seznamy pro více uživatelů pošty s různými cílovými adresami, vyhledávání informací o volném čase pro uživatele pošty musí cílit na umístění uživatele poštovní schránky.

Cílová organizace Exchange

Pokud chcete, aby uživatelé měli vzdálené poštovní schránky v místním prostředí, spusťte po dokončení migrace v hybridní organizaci následující příkaz PowerShellu:

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

Migrují se schůzky Teams mezi tenanty?

Když se schůzky Teams přesunou, adresa URL schůzky se při migraci položek mezi tenanty neaktualizuje. Vzhledem k tomu, že adresa URL v cílovém tenantovi nebude platná, musíte odebrat a znovu vytvořit schůzky Teams.

Jaký obsah se migruje mezi tenanty?

Když se poštovní schránka migruje mezi tenanty pomocí této funkce, migruje se jenom obsah v poštovní schránce viditelný uživatelem, který se označuje také jako hlavní úložiště informací (e-maily, kontakty, kalendář, úkoly a poznámky) a složky Obnovitelné položky– Odstranění, verze a vymazání.

Migrují se položky ve složce Pošta k odeslání mezi tenanty?

Položky ve složce Pošta k odeslání se nemigrují mezi tenanty, protože tato složka je klientská složka specifická pro klienta Outlooku. Položky ve složce Pošta k odeslání se ukládají místně a nesynchronizují se do cloudu.

Migruje se obsah složky chatu Teams mezi tenanty?

Ne, obsah složky chatu Teams se nemigruje mezi tenanty. Jakmile se ale poštovní schránka migruje mezi tenanty, bude obsah složky chatu Teams k dispozici pro správce zdrojového tenanta, aby ho hledal a vyexportoval pomocí vyhledávání obsahu.

Jak můžu zobrazit jenom přesuny, které jsou přesuny mezi tenanty, ne moje přesuny při zprovoznění a zprovoznění?

Použijte parametr Flags :

Get-MoveRequest -Flags "CrossTenant"

Můžete uvést ukázkové skripty pro kopírování atributů použitých při testování?

Poznámka

UKÁZKA – JAK JE, BEZ ZÁRUKY Tento skript předpokládá připojení ke zdrojové poštovní schránce (pro získání zdrojových hodnot) i k cílové místní Active Directory Doménové služby (pro razítko objektu 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

Jak získáme přístup k Outlooku 1. den po přesunutí poštovní schránky uživatele?

Vzhledem k tomu, že doménu může vlastnit pouze jeden tenant, nebude bývalá primární adresa SMTPAddress po dokončení přesunu poštovní schránky přidružena k uživateli v cílovém tenantovi. pouze ty domény přidružené k novému tenantovi. Outlook používá k ověření ve službě nový hlavní název uživatele (UPN) a profil outlooku očekává, že najde starší primární SMTPAddress odpovídající poštovní schránce v cílovém systému. Vzhledem k tomu, že starší verze adresy není v cílovém systému, outlookový profil se nepřipojí, aby našel nově přesunutou poštovní schránku.

Pro toto počáteční nasazení budou uživatelé muset znovu sestavit svůj profil s novým hlavním hlavním název uživatele (UPN), primární adresou SMTP a opětovnou synchronizací obsahu OST.

Poznámka

Naplánujte podle toho, jak budete uživatelům přát dávky k dokončení. Při vytváření profilů klientů outlooku a následných souborech OST a OAB do klientů je potřeba zohlednit využití a kapacitu sítě.

Jaké role Exchange RBAC potřebuji k nastavení nebo dokončení přesunu mezi tenanty?

Existuje matice rolí založených na předpokladu delegovaných povinností při provádění přesunu poštovní schránky. V současné době se vyžadují dvě role:

První role je pro jednorázovou úlohu nastavení, která vytváří autorizaci přesunu obsahu do nebo z hranice vašeho tenanta nebo organizace. Vzhledem k tomu, že přesun dat mimo organizační kontrolu je pro všechny společnosti zásadním problémem, rozhodli jsme se pro roli správce organizace s nejvyšším přiřazením. Tato role musí změnit nebo nastavit novou vlastnost OrganizationRelationship, která definuje -MailboxMoveCapability nastavení pro vzdálenou organizaci. Nastavení může změnit -MailboxMoveCapability jenom správce organizace, zatímco ostatní atributy v OrganizationRelationship může spravovat správce federovaného sdílení.
Roli provádění skutečných příkazů přesunu je možné delegovat na funkci nižší úrovně. Role Přesunout poštovní schránky je přiřazená možnosti přesunu poštovních schránek v organizaci nebo mimo ni.

Jak zacílíme, která adresa SMTP je vybraná pro targetAddress (TargetDeliveryDomain) v převedené poštovní schránce (na převod MailUser)?

Poštovní schránka Exchange se přesune pomocí MRS, která vytvoří targetAddress v původní zdrojové poštovní schránce při převodu na MailUser pomocí shody e-mailové adresy (proxyAddress) u cílového objektu. Proces převezme -TargetDeliveryDomain hodnotu předanou do příkazu a pak zkontroluje odpovídající proxy server pro danou doménu na straně cíle. Když najdeme shodu, použije se odpovídající proxyAddress k nastavení ExternalEmailAddress (targetAddress) u převedené poštovní schránky (nyní MailUser) objektu.

Jak funguje tok pošty po migraci?

Tok pošty mezi tenanty po migraci funguje podobně jako tok hybridní pošty Exchange. Každá migrovaná poštovní schránka potřebuje zdrojového uživatele MailUser se správnou cílovou adresou pro přeposílání příchozí pošty ze zdrojového tenanta do poštovních schránek v cílovém tenantovi. Funkce pravidel přenosu, zabezpečení a dodržování předpisů se poběží podle konfigurace v každém tenantovi, kterým pošta prochází. U příchozí pošty se tedy funkce, jako je antispam, antimalwarový software, karanténa, pravidla přenosu a pravidla deníku, spustí nejprve ve zdrojovém tenantovi a pak v cílovém tenantovi.

Jak se mají oprávnění poštovní schránky přecházet?

Oprávnění k poštovní schránce zahrnují oprávnění Odesílat jménem a Přístup k poštovní schránce:

Funkce Send On Behalf Of (AD:publicDelegates) ukládá dn příjemců s přístupem k poštovní schránce uživatele jako delegát. Tato hodnota je uložená ve službě Active Directory a v současné době se nepřesouvá jako součást přechodu poštovní schránky. Pokud má zdrojová poštovní schránka nastavenou hodnotu publicDelegates, budete muset znovu nastavit hodnotu publicDelegates na cílovou poštovní schránku, jakmile se v cílovém prostředí dokončí převod uživatele uživatele (MEU) na poštovní schránku spuštěním příkazu Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
Oprávnění poštovní schránky uložená v poštovní schránce se přesunou spolu s poštovní schránkou, když se objekt zabezpečení i delegát přesunou do cílového systému. Například uživatel TestUser7 má udělený úplný přístup k poštovní schránce TestUser_8 v SourceCompany.onmicrosoft.com tenanta. Po dokončení přesunu poštovní schránky do TargetCompany.onmicrosoft.com se v cílovém adresáři nastaví stejná oprávnění. Příklady použití _Get-MailboxPermission pro TestUser_7 ve zdrojových i cílových tenantech jsou uvedené níže. Rutiny Exchange mají předponu zdroj a cíl odpovídajícím způsobem.

Tady je příklad výstupu oprávnění poštovní schránky před přesunem ze zdrojové strany:

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

Tady je příklad výstupu oprávnění poštovní schránky po přesunutí z cílové strany:

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

Poznámka

Oprávnění k poštovní schránce a kalendáři mezi tenanty se nepodporují. Objekty zabezpečení a delegáty musíte uspořádat do konsolidovaných dávek přesunu, aby se tyto připojené poštovní schránky ze zdrojového tenanta přechály současně.

Jaký proxy server X500 by se měl přidat na cílové adresy proxy serveru MailUser, aby se povolila migrace?

Migrace poštovní schránky mezi tenanty vyžaduje, aby hodnota LegacyExchangeDN objektu zdrojové poštovní schránky byla v cílovém objektu MailUser označena jako e-mailová adresa x500.

Příklad:

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

Poznámka

Kromě tohoto proxy serveru X500 budete muset zkopírovat všechny proxy X500 z poštovní schránky ve zdroji do poštovní schránky v cíli. I když je to vzácné, můžete v poštovní schránce narazit na adresu proxy serveru X400, i když to není požadavek na dokončení přesunu, doporučujeme, abyste tuto adresu také orazítkoval u cílového objektu uživatele pošty.

Můžou zdroj a cíl tenanti používat stejný název domény?

Ne, názvy zdrojového a cílového tenanta musí být jedinečné, například zdrojová doména contoso.com a cílová doména northwindtraders.com.

Budou sdílené poštovní schránky přesouvat a dál fungovat?

Ano. Zachováme ale jenom oprávnění k úložišti, jak je popsáno v tomto článku:

Správa oprávnění pro příjemce v Exchange Online

Máte nějaká doporučení pro dávky?

Nepřekračujte 2 000 poštovních schránek na dávku. Důrazně doporučujeme odeslat dávky dva týdny před datem cut-over, protože to nemá vliv na koncové uživatele během synchronizace. Pokud potřebujete poradit s poštovními schránkami nad 50 000, můžete se obrátit na CSAM nebo otevřít žádost o podporu.

Co když použiju šifrování služby s klíčem zákazníka Microsoft Purview?

Poštovní schránka se před přesunutím dešifruje. Ujistěte se, že je klíč zákazníka nakonfigurovaný v cílovém tenantovi, pokud je stále potřeba. Další informace najdete tady.

Jaká je odhadovaná doba migrace?

V tabulce, která je tady k dispozici, najdete pokyny k tomu, kdy očekávat hromadné migrace poštovních schránek nebo jednotlivé migrace, které vám pomůžou s plánováním migrace. Tyto odhady vycházejí z analýzy dat předchozích migrací zákazníků. Vzhledem k tomu, že každé prostředí je jedinečné, může se přesná rychlost migrace lišit.

Ochrana dokumentů ve zdrojovém tenantovi, které uživatelé v cílovém tenantovi můžou použít.**

Migrace mezi tenanty migruje jenom data poštovní schránky a nic jiného. Existuje několik dalších možností, které jsou popsané v následujícím blogovém příspěvku, které vám můžou pomoct:

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

Můžu mít v cílovém tenantovi stejné popisky jako ve zdrojovém tenantovi, buď jako jedinou sadu popisků, nebo jako další sadu popisků pro migrované uživatele v závislosti na sladění mezi organizacemi.**

Vzhledem k tomu, že migrace mezi tenanty neexportují popisky a neexistuje způsob, jak je sdílet mezi tenanty, můžete tohoto cíle dosáhnout pouze opětovným vytvořením popisků v cílovém tenantovi.

Podporujete přesun Skupiny Microsoft 365?

Funkce migrace poštovních schránek mezi tenanty v současné době nepodporuje migraci Skupiny Microsoft 365.

Může správce zdrojového tenanta provést vyhledávání eDiscovery u poštovní schránky po migraci poštovní schránky do nového nebo cílového tenanta?

Ne, po migraci poštovní schránky mezi tenanty nefunguje eDiscovery vůči poštovní schránce migrovaného uživatele ve zdroji. Tato chyba eDiscovery je způsobená tím, že ve zdroji už není poštovní schránka, která by se hledala, protože poštovní schránka byla migrována do cílového tenanta a nyní patří do cílového tenanta. eDiscovery po migraci poštovní schránky je možné provést pouze v cílovém tenantovi (kde teď poštovní schránka existuje). Pokud se kopie zdrojové poštovní schránky musí po migraci zachovat ve zdrojovém tenantovi, správce ve zdrojovém tenantovi může obsah zkopírovat do alternativní poštovní schránky před migrací pro budoucí operace eDiscovery s daty.

V jakém okamžiku se cílová poštovní schránka převede na cílovou poštovní schránku a zdrojová poštovní schránka se převede na zdrojovou poštovní schránku MailUser?

K těmto převodům dochází automaticky během procesu migrace. Nejsou nutné žádné ruční kroky.

V jakém kroku přiřadím licenci Exchange Online cílovému uživateli MailUsers?

Toto přiřazení licence lze provést před dokončením migrace, ale neměli byste přiřadit licenci před razítkem atributu ExchangeGUID . jinak převod objektu MailUser na poštovní schránku selže a místo toho se vytvoří nová poštovní schránka. Pokud chcete toto riziko zmírnit, je nejlepší počkat na dokončení migrace a přiřadit licence během 30denního období odkladu.

Můžu použít Microsoft Entra Connect k synchronizaci uživatelů s novým tenantem, pokud zachovám místní Active Directory?

Ano. Je možné, že se do různých tenantů synchronizují dvě instance Microsoft Entra Connect. Je ale potřeba mít na paměti několik věcí:

Předběžné zřízení uživatelských účtů pomocí skriptu uvedeného v tomto článku by se nemělo provádět. Místo toho je možné provést selektivní synchronizaci organizačních jednotky uživatelů v oboru migrace a naplnit tak cílového tenanta. Během konfigurace Microsoft Entra Connect se zobrazí upozornění, že se hlavní název uživatele (UPN) neshoduje.
V závislosti na aktuálním stavu hybridního Serveru Exchange je potřeba ověřit, jestli mají objekty místního adresáře správně vyplněné požadované atributy (například msExchMailboxGUID a proxyAddresses), než se pokusíte synchronizovat s jiným tenantem. jinak narazíte na problémy s dvojitými poštovními schránkami a chybami migrace.
Pokud během přímé migrace nepřesouváte vlastní doménu, musíte provést několik dalších kroků ke správě přechodu hlavního názvu uživatele(UPN) a po dokončení migrace ho změnit místně.

Jak mám zpracovávat poštovní schránky, které jsou blízko kvóty nebo jsou nad kvótou.

Poštovní schránky blížící se kvótě před migrací můžou před samotnou migrací nebo během této migrace převýšit kvótu. Pokud k tomu dojde, migrace těchto poštovních schránek selže a bude potřeba je opravit a restartovat. Pokud chcete tento problém zmírnit, doporučujeme, aby správce zdrojového tenanta před migrací identifikoval poštovní schránky na úrovni kvóty nebo blízko kvóty a podnikl nezbytné kroky ke zmenšení velikosti poštovní schránky, zřízení primárního archivu nebo v některých případech povolení automatického rozšíření archivů pro poštovní schránky uživatele.

Poznámka

Jakmile povolíte archivaci nebo automaticky rozbalíte archiv pro uživatele, ujistěte se, že se pro uživatele použijí správné zásady archivace a spustí se proces přesunutí dat poštovní schránky do nového umístění a uvolnění místa.

Přesunují se automaticky rozbalené archivační poštovní schránky?

Problém: Automaticky rozbalené archivy nejde migrovat. Ano, pokud má uživatel ve zdroji povolené automatické rozbalování archivů a má další pomocné archivy, migrace poštovní schránky mezi tenanty bude fungovat. Podporujeme přesun uživatelů, kteří nemají více než 12 pomocných archivačních poštovních schránek. Kromě toho budou uživatelé s velkým primárním, velkým hlavním archivem a velkými pomocnými archivními poštovními schránkami vyžadovat více času k synchronizaci a měli by být odesláni s velkým předstihem před datem oříznutí. Pokud se zdrojová poštovní schránka během procesu migrace poštovní schránky rozbalí, migrace selže, protože se vytvoří nový pomocný archiv ve zdroji, ale ne v cíli. V takovém případě budete muset odebrat uživatele z dávky a znovu ho odeslat.

Můžu provést migraci mezi cloudovými tenanty na tenanta?

Migrace mezi cloudovými tenanty na tenanta se nepodporuje. Ukázkovým scénářem je přechod z Office 365 Worldwide na Office 365 Government Cloud.

Migrují se hlasové zprávy mezi tenanty?

Ano, hlasové zprávy se migrují mezi tenanty.

Přijaté hlasové zprávy v e-mailu jako přílohy jsou k dispozici v cílové poštovní schránce.
Přijaté hlasové zprávy jsou v Teams k dispozici, pokud voláte hlasovou schránku a posloucháte uložené zprávy. (Virtuální počítače přijaté ve zdroji jsou k dispozici jako uložené zprávy.)
Přijaté hlasové zprávy nejsou po migraci dostupné v klientském uživatelském rozhraní Teams.
Pozdrav hlasové pošty se také migruje do cíle.

Migrují se podpisy poštovní schránky mezi tenanty?

Podpisy poštovní schránky se nemigrují mezi tenanty a je nutné je vytvořit znovu.

Známé problémy

Funkce Teams po migraci ve zdrojovém tenantovi budou omezené. Po migraci poštovní schránky do cílového tenanta už Teams ve zdrojovém tenantovi nemá přístup k poštovní schránce uživatele. Pokud se uživatel přihlásí k Teams pomocí přihlašovacích údajů zdrojového tenanta, dojde ke ztrátě funkčnosti, jako je nemožnost aktualizovat profilový obrázek, žádná aplikace kalendáře a nemožnost vyhledávat a připojovat se k veřejným týmům.
Cloud MailUsers with non-owned SMTP proxyAddress block MRS moves. Při vytváření objektů MailUser cílového tenanta musíte zajistit, aby všechny proxy adresy SMTP patřily cílové organizaci tenanta. Pokud pro cílového uživatele pošty, který nepatří do místního tenanta, existuje adresa proxy serveru SMTP, převod uživatele pošty na poštovní schránku se zabrání. Tato prevence je způsobená naší jistotou, že objekty poštovních schránek můžou posílat poštu jenom z domén, pro které je tenant autoritativní (domény deklarované tenantem).
Pokud synchronizujete uživatele z místního prostředí pomocí nástroje Microsoft Entra Connect v cílovém tenantovi, můžete zřídit místní objekty MailUser s parametrem ExternalEmailAddress odkazujícím na zdrojového tenanta, ve kterém existuje poštovní schránka (LaraN@contoso.onmicrosoft.com), a označíte objekt PrimarySMTPAddress jako doménu, která se nachází v cílovém tenantovi (Lara.Newton@northwindtraders.com). Tyto hodnoty se synchronizují s tenantem a zřídí se příslušný uživatel pošty, který je připravený k migraci. Tady je uveden příklad objektu.
```
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

ExternalEmailAddress               EmailAddresses
--------------------               --------------
SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}
```
Poznámka

Contoso.onmicrosoft.com adresa není v poli EmailAddresses/proxyAddresses.
Objekty MailUser s "externími" primárními adresami SMTP se změní nebo resetují na "interní" domény deklarované společností.

Objekty MailUser jsou ukazatele na jiné než místní poštovní schránky. V případě migrace poštovních schránek mezi tenanty používáme objekty MailUser, které představují buď zdrojovou poštovní schránku (z pohledu cílové organizace), nebo cílovou poštovní schránku (z pohledu zdrojové organizace). MailUsers bude mít externalEmailAddress (targetAddress), která odkazuje na adresu SMTP skutečné poštovní schránky (ProxyTest@northwindtraders.onmicrosoft.com) a primární adresuSMTP, která představuje zobrazenou adresu SMTP uživatele poštovní schránky v adresáři. Některé organizace se rozhodnou zobrazit primární adresu SMTP jako externí adresu SMTP, nikoli jako adresu vlastněnou nebo ověřenou místním tenantem (například jako northwindtraders.com místo contoso.com). Jakmile se však objekt plánu služby Exchange použije na mailUser prostřednictvím licenčních operací, primární adresa SMTP se upraví tak, aby se zobrazovala jako doména ověřená místní organizací (contoso.com). Existují dva možné důvody:
Když se na uživatele MailUser použije jakýkoli plán služby Exchange, začne proces Microsoft Entra ID vynucovat scrubbing proxy, aby se zajistilo, že místní organizace nebude moct odesílat poštu, falšování nebo poštu z jiného tenanta. Všechny adresy SMTP na objektu příjemce s těmito plány služeb budou odebrány, pokud tato adresa není ověřena místní organizací. Stejně jako v tomto příkladu není doména northwindtraders.com ověřena tenantem contoso.onmicrosoft.com; proto scrubbing odebere northwindtraders.com doménu. Pokud chcete tyto externí domény u uživatele MailUser zachovat před nebo po migraci, musíte změnit procesy migrace tak, aby po dokončení přesunu nebo před přesunem odebraly licence, aby se zajistilo, že uživatelé budou mít použitý očekávaný externí branding. Budete muset zajistit, aby byl objekt poštovní schránky správně licencovaný, aby to nemělo vliv na poštovní službu. Tady je příklad skriptu pro odebrání plánů služeb u uživatele MailUser v tenantovi contoso.onmicrosoft.com.

Poznámka

Následující skript používá Microsoft Graph PowerShell. Další informace najdete v tématu Přehled Prostředí Microsoft Graph PowerShell.

Informace o použití různých metod ověřování Connect-Graph v bezobslužném skriptu najdete v článku Rutiny modulu ověřování v Prostředí Microsoft Graph PowerShell.

# 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

Výsledky v sadě přiřazených plánů služby jsou zobrazeny tady:

$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

Adresa PrimarySMTPAddress uživatele už není vyčistá. Doména northwindtraders.com není vlastněná tenantem contoso.onmicrosoft.com a zůstane zachována jako primární adresa SMTP zobrazená v adresáři.

Tady je příklad:

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

Pokud msExchRemoteRecipientType je nastavená hodnota 8 (DeprovisionMailbox) pro místní uživatele MailUsers, kteří se migrují do cílového tenanta, logika scrubbingu proxy proxy serveru v Azure odebere nevlastnící domény a resetuje primárníSMTP na vlastněnou doménu. Když se vymaže hodnota msExchRemoteRecipientType v místním mailUser, logika vymazání proxy serveru se už nepoužívá.

Níže je uvedená úplná sada aktuálních plánů služeb, které zahrnují Exchange Online:

Name (Název)
eDiscovery (Premium) Storage (500 GB)
Customer Lockbox
Ochrana před únikem informací
Exchange Enterprise CAL Services (EOP, DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (Plán 1)
Exchange Online (Plán 2)
Exchange Online – archiv pro Exchange Online
Exchange Online – archiv pro Exchange Server
doplněk Exchange Online neaktivního uživatele
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online Plán 1
Exchange Online POP
Exchange Online Protection
Vyhledávání konektorů grafů pomocí indexu
Informační bariéry
Information Protection pro Office 365 – Premium
Information Protection pro Office 365 – Standard
Insights by MyAnalytics
Zásady správného řízení informací microsoftu
Microsoft Purview Audit (Premium)
Služba Rezervace společnosti Microsoft
Microsoft Business Center
Microsoft Data Investigations
Microsoft MyAnalytics (úplná)
Microsoft Communications Compliance
Microsoft Communications DLP
Klíč zákazníka Microsoftu
Rozšířené auditování Microsoftu 365
Microsoft Records Management
Office 365 eDiscovery (Premium)
Office 365 Advanced eDiscovery
Microsoft Defender pro Office 365 (plán 1)
Microsoft Defender pro Office 365 (Plán 2)
Office 365 Privileged Access Management
Šifrování Premium v Office 365

Selhání migrace

MailboxNotInCrossTenantMigrationScopeException

Ujistěte se, že je ve zdrojovém tenantovi správně nastavený rozsah migrace a že je mailboxMovesPublishedScopes nastavený ve vztahu organizace s cílovým tenantem.
Ověřte, že poštovní schránka, která se má migrovat, byla přidána do skupiny zabezpečení ve zdrojovém tenantovi.
Po přidání uživatele do správné skupiny zabezpečení pokračujte v dávce migrace.
AuxArchiveNotFoundInTargetRecipientException

Toto selhání je způsobeno tím, že uživatel nebyl v oboru migrace, když byla spuštěna dávka, a uživatel má ve zdroji AuxArchive.
Přidejte uživatele do správné skupiny zabezpečení ve zdrojovém cíli.
Odeberte uživatele migrace z dávky.
Pomocí následujícího příkazu odeberte uživatele:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Přidání uživatele do nové dávky
Výjimka MailboxIsNotInExpectedDBException

Příčinou tohoto selhání je interní údržba Microsoftu.
Odeberte uživatele migrace z dávky.
Pomocí následujícího příkazu odeberte uživatele:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Přidání uživatele do nové dávky
NotAcceptedDomainException

Cílovému uživateli je označená neplatná adresa proxy serveru. Příkladem může být případ, kdy uživatel v contoso.onmicrosoft.com měl adresu proxy serveru fabrikam.onmicrosoft.com, což je zdrojový tenant.
Pomocí následujícího příkazu odeberte neplatnou adresu proxy serveru:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
```
Pokračujte v dávce migrace.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

Během migrace se zřídil nový AuxArchive.
Odeberte uživatele migrace z dávky.
Pomocí následujícího příkazu odeberte uživatele:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser 
```
Přidání uživatele do nové dávky
Výjimka UserDuplicateInOtherBatchException

Uživatel již existuje v jiné dávce.
Odeberte uživatele migrace z dávky.
Pomocí následujícího příkazu odeberte uživatele:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
```
Přidání uživatele do nové dávky
MissingExchangeGuidException

Cílovému objektu mailuser chybí správná hodnota ExchangeGuid.
Aktualizujte ExchangeGuid následujícím příkazem:
```
Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8  
```
Pokračovat v dávce migrace
SourceMailboxAlreadyBeingMovedPermanentException

Zdrojová poštovní schránka už má existující žádost o přesunutí. Prošetřete a odeberte existující přesun. Je možné, že se jedná o interní přesun Microsoftu a budete muset počkat, až se přesun dokončí.
Odeberte uživatele migrace z dávky.
Pomocí následujícího příkazu odeberte uživatele:
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
Po odebrání nebo dokončení původního přesunu přidejte uživatele do nové dávky.
UserAlreadyHasDemotedArchiveException

Uživatel měl dříve zakázanou archivační poštovní schránku. Pokud chcete tento problém vyřešit, zvolte jednu z následujících dvou možností.
Trvale odstraňte zakázanou archivační poštovní schránku, je to nedoručitelné. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Pomocí následujícího příkazu znovu povolte zakázanou archivační poštovní schránku:
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
Pokud zakázanou archivační poštovní schránku znovu povolíte, budete muset aktualizovat identifikátor GUID archivu u cílového objektu mailuser.
Pokračovat v dávce migrace

Viz také

Správa Microsoft 365 pomocí PowerShellu
Začínáme se sadou Microsoft Graph PowerShell SDK
[https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]

Sdílet prostřednictvím

Migrace poštovní schránky mezi tenanty

Licencování

Příprava zdrojových a cílových tenantů

Požadavky na zdrojové a cílové tenanty

Postup konfigurace pro povolení migrace poštovních schránek mezi tenanty

Příprava cílového (cílového) tenanta vytvořením aplikace pro migraci a tajného kódu

Udělení souhlasu s aplikací

Příprava cílového tenanta vytvořením koncového bodu migrace Exchange Online a vztahu organizace

Připravte zdrojového tenanta (aktuální umístění poštovní schránky) tím, že přijmete aplikaci migrace a nakonfigurujete vztah organizace.

Příprava cílových uživatelských objektů pro migraci

Požadavky na objekty cílových uživatelů

Návody víte, že to fungovalo?

Přesunutí poštovních schránek zpět do původního zdroje

Provádění migrací poštovních schránek

Vytvoření dávek migrace

Aktualizace místních uživatelů pošty

Odebrání koncových bodů a vztahů organizace po migraci

Nejčastější dotazy

Musím po přesunu aktualizovat remotemailboxes ve zdrojovém místním tenantovi?

Organizace zdrojové exchange

Cílová organizace Exchange

Migrují se schůzky Teams mezi tenanty?

Jaký obsah se migruje mezi tenanty?

Migrují se položky ve složce Pošta k odeslání mezi tenanty?

Migruje se obsah složky chatu Teams mezi tenanty?

Jak můžu zobrazit jenom přesuny, které jsou přesuny mezi tenanty, ne moje přesuny při zprovoznění a zprovoznění?

Můžete uvést ukázkové skripty pro kopírování atributů použitých při testování?

Jak získáme přístup k Outlooku 1. den po přesunutí poštovní schránky uživatele?

Jaké role Exchange RBAC potřebuji k nastavení nebo dokončení přesunu mezi tenanty?

Jak zacílíme, která adresa SMTP je vybraná pro targetAddress (TargetDeliveryDomain) v převedené poštovní schránce (na převod MailUser)?

Jak funguje tok pošty po migraci?

Jak se mají oprávnění poštovní schránky přecházet?

Jaký proxy server X500 by se měl přidat na cílové adresy proxy serveru MailUser, aby se povolila migrace?

Můžou zdroj a cíl tenanti používat stejný název domény?

Budou sdílené poštovní schránky přesouvat a dál fungovat?

Máte nějaká doporučení pro dávky?

Co když použiju šifrování služby s klíčem zákazníka Microsoft Purview?

Jaká je odhadovaná doba migrace?

Ochrana dokumentů ve zdrojovém tenantovi, které uživatelé v cílovém tenantovi můžou použít.**

Můžu mít v cílovém tenantovi stejné popisky jako ve zdrojovém tenantovi, buď jako jedinou sadu popisků, nebo jako další sadu popisků pro migrované uživatele v závislosti na sladění mezi organizacemi.**

Podporujete přesun Skupiny Microsoft 365?

Může správce zdrojového tenanta provést vyhledávání eDiscovery u poštovní schránky po migraci poštovní schránky do nového nebo cílového tenanta?

V jakém okamžiku se cílová poštovní schránka převede na cílovou poštovní schránku a zdrojová poštovní schránka se převede na zdrojovou poštovní schránku MailUser?

V jakém kroku přiřadím licenci Exchange Online cílovému uživateli MailUsers?

Můžu použít Microsoft Entra Connect k synchronizaci uživatelů s novým tenantem, pokud zachovám místní Active Directory?

Jak mám zpracovávat poštovní schránky, které jsou blízko kvóty nebo jsou nad kvótou.

Přesunují se automaticky rozbalené archivační poštovní schránky?

Můžu provést migraci mezi cloudovými tenanty na tenanta?

Migrují se hlasové zprávy mezi tenanty?

Migrují se podpisy poštovní schránky mezi tenanty?

Známé problémy

Selhání migrace

Viz také

Váš názor

Další materiály