K2 – Getting Started Installation Guide & Technology Overview

Installation

     • Server
     • Shadow
     • Admin
     • Reporter
     • Client

     • External Reports
     • Backup

Even if you have already done the “Quick Setup & Demo Tour” (previous section), you should check this document for options, cautions, details, etc. Always start by using your browser to open the README.html file at the top level of the K2 image folder. This will point out any last minute cautions, notes, or corrections that may help avoid wasted time or aggravation. The readme also gives a short description of all the components in the image along with the revision status of each installer.

Note that you can tell which installer is appropriate to use on each platform based on the file extension:

• .exe – Windows executable (Windows Installer)
• .app – Macintosh self extracting archive (Macintosh Installer)
• .mpkg – Macintosh OS X meta-package (Mac OS X Installer)
• .i386.rpm or .i386.deb – Linux installation package (Linux Installer)
• NLM.exe – Windows executable (NetWare Installer)

Most of this documentation is written from the point of view of the Windows or Macintosh operating systems. For specific information on Thin Client installs (WTS, MetaFrame, and WinFrame), other server platforms (NetWare and Linux), and for command line switches etc., always check the “OS Details” appendix.

If a Mac installer (.app, .sea, or .mpkg) is transported to a non-Mac file system, it must be stored as archived data - either in MacBinary .bin or disk image .dmg. After transfer back to a Mac file system, it can be extracted again.

In the Installers folder of any K2 image folder, you will find subfolders containing installers for several distinct functions. All of the functions listed below are implemented for both Windows and for Macintosh. In addition, the server function (KeyServer itself) is implemented for several other host operating systems. Each distinct function on each distinct operating system has its own installer. A complete set of installers (all functions, all platforms) together with a complete set of documentation constitutes an “image” which is identified by date, e.g. “K2 v6.2 (2009-09-01 image)”.

Server, Admin, & Client Functions

• Server

You need to run just one of the installers in this folder. First choose a platform to host your KeyServer and then locate the appropriate K2Server installer based on the filename extension from the list above. You will install KeyServer on this single computer in order to audit software, track program usage, and manage software licenses on all Windows and Macintosh client computers.

• Admin

This folder contains K2Admin.exe for installation on Windows and K2Admin.mpkg for installation on Macintosh. Use these to install the administrative program, KeyConfigure, on workstations used by administrative personnel for management of the KeyServer process. KeyConfigure does not have to run on the same computer or even under the same operating system as KeyServer.

• Reporter

In order to support the (optional) "web report" feature introduced with K2 version 6.1, first choose a platform to host the KeyReporter service and then locate the appropriate K2Reporter installer. Web browsers will query the KeyReporter process through port 80 (or a custom specified port - e.g. 8080) on this host - which may be the same as the KeyServer host or on a separate host.

• Client

This folder contains K2Client.exe for installation on Windows, and K2Client.mpkg for installation on Macintosh. Use these to install the client program, KeyAccess, on every Windows and Macintosh computer for which you want audit data, usage reports, and license control.

• Mobile Client

The mobile client installers, K2Mobile.exe and K2Mobile.mpkg, are used just like the other client installers, except they include an additional utility “KeyCheckout” for use on mobile computers. KeyCheckout enables a user to checkout software licenses for use off-line. If you don’t want your end users checking out portable licenses for use off-line, then install with the standard client installer on both desktop and portable computers.

The various installers can be run directly from the archive and you can copy (or download) any installer (or the entire image folder) to any mounted volume. Since the Client Installers are typically required for use on several computers, perhaps thousands, it may be convenient to copy them onto a shared file server. Then anyone can easily access the appropriate client installer in order to set up their own computer as a client. Consult the Help system for some comments on alternate client deployment strategies which make use of general purpose file distribution tools.

You can install multiple functions on a single computer. For example, it may be convenient to enable management of the KeyServer process from several client workstations, so in addition to running the client installer you would then run the admin installer. If the KeyServer process is hosted on a Windows or Macintosh computer, all three functions (server, client, and admin) can be installed and used on this same computer.

It is assumed in this document that you are installing for the first time. If a prior install exists on a target drive, the installers will re-install any existing components. See the “Upgrades” document for special cautions to avoid losing any of your custom configuration data, especially for the server process.

A few Windows or Macintosh specific issues that you may need to consider before picking a server host are detailed below. As a general rule, Admin and Client components tolerate all typical environments without any special requirements or side effects.

Server Requirements

