Administrator's Reference
|
|
|
KeyServer ® Administrator's Reference |
| |||
| Home | Support | Legal | Contact Us |
|
The KeyServer's main function is to control the use of Macintosh and Windows programs running on networked computers. Each KeyServer-controlled program has associated license restrictions and concurrent usage limits, which specify the maximum number of users who can be running the program at any given time. The KeyServer then guarantees that there is no more than the maximum number of users running the controlled program at a given time. With its authentication feature, described in the next chapter, KeyServer can also control which users can and cannot run each keyed program when there are licenses available for use.
The KeyServer uses an effective and friendly interface to enforce each program's usage limits. In the event that all of a program's licenses are in use, the KeyServer tells the requestor that they cannot run the program, places them in a queue if they choose, and then immediately notifies them when a license becomes available.
When the user double-clicks on a KeyServer-controlled program, control of the launch is temporarily handed to KeyAccess, which contacts the KeyServer over your network and asks for permission to launch the program. When the KeyServer receives this request-to-launch from KeyAccess, it first confirms its network link to the client machine, and then checks its license database for an available license to the program in question. At this point, one of a few things may cause the KeyServer to turn down KeyAccess's request. The user is prohibited from using the program if:
In each case, KeyServer explains why the program cannot be run, and details what must be done in order to run it. In the last case, the user must wait until someone else quits from the program and thus returns a license. The KeyServer will inform the waiting user when someone else has returned a license.
For example, suppose you want to run a keyed program named XYZWrite. First, launch the application as you normally would. Invisibly, XYZWrite asks KeyAccess to obtain a license. KeyAccess then contacts the KeyServer, which finds that all licenses are in use by other users. This information is sent back to KeyAccess, which informs you that the application is currently unavailable and asks if you want to be notified when you can run XYZWrite.
In our example, suppose you really need to use XYZWrite, so you click OK. Any other users who were placed on the waiting list before you will be notified first. A few minutes later, someone who was using XYZWrite decides to quit. You happen to have moved up to the front of the waiting list when they quit, so the KeyServer immediately notifies you that XYZWrite is available:
If you click Cancel, you forfeit the available license, and the next user in line is told that it is available. If you click Reserve, the KeyServer gives you five minutes to launch XYZWrite. Other users cannot use the license while it is reserved for you.
If you are already waiting for another program, you can choose to be notified when XYZWrite is available. Alternately, you can choose to cancel your request, which tells the KeyServer that you no longer wish to wait for a license.
Some licenses for bundled software stipulate that, if a user is running one program from the bundle, then all other programs in the bundle are "in use" or reserved for that user and no other user may run the programs associated with that license. KeyServer controls such licenses through its suite feature.
Suites allow you to group several programs together under one license counter. Furthermore, if a user has opened one program within a suite, other programs in the suite may be launched without issuing a new license. The license originally obtained is held by the user until the user quits from the last program within the suite.
Members of a suite share more than the license counter. They share such things as timed-use limits, portable key settings, authentication limitations, etc. All options with the exception of the Custom Message and Notes are inherited from the suite.
Suites can also be used to group together multiple versions of one program, and versions of a program that run on different computer platforms as well. For example, if you have licenses for ClarisWorks 1.0 and upgrade these licenses to version 2.0, you would put the Controls for both versions into a suite (as in the example above). Users who are still running version 1.0 share the licenses with those users who have upgraded to ClarisWorks 2.0, but the 1.0 users also get a post-launch message that tells them that the new version is available.
You might also have licenses for a program that runs on both Power Macintosh and older Macs, or on both Macintosh and Windows. Because such a program will have a distinct key for each platform, you should place the Controls in a suite. When you key a "fat" program (a program that has executable information for both the PowerPC- and the 680x0-based Macs), KeyConfigure will automatically create a new Suite and place the two new Controls in that suite.
Suites are useful for controlling standard "Suite" or "Office" licenses as well as cross-platform and multiple version licenses. While there is no restriction on the number of Controls placed within a suite, there are certain other limitations on the current implementation of suites.
Even with these limitations, KeyServer can sufficiently control current suite licenses.
To create a new Suite, choose the "Create New Suite" item from the Controls menu, and customize the settings that appears in the Control Details dialog box. If no other Controls are selected, a new, empty suite will be created. You can drag other Controls into this suite using standard drag and drop actions (see Adding a Control to a Suite below). If you have selected some Controls before choosing the "Create New Suite" command, KeyConfigure will create the new suite and automatically place the selected Controls into the suite.
By default, when a new suite is created an option is set indicating that users may launch multiple members of the suite (on a single computer) without using up more licenses. This is usually allowable with the program's license agreement, but in rare cases you might want each new program launch to require a new license. This can be accomplished by unchecking the "Multi-launch" option in the Control Details dialog box.
Deleting a suite is similar to deleting a Control, with the restriction that a suite cannot be deleted if it has member Controls. If you wish to delete a suite, first remove all of its members by dragging them out of the current suite (or moving them to another suite) or delete them using Cut or Clear in the Edit menu.
Moving Controls into or out of a suite is as simple as selecting, dragging, and dropping. First, make sure that you are viewing the Controls window "by suite": From the Controls menu, choose "Group Controls by Suite" if the item does not already have a check mark next to it. When Controls are grouped by suite, each suite member is listed underneath the suite, and indented to further indicate which programs belong to a suite.
Select the Controls that you wish to add to a suite, and then drag the selection until the mouse cursor is directly over the target suite (or any of its current members). The suite will then become hilighted. Drop the selection (release the mouse button) into the suite to complete the operation.
To remove a Control (or group of Controls) from a suite, select the Control(s) and drag the selection until the mouse cursor is over a Control that is not in any suite, or over a blank part of the Controls window. Drop the selection, and the Control(s) will no longer be associated with any suite.
The Controls in the Controls windows may be viewed as a simple list, or as a two level hierarchy of suites and their members. Controls that do not belong in any suite are listed in order with the suites. Immediately under each suite are listed those Controls that are part of the suite. As a visual indication that members of a suite inherit their settings from the suite, all settings are displayed next to the suite only. This includes the number of licenses enabled for the suite as well as the options. Custom messages are displayed next to the actual Controls, as each program may have its own custom message.
To view a Controls window as a hierarchical list, select the "Group Controls by Suite" item in the Controls menu. The names of all suites will appear in boldface, while normal Controls appear in plain text. When a suite is in use, the number of people who hold the suite appears in the "In Use" column of the Controls window, and the number of people waiting to use the suite appears in the "Waiting" column. Next to each member of the suite, the number in parentheses indicates how many copies of the actual programs are running on users' computers. To simplify the view, select "Hide Suite Members" from the Controls menu. This will hide from view all Controls that belong to suites.
The KeyServer keeps all of its data files, including the Active Controls file, log files, and authentication modules, in the KeyServer Data Folder. This folder is automatically placed within the same folder as the KeyServer program when you first set up the KeyServer. Note that on Windows computers where the original KeyServer installation was done with an image prior to August 1, 1998, this folder is named KSDATA.
For convenience and/or performance reasons, you may want to have the KeyServer store its data and logs on a volume other than the system disk. The entire folder and specific files within the folder, may be stored on different disks, or even on a remote file server volume.
 | On Windows 95, 98 or Windows NT 4, do this with a Shortcut. From the KeyServer machine, create a shortcut to the folder where you want KeyServer to place its files, name the shortcut KeyServer Data Folder (actually, the shortcut will be named KeyServer Data Folder.LNK, but Windows hides the extension), and place it in the same folder as the KS.EXE program file. When the KeyServer starts up, it locates the target folder of the link, and stores all files there. Use the same steps to create shortcuts to any items within this folder. |
 | On the Macintosh, do this with the Finder's Make Alias feature. From the KeyServer machine, create an alias to the folder where you want KeyServer to place its files, name the alias "KeyServer Data Folder", and place it in the same folder as the KeyServer program. When the KeyServer starts up, it locates the original folder you selected, and stores all files there. Use the same steps to create aliases to any items within this folder. |
