Admin Alerts & Journal
The Admin Log records administrator activity, server maintenance status, and other important events related to the operation of KeyServer.
The log can be configured to alert administrators when certain events occur, suppress events that are not interesting, and request that the admin supply a comment before making important changes.
Event Topics
Each Admin event belongs to an event topic. Topics provide a way to sort and search for similar events, like all the events that modified a policy, or all the events signaling the failure of some server task. Topics can be marked so that simultaneous occurrences will be collected into one event, reducing excessive logging when verbose detail is not required. Certain topics will combine multiple occurrences over time into one event, since in some cases only the most recent occurence is interesting.
Generally, event topics fall into three categories: events generated by administrator activity, events generated by the server during normal operaton, and events based on conditions that should be brought to an administrator's attention. For admin generated events, which happen when a change is made in KeyConfigure, the admin can be prompted for comment about the change before the change is saved. Events generated in other ways will not prompt for such comments.
Topics can be configured to set the level of interactivity — whether to log the events within the topic, whether the administrator should supply a note when making a change within the topic, and whether the topic's events should appear as alerts to be acknowledged.
Admin Alerts
Events that are deemed important enough for review will first appear in the Admin Alerts window. This window lists events beginning with the most recent. The event topic and further details are displayed for quick reference, and an Acknowledge button appears for each event. Clicking this button will bring up the Resolve Event dialog, which will give all the details of the event, as well as some suggestions for further action. Resolving an event moves it from the Admin Alerts window into the Admin Journal window.
To acknowledge an event (or multiple events) immediately without going through the Resolve Event dialog, select the event(s), right click, and choose Acknowledge Events.
All events are marked with a severity level. Higher severity events are indicated by a color bar of yellow, orange, or red. By default the Admin Alerts window will come to the front whenever an alert event occurs with higher severity. To turn off this behavior, uncheck the option "Show Admin Alerts window for critical events" in the Thresholds panel of the Alerts and Status dialog.
Admin Journal
All events are eventually archived into the Admin Journal. The Admin Journal window displays events that have been acknowledged, whether automatically or by an administrator after first appearing in the Admin Alerts window. This window uses a more compact display, and can be sorted, searched, and filtered to locate specific events or trends.
Initially, when KeyConfigure first starts, only the first 50 or so most recently resolved events are loaded. You can load more events by clicking on "Total" in the status bar at the bottom of the window. The status bar displays the number of displayed events, the number of loaded events, and an indication whether there are more events that can be loaded.
To filter the events in this window, choose Find from the Edit menu and type the text to filter on. Events that contain the entered text anywhere will be shown when you hit the Enter key. Note that filtering the Admin Journal in this window will only show events that are loaded. If searching for an event does not display what you are looking for, you might need to load more events.
When the number of displayed events is less than the number of loaded events, the Total will show these two values. This can happen if you are filtering the events in the window, or if you have chosen to hide certain event topics (see Configuration below).
Commit Notes
Events that are generated by administrator actions can be configured to request or require that the admin type a commit comment describing the change that is being made. For such events, KeyConfigure will prompt for the comment prior to saving the changes. If the event requires a comment, the changes cannot be saved until something is typed. For change that just request a comment, the admin can proceed without typing a comment.
The commit comment is recorded along with the event, and cannot be changed later. For events that are configured to be acknowledged, there is an opportunity to add further comments when the event is resolved.
Resolving Alerts
Events in topics configured for acknowledgement will first appear in the Admin Alerts window. These events can be resolved by clicking the Resolve button for each event. This will present the Resolve Event window, which lists some suggestions for further action relevant to the particular event. There is also a field to type a comment to be recorded with the event upon resolution.
The list of suggestions includes links to the documentation, which will open in a browser window. When more information or settings are available within KeyConfigure, suggestions will open the applicable windows and dialogs.
The event will be resolved and moved from the Admin Alerts window into the Admin Journal when you click the Resolve button. Note that if you right click and choose Resolve on the alert, you will NOT be presented with this window, it will just clear the event.
Configuration
Configuration of alerts is done in the Alerts And Status dialog, available in the Config menu.
Topics
The Topics panel lists all known topics, organized into categories. Each topic can be configured independently by checking these options:
On — enable events in this topic
Events in this topic will be generated and written to the Admin log. Unchecking this option disables the topic, so no events within the topic will be written to the log.
Ask — request that the administrator provide a comment
For admin generated topics, the administrator making the change will be prompted for a comment before the change is saved. The admin will have the option to leave a comment or not. If this option is not checked, the change will be saved without comment. This option is not applicable to some topics.
Req — require that the administrator provide a comment
For admin generated topics, the administrator making the change will be prompted for a comment before the change is saved. The admin must type a comment in order to proceed with the change. This option is not applicable to some topics.
Ack — add events to the Alert list for later acknowledgement
Events in this topic will be added to the Admin Alerts list to bring them to the attention of all administrators. This option is useful for events that signal that a problem has occurred, or for changes that should be reviewed by other administrators. If this option is not checked, events in the topic will be added directly to the Admin Journal.
Batch — combine simultaneous events into a single event
Certain event topics can generate many events when changes are made to multiple items In some cases, the individual changes are not important to know, but the general change should still be noted in the log. Checking this option allows the journal to combine events that happen at the same time. So for example, when you move hundreds of computers into a Division you will see just one event in the Admin log instead of hundreds.
Hide — do not show events in this topic
Unlike the other options, this setting applies only to the instance of KeyConfigure that is running. So some KeyConfigure users can hide certain options while others continue to see them. Events in hidden topics are still logged, and can be shown by unchecking this option.
By default, events in the Admin Journal older than a year will be deleted periodically. To change this setting, set a different number of weeks below the Topic list. Unchecking this setting allows your Admin Journal to grow without limit.
Thresholds
In the Thresholds tab are various settings for controlling when the server will send warnings for the disk and license usage. Set these thresholds to values that are most applicable to your needs.
The Free space lower than alert can be very useful for avoiding issues due to the server disk filling up if you have no other system monitoring in your environment. Be default this is very low, you may want to set it to something more like 10gb for a modern system. Note there is also a Dashboard Widget in the Web UI that shows this.
Logins greater than could be useful in settings with a 1:1 license allocation at 100% capacity and wanting to know when a certain % of your fleet is in use. It is based entirely off the number of connected clients vs your license limit, so in some settings it would be redundant to the capacity alerts.
The various capacity settings deal with the percentage of your KeyAccess seats that are in use. The warning bell icon shows if that trigger is currently tripped, or allows you to manually disable the trigger. In automatic operation, they reset when use falls below the trigger % again.
The option Show Admin Alerts window for critical events indicates whether KeyConfigure should bring that window to the front whenever critical events are added to the Alerts window.
KeyServer can optionally send status messages and alerts to any e-mail account. If this account is a mailing list, then all of the members of that list will get notified of events added to Admin Alerts. This is also required for the emailing of Purchase expiry notices and any Scheduled Reports you have created. Configure the e-mail information for your site in the E-Mail tab. The From:, To:, and SMTP Host: are the only mandatory fields, but others may be required by your mail server. Note that due to a flaw in the OSX libraries, a MacOS based KeyServer can not send test or daily status emails, but it can send scheduled Reports.
From: Email address from which KeyServer's e-mail will be addressed. This is the address that will appear in the “From” field of KeyServer's e-mail. This address can be anything valid for your domain, and does not necessarily have to be a full e-mail account. However, some mail servers may reject mail that is “relayed” from an external or non-existant account. In this case, you will need to use a valid account, and possibly configure the authentication options below. Note this field does not support bracket syntax, it can only be one plain email address.
To: Email address to which KeyServer should send status and error messages. This account must be valid, otherwise KeyServer will not be able to send e-mail. It is best to make this a mailing list address that goes to a few people who can be responsible for checking KeyServer if it reports a problem. Note only one plain email address can be specified, hence the recommendation for using a list address.
SMTP Host: Type the host name or IP address of the mail server that KeyServer will use to relay e-mail messages. Typically, this should be the mail server on which the “To” account exists. If your SMTP server supports or requires secure connections and authenticated access, enable that functionality in the relavant settings below. If it uses a non standard port (not 25), specify that at the end (i.e. server:port). Note that systems that require 2FA are not supported, so for example Gmail must allow "less secure applications".
Page To: Email style address (or mailing list) to which KeyServer should send abbreviated error messages. This option can be used for pagers or cell phones which can only receive short emails/ text messages.
Time between repeat warnings: This value sets how frequently KeyServer will repeat e-mail about a problem that has not been fixed. For example, say you choose to receive warnings when disk space is lower than 50 MB, and this condition arises. KeyServer will send you e-mail, and if you do not free up space, it will continue to send warning messages. The time between these messages is specified with this setting. If a different error condition arises, an e-mail message will be sent immediately, even if the Time between repeat warnings has not yet elapsed. Therefore, you could set this value to 1440 minutes (equal to one day), and you would not be bothered more than once per day about any given error condition. You would still be informed immediately upon any new notable events on the KeyServer.
Daily status Message at: KeyServer can send an informational message once a day. This can be useful to monitor the status of KeyServer. The daily status message will contain the basic status information, plus any warnings, expiring entitlement alerts, and so forth that you have elected to see in the Admin Alerts (Ack).
Connect securely using SSL - This checkbox will tell KeyServer to connect to the specified SMTP server using SSL/TLS on port 465 rather than the default port 25 for unsecured mail.
Authenticate with name and password - Enabling this and filling in the fields is required if your mail server does not allow unauthenticated relay.
The mail messages that KeyServer sends are formatted using HTML. Styles are used to call attention to important information in KeyServer's messages. For e-mail clients that do not support HTML, a plain text copy is included in the message. The message sent to the "Page To" address will be brief and in plain text.