Counting Client Access Licenses

Client Access Licenses (CALs) have a reputation for being difficult to figure out. Two exist for Exchange – the standard CAL that covers access to the basic feature set (such as being able to send and receive email) and the enterprise CAL, or eCAL, that licenses extended features such as in-place eDiscovery holds, customized ActiveSync policies, Unified Messaging, or Data Loss Prevention (DLP). The eCAL is additive to the standard CAL, so if you have an eCAL, you can use any of the functionality that exists in Exchange.

This all sounds very straight forward, so where’s the problem? As it turns out, there is no difficulty whatsoever in calculating the number of basic CALs that you need to buy from Microsoft as a CAL is required for every unique user who connects to Exchange. Well, that is until you read the Exchange Server 2013 Licensing page, which says that “a CAL is required for each user or device that accesses the server software”. This made sense in an era when people used a single Outlook client to access their mailbox. It’s not so good if you want to use Outlook, Outlook Web App, and a couple of ActiveSync clients (maybe your Windows Phone and an iPad) to access your mailbox on a round-the-clock basis.

Fortunately, you can buy per-user or per-device CALs. As explained in the Exchange Licensing FAQ, “Customers may still license Exchange Server 2013 with either per-user or per-device CALs.” Obviously, given the style of computing that we work with today, per-device CALs aren’t a great deal unless you are sure that people access Exchange with just one device.

Now that we know about per-user and per-device licensing, we can progress to figuring out how many standard CALs are needed and how many have to be upgraded to an enterprise CAL (remember, every enterprise CAL needs a standard CAL too).

The Exchange Server 2013 Licensing page contains a table that tells us what features require an enterprise CAL. It is entirely possible that you can take the table and use it to figure out your CAL requirements by examining each mailbox and determining what it uses. For example, if journaling is used, is the mailbox covered by database-wide journaling or is information captured on a per-mailbox basis? The first case is covered by the standard CAL, the second requires the enterprise CAL. Has the mailbox been enabled with an archive? If so, it needs an enterprise CAL. And so on…

As you can imagine, this kind of calculation is tiresome, boring, and prone to inaccurate counts. For this reason, Microsoft provided a facility as part of the Organizational Health feature in the Exchange 2010 management console to count and report on CALs. Unfortunately the counting code was notoriously inaccurate and never quite satisfied anyone (if you’re still running Exchange 2010, check out the TechNet script that does a better job of counting). I guess it was because of the problems with CAL calculation that Microsoft decided to omit the feature from the Exchange 2013 management tools.

But Exchange 2013 does contain an interesting cmdlet called Get-ExchangeServerAccessLicenseUser, which can be used to report the CALs required for both servers and mailboxes. For example, to report the mailboxes that need a standard CAL, run the command:

• Get-ExchangeServerAccessLicenseUser –LicenseName “Exchange Server 2013 Standard CAL”

The command will report the primary SMTP address of each mailbox that needs a standard CAL. To find out the total, use:

• Get-ExchangeServerAccessLicenseUser –LicenseName “Exchange Server 2013 Standard CAL” | Measure-Object | Select Count

Whereas to return a list of the servers which run the enterprise edition of Exchange 2013, type:

• Get-ExchangeServerAccessLicenseUser –LicenseName “Exchange Server 2013 Enterprise Edition”

It looks great, until you discover that the cmdlet has a detection problem mailboxes that need enterprise CALs. Any attempt to find these mailboxes is a value of zero. In addition, the counting CALs standard, they need to mailboxes seems pretty accurate. The problem exists in all versions up to and including Exchange 2013 CU3.

Fortunately Moazzezi MVP Oliver has published a very good script to help solve the problem. You can read all about his struggle with counting CAL and download the script in his spare time. And why is all PowerShell, you can modify the code as you like to suit the needs of your organization.



No one wants to pay too much for CALs that are never used. At the same time, it’s important that servers and users are properly licensed, so it follows that accurate counting becomes an absolute necessity. Perhaps your New Year’s resolution will be to count CALs better.