Earlier this week Brian K. Winstead, the author of the Exchange and Outlook blog on http://www.windowsitpro.com, contacted me to ask about the keynote that I’ll be giving at the Spring 2011 Exchange Connections event at the JW Marriott Resort hotel in Orlando from March 27 to 30. The resulting conversation is available online.
I’ve said before that 2011 will be a year of migration. According to this blog by Ian Hameroff of Exchange Product Management, they believe that 60% of the Exchange 2003/2007 installed base will upgrade this year. The choice facing many companies is to proceed with an on-premises or a hosted deployment, including the option to use Office 365, and this is one of the topics that I plan to talk about in Orlando. I’ve spoken to a lot of people about Office 365 and have had some exposure to its predecessor, the variant of Exchange Online that’s currently available as part of the mouthful called Microsoft Business Productivity Online Services (BPOS). Of course, this version is based on Exchange 2007 rather than Exchange 2010, which is what Office 365 uses, so it’s not the same. I was therefore keen to get hold of an Office 365 account and hoped that Microsoft would accept my application to be part of the Office 365 beta. Alas, this didn’t happen. To their credit, Microsoft was swamped with applications to join the beta. Even though I write about the technology as a contributing editor to Windows IT Pro magazine and am a current Exchange MVP, my application was duly dispatched to the wastebasket or filed under “maybe, some day, perhaps”.
In any case, InfoWorld columnist and fellow MVP, J. Peter Bruzzese, received access to Office 365 (he reports some of his recent musings about Office 365 here). I guess InfoWorld carries more weight with Microsoft PR than Windows IT Pro. So be it. Peter was kind enough to offer me an Office 365 from his test domain and I accepted the offer with thanks. I’ve been using my 25GB Office 365 mailbox complete with an online archive for a week or so since. Not long enough to learn everything about a product that is still in beta, but certainly long enough to arrive at some early conclusions.
So here’s the thing about Office 365 – it is totally boring for anyone who’s been trained as an Exchange administrator. All the fun (???) of setting up and running servers is removed because Microsoft does it all for you and hides the interesting technical detail behind a boring web-based administration console that could be managed by my grandmother. And that’s the point of a utility email service. It has to be boring, and robust, and dependable, just like any other utility service. Think of electricity or water – would you want to have administrative control over their delivery to your house? The answer is a resounding “No” – all you need is a meter to tell you how much of the utility you’re using, which is roughly the equivalent of the Office 365 administration option that tells you how many users you have in your domain and what licences are assigned (or in Office 365 parlance, the “plans” used by each user; a plan dictates what functionality is available to the user). Apart from checking the meter from time to time (or ignoring it until a utility bill arrives), the only interaction you have with a utility is to connect a new device. You might be brave and change a plug for an electric device before you plug it into the socket, but that’s about it. The equivalent in an Office 365 world is to set up a new user, an operation that is much easier than rewiring a plug.
There is some new administration work to do in a co-existence scenario when part of the company uses on-premises Exchange servers and some users connect to Office 365. Federation and directory synchronization are two critical activities to master here. But I suspect that the administration effort will peak sharply at the time when users first migrate to Office 365 due to the need to establish high-fidelity connectivity between the on-premises and cloud environments and to move mailbox data.
Companies should not underestimate the effort required to migrate users or that required to ensure that the right networking and operational configurations are in place to support Office 365. This is especially so when users want to move large mailboxes from on-premises servers to cloud-based servers, unless of course your company possesses ultra-wide network connections to transport all the data across the Internet to Microsoft’s datacenters. Of course, asking users to clean out mailboxes before the mailboxes are moved is often an act of total futility as has been proved in previous migrations over many years. Users are simply too busy to do this kind of housekeeping and anyway, why do you need to do it when storage is cheap?
After the initial burst of activity (which could last several months for a large company), I suspect that the migration and interoperability workload will decline to allow administrators to concentrate on other more productive activities.
From a user perspective, Office 365 is very much the same Outlook Web App (OWA) experience as delivered by Exchange 2010 SP1 (including selectable themes). The only issue I encountered was using the Chrome browser – OWA didn’t seem to want to allow me to save or send a new message. If you elect not to use a web browser, then you can choose an RPC-over-HTTP (aka Outlook Anywhere) connection for Outlook. It took about ten seconds to configure a connection between Outlook 2010 and Office 365 and, as far as I could tell, the subsequent experience was exactly similar to that when connected to an on-premises Exchange 2010 server, which is exactly what you’d expect.
I also connected my iPhone to my Office 365 mailbox. Curiously, I wasn’t able to use the inbuilt Microsoft Exchange-type connection and had to revert to using an IMAP setup. Fortunately Microsoft has published all the necessary settings via ECP and I was able to plug the settings for IMAP and SMTP into the iPhone and then synchronize.
Administrators get a web interface that’s a modified version of the on-premises Exchange 2010 ECP plus a separate Office 365 web interface that’s used to configure other non-Exchange options. The Office 365 version of ECP allows for options such as selecting the plan associated with a mailbox and displaying some mailbox data that is accessed through EMC for an on-premises deployment such as current mailbox size. If you know ECP for Exchange 2010 you won’t find much different here, nor is there anything different about connecting a mobile device to an Office 365 mailbox.
Office 365 therefore delivers exactly what it says on the box: a utility email service. This will be exactly what many companies need. I can’t, for instance, see the logic why a new start-up company would deploy on-premises servers unless they had a really good reason for doing so (such as being in the business of developing add-on software for Exchange). On the other hand, the utilitarian nature of Office 365 cannot deliver the flexibility or custom-built environment that is possible with an on-premises deployment and I suspect that there are many large companies that will find Office 365 to be a compelling vision that they cannot use at this point. The situation is likely to change over time as company requirements evolve and Microsoft builds out Office 365 and its successor products so that they can respond to the needs voiced by customers.
One interesting question exists that I can’t find an answer to yet is how Microsoft plans to migrate BPOS accounts to Office 365 (“move mailbox” is not a complete answer!). As covered here, creating and using new Office 365 mailboxes is straightforward but given the careful planning and enormous effort that companies dedicate to migrating from Exchange 2007 to Exchange 2010, a huge amount of work must be going on behind the scenes for Microsoft to prepare to move the millions of BPOS mailboxes they currently support. Like any migration, this has to be done with as little disruption on the end-user as possible and that’s where careful planning and solid execution pay big benefits. Some insight into the technical details of this transition would be compelling information. Maybe I shouldn’t care because when you’re using a utility, you don’t have any exposure to what goes on behind the scenes and couldn’t care less as long as the service stays running. But the technologist in me just wonders and this is the first time that Microsoft has had to cope with the migration challenge for millions of mailboxes!
All of this is interesting stuff and I look forward to debating the topic of Office 365 amongst others with those who attend Spring Connections. And I am sure that we will have similar debates at the Exchange 2010 Maestro events later on this year!
I have been working with the Office 365 beta for some months now in a rich coexistence environment. Your assessment of the administration effort is correct, once you have setup the infrastructure to federate to the cloud then it becomes a ‘simple’ user migration. It is interesting setting up the federation and organisational relationships but after that the nuts and bolts of the exchange system is out of your hands.
The coexistence features of the product are fantastic with rich calendaring between mailboxes in the cloud and on-premise for the period of any migration, in theory you could stay in a mixed mode forever. Just a shame it takes all the fun stuff away from an Exchange Admin.
Thanks for the article.
I think that some organizations will stay in mixed mode (or hybrid mode) for a very long time, if only because there are some mailboxes that they will be unwilling to move to the cloud. Companies, for instance, who secure the mailboxes of their executives on special servers that are only accessible by certain administrators. I’ve even seen such servers deployed in high-security rooms. These companies might be happy to allow mailboxes for the bulk of their employees to run on a cloud service but may wish to protect others, which leads us to a continuing hybrid situation.
As to removing the “fun stuff” from an Exchange administrator, I think that setting up and running a server could be considered fun the first time you do it, but afterwards it swiftly becomes part of the daily grind of operations. My hope is that by freeing administrators up from this kind of activity, they will be able to take on more high-value activities such as figuring out how to use software to solve real business problems. This might be a reach and real challenge for some, but overall I believe that it will be a welcome evolution.
Thanks for the reply.
As e-mail as become a utility service over time then the adoption of these managed services does free up resource within your IT organisation. You mention above that you would hope to see administrators taking on new high-value activities so do you see Exchange administrators having to re-skill?
Also the advent of Office 365 is an opportunity for integrators in one respect as they can assist with the move to the cloud and provide the hybrid environments you outlined. However once it is in the cloud then that is the end of exchange migrations.
I see Office 365 as potentially a real game changer in the market. I would be interested in hearing more on how you see it changing the future landscape?
The topic of reskilling of Exchange administrators to deal with a world of hybrid or pure cloud-based services deserved a full blog post… and I will cover this topic in the future. For now, I think that Exchange administrators will spend more time on monitoring services, security and certificate management, federation, SLA measurement, and examining how to use the technology that’s available to solve business needs. For example, a lot of administrators will say that they spend several hours weekly just keeping up with hot fixes, service packs, and other changes required to keep Windows, Exchange, and other products in good health. If this time is now available because Microsoft is running the services, why can’t it be used for more productive purposes such as setting up a SharePoint team site to help a department run its business more effectively?
You make a good point that integrators have an opportunity to assist companies assess, prepare for, and then move all or part of their organization into the cloud. However, I disagree that this will mark the end of Exchange migrations because it is the nature of business that companies split and join all the time through divestitures and acquisitions. These events will naturally lead to migration-like activities. Another thing to consider is that Microsoft plans to upgrade their services on a regular basis. This may or may not be welcomed by a company because of the impact of new technology on users and their help desk, so that’s obviously something that has to be managed. Remember that changing anything on thousands of desktops is much harder than a server upgrade.
The last point that I would make is that Exchange’s success over the last 15 years has been greatly assisted by being surrounded by an ecosystem of third-party products that have filled the feature and functionality gaps left by Microsoft. It will be interesting to see how the ecosystem develops in a changing world that is heavily influenced by cloud-based services.
I have a hopelessly vague hypothetical question 🙂
What do you see as the potential roadblocks/showstoppers/reasons why Office365 might not be a good fit for a 20,000 user company on Exchange 2003, with a global footprint typical of the oil/gas industry?
Currently we some challenges:
2) Public Folders (not available in Office365, data would have to be migrated to SharePoint; no small job)
3) Integration with in-house apps such as Cisco Unity
My impression is that Office365 is a good platform, but that it is more suitable for SMBs than for large corporations.
I think that you’ve mentioned a number of the obvious show-stoppers. Migration may not be as Microsoft has facilities to move mailboxes from Exchange 2003 to Office 365, just like you can move them from Exchange 2003 to Exchange 2010 on-premises. All it takes is good preparation, time, and energy. Public folders is a huge issue right now and Microsoft’s failure to provide a good path forward via SharePoint or something else is now causing them a problem. Voicemail via Cisco Unity might be overcome if you were willing to move to Microsoft’s own Unified Messaging platform, assuming that this will be provided in Office 365 at some time in the future. And then there are many other applications that people use with Outlook or Exchange, not all of which come to light until you start to look for them. Some, for instance, might depend on WebDAV, an API that was deemed to be very important in the Exchange 2003 timeframe but has now been deprecated (a nice way of saying “dropped”) and is unavailable with Exchange 2010.
The bottom line is that some companies will find it very easy to move to Office 365 and some will find it very hard. Amongst the easy category are small to medium enterprises that use “basic” Exchange, be it Exchange 2003 or 2007 today or those that are migrating from Lotus Notes or another messaging platform. In the hard are companies that have built an ecosystem around Exchange composed of public folders and other third-party applications plus those who are distributed and maybe don’t have the unified IT management that I think is necessary to assure a successful move to cloud services.
Great Blog Tony,
Like other comments I’m worried about the future a bit. I’m not an exchange admin but it will be interesting to see what the world looks like 15 years from now. Will there even be a job known as “sys admin” or “exchange admin” in 15-20 years.
I’m glad I’m in my 30’s and not starting out trying to figure out my job in IT.
Can you share any insights about the Exchange 2010 architecture that Microsoft is using to host Office 365? For instance, are they leveraging Hyper-V or hosting this service on physical servers like they are for their internal Exchange 2010 infrastructure (http://technet.microsoft.com/en-us/library/ff829232.aspx)? Are they using a SAN or DAS model? I suspect they are using Exchange 2010 SP1’s multi-tenant support as described here: (http://technet.microsoft.com/en-us/library/ff923272.aspx). However, I’m curious to know how they are facilitating co-existence deployments given the stated lack of support for Active Directory Federated Services when using Exchange 2010 SP1’s hosting mode. Thanks in advance for any insights that you are willing to share.
I would also like to know if you are planning to write about or have already written about Exchange 2010 SP1’s multi-tenant mode and how a Microsoft hosting partner could leverage this feature to build their own Exchange 2010 SaaS offering.
I’m somewhat constrained by NDA so I cannot answer all of your questions. However, from Microsoft’s public pronouncements you can say that: a) they use DAS for their hosting services (for example, the Exchange 2010-based Live@EDU), so I wouldn’t be surprised to see the same approach taken for Office 365, if only because of the cost; b) virtualization may be used in parts but not everywhere; c) they’re not using Exchange hosted mode as that does not use Active Directory Federated Services, which is the cornerstone of their single sign-on model. As to writing more about this topic, I think that there are others who run hosted Exchange services today – based on Exchange 2010 or otherwise – who are far better qualified than I to write about the technical details.
NDA constraints understood. I appreciate your response and insights.
The impetus for my previous post stems from my employer being a Microsoft partner with a SMB solution integration focus. Exchange is one of our core practice areas. We also have a burgeoning managed services practice that is relevant to this discussion. Given Microsoft’s “all in” cloud focus, we are thoroughly analyzing the potential impact that Microsoft’s shift to the cloud will have on our Microsoft consulting/integration business—our Exchange practice in particular.
We are fully aware of Microsoft’s cloud services reseller model and realize that it is the most obvious next play for a company in our position. Leveraging Microsoft’s investment in Office 365 infrastructure by simply reselling their service to our clients is a compelling proposition. However, we are also evaluating the possibility of diversifying our managed services portfolio to include a build-our-own Exchange 2010 SaaS offering (based on Exchange 2010 SP1’s multi-tenant capabilities). In comparison to reselling Office 365, a build-our-own strategy would certainly require far more investment on our part, but could it be a more effective business proposition in the long run? My gut tells me that, once we have completed our comparative analysis, the answer to that question will likely turn out to be, No. Nevertheless, such an analysis seems like a worthy thought experiment.
By the way, love your work. Thanks for all of your contributions to the Exchange community.
While I admit that the future looks a tad confused for those providing hosted Exchange today, I am more confident than some that there is a niche to be exploited. The first thing to remember is that the presence of Microsoft in the market legitimizes it in the eyes of many companies – in other words, it’s OK to used hosted Exchange now. The second thing is that Microsoft will provide a service that is automated, feature-rich, but like a supermarket – if it does what you need, it’s great. In other words, I think that there’s a chance for other companies to provide a tailored hosted service that meets the exact needs of their customers. In just the way that the bespoke tailors of London still survive and sell their $5,000 suits against fierce pressure from department stores, I suspect that there will be a way for smaller, more personal hosted providers to create and support a business.