Sysadmin blog Moving all of your email onto Office 365 is pretty easy; making it work properly once it's there is another story. As a salable product, I find Office 365 extremely curious; it's workable enough if you have a decade or two's experience beating Exchange into submission ... but a little too complex for anyone else. The cloud is supposed to be "push button receive bacon", and in practice I have found Office 365 to be anything but.
Microsoft's cloudy email offering does basic email very well. You can buy a licence for a new user with ease, set up an email address for them and connect up your client of choice. A few clicks and email starts flowing; it just works. But it's 2012. At this point, sendmail "just works" too, and it ships with virtually every Linux distribution known to man. You can even download fully operational real-boy mail servers as virtual appliances, put them on VMWare's freebie ESXi, and then build them into a wall. They'll run for the next decade or so without you having to fret about them.
Sendmail, however, has the added bonus of supporting certain highly demanded features like mail merges; Office 365 places severe restrictions (that you cannot control or change) on the amount and frequency of outbound mail. This makes running the corporate newsletter a no-go.
So if nobody is getting a solid gold Kewpie doll for providing basic mail flow, what are the sorts of advanced features I am expecting? Good control over mail enabled public folders for one. In a traditional Exchange setup, you can create and manage public folders from the central Exchange management software. You can mail-enable them, configure send-as permissions, set up security and otherwise do all that needs be done to make them usable without ever having to fire up Outlook or OWA.
The Office 365 solution to public folder management? Outlook and/or OWA + PowerShell. Would you like to configure send-as permissions for a distribution list? More PowerShell. One client wanted a mail account to accept mail for archiving purposes, but forward copies of all mail inbound to this account various other addresses within the company. Guess what; we need more PowerShell.
As much as I have a certain affection for the command line as an administrative tool, Microsoft and I have disagreements as to what constitutes "well documented." I also tend to like the command line as a means of modifying flat text files that drive configuration; all the configs in one place, easy to see and manipulate. I am significantly less fond of configuration systems in which I need to know the secret code word to see what the current configuration is.
Modern versions of Exchange are themselves pretty heavily reliant on PowerShell. If for example you want to set up a simple Linux anti-spam pre-filter to your Exchange server, you're probably going to have to root around in PowerShell to play with Exchange's junk mail defaults. In my time as an Exchange admin, I have had to drop to PowerShell the odd time to get some arcane - but obscure - bit of information out of Exchange.
But while PowerShell was an absolute necessity for Exchange 2007, Exchange 2010 largely removed the need and started moving us back towards an MTA as easy to use as Exchange 2003. Businesses without dedicated email admins were winning the war of usability!
Office 365 is a step backwards here. It simply isn't a solution I can set up for a client and wash my hands of. Your typical small business moving away from Small Business Server 2003 is not going to be able to manage and maintain Office 365. They will still end up needing an IT guy for any but the most minor changes.
Office 365 spam management is functionally incomprehensible to mere mortals. Spam can be filtered at three different stages. First, a mail can be blocked at the gateway system to your Office 365 data centre. Here, Microsoft maintains a secret list of ne'er-do-wells for whom it will outright block email. You don't have access to the list, you can't affect the list and you aren't informed if email destined for your domain is blocked by this list.
If the email admin of the sending domain is on his toes, he will notice that mail from his domain is bouncing when heading to Office 365, and he can request to be delisted. If he isn't, you simply won't get any notification that someone was trying to send you mail. When that critical email from a vital business partner goes missing, there isn't any bounce log to comb through looking for answers. Count me unimpressed.
The second place mail can be filtered is your domain-local instance of Forefront. Here you can define various flavours of mail rules and filter, and in truth it is an respectable - if not outright awesome - enterprise class product with a rich featureset. It's also completely incomprehensible if you aren't an email admin. To be fair; by default, anything flagged as spam here ends up in your "junk-email" folder.
In addition to this, your local email client may itself have junk email filtering. I've caught Outlook filtering things Forefront wasn't aware of. Try as you might, there doesn't seem to be a slider bar anywhere to change the Spam Confidence Level at which Office 365 chooses to filter mail.
At the end of the day, Office 365 is an enterprise product. It is full featured, but it needs to be managed by an enterprise email administrator. Unfortunately, an enterprise email administrator is going to be easily frustrated by the seemingly arbitrary system-wide limitations imposed by Microsoft that you don't have any power to change ... even through PowerShell.
What the customer wanted was the power of Exchange with a Fisher-Price-and-Crayons interface. One that exposed every last iota of functionality through a reasonably simple web interface backed up by a kick-ass wiki full of walk-throughs. Office 365 is supposed to replace Exchange, not Hotmail. Given its marketing and the promise of the cloud as hyped by Microsoft itself, it should be as easy to use as Hotmail, even for the really grown-up stuff.
Maybe in the next revision ... ®