Tips for Migrating to Exchange in the Cloud

With all of this "cloud speak" these days, I figured I would give some real-world advice about what is involved in moving to a hosted Exchange solution in the Cloud. With our recent growth and staff additions here at Liquidware Labs, we made the decision to upgrade our mail server from our locally hosted Exchange 2003 server to a more robust and flexible cloud-hosted solution. We chose Microsoft Online services for our Exchange Cloud for a number of reasons, with the primary reason being cost. At $5 per user per month, with 25 GB of storage per user, the savings would be hard to beat. This service from Microsoft is now known as Office 365, and we will be completely migrated later this year to the full suite.

Let me make an important clarification here, by pointing out that we did the migration ourselves and did not use a migration application. We supported the migration internally for a number of reasons. The first was that we had the internal resources and experience to handle the move. Secondly, we were on Exchange 2003 and our hosting provider did not provide any tools for Exchange 2003. Finally, we did not want to incur consulting fees for a migration.

During our experience of migrating, we learned some things that are very important to consider when moving to Exchange in the Cloud, and I would like to share these with you:

Things an administrator should plan for:

DNS -- Make sure you know who is hosting your DNS and that you can edit/create records. You will need this ability mainly because you need to change your MX record to point to your hosting provider's host name.

Internal services that use SMTP -- You will definitely need to review your internal services using SMTP. Most hosting providers will use username/password, custom ports and SSL to support SMTP/POP3. So when you audit your services that use SMTP, it's likely you will find some services that won't be able to send e-mail because they don't support all of the requirements your hosting provider has around using SMTP. To solve this issue, you might have to create a SMTP relay that internally is on port 25 and doesn't have any special configuration. However, when the relay sends mail to your hosting provider, it's using all the special requirements needed to send mail.

How users access e-mail -- If you have some users on Windows using Outlook 2007 or 2010, no problem. If you have some users on Apple operating systems, again no problem because with Outlook 2011, Apple OS works great. However, if your users are on Linux, you may have a problem because there is a chance that your hosting provider won't open up IMAP. This concern is where the "fun" begins, and , at this point, you have a few options:

Webmail is one possibility, but it depends on which version. Hosted Exchange 2007 webmail isn't bad, but Exchange 2010 webmail is more feature-rich.

POP3/SMTP could be an option but your provider might make you work for this access. They may ask you to use PowerShell to enable it, if it's not exposed in the admin console. Or they may have you open a ticket with the operations team, to enable for you. Of course, POP3/SMTP has its own inherent problems, folders, calendars, company directory, etc.

You can use different mail clients for Linux or some mail clients that use webmail/active sync settings to push and pull mail from Exchange like a smartphone. The one I found for Linux is Evolution mail client for Linux. Note: I have not tested this and my developers, who primarily use Linux as their OS, prefer their own POP/SMTP mail client choices.

Migrating user mail -- For me, migrating users was as painful as painful gets. We spent 16 hours migrating mail. We needed to perform this step manually, because we were on Exchange 2003, and I could not find any free tool to move mail from Exchange 2003 to hosted Microsoft Exchange 2007. In hindsight, I could have upgraded the Exchange server to 2007 in a sandbox and just used a tool to do all work for us. Instead we opted to logging in as each individual user into Outlook doing an export and Outlook import. We had issues with this approach, because many of our mail boxes were over 1.5 GB in size. It almost became a joke waiting to see how long it took to migrate the users' mail to hosted Exchange. If I had known how long that would be, I would have forced users to archive more e-mail, leaving it up to my users to clean up their own mail. So definitely make it an enforced rule to have users take the responsibility to clean up their mail and archive it before the migration.

Smartphone audit -- It is also important to know what your spilt is for smartphones, and which use active sync free and are built into hosted Exchange or have Blackberrys. This is where the Blackberry saga begins.

Blackberrys can connect via IMAP, POP and BlackBerry Internet Service (and there may even be more ways). If they are connected via BIS, your users most likely are paying extra from their cell carrier for a Blackberry plan. From my point of view, I was better off if I "paid" my users to get rid of these devices and just go to something that provided the functionality they needed without incurring the extra cost from the hosted Exchange provider and the cell phone carrier.

Default e-mail policies -- It's important to know what default e-mail policies are going to be applied to your users. Not all providers expose changing these policies, so you will need to have a set number of policies that will be hard-coded. You will also need to educate your users about these hard-coded policies. Here are just a few you will want to know (but there could be more):

• Deleted e-mail policy -- Some users (not naming names) like to just delete e-mails; however they never empty out their Deleted Items Folder. The hosted Exchange system could have a policy that removes the Deleted Items Folder contents every X number of days. But be aware that your users may call the help desk in a panic as they watch there 'deleted' folder count go from 10,000 to 0 in a matter of minutes.
• Mail send and receive size -- In the past, the size of individual e-mails might have been set high on your Exchange server because you didn't care about the mail sent and receive sizes, but on hosted Exchange, there will be a limit.

Spam Reduction Quality -- You probably should take the step to check your current spam filter reports to see how much e-mail you have on average and how much of that is spam. When you move to hosted Exchange, it will have built-in spam protection. However, the new system might not be as good as what you have today so you might need to keep your hosted spam filter in place even with hosted Exchange. Right now our experience is that Google Postini is better than the built-in Microsoft Online spam filter. We are hoping that when we move to Office 365, the spam filtering gets better.

User experiences that could come back to haunt you:

Outlook Autocomplete -- Since you're moving to a new Exchange server and a new Active Directory domain for e-mail, the encoding of the DN/CN information on the Outlook client Autocomplete is wrong for internal users. To avoid this problem, make sure you clear out the Autocomplete altogether, and/or train your users that when they start typing, they need to hit the "del" key when an Autocomplete pops up, and pick from the Global Address List to force a rebuild of Autocomplete.

E-mail starts to kick back -- External addresses that you were able to e-mail before the cutover might start to fail. The problem here is that some spam filters are stricter than others. Now that you're using a hosting provider, your MX records trace route does not resolve to your domain. For example, your MX record might have been mail.liquidwarelabs.com and IP, now it might be MX = mail.microsoftonline.com. With this change, some spam filters see this "other" host name and think it could be spoofing. To resolve this, the third-party you're e-mailing with would need to trust your domain, i.e. LiquidwareLabs.com. Don't worry about push-back from the third party, as those who have their e-mail filters set this way are use to this request.

Calendar items labeled with copy -- There could be Calendar items that cannot be edited, forwarded or modified in any way. Since these Calendar items were created with an entirely different e-mail and Active Directory user, you can't edit these items. If users need to edit a reoccurring meeting, they'll be better off recreating the meeting all together and sending it out again with the new Global Address List.

The good news is that once you rip off the Band-Aid and get migrated to hosted Exchange, it's well worth it in the end, because it's one less system to worry about for storage, backups, and redundancy. We are now fully productive using Microsoft Online hosted Exchange today. We plan to continue this path and migrate to Office 365 later this year. We're excited about our progress and looking forward to see what new features and benefits we'll get as we continually move our own systems to the cloud as a customer.

Posted by Jason Mattox on 12/09/2011 at 12:49 PM