KeyServer records various client actions in the KSUsage table. The event type is stored as an integer in the usageEvent field, and text representations of the event are in the KSTermEvent table. This document will describe the events in a bit more detail and explain when they will be written.
| 1 | obtain | license obtained | A license for a Site or Concurrent policy was obtained. This means it was issued by the server, and simultaneously used by the client. This single event for Site and Concurrent policies implies both allocation and usage, whereas Lease and Node policies have two separate events. |
| 2 | return | license returned | A license for a Site or Concurrent policy was returned. This means that at the same time it stopped being used by the client, it was revoked by the server. |
| 3 | launch | program launched | A program was launched in a situation where KeyServer had issued a policy for the program, and was able to count and enforce the necessary policy allocation. Either KeyAccess was online and in communication with KeyServer, or the policy type was Lease or Node and the client had a policy allocation. |
| 4 | quit | program quit | A program was quit in a situation where KeyServer had issued a policy for the program, and was able to count and enforce the necessary policy allocation. Either KeyAccess was online and in communication with KeyServer, or the policy type was Leased or Node and the client had a policy allocation. |
| 5 | queue | user placed on waiting queue | The user asked for a policy which had all copies in use. The KeyServer queued the user so that when a copy becomes available, the user is notified. |
| 6 | dequeue | user remove from waiting queue | The user was on a waiting queue for a policy, and a copy became available. They were removed from the queue and subsequently will be given the policy. |
| 7 | deny | program launch denied | The client tried to run a program for which the server had Products defined with Policies specifying this launch should be denied. |
| 8 | logged launch | logged program launched, no license control | A program was launched while the client was connected to the server. The program was associated with a product, but no applicable Manage policy was found. An applicable Observe policy was found. |
| 9 | logged quit | logged program quit, no license control | A program was quit while the client was connected to the server. The program was associated with a product, but no applicable policy was found. An applicable Observe policy was found. |
| 10 | launch offline | offline program launch, license obtained | A program Managed by a Site or Concurrent policy was launched offline. A policy associated with the program is recorded in the event by the server in an attempt to "count" the usage against some policy, but since the usage occured offline, there is no way to know whether if it had been online, this policy (or any policy associated with the program) would have been granted. |
| 11 | quit offline | offline program quit, license returned | A program which is ultimately Managed by some policies which was launched offline was quit. |
| 12 | logged launch offline | offline logged program launched, no license control | A program in a product with an Observe policy for this client (but no Manage policy) was either launched offline, or it was launched online, but the corresponding quit ultimately happened offline. |
| 13 | logged quit offline | offline logged program quit, no license control | A program in a product with an Observe policy for this client (but no Manage policy) was either quit offline, or was quit online but the corresponding launch was offline. |
| 14 | deny unkeyed | unkeyed program launch denied | unused |
| 15 | logon | session logon | A user logged on to KeyServer. In the simplest case this corresponds with a user logging in to the local computer. However, this event can also be written if the user goes offline, their session with KeyServer times out, then they come back online and reach KeyServer again. It will also be recorded if KeyServer is restarted, when clients that were connected to the old process initiate communication with the new process. |
| 16 | logoff | session logoff | A user logged out of KeyServer. The user logged out of the local computer, or KeyServer stopped running, or the client lost its connection to the KeyServer and the session timed out. |
| 17 | block | session blocked | A client tried to log into KeyServer but could not. Either the computer record is set to Excluded, the connection is being attempted from a location which is not allowed to connect, the user was unable to authenticate, or the computer is set to Dormant and KeyServer's seats are full. |
| 18 | info | server information | Currently not used. |
| 19 | up | server started | The KeyServer process started up. |
| 20 | down | server stopped | The KeyServer process stopped. |
| 21 | shadow info | shadow information | Currently not used. |
| 22 | shadow up | shadow started serving | A KeyShadow started to communicate with clients because the KeyServer could not be reached. |
| 23 | shadow down | shadow stopped serving | A KeyShadow stopped communicating with clients because the KeyServer came back. |
| 24 | audited | audit completed | A client finished sending a software audit to the KeyServer. |
| 25 | issued | server lease issued | A KeyServer license was issued to the client, enabling it to connect to KeyServer. |
| 26 | revoked | server lease revoked | A KeyServer license was revoked from the client, either due to client inactivity, or because the computer record was deleted or set to "Excluded". |
| 27 | license issued | license lease issued | A license for a Leased, Node, or portable policy was issued to the client and will count against the policy limit until it is revoked, regardless of whether it is actively in use. |
| 28 | license revoked | license lease revoked | A license for a Leased, Node, or portable policy was revoked, and the client will no longer be able to use the policy unless it is issued to the client again. |
| 29 | license start | license usage start | A client started using a license for a policy in order to enable the use of a program. |
| 30 | license stop | license usage stop | A client stopped using a license for a policy that it no longer needs in order to use any program. |
| 31 | session idle start | idle | A client recorded that the user input has been idle for the defined time and entered the idle state. |
| 32 | session idle stop | idled | A client has recorded that there was user input exiting the system from an idled state. |
| 33 | product usage start | product start | Usage started of a Product that is in an Observe or Manage Policy. |
| 34 | product usage stop | product stop | Usage stopped of a Product that is in an Observe or Manage Policy. |
Events 1-4 can have a reason indicating "shutdown", "lost", or "crashed". This means that the client became unable to talk to the KeyServer for some reason, and the session timed out. When this occurs, both the client and the server (if it is still running) know that the server will no longer be counting the usage. If the policy is set to "Relaxed Enforcement", or it is a policy type that remains allocated to the client, the client will continue to run the associated program and will report the remainder of the usage to the Server later. If on the other hand the policy is Site or Concurrent, and is uses "Strict Enforcement", the client will force the user to quit the program.
Since there are different events for usage and allocation, one can report either on policy usage or on policy allocation, for any policy type. This is perhaps most interesting for a Lease Policy, where usage and allocation are quite different, but unlike a Node policy, allocation does more than just grow over time.
When a 6.2 KeyAccess cannot contact the KeyServer, it knows in some cases that it has a policy - and in these cases, the eventual usage that is written will not be considered "offline" since the server has accounted for the policy allocation. So "offline" does not mean strictly that the client could not reach the server, but moreover that the client did not have a policy allocated. In this case, the client does not know whether it would have been able to get a policy allocation if it were online.
Generally when writing reports, multiple event types need to be selected depending on what type of data you wish to report on. Here are some examples:
Also, depending on what you need to report on, you may wish to select only "end" events - e.g. policy return but no policy obtain.