Migratie van postvakken tussen tenants
Tijdens fusies of afstotingen moet u mogelijk de mogelijkheid hebben om de Exchange Online postvakken van uw gebruikers te verplaatsen naar een nieuwe tenant. Migratie van meerdere tenantpostvakken stelt tenantbeheerders in staat om bekende interfaces zoals Exchange Online PowerShell en MRS te gebruiken om gebruikers over te zetten naar hun nieuwe organisatie.
Beheerders kunnen de cmdlet New-MigrationBatch , die beschikbaar is via de beheerrol Postvakken verplaatsen , gebruiken om verplaatsingen tussen tenants uit te voeren.
Gebruikers die migreren, moeten aanwezig zijn in de doeltenant Exchange Online systeem als e-mailgebruiker, gemarkeerd met specifieke kenmerken om verplaatsingen tussen tenants mogelijk te maken. Het systeem kan gebruikers die niet goed zijn ingesteld niet verplaatsen in de doeltenant.
Nadat de verplaatsingen zijn voltooid, wordt het postvak van de brongebruiker geconverteerd naar een MailUser
en wordt de targetAddress
(weergegeven als ExternalEmailAddress in Exchange) voorzien van het routeringsadres naar de doeltenant. Dit proces laat de verouderde MailUser
in de brontenant achter en maakt co-existentie en e-mailroutering mogelijk. Wanneer bedrijfsprocessen dit toestaan, kan de brontenant de bron-MailUser verwijderen of converteren naar een e-mailcontactpersoon.
Exchange-postvakmigraties tussen tenants worden alleen ondersteund voor tenants in hybride of cloud, of een combinatie van beide.
In dit artikel wordt het proces beschreven voor het verplaatsen van postvak tussen tenants en bevat richtlijnen voor het voorbereiden van bron- en doeltenants voor het verplaatsen van de inhoud van het Exchange Online postvak.
Belangrijk
Postvakken die zich in elk type bewaring bevinden, worden niet gemigreerd en de verplaatsing voor die postvakken wordt geblokkeerd.
Wanneer een postvak wordt gemigreerd tussen tenants met deze functie, wordt alleen gebruikers zichtbare inhoud in het postvak (e-mail, contactpersonen, agenda, taken en notities) gemigreerd naar het doel (doeltenant). Na een geslaagde migratie wordt het bronpostvak verwijderd. Deze verwijdering betekent dat het bronpostvak na de migratie in geen geval beschikbaar, detecteerbaar of toegankelijk is in de brontenant.
Licenties
Belangrijk
Migraties tussen tenants vereisen een licentie per gebruiker (eenmalige kosten) en kunnen worden toegewezen aan het bron- of doelgebruikersobject. Deze licentie heeft ook betrekking op OneDrive voor Bedrijven migratie. Migratie van gebruikersgegevens tussen tenants is beschikbaar als invoegtoepassing voor de volgende Microsoft 365-abonnementen: Microsoft 365 Business Basic, Standard en Premium; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; OneDrive voor Bedrijven en EDU.
Waarschuwing
U moet voorafgaand aan de volgende stappen licenties voor migratie van gebruikersgegevens voor meerdere tenants hebben aangeschaft of gecontroleerd. Migraties mislukken als deze stap niet is voltooid. Microsoft biedt geen uitzonderingen voor deze licentievereiste.
Als u niet de juiste licentie hebt toegewezen aan de gebruiker die wordt gemigreerd, mislukt de migratie en ontvangt u een foutbericht dat vergelijkbaar is met het volgende:
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.
Bron- en doeltenants voorbereiden
Vereisten voor bron- en doeltenants
Voordat u begint, moet u ervoor zorgen dat u over de benodigde machtigingen beschikt om de toepassing Postvak verplaatsen in Azure, EXO Migration Endpoint en de EXO-organisatierelatie te configureren.
Daarnaast is ten minste één beveiligingsgroep met e-mail in de brontenant vereist. Deze groepen worden gebruikt om de lijst met postvakken te bepalen die kunnen worden verplaatst van de brontenant (of soms aangeduid als resource) naar de doeltenant. Met dit bereik kan de beheerder van de brontenant de specifieke set postvakken beperken of beperken die moeten worden verplaatst, zodat onbedoelde gebruikers niet kunnen worden gemigreerd.
Als u meer dan 10.000 gebruikers migreert, raden we u aan om meerdere groepen te maken die de gebruikerslijst bevatten voor de beste prestaties. Hoewel geneste groepen worden ondersteund, worden ze niet aanbevolen.
U moet ook communiceren met uw vertrouwde partnerbedrijf (met wie u postvakken gaat verplaatsen) om hun Microsoft 365-tenant-id te verkrijgen. Deze tenant-id wordt gebruikt in het veld Domeinnaam organisatierelatie .
Als u de tenant-id van een abonnement wilt ophalen, meldt u zich aan bij de Microsoft 365-beheercentrum en gaat u naar https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView. Selecteer het kopieerpictogram voor de eigenschap Tenant-id om deze naar het klembord te kopiëren.
Alle gebruikers in zowel de bron- als doelorganisatie moeten een licentie hebben met de juiste Exchange Online-abonnementen. Zorg er ook voor dat u licenties voor migratie van gebruikersgegevens tussen tenants toepast op alle gebruikers die naar de doelzijde worden gemigreerd.
Configuratiestappen voor het inschakelen van uw tenants voor postvakmigraties tussen tenants
Opmerking
U moet eerst het doel (doel) configureren. Als u deze stappen wilt uitvoeren, hoeft u de referenties van de tenantbeheerder voor zowel de bron- als de doeltenant niet te hebben of te kennen. Stappen kunnen voor elke tenant afzonderlijk worden uitgevoerd door verschillende beheerders.
De doeltenant (doel) voorbereiden door de migratietoepassing en het geheim te maken
Meld u aan bij uw Microsoft Entra-beheercentrum (https://portal.azure.com) met de referenties van uw doeltenantbeheerder.
Selecteer onder Microsoft Entra ID beherende optie Weergave.
Selecteer App-registraties in het navigatiedeelvenster.
Selecteer Nieuwe registratie.
Selecteer op de pagina Een toepassing registreren onder Ondersteunde accounttypen de optie Accounts in elke organisatiemap (Elke Microsoft Entra-map - Meerdere tenants). Selecteer vervolgens onder Omleidings-URI (optioneel)de optie Web en typ
https://office.com
. Selecteer vervolgens Registreren.Zie in de rechterbovenhoek van de pagina het meldingsdialoogvenster waarin wordt aangegeven dat de app is gemaakt.
Terug naar de startpagina, ga naar Microsoft Entra ID en selecteer App-registraties.
Zoek onder Toepassingen in eigendom de app die u hebt gemaakt en selecteer deze.
Kopieer onder Essentials de toepassings-id (client). U hebt deze informatie later nodig om een URL voor de doeltenant te maken.
Selecteer API-machtigingen in het navigatiedeelvenster om machtigingen weer te geven die zijn toegewezen aan uw app.
Standaard worden user.read-machtigingen toegewezen aan de app die u hebt gemaakt, maar deze machtigingen zijn niet vereist voor postvakmigraties. U kunt deze machtigingen verwijderen.
Als u machtigingen wilt toevoegen voor postvakmigratie, selecteert u Een machtiging toevoegen.
Selecteer in het venster API-machtigingen aanvragenDE API's die mijn organisatie gebruikt, zoek
Office 365 Exchange Online
naar en selecteer deze vervolgens.Selecteer Toepassingsmachtigingen.
Vouw onder Machtigingen selecterenpostvak uit en selecteer Mailbox.Migration en selecteer vervolgens Machtigingen toevoegen onderaan het scherm.
Selecteer nu Certificaten & geheimen in het navigatiedeelvenster voor uw toepassing.
Selecteer onder Clientgeheimende optie Nieuw clientgeheim.
Typ in het venster Een clientgeheim toevoegen een beschrijving en configureer vervolgens uw verloopinstellingen.
Opmerking
Het wachtwoord wordt gebruikt bij het maken van uw migratie-eindpunt. Het is uiterst belangrijk dat u dit wachtwoord kopieert naar het klembord en/of naar een veilige/geheime locatie met een wachtwoord. De fase voor het maken van een geheim is de enige tijd waarin u dit wachtwoord kunt zien. Als u deze op een of andere manier kwijtraakt of opnieuw wilt instellen, kunt u zich opnieuw aanmelden bij de Azure Portal, naar App-registraties gaan, uw migratie-app zoeken, Geheimen & certificaten selecteren en vervolgens een nieuw geheim voor uw app maken.
Nu u de migratietoepassing en het geheim hebt gemaakt, is de volgende stap toestemming geven voor de toepassing.
Toestemming verlenen aan de toepassing
Selecteer bedrijfstoepassingen in het navigatiedeelvenster op de landingspagina van Microsoft Entra ID. Zoek vervolgens de migratie-app die u hebt gemaakt, selecteer deze en selecteer vervolgens API-machtigingen.
Selecteer Beheerderstoestemming verlenen voor [uw tenant]. Er wordt een nieuw browservenster geopend.
Selecteer Accepteren.
Terug naar het portalvenster en selecteer Vernieuwen om uw acceptatie te bevestigen.
Formuleer de URL die moet worden verzonden naar uw vertrouwde partner (brontenantbeheerder), zodat deze ook de toepassing kan accepteren om postvakmigratie in te schakelen.
Hier volgt een voorbeeld van de URL die aan hen moet worden verstrekt:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com
Opmerking
U hebt de toepassings-id nodig van de postvakmigratie-app die u zojuist hebt gemaakt. U moet contoso.onmicrosoft.com in het bovenstaande voorbeeld vervangen door de juiste onmicrosoft.com naam van uw brontenant. U moet ook [application_id_of_the_app_you_just_created] vervangen door de toepassings-id van de postvakmigratie-app die u zojuist hebt gemaakt.
De doeltenant voorbereiden door het Exchange Online migratie-eindpunt en de organisatierelatie te maken
Maak verbinding met Exchange Online PowerShell in de doel-Exchange Online-tenant.
Maak een nieuw migratie-eindpunt voor verplaatsingen van postvak tussen tenants.
Opmerking
U hebt de toepassings-id nodig van de postvakmigratie-app die u zojuist hebt gemaakt en het wachtwoord (geheim) dat u hebt geconfigureerd in De doeltenant (doeltenant voorbereiden) door de migratietoepassing en het migratiegeheim te maken. Afhankelijk van het Microsoft 365-cloudexemplaren dat u gebruikt, kan uw eindpunt afwijken. Zie de pagina Microsoft 365-eindpunten; selecteer het juiste exemplaar voor uw tenant; controleert u vervolgens het Exchange Online Adres Optimaliseren/Vereist en vervangt u indien nodig.
Uw vertrouwde partner (brontenantbeheerder) moet de toepassing accepteren met behulp van de URL die in de vorige sectie wordt vermeld voordat u verdergaat met de volgende stappen. Anders mislukt de laatste opdracht in de onderstaande opdrachten met een verificatiefout en kunt u het maken van het migratie-eindpunt niet voltooien.
$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
Opmerking
Als de bovenstaande opdracht mislukt, neemt u contact op met de brontenantbeheerder om te controleren of aan de toepassing beheerderstoestemming is verleend.
Maak een nieuw organisatierelatieobject of bewerk uw bestaande organisatierelatieobject met uw brontenant.
$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 }
Bereid de brontenant (huidige postvaklocatie) voor door de migratietoepassing te accepteren en de organisatierelatie te configureren
Ga in uw browser naar de URL-koppeling van uw vertrouwde partner om toestemming te geven voor de postvakmigratietoepassing. De URL moet er als volgt uitzien:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com
Opmerking
U hebt de toepassings-id nodig van de postvakmigratie-app die u zojuist hebt gemaakt. U moet in het vorige voorbeeld vervangen door
contoso.onmicrosoft.com
de URL vanonmicrosoft.com
uw brontenant. U moet ook [application_id_of_the_app_you_just_created] vervangen door de toepassings-id van de postvakmigratie-app die u zojuist hebt gemaakt.Accepteer de toepassing wanneer het pop-upvenster wordt weergegeven. U kunt zich ook aanmelden bij uw Microsoft Entra-beheercentrum en de toepassing vinden onder Bedrijfstoepassingen.
Maak verbinding met Exchange Online PowerShell op de bron-Exchange Online-tenant.
Maak een nieuw organisatierelatieobject of bewerk uw bestaande organisatierelatieobject met uw doeltenant (doel) in Exchange Online PowerShell:
$targetTenantId = "[tenant ID of your trusted partner, where the mailboxes are being moved to]" $appId = "[application ID of the mailbox migration app you consented to]" $scope = "[name of the mail enabled security group that contains the list of users who are allowed to migrate]" $orgrelname = "[name of your new organization relationship]" # Enable customization if tenant is dehydrated $dehydrated = Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host "Group already exists." } $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope } If ($null -eq $existingOrgRel) { New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope }
Opmerking
De tenant-id die u invoert als de $sourceTenantId en $targetTenantId is de GUID en niet de tenantdomeinnaam. Zie Uw Microsoft 365-tenant-id zoeken voor een voorbeeld van een tenant-id en informatie over het vinden van uw tenant-id.
Doelgebruikersobjecten voorbereiden voor migratie
Gebruikers die migreren, moeten aanwezig zijn in de doeltenant en Exchange Online systeem (als e-mailgebruiker) die zijn gemarkeerd met specifieke kenmerken om verplaatsingen tussen tenants in te schakelen. Het systeem kan gebruikers die niet goed zijn ingesteld niet verplaatsen in de doeltenant. In de sectie Vereisten voor doelgebruikersobjecten worden de vereisten voor het MailUser-object voor de doeltenant beschreven.
Vereisten voor doelgebruikersobjecten
Zorg ervoor dat de volgende objecten en kenmerken zijn ingesteld in de doelorganisatie:
Tip
Microsoft ontwikkelt een functie om een veilige geautomatiseerde methode te bieden voor het instellen van veel van de kenmerken (hieronder vermeld in deze sectie). Deze functie, genaamd Cross-Tenant Identity Mapping, is momenteel op zoek naar klanten die willen deelnemen aan een kleine persoonlijke preview. Zie Cross-Tenant Identity Mapping (Identiteitstoewijzing tussen tenants) voor meer informatie over deze prereleasefunctie en hoe deze uw migratieprocessen voor meerdere tenants kan vereenvoudigen.
Voor elk postvak dat vanuit een bronorganisatie wordt verplaatst, moet u een MailUser-object inrichten in de doelorganisatie:
De doel-mailgebruiker moet deze kenmerken hebben uit het bronpostvak of toegewezen met het nieuwe gebruikersobject:
ExchangeGUID (directe stroom van bron naar doel): de postvak-GUID moet overeenkomen. Het verplaatsingsproces wordt niet voortgezet als dit kenmerk niet aanwezig is op het doelobject.
ArchiveGUID (directe stroom van bron naar doel): de archief-GUID moet overeenkomen. Het verplaatsingsproces wordt niet voortgezet als dit kenmerk niet aanwezig is in het doelobject. (Dit kenmerk is alleen vereist als het bronpostvak is Archief ingeschakeld).
LegacyExchangeDN (stroom als proxyAddress, "x500:<LegacyExchangeDN>"): De LegacyExchangeDN moet op de doel-MailUser aanwezig zijn als x500: proxyAddress. Daarnaast moet u ook alle x500-adressen van het bronpostvak naar de doelgebruiker voor e-mail kopiëren. De verplaatsingsprocessen worden niet voortgezet als deze x500-adressen niet aanwezig zijn in het doelobject. Deze stap is ook belangrijk voor het inschakelen van antwoordmogelijkheid voor e-mailberichten die vóór de migratie worden verzonden. Het adres van de afzender/geadresseerde in elk e-mailbericht en de cache voor automatisch aanvullen in Microsoft Outlook en in Microsoft Outlook Web App (OWA) gebruiken de waarde van het kenmerk LegacyExchangeDN. Als een gebruiker niet kan worden gevonden met behulp van de waarde LegacyExchangeDN, kan de bezorging van e-mailberichten mislukken met een 5.1.1 NDR.
UserPrincipalName: UPN wordt uitgelijnd met de NIEUWE identiteit of het doelbedrijf van de gebruiker (bijvoorbeeld user@northwindtraders.onmicrosoft.com).
Primair SMTP-adres: het primaire SMTP-adres wordt uitgelijnd met het NIEUWE bedrijf van de gebruiker (bijvoorbeeld user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: MailUser verwijst naar het huidige postvak van de gebruiker dat wordt gehost in de brontenant (bijvoorbeeld user@contoso.onmicrosoft.com). Wanneer deze waarde wordt toegewezen, controleert u of u ook PrimarySMTPAddress hebt/toewijst; anders wordt met deze waarde het PrimarySMTPAddress ingesteld, waardoor verplaatsingsfouten worden veroorzaakt.
U kunt geen verouderde SMTP-proxyadressen uit het bronpostvak toevoegen aan de doel-MailUser. U kunt bijvoorbeeld geen contoso.com onderhouden op de meu in northwindtraders.onmicrosoft.com tenantobjecten. Domeinen zijn alleen gekoppeld aan één Microsoft Entra ID of Exchange Online tenant.
Voorbeeld van het MailUser-doelobject :
Attribuut Waarde Alias LaraN RecipientType MailUser RecipientTypeDetails MailUser UserPrincipalName LaraN@northwintraders.onmicrosoft.com PrimarySmtpAddress Lara.Newton@northwindtraders.com ExternalEmailAddress SMTP:LaraN@contoso.onmicrosoft.com ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8 LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara Smtp:LaraN@northwindtraders.onmicrosoft.com SMTP:Lara.Newton@northwindtraders.com X500:/o=ExchangeLabs/ou=Exchange-beheergroep (FYDIBOHF23SPDLT)/cn=Ontvangers/cn=f161af74128f460fba5c0c23984b3d6c-Lara Voorbeeld van bronpostvakobject :
Attribuut Waarde Alias LaraN RecipientType UserMailbox RecipientTypeDetails UserMailbox UserPrincipalName LaraN@contoso.onmicrosoft.com PrimarySmtpAddress Lara.Newton@contoso.com ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8 LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara EmailAddresses Smtp:LaraN@contoso.onmicrosoft.com SMTP:Lara.Newton@contoso.com X500:/o=ExchangeLabs/ou=Exchange-beheergroep (FYDIBOHF23SPDLT)/cn=Ontvangers/cn=f161af74128f460fba5c0c23984b3d6c-Lara
Andere kenmerken zijn mogelijk al opgenomen in hybride write-back van Exchange. Als dat niet het geval is, moeten ze worden opgenomen.
-
msExchBlockedSendersHash
– Schrijft online geblokkeerde afzendergegevens terug van clients naar on-premises Active Directory. -
msExchSafeRecipientsHash
– Schrijft online veilige geadresseerdengegevens terug van clients naar on-premises Active Directory. -
msExchSafeSendersHash
– Schrijft online veilige afzendergegevens terug van clients naar on-premises Active Directory.
Gebruikers in de doelorganisatie moeten een licentie hebben met de juiste Exchange Online abonnementen die van toepassing zijn op de organisatie. U kunt een licentie toepassen voordat een postvak wordt verplaatst, maar ALLEEN wanneer de doel-MailUser correct is ingesteld met ExchangeGUID- en proxyadressen. Als u een licentie toepast voordat de ExchangeGUID wordt toegepast, resulteert dit in een nieuw postvak dat is ingericht in de doelorganisatie. U moet ook een licentie voor migratie van gebruikersgegevens voor meerdere tenants toepassen; anders ziet u mogelijk een tijdelijke fout bij het lezen waarvoor goedkeuring is vereist, waardoor een waarschuwing in het verplaatsingsrapport wordt weergegeven dat er geen licentie is toegepast op de doelgebruiker.
Opmerking
Wanneer u een licentie toepast op een Postvak- of MailUser-object, worden alle PROXYAddresses van het SMTP-type verwijderd om ervoor te zorgen dat alleen geverifieerde domeinen worden opgenomen in de Exchange EmailAddresses-matrix.
-
U moet ervoor zorgen dat de doel-MailUser geen eerdere ExchangeGUID heeft die niet overeenkomt met de ExchangeGUID-bron. Deze fout kan optreden als de doel-MEU eerder een licentie voor Exchange Online had en een postvak heeft ingericht. Als de doel-MailUser eerder een licentie had voor of een ExchangeGUID had die niet overeenkomt met de ExchangeGUID-bron, moet u een opschoning van de cloud-MEU uitvoeren. Voor deze cloud-E-gebruikers kunt u uitvoeren
Set-User <identity> -PermanentlyClearPreviousMailboxInfo
.
Voorzichtigheid
Dit proces is onomkeerbaar. Als het object een postvak met softDeleted heeft, kan het na dit punt niet meer worden hersteld. Zodra deze optie is gewist, kunt u echter de juiste ExchangeGUID synchroniseren met het doelobject, waarna MRS het bronpostvak verbindt met het zojuist gemaakte doelpostvak. (Referentie EHLO-blog over de nieuwe parameter.)
Zoek objecten die eerder postvakken waren met behulp van de volgende opdracht:
Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize
Hier volgt een voorbeeld:
Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize
Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails
---- ---------------------------- ------------- --------------------
John UserMailbox MailUser MailUser
Wis het voorlopig verwijderde postvak met de volgende opdracht:
Set-User <identity> -PermanentlyClearPreviousMailboxInfo
Hier volgt een voorbeeld:
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
Hoe kan ik weet dat dit werkt?
U kunt de configuratie van de migratie van postvak tussen tenants controleren door de cmdlet Test-MigrationServerAvailability uit te voeren op het migratie-eindpunt voor meerdere tenants dat u op uw doeltenant hebt gemaakt. Voer de volgende cmdlet uit vanuit de doeltenant:
Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"
Opmerking
Daarnaast kunt u gebruikmaken van het validatiescript voor postvakmigratie tussen meerdere tenants, waarmee u kunt controleren of de organisaties correct zijn ingesteld tussen hen en de objecten die u van de ene tenant naar de andere wilt migreren. Het script helpt bij het identificeren van eventuele discrepanties die aanwezig kunnen zijn op alle objecten tegelijk, waardoor de tijd die aan de eerste fase wordt besteed, wordt verkort.
Postvakken terug verplaatsen naar de oorspronkelijke bron
Als een postvak moet worden teruggezet naar de oorspronkelijke brontenant, moet dezelfde set stappen en scripts worden uitgevoerd in zowel nieuwe bron- als nieuwe doeltenants, met enige afwijking.
Voer de opgegeven voorbeeldscripts niet uit om de OrganizationRelationship te maken.
Werk de volgende waarden bij in de bestaande OrganizationRelationship die in elke tenant is gemaakt:
- MailboxMovesCapability moet Inbound, RemoteOutbound hebben als de mogelijkheden in zowel bron- als doeltenants.
- Werk in de nieuwe brontenant de waarde OAuthApplicationId bij met de waarde van de zojuist gemaakte toepassing in de nieuwe brontenant.
- Werk in de nieuwe brontenant de waarde MailboxMovePublishedScopes bij met de zojuist gemaakte beveiligingsgroep in de nieuwe brontenant.
Postvakmigraties uitvoeren
Migraties van Exchange-postvak tussen tenants worden vanuit de doeltenant geïnitieerd als migratiebatches. Dit proces is vergelijkbaar met de manier waarop migratiebatches bij het instappen werken bij het migreren van Exchange on-premises naar Microsoft 365.
Migratiebatches maken
Hier volgt een voorbeeldopdracht voor het initiëren van een batchmigratie:
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
Opmerking
Het e-mailadres in het CSV-bestand moet het adres zijn dat is opgegeven in de doeltenant (bijvoorbeeld userA@northwindtraders.onmicrosoft.com), niet het adres in de brontenant. Klik hier voor meer informatie over de cmdlet Klik hierVoor een voorbeeld van CSV-bestandsgegevens klikt u hier
Een minimaal voorbeeld van een CSV-bestand is:
EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com
Migratiebatchverzending wordt ook ondersteund vanuit het nieuwe Exchange-beheercentrum wanneer u de optie voor meerdere tenants selecteert.
On-premises e-mailgebruikers bijwerken
Zodra het postvak van bron naar doel is verplaatst, moet u ervoor zorgen dat de on-premises e-mailgebruikers, in zowel de bron als het doel, worden bijgewerkt met het nieuwe targetAddress. In de voorbeelden is de targetDeliveryDomain die tijdens de verplaatsing wordt gebruikt , northwindtraders.onmicrosoft.com. Werk de e-mailgebruikers bij met dit targetAddress.
Eindpunten en organisatierelaties verwijderen na migratie
Gebruik de cmdlet Remove-MigrationEndpoint om bestaande migratie-eindpunten voor bron- of doelservers te verwijderen nadat de migratie is voltooid.
Gebruik de cmdlet Remove-OrganizationRelationship om bestaande organisatierelaties voor bron- of doelservers te verwijderen nadat de migratie is voltooid.
Veelgestelde vragen
Moet ik RemoteMailboxes bijwerken in de on-premises brontenant na de verplaatsing?
Exchange-bronorganisatie
U moet het targetAddress (RemoteRoutingAddress/ExternalEmailAddress) van elke on-premises brongebruiker bijwerken wanneer het postvak van de brontenant naar de doeltenant wordt verplaatst. Hoewel e-mailroutering de verwijzingen voor meerdere e-mailgebruikers met verschillende targetAddresses kan volgen, moeten zoekacties voor beschikbaarheid/bezet voor e-mailgebruikers zich richten op de locatie van de postvakgebruiker.
Exchange-doelorganisatie
Nadat de migratie is voltooid in een hybride organisatie, voert u de volgende PowerShell-opdracht uit als u wilt dat uw gebruikers externe postvakken on-premises hebben:
Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox
Worden Teams-vergaderingen gemigreerd tussen tenants?
Terwijl Teams-vergaderingen worden verplaatst, wordt de URL van de vergadering niet bijgewerkt wanneer items worden gemigreerd tussen tenants. Omdat de URL ongeldig is in de doeltenant, moet u Teams-vergaderingen verwijderen en opnieuw maken.
Welke inhoud wordt gemigreerd tussen tenants?
Wanneer een postvak wordt gemigreerd tussen tenants met deze functie, worden alleen door de gebruiker zichtbare inhoud in het postvak, ook wel bekend als Top of Information Store (e-mail, contactpersonen, agenda, taken en notities), en de mappen Herstelbare items verwijderen, versies en opschonen gemigreerd.
Worden items in het Postvak UIT gemigreerd tussen tenants?
Items in het Postvak UIT worden niet gemigreerd tussen tenants, omdat deze map een clientmap is die specifiek is voor de Outlook-client. Items in het Postvak UIT worden lokaal opgeslagen en niet gesynchroniseerd met de cloud.
Wordt de inhoud van de Teams-chatmap gemigreerd tussen tenants?
Nee, de inhoud van de Teams-chatmap wordt niet gemigreerd tussen tenants. Zodra het postvak echter is gemigreerd tussen tenants, is de inhoud van de Teams-chatmap beschikbaar voor de brontenantbeheerder om te zoeken en te exporteren, met behulp van een inhoudszoekopdracht.
Hoe kan ik alleen verplaatsingen zien die verplaatsingen tussen tenants zijn, niet mijn onboarding- en off-boarding-verplaatsingen?
Gebruik de parameter Vlaggen :
Get-MoveRequest -Flags "CrossTenant"
Kunt u voorbeeldscripts opgeven voor het kopiëren van kenmerken die tijdens het testen worden gebruikt?
Opmerking
VOORBEELD : ZO IS, GEEN GARANTIE Dit script gaat uit van een verbinding met zowel het bronpostvak (om bronwaarden op te halen) als de doel-on-premises Active Directory Domeinservices (om het ADUser-object te stempelen).
# 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
Hoe krijgen we toegang tot Outlook op dag 1 nadat het postvak van de gebruiker is verplaatst?
Omdat slechts één tenant eigenaar kan zijn van een domein, wordt het voormalige primaire SMTP-adres niet gekoppeld aan de gebruiker in de doeltenant wanneer het postvak is verplaatst; alleen de domeinen die zijn gekoppeld aan de nieuwe tenant. Outlook gebruikt de nieuwe UPN van de gebruiker om te verifiëren bij de service en het Outlook-profiel verwacht het verouderde primaire SMTP-adres te vinden dat overeenkomt met het postvak in het doelsysteem. Omdat het verouderde adres zich niet in het doelsysteem bevindt, maakt het Outlook-profiel geen verbinding om het zojuist verplaatste postvak te vinden.
Voor deze eerste implementatie moeten gebruikers hun profiel opnieuw opbouwen met hun nieuwe UPN, primaire SMTP-adres en OST-inhoud opnieuw synchroniseren.
Opmerking
Plan dienovereenkomstig terwijl u uw gebruikers batcht voor voltooiing. U moet rekening houden met het netwerkgebruik en de capaciteit wanneer Outlook-clientprofielen worden gemaakt en de volgende OST- en OAB-bestanden naar clients worden gedownload.
Van welke Exchange RBAC-rollen moet ik lid zijn om een verplaatsing tussen tenants in te stellen of te voltooien?
Er is een matrix van rollen op basis van het aannemen van gedelegeerde taken bij het uitvoeren van een postvakverplaatsing. Op dit moment zijn er twee rollen vereist:
- De eerste rol is voor een eenmalige installatietaak waarmee de autorisatie wordt ingesteld voor het verplaatsen van inhoud naar of buiten de grens van uw tenant/organisatie. Omdat het verplaatsen van gegevens uit de controle van uw organisatie een kritieke zorg is voor alle bedrijven, hebben we gekozen voor de hoogst toegewezen rol van organisatiebeheerder. Deze rol moet een nieuwe OrganizationRelationship wijzigen of instellen waarmee de
-MailboxMoveCapability
instelling met de externe organisatie wordt gedefinieerd. Alleen de organisatiebeheerder kan de-MailboxMoveCapability
instelling wijzigen, terwijl andere kenmerken in de OrganizationRelationship kunnen worden beheerd door de beheerder van federatief delen. - De rol van het uitvoeren van de werkelijke verplaatsingsopdrachten kan worden gedelegeerd aan een functie op lager niveau. De rol van Postvakken verplaatsen is toegewezen aan de mogelijkheid om postvakken binnen of uit de organisatie te verplaatsen.
Hoe richten we ons op welk SMTP-adres is geselecteerd voor targetAddress (TargetDeliveryDomain) in het geconverteerde postvak (naar MailUser-conversie)?
Exchange-postvak verplaatst met BEHULP van MRS maakt het targetAddress op het oorspronkelijke bronpostvak bij het converteren naar een MailUser door een e-mailadres (proxyAddress) op het doelobject te vergelijken. Het proces neemt de -TargetDeliveryDomain
waarde die is doorgegeven aan de opdracht en controleert vervolgens op een overeenkomende proxy voor dat domein aan de doelzijde. Wanneer we een overeenkomst vinden, wordt het overeenkomende proxyAddress gebruikt om het ExternalEmailAddress (targetAddress) in te stellen op het geconverteerde postvakobject (nu MailUser).
Hoe werkt de e-mailstroom na de migratie?
E-mailstroom voor meerdere tenants na migratie werkt vergelijkbaar met exchange hybrid e-mailstroom. Elk gemigreerd postvak heeft de bron-mailgebruiker met het juiste doeladres nodig om binnenkomende e-mail van de brontenant door te sturen naar postvakken in de doeltenant. Transportregels, beveiligings- en nalevingsfuncties worden uitgevoerd zoals geconfigureerd in elke tenant waar de e-mail doorheen stroomt. Voor inkomende e-mail worden functies zoals antispam, antimalware, quarantaine, transportregels en logboekregels eerst uitgevoerd in de brontenant en vervolgens in de doeltenant.
Hoe worden postvakmachtigingen overgezet?
Postvakmachtigingen omvatten Verzenden namens en Postvaktoegang:
- Verzenden namens (AD:publicDelegates) slaat de DN van geadresseerden op met toegang tot het postvak van een gebruiker als gemachtigde. Deze waarde wordt opgeslagen in Active Directory en wordt momenteel niet verplaatst als onderdeel van de postvakovergang. Als voor het bronpostvak publicDelegates zijn ingesteld, moet u de publicDelegates op het doelpostvak opnieuw instellen zodra de conversie van de MEU naar Postvak is voltooid in de doelomgeving door uit te voeren
Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>
. - Postvakmachtigingen die zijn opgeslagen in het postvak, worden met het postvak mee verplaatst wanneer zowel de principal als de gemachtigde naar het doelsysteem worden verplaatst. De gebruiker TestUser7 krijgt bijvoorbeeld FullAccess voor het postvak TestUser_8 in de tenant-SourceCompany.onmicrosoft.com. Nadat het postvak is verplaatst naar TargetCompany.onmicrosoft.com, worden dezelfde machtigingen ingesteld in de doelmap. Voorbeelden van _Get-MailboxPermission voor TestUser_7 in zowel bron- als doeltenants worden hieronder weergegeven. Exchange-cmdlets worden dienovereenkomstig voorafgegaan door bron en doel.
Hier volgt een voorbeeld van de uitvoer van de postvakmachtiging vóór een verplaatsing vanaf de bronzijde:
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
Hier volgt een voorbeeld van de uitvoer van de postvakmachtiging na de verplaatsing vanaf de doelzijde:
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
Opmerking
Postvak- en agendamachtigingen voor meerdere tenants worden niet ondersteund. U moet principals en gemachtigden organiseren in geconsolideerde verplaatsingsbatches, zodat deze verbonden postvakken tegelijkertijd worden overgezet van de brontenant.
Welke X500-proxy moet worden toegevoegd aan de doelproxyadressen van MailUser om migratie in te schakelen?
Voor de migratie van postvak tussen tenants moet de waarde LegacyExchangeDN van het bronpostvakobject worden gestempeld als een x500-e-mailadres op het doelobject MailUser.
Voorbeeld:
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
Opmerking
Naast deze X500-proxy moet u alle X500-proxy's uit het postvak in de bron kopiëren naar het postvak in het doel. Hoewel het zelden voorkomt, kunt u ook een X400-proxyadres uitvoeren op een postvak. Hoewel dit geen vereiste is om de verplaatsing te voltooien, wordt u aangeraden dit adres ook te stempelen op het doelobject van de e-mailgebruiker.
Kunnen de bron- en doeltenant dezelfde domeinnaam gebruiken?
Nee, de namen van de brontenant en de doeltenant moeten uniek zijn, bijvoorbeeld een brondomein van contoso.com en het doeldomein van northwindtraders.com.
Worden gedeelde postvakken verplaatst en werken ze nog steeds?
Ja. We behouden echter alleen de opslagmachtigingen zoals beschreven in dit artikel:
Hebt u aanbevelingen voor batches?
Niet meer dan 2000 postvakken per batch. We raden u ten zeerste aan om batches twee weken vóór de cut-over datum in te dienen, omdat er tijdens de synchronisatie geen gevolgen zijn voor de eindgebruikers. Als u hulp nodig hebt voor postvakken van meer dan 50.000, kunt u contact opnemen met uw CSAM of een ondersteuningsaanvraag openen.
Wat gebeurt er als ik Serviceversleuteling gebruik met Microsoft Purview-klantsleutel?
Het postvak wordt ontsleuteld voordat het wordt verplaatst. Zorg ervoor dat de klantsleutel is geconfigureerd in de doeltenant als deze nog steeds is vereist. Zie hier voor meer informatie.
Wat is de geschatte migratietijd?
Om u te helpen bij het plannen van uw migratie, bevat de hier aanwezige tabel de richtlijnen over wanneer u bulkpostvakmigraties of afzonderlijke migraties kunt verwachten om te voltooien. Deze schattingen zijn gebaseerd op een gegevensanalyse van eerdere klantmigraties. Omdat elke omgeving uniek is, kan de exacte migratiesnelheid variëren.
Documenten beveiligen in de brontenant die kunnen worden gebruikt door gebruikers in de doeltenant.**
Migratie tussen tenants migreert alleen postvakgegevens en niets anders. Er zijn meerdere andere opties, die worden beschreven in het volgende blogbericht die u kunnen helpen:
Kan ik dezelfde labels in de doeltenant hebben als u in de brontenant had, als de enige set labels of als een extra set labels voor de gemigreerde gebruikers, afhankelijk van de uitlijning tussen de organisaties.**
Omdat migraties tussen tenants geen labels exporteren en er geen manier is om labels tussen tenants te delen, kunt u deze doelstelling alleen bereiken door de labels opnieuw te maken in de doeltenant.
Ondersteunt u het verplaatsen van Microsoft 365 Groepen?
Momenteel biedt de functie postvakmigraties tussen tenants geen ondersteuning voor de migratie van Microsoft 365 Groepen.
Kan een brontenantbeheerder een eDiscovery-zoekopdracht uitvoeren op een postvak nadat het postvak is gemigreerd naar de nieuwe/doeltenant?
Nee, na een migratie van een postvak tussen tenants werkt eDiscovery voor het postvak van de gemigreerde gebruiker in de bron niet. Deze eDiscovery-fout komt doordat er geen postvak meer in de bron is om naar te zoeken, omdat het postvak is gemigreerd naar de doeltenant en nu deel uitmaakt van de doeltenant. eDiscovery na de migratie van het postvak kan alleen worden uitgevoerd in de doeltenant (waar het postvak nu bestaat). Als er na de migratie een kopie van het bronpostvak moet blijven bestaan in de brontenant, kan de beheerder in de brontenant de inhoud kopiëren naar een alternatieve postvakvoormigratie voor toekomstige eDiscovery-bewerkingen op basis van de gegevens.
Op welk moment wordt de doel-MailUser geconverteerd naar een doelpostvak en het bronpostvak geconverteerd naar een bron-MailUser?
Deze conversies vinden automatisch plaats tijdens het migratieproces. Er zijn geen handmatige stappen nodig.
In welke stap moet ik de Exchange Online-licentie toewijzen aan doel-MailUsers?
Deze licentietoewijzing kan worden uitgevoerd voordat de migratie is voltooid, maar u moet geen licentie toewijzen voordat u het ExchangeGUID-kenmerk stempelt; anders mislukt de conversie van het MailUser-object naar het postvak en wordt in plaats daarvan een nieuw postvak gemaakt. Om dit risico te beperken, kunt u het beste wachten tot de migratie is voltooid en licenties toewijzen tijdens de respijtperiode van 30 dagen.
Kan ik Microsoft Entra Connect gebruiken om gebruikers te synchroniseren met de nieuwe tenant als ik de on-premises Active Directory behoud?
Ja. Het is mogelijk om twee exemplaren van Microsoft Entra Connect te laten synchroniseren met verschillende tenants. Er zijn echter enkele zaken waar u rekening mee moet houden:
- Het vooraf inrichten van de accounts van de gebruiker met het script in dit artikel mag niet worden uitgevoerd. In plaats daarvan kan een selectieve OE-synchronisatie van de gebruikers binnen het bereik van de migratie worden uitgevoerd om de doeltenant te vullen. U ontvangt een waarschuwing dat de UPN niet overeenkomt tijdens Microsoft Entra Connect-configuratie.
- Afhankelijk van uw huidige status van hybride Exchange, moet u controleren of de on-premises mapobjecten de vereiste kenmerken (zoals msExchMailboxGUID en proxyAddresses) correct hebben ingevuld voordat u probeert te synchroniseren met een andere tenant; anders ondervindt u problemen met dubbele postvakken en migratiefouten.
- U moet enkele extra stappen uitvoeren om de UPN-overgang te beheren en deze on-premises te wijzigen zodra de migratie voor een gebruiker is voltooid, tenzij u ook het aangepaste domein verplaatst tijdens een cut-overmigratie.
Hoe moet ik postvakken die het quotum naderen of overschrijden, afhandelen.
Postvakken die hun quotum vóór de migratie bijna hebben bereikt, kunnen het quotum vóór of tijdens de daadwerkelijke migratie overschrijden. Als dit gebeurt, mislukken de migratie van deze postvakken en moeten ze worden hersteld en opnieuw worden opgestart. Om dit te verhelpen, wordt de beheerder van de brontenant aangeraden postvakken op of bijna quotum te identificeren vóór de migratie en de benodigde stappen uit te voeren om de postvakgrootte te verkleinen, een primair archief in te richten of in sommige gevallen automatisch uitbreidende archieven in te schakelen voor de postvakken van de gebruiker.
Opmerking
Nadat u een archief of automatisch uitbreidend archief voor een gebruiker hebt ingeschakeld, moet u ervoor zorgen dat het juiste archiveringsbeleid wordt toegepast op de gebruiker en dat het proces wordt uitgevoerd om de postvakgegevens naar de nieuwe locatie te verplaatsen en ruimte vrij te maken.
Worden automatisch uitgevouwen archiefpostvakken verplaatst?
Probleem: Automatisch uitgevouwen archieven kunnen niet worden gemigreerd. Ja, als de gebruiker in de bron automatisch uitbreidende archieven heeft ingeschakeld en aanvullende aanvullende archieven heeft, werkt de migratie van een postvak tussen tenants. We bieden ondersteuning voor het verplaatsen van gebruikers die niet meer dan 12 extra archiefpostvakken hebben. Daarnaast hebben gebruikers met een groot primair, groot hoofdarchief en grote hulparchiefpostvakken extra tijd nodig om te synchroniseren en moeten ze ruim vóór de cut-overdatum worden ingediend. Als het bronpostvak wordt uitgevouwen tijdens het migratieproces van het postvak, mislukt de migratie als er een nieuw hulparchief wordt gemaakt in de bron, maar niet in het doel. In dit geval moet u de gebruiker uit de batch verwijderen en deze opnieuw indienen.
Kan ik een migratie tussen cloudtenant en tenant uitvoeren?
Migratie tussen cloudtenant en tenant wordt niet ondersteund. Een voorbeeldscenario is de overstap van Office 365 Worldwide naar Office 365 Government Cloud.
Worden voicemails gemigreerd tussen tenants?
Ja, voicemails worden gemigreerd tussen tenants.
- Ontvangen voicemails in e-mail als bijlagen zijn beschikbaar in het doelpostvak.
- Ontvangen voicemails zijn beschikbaar in Teams als u voicemail belt en luistert naar opgeslagen berichten. (VM's die in de bron zijn ontvangen, zijn beschikbaar als opgeslagen berichten)
- Ontvangen voicemails zijn na de migratie niet beschikbaar in de gebruikersinterface van de Teams-client.
- De voicemail begroeting wordt ook gemigreerd naar het doel.
Worden postvakhandtekeningen gemigreerd tussen tenants?
Postvakhandtekeningen worden niet gemigreerd tussen tenants en moeten opnieuw worden gemaakt.
Bekende problemen
Na de migratie is de functionaliteit van Teams in de brontenant beperkt. Nadat het postvak is gemigreerd naar de doeltenant, heeft Teams in de brontenant geen toegang meer tot het postvak van de gebruiker. Als een gebruiker zich bij Teams aanmeldt met de brontenantreferentie, gaat de functionaliteit verloren, zoals het niet kunnen bijwerken van de profielafbeelding, het ontbreken van een agendatoepassing en het niet kunnen zoeken naar en deelnemen aan openbare teams.
Cloud MailUsers met een smtp-proxyadres zonder eigendom blokkeren MRS-verplaatsingen. Wanneer u MailUser-objecten voor de doeltenant maakt, moet u ervoor zorgen dat alle SMTP-proxyadressen deel uitmaken van de doeltenantorganisatie. Als er een SMTP-proxyAddress bestaat op de doel-e-mailgebruiker die niet tot de lokale tenant behoort, wordt de conversie van de MailUser naar een postvak voorkomen. Deze preventie is het gevolg van onze verzekering dat postvakobjecten alleen e-mail kunnen verzenden vanuit domeinen waarvoor de tenant gezaghebbend is (domeinen die door de tenant worden geclaimd).
Als u gebruikers van on-premises synchroniseert met behulp van Microsoft Entra Connect in de doeltenant, kunt u on-premises MailUser-objecten inrichten met ExternalEmailAddress die verwijst naar de brontenant waar het postvak bestaat (LaraN@contoso.onmicrosoft.com). Vervolgens stempelt u het PrimarySMTPAddress in als een domein dat zich in de doeltenant bevindt (Lara.Newton@northwindtraders.com). Deze waarden worden gesynchroniseerd met de tenant en een geschikte e-mailgebruiker wordt ingericht en is klaar voor migratie. Hier wordt een voorbeeldobject weergegeven.
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses ExternalEmailAddress EmailAddresses -------------------- -------------- SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}
Opmerking
Het contoso.onmicrosoft.com adres is niet aanwezig in de matrix EmailAddresses/proxyAddresses.
MailUser-objecten met 'externe' primaire SMTP-adressen worden gewijzigd/opnieuw ingesteld op 'interne' door het bedrijf geclaimde domeinen.
MailUser-objecten zijn aanwijzers naar niet-lokale postvakken. In het geval van postvakmigraties tussen tenants gebruiken we MailUser-objecten om het bronpostvak (vanuit het perspectief van de doelorganisatie) of het doelpostvak (vanuit het perspectief van de bronorganisatie) weer te geven. De MailUsers hebben een ExternalEmailAddress (targetAddress) die verwijst naar het SMTP-adres van het werkelijke postvak (ProxyTest@northwindtraders.onmicrosoft.com) en primarySMTP-adres dat het weergegeven SMTP-adres van de postvakgebruiker in de map vertegenwoordigt. Sommige organisaties kiezen ervoor om het primaire SMTP-adres weer te geven als een extern SMTP-adres, niet als een adres dat eigendom is van/is geverifieerd door de lokale tenant (bijvoorbeeld als northwindtraders.com in plaats van als contoso.com). Zodra echter een Exchange-serviceplanobject is toegepast op de MailUser via licentiebewerkingen, wordt het primaire SMTP-adres gewijzigd om weer te geven als een domein dat is geverifieerd door de lokale organisatie (contoso.com). Er zijn twee mogelijke redenen:
Wanneer een Exchange-serviceplan wordt toegepast op een MailUser, wordt het Microsoft Entra ID proces gestart met het afdwingen van proxy-scrubbing om ervoor te zorgen dat de lokale organisatie geen e-mail, adressering of e-mail kan verzenden vanuit een andere tenant. Elk SMTP-adres op een geadresseerdeobject met deze serviceplannen wordt verwijderd als het adres niet wordt geverifieerd door de lokale organisatie. Zoals in het voorbeeld het geval is, wordt het northwindtraders.com domein niet geverifieerd door de contoso.onmicrosoft.com tenant; daarom verwijdert de scrubbing dat northwindtraders.com domein. Als u deze externe domeinen op MailUser wilt behouden, voor of na de migratie, moet u uw migratieprocessen wijzigen om licenties te verwijderen nadat de verplaatsing is voltooid of voordat de verplaatsing is voltooid om ervoor te zorgen dat de gebruikers de verwachte externe huisstijl hebben toegepast. U moet ervoor zorgen dat het postvakobject de juiste licentie heeft om de e-mailservice niet te beïnvloeden. Hier ziet u een voorbeeldscript voor het verwijderen van de serviceplannen op een MailUser in de contoso.onmicrosoft.com-tenant.
Opmerking
Het volgende script maakt gebruik van Microsoft Graph Powershell. Zie Overzicht van Microsoft Graph PowerShell voor meer informatie.
Zie het artikel Cmdlets voor verificatiemodules in Microsoft Graph PowerShell voor meer informatie over het gebruik van verschillende methoden voor verificatie Connect-Graph
in een script zonder toezicht.
# 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
Resultaten in de set toegewezen ServicePlans worden hier weergegeven:
$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
Het PrimarySMTPAddress van de gebruiker wordt niet meer verwijderd. Het northwindtraders.com domein is geen eigendom van de contoso.onmicrosoft.com tenant en blijft behouden als het primaire SMTP-adres dat wordt weergegeven in de map.
Hier volgt een voorbeeld:
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
Wanneer msExchRemoteRecipientType
is ingesteld op 8 (DeprovisionMailbox) voor on-premises mailgebruikers die zijn gemigreerd naar de doeltenant, verwijdert de proxy-scrublogica in Azure domeinen die geen eigendom zijn en stelt de primarySMTP opnieuw in op een domein in eigendom. Nu de msExchRemoteRecipientType in de on-premises MailUser wordt gewist, is de logica voor proxyscrubs niet meer van toepassing.
Hieronder vindt u de volledige set huidige serviceabonnementen met Exchange Online:
Naam |
---|
eDiscovery (Premium) Storage (500 GB) |
Klanten-lockbox |
Preventie van gegevensverlies |
Exchange Enterprise CAL-services (EOP, DLP) |
Exchange-Essentials |
Exchange Foundation |
Exchange Online (P1) |
Exchange Online (Abonnement 1) |
Exchange Online (Abonnement 2) |
Exchange Online Archiving voor Exchange Online |
Exchange Online Archiving voor Exchange Server |
Invoegtoepassing voor inactieve gebruikers Exchange Online |
Exchange Online Kiosk |
Exchange Online Multi-Geo |
Exchange Online Abonnement 1 |
Exchange Online POP |
Exchange Online Protection |
Grafiekconnectors zoeken met index |
Informatiebarrières |
Information Protection voor Office 365 - Premium |
Information Protection voor Office 365 - Standard |
Inzichten van MyAnalytics |
Microsoft Information Governance |
Microsoft Purview Audit (Premium) |
Microsoft Bookings |
Microsoft Business Center |
Microsoft-gegevensonderzoeken |
Microsoft MyAnalytics (volledig) |
Naleving van Microsoft Communications |
Microsoft Communications DLP |
Microsoft-klantsleutel |
Microsoft 365 Advanced Auditing |
Microsoft Records Management |
Office 365 eDiscovery (Premium) |
Office 365 Advanced eDiscovery |
Microsoft Defender for Office 365 (Plan 1) |
Microsoft Defender voor Office 365 (abonnement 2) |
Office 365 Privileged Access Management |
Premium-versleuteling in Office 365 |
Migratiefouten
MailboxNotInCrossTenantMigrationScopeException
Zorg ervoor dat het migratiebereik juist is ingesteld op de brontenant en dat MailboxMovesPublishedScopes is ingesteld in de organisatierelatie met de doeltenant.
Controleer of het postvak dat moet worden gemigreerd, is toegevoegd aan de beveiligingsgroep in de brontenant.
Nadat u de gebruiker hebt toegevoegd aan de juiste beveiligingsgroep, hervat u de migratiebatch.AuxArchiveNotFoundInTargetRecipientException
Deze fout komt doordat de gebruiker zich niet in het migratiebereik bevond toen de batch werd gestart en de gebruiker AuxArchive op de bron heeft.
Voeg een gebruiker toe aan de juiste beveiligingsgroep op het brondoel.
Verwijder de migratiegebruiker uit de batch.
Verwijder gebruikers met de volgende opdracht:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
Gebruiker toevoegen aan nieuwe batch.
MailboxIsNotInExpectedDBException
Deze fout wordt veroorzaakt door intern microsoft-onderhoud.
Verwijder de migratiegebruiker uit de batch.
Verwijder gebruikers met de volgende opdracht:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
Gebruiker toevoegen aan nieuwe batch.
NotAcceptedDomainException
Er is een ongeldig proxyadres gestempeld op de doelgebruiker. Een voorbeeld hiervan is wanneer een gebruiker in contoso.onmicrosoft.com een proxyadres van fabrikam.onmicrosoft.com had, de brontenant.
Verwijder het ongeldige proxyadres met de volgende opdracht:Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}
De migratiebatch hervatten.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException
Tijdens de migratie is een nieuwe AuxArchive ingericht.
Verwijder de migratiegebruiker uit de batch.
Verwijder gebruikers met de volgende opdracht:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
Gebruiker toevoegen aan nieuwe batch.
UserDuplicateInOtherBatchException
De gebruiker bestaat al in een andere batch.
Verwijder de migratiegebruiker uit de batch.
Verwijder gebruikers met de volgende opdracht:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
Gebruiker toevoegen aan nieuwe batch.
MissingExchangeGuidException
In het doel-mailgebruikerobject ontbreekt de juiste ExchangeGuid-waarde.
Werk de ExchangeGuid bij met de volgende opdracht:Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8
Migratiebatch hervatten.
SourceMailboxAlreadyBeingMovedPermanentException
Het bronpostvak heeft al een bestaande verplaatsingsaanvraag. De bestaande verplaatsing onderzoeken en verwijderen. Het is mogelijk dat dit een interne Verplaatsing van Microsoft is en u moet wachten tot de verplaatsing is voltooid.
Verwijder de migratiegebruiker uit de batch.
Verwijder gebruikers met de volgende opdracht:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser
Voeg een gebruiker toe aan een nieuwe batch nadat de oorspronkelijke verplaatsing is verwijderd of voltooid.
UserAlreadyHasDemotedArchiveException
De gebruiker had eerder een archiefpostvak dat was uitgeschakeld. Kies een van de twee volgende opties om dit probleem op te lossen.
Verwijder het uitgeschakelde archiefpostvak definitief, dit is niet terug te draaien. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Schakel het uitgeschakelde archiefpostvak opnieuw in met de volgende opdracht:Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
Als u het uitgeschakelde archiefpostvak opnieuw inschakelt, moet u de archief-GUID bijwerken op het doel-mailgebruikerobject.
Migratiebatch hervatten.
Zie ook
- Microsoft 365 beheren met PowerShell
- Aan de slag met de Microsoft Graph PowerShell SDK
- [https://techcommunity.microsoft.com/t5/exchange-team-blog/troubleshooting-cross-tenant-mailbox-migrations/ba-p/4178404]