Installing the K2 Client on Thin Client (Citrix, RDS) Servers

This is a followup to Counting K2 Client Licenses for Thin Clients, which covered the issues an Administrator must consider before deploying the K2 client (KeyAccess) to Thin Client Servers. This document covers how the client is actually installed, and what happens after. It assumes a simple three-server farm but applies to a thin client enviroment of any size or type. We’ll also assume that new computer records are created using the default ID settings – thin client sessions will be identified using the initiating client computer’s name.

Deploying KeyAccess is simple: the administrator chooses a time when the thin client servers can be rebooted and runs the K2 Windows client Installer (k2client.exe) on each server in turn. After supplying the DNS name of the KeyServer host to the installer and taking all defaults, each server is rebooted so that KeyAccess is running as a service on all three Thin Client Servers.

Whenever a user on a remote device initiates a thin client session, KeyAccess on the Thin Client server inserts itself into the session created on that Server. This is true both when the session is just displaying a ‘published’ app as well as when a full thin client desktop is displayed on the remote device.

When KeyAccess passes the session information to KeyServer it includes the IP and MAC addresses of the thin client server where the KeyAccess process is actually running. More importantly, however, the computer name of the remote device initiating the session is reported up to the KeyServer – a “thin client computer” record is created using this device name. Which Server is hosting the session is irrelevant. Usage of any controlled or logged program is properly linked to the initiating device. This ensures accurate licensing and useful reporting.

One final note: even if the KeyServer is configured to audit all new computers, when a record is created for a Thin Client session, auditing is not performed since it would be uninteresting to re-audit the thin client server host every time a distinct device connects to a thin client server and generates a new record in KeyServer’s computer table.