Please enable JavaScript to view this site.

A-Shell Consolidated Reference

Navigation: ATE > Introduction > Installation

Multi-User Installation

Scroll Prev Top Next More

Added December 2011

At sites where ATE is being installed for many users, a semi-automated process is available to (a) make sure that all users have the same—and correct—connection settings that enable their connection to the host computer, and (b) shift some of the responsibility for configuration away from individual users and onto the firm's IT staff.

Here is an overview of what has to happen:

ATE files are installed onto the user's PC. The location of the installation program is not relevant; it can be local, on a local network, on a flash drive, or out on the internet somewhere. When run, the installation program is going to copy files onto the user's PC and place them, by default, in the C:\ATE directory. ATE can be run from files stored in a common network location, but this is not recommended.
The values and variables from the ATE connection profile, which define the various ways in which ATE will know how to connect to the host computer, are loaded into the registry of the user's PC. Once this is done, all subsequent runnings of ATE will use the values from the connection profile and automatically connect the user to the host computer.

The procedure described here deals exclusively with setting up and using the connection profile. Actual installation of ATE files (first bullet above) has to be handled manually or using standard network deployment tools.

Setting up a default connection profile

The basis for a common installation procedure is the customized connection profile.

The system administrator (hereafter "SA") installs ATE on a PC, connects to the host computer using the settings and variables that she wishes to have used by ALL users, saves those settings, and exports them into a named connection profile file. The name of the profile is determined by the method being used to distribute it to users; see below. This profile, which contains all of the settings that will be required by each PC, now needs to be loaded into the users' copies of ATE.

Since ATE reads the connection profile data from the Windows registry, rather than from a file, the connection profile cannot simply be read by the individual users' copy of ATE at the time of connection; instead, the profile must be imported into ATE on each PC, which will in turn write the values into the registry.

There are two methods by which the connection profile can be loaded into the copy of ATE running on an individual PC, described below. Note that both methods require that ATE be already installed on the individual PCs.

Method 1: User-Directed Import

This method is a little less work for the SA and a little more work (and required know-how) for the user.

When the SA creates the connection profile, she calls it "OURPROFILE" (or anything) and places it in a location that is accessible by the user and individual PC. This can be on the user's PC, or a flash drive, but the most common procedure is to place it in a network folder. For example, she creates a file called S:\ATE\OURPROFILE.CFG.
If ATE has not already been installed, the user (or somebody) runs the ATE installation program, which installs the ATE files. No connection profile is needed, used or built during this step.
The SA communicates to the user (a) he will need to run an import procedure, and (b) the location of the profile.
The user (or somebody) runs ATE on the PC and is presented with the Configure Connection dialog. The user selects Configure, then Import, navigates to S:\ATE\OURPROFILE.CFG, and finishes the import procedure. The values from OURPROFILE.CFG are now loaded into this PC, and this user should be connected to the host computer.

Method 2: Automatic Import

This approach is a little more work for the SA to set up, but a little easier for the users. It requires that the SA give the connection profile the specific name "default-ate.cfg," and that it be placed it in a directory where ATE will find it.

There are four directories, relative to each workstation, which are scanned by ATE if it is launched and does not find a connection profile. The SA simply has to place default-ate.cfg in one of these directories, and ATE will find and load it automatically. The choices of directory are described below along with notes suggesting why one might be better than another, depending on your environment.

The directory from which ATE will run, normally C:\ATE. If you configure your network so that all users launch ATE from a common directory on a server, e.g. X:\ATE, then a single copy of default-ate.cfg is all you'll need.
The "Common Templates" directory. In Windows jargon this is known by the symbolic name CSIDL_COMMON_TEMPLATES, or FOLDERID_CommonTemplates, or %ALLUSERSPROFILE%\Microsoft\Windows\Templates. This directory is often read-only (so you may need admin privileges to save the file there, but that will protect other users from overwriting it), and may be a directory common to all users, depending on your environment.
The "Common Documents" directory. In Windows jargon this is known by the symbolic name CSIDL_COMMON_DOCUMENTS or FOLDERID_PublicDocuments, or %PUBLIC%\Documents. As with the templates directory, it is sometimes a location common to all users, depending on your environment.
The user's downloads directory, i.e. %USERPROFILE%\Downloads. This is certain to be a directory unique to each user, but it might be convenient if you store your default-ate.cfg file on a web server, possibly along with the install package, and instruct your users to simply download it.

If you put the default-ate.cfg file in any of the above directories, ATE will locate it on the first (or any) launch when there is no profile yet defined, and will simply ask if the user wants to load the default profile from that location. Note that it is ATE, and not the ATE installation program, that does the scanning of directories, finds and imports the profile, etc.

Comments

There is one variation of the auto-import feature that might be useful in some situations. If the user executes a shortcut that specifies an explicit ATE configuration, but that configuration is not defined in the user's registry, ATE will scan the same directories listed above, looking for a .cfg file with the same name as the requested profile. If found, it will automatically load it. If not found, it will repeat the scan for a default-ate.cfg file and give the user an option to load it if found. This situation might arise in a Terminal Server environment where many users are sharing a single installation of ATE, and even a common desktop shortcut to launch it with a specific profile. But since the profiles are stored in the registry, each new user would probably need to import the profile from a disk file the first time.

Regarding the registry storage, the normal location for the profile storage is within the "Current User" hive, meaning that each user login stores their connection profile information privately. Whenever a new profile is created (or imported), you have the option of storing it in the "Local Machine" hive (common to all users of the machine) instead, but this requires administrator privileges and thus is not usually practical. The one case where it might be practical is if an administrator of a machine used by many individuals wanted to create a single profile that could be shared by all of those logins. In that case, only the administrator would be able to edit the profile, but all the users could load it.