Indeholder illustrationer skabt med AI
En mailbox migration til Microsoft 365 kræver mere end at oprette nye Outlook-konti. I skal vælge den rigtige migrationsmetode, kontrollere licenser og sikre, at brugernes identiteter matcher korrekt.
En god plan begrænser risikoen for mistede mails, forkerte DNS-poster og afbrudt kommunikation. Her får I en praktisk model til både simple IMAP-flytninger og mere krævende cross-tenant mailbox migration.
Det vigtigste at tage med
- Vælg migrationsmetode ud fra jeres nuværende mailsystem, ikke kun antallet af postkasser.
- En cross-tenant-flytning kræver blandt andet en aktiv kildepostkasse og korrekt konfiguration af målmiljøet.
- Flyt ikke MX-posterne, før test, sidste synkronisering og brugerklargøring er gennemført.
- IMAP flytter kun e-mails. Kontakter, kalenderaftaler og opgaver kræver en anden metode.
- Planlæg altid en kontrolfase efter overgangen, hvor mail flow, Outlook-profiler, mobile enheder og sikkerhed bliver testet. En kort, planlagt afbrydelse kan være nødvendig, så lov ikke garanteret zero downtime.
Start med at vælge den rigtige migrationsmetode
Den tekniske løsning til en mailbox migration afhænger af, hvor mails ligger i dag. Den afhænger også af, om brugerne skal arbejde i to miljøer under overgangen. En mindre virksomhed med et almindeligt IMAP-hostet mailsystem har ikke de samme krav som en koncern, der flytter mellem to Microsoft 365-tenants, tidligere omtalt som Office 365.
Cross-tenant mailbox migration
En cross-tenant mailbox migration passer til en flytning mellem to Microsoft 365-organisationer. Det kan for eksempel være relevant ved virksomhedskøb, fusioner eller en opsplitning af en eksisterende tenant.
Metoden bevarer postkassens data bedre end en simpel eksport og import. Kildepostkassen skal være aktiv. I måltenanten skal brugeren først være et MailUser uden en provisioneret postkasse.
Der kræves en migration application, et migration endpoint og en organization relationship. Kilde- og måltenanten skal have en korrekt organization relationship, før flytningen kan begynde.
Kilde- og målobjektet forbindes blandt andet med ExchangeGUID, targetAddress, tenant ID, primary SMTP address og LegacyExchangeDN. Identitetsmappingen skal være korrekt, så den rigtige bruger og postkasse kobles sammen.
Cutover, staged eller hybrid migration
En cutover migration flytter typisk alle postkasser i en samlet overgang. Den kan passe til mindre miljøer, hvor organisationen kan acceptere et planlagt skift på et bestemt tidspunkt.
En staged migration opdeler flytningen i mindre grupper. Det giver bedre kontrol, men kræver mere planlægning af mailflow og brugere. En hybrid migration er ofte relevant, når Exchange Server og Exchange Online skal fungere sammen i en periode.
For mange små og mellemstore virksomheder er en styret batchmigration mere praktisk end en stor engangsændring. En mailbox migration kan begynde med få brugere, så I kan teste, rette problemer og fortsætte med næste gruppe.
Datamængden og postkassetyperne bør også indgå i metodevalget. Vurder for eksempel, om der findes en archive mailbox, og om den valgte license understøtter den planlagte løsning.
Hvornår IMAP er nok
IMAP kan være en enkel løsning, hvis mailsystemet ikke er baseret på Exchange. En IMAP migration kan hente e-mails fra en ekstern udbyder og placere dem i Exchange Online.
Begrænsningen er vigtig: IMAP flytter ikke kontakter, kalenderaftaler eller opgaver. Det fremgår også af IMAP-migrationens begrænsninger. Hvis medarbejderne bruger kalenderen aktivt, skal I planlægge en separat dataflytning.
Forberedelse før en mailmigration Microsoft 365
En mailmigration bør begynde med en opgørelse, ikke med en DNS-ændring. Skriv alle postkasser, aliaser, delte postkasser, mobilbrugere, videresendelser og systemer med afsenderadgang ned.
Kortlæg data, domæner og licenser
Registrér postkassernes størrelse, antal brugere og særlige krav. Notér også, om en postkasse har et archive mailbox, og om data skal håndteres gennem en IMAP migration.
Brug Microsoft Entra ID og admin center til at skabe overblik over brugere, tenant ID og licenser. En security group og en organization relationship kan også blive relevante i et cross-tenant-forløb.
Ved en cross-tenant mailbox migration skal brugerne have relevante Exchange Online-abonnementer. Der kræves en Cross-Tenant User Data Migration license pr. bruger, der flyttes. En license er den tekniske betegnelse for denne licens, som beskrives som et engangsgebyr. Kontrollér derfor, at den rigtige license er knyttet til hver bruger. Shared mailboxes og resource- eller room-mailboxes er omfattet af andre regler end almindelige brugerpostkasser.
Licenser bør afklares tidligt, men den endelige Exchange Online-licens til målbrugeren skal normalt først tildeles, når MailUser-objektet og identitetsdataene er klargjort. Rådgivning om Microsoft 365-licenser kan være relevant, hvis I er usikre på kombinationen af abonnementer og migrationslicenser.
Klargør kilde og mål
Kildepostkassen skal være tilgængelig under migreringen. Målbrugeren skal oprettes som MailUser uden en provisioneret postkasse, og målobjektet må ikke allerede have en ny, tom postkasse.
Saml værdierne for ExchangeGUID og LegacyExchangeDN fra kilden. Kontrollér samtidig primary SMTP address, aliaser, targetAddress og eksisterende x500-adresser. Dokumentér også ExchangeGUID på målobjektet, før attributterne ændres.
Kontrollér, at målobjektet fortsat er et MailUser, og at targetAddress peger korrekt. Sammenhold ExchangeGUID og LegacyExchangeDN med kildens oplysninger, og gem en kopi, før I ændrer objekterne.
Tag også backup af kritiske mails, og dokumentér den eksisterende opsætning. En mailbox migration er ikke en erstatning for backup. Den gør det lettere at genskabe adgang, hvis en bruger eller en regel er konfigureret forkert.
Konfiguration af Microsoft 365 og Exchange Online
Når planlægningen er på plads, kommer den tekniske opsætning af en cross-tenant mailbox migration. Det er her, mange fejl opstår, fordi to tenants, flere identiteter og forskellige tilladelser skal passe sammen.
Opret migration application i Microsoft Entra ID
I måltenanten opretter administratoren en migration application i Microsoft Entra ID. Applikationen får de nødvendige API-tilladelser til en mailbox migration. Der oprettes også en client secret, som skal håndteres sikkert og have en planlagt udløbsdato.
Dokumentér application ID, tenant ID, secretens udløb og de personer, der må ændre opsætningen. Brug ikke en personlig administratorkonto som eneste afhængighed. En udløbet secret kan stoppe nye batches, selv om de øvrige indstillinger er korrekte.
Opret migration endpoint og organization relationship
I Exchange Online PowerShell oprettes et migration endpoint, som beskriver forbindelsen til den anden organisation. Kommandoen New-MigrationEndpoint indgår typisk i denne del. Kontrollér både kildeorganisationens tenant ID og målorganisationens tenant ID, før forbindelsen gemmes.
Derefter oprettes en organization relationship mellem kilde- og måltenant. Den styrer, hvilke organisationer der må udføre mailbox moves, og hvilke tilladelser der gælder. En mail-enabled security group i kildetenanten bruges ofte til at begrænse, hvilke brugere der er omfattet.
Forholdet mellem kilde og mål beskrives i organisationens organization relationship. Det skal fremgå tydeligt, hvilken tenant der leverer postkasserne, og hvilken tenant der modtager dem. En security group kan samtidig begrænse migreringen til en afgrænset brugergruppe.
Kommandoer som New-OrganizationRelationship og New-MigrationBatch kan bruges i forløbet. Kontrollér organization relationship i Exchange Online, før den første migration batch startes. Indsæt altid jeres egne tenant ID’er, app-id’er, URL’er og security group i PowerShell-kommandoerne.
Dokumentér organisationens værdier, og brug organisationens organization relationship som kontrolpunkt før produktion. Det gør fejlsikring lettere, hvis en tilladelse, et endpoint eller en identitet ikke matcher. Kommandoerne er illustrative og skal tilpasses det konkrete miljø.
Få ExchangeGUID og LegacyExchangeDN til at passe
ExchangeGUID skal matche mellem kildepostkassen og målobjektet. Hvis værdien mangler eller er forkert, kan flytningen stoppe, selv om brugeren kan logge ind i Exchange Online. Kontrollér også, at tenant ID og målobjektets identitet peger på den rigtige organisation.
Kildens LegacyExchangeDN skal tilføjes som en x500-proxyadresse på målobjektet. Eksisterende x500-adresser skal bevares, fordi de kan bruges i gamle mails, kalenderinvitationer og autofuldførelse i Outlook. Det gælder også ved flytninger fra Exchange Server til Exchange Online.
Identitetsmappingen bør bruge MailUser, targetAddress, ExchangeGUID og LegacyExchangeDN. Kontrollér samtidig targetAddress og primary SMTP address på objektet, før brugeren flyttes. Et MailUser-objekt skal pege korrekt på målpostkassen, uden at den endelige postkasse er klargjort for tidligt.
Rækkefølgen er vigtig: Opret MailUser, overfør ExchangeGUID og LegacyExchangeDN, kontrollér proxyadresserne, og tildel derefter den endelige Exchange Online-license. En license giver adgang til tjenesterne, men opretter ikke i sig selv et korrekt MailUser-objekt.
Tildel først den endelige license, når identiteten er kontrolleret. En for tidlig license kan klargøre målpostkassen for tidligt og blokere det planlagte migrationsforløb. Kontrollér derfor MailUser-objektet, ExchangeGUID og LegacyExchangeDN, før den sidste license tildeles.
Gennemfør migrationen med test og delta-synkronisering
Selve en mailbox migration bør foregå i kontrollerede trin. Ved en cross-tenant mailbox migration skal du begynde med en lille testgruppe, der repræsenterer forskellige roller, postkassestørrelser og enheder.
Kør en testbatch først
Opret en første migration batch med en eller to brugere fra en afgrænset security group. Gruppen bør indeholde almindelige postkasser og mindst én bruger med særlige aliaser eller mobiladgang.
Kontrollér før start, at targetAddress, LegacyExchangeDN, tenant ID og organisationens organization relationship er korrekt konfigureret. Bekræft også, at en eventuel archive mailbox, den nødvendige license og relevante arkivdata er omfattet af testen.
Kontrollér derefter, at mails, mapper, kalender og Outlook-forbindelse fungerer i målmiljøet i Exchange Online. Test også indgående og udgående mail, interne mails, svar på gamle beskeder og adgang fra mobiltelefoner.
Brugerne skal vide, hvor de logger ind, og hvad de skal gøre, hvis Outlook beder om godkendelse igen.
Brug initial synkronisering og delta
Den første synkronisering kopierer den eksisterende postkasse. Brugerne kan ofte fortsætte arbejdet i denne periode, men nye mails og ændringer skal synkroniseres igen tæt på overgangen.
Planlæg derfor en sidste delta-synkronisering, også kaldet en delta migration. Den kopierer ændringer, der er kommet efter den første synkronisering. Det reducerer datatab, men giver ikke nødvendigvis zero downtime.
Aftal et kort tidspunkt, hvor brugerne ikke ændrer vigtige mails eller kalenderdata. DNS-cache og brugeradfærd kan stadig påvirke overgangen.
Skift MX på det rigtige tidspunkt
Når testgruppen er godkendt, kan du planlægge den produktionsklare migration batch. Gennemfør den som en cutover migration, når målpostkasserne er klar, sidste synkronisering er afsluttet, og brugerne er informeret.
MX records bestemmer, hvor nye mails leveres. Flyt dem først, når de øvrige DNS records er klar til ændringen. DNS-opslag bliver cachet, og TTL-feltet bestemmer, hvor længe et DNS-svar kan ligge i cachen, og dermed hvor hurtigt en ændring slår igennem. Cloudflares forklaring af TTL i DNS beskriver denne sammenhæng.
Kontrollér også SPF, DKIM, DMARC, autodiscover og eventuelle tredjepartssystemer efter MX-skiftet. Test mail flow fra en ekstern adresse, en intern adresse og de vigtigste systemer, der sender på virksomhedens vegne.
Fejlfinding ved typiske migrationsfejl
De fleste problemer skyldes identitetsdata, licenser, kvoter eller forkert rækkefølge. Ved en mailbox migration til Microsoft 365 og Exchange Online skal I gemme fejlene fra migration batch, så fejlfindingen bygger på konkrete data.
Manglende ExchangeGUID eller forkert MailUser
Ved en fejl i ExchangeGUID skal I følge en fast kontrolrækkefølge. Sammenlign først kildepostkassens ExchangeGUID med målobjektets værdi.
Kontrollér derefter, at målobjektet er et MailUser, at targetAddress peger korrekt, og at primary SMTP address matcher. Sammenlign også LegacyExchangeDN med kildeobjektet. Brug eventuelt PowerShell til at kontrollere attributterne. Bekræft til sidst, at ExchangeGUID stadig er korrekt, og at LegacyExchangeDN ikke er blevet ændret.
Hvis målpostkassen allerede er oprettet, bør I stoppe og vurdere objektets tilstand, før I sletter eller ændrer noget. Dokumentér proxyadresser og øvrige attributter først, da en hurtig oprydning kan fjerne data, der senere skal bruges.
Ved fejl med adgang eller forbindelse skal I kontrollere tenant ID og den relevante organization relationship. Kontrollér også, om tilladelserne gælder for den rigtige bruger eller gruppe.
Over quota eller ufuldstændige data
En over quota-fejl kan skyldes manglende kapacitet, en forkert tildelt license eller store datamængder. Kontrollér også, om en archive mailbox er nødvendig, og gennemgå store mapper, vedhæftninger og gamle elementer.
Hvis problemet kun rammer bestemte brugere, skal I kontrollere brugeromfanget og eventuelle tilladelser i den relevante security group. Gennemgå derefter næste batch, før flere postkasser flyttes.
Ved IMAP migration skal I kontrollere resultatet ekstra grundigt. E-mails kan være flyttet, mens kalender, kontakter og opgaver stadig ligger i det gamle system. Planlæg den del separat i stedet for at antage, at migrationen har taget alt med.
Afslut med at kontrollere mail flow, så I ved, om fejlen påvirker indgående, udgående eller intern post.
Ofte stillede spørgsmål
Hvilke licenser kræver en cross-tenant migration?
Ved en cross-tenant mailbox migration skal brugerne have relevante abonnementer i Microsoft 365. Hver bruger, der flyttes, skal have en Cross-Tenant User Data Migration-license. Exchange Online-abonnementet er en separat license, og shared mailboxes samt resource-mailboxes følger andre license-regler end almindelige brugerpostkasser.
Hvilke attributter skal matche?
Målobjektet skal være en MailUser og må ikke allerede være en provisioneret postkasse. ExchangeGUID skal matche mellem kilde og mål, mens targetAddress skal pege på den tilsvarende postkasse i måltenanten. Kildens LegacyExchangeDN skal føjes til målobjektet som en x500-proxyadresse, og den samme LegacyExchangeDN skal bevares for at sikre korrekt identitetsmapping. Den primære primary SMTP address og aliaser skal også kontrolleres.
Hvad skal oprettes i Microsoft Entra ID?
I Microsoft Entra ID opretter I en migrationsapplikation og en client secret med de nødvendige tilladelser. Dokumentér både kildens tenant ID og måltenantens tenant ID, før I konfigurerer forbindelsen. Opret derefter migration endpoint og organization relationship i Exchange Online. Begræns eventuelt adgangen med en security group, og kontrollér, at begge tenants tillader den planlagte flytning.
Hvornår bør en virksomhed få hjælp udefra?
Hvis I mangler intern Exchange-kompetence, har flere domæner eller skal flytte mellem tenants, kan en erfaren partner reducere risikoen. En fast IT Serviceaftale eller Ekstern IT Support kan sikre hjælp til brugerkommunikation, test og drift efter skiftet. For nogle virksomheder er Outsourcing af it til et lokalt IT firma en bedre løsning end at håndtere migrationen alene.
Når mailmigrationen er gennemført
En vellykket mailbox migration til Microsoft 365 slutter ikke, når MX-posten er ændret. Kontrollér mail flow i Exchange Online samt Outlook, mobile enheder, delte postkasser, regler, signaturer og systemintegrationer de første dage efter overgangen.
Dokumentér den nye Microsoft 365-platform, tidligere kendt som Office 365, samt targetAddress, Microsoft Entra ID, license og migration batch efter en cross-tenant mailbox migration. Kontrollér også, at archive mailbox og backupforhold er dokumenteret. Når driften er stabil, kan I arbejde videre med Microsoft 365-migrering og support samt beskyttelse af følsom kommunikation med sikker e-mail med kryptering.
Den bedste migration er den, brugerne næsten ikke bemærker. Det kræver ikke et risikabelt hastværk, men korrekt identitetsmapping, en testet overgang og en plan for tiden efter.