Paul's Down-Home Page

Now this is a neat idea; I wish I’d thought of it.

Microsoft’s released the Exchange 2010 Deployment Assistant, a web site that interviews you about what your deployment plans are and then assembles a customized subset of the Exchange 2010 documentation for you.

You start by indicating whether you’re moving from an existing deployment (either 2003, 2007, or mixed) or creating a new one. Once you’ve done that, you answer questions (such as "will you be using public folders?" or "do you plan to deploy unified messaging?"), and you get a checklist like this one:

The tool is clearly still in the early stages of development; it only includes content for upgrading from pure Exchange 2003 environments. However, it’s an improvement over the old deployment wizard in two major ways. First, it’s more highly customized for your particular migration plans. Second, it gives you a single point of access to everything you need to know about a particular topic (like installing a mailbox server).

I’m looking forward to seeing how the product group improves the tool in future releases. Check it out and you’ll see what I mean.

I’ll ignore the easy route of poking fun at Cisco’s massive product introduction. 61 collaboration and communications product? That’s not a strategy; it’s a yard sale. Even IBM does a better job at acquiring others’ technologies and making them into something cohesive (well, except for Workplace Messaging, but why beat that dead horse again?) Instead, I want to dig a little deeper into Cisco’s announcement of Cisco WebEx Mail—not too deep, since I haven’t had time to watch the videos from Cisco’s virtual launch event. They won’t play on Windows 7, using either IE8 or Firefox 3.5. Oh well. (Also: Cisco, your video portal is weak sauce compared to PKS. Call 3Sharp, stat!)

WebEx Mail is based on Cisco’s PostPath acquisition. After the purchase, my guess was that Cisco would turn PostPath into an e-mail appliance that could nestle in a rack next to other Cisco gear. Turns out I was wrong; instead, Cisco’s turned it into a hosted service. This is an interesting play for a couple of reasons. One is that a historic PostPath weakness is the admin experience. Keeping customers from being exposed to that level of awfulness is a great idea. Another is that offering a black-box hosting solution plays to PostPath’s strength: mostly seamless interop with Outlook.

If you compare the last release of PostPath (which emulated Exchange 2003) to Exchange 2007, you could argue that some of the storage and performance improvements in Exchange 2007 were obviated by the fact that PostPath uses a completely different method of message storage. However, in the testing Tim and I did, we documented lots of other Exchange 2007 improvements (PowerShell, CCR/SCR, full Exchange ActiveSync support, and MRM, to name a few) that PostPath didn’t have.

In the interval since Cisco bought PostPath, I’m sure they’ve made improvements. So has Microsoft, though. Exchange 2010 offers a number of hosting-oriented features, but the biggest is probably the option to have seamless interoperability between hosted Exchange and on-premises servers. Being able to do an online mailbox move between the cloud and your own server room is pretty darn useful. I haven’t seen enough details to tell whether Cisco’s claim "frictionless migration" is real or baloney. In addition, Exchange 2010 offers a very powerful set of confidentiality tools: between Outlook protection rules and IRM in transport rules, you can easily set up an environment such that your hosters can’t read your mail, no matter their motivation.

Another area where WebEx Mail appears to fall short: integration. Of course, we’re all familiar with the integration between Outlook, Communicator, Exchange, SharePoint, and other MS products. Less familiar is the fact that you can take advantage of that integration using Microsoft’s BPOS hosting offering, too. Does Cisco have an equivalent? Not that I can tell. Are they working on one? My guess is yes, but delivering a seamless experience is not an easy problem to solve, and Cisco is hampered by having lots of individual products that have to be sewn together. Seems like MS has a clear lead in this area.

Props to Cisco for describing their security infrastructure, though. This white paper makes clear what security measures they use for various parts of their system. In particular, they call out security policy, physical security, and auditing, and they mention that they follow the NIST STIGs for server hardening. This is just the kind of detail that we need to evaluate cloud-based service security, and it stands in sharp contrast to Google, which says nothing about their security. Even Microsoft basically says "hey, we’re SAS70 certified, trust us"—they can do better.

