Paul's Down-Home Page

So, a brief rant about Exchange ActiveSync (EAS).
Nearly ten years ago, Microsoft developed the what we now call the EAS protocol. For a while, they licensed it only under a strict NDA. Now they have documented it. As far as I can tell, they still license it, so not just any random knucklehead can use it. The server implementation of EAS in Exchange 2010 (and earlier versions) behaves in a predictable and mature manner. The clients? Not so much.
Each device or software vendor implements their own EAS client. There’s no standard library or toolkit that you get as part of the license. There also don’t seem to be any restrictions or requirements. Two manufacturers can choose to implement wildly different levels of EAS support, yet they’re both able to claim that they support EAS.
In general I’m OK with that in principle. After all, different vendors compete on price, functionality, quality, and a host of other factors. If a vendor wants to skimp on their EAS implementation
(oh, yoo-hoo, Mr. Jobs… please pick up the white courtesy iPhone) they are free to do so. That’s just one aspect of the mobile device marketplace.
In practice, though, this is one of the most frustrating parts of supporting mobile devices with Exchange. First, tere is no central source listing the degree of EAS support provided by individual vendors. Second, and much worse, Microsoft doesn’t require a minimum degree of EAS support or require any particular features. Contrast this with the various Windows logo programs that Microsoft offers.
In Microsoft’s defense, I’m sure they work with their EAS licensees to try to get them to do the best job possible on their clients. However, the results would indicate that this has not been very successful. Consider the flap around encryption policy support on the iPhone 3GS, or the Palm Pre’s lack of support for password policies, or the morass that is the Sony-Ericsson EAS implementation. Clearly there’s more work to be done here.
Until then, Exchange now provides EAS device access rules, more about which in a future post.

Exchange 2010 DAGs support encryption and compression of the mail data they pass around as part of the seeding and replication process. How do these capabilities work?

The short answer is “it’s a Windows thing.” Exchange uses the encryption and signing methods provided by the underlying Windows OS whenever possible. In the case of SSL/TLS, Exchange can do much of its own certificate management (including generating its own self-signed certificates), but all of the actual crypto is done by Windows.

In the case of DAG encryption, Exchange uses the Kerberos implementation included in the Windows Kerberos security support provider (SSP). The SSP provides routines that allow clients to encrypt, sign, verify, and decrypt messages containing arbitrary application-specific data. Once the two endpoints have concluded a handshake and key exchange, they can both make calls to process the data blocks.

Exchange always tries to pick the strongest possible algorithm from the list of those supported by the host OS. For Windows Server 2008 and 2008 R2, that means AES 256-bit, ideally with SHA-1 used as an HMAC.

On the compression front, DAGs use the familiar LZ77 algorithm. Microsoft internally calls their implementation (described on page 45 here) “XPRESS”, for some reason that I haven’t been able to figure out.

Outlook uses many of these same mechanisms; for example, MAPI RPC compression between Exchange and Outlook uses XPRESS too, and MAPI RPC encryption can use the Kerberos SSP (or the NTLM SSP, but that’s not available for DAGs.) That’s no big surprise, given that these capabilities are built into Windows. Why reinvent the wheel?

In terms of how you control these options in a live DAG, Set-DatabaseAvailabilityGroup is your friend. By default, newly created DAGs will use encryption only when replicating across different subnets, with no encryption used during seeding operations. You can change this with the NetworkEncryption switch; just set it to Enabled instead of InterSubnetOnly. In like manner, compression is normally enabled only for cross-subnet replication, but the NetworkCompression switch will let you fix that right up.

Note that these properties are associated with the DAG itself, not the underlying DAG network. For that reason, you can only set these properties when the DAG (and its underlying WFC nodes) are up– the settings are node-level properties.

What about using IPsec with DAGs? That’s a topic for another post!

From the reader mailbag:

Can you recommend books or training on Exchange 2010?

Why yes, I can!

My current favorite Exchange 2010 book is from Jim McBee and David Elfassy: Mastering Exchange Server 2010. It’s a solid overview of the key features and technologies in Exchange 2010, although I’d like to see a second edition with more coverage of DAGs.

As for training, I don’t have much to say on that topic at the moment, but I hope to in a few weeks.

I’ve been busily building out a shiny new Exchange 2010 setup at work, with Windows Server 2008 R2 as the base OS. I spent some time this morning puzzling over why I couldn’t add a second server to a DAG. It turns out that the Exchange Trusted Subsystem group doesn’t have the needed permissions under R2; to fix it, you have to add that group to the Administrators group. I found this out by poring over many a dreary Google search result, but if I had looked here first I would have found the solution faster.