Sean Wallbridge
This is not going to be a highly technical post; i just want to highlight some observations I’ve made about O365 over the last little while. If you are a newbie to O365 you might find some of this helpful. If you are an old hand then you already are aware of what I’ll be talking about.
The single biggest “thinking adjustment” you will have to make coming into O365 from an on-premise Exchange environment is that the O365 management interface is a couple of layers “removed” from the actual Exchange services that do the heavy lifting. And while you might well be familiar with the slight time lag that you could see in Exchange 2007 and Exchange 2010 management console (the time between you making a change in the console and the time when the change actually occurred), it is nothing like what you will see in O365. O365 will report back that a change has been made (as in you have added a user or you have changed a user settings, and so forth) but the actual results of the change might not show up for some period of time (minutes, not hours). I was reminded of this last night when I was helping a customer with their new O365 tenancy when we turned on access to Exchange, Lync and SharePoint for a user and it took about 5 minutes for the links in the O365 web interface to “light up”. It was a bit disconcerting for the customer and me, truth be told, as I forgot things weren’t necessarily “immediate”. So, keep in mind that patience is a virtue with O365.
As an O365 admin you will also discover that you really have far less control over the backend than you would have with an on-premise Exchange (or SharePoint or Lync). Keep in mind that you are a tenant in a monster big Exchange (or SharePoint or Lync) installation and you only have direct control over things in your immediate space. It is very much akin to having an apartment in a large apartment building; you can do pretty much want you want (within reason) within your own apartment but you can’t mess with the building itself. Microsoft has made great strides with the O365 management interface over the past year or so and they do make certain controls available via PowerShell but there are some things you simply won;t be able to do in O365 Exchange (or SharePoint or Lync) that you could do in your own on-premises environment. For 90+ % of O365 users this won’t be an issue but it is something to factor in to your thinking IF you have a very complex on-premises environment and you are thinking about migrating to O365.
Another thing that many people forget about is the simple fact that your “Exchange” is now out in the Cloud and not sitting local on your gigabit LAN. This means that things can take a little more time to complete, Outlook might feel “sluggish” on occasion, and its way easier to saturate the link between machines on the LAN and Exchange out in the Cloud. In day to day operations it actually is not that big of a deal, at least not that we’ve seen with our customers that have moved to O365, but it does make a difference when you are first getting your users cut over. There are many ways of migrating data from on-premise into O365 and a number of those methods have built in “metering” to keep things from saturating the connections. However, if you choose to migrate data by plugging in PST files to local Outlook installs and then “slurp” the PST data into the user’s Outlook you need to keep in mind that you can’t do this with a whole bunch of users at once and expect good performance in Outlook or on your WAN link.
And, of course, it is much harder to troubleshoot user issues with O365 than with on-premise as you don’t have backend access to the the “guts” of the system. But you do get good indicators from Microsoft through the O365 management portal as to the status of the system. They post health status on the management portal and that is the first place to look if there appear to be issues. O365 is a very robust service and it has a remarkably low failure rate but service interruptions can occur. So keep in mind that you need to check the management portal if you get user complaints and you also need to be more cognizant of the health of your WAN connections. Users can be blissfully unaware of larger issues when their Outlook talks to a local Exchange server (Exchange soaks it all up so Outlook never complains) but they become acutely aware of larger WAN issues when on O365 as their Outlook will let them know that it can’t talk to Exchange.
OK, that’s my small piece for the morning. Hope it helps.