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 straightforward, 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”
Looks pretty good, until you find that the cmdlet has a problem detecting mailboxes that need enterprise CALs. Every attempt to find these mailboxes results in a zero count. On the other hand, the count of mailboxes that need standard CALs seems pretty accurate. The problem exists in all versions up to and including Exchange 2013 CU3.
Fortunately MVP Oliver Moazzezi has published a very nice script to help resolve the problem. You can read all about his struggles with CAL counting and download the script at your leisure. And because it’s all PowerShell, you can tweak the code in whatever way you like to meet the requirements 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.
Follow Tony @12Knocksinna