It's possible that the license on the agent became invalidated somehow - the license is based on the hostid - which is based on different items depending on the os. if the hostid changed for some reason the server would become unlicensed.
the licensing site shows the date a server was licensed (when the autolic was run) - but after that there is no communication to the licensing site - there is no auto-syncing.
what OS are these servers?
This occurred on a couple dozen servers running following OS...
None of the host id's changed since running autolic. I'm going to re-license today and monitor. Thanks for the feedback.
My licenes went away on my nodes as well. Nothing changed...
For licensing purposes in a Windows environment, the host is identified by the serial number of the disk volume. For instance, if the volume "C" has a serial number of abcd-efgh, that's keyed to the license.
This procedure is different for other operating systems - further information can be found here:
Other things which could affect the license are:
- The agent's ACL; if the ACL isn't set up correctly, you won't be able to license the managed host.
- Is it possible the Windows GPO changes interfered with the agent ACL? IIRC, the GPO changed the name of the Windows administrative account.
- Of course network connectivity to the managed host and from the host doing the licensing to the internet is required also.
I also have this problem from time to time, and haven't been able to track down the reason.
none of the suggested caused seems to apply.
I resorted to running an autolic job nightly onto a smart group built of "agent state" = "unlicensed"
It seems to me that a licensing scheme based on agents number and located totally on the appserver would be more manageble
We have seen the same issue and it appears to be caused by the agent itself. Stopping and starting the agent service fixes this issue at least for us. We have seen this issue with agent version 7.3.057 and 184.108.40.2063. We have upgraded one of the windows boxes to 220.127.116.113 two weeks ago and so far we have not yet seen this issue again.