A single KeyServer will effectively manage software licenses at sites supporting from ten to tens of thousands of computers. KeyServer’s scalability is achieved by using the basic network protocol TCP/IP. Communication between the license server and its clients does not use any higher level file server or Network Operating System (NOS) services. Hence standard network wiring and routing between machines is all that is required to support clients spread across the globe. You don’t need a file server or database server.

To run the KeyServer process, you should choose a single computer (Windows, Macintosh, NetWare, or Linux) that is in a robust location on your network. Client computers must be able to exchange network packets reliably with the KeyServer machine. This computer should be secure from unauthorized users. It should be turned on at all times, configured to never sleep, and not be subjected to frequent restarts or reconfiguration. If you are already running a file server on some computer, this may be the logical place to put the KeyServer so that one secure machine is supporting multiple network services.

The TCP/IP address of the server host must be static. It will be convenient to register a DNS alias for this IP address on your Domain Name Server. Then clients can be configured to locate KeyServer using this DNS alias instead of a raw IP address. This will make it easy to move the KeyServer process to a different IP address if you ever need to in the future.

If clients are accessing KeyServer through any firewalls, you will need to grant access to the KeyServer address through UDP port 19283 and likewise for any KeyConfigure admin connections. In addition to UDP access, KeyConfigure's reporting functionality requires access through TCP port 19283 as does the optional KeyReporter program. Consult the Firewall Settings documentation (online) for complete details (including timeout issues).

For basic license management and audit services, KeyServer’s processor demands are minimal. A slow computer will suffice and there will typically be power left over to run user programs or other services at the same time. When a KeyServer supporting thousands of clients with many months of accumulated usage and audit data generates a complex report (at the request of KeyConfigure or an external reporting tool), the time required will be highly dependent on both the cpu and disk performance of the host. When KeyServer is managing data for tens of thousands of computers, fast report generation is best achieved using KeyServer’s automatic data export feature. Then you can take advantage of KeyConfigure’s internal and external reports running against a separate, high performance, SQL server. But even for such large scale reporting demands, KeyReporter, with its automatically scheduled report generation often makes the desire for “instant” reporting irrelevant.

Many sites find it convenient to run the KeyServer process on a general purpose, network services computer that is also set up as a mail server, print server, file server, fax server, web server, etc. In such an environment, KeyServer will typically be the least demanding of processor overhead, except when running reports. An alternate strategy is to put only a few services on several inexpensive computers both for redundancy and so that reconfigurations and restarts will be independent and will not affect all services at once. A similar goal can be achieved by installing KeyServer and other services each within a dedicated virtual machine.

Remember that we use the word “server” to mean any computer (or virtual computer) that is hosting a network service such as the KeyServer process. KeyServer does not require a “file server” or a “network operating system” (NOS), but it will manage license compliance and perform software audits for programs stored on multiple local volumes and multiple file server volumes.

The K2 image includes KeyServer installers for 4 different operating systems: Windows (NT4, 2000, 2003, XP, Vista, 2008, 7), Mac OS X (10.3, 10.4, 10.5), Linux (486), and Netware (4.1 or better). The implementation on all platforms is compiled from the same code base. Since KeyServer is a very “light-weight” process, the criteria in choosing the host are Authentication method, Export method, convenience, and report generation speed.

If you wish to use a particular Authentication or Export method this may force you to choose a particular platform for the KeyServer host computer, since certain modules only exist for one platform. Note: exporting and authentication are optional. See the Authentication and Export documentation for more details.

The amount of disk space required for K2 databases and log files is highly dependent on how many programs are being logged and on the number of computers being managed. A KeyServer supporting several thousand clients may generate 50 megabytes of log and usage data per day. A several hundred client KeyServer will require proportionally less space, perhaps 25 megabytes per week. Initially it will be most convenient to set KeyServer up with space for at least several months’ worth of data. Once you have configured logged and controlled programs and KeyServer has started to collect Usage data, you can get a better estimate of how much disk space is required per week or month of Usage data.

The RAM requirements for the KeyServer process are negligible even when supporting tens of thousands of clients.

Server Install – KeyServer

Installation of the K2 server itself (that is, the KeyServer executable program) is unique in that you only do it once, and only on one computer. This one computer also requires a license certificate file, server.lic, in order to enable KeyServer with a unique serial number, proper client count, and other parameters. If you choose Windows or Macintosh as the server platform, you can install the administrative components on this same computer but this is not required since remote administration is just as effective.

It is important to emphasize that KeyServer runs on a single computer to support both Windows and Macintosh clients. Use of the same license certificate on two or more computers at once can lead to unpredictable behavior for both client and administrative software.

