License issue in ELA

[North49Ken 0]

I noticed after upgrading to ESET ERA 6.4 (and now with 6.5) that checking Administration>Licenses my count is more than the installed copies.

Checking in ELA I see that I will have duplicates, the duplicates named "computer_name.domain.local - n"  where n is a value from 1 to (so far) 4.

This is only applying to some virtual computers (not all VMs). Some are servers running on eSXi 5.5, others are Desktops running in Workstation 11.

The phenomena only shows up after the computer reboots.

The workaround is to deactivate the license on the ELA,  run a Activate Product task on ERA and then rename the seat (removing the "-n" value.

Having to use this workaround is pretty tedious and it's not consistent, other VMs can reboot and are fine, so far it's a Server 2008R2 OS and Windows 10 OS that are the culprits.

What can I do to prevent this from occurring?

 

Thanks

[XR219 2]

I have the same issue. We are now on ERA 6.5 and there are a number of duplicate machines in ELA (in one case 4). I don't understand why, if machines are managed by ERA, they need to communicate directly with ELA at all. We have a number of machines in a DMZ which ELA reports as not connecting to the license server for x days. These machines are all managed by ERA and have been activated by ERA, so why are they even trying to communicate directly with ELA. Could this be the cause of the problem with duplicates, i.e. where the machine is communicating with both ERA and ELA for its license?

[MichalJ 434]

Hello, ESET Licensing works in the way, that ERA does not act as a license proxy / nor as "local activation server".

Upon activation, each ESET application contacts ESET Licensing Authority (internal name of EDF servers), to get "allocated seat". Seat is allocated according to the HWF (hardware fingerprint). Especially in case, when machines are running on virtualized environments, this causes duplicates. When HWF on the machine changes, it gets a new seat, however the older one is not automatically removed (for example a change of virtual network adapter, which has a different mac address).

Basically the logic is:

1. Machine with name "machine" is activated.
2. Seat with name "machine" is created
3. Machine gets a new HWF (for example was reverted using some deep-freeze), so a new HWF is granted.
4. Seat with name "machine-1" is created (seat name needs to be unique). You can see, if it is the same computer, by checking the computer name. Also, in this case "activation date" is missing (usually). Previous instances of the same machine, are no longer connecting. you can resolve this, by altering "deactivate the seats not connecting for XX days" switch, or remove them automatically.

Ideally, you should allow your computer in DMZ to connect ESET servers using the preconfigured apache http proxy, which is configured to allow only communication with ESET Servers that are needed (licensing, live grid cloud reputation services, module update servers). Alternatively, when there is no connection, use an offline file, that you can get from ERA (but in this case, computers should not connect to licensing servers at all, as it is considered as "license policy violation").

We are aware of those issues, and are planning to adjust our licensing system logic so such issues will stop occurring.

 

[XR219 2]

Hi Michael,

Thanks very much for that information, its a big help, and I understand more clearly now the way licensing works. It will be good to have a more structured method for DMZ servers in future, so I will keep monitoring the website for updates over the months ahead.

 

Many thanks.

[North49Ken 0]

 

Thanks MichalJ,

The Virtual Machines that this is affecting on my site haven't had the virtual adapter (Mac Address) changed.

You are right, both 'Activation Date' and 'Activated by ERA' weren't checked. Just Status was.

As it seems to only occur after the machines are restarted it just adds a step to check for after the windows updates.

I look forward to the changes you're making.