There are a number of reasons why Licence Server (LS) licences may be revoked, accompanied by the RVOK, RALL command, however, first it's best to understand how Licence Server is intended to work.
Client (Impact or nServer) communication is initiated on the TCP/IP port configured within LS, and in the client-side configuration. Within LS Administrator, we can also specify the first UDP port and number of listening ports.
The TCP communication between client and LS is used to identity which licences are available, and to request the allocation of an available licence. Along with licence allocation, LS instructs which UDP port the client should listen on for keep alive PING commands. After this, TCP communication ceases.
The LS continually PINGs each client (~every 30 seconds) on the instructed UDP port, to ensure they still require the granted licences. A message is sent for each licence granted to a client (on some clients, multiple instances of Impact could be in use across different Windows sessions). The client responds to these messages by returning an ACKP (ACKnowlege Ping) message.
The most common issue is therefore that the keep alive PINGs are never received by the client, thus no ACKP response is returned.
Without a keep alive message, the client has to assume LS is no longer issuing the licence, and will self-revoke after 90 seconds. Similarly, without a client response, the LS assumes the client is now offline or not in use, and will revoke (deallocate) the licence, to free it up for the next client.
90% of the time, revoke issues are due to the UDP messages from the server not arriving at the client due to one or more Firewalls (server, client or inbetween) blocking the LS to client PINGs.
This would be indicated by a number of UDP Out PING entries in the LS log (where enabled), with no corresponding ACKP response (e.g. UDP In (xxxx): ACKP) from the client, e.g.
Server thread 2316 10.250.250.10:0001 UDP Out (3001): PING:724f9f59-4262-44a6-8cb2-954107cae8a9:2308346125:2 Size: 91 bytes
Server thread 2316 10.250.250.10:0001 UDP Out (3001): PING:724f9f59-4262-44a6-8cb2-954107cae8a9:2308346125:2 Size: 91 bytes
Server thread 2316 10.250.250.10:0001 UDP Out (3001): PING:724f9f59-4262-44a6-8cb2-954107cae8a9:2308346125:2 Size: 91 bytes
A healthy exchange would instead appear as follows:
Server thread 2316 10.250.250.10:0001 UDP Out (3001): PING:724f9f59-4262-44a6-8cb2-954107cae8a9:2308346125:2 Size: 91 bytes
Server thread 2316 UDP In (3000): ACKP:724f9f59-4262-44a6-8cb2-954107cae8a9:2308346125:2 Size: 91 bytes
Server thread 2316 10.250.250.10:0003 ACKP licence 'Temporary Impact' maintained
Refer to the article TCP/IP and UDP Ports for details about which ports Firewall exception rules must be configured for.
Of course, if the PING messages appear in the client licence log, but the ACKP messages do not reach the LS, this would indicate a problem with Firewall ports in that direction of travel only.
Other contributing reasons PINGs not getting through are often due to conflicts with port allocation or reuse (conflicts) of the same listening ports as other applications or services on the LS or client.
From a command line (running as the local Administrator), you can run the following command to see ALL ports (' -a' switch) are in use, and which application ('-b' switch) created by each connection or listening port, and by which running process (ID) ('-o' switch). TCP entries are listed first, followed by UDP entries.
netstat -a -b -o
Example output (LS):
[sqlbrowser.exe]
UDP 0.0.0.0:3001 *:* 7124
[Impact.exe]
UDP 0.0.0.0:3020 *:* 3540
[dllhst3g.exe]
UDP 0.0.0.0:3020 *:* 1275
[LicSrvr.exe]
UDP 0.0.0.0:3021 *:* 7744
[LicAdmin.exe]
UDP 0.0.0.0:3022 *:* 1216
This example shows a mixture of Impact and nServer (dllhst...) client, as well as Licence Server Administrator connections, communicate across various ports.
Notice above that the sqlbrowser.exe is operating on the default 'First UDP Port' of Licence Server, so here that's been altered to start at 3020 and operate on 5 UDP ports above that.