If you are upgrading from KeyServer version 5.0, 5.1, 5.2, 6.0, or 6.1, you will need a new version 6.2 license file, server.lic. Consult the “Upgrades” document for details on how to avoid losing your existing configuration data or losing support for existing clients when upgrading.

The first step in installing a new KeyServer is to choose a host platform and then run the appropriate Server installer from the K2 image folder. For platforms other than Windows and Macintosh, consult the “OS Details” appendix

After the installer is finished, there is still one more step required before launching the KeyServer process: You must install your custom license certificate file, server.lic, in order to enable full KeyServer functionality with support for your licensed number of clients.

For evaluation you don’t need a server.lic. Without it, KeyServer will use instead the default file, eval.lic, which is created by the installer. See the “License Certificate File” documentation for a description of restrictions imposed by the default evaluation license.

You obtain your custom license certificate from Sassafras as an e-mail attachment. The e-mail explains how to save the license certificate as a file named server.lic and then copy it into the KeyServer Data Folder.

The server.lic is a text file readable by any text editor. You must not save it in any format other than text nor alter it in any way. If it does become altered, KeyServer will regard the file as “not valid”. This will have the somewhat unexpected consequence that KeyServer will then attempt to find another valid license such as the eval.lic file to use instead.

If you have configured the Windows Explorer or Macintosh Finder to “hide file extensions for known file types”, the actual name assigned when saving a file can be a surprise. When you instruct a save dialog to use the name “server.lic” while saving as text, what you end up with is a file named “server.lic.txt”. It may appear to be named “server.lic” but the actual file extension, ".txt", is hidden. KeyServer will not find the file until you remove the .txt extension from the full name.

The standard install location on Windows is C:\Program Files\Sassafras K2\Server\

The standard install location on Macintosh is /Library/KeyServer/ on the boot drive.

Regardless of platform, the server installer creates a folder containing the KeyServer program and a sub-folder called “KeyServer Data Folder”. Copy the server.lic file into the KeyServer Data Folder. It is not necessary to remove the eval.lic file, since the server.lic will take precedence. If there is already a server.lic file in place, be careful! You will have to figure out whether to replace it. If this is an upgrade install, or you are adding clients to your K2 license, see the “Upgrades” document.

The server installers set up the KeyServer so it will start automatically whenever the host is booted.

On Windows XP, NT, 2000, 2003, or Vista use the services control panel to start the KeyServer process. For testing a new installation it is also possible to double click on ks.exe to run it as an application. But note: you will get an error message, “can’t load...”, if you attempt to run KeyServer simultaneously as a process and as an application.

On Mac OS X, the installer will bring up an Applescript applet for starting and stopping the KeyServer process, but in general, the KeyServer is started via launchd.

It is important to consult the “OS Details” appendix for specific KeyServer launch options available under other operating systems and for details on which options are set up by the installer for automatic KeyServer startup (if any).

The KeyServer process will activate in one of three states:

i) full service with support for the licensed number of client accounts

(a valid version 6.2 server.lic is installed)

ii) service for a limited number of clients supported in evaluation mode

(there is no valid server.lic but the default eval.lic has not expired)

iii) no service

(the eval.lic has expired and there is no valid server.lic)

On some of the host platforms, there is a minimal status screen which displays the KeyServer state, but on others the state is only reported to a console or error log. For more information, read the “OS Details” appendix.

Caution: if you launch a second KeyServer on a computer that is already running a KeyServer process (either in foreground or background), things can become confusing. Depending on the operating system, you may or may not get an error message and various network protocols may or may not communicate as expected. Always shut down any previously running KeyServer process before starting KeyServer.

Shadow Install – KeyShadow

In addition to the states listed in the previous section, the KeyServer program has another behavior when it is installed with a “shadow” license (shadow.lic) instead of a server license (server.lic). The installed service then becomes a “KeyShadow” which mirrors the KeyServer's data in order to take over service in the event of a network failure. KeyShadows are not necessary. Assuming K2’s defaults are accepted while setting up license controls, then controlled programs will be allowed to run when the client computer is off-line or when the KeyServer is unreachable for any reason. It is only when the default "allow launch offline" is unchecked or when the optional "keyed" control method is used that KeyShadows become important.

