Exchange 2010 “Organizational Health” and the phantom ECAL

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.