Category Archives: UC&C

Tony’s recent post on the history of the Microsoft Exchange Conference got me to thinking. Why is it that there is no independent Exchange conference?

“Independent” has a couple of different meanings in this context. One meaning is that of a conference that is not tied to other products. Another is that of a conference that is not sponsored by, or even closely affiliated with, Microsoft. I’d like to explore both of those meanings in more detail.

One of the things that made the MEC so special is that it focused exclusively on Exchange. At one point, the event organizers included SharePoint, but there was little synergy between the two products, and that affiliation didn’t last. Because of the focus on Exchange, there were many more opportunities for deep technical content to be presented and discussed. At the Boston in me see in 1998, I remember attending a presentation on the internals of the extensible storage engine given by Laurion Burchalll, one of the developers. It was actually at Fleet Arena, and it was very well attended. Most of the presentations at the MEC were given by Exchange program managers or developers. However, there was a sprinkling of material presented by Microsoft product support, and this was arguably the most interesting and valuable content.

Over the years, the focus on content has changed as an inevitable result of being tied to TechEd, Microsoft’s premier IT professional event. TechEd is a great show for launching products, evangelizing the features or business value of new products, or sharing some types of deployment information. However, the problem is pie.

Not literally, of course; how could pie ever be a problem? (Except when you run out of it!)

No, the problem is that Tech Ed is a pie of a fixed size. The more products Microsoft shoehorns into TechEd, the smaller the individual slices must become. For example, consider that there are roughly the same number of sessions available to cover both OCS and Exchange than used to be to cover Exchange only. Now factor and other products, like Forefront Protection for Exchange, that can legitimately claim to be part of the same product track. There just isn’t room for deep coverage of everything. The result is that interesting, valuable sessions don’t make the cut. Instead, the sessions that are chosen tends to be those that the product team believes will be of interest to the broadest audience.

That’s not a bad thing, because it means that non-Microsoft conferences like Exchange Connections and TEC have room to flourish. However, as Tony points out, there is value in having a Microsoft owned and sponsored event as the flagship for a product. In my role as Exchange Connections conference chair, one perennial frustration I have is that it is difficult to get Microsoft developers or program managers to speak. The juiciest announcements and launches are reserved for Microsoft’s own events, and internal politics often make it impossible to get the key technical support and development staffers– the folks who are most knowledgeable and passionate about their work– to come speak.  Microsoft’s marketing and PR plans often don’t allow us to get the most interesting speakers or topics covered with Microsoft’s official imprimatur.

(Side question: Microsoft still maintains a separate, unofficial conference for SharePoint, so why can’t we have one?)

Now, on to the second meaning of “independent”. The SQL Server community already has its own, completely independent event. It’s known as PASS Summit, and it is organized, sponsored by, and run by a user group of SQL Server administrators. There doesn’t seem to be an equivalent in the Exchange (or OCS) world. There certainly are user groups, but none have the national, or international, reach necessary to successfully put on such an event. I’m not sure why that is, given that the Exchange community is both large and lively, but it’s a fact nonetheless.

I think that there would be value both for the community and for Microsoft to have a dedicated conference, similar to MMS or the SharePoint conference, just for Exchange and OCS. Perhaps one day we’ll get such a conference. In the meantime, I hope to see you at Exchange Connections, which is coming up the first week of November in Las Vegas. We have some big and interesting things to talk about there, and I hope you’ll be part of it.

In case you were wondering about installing the Lync release candidate now, then upgrading it to the RTM version:

There is no supported way for customers evaluating the public bits to do this.

Normally build-to-build upgrades for pre-release software are only supported for customers who are in one of Microsoft’s early adopter programs, like the Technology Adoption Program (TAP) that various product groups run. In the Exchange 2010 (and 2010 SP1) TAP, build-to-build upgrades were fully supported, and we spent a lot of time chasing down problems that occurred because of them. In that light, the Lync product team’s decision not to support upgrades from the RC to the RTM version for ordinary users is perfectly understandable, though disappointing. (Of course, Lync TAP customers are fully supported for build-to-build upgrades.)

Having said that, I am eagerly looking forward to hearing from people who install the RC now and then upgrade to the RTM version later. I’d love to hear what the pitfalls are.

(Edit: clarified that Lync TAP customers are supported for b2b upgrades, just not the rest of us. This puts Lync on equal footing with Exchange, SQL Server, and most other MS server applications.)

I got an interesting question in my mailbox the other day, and I didn’t know the answer offhand, so I had to do some digging. I love it when that happens. The question:

I have a customer who’s using RightFax and wants to deploy Exchange 2010 in a completely virtualized environment. If they’re only using the UM role to serve as a fax gateway, i.e. no voice, then are the same processing requirements present?

Short answer: no. Although Microsoft doesn’t support virtualizing the UM server for any reason, Exchange 2010 fax should work OK in this configuration.

Longer answer: the UM server answers calls when they arrive from the gateway or IP PBX. If the call is to an extension that maps to a UM-enabled mailbox, the UM server will answer. If it hears a fax CNG tone, it will treat the call as a fax.

In Exchange 2007, this would have meant that the UM server accepted a T.38-over-RTP audio stream from the gateway/PBX and rendered it as a fax message. Exchange 2010, however, lacks inbound fax support, so instead it loads the external fax service URL (if one is defined on the UM mailbox policy) and sends a SIP redirect back to the gateway or PBX. That device then sends a SIP INVITE to the fax service, which accepts the INVITE, accepts the resulting audio stream, and generates a fax message.

If the call isn’t a fax, Exchange will record a voice message from the caller, transcribe it to generate the Voice Mail Preview data, and then send it on to the recipient’s mailbox.

Audio playback and recording are sensitive to CPU performance, and Voice Mail Preview transcription is CPU-bound; that’s why MS doesn’t support virtualized UM servers. Fax answering in Exchange 2007 requires audio recording and decoding, which is why it didn’t work well on virtualized servers. However, the overhead of sending a SIP redirect is really minimal, so this configuration should work well.

In this video from TechEd 2010 (as opposed to the other one), Paul Thurrott and I talk about Windows Phone 7 and the smartphone market wars.
http://www.ittv.net/DesktopModules/UltraVideoGallery/uvg.swf

This is pretty cool: the paper that Devin and I wrote about phishing detection actually got cited as a reference in a computer science research book.

At the risk of being a one-note wonder, I’ve complained before about not having a good way to tell what Exchange ActiveSync (EAS) features a given mobile device (or device family) supports. At TechEd this year, Microsoft’s Adam Glick told me that the Exchange team was working on a solution.

I’m delighted to point to the fruits of their labor: a Microsoft-hosted wiki page that shows what features different Exchange ActiveSync clients support. I’d like to say it makes for fascinating reading but that would be a lie. It is, however, useful, and that’s even better.

Now all we need to do is get the vendors who implement EAS to do it properly and we’ll be golden.

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.