If the optional “keyed” method of securing software against piracy has been employed for one or more applications, then installation of one or more KeyShadows is advisable. A keyed program is altered in such a way that it must obtain its key in order to run. Hence for keyed programs, KeyShadow's ability to provide an alternate path for a client computer to obtain a key can be a very important fail safe mechanism whenever the KeyServer is unreachable for any reason (e.g network failure or hardware failure of the KeyServer host). Note: an unkeyed program that is controlled by a KeyServer can be configured with its default “allow launch offline” option disabled - in this case, KeyShadow will be just as important for this controlled unkeyed program as it is for keyed programs.

KeyServer will add a KeyShadow address to its “shadow hint list” when an installed KeyShadow first makes contact with its parent KeyServer. Clients will receive a list of shadow addresses automatically every time they login. KeyShadow is designed to automatically mirror all of KeyServer's configuration data (in an encrypted form). A KeyShadow will start serving whenever KeyServer doesn't respond to periodic status requests from the shadow process. If there is a network or hardware failure that prevents clients from reaching the KeyServer, they will then try to reach a KeyShadow.

Requirements for hosting a KeyShadow are similar to KeyServer but with insignificant storage and processor demands.

When the KeyServer component is running as a KeyShadow process, clients must be able to connect to the shadow host address using UPD port 19315 (instead of 19283 used by KeyServer).

Since the standard eval.lic does not have a custom serial number for unique identification, it is not possible to “shadow” a standard evaluation KeyServer. Hence KeyConfigure connected to an evaluation KeyServer will not display its shadow menu - you cannot create a shadow.lic file so you will not be able to create a KeyShadow install.

To create a KeyShadow, choose a computer host that is strategically located so clients are likely to be able to reach it even when the network link to the KeyServer host is broken. Then:

1. Connect KeyConfigure to the running KeyServer and from the Admin menu, select “Create Shadow Certificate...”. You will be asked to assign a “shadow first-run password”. The shadow.lic file specifies the parent KeyServer's ip address, the KeyServer id, and the special “shadow first run password” which prevents easy duplication of the shadow install onto un-authorized computers.

2. Run the KeyServer installer to create a fresh install (never an upgrade!), and then copy the shadow.lic file into the KeyServer Data Folder. [Note: the installation of a shadow.lic instead of the server.lic is what makes the process run as a KeyShadow instead of the KeyServer.]

3. From an account with administrative rights, start up the KeyShadow process in a special “user interface mode” so you can type in the “shadow first-run password”. Then restart the process as a normal “faceless” task:

       cd /Library/KeyServer; sudo /Library/KeyServer/ks -c

       sudo launchctl load /Library/LaunchDaemons/com.sassafras.KeyServer.plist

Admin Requirements

KeyConfigure’s capabilities are essentially identical when run on either Windows or Macintosh. Even when auditing or managing licenses for both platforms, KeyConfigure can be run on which ever platform is convenient. There is one exception to this rule. Due to KeyServer’s optional keying feature for secure control, the actual step of using KeyConfigure to transform a copy of a program file into a keyed version must be done on the program’s native platform.

The “Deputize” feature which can be used to aid in the deployment of keyed program versions, is supported on Macintosh only for OS 9 installers..

KeyConfigure’s internal reports will require more or less memory and disk space depending on how each particular report is summarizing data and how many detail records must be downloaded from the KeyServer. One hundred megabytes of memory and half a gigabyte of disk space should suffice for most reports even when KeyServer is supporting thousands of clients. Extreme cases and more detailed resource estimates are documented in the “OS Details” appendix and the Reports documentation.

Except as noted above, the hardware and software requirements for running KeyConfigure are minimal and generally the same as for the client component (see below). The KeyServer hosts connections from KeyConfigure on UDP port 19283 and on TCP port 19283 (for reports).

Admin Install – KeyConfigure

Run the Admin Install on one or more computers where it will be convenient for you to manage KeyServer. You may find it convenient to install KeyConfigure on the KeyServer machine itself (assuming the server host is Windows or Macintosh), but this is not a requirement.

The default password for the KeyConfigure administrative connection is “Sassafras” (first letter capitalized). Communication is via UDP and TCP/IP on the default port 19283. You will need to open this port in any firewall that is between the admin computer and the KeyServer.

Reporting – KeyReporter

KeyReporter is an optional component which provides web access to all the same reports which are available in KeyConfigure. It also allows you to configure reports to be run automatically on a schedule. It can be installed on the same computer as KeyServer, or on a different computer. For more details on installation, configuration, and use of KeyReporter, see the KeyReporter documentation.

Client Requirements

Client computers must be connected to the network and properly configured with TCP/IP. Mobile clients, (i.e., portable or laptop computers), can be configured for use of controlled software while disconnected but they must be on the network to gain a KeyServer account when the client software is first installed.

