Exchange 2010 SP1: More Than a Simple Upgrade

I'm confused by Microsoft Exchange Server 2010 SP1. Bewilderment isn't a natural state for me, so maybe the confusion results from the evolving definition of what Microsoft will or won't include in a service pack. In the past, a service pack consisted of a selection of bug fixes designed to improve the reliability and robustness of the software. New features might be introduced, but perhaps without the benefit of a GUI so they had to be controlled through registry settings or other arcane mutterings of the systems administrator. All in all, service packs were easy to understand and reasonably easy to apply.

Exchange 2010 SP1 is different. First, you have to upgrade the Active Directory (AD) schema before you can install the software. Second, although SP1 includes a stack of bug fixes, it also includes a huge amount of new functionality. Third, SP1 improves or completes much of the new functionality that appeared in Exchange 2010 RTM. In short, SP1 is much more like a full-fledged release than a mere update.

Is Exchange Now Too Feature-Heavy?

Any article that discusses SP1 has a lot of ground to cover and it's a challenge to review new features in any depth. With that thought in mind, let's make a flyby list of what you can expect to see in SP1:

These are just the highlights; there are many other upgrades throughout SP1, some subtle and some relatively obscure and restricted to particular circumstances. Granular replication is probably the most interesting advance from a technical perspective; the new OWA UI will be the most obvious change to users; I really like the new mailbox import and export cmdlets; but overall, I think that providing a GUI to manage retention policies and tags and RBAC roles and assignments will have the largest administrative impact on an Exchange 2010 organization. I'll discuss these changes in some detail later in this article.

The collective weight of these new features adds a lot to the functionality of Exchange 2010. Indeed, there are so many features in Exchange now that it reminds me of the criticism of the Office applications when people wondered just how Microsoft could stuff in any more features to products that were already bursting with functionality, some of which is of interest to only a small minority of users. Maybe we're reaching the point where the split between Exchange Standard and Enterprise versions doesn't provide sufficient differentiation for all the markets that Exchange serves and we'll end up with versions such as Exchange (Real Simple), Exchange (Slightly Complicated), Exchange (Complex), and Exchange (All the Bells and Whistles). Or maybe Microsoft's grand plan is to make Exchange so baffling that we'll all migrate to Exchange running in Microsoft Business Productivity Online Standard Suite (BPOS) datacenters!

OWA: Big, Bright, and Beautiful

There's no doubt that the benchmark for good UI design has advanced enormously since the introduction of the first web access for Exchange in 1997. Web-based email clients such as Hotmail and Gmail as well as the commercial offerings from companies such as Yahoo! advance the standard continuously. OWA's UI in the version of Exchange 2010 released in 2009 was effective and efficient without blowing anyone's socks off. The challenge therefore was to improve OWA significantly in terms of its attractiveness without losing any of its effectiveness. Microsoft has given OWA a lot of attention and, as Figure 1 shows, there's a heap of difference between the two versions.

