Pages

Kamis, 10 Mei 2012

10 things you should know about moving to Office 365

Takeaway: If you’re planning a move to Office 365, expect a few surprises. Brien Posey shares some of the gotchas he encountered during the transition.

A couple of weeks ago, I was forced to begin using Office 365 for my own organization. It wasn’t something I had planned on doing. In fact, I didn’t get to spend any time planning. But it happened nonetheless. Construction in my area was causing numerous power and Internet outages, and I had to move my email offsite because I was losing too many messages.

All in all, the move to Office 365 has been a good thing. Even so, a few things caught me by surprise. So I wanted to pass along a list of things to consider before subscribing to Office 365.

1: Migrating is not a simple process

If you have an on-premise Active Directory environment and you want to perform a migration, it won’t be an easy process. Exchange Server 2010 SP2 includes a wizard that reduces the number of steps from roughly 50 down to six, but the migration process is still tedious and requires a lot of advanced planning. Because I have only a couple of users in my organization, I opted to start fresh rather than migrating my user accounts.

2: You may have to start over with spam filtering

One of the biggest things that surprised me was that spam filtering suddenly became an issue. Prior to subscribing to Microsoft Office 365, I was using GFI Mail Essentials. I had spent a great deal of time fine-tuning my spam filters so that I rarely received any spam. Office 365 uses Microsoft Forefront Online Protection for Exchange. Although Forefront is a decent spam filter, I had to take the time to configure it.

3: Outbound email addresses might change

When you subscribe to Office 365, all user accounts have a default email address that ends in onmicrosoft.com. While it is possible to use your own domain, simply accepting mail for your domain name isn’t enough. Outbound messages will continue to use the .onmicrosoft.com domain unless you make some configuration changes, which are far from intuitive.

4: You can say goodbye to third-party utilities

Many organizations use third-party utilities to manage Exchange Server. If you are using any such utilities and they’re designed to be installed directly on an Exchange Server, you won’t be able to use them with Office 365 (unless you keep an Exchange Server on premise). Microsoft does not allow you to install software onto the Office 365 servers.

5: You might have DNS issues

When you add a domain to your Office 365 account, you will receive a list of DNS entries that you must be make for the domain to function correctly. Although most of these DNS entries are relatively straightforward, Microsoft Lync requires some SRV records to be created.
This shouldn’t be a problem for those who have Microsoft DNS servers, but it can be problematic for non-Microsoft DNS servers. For example, my ISP manages my DNS entries. The ISP had no idea how to create the SRV records because it uses a Linux DNS server. That isn’t to say that the DNS entries won’t work with a Linux DNS server — but if someone else manages your DNS, you might have trouble getting the necessary DNS records created.

6: You may have to use different management tools

Because I didn’t keep any on-premise servers, managing Exchange through the Exchange Management Console was no longer an option. Office 365 uses the Exchange Control Panel as the primary Exchange Server management tool. Likewise, user accounts are created through a proprietary interface rather than through the Active Directory Users And Computers console.

7: You might have to reset file server permissions

As I mentioned earlier, my goal was to outsource my entire Active Directory domain. In doing so, however, I was left with orphaned on-premise file servers. If you find yourself in a similar situation, make sure that you have a plan for your file server data before you decommission your domain controllers. I moved all my file data to an NAS appliance, but that isn’t going to be an ideal solution for everyone. In any case, just remember that if you are outsourcing everything except for your file servers, you probably won’t be able to use Active Directory accounts for managing file access.

8: Prepare to be bombarded with phone calls and email messages

One aspect of the transition that really surprised me was that I was bombarded with phone calls and email messages from Microsoft. While I appreciate having the opportunity to ask questions about the transition, there is such a thing as too much of a good thing.

9: You might not be able to immediately connect users’ mobile devices

One of the issues I ran into during my transition was that even though I was able to bring my mailbox online quickly, the logistics of the transition kept me from connecting my Windows Phone to my mailbox for several days.
The reason for this is that prior to the transition I had an on-premise domain and an on-premise Exchange Server. Rather than working through a co-existence scenario and migrating everything, I decided that it would be easier to start fresh. This meant that if I had immediately connected my phone to my new Exchange mailbox, my contacts, calendar entries, and old messages would have disappeared from my phone (which would have been a big deal).
So I had to create a PST file on my PC and move all my mail, contacts, and calendar entries from Outlook to my PST. Once that was done, I disjoined my PC from the on-premise domain and then connected Outlook to my new Office 365 mailbox. Then I copied all my PST data to the new mailbox. At that point, I was able to connect my phone to my mailbox without having to worry about losing access to my contacts and other data.
Obviously, this won’t be a concern for organizations that work through the “real” migration process. But smaller organizations that choose to abandon their on-premise domain will have to consider this.

10: Expect a loss of control

Finally, moving to Office 365 means giving up some level of control. For example, you won’t have any control over the patch management process, software upgrades, and other similar administrative tasks you may be used to performing on-premise.