It is best to set up your DNS server with an alias name configured to resolve to the IP address of your KeyServer host computer. Then clients are configured using this DNS name instead of the hard IP address.

The client software, KeyAccess, is designed to have negligible impact on performance regardless of the specific operating system and hardware environment. If a client computer is configured to audit for installed software, mounted local disks will be scanned periodically by KeyAccess. Otherwise, KeyAccess is active briefly at startup time while it establishes a session with KeyServer, and then again whenever a program launches or quits. In addition, KeyAccess responds to session maintenance tickles from the KeyServer approximately every 5 minutes. With a properly functioning network connection to KeyServer, these transactions are essentially instantaneous.

The KeyAccess client software can be run under any 32 or 64 bit Windows operating system (Windows 95 thru Windows 7). The task manager will report from 5 MB to 15 MB of “Mem Usage” for KeyAccess, but this total really only reflects which shared system resources are included. The actual size of KeyAccess executable code (including its private transport libraries and private data) is under 1 MB.

The KeyAccess client software can be run on any PowerPC or Intel processor running Mac OS X, version 10.3 or better. The system memory requirement is under 5 MB. In order to run a client on Mac OS 9 (classic), you must use KeyAccess version 6.0 classic.

Client Install – KeyAccess

When KeyAccess is installed on a client computer, it must be configured with the desired address to access the KeyServer. You will have to know the IP address or the DNS name of the KeyServer machine.

Run the Client Installer on all desktop computers that you wish to manage with KeyServer (and on Thin Client servers). KeyServer is licensed to support a fixed number of client records which can be any mix of Windows, Macintosh, and Thin Clients. Each of these computers needs to have the client software, KeyAccess, installed in order to communicate with KeyServer. When installing, your KeyServer should be up and running so you can immediately use KeyVerify to test KeyAccess’s network connection to KeyServer.

During the Client install you will be asked to supply a DNS name or raw IP address for the KeyServer. Don’t enter the Windows NT server name or NetWare server name into the KeyAccess Setup “Connection” field! The address field in the setup dialog is for the raw IP address or a DNS name of the KeyServer host.

When a new client first connects to the KeyServer, a new computer record is created and it shows up in the "Computers Window" in KeyConfigure - click on the word "refresh" at the bottom of the window to see new items immediately. You can inspect this window to confirm that clients are logging on correctly.

For a large scale client deployment, the client installer can be pre-configured with the KeyServer host address and customized preferences for silent installation or upgrade of the client components. General purpose software deployment tools (including image cloning, logon scripts, network install, Group Policy Objects, NetBoot, etc.) can also be used. For more information, consult the following help pages: Deployment, Cloning, Customizing Mac Installer, and Customizing Win Installer

Mobile Client Install – KeyAccess & KeyCheckout

For mobile computers (laptops or portables) that will use controlled software off-line, you may want to use the Mobile Client Installer instead of the basic Client Installer. It installs the program KeyCheckout in addition to the basic client components. KeyCheckout is used to manually “checkout” a software license for use on a mobile computer that won't always have a network connection. You must specify an expiration time when the license will be automatically reclaimed by the KeyServer.

If K2client.exe has been run on a Windows client, and then you subsequently want to add KeyCheckout, you must first un-install the “Sassafras K2 Client” (using the “Add or Remove Programs” control panel) before running K2Mobile.exe. Alternately, you can simply copy the executable file, keychk32.exe, into the folder, Program Files\Sassafras\Client\, and then create a short cut in the Start menu..

By default, a controlled program will be allowed to launch when offline, regardless of the license limits specified in the controlling license. The offline usage will be recorded by KeyAccess and uploaded to KeyServer when the client returns to the network. For such programs, using KeyCheckout may not be necessary. When a program has been transformed to a keyed version then KeyCheckout must be used in order to support offline launches. When the default behavior for an unkeyed program, “allow launch offline“, has been disabled then KeyCheckout must likewise be used in order to support its offline launches on managed computers. One final alternative is to use Leased Licenses to allow clients to go offline for a few days and continue to be able to use controlled programs which they have used recently. See the License Details documentation for more on Leased Licenses.

Depending on your management strategy, you may not want all mobile computers to use the KeyCheckout program. Use the basic Client Installer when you want to provide only online access for KeyServer managed software, or when controlling only unkeyed programs with offline usage allowed. Note: a slow modem connection is completely adequate to transparently support a remote connection to KeyServer. Thus online usage can be quickly enabled from anywhere (assuming that port 19283 is not being blocked by a firewall).