Figure 1: A comparison of OWA's UI in Exchange 2010 RTM, top,
and Exchange 2010 SP1, bottom (Click to enlarge

A number of visual differences are immediately apparent:

As Figure 2 shows, the SP1 version of OWA also presents some common options, such as the ability to change a password, that let users keep working in OWA without having to navigate to ECP and back again to change a setting. This change is small, simple, but effective.

Figure 2: New settings you can change in OWA

Granular Replication

Exchange 2010 introduced the DAG, which is a construct based on replication of transaction data from Mailbox servers that host active copies of databases (those to which clients are currently connected) and other Mailbox servers in the DAG that host passive copies of the databases. The Microsoft Exchange Replication service is responsible for replicating the data between the servers and replaying the data into the passive copies to keep them synchronized with the active databases so they're available for failover if necessary.

Exchange 2010 replicates transaction data on the basis of 1MB transaction logs. As logs are closed off on the active server, they're replicated, validated, and replayed on the passive servers. Granular, or block, replication is a new feature introduced to minimize the delay between a transaction occurring in an active database and when it's copied and replayed to the database copies. The idea is that speeding up replication reduces the potential exposure to data loss in the case of failure between the time a transaction log is generated and copied. In this respect, a transaction log can be considered a potential single point of failure that Exchange needed to address to achieve true high availability.

On an Exchange 2010 Mailbox server, the current transaction log file is locked and the data it holds is unavailable when it's in use. Exchange 2010 SP1 still uses transaction log replication, but the log copier component includes new code that monitors the state of replication to understand when it's safe enough to begin replication at the block level as data is flushed to disk. In this context, safe means that file-level replication is proceeding without problems and the database copies are healthy. Exchange 2010 SP1 Mailbox servers take the following approach:

The same data paths are used for block replication as for copying transaction logs, which continue to be copied to servers that host database copies to ensure that the copies have complete data sets available to them. The advantage of block mode is that transactions are dispatched to the copies as soon as they're available to the log buffer of the active database. No log roll (i.e., closing off the current transaction log to force replication to occur) is required, and transaction data arrives at the servers that hold passive databases as quickly as the server hosting the active database can dispatch data across the network. Because log file replication continues and the logs are verified both on the sending and receiving servers (a verification failure causes a log rewrite), the previous potential for failure caused by a corrupt transaction log is removed.

An individual transaction might fit into a single 32KB database page. New data obviously reaches the servers that host database copies faster if the log copier only has to wait for and then copy a 32KB page instead of a complete 1MB transaction log. The benefit is less obvious for transactions generated by large, multimegabyte messages because these require the replication of a number of transaction logs. However, sufficient small transactions fit into single pages to make block replication very attractive for its ability to dramatically reduce overall replication latency.

New Import and Export Cmdlets

Immediately following the release of Exchange 2010, a great deal of hot air was generated in the Exchange community about the requirement to run a 64-bit version of Outlook 2010 on an Exchange 2010 Mailbox server in order to use the Import-Mailbox or Export-Mailbox cmdlets to import or export PST data. These cmdlets are also used with Exchange 2007 to work with PST data, and they have a dependency on Outlook's client-side MAPI provider to be able to access mailboxes. Much of the problem came about because of a disconnect between the two Microsoft engineering groups that produce Exchange and Outlook: The 64-bit version of Outlook 2010 didn't appear until six months after Exchange 2010.

Thankfully, the Import-Mailbox and Export-Mailbox cmdlets are made obsolete by Exchange 2010 SP1, which replaces these cmdlets with a new mechanism modeled after the move mailbox method. The new cmdlets are based on a new PST writer library written by the Exchange development group rather than on the Outlook MAPI libraries used by the older cmdlets, and there's no requirement to install any Outlook code on any Exchange server to import from a PST or export to a PST.

From Exchange 2010 SP1 onwards, import and export requests are managed by the new cmdlets, New-MailboxImportRequest and New-MailboxExportRequest, so you need to replace any scripts that depend on the older cmdlets if you want to run them on an Exchange 2010 SP1 server. The previous cmdlets can, of course, continue to be used on Exchange 2010 RTM and Exchange 2007 servers.

Like mailbox move requests, mailbox import and export requests are first placed on a queue and are then picked up for processing by a Mailbox Replication Service (MRS) instance running on a Client Access server in the site where the requests are created. Requests are processed asynchronously in the background. MRS can import data into mailboxes in any database or export data from any mailbox within its site. To facilitate mailbox import/export operations, all the PSTs that MRS reads or writes must be placed on a file share that's accessible by the Client Access servers. The file shares are secured against casual browsing by granting access only to the Exchange Trusted Subsystem; read-write access is required for export, but only read access is necessary for import. All exports generate Unicode-formatted PSTs, although Exchange can read both the older ANSI-formatted as well as Unicode PSTs when it imports data.

As an example of the New-MailboxImportRequest cmdlet, let's say we want to import a PST called Redmond.pst into the mailbox Redmond. The PST is available in the file share called \ExServer44Imports. Here's the command:

New-MailboxImportRequest  -Mailbox Redmond -FilePath  '\Exserver44ImportsRedmond.pst'  -ConflictResolutionOption KeepLatestItem  -BadItemLimit 5

The -ConflictResolutionOption says that we'll keep the latest version of any duplicate item encountered during the import (the message identifier is used to detect duplicates), and the bad item limit is set to five, which means that Exchange can meet up to five items that are corrupt or otherwise unreadable in some way and keep running the import to completion. Items become corrupt for many reasons; their properties might not be correctly populated, a software bug could have affected the item in the past, or an item might simply be very old. When I was testing Exchange 2010 SP1, I had some interesting problems importing old items that had originated on an Exchange 4.0 server in 1996.

In the following example, you can see that much the same syntax is used for exporting data:

New-MailboxExportRequest  -Mailbox 'Jim Smith'  -BadItemLimit 5 -FilePath  '\ExServer44ExportsJSmith.pst'

Public folder data can't be imported or exported using the import/export cmdlets and has to pass through a mailbox before it can be processed. You can copy items from a public folder into a PST with Outlook and then import the items from the PST into another mailbox.

Removing the requirement to install Outlook on Exchange Mailbox servers is a great step forward. More importantly, the new mailbox import and export request mechanism in SP1 is far more functional than the previous cmdlets—the only missing piece is the lack of a wizard to run these tasks from EMC; Microsoft wasn't able to complete this work for SP1, so you have to run any mailbox import/export tasks through EMS.

Remember that before you can import or export mailbox data, your account must have the Mailbox Import Export role. This role isn't assigned by default to any accounts—even those that hold the Organization Management role. A deliberate administrative action is therefore required to assign the role to the users or groups that will perform these operations. The logic here is that accessing mailboxes is a sensitive operation that should be restricted to users who really need permission to import data into someone else's mailbox or export data from someone else's mailbox. This is also true for the original version of Exchange 2010 because you need to hold the Mailbox Import Export role to be able to use the Import-Mailbox and Export-Mailbox cmdlets or run the EMC wizard to import or export mailbox data.

Retention Policies and Tags

Microsoft introduced Messaging Records Management (MRM) in Exchange 2007 to help manage email retention—and it promptly hit the rocks. MRM forces users to move items into special managed folders for retention purposes. As any administrator knows, users aren't the most biddable of communities, especially when they perceive that they're being asked to do additional work with no great benefit to themselves.

It was obvious that MRM needed to be made more automatic and administrator-driven if it were to succeed. Exchange 2010 ditched the managed folders and deployed a new system of retention tags and policies. Retention tags are attached to items to give items a retention period (e.g., 30 days) and an action that will be executed by the Managed Folder Assistant when the retention period expires. The Managed Folder Assistant, which maybe now should be called the "Retention Assistant," is a process that runs in the background. SP1 makes a change here, too, because the assistant is running constantly rather than according to a restricted maintenance window. The idea is to make sure that workload is processed as it arises rather than forcing administrators to wait for a maintenance window before retention policies become active.

A tag might be specific to one folder, such as the Inbox, or apply across all folders. A range of actions are supported, from permanently deleting the item to moving it to the Deleted Items folder to moving it into the archive. Retention policies gather tags together into convenient sets that can then be assigned to mailboxes.

All in all, it's not a bad system in concept. Alas, the execution in Exchange 2010 was flawed because it required administrators to create and manage retention tags and policies through EMS. Sure, it's easy to do if you spend the time to figure out what all the cmdlets and their parameters do, but who's got the time to figure out the finer points of the New-RetentionPolicyTag cmdlet?

In any case, Microsoft got the message and, as Figure 3 shows, has done a nice job of integrating the necessary GUI into EMC to let administrators create and manage retention tags and policies and apply the policies to mailboxes. Work that might have taken hours to set up an effective retention policy through EMS now takes minutes with EMC.

Figure 3: Retention policy tags as seen through EMC (Click to enlarge)

After a retention policy is applied to a mailbox, the Managed Folder Assistant applies the retention tags in the policy to items in the mailbox the next time the mailbox is processed. After that, users see the effect of retention tags with clear indications in the OWA and Outlook 2010 clients. Figure 4 shows an email message in OWA with a retention policy applied and indicates that the retention period for the tag on the item expires in 14 days, after which the item will be processed again by the Managed Folder Assistant and the action specified in the tag will be executed.

Figure 4: The effect of a retention tag clearly showing in an OWA
email message (Click to enlarge)

The beauty of retention tags and policies is that they offer the real prospect of automatic housekeeping for mailboxes that can keep the folders in mailboxes clear of the clutter that builds up over time. Getting users to clean out folders such as Sync Issues or RSS Feeds, let alone their Inbox, to remove redundant or unnecessary items will always be an impossible task. But apply the right retention policy, and users' mailboxes will be cleaned up automatically. There's no doubt that this is a culture shock for many people because they notice items disappearing from their mailboxes, but maybe it will help make everyone less packrattish with their email storage.

Easier RBAC

As implemented in Exchange 2010 RTM, RBAC makes many administrators wince as they contemplate the change from the previous Windows ACL–based model to a system based on roles, role assignments, role groups, and policies. It's not that RBAC isn't effective because it certainly is. Rather, it's because the vast majority of work with RBAC has to be done through EMS and not every administrator is yet fluent with the shell commands. This situation, allied to a change from local PowerShell (in which sessions run on the computer where they execute commands) to remote PowerShell (in which all sessions are channeled through Microsoft IIS, even when you're executing commands on the local computer), made the changeover to RBAC tougher than it should have been.