Every Control that you install into your KeyServer (for either a Macintosh or Windows application) is stored in a special file named "Active Controls", which is in the KeyServer Data Folder. When KeyServer is installed on a computer, the installer creates a default Active Controls file containing Controls for KeySentry, KeyCheckout, KeyAudit, and KeyVerify.
The format of the Active Controls file is identical to the format of all Controls files that KeyConfigure creates. Therefore, this file can be edited off line (when the KeyServer is not running) as well as on-line (by connecting to the KeyServer with KeyConfigure). If you name a Controls file "Active Controls" and place it in KeyServer Data Folder, it becomes the new active Controls file, out of which the KeyServer takes its Controls.
Whenever a user checks out a portable key, KeyServer saves the identifying information in the Portable Keys Record. The information is removed when the portable key times out or is returned early by the user. This file will grow large only if there are many portable keys checked out, but you should make sure that there is always plenty of free space available on the KeyServer machine's System disk so that users are not denied access to portable keys.
The Portable Keys Record, which is the only record of portable key usage, should not be removed from the KeyServer Data Folder. It is good practice to make a daily backup of the file in case the disk on the KeyServer machine crashes and is not recoverable.
For more information on using portable keys, see the KeyAccess, KeyConfigure, and KeyCheckout chapters.
Every event that concerns the KeyServer is written into a log file on the KeyServer machine's System disk. The log file can be used to retrace the KeyServer's activity over a period of time.
Log files are stored in the KeyServer Data Folder. There may be many log files in this folder (see the Log File Management... section for details), but only one is the active log file into which the KeyServer writes current information.
Any database or spreadsheet program can read the text-only log files. Each line, or record, contains tab delimited fields, which are defined according to a few simple rules. Most of the time you do not need to read the raw log file. Instead, you can obtain a summary of the log file's contents by running the "Summarize" report (see the KeyConfigure chapter for details).
Those KeyServer administrators who need to collect complex statistics from the log files need to become familiar with the contents of this section. If you wish to use the raw log data, first use KeyConfigure to turn on the Write All Information to Log option (see the KeyConfigure chapter). Once you understand the log file contents, you may determine that the Program Specific Info Only option suffices for your purposes.
Let's follow the XYZWrite example from Launching a Keyed Program, and see what would appear in the log file.
1) Start up your computer with KeyAccess installed:
09/26 10:30:15 g 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
2) Launch XYZWrite, KeyServer has no licenses left to give out:
09/26 10:32:47 D 2000036C 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public 09/26 10:32:47 j 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
3) Click OK in notification request dialog box:
09/26 10:32:56 H 2000036C 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public 09/26 10:32:56 h 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
4) Notification is given as indicated by the W/á entries, launch on XYZWrite again, and this time it runs successfully (because KeyServer reserved it for you):
09/26 10:41:35 W 2000036C 0000:08:39 00A1 4B 00 A2A36525 J.Q. Public 09/26 10:41:35 á 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public 09/26 10:41:35 O 2000036C 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public 09/26 10:41:35 o 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
5) Quit from XYZWrite to return the license:
09/26 11:47:21 R 2000036C 0001:05:46 00A1 4B 00 A2A36525 J.Q. Public 09/26 11:47:21 r 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
6) Shut down your computer:
09/26 11:48:07 s 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
As you can see from the example, every important transaction gets recorded in the KeyServer's active log file. This example is not complete - many more events can happen that will be recorded in the log file - but it is the type of "conversation" you will typically see in your log files.
In general, records with lower case letter codes explain why events happen, while records with upper case codes specify which program was involved in an event. Let's look at another example, where you run a program and then turn your computer off in a non-standard way (without quitting from the program):
7) Start up your computer with KeyAccess in the System Folder:
09/26 12:40:29 g 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
8) Launch XYZWrite, KeyServer gives you a license to run:
09/26 12:43:20 O 2000036C 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public 09/26 12:43:20 o 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
9) Turn your computer off without shutting down properly. About ten minutes later, the KeyServer realizes that you are no longer using the license to XYZWrite:
09/26 12:58:17 R 2000036C 0000:14:57 00A1 4B 00 A2A36525 J.Q. Public 09/26 12:58:17 d 00000000 0000:00:00 00A1 4B 00 A2A36525 J.Q. Public
Notice the difference between transactions 5 and 9. In both cases, the KeyServer logs the return of a license to its control (the 'R' tells you this). In the first case, the license was returned because you Quit from the program ('r'), while in the second case, the license was returned because you turned your Mac off unexpectedly ('d').
In each case, the log file indicates that the event concerns program 2000036C. You can map this number to a program name using records with the code 'C':
09/26 08:26:37 C 2000036C 0000:00:00 0003 00 00 00000000 XYZWrite
Each time the KeyServer starts up or creates a new log file, one of these records is written to the log file for each Controlled program. Whenever you install or edit a Control, similar entries (with different codes) are placed in the log file.
Suite licenses and multi-launch options requires a few different log file codes. These log codes indicate that a particular program was launched, but do not reflect any license activity. Use the 'O' (obtain) and 'R' (return) codes to determine when a license is actually issued to, or returned by, the user. When a suite license is initially issued to a user, the log file will contain an 'O' transaction (user obtained the suite license) followed by an 'L' transaction (user launched a member of the suite). Similarly, when the user quits from the last running member of a suite, the log will contain an 'F' transaction (user quit a member of the suite) followed by an 'R' transaction (user returned the suite license). These two new codes apply only to launches and quits of programs within a suite (or are enabled for multi-launch), and do not appear for programs that are not members of a suite (and are not enabled for multi-launch).
The table below contains all the information you need to use your favorite database, spreadsheet, or other special program to obtain data from the KeyServer's log files. Each possible log record code is listed with an explanation of why it is written into the log file. The Notes column details relationships between the log codes, using the following terminology:
paired: the two codes appear with the same date/time stamp (for a given transaction)
pre-associated: the listed code(s) appear previously in the log file, but not necessarily with the same time stamp
post-associated: the listed code(s) appear subsequently in the log file, but not necessarily with the same time stamp
Associated codes are bound together through the 'user link' field.
| Code | Explanation | Notes |
| a | Client is in the process of authenticating, because either the KeyServer or a Control requires it. | post-assoc. with one of many request codes |
| b | The key that was sent was not acceptable, so it has been returned. | paired with 'R' |
| c | Configuration string follows. This only appears when the server starts up. | |
| d | Client missed the maximum number of tickles. Any li censes were reclaimed. | possibly paired with 'R' |
| e | Log file has been closed through normal shutdown. | pre-assoc. with 'i' |
| f | Client tried to log on, but was rejected because there were no free client records. | |
| g | Client was placed in the client table as normal in re sponse to a logon request. | possibly paired with 'R' |
| h | Client requested that notification be held for a program. | pre-assoc. with 'j', post-assoc. with 'y' |
| i | Log file has been opened at KeyServer startup time. | post-assoc. with 'e' |
| j | License was denied because there are none left (notifi cation query was sent). | paired with 'D' |
| k | License was denied because the server does not have the key, or there are no licenses left (no notification que ry). | paired with 'D' |
| l | The log file was swapped. What follows is the new log file's name. | |
| m | License was denied because the Control is disabled, custom deny message was sent. | paired with 'D' |
| n | The client had fewer licenses than thought. Un-held li censes were reclaimed. | paired with 'R' |
| o | Client asked for a license and got it. | paired with 'O' or 'G' |
| p | License was denied because client is already using the maximum number of Controlled programs. | paired with 'D' |
| q | Server is shutting down, so this client has been re moved and any held licenses have been reclaimed. | possibly paired with 'R' |
| r | Client returned a license by quitting a program. | paired with 'R' or 'Q' |
| s | Client shut down normally, and was removed from cli ent table. Remaining licenses were reclaimed. | possibly paired with 'R' |
| t | A reservation was terminated by the client. | paired with 'R' or 'T' |
| u | Client attempted to log on, but was turned down due to an old version of the client software. | |
| v | Client was placed in the client table as normal in re sponse to a log on request, notified of old version. | |
| w | Client was removed from queue on user's request. | paired with 'W' |
| x | The reservation of a license expired. | paired with 'R' or 'T' |
| y | Client has not been receiving tickles, and sent its license table to re-establish connection and regain licenses. | possibly paired with 'O', 'R', 'Q', or 'Y' |
| z | Client asked for a license, but was rejected because the program can't be run in the client's Zone. | |
| 1 | License was denied because there are none left (client already on notification queue). | paired with 'D' |
| á | Client was removed from queue because a license was available for use. | paired with 'W' |
| â | Client was removed from one queue in order to be placed on another queue. | paired with 'W' |
| ä | Client was removed from queue on shutdown. | paired with 'W' |
| é | License was reclaimed by the administrator. | paired with 'R' |
| ë | A timed check-out license has expired, so the license has been reclaimed. | paired with 'R' |
| ê | A portable key has expired, so the license has been re claimed | paired with 'R' |
| è | A portable key has been returned early by the user | paired with 'R' |
| Ä | License was denied by the remote function. | paired with 'D' |
| í | License was denied to a user of Remote Access. | paired with 'D' |
| µ | Client was removed from the client table because the authentication process did not succeed. | |
| ñ | Inactive guest client was removed from the client table to make room for another client. | |
| ó | Client asked for a portable license and got it | paired with 'O' |
| ö | Client extended the time on a timed license | paired with 'X' |
| ø | Client extended the time on a portable key | paired with 'X' |
| _ | Program was not launched from an allowed (local or re mote) location | paired with 'R' |
| ß | Client shut down normally, but is retained in the client table until sticky licenses time out. | |
| ú | License was denied because there are no common li censes, and user can never become authenticated. | paired with 'D' |
| ü | License was denied because it has expired. | paired with 'D' |
| û | License was denied because there are no common li cense, and the client is not preferred. | paired with 'D' |
| ù | License was denied because the requesting program does not match exactly (Exact Match Only option is on). | paired with 'D' |
| ÿ | Client has not been receiving tickles. Same as 'y', but the server had no previous record of the client. | possibly paired with 'O' or 'Y' |
| # | Log file version number. | |
| * | External module's log entry. | |
| @ | Shadow KeyServer is announcing presence | + | Unkeyed application launch. | post-assoc. with '-' |
| - | Unkeyed application quit. | pre-assoc. with '+' |
| ... | Log file is missing some entries due to disk problems | |
| ? | Client issued an unsupported request. | |
| ! | KeyServer detected a race condition (check routers) | |
| A | Control was added by KeyConfigure. | |
| C | Control configuration for the named Control. This only appears when the server starts up. | |
| D | License was denied. | paired with '1', 'Ä', 'í', 'j', 'k', 'm', 'p', 'ú', 'ü', 'û', or 'ù' |
| E | Control was edited by KeyConfigure. | |
| F | Program was quit, but license is still held by client (oth er programs still using suite or multi-launch license) | paired with 'b', 'd', 'é', 'ë', 'g', 'n', '_', 'q', |
| G | License was regained by client after a client crash. | paired with 'o' |
| H | Client was placed on a program's queue | paired with 'h' |
| K | Configuration for the KeyServer | |
| L | Program was launched on a license that client already holds (suite or multi-launch) | paired with 'o' or 'y' |
| O | License was obtained. | paired with 'o' or 'y' |
| Q | User quit from a previously timed-out program | paired with 'r' or 'y' |
| R | License was returned. | paired with 'b', 'd', 'é', 'ë', 'g', 'n', '_', 'q', |
| S | License usage summary. Appears at server shutdown. | post-assoc. with 'e' |
| T | License reservation has been terminated. | paired with 't' or 'x' possibly pre-assoc. with 'h' |
| U | Control was deleted by KeyConfigure. | |
| W | Client was removed from a program's queue | paired with 'w', 'á', 'ä', or 'â' |
| X | Portable key time limit was extended | paired with 'ö' or 'ø' |
| Ä | Control was added by KeyConfigure, but remains un available to users until KeyServer restarts. | |
| É | Control was edited by KeyConfigure, but remains un available to users until KeyServer restarts. | |
| Ü | Control was deleted by KeyConfigure. The control was not available to users until restart. |
Record format for all codes not specifically listed below:
date time code prog ID time out user link flags address name 00/00/00 00:00:00 c 00000000 0000:00:00 00000000 00000000 <varies> xxxx
Record format for codes 'A', 'C', 'E', 'U', 'Ä', 'É', and 'Ü':
date time code prog ID enbl op gop reserved name 00/00/00 00:00:00 c 00000000 0000:00:00 00000000 00000000 <empty> xxxx
Record format for code 'S':
date time code prog ID total time launches reserved reserved name 00/00/00 00:00:00 c 00000000 0000:00:00 00000000 00000000 <empty> xxxx
Record format for codes 'c', 'e', 'i', 'l', '#', '*', '+', '-' and '...':
date time code text 00/00/00 00:00:00 c xxxx
Record format for '@':
date time code reserved last contact reserved reserved reserved name 00/00 00:00:00 c 00000000 0000:00:00 00000000 00000000 <empty> xxxx
| date/time | date and time (24 hour format) at which record was written to the log |
| code | event code, indicating the event that occurred |
| prog ID | identifying number unique to each Control in the Active Controls file |
| time out | if prog ID is not zero, the time that the license has been in use by the user |
| user link | unique number given to each session, changes across client restarts |
| address | network address of user's computer, format depends on transport used |
| flags | user's status flags. In high-low order (bit 0 is rightmost): bit 0 indicates authentication status (0=guest, 1=authenticated); bit 1 indicates authorization status (0=common, 1=preferred);bits 16-17 indicate transport (00=AppleTalk, 01=IP, 10=IPX) |
| name | name of user (name of program if code is 'A', 'C', 'E', 'U', 'Ä', 'É', or 'Ü') |
| enbl | number of licenses enabled in all pools |
| op | license options (background, exact, local, detachable) |
| gop | more license options (remote, notify, force) |
| wait | number of users waiting for a license |
| usage | number of authorized licenses in use/number of guest licenses in use |
| total time | total amount of time the program was in use |
| launches | total number of times the program was launched |
| text | defined by code |
| last contact | amount of time elapsed since shadow last communicated with server. |
The full AppleTalk address is available, including the socket number, and the full IP and IPX address are also available, including port or socket numbers. The transport protocol used by the client can be determined by examining bits 16 and 17 in the flags field. When the client is connected over AppleTalk, the address field will also contain the AppleTalk zone, if known.
Because log files are organized by time stamps, strange things may appear in the active log file when the KeyServer's clock is set back one hour in the Fall. When you are ready to reset the KeyServer's clock, the best thing to do is first reset the clock, and then restart the KeyServer machine. If you want to be extra careful, you should manually swap the active log file immediately after you restart the KeyServer machine (see the KeyConfigure chapter to find out how to manually swap the active log file). This will minimize any confusion caused by the time change.
Due to the number of factors that bear on a given machine's calculation of date and time zone and its relation to the KeyServer machine, the least troublesome path, if your KeyServer and users are all in the same time zone, is simply to turn off Time Zone and DST awareness by means of the KeyServer Global Settings, in KeyConfigure.
System 7 introduced Time Zone and Daylight Savings Time (DST) awareness. System 7 users on both the client and server side should bear in mind that both the "Date & Time" control panel and the Map control panel can have an effect on how KeyServer interprets local time. System 7.5 users can use the improved "Date & Time" control panel to set date and time zone awareness (and this control panel can be copied back to pre-7.5 users as well).
Windows 3.1 clients should remember that the insertion or modification of the TZ environment variable in the AUTOEXEC.BAT file might be required, as well. Windows 95, 98 and Windows NT users should not have to make any changes to their systems, if the date, time, and time zone information was properly configured when Windows was installed.
If you're having trouble with KeyServer or client Date/Time configuration, look at the KeyServer and Time Zone Awareness document in the KeyServer online documentation set. If your problem persists or you are uncertain what to do, call Sassafras Technical Support or email tech.support@sassafras.com.
KeyServer simultaneously accepts network connections over AppleTalk, TCP/IP, and IPX, but in order to enable this feature you must first install and configure the appropriate network drivers for the protocols you wish to use.
Because TCP/IP networks are likely to be accessible from around the world, you may wish to limit the locations from which users can access your KeyServer. To do this, use the "Network Access" command, described in the KeyConfigure chapter. Also you can use an authentication method that requires a name and password, and anyone who attempts to use your KeyServer (whether or not over TCP/IP) must enter their name and password before they are granted licenses.
| Windows 95, 98 and Windows NT systems give you the option to install support for the TCP/IP protocol, including the WinSock interface. You will need to install these options in order for KeyServer to provide service over TCP/IP. In order to support IPX networks, Novell's Client32 for Windows 95, 98 and Windows NT or Microsoft's "IPX/SPX compatible" drivers must be installed. |
|
For TCP/IP support on a Macintosh, you need to install Apple's MacTCP software
(also called TCP/IP Connection for Macintosh) on a KeyServer machine running
Classic networking, or the TCP/IP control panel on a KeyServer running Open
Transport. Any Mac users who wish to connect to the KeyServer over TCP/IP also
must have the MacTCP or TCP/IP control panel installed and configured, and must
configure KeyAccess with the KeyServer's IP host name or IP network address.
To support IPX client from a Macintosh KeyServer, Novell's MacIPX control panel must be installed and configured properly. Be sure to check the "Frame Type" setting that MacIPX will use, and make sure that it matches the frame type that the Windows IPX clients will use when connecting to KeyServer. |
When a protocol is not available on the KeyServer machine, you will not be able to turn it on via KeyConfigure or the KeyServer's Status window. If a protocol is disabled in the KeyServer Status window or in KeyConfigure's Network Access dialog, but the proper drivers are installed and you think that it should be enabled, contact Sassafras technical support.
Tickles are sent to clients about every 5 minutes when a KeyServer-controlled program is in use, and farther apart when no licenses are held. This rate increases whenever a tickle goes unacknowledged. After several consecutive missed tickles, KeyServer assumes that the user has shut down or somehow lost their session: the user is dropped from the user list and all outstanding licenses are recovered. Licenses checked out to a user who has crashed (or turned off the client Mac without selecting "Shut Down" in the Finder) are recovered within about 10 minutes. If the reason for loss of contact between KeyServer and KeyAccess is a broken network link, an alert reminds the user to Quit controlled programs at approximately the same time that the KeyServer recovers the licenses. This alert is repeated until the user complies. The alert is not posted if programs running on the user's Mac have been made "detachable" by the KeyServer administrator or if shadow service is available to the user.
Most KeyServer functions can be controlled from a remote client running KeyConfigure on any networked Macintosh or a Windows PC. Local access to the computer running KeyServer is required only for the configuration of some types of authentication (such as the Text File method) and for the installation of new KeyServer components.
|
KeyServer's management of software licenses takes precedence over its
communication with KeyConfigure. While a dialog posted on a Macintosh running
KeyServer might in rare cases block communication to KeyConfigure, users can
still launch KeyServer-controlled programs and access all of KeyServer's
services.
In order to ensure uninterrupted remote administration of a Macintosh KeyServer, you should avoid running programs that might post a dialog on the KeyServer machine when it is unattended. For example, you do not want notification of incoming mail or notification of printer problems to appear on the KeyServer machine. |
| |||
| Home | Support | Legal | Contact Us |
|