After the sale of a large part of a company, the new owner wanted a quick adjustment to the email addresses for both internal and, more importantly, external communication for existing employees. Further domain migrations will occur in a later phase, but for the first phase, the message was as clear as it was challenging: 1700 users, same AD domain, new mail domain. <\/p>\n
Since the full migration scope spans a forest of about 15 domains, step one was determining which 1700 of the 2500 users to ensure that only they received the new email address and that it would be clear for further phases who to migrate or not. To make as few changes to the domain as possible, we chose not to create groups or OUs to mark users as ‘to be migrated’. We opted to populate msDS-cloudExtensionAttribute19 with a specific value, making it clear everywhere, both on-premises and in the cloud. Given that local Service Desks had rights to modify this attribute in AD for ‘their’ users, this task was performed by them. This was already an important step in the process. <\/p>\n
The next step was to come up with the necessary funds to purchase a new O365 tenant from Microsoft. Since the new owner already had on-premises mail and thus their own mail server with corresponding MX record (let’s say @company.com), we chose to register @companycloud.onmicrosoft.com with Microsoft. In a much later phase, the on-premises mail users of @company.com will also be transferred to @companycloud.onmicrosoft.com, but to keep these separate at this time, we chose this name for the O365 tenant. <\/p>\n
With everything ready to effectively transfer the users, we could start creating users in our new O365 tenant. For this, an Azure AD Connect server was installed next to the on-premises AD of the previous company. This was configured to synchronize all users with the cloudExtensionAttribute19 filled with the correct value to the new tenant. When creating users in the Azure AD of companycloud, an empty mailbox was immediately created. The same approach was used for shared mailboxes; these were listed and then created as empty mailboxes on the new tenant. About 250 groups were created via PowerShell. Since all users were already known on the new tenant by this time, we could populate the groups with the right users and ensure that after migration, the right people had access to the shared mailboxes. <\/p>\n
With all these preparations carefully executed, we slowly approached the big day when the end-user would be converted, and he or she could use the new @company.com address instead of their old email address. In a busy weekend, all emails from the mailboxes of the previous company were copied to the new empty mailboxes on the new tenant, but that wasn’t all. Of course, all Teams groups (with chat history), SharePoint sites, and OneDrives were also copied. Simultaneously, crucial actions were carried out on two other fronts, as it’s not the intention to have emails sent to their companycloud-tenant address. To get the emails sent to their new @company address into their mailbox, mail contacts were created on-premises at company to deliver all emails sent to name@company.com to name@companycloud.onmicrosoft.com. To ensure they send with the correct email address, the SMTP address in their AD account was changed to their company.com address. On the Sunday of that weekend, some IT people were already asked to take the necessary steps on their PC to use their new mail accounts. This way, these people were prepared to guide the end-user in the adjustments needed on their PC in the following days. <\/p>\n
The steps the end-user needed to perform on their PC were put into a nice script beforehand, which was placed on the desktop of all PCs via SCCM. This way, the end-user could simply double-click on the migration icon, and all personal address books, tasks, archives, along with any personal PST files were transferred to a temporary folder. This was followed by an automatic complete log-off from Outlook, Teams, and OneDrive. The PC was also restarted for safety, and people could log in again, still with their original user, because as mentioned, the AD domain was not changed. They were then asked to start Outlook and log in with their new email address and the same password (AD sync). By performing an MFA setup, their PC became hybrid joined to the new tenant, and from that moment on, they could use Outlook, Teams, and OneDrive without having to log in constantly. <\/p>\n
After some testing and transferring a few users who were overlooked in the initial list, along with some missing Teams and OneDrive files, we could conclude after a few intense weeks that we had a successful migration behind us. On to the next project to migrate the domain itself. I’m looking forward to it… \ud83d\ude0a <\/p>\n
Written by: Dimitri M.<\/p>\n","protected":false},"excerpt":{"rendered":"
After the sale of a large part of a company, the new owner wanted a quick adjustment to the email addresses for both internal and, more importantly, external communication for existing employees. Further domain migrations will occur in a later phase, but for the first phase, the message was as…<\/span><\/p>\n","protected":false},"author":2,"featured_media":18432,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[243,244],"tags":[247,289,334],"class_list":["post-21321","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-en","category-ict-en","tag-connect-consulting-en","tag-ict-en","tag-o365-migration"],"acf":[],"yoast_head":"\n