Multiple license problem

We are running ERAS 3.1.11, and I'm having a problem with the 4 license keys we own. We bought all 4 keys at the same time from the same vendor. The 4 keys are:

ESET Mail Security for Linux - 5 computers
ESET File Security fo Linux - 400 computers
ESET NOD32 Antivirus Business Edition - 460 computers
ESET NOD32 Antivirus for MS Exchange - 400 computers

I'm running into a problem with getting all of these keys into the License Manager in the ERAS. I've uploaded all 4 keys using the License Manager, but it is only displaying the NOD32 Business Edition license. It's not showing the other 3 when I click the details button.

What's happening is that all of the Linux machines that connect into the ERAS are consuming only the NOD32 Business Edition licenses rather than their Linux licenses. So the ERAS is now saying we are out of the 460 licenses.

We included the Linux license file in our deployment of the Linux installs, and those local Linux installs are accepting the Linux license file just fine. In fact, they won't run without the license file in place. So, the Linux installs on each machine are correctly using their Linux license file. So *why* are they consuming our Windows licenses when they check in with the ERAS?

This makes no sense. They are consuming licenses for a completely different product!

 

Hey jreiter,

This is a licensing issue which you may want to contact your local ESET vendor about to see if they can correct this for you.

Yes, your linux file server will definitely need the license file to operate but unfortunately the linux license file will not function properly in ESET RA's license manager. It will only take ESET's business edition licenses (i.e. NOD32 Business Edition license file). You can't really combine licenses together unless they are of the same product and you are either increasing the number of workstations or extending your expiration date.

Again, contact your local ESET vendor and see what they can do for your licensing issue.

 

Ah, I was afraid that would be the issue. So here's what we're faced with:

1) I can't import our Linux licenses into the RAS.
2) When a Linux client connects to the RAS, it gladly consumes a Windows client license instead.
3) The Linux clients still require a Linux license in order to run, despite also consuming a Windows license in the RAS.

Since this sounds like a major bug/design flaw in ESET's software, we may only have two options:

1) See if our vendor will give us an additional batch of Windows client licenses for use in the RAS in order to offset all the Linux clients we have, just so the RAS doesn't think we are out of licenses.
2) Don't have the Linux clients connect to the RAS.

Neither of which is a very good way to handle things.

 

Just out of curiosity how does the key for Exchange work? You have the Exchange antivirus installed, and each mailbox consumes a license or what?

 

I haven't actually rolled out the Exchange piece yet, so I can't comment on how it happens. We do have a separate Exchange license file, though, which I'll apply to the local Exchange config. We'll see how it works. At this point, though, it won't be able to connect to the RAS regardless since the RAS thinks all of its licenses are consumed, and therefore doesn't allow any new connections from new clients.

 

Just an update for anyone following this bug. After escalating the problem within ESET's support department, I was finally told that this license issue is a bug with ERAS. Just as I mentioned above, ERAS only supports importing Windows license files. However, it will consume a Windows license for *any* client that connects, regardless of the client operating system.

To work around this bug, we basically had to do option #1 that I posted in comment #3 up above. Our ESET sales rep had to issue us an additional Windows license file containing the same number of licenses as we have for our Linux installs. To clarify:

We have 400 Linux clients and 460 Windows clients. To make that work, our sales rep had to issue us a 400-count Linux license file and an 860-count Windows license file. I then imported the 860-count Windows license file into ERAS. So now, when all 860 of our clients (both Windows and Linux) connect to ERAS, there are enough Windows licenses to go around. Note that we only paid for 400 Linux clients and 460 Windows clients. We did *not* have to pay for 1260 clients, as that would've been ridiculous.

 

Wouldn't your rep have retracted the 400 linux license files since they aren't needed because of the bug?

Effectively all you needed was 860 windows licenses, right?

 

We actually still need a Linux license file, since the Linux client doesn't appear to run without that file in place.

 

Interesting. None of my Windows clients actually have the .LIC attached to them, the .LIC is simply imported into ERAC/ERAS.

Do you have to push the .LIC in the Policy to the Linux machines, or just have it imported into ERAS/ERAC?

 

On the Linux clients, we have to push out the license file with each individual install. The Redhat client wouldn't appear to even function without the license file in place on each machine. We actually ended up heavily modifying the rpm provided by ESET to make it more robust and reliable across different Redhat versions. The original rpm was created in such a way that it did not work on certain Redhat versions. But anway, we manage remote installs via a custom rpm management system we use here, and then we push out the license and config files via a custom rsync system. We already had the rpm management and rsync systems in place for everything else we do, so rolling ESET's package into it wasn't too bad. (Other than the somewhat broken rpm.)

We actually don't manage the linux clients at all via the ERAS. The linux clients do report in to the ERAS just fine for virus tracking and statistics purposes and to get definition updates, but the linux admin team actually handles pushing out all installs and configuration policy management of those clients using our custom management systems mentioned above. The ERAS doesn't push out any policies to those linux clients. We actually did try that once, and it didn't work. Since it wasn't something we really wanted to do anyway, we just moved on.