SP1 can't address the deficiencies in administrator knowledge, but it can provide the GUI to protect administrators from the intricacies of RBAC, and that's just what's added through a revamped Roles section in ECP. Some people will be surprised that Microsoft chose ECP rather than EMC as the management platform for RBAC. It can certainly be argued that EMC is the domain of hardcore administrative activity for Exchange, but that ignores the great benefit of delivering functionality through a web-based application that can be run from any PC that can support Internet Explorer (IE), Chrome, or Firefox. In fact, in addition to RBAC management, ECP includes functionality, such as delivery reports and management audit reports (SP1), that aren't available in EMC, pointing to a differentiation in tool choice that exists in at least the minds of the Microsoft developers if not real-life administrators.

Many of the most common administrative interactions with RBAC can now be handled through ECP. As Figure 5 shows, ECP lets administrators easily amend the roles assigned to the role groups delivered with Exchange and create their own role groups and assign them to users. You still have to use EMS to accomplish some fine-tuning for RBAC, such as replacing a role assignment with a customized role in the default role assignment policy, but SP1 makes RBAC a much easier system with which to work.

Figure 5: Working with RBAC roles through the ECP

It's also good to report that ECP debuts a set of new options in SP1. You can now set retention and litigation holds on mailboxes through ECP, you can manage ActiveSync device policies, and there's a section offering pre-packaged reports for data captured through the mailbox audit feature. In addition, ECP is the interface through which you create a group naming policy for the organization, which is yet another option that doesn't appear in EMC.

More Than a Service Pack

I began this article with a certain sense of bewilderment caused by the amount of change in Exchange 2010 SP1. That confusion hasn't gone away because there's just too much new stuff in SP1—and the amount of change will lend weight to the argument that no one should ever install the first release of a Microsoft server product because it won't be finished until the first service pack comes along. It's a sad fact that Exchange 2010 was incomplete in many ways. The good thing is that SP1 contains the fixes; the bad thing is that the amount of change mandates substantial testing to prepare for SP1's deployment.