As part of their announcements at TechEd, Microsoft revealed the worst secret in the Exchange world and told us that they’re working on Exchange 2010 SP2. The software is still in a restricted beta and won’t be available for some time yet, but the outline of the new features is solid enough for Microsoft to announce that they include:
- Outlook Web App (OWA) Mini: A browse-only version of OWA designed for low bandwidth and resolution devices. Based on the existing Exchange 2010 SP1 OWA infrastructure, this feature provides a simple text based interface to navigate the user’s mailbox and access to the global address list from a plurality of mobile devices.
- Cross-Site Silent Redirection for Outlook Web App: With Service Pack 2, you will have the ability to enable silent redirection when CAS must redirect an OWA request to CAS infrastructure located in another Active Directory site. Silent redirection can also provide a single sign-on experience when Forms-Based Authentication is used.
- Hybrid Configuration Wizard: Organizations can choose to deploy a hybrid scenario where some mailboxes are on-premises and some are in Exchange Online with Microsoft Office 365. Hybrid deployments may be needed for migrations taking place over weeks, months or indefinite timeframes. This wizard helps simplify the configuration of Exchange sharing features, like: calendar and free/busy sharing, secure mailflow, mailbox moves, as well as online archive.
- Address Book Policies: Allows organizations to segment their address books into smaller scoped subsets of users providing a more refined user experience than the previous manual configuration approach. We also blogged about this new feature recently in GAL Segmentation, Exchange Server 2010 and Address Book Policies.
- Customer Requested Fixes: All fixes contained within update rollups released prior to Service Pack 2 will also be contained within SP2. Details of our regular Exchange 2010 release rhythm can be found in Exchange 2010 Servicing.
Compared to the full bag of tricks that arrived in Exchange 2010 SP1, SP2 is somewhat of a damp squib and there’s a horrible suspicion that the development group might have its attention more fixed on making Exchange work efficiently as a cloud platform rather than keeping on-premises customers happy. This unworthy suspicion will be confirmed or refuted when Microsoft announces the set of features that it will include in the next major release of Exchange but a nagging concern is creeping into my sub-consciousness now.
On a more positive note, Address Book Policies (ABPs), aka GAL segmentation or the ability to serve up different LDAP-based views of a directory to different sets of users within the same Exchange organization, is the big new feature in the list. Although it is a worthy advance that is well executed and will mean a lot to the organizations that need to deploy these policies, ABPs won’t have the same fundamental impact on Exchange that some of the SP1 features have had. Compare the banal ordinariness of ABPs to SP1 advances such as the completion of retention policies and tags, the introduction of block mode replication for DAGs, and a refreshed Outlook Web App (OWA) client and a certain sense of disappointment might wash over those who expect more in a service pack.
However, service packs are not intended to be new product releases and Exchange 2010 SP1 set a new benchmark in terms of the new features and functionality that it included. In fact, there’s so much in SP1 that it is a very different product in some respects to the original release. So much so that it simply confirmed all of the hoary old advice that no sane administrator ever deployed the first edition of a new Microsoft server product. Always wait for the first service pack went the refrain and that proved correct for Exchange 2010.
Don’t get me wrong. There are other worthy improvements in Exchange 2010 SP2 that will be welcome to many and it’s always good to be able to install a release that represents the current state of the art. The change to make cross-site redirection for OWA more automatic by removing the need for users to navigate through multiple sign-on screens following a site transition and end up connecting to a CAS server in the “wrong” Active Directory site is good progress. I think it also indicates the importance that Microsoft assigns to making native in-product high availability work as seamlessly as possible.
Good news for the folks who plan to operate hybrid deployments of on-premises and cloud Exchange servers is the introduction of a wizard that eliminates many of the steps now required to configure seamless interoperability between the two sets of servers. The word is that the wizard takes care of some 40 of the 46 separate operations that administrators have to perform today and I imagine that this will remove a lot of frustration on the part of administrators who are tasked with the need to connect on-premises Exchange servers to Office 365.
I’m not sure if the reintroduction of Outlook Mobile App (OMA) will be more successful than it was in the past but someone must have been lobbying for its inclusion. I hear that simplified web browser interfaces to email are important in some markets (Japan has been mentioned in this respect), so maybe that’s where the impact of OMA will be felt.
You won’t be able to install Exchange 2010 SP2 until Microsoft releases the code to the world sometime later this year. You can start to prepare for SP2 by making your Active Directory administrators (that might even be you) aware that a schema update is necessary to support the new ABP objects and properties plus to extend mailbox properties so that Exchange can stamp ABPs on them.
Schema updates are often seen as a “tremendously difficult thing” but I suspect that this reputation was earned a long time ago when Active Directory replication was often handicapped by flaky network links and slow servers. In addition, early Active Directory deployments tended to over-complicate things (the benefit of hindsight!) by having too many domains. It therefore took careful planning to make sure that all domain controllers in the forest were updated in a reasonable time. We’ve become smarter over time, Active Directory replication has improved, network links are more capable, servers are faster, and schema updates are easier to perform, if not to schedule. In any case, you won’t be able to deploy Exchange 2010 SP2 without first updating the schema so now’s a good time to include the update in your operations plan for late 2011.
ABPs deserve more in-depth coverage so I’ll cover them in a future post. Until then…
Thanks for a really useful assessment of SP2 and interesting top hear your points about improvements in on-premise functionality versus developing Exchange Online.
Any idea if cross site CAS redirection for MAPI traffic will finally see the light of day?
We’ll just have to wait and see the final code that Microsoft releases for SP2…
I am quite excited for new release of SP2 and I’ve been looking for some ISV for an easy go to manage Exchange as one I am using is custom app which is not suitable for Exchange 2010. I have not found anyone other than MachSol (www.machsol.com) to provide control panel supporting SP2 and here is their announcement for Exchange 2010 SP2 support. I Googled a lot but no provider is yet ready so far. What do you suggest or do you know of any solution provider for Exchange?
I don’t have much experience with the control panels used to manage hosted deployments of Exchange. What I do know is that it’s important that your selection of control panel software supports the guidelines that Microsoft has now put in place for automation and management of Exchange. If they don’t, then it’s likely that their software will run into problems (yet to be determined) in the future. Your ISV should be able to respond to the question about support for Microsoft’s guidelines.
So, let’s suppose if I choose MachSol’s solutions that they call MachPanel, should have implemented guidelines of Microsoft within it? Here is what could make me a bit confuse…if I use an automation solution that works perfectly fine and fulfills all of my requirements why should I be worrying for guidelines of Microsoft and what advantage I may have if guidelines are followed in automation solutions? I am asking so because I am using a custom app for Exchange 2007 management that does a lot and just perfect for me to make money out of Hosted Exchange business, If somehow I manage to get a custom app for Exchange 2010 SP2 and that does not follow the guidelines but works perfect for me like any off-the -shelf control panel solution as MachPanel (I just know now) then what disadvantage comes in?
So let’s assume that you select a solution from any vendor. The first thing that you look for in any purchase is a guarantee that it will endure. In this context, a solution that cannot (for whatever reason) support Microsoft’s guidelines is a risky bet because you’re assuming that a) it will be strong enough to prosper on its own even as Microsoft attempts to move the providers of hosting software towards their vision, or b) that Microsoft will fail in their effort and the world will revert to the point where everyone does their own thing when it comes to building a framework to manage a platform for hosted Exchange.
I think a) is unlikely, at least over the long run. Anything can happen in the short term because Microsoft’s effort to convince hosting providers about the way forward only really began with the run-up to Exchange 2010 SP2 and the decision to stop production of the hosting mode for Exchange 2010. So we’re in a situation where people are making up their minds. However, given Microsoft’s pretty strong advice on the topic, I think that the world will evolve towards using the framework proposed by Microsoft. If you look at their blog post of December 6, Microsoft said:
“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.”
“… 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.”
The guidance seems pretty straightforward and sensible so I don’t think b) (failure) will occur if only because Microsoft is likely to use much of the same advice in their own deployment of Exchange within Office 365. I also see the prospect of positive feedback from Office 365 into future advice from Microsoft.
So, you can go and do your own thing or select a vendor that has some secret sauce that runs contrary to the position now taken by Microsoft, but I think it’s a risk. Your call.