Reporting Exchange Server 2010 Client Access Licenses

Exchange Server requires customers to purchase two types of licenses, server and client. There seems to be some doubt about how these licenses work. Let me see if I can cast some light onto the topic.

Exchange servers start off in an unlicensed state after software is installed on a computer. This allows servers to be used in test or trial deployments. When you put servers in production, you have to purchase a license for every server that you have in the organization and enter the 25-character license key through the Exchange Management Console (EMC) or Exchange Management Shell (EMS) using the Set-ExchangeServer cmdlet. For example:

Set-ExchangeServer –Identity ‘ExCAS1’ –ProductKey ‘XXXXX-XXXX-XXXXX-XXXXX-XXXXX’

This arrangement is straightforward and easy to understand. Interestingly, Exchange doesn’t stop working if you never enter a license key. However, after the 120-day trial period expires, you’ll be nagged by Exchange every time you start EMC that such-and-such a server is currently unlicensed but you can close your eyes and ignore the nagging and all will be well.

Client licensing is the second requirement. You don’t have to input or install client licenses, which come in the form of paper Client Access Licenses (CALs). Instead, to comply with Microsoft licensing regulations, you have to purchase sufficient CALs to cover the usage of Exchange in your organization. CALs come in two flavors: standard and enterprise. A standard CAL covers use of basic Exchange functionality such as the operation of a mailbox. An enterprise CAL is required when you want to use extended Exchange functionality such as Unified Messaging, per-mailbox journaling, or archive mailboxes. CALs are additive. In other words, an enterprise CAL is added to a standard CAL. This leads to the rule that every Exchange user needs a standard CAL and those who access extended features need a standard CAL plus an enterprise CAL. Resource mailboxes like those used for room scheduling do not require a CAL.

Confused? Well, you wouldn’t be the only one who finds Exchange CALs a headache-inducing topic. But some help is available in the form of a nice PowerShell script that Microsoft has posted in the TechNet Gallery. The script is designed to run on an Exchange 2010 SP1 server and works by scanning for mailboxes that make use of standard and extended functionality (another script is available to do the same job for Exchange 2007 servers; the code in the scripts is different and you have to use the script designed for the version of Exchange that you run).

Most of the calculations are easy to understand – if a mailbox has an archive then it obviously requires an enterprise CAL. Other calculations are more subtle. For instance, if an Active Directory Rights Management template is enabled for any transport rule, then all mailboxes in the organization count for Enterprise CALs. When it finishes scanning mailboxes, the script outputs counts for the number of standard and enterprise CALs it calculates are required by the organization.

Apart from the option of discarding the script on the grounds that it isn’t interesting to you, two choices exist for this script. You can believe its output and pay up on the basis of the numbers of CALs that it reports or you can use the script as a useful learning exercise to discover how CALs are counted and perhaps what mailboxes are reported as needing enterprise CALs. It is entirely possible that you are paying for too few or too many CALs of either flavor and it’s possible that CALs are being clocked up by mailboxes that are no longer needed. You’ll have to tweak the PowerShell code in the script to capture and output details of mailboxes that require enterprise CALs but that isn’t a difficult task for anyone who is willing to spend a little time discovering how PowerShell works in an Exchange environment.

Other options are available if you don’t like Microsoft’s script. You can use EMC to report organization data including CAL requirements or you can grab a copy of Steve Goodman’s all-singing, all-dancing Exchange organization report script and use that instead. Or, if you’re really brave, you can write your very own version from scratch.

Licensing always seems to cause problems and Microsoft licensing seems to cause more problems than most. It’s good to have tools to help you figure out what client licenses are necessary – but do take the time to check and validate the numbers reported by any script before you rush to write Microsoft a check. And remember, apart from the Exchange licenses you need, you'll also have to buy the appropriate licenses for clients such as Outlook that you connect to Exchange.