Testing – KeyAccess logon & KeyVerify

After installing KeyAccess on a client computer and configuring it to connect to your KeyServer, bring up the KeyAccess Setup window:

In the Windows Control Panel folder click on the item named KeyAccess.

On Mac OS X, open System Preferences and click on the KeyAccess preference pane.

Select the Logon button in the KeyAccess Setup window – if KeyServer is running and everything is set up correctly, you will get a message confirming a connection. Otherwise, double check the installation steps and make sure the network is functioning correctly with no firewalls blocking UDP port 19283.

Use the KeyVerify button in the setup window to further test and verify KeyServer’s license control functionality. You can find the KeyVerify license listed in KeyConfigure's Licenses window. Play with its license configuration parameters and usage reports while running the KeyVerify test from various client machines. This is a good way to test complex configurations using a controlled program (KeyVerify) that is always installed on all client computers.

The KeyVerify test program is not only controlled but it was created using the “keyed” option so it will launch only if KeyAccess is successful in obtaining its key. When the launch does succeed, KeyVerify displays status information about where it got the key – either from KeyServer, a KeyShadow, or from a checked-out key stored on a local disk. If you get the error message KA–280, it means that KeyAccess has failed to connect to either a KeyServer or a KeyShadow and no portable key for KeyVerify is available. Open the KeyAccess Setup interface and check that you have correctly selected the KeyServer name or correctly entered its address.

External Reports

The Admin installer creates a sub-folder called Report Modules that contains the standard set of “internal” reports. These internal reports are interactively linked to all of KeyConfigure’s other windows. There is a point and click interface (using context menus) for restricting reports to just the scope of interest based on the current selected item: a computer, a program, a license, a division, a filter, etc. Conversely, double clicking on items within a report window will open the corresponding details window: program details, computer details, license details, etc. See the Reports documentation for more details.

On Windows, the Admin installer gives you the additional option of installing external report templates in Crystal Reports and Microsoft Access formats. These are placed in the External Reports folder within the Admin folder. To support external queries to the KeyServer databases, a KeyServer ODBC driver, ksODBC, is also installed as part of this option (note: ksODBC driver is installed on Macintosh, but without sample reports). A default data source (DSN) is created with the default target address 127.0.0.1 so you can easily test these external reports under the assumption that there is a KeyServer hosted on the same computer. The DSN “KeyServer DataSource” is configured by default with the password “Sassafras” - a matching password must be created for the External Report Account in order to enable connections.

Any SQL based reporting tool that makes use of ODBC for connecting to a data source can access KeyServer’s database tables. The Admin installer includes the necessary ksODBC driver to support these connections from any reporting tool. External reports have the advantage of being completely customizable (all fields are accessible through KeyServer’s “External Reports Account”) but they have the disadvantage of not supporting live links to KeyConfigure’s other windows. Furthermore, some of the more complex internal reports (e.g. histograms) may be difficult to replicate with an external tool. See the External Reports documentation for more details.

External reports can be customized to use multiple data sources so software audit and usage reporting can be integrated with other corporate data such as purchase or contract tracking data. As an alternate strategy for custom integration with other corporate data, KeyServer can also export its internal databases to any SQL server. If this SQL server also hosts other corporate data, then external reports can be pointed to this single data source and customized to integrate data from other tables. With an appropriate ODBC driver configured for connection to a remote SQL server, KeyConfigure’s internal reports can still be used in addition to the external reports.

The advantage of exporting to a dedicated SQL server can be faster report generation. This may become important when KeyServer is supporting tens of thousands of clients and the reports are customized to perform intricate server side joins with multiple tables.

Use the built in context sensitive help for details on the individual internal reports and ODBC configuration. If you have installed the external report templates, check for documentation in the External Reports folder.

Backup

All the custom license management information (program keys, license counts, network access requirements, etc.) that you set up using KeyConfigure is stored within the KeyServer Data Folder on the KeyServer machine. You should always maintain a backup of this data so you can recover from a disaster such as a disk failure.

If some programs are “keyed” for secure control, it is most important that you back up at least the License Data file – keyed programs are useless without it. You should also keep backups of the original program files themselves, before they are keyed. Consult KeyConfigure’s built in Help for details on how to set up a schedule for automatic backups and how to configure a remote storage location.

Upgrades

K2 - Getting Started

    - Appendix: OS Details
    - Firewall Settings
    - Client Deployment