How it Works
Installation and Client Configuration
XML Config File format and example

How it Works

Hiker uses a xml config file to hold the information about the terminal server farm, this file can be located on a windows share, local hard disk or web site. When hiker launches it needs to know the location and type of this file, first it looks for command line arguments to get this information from, if these are not found it looks in the registry.

The command line arguments are as follows:

/t:[type] – This is telling hiker where to get the file from. The only valid values are UNC if the config file is on a windows share/local disk or HTTP if the file is hosted on a web server
/l:[location] – This is the path to the file if the type is UNC, or the url if the type is HTTP. If the file path or name contains a space, you need to enclose the location in quote marks like you would if you were at a command prompt, otherwise the path will be cut of at the space.

So, an example to call hiker if the config file was located on the file share \\servername\hiker\hiker_conf.xml would be:

hiker.exe /t:UNC /l:\\servername\hiker\hiker_conf.xml

If you are using the registry instead of a command line option, you need to set two string values in the current user hive, that again contain the type and location of the file. If hiker has been launched with command line options these are ignored.

Registry Keys:

HKEY_CURRENT_USER\Software\we3soft\hiker\ConfigType
HKEY_CURRENT_USER\Software\we3soft\hiker\ConfigLocation

You can download and example .reg file here, double click it to add the information to the registry.

As long as the location of this file is valid, it will then be copied down to the users local profile (in their application data\we3soft\hiker folder)

The hiker application then checks this config file is valid,  and uses the Cassia .net library to communicate with each terminal server. It asks the servers if the current user has already got a session open, and how many users have sessions open on that server.

If the user has already got a session open on any of the servers in the Farm, they are listed and the user can double click on one to re-connect to that session. If the user has no sessions open then an RDP connection is launched to the server with the least number of users connected.

Installing Hiker

As hiker is a tool for multiple users across multiple client machines, we have tried to make the installation as transparent to the end user as possible. There is a MSI version of the installer, so you should be able to push it out via a group policy, as well as a standard win32 installer.

To configure the applications two settings (location and type of config) you could use a vbs login script to create a shortcut on the users desktop with the arguments, or use it to create the two reg keys and put a shortcut to the application on the desktop.

There is an example of the script available to download, this contains examples of both options

Download Example Login Script

If you want to do a silent install using the standard exe, you can call the setup exe with the following command line arguments, this will mean the user will not have to answer any questions during the install:

/sp- /silent /norestart

XML Config File

Hiker gets all of its server farm information from an xml config file that is copied down as the application starts. This config holds the name of the farm, the number of servers in the farm and the names/status’s of the servers in the farm.

Example Config

<hiker>
<farmname>Production</farmname>
<no_servers>3</no_servers>
<server>
<name>prod-ts1.domain.com</name>
<status>1</status>
</server>
<server>
<name>prod-ts2.domain.com</name>
<status>1</status>
</server>
<server>
<name>prod-ts3.domain.com</name>
<status>0</status>
</server>
</hiker>

As you can see, the first tag is the <hiker> tag, then the name of the server farm is in the <farmname> tag. The farm name can be anything you want, it is just for your own reference. Next is the number of servers in the farm, this is held in the <no_servers> tag.

Next we come to the <server> tag. We have one of these for each server in our farm. In this tag we have <name> and <status>. The <name> tag needs to hold the name of the server the user would connect to (it could also hold the IP address of the server if you prefer), and the <status> can either be a 1 or a 0. If it is set to a 1 then the server can be used, if it is set to 0 this means the server will be ignored and wont be connected to.

The <status> is in here to make it easy to set servers off-line,  without having to remove the whole server section out of the config file.