Na de verkoop van een groot deel van een bedrijf wou de nieuwe eigenaar dat er heel snel voor de bestaande werknemers een aanpassing zou komen van de mailadressen voor zowel de interne, maar nog belangrijker, de externe communicatie. In een latere fase zullen verdere domein-migraties gebeuren, maar voor de eerste fase was de boodschap even duidelijk als uitdagend: 1700 gebruikers, zelfde AD domein, nieuw maildomein.

Aangezien de volledige migratiescope zich over een forest van een 15-tal domeinen verspreidt, was stap één het bepalen van welke 1700 van de 2500 gebruikers om zeker te zijn dat enkel zij het nieuwe mailadres kregen en ook voor verdere fases duidelijk zou zijn wie wel of niet te migreren. Om zo weinig mogelijk wijzigingen in het domein aan te brengen, kozen we ervoor om geen groepen of OU’s aan te maken om de gebruikers te markeren als zijnde ‘te migreren’. We kozen ervoor om msDS-cloudExtensionAttribute19 in te vullen met een bepaalde waarde, zo is het overal, zowel on prem als in de cloud duidelijk. Gezien de lokale Service Desks rechten hadden om dit attribuut in AD aan te passen voor ‘hun’ gebruikers, werd deze taak door hun uitgevoerd. Daarmee was al een belangrijke stap gezet in het proces.

De volgende stap was om met de nodige centen over de brug te komen om een nieuwe O365-tenant aan te kopen bij Microsoft. Aangezien de nieuwe eigenaar zelf al een on prem mail had en dus hun eigen mailserver met bijhorend MX-record (laten we zeggen @company.com), kozen we er voor om @companycloud.onmicrosoft.com te registeren bij Microsoft. In een veel latere fase zullen de on prem mailusers van @company.com ook overgezet worden naar @companycloud.onmicrosoft.com, maar om deze op dit moment nog gescheiden te houden, kozen we voor deze naam voor de O365-tenant.

Nu alles klaar staan om de gebruikers effectief over te zetten konden we aan de slag om de gebruikers aan te maken in onze nieuwe O365-tenant, daarvoor werd naast de on prem AD van het vorige bedrijf een Azure AD Connect server geïnstalleerd, deze werd zo geconfigureerd om alle gebruikers, met het cloudExtensionAttribuut19 ingevuld met de juiste waarde te synchroniseren naar de nieuwe tenant. Bij de aanmaak van de gebruikers in de Azure AD van companycloud werd ook onmiddellijk een lege mailbox aangemaakt. Voor de gedeelde mailboxen werd net dezelfde aanpak gebruikt, deze werden opgelijst en werden dan ook als lege mailboxen aangemaakt op de nieuwe tenant. Via Powershell werden nog een 250-tal groepen aangemaakt. Aangezien ondertussen alle gebruikers al gekend waren op de nieuwe tenant konden we de groepen al bevolken met de juiste gebruikers en er voor zorgen dat na de migratie de juiste mensen ook al toegang hadden tot de gedeelde mailboxen.

Met al deze voorbereidingen zorgvuldig uitgevoerd, kwamen we stilletjes aan bij de grote dag waarop de eindgebruiker zelf zou omgezet worden, en hij of zij dus in plaats van zijn oude emailadres, het nieuwe @company.com adres zou kunnen gebruiken. In een druk weekend werden alle mails uit de mailboxen van het vorige bedrijf over gekopieerd naar de nieuwe lege mailboxen op de nieuwe tenant, maar daar bleef het niet bij. Uiteraard werden ook alle Teams-groepen (met chatgeschiedenis), Sharepointsites en OneDrives over gekopieerd. Tegelijkertijd werd op 2 andere fronten ook nog broodnodige acties uitgevoerd, het is natuurlijk niet de bedoeling dat naar hun companycloud-tenant adres zou gemaild worden. Om de mails die naar hun nieuw @company adres gestuurd werden, in hun mailbox te krijgen, werden op de on prem van company mail contacts aangemaakt om alle mails die naar naam@company.com gestuurd werden af te leveren bij naam@compaycloud.onmicrosoft.com. Om er voor te zorgen dat ze met het juiste mail adres uit sturen werd het SMTP-adres in hun AD-account aangepast naar hun company.com adres. De zondag van dat weekend werden ook al enkele IT-mensen gevraagd om op hun PC de nodige stappen te doen om zo hun nieuwe mail-accounts te kunnen gebruiken. Op die manier werden deze mensen dan ook klaargestoomd om de dagen erna de eindgebruiker te begeleiden in de aanpassingen die nodig waren op hun PC.

De stappen die de eindgebruiker diende uit te voeren op zijn of haar pc werden op voorhand in een mooi script gegoten dat via SSCM op het bureaublad van alle pc’s werd geplaatst. Zo kon de eindgebruiker gewoon dubbelklikken op het migratie-icoontje en werden alle persoonlijke adresboeken, taken, archieven, samen met eventuele persoonlijke PST bestanden overgezet naar een tijdelijke map. Daarna volgde een automatische complete log-off uit Outlook, Teams en OneDrive. Ook werd de pc voor alle zekerheid herstart en konden de mensen opnieuw aanmelden, nog steeds met hun originele gebruiker, want zoals gezegd, het AD domain werd niet gewijzigd. Daarna werd hen gevraagd om Outlook te starten en aan te melden met hun nieuwe mailadres en zelfde paswoord (AD sync), door een MFA setup uit te voeren werd hun pc hybrid joined op de nieuwe tenant en konden ze vanaf dat moment Outlook, Teams en OneDrive gebruiker zonder steeds te moeten aanmelden.

Na wat testwerk en het overzetten van enkele gebruikers die in de initiële lijst over het hoofd werden gezien, samen met enkele ontbrekende Teams en OneDrive bestanden, konden we na enkele intense weken concluderen dat we een succesvolle migratie achter de rug hadden. Op naar het volgende project om het domein zelf te migreren. Ik kijk er naar uit … 😊