Bonus interlude: Windows 7? What’s that? Cisco apparently never heard of it.

One last thought: terrible name. Most people who know the WebEx brand associate it with conferencing, not e-mail. Most people who know the Cisco name don’t associate it with WebEx (and probably vice versa). Surely Cisco could have done better than this. I’m reminded of the old Jerry Pournelle jape about AT&T: if they bought Kentucky Fried Chicken they’d advertise it as "hot, dead chicken."

I’ll have more to say about WebEx Mail once I’ve had a chance to dig into it more thoroughly.

There’s been quite an active thread among Exchange MVPs and TAP participants about the implementation of a new feature: the Exchange 2010 Organizational Health Check. It turns out that this new feature has a problem that makes it even harder than usual to decipher Microsoft’s licensing requirements.

Quick recap: Exchange 2007 introduced the idea of the Enterprise client access license (ECAL) for Exchange (though the introduction was not without hiccups). The ECAL is an additional license that you had to buy in order to use certain features, like unified messaging or the enhanced Exchange ActiveSync policies. ECALs are additive, so you must buy both a standard CAL and an ECAL for every user that needs one of the premium features.

Exchange 2010 retains the same edition and ECAL structure that Exchange 2007 had. That’s fine and good. Exchange 2010 also adds a new features, the Organizational Health view (see Figure 31 here). This view is supposed to summarize how many CALs you have versus how many you need to have…

…except that it gets the comparison wrong. If you have N mailboxes, the Organizational Health view will tell you that you need N ECALs, even if you don’t.

How did this happen? In this particular case, it’s down to Exchange ActiveSync policies. When you install Exchange 2007 or Exchange 2010, you get a default Exchange ActiveSync device policy. This default policy enables (or, more precisely, does not block) all the features on the device. Here’s what it looks like:

The text block at the bottom of the option list helpfully tells you that changing any of these checkboxes–in other words, blocking any feature that would otherwise be enabled–requires an ECAL. That’s because by changing these settings you are defining an advanced EAS policy. Fine; that’s the way it was in Exchange 2007 too.

The difference is that whoever wrote the Organizational Health view apparently didn’t know this, so it tallies up 1 ECAL per defined user–even if that user doesn’t have an Exchange ActiveSync device, or if you haven’t changed the policy settings. Therein lies the bug. The data displayed in this view comes from the Exchange Best Practices Analyzer tool, but I believe that it correctly counts CALs and ECALs in its current incarnation.

The bug led one prominent MVP to say that the “entire counting process is screwed up and useless,” which is hard to disagree with in this case–but it gets worse. Unified Messaging is another feature that requires the ECAL. However, the Organizational Health view ignores UM-enabled users, so changing the UM enablement state of your users doesn’t change the number of ECALs that it thinks you need.

Fortunately, Exchange doesn’t actually enforce any of these restrictions. The license may require you to buy ECALs for particular users, but Exchange won’t stop working (or even degrade its functionality) if you don’t do so. You can use this script to estimate your CAL and ECAL requirements (it hasn’t been updated for Exchange 2010 yet, but it should be soon). However, I wouldn’t recommend making licensing decisions based on the Organizational Health view at this point in time.

Suppose that you wanted to allow your users to play back voice mail through Outlook Voice Access 2007, but that you didn’t want them to have access to their e-mail. That was the question I recently got from someone who was replacing their old Avaya system, in part because they didn’t want people to get their e-mail over the phone.

(To me this is sad; I depend heavily on that feature, but different strokes and all that.)

The trick is to use the -TUIAccessToEmailEnabled flag to Set-UMMailbox (“TUI” stands for “telephone user interface”, in case you were curious.) A little of this:

Get-Mailbox | Set-UMMailbox -TUIAccessToEmailEnabled:$false

and you’re done! There are also separate parameters that control TUI access to the calendar and contacts folders.

Exchange 2010 improves on this in a couple of ways.

First, instead of applying the fix to individual users, you can apply it at the UM mailbox policy level. Poof! Instant consistency.

