If you follow our Technical Hub you may have seen our earlier entry about counting GFI licenses. At that time we were just surprised but now we've got final confirmation from GFI and it seems it's not going to change anytime soon.
Problem Description
To give you a short reminder our Client bought 850 licenses of GFI MailEssentials to be installed on four Exchange 2013 multi-role servers. After installation it seems that depending on how databases with users are located licenses are getting counted differently.
Our Clients setup consists of 4 servers with Exchange 2013
Mail1 – Database1 Active, Database2 Active
Mail2 – Database1 Passive,Database2 Passive
Mail3 – Database1 Lagged Copy 1 day, Database2 Lagged Copy 1 day
Mail4 – Database1 Lagged Copy 7 days, Database2 Lagged Copy 7 days
While MAIL1 was able to get things within limits or was outside of limit with few accounts, MAIL2 was having a hard time making the limit showing a lot of accounts over the limit that shouldn't be counted at all, essentially being the same for MAIL3 and MAIL4.
After weeks of analysis by GFI support here's what they have to say:
As per Development and Product Management analysis, MailEssentials is working as per design. Everything is working as designed. The count is consistent regarding the number of users in AD and in the database mailboxes:
MAIL1 counts the number of active mailboxes in MailboxDatabase1 (below license limit)
MAIL2 counts the number of active mailboxes in MailboxDatabase2 (below license limit)
MAIL3 and MAIL4, as those don't have any Exchange Mailbox DB, counts the number of active users in the domains (above license limit).
Customer has a license of 850 users although the number of active AD users is above this number.
In all of GFI products, for licensing purposes, disabled users are not counted. This is the policy across all GFI products which has been in place through all the products' lifetime. In this case, the client wants to exclude users with disabled mailboxes. This feature is not supported and will not be added as a feature.
What that means in short: It is how it is and we're not going to change it. Use it as you want.
Solution
It seems that following statements about GFI License Counting are true:
If GFI MailEssentials can find Active Database on server it counts the licenses for that Active Database
If GFI MailEssentials can't find Active Databases on server it queries Active Directory and the result will vary a lot because what Exchange treats as disabled mailboxes it's not actually the same as returned by LDAP query made by GFI
If license counting is exceeded you're given 30 days to upgrade license with more users
What that information gets you? If you split Active Databases between all servers you can use bought licenses multiple times. Weird right? I would suspect GFI would like to fix it but that's not the plan as you've seen above. What can our Client do? Simply by spliting Active / Passive between servers will split number of licenses in use in half.
Mail1 – Database1 Active, Database2 Passive
Mail2 – Database1 Passive,Database2 Active
Since counting of licenses has 30 days grace period even if both Active databases end up for few days on same server it's enough to make sure the licenses are under the limit. GFI does recount of licenses every couple of hours but you can force recount by simply restarting all GFI services. What works fine for Active / Passive databases that are easily switched even in production time it's harder for lagged database copies as those get activated hopefully never. Since our Client doesn't use MAIL3 and MAIL4 for now we've deactivated GFI on those servers.
However those 2 servers could easily be switched if we create additional 2 databases with just 1 test user.
Mail3 – Database3 Active, Database4 Passive, Database1 Lagged Copy 1 day, Database2 Lagged Copy 1 day
Mail4 – Database3 Passive, Database4 Active, Database1 Lagged Copy 7 days, Database2 Lagged Copy 7 days
This simple step would allow us to use GFI MailEssentials on those lagged servers. Since currently we have no plans to use SMTP traffic on those servers we're not going to implement that. But who knows what will happen in future.
