With the release of Exchange 2010 SP1, we introduced the /hosting mode switch – a feature which deploys Exchange using an Active Directory structure that affords complete separation between tenant organizations shared on the same underlying platform. /Hosting mode makes the need for a solution like Hosted Messaging and Collaboration largely redundant when hosting multi-tenant Exchange. /Hosting mode does not ship with any automation tools necessary for hosters to operate a service at scale, but it does address the requirements typical of a multi-tenant infrastructure (such as tenant organizations and service plans).
On one hand, /hosting mode solves many challenges inherent to offering this type of service. On the other hand, /hosting mode offers a reduced feature set as compared to the typical on-premises configuration. In the time since we released SP1 and /hosting mode, we have heard from customers and partners alike that many of these features are a fundamental requirement for doing business, and so to this end I announced that hosters would be supported when using the on-premises configuration from SP2 onwards (assuming their configuration meets certain design requirements). In addition, we also provided perspective on which is the right approach for hosters to take.
The purpose of this blog post is to explain the next step in the evolution of our thinking regarding /hosting mode. After hearing feedback about the importance of these features, we have concluded that the best approach to multi-tenant hosting on Exchange is to use the on-premises configuration as the basis for a hosting infrastructure. As such, no additional features will be added to /hosting mode, and it will not be carried forward into the next version of Exchange. Here are a few key facts you’ll need to know:
While this represents a change in direction, and will no doubt result in varying amounts of migration work on the part of hosters who have deployed /hosting mode, there is good news. This new approach means that hosters will be able to offer a wider set of hosted Exchange features to their customers. In addition, integrating Lync into a hosted service portfolio will be more streamlined and much simpler.
Looking at the data we presented at Worldwide Partner Conference, this opens up a sizeable market opportunity for hosters. Most customers looking to upgrade to Exchange 2010 cite the product’s advanced capabilities (such as Exchange UM – not available in /hosting mode) and a hosted UC service as a primary driver.
The obvious question you’re probably asking yourself is “what should I do now?” If you haven’t yet deployed Exchange 2010, our recommendation is to avoid /hosting mode and go directly to Exchange 2010 SP2 using the on-premises configuration. This will allow you to offer the features customers are looking for, and avoid a cross forest migration down the road.
If you’ve already deployed /hosting mode, you will continue to be fully supported through the standard support lifecycle of Exchange 2010, though you will continue to have a reduced set of features at your disposal. In addition, if you’re planning on hosting Lync and have deployed Exchange using /hosting mode, you will need to deploy Lync in a separate forest. You might consider switching to Exchange 2010 SP2 using the on-premises configuration. If neither of these issues are considerations, stay the course until the next version of Exchange is available.
As I mentioned above, documentation for hosting as well as a step-by-step process for both scenarios will be forthcoming from my team in the coming months.
We appreciate the challenges involved with this decision are considerable, but we do believe this is the best, most flexible course of action available for our service provider partner community going forward. We will provide more information and details in the coming months, but wanted to be clear about this directional change as you make plans for your infrastructure today.