Second, you can control user access to their personal contacts and the organization’s GAL separately. Where Exchange 2007 lumps both together with TUIAccessToAddressBookEnabled, Exchange 2010 gives us AllowTUIAccessToPersonalContacts and AllowTUIAccessToDirectory.

There are lots of other improvements in Exchange 2010 UM, some of which I’ll be writing about in the not-too-distant future.

From the "man, I can’t believe I haven’t written about this yet" file…

Exchange Unified Messaging can make phone calls. (OK, OK; I did know that much!) For example, when you call in to Outlook Voice Access, you can ask Exchange to place a call to someone who’s in your personal Contacts folder, or in your organization’s GAL. It turns out that you can harness this feature by writing code to have Exchange UM place calls for you… sort of.

"How does it work?" you ask. Good question. It’s the same as the mechanism that Exchange uses to route calls through an auto-attendant. Let’s say that Alice calls the main number at Contoso. Alice’s device connects to the PSTN, which routes the call to the Contoso PBX (or OCS server, whichever; it doesn’t matter for our purposes).

The PBX sees the inbound call, consults its call coverage map, and sends the call to Exchange, which answers it and triggers the auto-attendant. If Alice requests Bob’s extension (or does anything else that requires the attendant to route the call, as opposed to just playing prompts and recording responses), Exchange will make a SIP request to the PBX asking that the call be transferred.

It turns out that Play on Phone uses the same trick. In fact, there are several other cool things you can do with the UM web service: play messages, reset user PINs, and play greeting messages among other things. This article has a summary of the things you can do, along with some (.NET Framework-based) code showing how to do raw SOAP calls and to use them to connect to the UM service. (There’s sample code for using the web service here, too, if you’re the coding sort.)

The article, sadly, doesn’t mention the power of Autodiscover, which is what you can and should use to find which UM service a given user should be connecting to. Regular users of Exchange Web Services already know that, however.

It’s too bad that you can’t use this feature to place a call to an arbitrary number and play whatever content you want (although that would be easy to do with Speech Server). Still, it’s a useful capability; I’d love to see an iPhone app that would tell the Exchange server to Play-on-Phone all my voice mail messages.

Here’s an executive summary of the way Apple handles multi-part messages in Snow Leopard’s Mail.app.

Here’s the problem. Say that you use Mail.app to compose a message that has some text, then an inline image (or PDF; doesn’t matter), then some more text. What you’d probably expect is that it would display properly in Outlook, OWA, and other non-Apple mail clients. What you get instead is rubbish.

It turns out there are two ways to construct a MIME message with multiple parts, and at least two ways to put them back together again. Exchange and Outlook use one method: the messages they generate are tagged as MIME multipart/related, and inline attachments are referenced as separate parts. The body text for the entire message is one contiguous block, with "cid:XXXX" references to the inline items. Outlook or OWA are responsible for rendering the inline images. Apple Mail uses the other method: inline attachments are tagged with "content-disposition:inline". Any blocks of content after an inline attachment are created as separate message parts. The client is responsible not only for rendering the inline images, but also with taking any additional attachments and putting them inline.

What does that actually mean? Say you compose a message. The image on the right show what it looks like when you send it. The image on the left shows what it looks like to the recipient. You’ll have to click on the thumbnails to get the full versions, but you can see what I’m talking about: the Outlook user gets no cheese, no lolcat, and no text below the picture—at least not without clicking on them.

Now, perhaps I’m being too harsh by saying that Apple’s doing it "wrong". I mean, can’t we all just get along?

In this case, no, Apple is doing it wrong. One of the major features in Snow Leopard Mail was supposed to be Exchange compatibility. If you produce messages that Exchange clients can’t read, well, that’s not very compatible, now is it? There are tons of complaints about this on Apple’s discussion forums, mostly centering around Mail’s inability to read voice mail messages from Vonage– so it’s not just Exchange users who are being bitten by this.

For another day: how I used the ever-useful pickup directory to figure out exactly what the problem was.