Postaláda-áttelepítés bérlők között
Fúziók vagy elidegenítések során előfordulhat, hogy át kell helyeznie a felhasználók Exchange Online-postaládáit egy új bérlőbe. A bérlők közötti postaláda-áttelepítés lehetővé teszi, hogy a bérlői rendszergazdák olyan jól ismert felületeket használjanak, mint az Exchange Online PowerShell és az MRS, hogy átálljanak a felhasználók az új szervezetükre.
A rendszergazdák a Postaládák áthelyezése felügyeleti szerepkörrel elérhető New-MigrationBatch parancsmaggal hajthatnak végre bérlők közötti áthelyezéseket.
A bérlők közötti áthelyezés engedélyezéséhez a migrált felhasználóknak a célbérlő Exchange Online rendszerében MailUserként kell szerepelnie, és meghatározott attribútumokkal kell megjelölve lenniük. A rendszer nem tudja áthelyezni azokat a felhasználókat, amelyek nincsenek megfelelően beállítva a célbérlőben.
Az áthelyezések befejeződése után a forrásfelhasználó postaládája át lesz alakítva egy MailUserértékre, a targetAddress (Exchange-ben ExternalEmailAddress néven látható) pedig a célbérlőre mutató útválasztási címmel lesz lebélyegzve. Ez a folyamat a forrásbérlőben hagyja az örököltet MailUser , és lehetővé teszi az egyidejűséget és az e-mail-útválasztást. Ha az üzleti folyamatok lehetővé teszik, a forrásbérlő eltávolíthatja a mailUser forrást, vagy átalakíthatja őket levelezési kapcsolattartóvá.
A bérlők közötti Exchange-postaládák áttelepítése csak hibrid vagy felhőbeli bérlők esetén, illetve a kettő kombinációjában támogatott.
Ez a cikk a bérlők közötti postaláda-áthelyezés folyamatát ismerteti, és útmutatást nyújt a forrás- és célbérlők előkészítéséhez az Exchange Online-postaláda-tartalom áthelyezéséhez.
Fontos
A bármilyen típusú visszatartott postaládák nem lesznek áttelepítve, és a postaládák áthelyezése le van tiltva.
Ha ezzel a funkcióval bérlők közötti postaládát telepít át, a rendszer csak a felhasználó által látható tartalmakat (e-maileket, névjegyeket, naptárt, feladatokat és jegyzeteket) telepíti át a célhelyre (célbérlő). A sikeres áttelepítés után a forráspostaláda törlődik. Ez a törlés azt jelenti, hogy az áttelepítés után a forráspostaláda semmilyen körülmények között nem érhető el, deríthető fel vagy érhető el a forrásbérlőben.
Licencelés
Fontos
2022. nov.-ától a bérlők közötti felhasználói adatok áttelepítése bővítményként érhető el a Nagyvállalati Szerződéssel rendelkező ügyfeleknek készült alábbi Microsoft 365-előfizetési csomagokhoz, és a bérlők közötti migráláshoz szükséges. A felhasználói licencek migrálásonként vannak (egyszeri díj), és hozzárendelhetők a forrás- vagy a célfelhasználói objektumhoz. Ez a licenc a OneDrive Vállalati verzió áttelepítésére is vonatkozik. Részletekért forduljon a Microsoft-fiókért felelős csapathoz.
A bérlők közötti felhasználói adatmigrálási bővítmény külön megvásárolható a Microsoft 365 Vállalati alapszintű, Standard és Prémium verzióhoz; Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; és a OneDrive Vállalati verzióban.
Figyelmeztetés
A következő lépések előtt meg kell vásárolnia vagy ellenőriznie kell, hogy vásárolhat-e bérlők közötti felhasználói adatmigrálási licenceket. Az áttelepítés sikertelen, ha ez a lépés még nem fejeződött be. A Microsoft nem kínál kivételeket ehhez a licencelési követelményhez.
Ha nem rendelkezik a migrált felhasználóhoz rendelt megfelelő licenccel, az áttelepítés sikertelen lesz, és a következőhöz hasonló hibaüzenet jelenik meg:
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.
Forrás- és célbérlők előkészítése
A forrás- és célbérlők előfeltételei
Mielőtt hozzákezd, győződjön meg arról, hogy rendelkezik a Postaláda áthelyezése alkalmazás azure-beli konfigurálásához szükséges engedélyekkel, az EXO-migrálási végpontgal és az EXO szervezeti kapcsolatával.
Emellett legalább egy levelezési biztonsági csoportra van szükség a forrásbérlőben. Ezek a csoportok a forrásbérlőből (vagy más néven erőforrásból) a célbérlőbe áthelyezhető postaládák listájának hatókörére szolgálnak. Ezzel a hatókörrel a forrásbérlő rendszergazdája korlátozhatja vagy korlátozhatja az áthelyezni kívánt postaládák adott készletét, megakadályozva a nem kívánt felhasználók áttelepítését.
Ha több mint 10 000 felhasználót migrál, javasoljuk, hogy hozzon létre több csoportot, hogy a legjobb teljesítmény érdekében tartalmazza a felhasználói listát. Bár a beágyazott csoportok támogatottak, nem ajánlottak.
A Microsoft 365-ös bérlőazonosító beszerzéséhez a megbízható partnervállalattal is kommunikálnia kell (akivel postaládákat fog áthelyezni). A rendszer ezt a bérlőazonosítót használja a Szervezeti kapcsolat tartományneve mezőben.
Egy előfizetés bérlőazonosítójának beszerzéséhez jelentkezzen be a Microsoft 365 Felügyeleti központba , és nyissa meg a következőt https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties: . Válassza a Bérlőazonosító tulajdonság másolás ikonját a vágólapra való másoláshoz.
A forrás- és célszervezetek minden felhasználójának rendelkeznie kell a megfelelő Exchange Online-előfizetésekkel. Emellett győződjön meg arról, hogy a bérlők közötti felhasználói adatmigrálási licenceket a céloldalra migrálni kívánt összes felhasználóra alkalmazza.
Konfigurációs lépések a bérlők bérlők közötti postaláda-áttelepítések engedélyezéséhez
Megjegyzés:
Először konfigurálnia kell a célt (célhelyet). A lépések végrehajtásához nem kell rendelkeznie vagy ismernie kell a bérlői rendszergazdai hitelesítő adatokat a forrás- és a célbérlőhöz. A lépéseket a különböző rendszergazdák egyenként hajthatják végre az egyes bérlők esetében.
A célbérlő (cél) előkészítése a migrálási alkalmazás és a titkos kód létrehozásával
Jelentkezzen be a Microsoft Entra felügyeleti központba (https://portal.azure.com) a cél bérlői rendszergazdai hitelesítő adataival.
A Microsoft Entra-azonosító kezelése területen válassza a Megtekintés lehetőséget.
A navigációs ablakban válassza az Alkalmazásregisztrációk lehetőséget.
Válassza az Új regisztráció lehetőséget.
Az Alkalmazás regisztrálása lap Támogatott fióktípusok területén válassza a Bármely szervezeti címtárban (Bármely Microsoft Entra-címtár – több-bérlős) található fiókok lehetőséget. Ezután az Átirányítási URI (nem kötelező) területen válassza a Web lehetőséget, majd írja be a következőt:
https://office.com. Ezután válassza a Regisztráció lehetőséget.
A lap jobb felső sarkában tekintse meg az alkalmazás sikeres létrehozását jelző értesítési párbeszédpanelt.
Lépjen vissza a Kezdőlapra, nyissa meg a Microsoft Entra-azonosítót, majd válassza az Alkalmazásregisztrációk lehetőséget.
A Saját alkalmazások területen keresse meg a létrehozott alkalmazást, majd válassza ki.
Az Alapvető szolgáltatások területen másolja ki az alkalmazás (ügyfél) azonosítóját. Ezekre az adatokra később szüksége lesz a célbérlő URL-címének létrehozásához.
A navigációs panelen válassza az API-engedélyek lehetőséget az alkalmazáshoz rendelt engedélyek megtekintéséhez.
Alapértelmezés szerint a User.Read engedélyek hozzá vannak rendelve a létrehozott alkalmazáshoz, de ezek az engedélyek nem szükségesek a postaláda áttelepítéséhez. Ezeket az engedélyeket eltávolíthatja.
A postaláda áttelepítésére vonatkozó engedély hozzáadásához válassza az Engedély hozzáadása lehetőséget.
Az API-engedélyek kérése ablakban válassza ki a szervezet által használt API-kat, keressen rá a kifejezésre
Office 365 Exchange Online, majd válassza ki azt.
Válassza az Alkalmazásengedélyek lehetőséget.
Az Engedélyek kiválasztása területen bontsa ki a Postaláda elemet, válassza a Postaláda.Migrálás elemet, majd válassza az Engedélyek hozzáadása lehetőséget a képernyő alján.
Most válassza a Tanúsítványok & titkos kulcsokat az alkalmazás navigációs paneljén.
Az Ügyfél titkos kódjai területen válassza az Új titkos ügyfélkód lehetőséget.
Az Ügyfélkód hozzáadása ablakban adjon meg egy leírást, majd konfigurálja a lejárati beállításokat.
Megjegyzés:
A jelszó a migrálási végpont létrehozásakor használatos. Rendkívül fontos, hogy ezt a jelszót a vágólapra és/vagy egy biztonságos/titkos jelszó biztonságos helyre másolja. Ez a jelszó csak a titkos kód létrehozási szakaszában jelenik meg! Ha valahogy elveszíti vagy alaphelyzetbe kell állítania, jelentkezzen be újra az Azure Portalra, lépjen az Alkalmazásregisztrációk menüpontra, keresse meg az áttelepítési alkalmazást, válassza a Titkos kódok & tanúsítványok lehetőséget, majd hozzon létre egy új titkos kódot az alkalmazáshoz.
Most, hogy sikeresen létrehozta a migrálási alkalmazást és a titkos kódot, a következő lépés az alkalmazás jóváhagyása.
Hozzájárulás megadása az alkalmazáshoz
A Microsoft Entra ID kezdőlapján válassza a Nagyvállalati alkalmazások lehetőséget a navigációs panelen; majd keresse meg a létrehozott migrálási alkalmazást, válassza ki, majd válassza az API-engedélyek lehetőséget.
Válassza a Rendszergazdai hozzájárulás megadása a(z) [bérlőhöz] lehetőséget. Megnyílik egy új böngészőablak.
Válassza az Elfogadás lehetőséget.
Térjen vissza a portál ablakához, és válassza a Frissítés lehetőséget az elfogadás megerősítéséhez.
Alakítsa ki a megbízható partnernek (a forrásbérlő rendszergazdájának) küldendő URL-címet, hogy a postaládák áttelepítésének engedélyezéséhez az alkalmazást is elfogadhassák.
Íme egy példa a számukra megadható URL-címre:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comMegjegyzés:
Szüksége lesz az imént létrehozott postaláda-áttelepítési alkalmazás alkalmazásazonosítójára. A fenti példában a contoso.onmicrosoft.com a forrásbérlő helyes onmicrosoft.com nevére kell cserélnie. A [application_id_of_the_app_you_just_created] helyére az imént létrehozott postaláda-áttelepítési alkalmazás alkalmazásazonosítóját is be kell írnia.
A célbérlő előkészítése az Exchange Online migrálási végpontjának és a szervezeti kapcsolatnak a létrehozásával
Csatlakozzon az Exchange Online PowerShellhez a cél Exchange Online-bérlőben.
Hozzon létre egy új áttelepítési végpontot a bérlők közötti postaláda-áthelyezésekhez.
Megjegyzés:
Szüksége lesz az imént létrehozott postaláda-áttelepítési alkalmazás alkalmazásazonosítójára, valamint a célhely (cél) bérlőjének előkészítéséhez az áttelepítési alkalmazás és titkos kód létrehozásával konfigurált jelszóra (titkos kódra). A használt Microsoft 365-felhőpéldánytól függően a végpontja eltérő lehet. Tekintse meg a Microsoft 365-végpontok oldalt; válassza ki a bérlőnek megfelelő példányt; ezután tekintse át az Exchange Online Optimalizálás/Kötelező címet, és szükség szerint cserélje le a elemet.
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $AppId = "[Guid copied from the migrations app]" $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the previous steps]" -AsPlainText -Force) New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppIdHozzon létre egy új szervezeti kapcsolatobjektumot, vagy szerkessze a meglévő szervezeti kapcsolatobjektumot a forrásbérlőn.
$sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]" $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound } If ($null -eq $existingOrgRel) { New-OrganizationRelationship "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId }
Készítse elő a forrás (aktuális postaláda helye) bérlőt az áttelepítési alkalmazás elfogadásával és a szervezeti kapcsolat konfigurálásával
A böngészőben lépjen a megbízható partner által megadott URL-címre a postaláda-áttelepítési alkalmazáshoz való hozzájáruláshoz. Az URL-címnek így kell kinéznie:
https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.comMegjegyzés:
Szüksége lesz az imént létrehozott postaláda-áttelepítési alkalmazás alkalmazásazonosítójára. Az előző példában le kell cserélnie
contoso.onmicrosoft.coma forrásbérlő URL-címétonmicrosoft.com. A [application_id_of_the_app_you_just_created] helyére az imént létrehozott postaláda-áttelepítési alkalmazás alkalmazásazonosítóját is be kell írnia.Fogadja el az alkalmazást, amikor megjelenik az előugró ablak. Bejelentkezhet a Microsoft Entra felügyeleti központba is, és megtalálhatja az alkalmazást a Nagyvállalati alkalmazások területen.
Csatlakozzon az Exchange Online PowerShellhez a forrás Exchange Online-bérlőn.
Hozzon létre egy új szervezeti kapcsolatobjektumot, vagy szerkessze a meglévő szervezeti kapcsolatobjektumot a cél (cél) bérlőn az Exchange Online PowerShellben:
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]" $appId="[application id of the mailbox migration app you consented to]" $scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]" New-DistributionGroup -Type Security -Name $scope $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope } If ($null -eq $existingOrgRel) { New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope }Megjegyzés:
A $sourceTenantId és $targetTenantId megadott bérlőazonosító a GUID, nem pedig a bérlő tartományneve. A bérlőazonosítóra és a bérlőazonosító megkeresésére vonatkozó információkért lásd: A Microsoft 365-ös bérlőazonosító megkeresése.
Célfelhasználói objektumok előkészítése a migráláshoz
A bérlők közötti áthelyezés engedélyezéséhez a migrált felhasználóknak jelen kell lenniük a célbérlőben és az Exchange Online rendszerben (MailUserként) meghatározott attribútumokkal. A rendszer nem tudja áthelyezni azokat a felhasználókat, amelyek nincsenek megfelelően beállítva a célbérlőben. A célfelhasználói objektumok előfeltételei szakasz részletesen ismerteti a célbérlő MailUser objektumkövetelményeit.
A célfelhasználói objektumok előfeltételei
Győződjön meg arról, hogy a következő objektumok és attribútumok vannak beállítva a célszervezetben:
Tipp
A Microsoft egy olyan funkciót fejleszt, amely biztonságos automatizált módszert biztosít számos attribútum beállításához (lásd alább, ebben a szakaszban). Ez a bérlők közötti identitásleképezés nevű funkció jelenleg olyan ügyfeleket keres, akik hajlandóak részt venni egy kis privát előzetes verzióban. Erről a kiadás előtti funkcióról és arról, hogyan egyszerűsítheti le a bérlők közötti migrálási folyamatokat, tekintse meg a bérlők közötti identitásleképezést ismertető cikket.
A forrásszervezetből áthelyezett postaládák esetében ki kell építenie egy MailUser objektumot a Célszervezetben:
A célpostafelhasználónak rendelkeznie kell ezekkel az attribútumokkal a forráspostafiókból, vagy hozzá kell rendelni az új User objektumhoz:
ExchangeGUID (közvetlen folyamat a forrástól a célig): A postaláda GUID azonosítójának egyeznie kell. Az áthelyezési folyamat nem folytatódik, ha ez az attribútum nincs jelen a célobjektumon.
ArchiveGUID (közvetlen folyamat a forrástól a célig): Az archív GUID azonosítónak egyeznie kell. Az áthelyezési folyamat nem folytatódik, ha ez az attribútum nincs jelen a célobjektumon. (Ez az attribútum csak akkor szükséges, ha a forráspostaláda archiválva van.
LegacyExchangeDN (folyamat proxyAddress, "x500:<LegacyExchangeDN"): Az LegacyExchangeDN-nek> x500: proxyAddress néven kell szerepelnie a cél MailUserben. Emellett az összes x500 címet át kell másolnia a forráspostaládából a célposta-felhasználóba. Az áthelyezési folyamatok nem folytatódnak, ha ezek az x500-címek nincsenek jelen a célobjektumon. Ez a lépés a migrálás előtt elküldött e-mailek válaszképességének engedélyezéséhez is fontos. A Feladó/címzett cím az egyes e-mail-elemekben és az automatikus kiegészítési gyorsítótárban a Microsoft Outlookban és a Microsoft Outlook Web Appban (OWA) a LegacyExchangeDN attribútum értékét használja. Ha egy felhasználó nem található a LegacyExchangeDN érték használatával, az e-mailek kézbesítése sikertelen lehet 5.1.1 sikertelen kézbesítésről rendelkező sikertelen kézbesítés esetén.
UserPrincipalName: Az UPN igazodik a felhasználó ÚJ identitásához vagy célvállalatához (például user@northwindtraders.onmicrosoft.com).
Elsődleges SMTPAddress: Az elsődleges SMTP-cím igazodik a felhasználó ÚJ vállalatához (például user@northwindtraders.com).
TargetAddress/ExternalEmailAddress: A MailUser a felhasználó aktuális postaládájára hivatkozik, amely a forrásbérlőben található (például user@contoso.onmicrosoft.com). Ennek az értéknek a hozzárendelésekor ellenőrizze, hogy rendelkezik-e primarySMTPAddress kiszolgálóval vagy azzal is; máskülönben ez az érték állítja be a PrimarySMTPAddress értéket, ami áthelyezési hibákat okoz.
Nem adhat hozzá örökölt SMTP-proxycímeket a forráspostafiókból a mailUser célhoz. Nem tarthatja fenn például contoso.com a meu-n northwindtraders.onmicrosoft.com bérlőobjektumokban. A tartományok csak egy Microsoft Entra-azonosítóhoz vagy Exchange Online-bérlőhöz vannak társítva.
Példa cél MailUser objektumra:
Attribútum Érték Alias LaraN Címzett típusa 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 felügyeleti csoport (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara E-mail-címek x500:/o=First Organization/ou=Exchange felügyeleti csoport (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara Smtp:LaraN@northwindtraders.onmicrosoft.com SMTP:Lara.Newton@northwindtraders.com X500:/o=ExchangeLabs/ou=Exchange felügyeleti csoport (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara Példa forrás postaláda objektumra:
Attribútum Érték Alias LaraN Címzett típusa 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 felügyeleti csoport (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara E-mail-címek Smtp:LaraN@contoso.onmicrosoft.com SMTP:Lara.Newton@contoso.com X500:/o=ExchangeLabs/ou=Exchange felügyeleti csoport (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara
Más attribútumok is szerepelhetnek már az Exchange hibrid visszaírásában. Ha nem, akkor bele kell foglalni őket.
msExchBlockedSendersHash– Online letiltott feladói adatokat ír vissza az ügyfelekről a helyszíni Active Directoryba.msExchSafeRecipientsHash– Online biztonságos címzettek adatait írja vissza az ügyfelekről a helyszíni Active Directoryba.msExchSafeSendersHash– Online megbízható feladói adatokat ír vissza az ügyfelekről a helyszíni Active Directoryba.
A célszervezet felhasználóinak licenccel kell rendelkeznie a szervezetre vonatkozó megfelelő Exchange Online-előfizetésekkel. A postaláda áthelyezése előtt alkalmazhat licencet, de CSAK akkor, ha a cél MailUser megfelelően be van állítva exchangeGUID-vel és proxycímekkel. Ha az ExchangeGUID alkalmazása előtt alkalmaz egy licencet, az új postaládát hoz létre a célszervezetben. Bérlők közötti felhasználói adatmigrálási licencet is alkalmaznia kell; máskülönben előfordulhat, hogy egy átmeneti hiba olvasásakor jóváhagyásra van szükség, amely figyelmeztetést küld az áthelyezési jelentésben arról, hogy a licenc nem lett alkalmazva a célfelhasználóra.
Megjegyzés:
Amikor licencet alkalmaz egy Postaláda vagy MailUser objektumra, a rendszer minden proxyAddresses SMTP-típust töröl, hogy csak ellenőrzött tartományok szerepeljenek az Exchange E-mailAddresses tömbjében.
Győződjön meg arról, hogy a cél MailUser nem rendelkezik olyan korábbi ExchangeGUID-val, amely nem egyezik a forrás ExchangeGUID-val. Ez az eltérés akkor fordulhat elő, ha a cél meu korábban licencelt az Exchange Online-hoz, és létrehozott egy postaládát. Ha a cél MailUser korábban licencelve volt a forrás ExchangeGUID-hez, vagy rendelkezik olyan ExchangeGUID-val, amely nem egyezik meg a forrás ExchangeGUID-val, törölnie kell a felhőbeli felhasználói felületét. Ezekhez a felhőalapú meu-khoz futtathatja a következőt
Set-User <identity> -PermanentlyClearPreviousMailboxInfo: .
Figyelem!
Ez a folyamat visszafordíthatatlan. Ha az objektum helyreállítható módon törölt postaládával rendelkezik, akkor ezt követően nem állítható vissza. A törlés után azonban szinkronizálhatja a megfelelő ExchangeGUID-t a célobjektummal, és az MRS csatlakoztatja a forráspostaládát az újonnan létrehozott célpostaládához. (Hivatkozzon az EHLO-blogra az új paraméterről.)
Keresse meg azokat az objektumokat, amelyek korábban postaládák voltak az alábbi paranccsal:
Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize
Íme egy példa:
Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize
Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails
---- ---------------------------- ------------- --------------------
John UserMailbox MailUser MailUser
Törölje a helyreállítható módon törölt postaládát a következő paranccsal:
Set-User <identity> -PermanentlyClearPreviousMailboxInfo
Íme egy példa:
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
Honnan tudhatom, hogy ez működött?
A bérlők közötti postaláda-áttelepítés konfigurálásának ellenőrzéséhez futtassa a Test-MigrationServerAvailability parancsmagot a célbérlőn létrehozott bérlők közötti áttelepítési végponton. Futtassa a következő parancsmagot a célbérlőből:
Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"
Megjegyzés:
Emellett érdemes lehet kihasználni a bérlők közötti postaláda-áttelepítés ellenőrzési szkriptjét, amely lehetővé teszi a szervezetek megfelelő beállításának ellenőrzését, valamint az egyik bérlőről a másikra való áttelepítést tervezi. A szkript segít azonosítani azokat az eltéréseket, amelyek az összes objektumon egyszerre jelen lehetnek, és ennek eredményeképpen csökkenti a kezdeti fázisban töltött időt.
Postaládák visszaállítása az eredeti forrásra
Ha az eredeti forrásbérlőre való visszalépéshez postaláda szükséges, akkor ugyanazokat a lépéseket és szkripteket kell futtatni az új forrás- és új célbérlőkben is, némi eltéréssel.
Ne futtassa az OrganizationRelationship létrehozásához megadott mintaszkripteket.
Frissítse a következő értékeket az egyes bérlőkben létrehozott meglévő OrganizationRelationshipben:
- A MailboxMovesCapability szolgáltatásnak a forrás- és a célbérlőkben is rendelkeznie kell a bejövő és a távoli kimenő lehetőségekkel.
- Az új forrásbérlőben frissítse az OAuthApplicationId értékét az új forrásbérlőben újonnan létrehozott alkalmazás értékével.
- Az új forrásbérlőben frissítse a MailboxMovePublishedScopes értéket az új forrásbérlőben újonnan létrehozott biztonsági csoporttal.
Postaláda áttelepítése
A bérlők közötti Exchange-postaláda-áttelepítéseket a célbérlő kezdeményezi áttelepítési kötegekként. Ez a folyamat hasonló ahhoz, ahogyan a beszálló áttelepítési kötegek működnek a helyszíni Exchange-ből a Microsoft 365-be való migrálás során.
Migrálási kötegek létrehozása
Íme egy példaparancs a kötegelt migrálás kezdeményezéséhez:
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
Megjegyzés:
A CSV-fájlban szereplő e-mail-címnek nem a forrásbérlőben, hanem userA@northwindtraders.onmicrosoft.coma célbérlőben megadott e-mail-címnek kell lennie. A parancsmaggal kapcsolatos további információkért kattintson ide: Példa CSV-fájladatokra, kattintson ide
A CSV-fájlokra minimális példa a következő:
EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com
A migrálási kötegküldés az új Exchange Felügyeleti központban is támogatott a bérlők közötti lehetőség kiválasztásakor.
A helyszíni MailUsers frissítése
Miután a postaláda átkerült a forrásból a célba, gondoskodnia kell arról, hogy a helyszíni levelezési felhasználók a forrásban és a célban is frissüljenek az új targetAddress címmel. A példákban az áthelyezésben használt targetDeliveryDomain northwindtraders.onmicrosoft.com. Frissítse a levelezési felhasználókat ezzel a targetAddress címmel.
Végpontok és szervezeti kapcsolatok eltávolítása a migrálás után
A Remove-MigrationEndpoint parancsmaggal eltávolíthatja a forrás- vagy célkiszolgálók meglévő áttelepítési végpontjait az áttelepítés befejezése után.
A Remove-OrganizationRelationship parancsmaggal eltávolíthatja a forrás- vagy célkiszolgálók meglévő szervezeti kapcsolatait a migrálás befejezése után.
Gyakori kérdések
Frissíteni kell a RemoteMailboxokat a helyszíni forrásbérlőben az áthelyezés után?
Forrás Exchange-szervezet
Frissítenie kell az egyes helyszíni forrásfelhasználók targetAddress (RemoteRoutingAddress/ExternalEmailAddress) címét, amikor a forrásbérlő postaládája a célbérlőbe kerül. Bár az e-mailek útválasztása több, különböző targetAddresses címmel rendelkező e-mail-felhasználó javaslatait is képes követni, a levelezési felhasználók szabad/foglalt kereséseinek a postaláda-felhasználó helyét kell megcélzniuk.
Cél Exchange-szervezet
Miután az áttelepítés befejeződött egy hibrid szervezetben, futtassa a következő PowerShell-parancsot, ha azt szeretné, hogy a felhasználók távoli postaládákkal rendelkezzenek a helyszínen:
Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox
A Teams-értekezletek bérlők közötti áttelepítést végeznek?
A Teams-értekezletek áthelyezése közben az értekezlet URL-címe nem frissül, amikor az elemek bérlők közötti áttelepítésre kerülnek. Mivel az URL-cím érvénytelen lesz a célbérlőben, el kell távolítania és újra létre kell hoznia a Teams-értekezleteket.
Milyen tartalmak migrálása történik bérlők között?
Ha egy postaládát ezzel a funkcióval bérlők között telepít át, a rendszer csak a felhasználó által látható tartalmat telepíti át a postaládában, más néven a Top of Information Store (e-mail, névjegyek, naptár, feladatok és feljegyzések), valamint a Helyreállítható elemek mappákat Törlések, Verziók és Végleges törlés mappába.
A Kimenő üzenetek mappában lévő elemek bérlők között lesznek migrálva?
A Kimenő üzenetek mappában lévő elemek nem települnek át bérlők között, mivel ez a mappa az Outlook-ügyfélre jellemző ügyfélalapú mappa. A Kimenő üzenetek mappában lévő elemek helyileg vannak tárolva, és nem szinkronizálódnak a felhőbe.
A Teams csevegési mappájának tartalma bérlők között migrál?
Nem, a Teams csevegési mappájának tartalma nem migrál bérlők közötti áttelepítést. A postaláda bérlők közötti áttelepítése után azonban a Teams csevegési mappájának tartalma elérhető lesz a forrásbérlő rendszergazdája számára tartalomkereséssel történő kereséshez és exportáláshoz.
Hogyan láthatom csak a bérlők közötti áthelyezéseket, nem az előkészítési és a kiszállási áthelyezéseimet?
Használja a Flags paramétert :
Get-MoveRequest -Flags "CrossTenant"
Megadhat példaszkripteket a tesztelés során használt attribútumok másolásához?
Megjegyzés:
SAMPLE – AS IS, NO WARRANTY Ez a szkript feltételezi a kapcsolatot a forráspostaládával (a forrásértékek lekéréséhez) és a cél helyszíni Active Directory Domain Serviceshez (az ADUser objektum lebélyegzéséhez).
# 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
Hogyan lehet elérni az Outlookot az 1. napon a felhasználói postaláda áthelyezése után?
Mivel csak egy bérlő rendelkezhet tartománnyal, a korábbi elsődleges SMTPAddress nem lesz társítva a célbérlőben lévő felhasználóval, amikor a postaláda áthelyezése befejeződött; csak az új bérlőhöz társított tartományok. Az Outlook a felhasználó új UPN-jét használja a szolgáltatásban való hitelesítéshez, az Outlook-profil pedig arra számít, hogy az örökölt elsődleges SMTPAddress a célrendszer postaládájának megfelelő lesz. Mivel az örökölt cím nem szerepel a célrendszerben, az Outlook-profil nem fog csatlakozni az újonnan áthelyezett postaláda megkereséséhez.
A kezdeti üzembe helyezéshez a felhasználóknak újra kell építeniük a profiljukat az új EGYSZERŰ FELHASZNÁLÓNÉVvel, elsődleges SMTP-címmel és az OST-tartalom újraszinkronizálásával.
Megjegyzés:
Ennek megfelelően tervezze meg, ahogy kötegeli a felhasználókat a befejezéshez. Figyelembe kell vennie a hálózat kihasználtságát és kapacitását az Outlook-ügyfélprofilok létrehozásakor, majd az OST- és OAB-fájlok ügyfelekre való letöltésekor.
Milyen Exchange RBAC-szerepkörök tagjának kell lennem a bérlők közötti áthelyezés beállításához vagy befejezéséhez?
A szerepkörök mátrixa a postaláda áthelyezésekor a delegált feladatok feltételezésén alapul. Jelenleg két szerepkör szükséges:
- Az első szerepkör egy egyszeri beállítási feladathoz tartozik, amely meghatározza a tartalom bérlői/szervezeti határra való áthelyezésének engedélyezését. Mivel az adatok céges felügyeletből való áthelyezése minden vállalat számára kritikus fontosságú szempont, a szervezeti rendszergazda legmagasabb hozzárendelt szerepkörét választottuk. Ennek a szerepkörnek módosítania kell vagy be kell állítania egy új OrganizationRelationship tulajdonságot, amely meghatározza a
-MailboxMoveCapabilitybeállítást a távoli szervezettel. A beállítást csak a szervezet rendszergazdája módosíthatja-MailboxMoveCapability, míg az OrganizationRelationship egyéb attribútumait az összevont megosztási rendszergazda kezelheti. - A tényleges áthelyezési parancsok végrehajtásának szerepe delegálható egy alacsonyabb szintű függvénybe. A Postaládák áthelyezése szerepkör hozzá van rendelve a postaládák szervezeten belüli és kívüli áthelyezésének képességéhez.
Hogyan lehet megcélzni, hogy melyik SMTP-cím legyen kiválasztva a targetAddress (TargetDeliveryDomain) fiókhoz a konvertált postaládában (MailUser átalakításra)?
Az Exchange-postaláda az eredeti forráspostaláda targetAddress címének megadásával vált át MailUserre a célobjektumon található e-mail-cím (proxyAddress) egyeztetésével. A folyamat a parancsnak átadott értéket veszi -TargetDeliveryDomain át, majd a céloldalon keres egyező proxyt az adott tartományhoz. Ha talál egyezést, a rendszer az egyező proxyAddress paranccsal állítja be az ExternalEmailAddress (targetAddress) objektumot a konvertált postaláda (mostantól MailUser) objektumon.
Hogyan működik az e-mail-forgalom a migrálás után?
A bérlők közötti levelezési folyamat a migrálás után hasonlóan működik, mint az Exchange hibrid levelezési folyamata. Minden áttelepített postaládához a megfelelő célcímmel rendelkező mailUser forrás szükséges a bejövő levelek forrásbérlőből a célbérlő postaládáiba való továbbításához. Az átviteli szabályok, a biztonsági és a megfelelőségi funkciók az egyes bérlőkben konfigurált módon fognak futni, amelyeken az e-mailek áthaladnak. A bejövő levelek esetében tehát az olyan funkciók, mint a levélszemét elleni védelem, a kártevőirtó, a karantén, az átviteli szabályok és a naplózási szabályok először a forrásbérlőben, majd a célbérlőben futnak.
Hogyan váltanak át a postaláda-engedélyek?
A postaláda-engedélyek közé tartozik a Küldés a nevében és a Postaláda-hozzáférés:
- A Küldés más nevében (AD:publicDelegates) a felhasználó postaládájához meghatalmazottként hozzáférő címzettek DN-jét tárolja. Ez az érték az Active Directoryban van tárolva, és jelenleg nem kerül át a postaládaváltás részeként. Ha a forráspostaláda rendelkezik beállított publicDelegates beállítással, akkor a célpostaládán újra meg kell adnia a publicDelegates elemet, miután a meU-ból postaláda-átalakítás befejeződött a célkörnyezetben a következő futtatásával
Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>: . - A postaládában tárolt postaláda-engedélyek a postaládával együtt lesznek áthelyezve, amikor a rendszerbiztonsági tagot és a meghatalmazottat is áthelyezi a célrendszerbe. A TestUser 7 felhasználó példáulFullAccess-hozzáférést kap a bérlői SourceCompany.onmicrosoft.com TestUser_8 postaládához. Miután a postaláda elkészült TargetCompany.onmicrosoft.com, ugyanazok az engedélyek lesznek beállítva a célkönyvtárban. Alább láthatók a forrás- és a célbérlők TestUser_7 _Get MailboxPermission funkcióját használó példák. Az Exchange-parancsmagok előtagja ennek megfelelően a forrás és a cél.
Íme egy példa a postaláda-engedély kimenetére, mielőtt továbblép a forrásoldalról:
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
Íme egy példa a postaláda-engedély kimenetére a céloldalról való áthelyezés után:
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
Megjegyzés:
A bérlők közötti postaláda- és naptárengedélyek nem támogatottak. A rendszerbiztonsági tagokat és meghatalmazottakat összevont áthelyezési kötegekbe kell rendeznie, hogy ezek a csatlakoztatott postaládák egyszerre legyenek áttűnve a forrásbérlőből.
Milyen X500-proxyt kell hozzáadni a cél MailUser proxycímekhez az áttelepítés engedélyezéséhez?
A bérlők közötti postaláda-áttelepítéshez a forrás postaláda-objektum LegacyExchangeDN értékét x500-as e-mail-címként kell lebélyegződni a cél MailUser objektumra.
Példa:
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
Megjegyzés:
Az X500-proxyn kívül az összes X500 proxyt át kell másolnia a forrás postaládájából a célpostaládára. Bár ritkán előfordulhat, hogy egy postaláda X400-proxycímén keresztül is futhat, bár az áthelyezés végrehajtásának nem követelménye, javasoljuk, hogy ezt a címet is a célposta-felhasználói objektumra bélyegezze.
Használhatják a forrás- és a célbérlők ugyanazt a tartománynevet?
Nem, a forrásbérlő és a célbérlő tartománynevének egyedinek kell lennie, például egy contoso.com forrástartományának és a northwindtraders.com céltartományának.
Áthelyezi és továbbra is működik a megosztott postaládák?
Igen, Az áruházi engedélyeket azonban csak az ebben a cikkben leírtak szerint tartjuk meg:
Vannak kötegekre vonatkozó javaslatai?
Ne haladja meg a 2000 postaládát kötegenként. Határozottan javasoljuk, hogy a kötegeket az átállás dátuma előtt két héttel küldje el, mivel a szinkronizálás során nincs hatással a végfelhasználókra. Ha útmutatásra van szüksége az 50 000-t meghaladó postaládák mennyiségével kapcsolatban, forduljon a CSAM-hez, vagy nyisson meg egy támogatási kérést.
Mi a teendő, ha szolgáltatástitkosítást használok a Microsoft Purview ügyfélkulccsal?
A postaláda visszafejtése az áthelyezés előtt történik. Győződjön meg arról, hogy az ügyfélkulcs konfigurálva van a célbérlőben, ha még szükség van rá. További információt itt talál.
Mennyi a becsült migrálási idő?
A migrálás megtervezéséhez az itt található táblázat ismerteti azokat az irányelveket, amelyek azt ismertetik, hogy mikor várható tömeges postaláda-áttelepítés vagy egyéni áttelepítés. Ezek a becslések a korábbi ügyfélmigrálások adatelemzésén alapulnak. Mivel minden környezet egyedi, a migrálás pontos sebessége eltérő lehet.
Dokumentumok védelme a forrásbérlőben, amelyet a célbérlő felhasználói használhatnak.**
A bérlők közötti áttelepítés csak a postaládaadatokat migrálja, semmi mást. A következő blogbejegyzésben található további lehetőségek segíthetnek:
Rendelkezhetek ugyanazokkal a címkékkel a célbérlőben, mint a forrásbérlőben, akár az egyetlen címkekészletként, akár további címkekészletként az áttelepített felhasználók számára a szervezetek közötti igazítástól függően.**
Mivel a bérlők közötti migrálások nem exportálnak címkéket, és nem oszthatók meg címkék a bérlők között, ezt a célt csak úgy érheti el, ha újra létrejönnek a címkék a célbérlőben.
Támogatja a Microsoft 365-csoportok áthelyezését?
A bérlők közötti postaláda-áttelepítési funkció jelenleg nem támogatja a Microsoft 365-csoportok áttelepítését.
Végrehajthat a forrásbérlő rendszergazdája feltárási keresést egy postaládán a postaláda új/célbérlőbe való áttelepítése után?
Nem, a bérlők közötti postaláda áttelepítése után az áttelepített felhasználó postaládájának feltárása a forrásban nem működik. Az elektronikus feltárási hiba oka az, hogy a forrásban már nincs megkereshető postaláda, mivel a postaláda át lett migrálva a célbérlőbe, és most már a célbérlőhöz tartozik. A postaláda áttelepítése utáni feltárás csak a célbérlőben végezhető el (ahol a postaláda már létezik). Ha a forráspostaláda egy példányát meg kell őriznie a forrásbérlőben az áttelepítés után, a forrásbérlő rendszergazdája átmásolhatja a tartalmat egy alternatív postaláda-áttelepítés előtti postaládába az adatokkal végzett későbbi feltárási műveletekhez.
Melyik ponton lesz a CélPostafelhasználó célpostaládává, a forráspostaládát pedig forráspostaládává konvertálja a rendszer?
Ezek a konverziók automatikusan történnek a migrálási folyamat során. Nincs szükség manuális lépésekre.
Melyik lépésben rendelhetem hozzá az Exchange Online-licencet a cél MailUsershez?
Ez a licenckiosztás a migrálás befejezése előtt is elvégezhető, de az ExchangeGUID attribútum lebélyegezése előtt ne rendeljen hozzá licencet; ellenkező esetben a MailUser objektum postaláda-ra konvertálása sikertelen lesz, és helyette új postaláda jön létre. A kockázat csökkentése érdekében érdemes megvárni a migrálás befejezését, és hozzárendelni a licenceket a 30 napos türelmi időszak alatt.
A Microsoft Entra Connect használatával szinkronizálhatom a felhasználókat az új bérlőhöz, ha a helyszíni Active Directoryt megtartom?
Igen, A Microsoft Entra Connect két példánya szinkronizálható különböző bérlőkkel. Van azonban néhány dolog, amiről tisztában kell lennie:
- A felhasználó fiókjainak előzetes üzembe helyezése a cikkben megadott szkripttel nem végezhető el. Ehelyett a célbérlő feltöltéséhez a migrálás hatókörében lévő felhasználók szelektív szervezetiegység-szinkronizálása is elvégezhető. A Microsoft Entra Connect konfigurálása során figyelmeztetést fog kapni arról, hogy az UPN nem egyezik.
- A hibrid Exchange jelenlegi állapotától függően ellenőriznie kell, hogy a helyszíni címtárobjektumok megfelelően vannak-e feltöltve a szükséges attribútumokkal (például msExchMailboxGUID és proxyAddresses), mielőtt megkísérelné a szinkronizálást egy másik bérlővel; máskülönben kettős postaládákkal és migrálási hibákkal kapcsolatos problémákba ütközik.
- További lépéseket kell tennie az egyszerű felhasználónevek átvezetésének kezeléséhez, és ezt a felhasználó áttelepítésének befejezése után a helyszínen kell módosítania, kivéve, ha az egyéni tartományt is áthelyezi az átállásos áttelepítés során.
Hogyan kezelhetem a kvótához közel vagy túlterjedő postaládákat?
Az áttelepítés előtt a kvótájukhoz közelítő postaládák a tényleges áttelepítés előtt vagy közben is túlléphetik a kvótát. Ha ez történik, ezek a postaládák nem lesznek migrálva, és szervizelést és újraindítást igényelnek. Ennek csökkentése érdekében javasoljuk, hogy a forrásbérlő rendszergazdája az áttelepítés előtt azonosítsa a postaládákat a kvótánál vagy a kvóta közelében, és tegye meg a szükséges lépéseket a postaláda méretének csökkentéséhez, egy elsődleges archívum kiépítéséhez, vagy bizonyos esetekben engedélyezze az archívumok automatikus bővítését a felhasználó postaládáiban.
Megjegyzés:
Miután engedélyezte egy archív vagy automatikusan bővülő archívumot egy felhasználó számára, győződjön meg arról, hogy a megfelelő archiválási házirendek vannak alkalmazva a felhasználóra, és a folyamat lefuttatva áthelyezi a postaládaadatokat az új helyre, és helyet szabadít fel.
Áthelyezik az automatikusan kibontott archív postaládákat?
Probléma: Az automatikusan kibontott archívumok nem migrálhatók. Igen, ha a forrás felhasználója engedélyezte az automatikusan bővülő archívumokat, és további kiegészítő archívumokkal rendelkezik, a bérlők közötti postaláda-áttelepítés működni fog. A legfeljebb 12 kiegészítő archív postaládával rendelkező felhasználók áthelyezését támogatjuk. Emellett a nagy elsődleges, nagy fő archívummal és nagyméretű segédarchívum-postaládákkal rendelkező felhasználóknak további időre van szükségük a szinkronizáláshoz, és jóval az átállási dátum előtt el kell küldeni őket. Ha a postaláda áttelepítése során a forráspostaláda ki van bontva, az áttelepítés sikertelen lesz, mivel a forrásban létrejön egy új kiegészítő archívum, de a célban nem. Ebben az esetben el kell távolítania a felhasználót a kötegből, és újra el kell küldenie őket.
Végrehajthatok felhők közötti bérlői migrálást a bérlők között?
A felhőbeli bérlők közötti migrálás nem támogatott. Erre példa az Office 365 Worldwide verzióról az Office 365 Kormányzati felhőre való áttérés.
Bérlők között migrálhatók a hangposták?
Igen, a hangposta-üzenetek bérlők közötti áttelepítése.
- Az e-mailben mellékletként kapott hangpostaüzenetek a célpostaládában érhetők el.
- A beérkezett hangpostaüzenetek akkor érhetők el a Teamsben, ha hangpostát hív, és figyeli a mentett üzeneteket. (A forrásban fogadott virtuális gépek mentett üzenetekként érhetők el)
- A beérkezett hangpostaüzenetek nem érhetők el a Teams ügyfél felhasználói felületén a migrálás utáni célhelyen.
- A hangposta üdvözlőszövege is át lesz telepítve a célba.
Bérlők között migrálhatók a postaláda-aláírások?
A postaláda-aláírások nem települnek át bérlők között, ezért újra létre kell hozni.
Ismert problémák
Az áttelepítés utáni Teams-funkciók korlátozottak lesznek a forrásbérlőben. Miután áttelepítette a postaládát a célbérlőbe, a forrásbérlőben lévő Teams már nem fér hozzá a felhasználó postaládához. Ha egy felhasználó a forrás bérlői hitelesítő adatokkal jelentkezik be a Teamsbe, akkor olyan funkciók elvesznek, mint a profilképük frissítése, nincs naptáralkalmazás, és nem lehet keresni és csatlakozni a nyilvános csapatokhoz.
Cloud MailUsers with non-owned smtp proxyAddress block MRS moves. A célbérlő MailUser objektumainak létrehozásakor meg kell győződnie arról, hogy az összes SMTP-proxycím a célbérlő szervezethez tartozik. Ha olyan SMTP proxyAddress cím található a célpostafelhasználón, amely nem tartozik a helyi bérlőhöz, a MailUser postaláda-ra konvertálása nem lehetséges. Ezt a megelőzést annak a garanciánknak köszönhetjük, hogy a postaláda-objektumok csak olyan tartományokból küldhetnek leveleket, amelyek esetében a bérlő mérvadó (a bérlő által igényelt tartományok).
Ha a helyszíni felhasználókat a Microsoft Entra Connect használatával szinkronizálja a célbérlőben, akkor helyszíni MailUser-objektumokat építhet ki az ExternalEmailAddress paranccsal, amely arra a forrásbérlőre mutat, ahol a postaláda létezik (LaraN@contoso.onmicrosoft.com), és a PrimarySMTPAddress címet a célbérlőben található tartományként (Lara.Newton@northwindtraders.com) bélyegzi le. Ezek az értékek szinkronizálódnak a bérlővel, és a rendszer kiépíti a megfelelő levelezési felhasználót, és készen áll a migrálásra. Itt egy példaobjektum látható.
Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses ExternalEmailAddress EmailAddresses -------------------- -------------- SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}Megjegyzés:
A contoso.onmicrosoft.com cím nincs jelen az EmailAddresses/proxyAddresses tömbben.
A "külső" elsődleges SMTP-címmel rendelkező MailUser-objektumok "belső" vállalat által igényelt tartományokra módosulnak/állíthatók vissza.
A MailUser objektumok nem helyi postaládákra mutatnak. A bérlők közötti postaláda-áttelepítések esetében a MailUser objektumokkal jelöljük a forráspostaládát (a célszervezet szempontjából) vagy a célpostaládát (a forrásszervezet szempontjából). A MailUsers egy ExternalEmailAddress (targetAddress) címmel fog rendelkezni, amely a tényleges postaláda smtp-címére (ProxyTest@northwindtraders.onmicrosoft.com) és a primarySMTP-címre mutat, amely a postaláda-felhasználó megjelenített SMTP-címét jelöli a címtárban. Egyes szervezetek úgy döntenek, hogy az elsődleges SMTP-címet külső SMTP-címként jelenítik meg, nem pedig a helyi bérlő tulajdonában lévő/ellenőrzött címként (például northwindtraders.com és nem contoso.com). Ha azonban licencelési műveleteken keresztül alkalmaz egy Exchange szolgáltatáscsomag-objektumot a MailUserre, az elsődleges SMTP-cím úgy módosul, hogy a helyi szervezet által ellenőrzött tartományként jelenjen meg (contoso.com). Ennek két lehetséges oka lehet:
Ha egy Exchange-szolgáltatáscsomagot alkalmaz egy MailUserre, a Microsoft Entra ID-folyamat elkezdi kényszeríteni a proxytisztítást, hogy a helyi szervezet ne tudjon leveleket, hamisításokat vagy leveleket küldeni egy másik bérlőtől. Ha a helyi szervezet nem ellenőrzi a címet, az ilyen szolgáltatáscsomagokkal rendelkező címzettobjektumok SMTP-címe el lesz távolítva. Ahogy a példában is látható, a northwindtraders.com tartományt nem ellenőrzi a contoso.onmicrosoft.com bérlő; ezért a tisztítás eltávolítja a northwindtraders.com tartományt. Ha meg szeretné őrizni ezeket a külső tartományokat a MailUseren az áttelepítés előtt vagy után, az áttelepítési folyamatokat úgy kell módosítania, hogy az áthelyezés befejezése után vagy az áthelyezés előtt a licenceket eltávolítsa, hogy a felhasználók a várt külső arculatot alkalmazzák. Győződjön meg arról, hogy a postaláda-objektum megfelelő licenccel rendelkezik, hogy ne legyen hatással a levelezési szolgáltatásra. Itt látható egy példaszkript, amely eltávolítja a szolgáltatáscsomagokat a contoso.onmicrosoft.com bérlőben lévő MailUserben.
Megjegyzés:
A következő szkript a Microsoft Graph PowerShellt használja. További információ: A Microsoft Graph PowerShell áttekintése.
A különböző módszerek felügyelet nélküli szkriptekben történő hitelesítésével Connect-Graph kapcsolatos információkért tekintse meg a Hitelesítési modul parancsmagjai a Microsoft Graph PowerShellben című cikket.
# 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
A hozzárendelt ServicePlans-készlet eredményei itt jelennek meg:
$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
A felhasználó PrimarySMTPAddress tulajdonsága már nincs megtisztítva. A northwindtraders.com tartomány nem a contoso.onmicrosoft.com bérlő tulajdonában van, és a címtárban látható elsődleges SMTP-címként marad meg.
Íme egy példa:
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
Ha msExchRemoteRecipientType a 8(DeprovisionMailbox) értékre van állítva a célbérlőbe migrált helyszíni MailUsers esetében, az Azure proxytisztítási logikája eltávolítja a nem birtokolt tartományokat, és visszaállítja az elsődlegesSMTP-t egy saját tartományra. A helyszíni MailUser msExchRemoteRecipientType paraméterének törlése után a proxy-tisztítási logika már nem érvényes.
Az alábbiakban az Exchange Online-t tartalmazó aktuális szolgáltatáscsomagok teljes készlete látható:
| Name (Név) |
|---|
| Elektronikus adatok feltárása (Prémium) Tárterület (500 GB) |
| Ügyfélszéf |
| Adatveszteség-megelőzés |
| Exchange Enterprise CAL-szolgáltatások (EOP, DLP) |
| Exchange Essentials |
| Exchange Foundation |
| Exchange Online (P1) |
| Exchange Online (1. csomag) |
| Exchange Online (2. csomag) |
| Exchange Online archiválás az Exchange Online-hoz |
| Exchange Online archiválás az Exchange Serverhez |
| Az Exchange Online inaktív felhasználói bővítménye |
| Exchange Online Kioszk |
| Exchange Online Multi-Geo |
| Exchange Online 1. csomag |
| Exchange Online POP |
| Exchange Online Védelmi szolgáltatás |
| Graph Connectors Search with Index |
| Szervezeten belüli elkülönítések |
| Information Protection for Office 365 – Premium |
| Information Protection for Office 365 – Standard |
| A MyAnalytics elemzései |
| Microsoft Information Governance |
| Microsoft Purview-naplózás (prémium) |
| Microsoft-előjegyzések |
| Microsoft Business Center |
| Microsoft-adatvizsgálatok |
| Microsoft MyAnalytics (teljes) |
| A Microsoft Communications megfelelősége |
| Microsoft Communications DLP |
| Microsoft ügyfélkulcs |
| Microsoft 365 Speciális naplózás |
| Microsoft Records Management |
| Office 365 elektronikus adatfeltárás (Prémium) |
| Bővített elektronikus adatfeltárás az Office 365-ben |
| Office 365-höz készült Microsoft Defender (1. csomag) |
| Office 365-höz készült Microsoft Defender (2. csomag) |
| Office 365 Privileged Access Management |
| Prémium szintű titkosítás az Office 365-ben |
Migrálási hibák
MailboxNotInCrossTenantMigrationScopeException
Győződjön meg arról, hogy az áttelepítési hatókör megfelelően van beállítva a forrásbérlőn, és hogy a MailboxMovesPublishedScopes be van állítva a célbérlővel fennálló szervezeti kapcsolatban.
Ellenőrizze, hogy az áttelepítendő postaláda hozzá lett-e adva a forrásbérlő biztonsági csoportjához.
Miután hozzáadta a felhasználót a megfelelő biztonsági csoporthoz, folytassa az áttelepítési köteget.AuxArchiveNotFoundInTargetRecipientException
Ennek a hibának az az oka, hogy a felhasználó nem volt a migrálási hatókörben a köteg elindításakor, és a felhasználó AuxArchive tulajdonsága van a forráson.
Adja hozzá a felhasználót a megfelelő biztonsági csoporthoz a forráscélon.
Távolítsa el az áttelepítési felhasználót a kötegből.
Távolítsa el a felhasználókat a következő paranccsal:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFelhasználó hozzáadása az új köteghez.
MailboxIsNotInExpectedDBException
Ezt a hibát a Microsoft belső karbantartása okozza.
Távolítsa el az áttelepítési felhasználót a kötegből.
Távolítsa el a felhasználókat a következő paranccsal:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFelhasználó hozzáadása az új köteghez.
NotAcceptedDomainException
Érvénytelen proxycím van lebélyegzve a célfelhasználóra. Ilyen lehet például, ha egy contoso.onmicrosoft.com felhasználó proxycíme fabrikam.onmicrosoft.com, amely a forrásbérlő.
Távolítsa el az érvénytelen proxycímet a következő paranccsal:Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}Folytassa az áttelepítési köteget.
SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException
A migrálás során új AuxArchive lett kiépítve.
Távolítsa el az áttelepítési felhasználót a kötegből.
Távolítsa el a felhasználókat a következő paranccsal:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFelhasználó hozzáadása az új köteghez.
UserDuplicateInOtherBatchException
A felhasználó már létezik egy másik kötegben.
Távolítsa el az áttelepítési felhasználót a kötegből.
Távolítsa el a felhasználókat a következő paranccsal:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFelhasználó hozzáadása az új köteghez.
MissingExchangeGuidException
A cél mailuser objektumból hiányzik a megfelelő ExchangeGuid érték.
Frissítse az ExchangeGuid műveletet a következő paranccsal:Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8A migrálási köteg folytatása.
SourceMailboxAlreadyBeingMovedPermanentException
A forráspostaláda már rendelkezik egy meglévő áthelyezési kérelemmel. Vizsgálja meg és távolítsa el a meglévő áthelyezést. Lehetséges, hogy ez egy belső Microsoft-áthelyezés, és meg kell várnia, amíg az áthelyezés befejeződik.
Távolítsa el az áttelepítési felhasználót a kötegből.
Távolítsa el a felhasználókat a következő paranccsal:Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUserFelhasználó hozzáadása az új köteghez az eredeti áthelyezés eltávolítása vagy befejezése után.
UserAlreadyHasDemotedArchiveException
A felhasználó korábban letiltott archív postaládával rendelkezett. A probléma megoldásához válassza az alábbi két lehetőség egyikét.
Véglegesen törölje a letiltott archív postaládát, ez nem visszafordítható. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
Engedélyezze újra a letiltott archív postaládát a következő paranccsal:Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.Ha újra engedélyezi a letiltott archív postaládát, frissítenie kell az archív GUID azonosítót a cél mailuser objektumon.
A migrálási köteg folytatása.
Lásd még
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: