Latest posts by Paul Schnackenburg (see all)
- Azure Data Lake overview - Fri, Sep 22 2017
- Moving from Office 365 to on-premises Exchange - Tue, Sep 19 2017
- Office 365 Secure Score – Securing Exchange Online - Thu, Aug 3 2017
This small business had no on-premises infrastructure, just a Windows server hosted in a public cloud running Active Directory and file services along with a few line-of-business (LOB) applications. And all of their collaboration was through Office 365.
The heavy mail user profile ^
Veterans in the Exchange server space will remember the challenges in sizing servers, where you could fit 500 "light" mail users on a server, or 100 "heavy" users. And of course, users don't fit in predefined boxes nor do they change their habits, making sizing difficult at the best of times.
After an initial outline by the client's IT department, it seemed like moving these few users should be a fairly easy process. After all, how difficult could it be with only a handful of users? When I met with the actual users and started investigating how they use Exchange and Outlook, I realized that it would be a bit more challenging. This business is a recruitment agency, linking job seekers with open positions. They rely on a third-party Outlook add-in (Fasttrack) that links applications to jobs in the database behind the scenes. The first challenge was to make sure this add-in continued to work after the migration.
The second challenge was the size of the mailboxes; with generous limits in Office 365, they had accumulated quite a horde of emails from the last 10 years. After a clean-up and archiving to shared PST files of the really old stuff, the largest mailbox was still 12 GB with the rest around 8 GB—not huge but still a factor for download speeds.
The third challenge was that they were also going to add two new email domains, along with needing to point their existing domain from Office 365 to the on-premises server. The business relies on an external spam-filtering service from Symantec. Thus, I had to add the new email domains to DNS and the spam-filtering solution.
The fourth issue was that they didn't just have individual mailboxes; they also had several ordinary user mailboxes that they were sharing amongst several users. In addition, they had a large collection of signatures they picked from manually when sending out emails, depending on which address they were sending from.
Their requirements were also specific. I couldn't just assign multiple email addresses to a single user mailbox because the users had to be able to pick which email address to send a new email from. And they could only do that using separate mailboxes. (I found an application that does allow this from a single mailbox: ChooseFrom/SmartReply, but the cost and risk of running third-party software on the Exchange infrastructure was too high.)
The plan ^
Planning is vital, especially for a business that's very reliant on email. The plan was:
- Set up user mailboxes on the on-premises Exchange server for each user.
- Set up shared mailboxes for all individual users in the two additional email domains so they pick "send from" when creating a new email, thus making sure any replies end up in the right inbox.
- Do the migration over a weekend and create forwarding rules from the Office 365 mailboxes to the Exchange server so that no email is lost.
- Download the content of each Office 365 mailbox in a PST file and import it into the corresponding email inbox in Exchange.
- Set up new Outlook profiles for each user with the right mailboxes added, leaving the current profiles so that users could go back to check their existing mailboxes if necessary.
- Test each step first with a test account in Office 365 and a test mailbox on premises.
There were two options for getting the existing email/calendar/notes/task data out of Office 365. (Microsoft doesn't really make this step that easy; I wonder why?) I considered a third-party application from Lepide, but in the end, I opted for using built-in tools. This always makes me less worried because if there's a problem, at least I've only got to talk to Microsoft support.
The migration ^
The built-in method relies on eDiscovery to do a search of all data in a mailbox. We then export it to a PST file, which we then download. The steps are:
- Go to https://outlook.office365.com/ecp as an O365 administrator.
- Click on Permissions, admin roles, and then double-click on Discovery Management.
- Under Roles, click the + button, find Mailbox Import Export, and add it to the role.
- Under Members, add yourself to the role. (Global Administrators in Office 365 do not have this role by default.)
- Click compliance management in EAC and pick in-place eDiscovery & hold. (Note that this functionality will move from the EAC and the SharePoint management console in the near future to the consolidated console at https://protection.office.com/.)
- Click the + sign to add a new search, give it a name, and click Next.
- Pick a mailbox. (I did each mailbox individually as that gave me some control over the download phase, but you can do multiple mailboxes in one search.)
- On the next screen, you can optionally filter based on dates, sender, etc. I chose all content.
- The next screen allows you to set legal hold; this is not required for this scenario.
- Finish will start the process in Office 365 of going through the entire mailbox and then gathering all the information into a PST file.
- Clicking the download button will install the eDiscovery PST Export Tool and ask you where you'd like to download the PST file. For this project, I chose not to enable deduplication and to include unsearchable items. After I clicked download, the project presented me with a string as a secure key to enter in the download tool. When I ran the same tool recently writing this article, it asked me for credentials instead. Note that if you have two-factor authentication (2FA) turned on for your account, you'll need to enter your app password for Outlook, not your ordinary password for Office 365.
- After downloading the PST for each mailbox, open an administrative PowerShell Exchange Shell on the Exchange server.
- The New-MailboxImportRequest only takes a universal naming convention (UNC) path to the PST file to import, so you'll need to share the folder where you've downloaded the files. Run:
New-MailboxImportRequest -FilePath "\\Exch13\Exports\Test\08.18.2017-1840PM\Exchange\firstname.lastname@example.org" -Mailbox Test
- The import into the mailbox will take some time, but you'll be able to track the progress in the Exchange Administrative Center.
- After importation of the data, be aware that it shows up in a subfolder. So if you want the imported messages to show up in the right folders, the user (or you) will need to move the messages from the imported inbox to the inbox in the mailbox, for instance. The same goes for Notes and Calendar items; users will need to move them all into the corresponding parts of their mailboxes.
I ran through all of these steps with a test mailbox (with some copied data added to give it some size) to verify that it would work for the real migration.
I started the migration on a Friday afternoon, exported and downloaded each mailbox in turn, and followed by importing them into the right mailboxes. Based on information from the users, I also went through all the shared mailboxes and assigned the correct permissions to each user who should be able to access the mailbox and have the Send As permission for it.
The reality ^
Nothing ever goes according to the plan though. It turns out that when you add a new email address on premises (and run a manual sync job), it still takes a few hours until the Symantec email hygiene solution accepts incoming email for that user as legitimate. So that took a bit of troubleshooting on the big day: the Monday after the weekend when I did all the exporting, downloading, and importing.
Out of habit I had also opted for cached mode in Outlook where it keeps a copy of the mailboxes in a local OST file. This makes Outlook much more resilient to the occasional network interruption. The problem was that, as I was setting up users' mailboxes, they were "missing" emails that simply hadn't synchronized to their OSTs yet. Worse, once they started using the shared mailboxes, users were seeing outdated versions of them, leading to confusion about whether users had replied to messages or not. Switching them to online mode for Outlook fixed this issue.
Nobody had mentioned email on phones, but of course I found out that a few users did need this access, so I sorted this out as well using the free Outlook app on iPhone.
The Fasttrack Outlook add-in was a highlight however; it simply picked up the right settings for each user as I created new Outlook profiles, so I had nothing to do to at all.
One lingering problem seems to be the occasional prompting for a password that Outlook is famous for, but other than that the users are happy.
The next project is migrating their LOB applications—controlled documents currently in SharePoint in Office 365 and other applications—from their shared server in the cloud to the on-premises Citrix servers for remote access. I have a feeling that project will make this one look like a walk in the park.