With the changes in strategy we announced in Future of /Hosting Mode a few months back we wanted to take the opportunity to make clear what is supported in what are typically referred to as hosting scenarios.
We announced that hosters would be able to use Exchange 2010 SP2 to provide hosted Exchange services once we released it. Well, we just released SP2 and now we have also released Multi-Tenancy and Hosting Guidance for Exchange Server 2010 SP2 to help our customers configure their solutions in a supported manner. We have created a multi-tenancy solutions and guidance web site to recognize control panel vendors who have provided adequate details about their solutions for us to list them as having a compliant solution. The guidance is intended for both hosters and control panel ISVs, but will also be useful for anyone trying to build a multi-tenant type system (sometimes referred to as a private cloud), using Exchange 2010 SP2.
Update Dec 20th: We’ve just published the Exchange 2010 SP2 Multi-Tenant Scale Guidance, which contains guidance for properly scaling and deploying a multi-tenant Exchange 2010 SP2 solution.
The most important thing to understand is that a hoster, a control panel vendor, or anyone who uses and follows the guidance we publish publically to build their solution is fundamentally no different than any other customer who deploys Exchange, but chooses not to change any of the default settings. We intend to offer support to you no differently than we would any other customer.
For example, you are an a typical Enterprise customer, and deploy Exchange, configure some Address Book Policies (ABP), change some calendar permissions and add few thousand accepted domains, you will get support just as you always have, as your configuration uses only supported tools and processes. As a hoster or private cloud builder it will be no different. You too create objects, set up some ABPs, and may end up with an unusual configuration in the eyes of an average Exchange customer, but that is all it is – unusual, customized to meet your requirements, but not unsupported.
Here are a few examples to try and clarify what this means:
- You call us with an Exchange transport agent problem and it is clear that whatever you built doesn't follow any of our published development guidance. We will recommend you change it to follow our guidance, and that advice won't change whether you are a hoster, building a private cloud or are an Enterprise organization.
- You are a hoster and call us to say that you can't stop internal OOFs being delivered between tenants on your self-built hosting platform. We point you to our hosting guidance where we clearly state this is a known issue with this type of configuration and also tell you that the document also suggests the right approach to take to try and solve this kind of issue. If you want to then open a separate developer case to get help as you create the solution, you can do that too.
So as you can see, if you are a hoster or an Enterprise customer, or someone who builds themselves a solution to host multiple tenants in some way, and you have used supported tools and methods to configure your system we'll be able to effectively support it. That's really no different than it is today, if you choose to make some rather unusual changes to your system, we don't ask to validate the end-to-end system before we help you recover that database. If, on the other hand, the database failed because of that rather unusual change you made, that's when we get to discuss why you made those changes and potentially point out that they're unsupported.
If a control panel vendor wishes to sell their solution AND have their solution listed on our web site, they need to provide written confirmation to us that their solution complies with the ENTIRE guidance document. If they only 90% comply, they won't be listed. It won't stop a vendor selling their solution, as they can do that without us reviewing any of their solution, but a customer who wants to buy a solution will not see theirs listed on our web site.
So in summary, for customers using Exchange 2010 SP2, we will treat our hosters and enterprise customers the same – if the root cause of your problem is an unsupported setting or change, we will point that out and recommend you change it. As a hoster you can really create a multi-tenancy system without making any unsupported changes. The guidance we have published will help you to do so, and we recommend you follow it.
I like to think about it like this: our end goal in providing guidance and allowing hosters to use Exchange Server 2010 SP2 is to make sure they end up with a solution based upon a supported configuration, which makes their system just the same as anyone else’s. We really do want you to get support for your system when you need it, you just need to make sure what you are doing will help us to help you.
