Outlook.com and Exchange Online: Two Services and a Common Infrastructure
The Move to Exchange Online That Vexed Paul Thurrott
In 2015, Microsoft began to migrate Outlook.com from the venerable legacy of Hotmail.com to share a common infrastructure with its commercial Office 365 service. In February 2016, Microsoft moved Outlook.com out of preview, saying that their consumer email service was now “powered by Office 365”, with “the benefits of an email service that millions of businesses, governments and schools around the world rely on every day.” Those benefits are gained because Outlook.com uses the same infrastructure and underpinnings as Exchange Online.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
As Petri readers know, Paul Thurrott closely tracked the progress of the Outlook.com project, mostly to complain that Microsoft had not yet moved his mailbox. In September 2016, Paul reported that Microsoft had moved 90 percent of the user base. His mailbox eventually got to new Outlook.com the following month.
Hints That Things Were Changing
Anyone interesting in Microsoft email technology will have noticed the growing closeness of Outlook.com and Exchange over the last few years. Sure, the Outlook web client is simpler and less feature-rich (or cluttered) than OWA, but it recognizably shares the same roots and “design language”. Even the splash screens shown when the client initializes are identical. But having a suspicion that the two services share common roots is one thing, having evidence is another.
One Way Forward
When I asked Jon Orton, Microsoft’s Director of Marketing for Exchange and Outlook, about the growing closeness between the two services, he explained:
“Outlook.com and Exchange Online both run on the Office 365 infrastructure but are distinct services governed by separate privacy, security and compliance policies. From a development perspective, the two share a common core codebase, but have different release rhythms and expose features unique to their respective audiences.”
Reading between the lines, Jon’s statement means that Microsoft operates a common infrastructure to deliver multiple variations of Exchange Online (available as standalone plans and integrated into Office 365 plans like E3 and E5) for enterprise, government, and education customers and the consumer Outlook.com service, available in free (with ads) or premium. As Paul notes, the premium version comes without ads and a number of other benefits, including support for custom domains. However, the premium version of Outlook.com is only available to people in the United States.
The infrastructure includes well-known Exchange features like Database Availability Groups together with feeds like those used to drive security analytics, and a set of common APIs exposed through Microsoft Graph endpoints. Although some traffic flows through legacy Hotmail interfaces, Exchange Online Protection (EOP) provides mail filtering for both services. This is an important step because it allows Microsoft to concentrate all its efforts on fighting email-transmitted malware in one place.
OWA – The Common Link
In terms of clients, OWA is the common link, and clients essentially use the same protocols to connect to both back-end services. You can connect the Outlook desktop clients to both services using MAPI over HTTP and Outlook treats Outlook.com mailboxes exactly like Exchange Online mailboxes. This is not surprising because the two types of mailboxes are identical. Due to the change in infrastructures, if you use Outlook 2013 or Outlook 2016 to connect to Outlook.com, you must reconnect (create a new profile). Some might query why this step is necessary and why it could not be done automatically during the migration. It’s a reasonable question, and the answer is that the old and new infrastructures are so different, the simplest solution is to ask people to go through the connection process to ensure that Outlook configures itself properly.
Figure 1 shows how Outlook 2016 reports connections to various Office 365 mailboxes, including personal, public folder, shared, and group mailboxes. An Outlook.com mailbox is present (marked) and is accessed in the same manner as the Office 365 mailboxes. Note the similar endpoints, with the mailbox identifier (a GUID) used to locate the relevant mailbox in an Exchange Online database.
Mobile clients like Outlook for iOS and Android now use the same architecture to process email for both Outlook.com and Office 365. Indeed, the mobile versions of Outlook and OneDrive blur the distinction between personal and business data by supporting both types of accounts together with fast switching from one to the other.
Figure 2 shows further evidence of how closely the two services interact. In this case, Outlook.com submits a message to the server, which then processes and sends it via the transport service (MAPI). This is the same as you see with OWA. The system where the message originates is a server in Europe. With some knowledge of Office 365, we can say that it is in Vienna, Austria (VI prefix) and is in one of the Exchange Online production forests. The message transfers to Exchange Online Protection and then to Exchange Online for delivery to my mailbox, which happens to be a database mounted on a server in Helsinki.
The Message Header Analyzer tool used to report the routing is an Outlook add-in that works in Outlook, OWA, and Outlook.com – another advantage of common interfaces and infrastructures!
I estimate that the Exchange Online infrastructure now supports over 600 million mailboxes based on what we know about Office 365 commercial users, Exchange Online standalone plans, Outlook.com, and the low-cost or free mailboxes that Microsoft makes available to education customers.
The Outlook.com users are not grouped into one massive Exchange organization. Instead, like other Exchange Online mailboxes, they are divided across a number of production forests. This approach minimizes the effect that any outage can have on the overall infrastructure.
Why Microsoft Did Not Use Exchange Online Before Now
It is reasonable to ask why Microsoft did not merge the infrastructures together before now. Waiting until they had a good technical solution to move data is probably one reason. Not wanting to disrupt operations is another. But perhaps the most compelling reasons exist in the economics involved in operating a massive service like Office 365 on a global basis. Microsoft has invested billions to date and has plans to invest more to build out the Office 365 service to deal with customer demand (datacenters have recently come online in the U.K. and Germany to serve those regions). With such a huge investment in place, it makes sense to rationalize and consolidate to maximize the return on engineering, datacenter, and operational costs.
With these points in mind, it is difficult to argue against Microsoft’s strategy from an economic or engineering perspective. It just makes sense to operate a single infrastructure instead of duplicating systems to deliver essentially an identical service. It is also easier and cheaper to maintain a single infrastructure.
The first generation of Office 365 released in 2011 included a version of Exchange based on Exchange 2010. This release laid the foundation for what we have now, but it is only since the advent of Exchange 2013 and the rapid maturing of features like Native Data Protection and low-cost database storage that Microsoft could plan to merge Outlook.com into Exchange Online.
Now, the engineering teams focus on how to develop functionality that is applicable for both services. Feature differentiation is controlled through the directory service (which determines the plan available to a user) and the Role-Based Access Control (RBAC) system that first introduced in Exchange 2013. RBAC turns on and off client features in OWA depending on the license a user has.
Although it took Microsoft much longer to complete the migration, it is important to realize that they had to move more than 400 million mailboxes. Microsoft has used the “more than 400 million” number for Outlook.com since 2013 and it is fair to assume that a few more people have signed up for free email since.
In any case, while Outlook.com mailboxes tend to be smaller than corporate mailboxes (especially those taking advantage of the new 100 GB mailbox quota assigned in some Office 365 plans), Microsoft had to move a lot of data around. It is unsurprising that the project took so long, especially when a core goal for the migration was not to lose any email and they had to upgrade the surrounding infrastructure at the same time.
Functionality can flow both ways between the services. Sometimes it makes sense for Microsoft to test a new feature in Outlook.com before deciding to make it available to Office 365. For instance, the ability to “sweep” messages to remove messages you do not want to keep first appeared in Outlook.com and is now present in OWA.
On the other hand, a simplified version of OWA’s calendar is now available to Outlook.com users and the recent improvements in calendar sharing for OWA extends to Outlook.com too.
Given Microsoft’s determination that Outlook is a brand rather than a client, it comes as no surprise that both Exchange and Outlook.com absorb features first introduced elsewhere. The Focused Inbox, first appeared in the Outlook mobile clients, is now rolling out across all of Office 365 and Outlook.com, and will soon be available for the Windows 10 Mail client. Focused Inbox is a good example of how a common infrastructure delivers functionality to multiple services. It’s all part of the plan to create an Outlook brand where people have a choice of different clients, all of which support common functionality.
The Differences Between Outlook.com and Exchange Online
With all this common functionality, you could ask why you pay Office 365 when Microsoft delivers so much free to Outlook.com users. It is a valid question, but only if you need email to a certain level. Full-blown Exchange Online operates at a much more comprehensive and deeper level than Outlook.com does. The same is true for an on-premises deployment of Exchange 2013 or Exchange 2016.
Even if you buy the entry-level Exchange Online Plan 1, you get more functionality, flexibility, and support. Upgrading to Plan 2 brings Data Loss Prevention, in-place holds, hosted voicemail, and “unlimited storage” in the form of expandable archives. In the U.S., a plan 1 license costs $4/month and plan 2 costs $8/month. These plans include OWA but not Outlook desktop. You can use PowerShell to automate operations and the Microsoft Graph (or Exchange Web Services) APIs for programmatic access to data. In short, you use full-blown Exchange.
The Goodness of Integration
I see nothing but goodness in Outlook.com being “powered by Office 365”. It is a strategy that works for Microsoft and delivers better email to end users, all for the princely sum of zero cents. There is a lot to like about that price point. After all, if Outlook.com delivers the same SLA as Office 365 has attained over the last few years, few will have cause to complain.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.