Sometimes I have been accused of being a “yes man” for the Exchange development group; someone who thinks that everything Redmond (the development group in the town rather than myself) does is good in terms of advancing the Exchange product and is slow to offer criticize. I happen to believe that this is untrue and of course I would, but I’d also offer my trenchant views over the years that Microsoft had to improve in terms of automation within the Exchange, remove the need for administrators to configure options through registry hacks, and to improve documentation. Indeed, I attended a very interesting internal meeting with Microsoft in Whistler, Canada in early 2004 to discuss just these points because Exchange 2003 was full of registry hacks, required too much administrative intervention, and had abysmal documentation. We’ve come a long way since then with advances such as a heartfelt and in-depth embrace of PowerShell through the Exchange Management Shell that enables administrators to automate operations in both Exchange 2007 and 2010, a gradual elimination of registry updates in favor of somewhat obtuse but accessible configuration files in addition to those manipulable through PowerShell, and a radical and pleasing upgrade of the product documentation on TechNet and elsewhere. I guess the consistent and ongoing criticism has been listened to by some of the developers…

Anyway, back to the point in hand, which is that the development team announced that they will ship Service Pack 1 (SP1) for Exchange 2010 later on this year. When you read the contents of the blog post used by the Exchange development group to announce Exchange 2010 SP1 (http://msexchangeteam.com/archive/2010/04/07/454533.aspx), you’d be forgiven if the thought that the version now available wasn’t fully baked when Microsoft released it in October 2009. To be blunt, SP1 is a huge and absolutely required upgrade for Exchange 2010 because it finishes off many of the most compelling and interesting features introduced in the RTM version.

Take Role-Based Access Control (RBAC) for instance. RBAC is at the heart of the Exchange 2010 authorization model and it’s a fundamental concept for administrators to understand as they approach a deployment. However, the Exchange Management Console (EMC) doesn’t allow you to manage RBAC components such as roles, role groups, and role assignments. Instead, you have to use the Exchange Control Panel (ECP), only to find that ECP offers limited ability to create new roles and manage role groups and assignments, which means that you’re forced to use Exchange Management Shell (EMS) cmdlets if you want to do any real work with RBAC. SP1 changes the picture completely by providing an enhanced user interface that makes RBAC much more approachable and easier to manage. Creating a new role group is now literally a point and click exercise that takes minutes where previously grappling with EMS cmdlets might have taken hours to achieve the desired effect.

Retention tags and policies are another example. Exchange 2010 forces you to do all the work to create new retention tags and policies through EMS. This is OK as long as you’re used to EMS and figure out what has to be done with the various cmdlets that you have to use. But then you see the new UI exposed in EMC by SP1 and you realize that creating and implementing retention policies is now a matter of running a couple of wizards. What could take hours to do now takes minutes.

The changes made in SP1 demonstrates that Microsoft has also learned from experience and user feedback from the RTM version of Exchange 2010. Discovery searches are a good example. These work well in Exchange 2010 and it’s easy to create a search that will scan every mailbox in an organization for evidence of wrongdoing. However, such a search might return tens of gigabytes of items to the discovery mailbox where search results are stored, which immediately strains the server that hosts the discovery mailbox because it has to handle the sudden load of copying all of the discovered items. SP1 improves matters by allowing administrators to perform an estimated search first to discover how many items will be uncovered if a full search is executed. You can then tune the search criteria to find more or less items as desired. And you can deduplicate search results by telling Exchange to copy only a single instance of a discovered item rather than the duplicates that might be stored in multiple mailboxes. These are small but important tweaks that make life easier for those who have to interpret search results and respond to legal subpoenas.

Lots of attention will focus on personal archives and the news that you can now place a personal archive in a separate database from its primary mailbox. This is good because it creates a lot more flexibility for administrators in terms of the ability to group archives into specific databases that might run on low cost storage or even use specific servers that do nothing but host archives. Upgrading Outlook 2007 to be able to access personal archives is a brain-dead decision that removes a huge deployment blocker for many organizations that simply are not interested in deploying Outlook 2010 until they have had a chance to test the new software thoroughly and prepare users for its deployment. Microsoft hasn’t given any details yet about how they will provide the upgrade for Outlook 2007, but I expect to see it released as an update for Outlook 2007 SP2 or even incorporated into the next service pack for Outlook. Or maybe Microsoft will just issue a hot fix. We shall see in good time.

I also like the news that SP1 includes new cmdlets to allow administrators to import data into a mailbox from a PST without having to install Outlook onto an Exchange server. This makes it much easier to convince users to move from PSTs that are invisible from an administrative perspective to use online personal archives that are searchable, indexed, and manageable. Cmdlets will also be available to export mailbox data to PSTs.

On the client side, the changes made to OWA make what was an attractive client better performing and better looking. Some features that should have been in the initial release (calendar printing!) are now there and the availability of customizable themes allows users to express a little more control over their web-based client. My personal favorite is the “herding cats” theme. It’s debatable whether making the interface refresh before actions such as deletes are confirmed by the server, but you can argue an excellent case that most actions will happen without incident so it’s safe to go ahead and refresh to make performance better for users – in other words, it’s an acceptable risk.

All in all, there is much in SP1 that recommends it for early deployment after Microsoft releases the code later on this year. It’s just a pity that the features that SP1 brings to the table weren’t available in the first version of Exchange 2010. This stance isn’t being apologetic for Microsoft; it’s a reflection of the state of play – we would have welcomed these features in the first version of Exchange 2010 released in October 2009, but it’s a hard fact of life that sometimes engineers can’t complete features in time at an adequate quality level to warrant inclusion into shipping software. That’s why service packs come out. At least SP1 will deliver real value – and it comes at a time when companies will have had time to prepare for their deployment of Exchange 2010 and have worked out all the kinks that get in the way such as the need to upgrade their Windows infrastructure to Windows 2008 SP2 or R2 and use new servers because in-place upgrades are not supported (and probably impossible) to move a server from Exchange 2003 or 2007 to 2010. In any case, we can look forward to SP1 when it appears later on this year.

– Tony