Counting Client Access Licenses

Software licensing is hardly a sparkling topic with which to begin the New Year, but like taxes, it's important to pay enough but not too much for the pleasure of connecting to Exchange. You'd think that Microsoft would help by providing a CAL reporting facility. Well, that didn't work so well in Exchange 2010 and no equivalent feature exists in Exchange 2013... until one came along from a nice MVP.

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

Discuss this Blog Entry 3

on Jan 16, 2014

What about Admins? "Best Practice" is for admins to have a non-admin account for normal tasks, and a seprate admin account for admin tasks. Exchange 2010 means they now need two mail boxes. As its a "single person" owning both mailboxes and the licence says "per person or device" not "per mailbox" I assume they only need one CAL?

If so any of the CAL counting tools are a waste of time....

on Jan 16, 2014

An administrator does not need a mail-enabled account to work with ECP (for Exchange 2010) or EAC (for Exchange 2013) or EMS. All you need to do is to add the non-mail enabled account to the appropriate RBAC group. All of which means that you only need one mailbox for the admin's personal use.

on May 5, 2014

I have 2 VM's - (1) Server 2012 R2 Essentials with 25 Users, (1) Server 2012 R2 Exchange 2013 with 15 user licenses. When I installed Exchange 2013 it added 9 users to Essentials putting me over my user limit of 25. All 9 are exchange related management users like (3) healthmailboxes, (5) M.Exchange: sm_xxxx, (1) $IJ3000-GBOMN031S5OI. Is there a way to change these "Users" or remove them without hurting Exchange 2013 operations?

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×