Although VTS can operate with the same server controlling all services and configuration for the application, it is recommended that you specify different servers for different services. This is a convenient way of sharing tasks out to multiple servers, rather than inundating one server with the task of running all services, and will help prevent delays in the event that a server is lost. Because the Security Manager is a VTS service, you have the option of specifying a server other than the primary configuration server to manage it.
The choice of Security Manager servers is fairly arbitrary, but it is recommended that at least two servers be arranged: one as the primary Security Manager server; the other as a backup server in the case that the primary Security Manager server fails. Whatever servers you choose must be added to the Config.ini configuration file under the [SECURITYMANAGER–Servers] section.
The following example demonstrates the correct way to configure the Config.ini file when designating servers to manage the Security Manager tasks.
Config.ini
[SECURITYMANAGER-Servers]
Name = SMYTHE
Name = TERRY
In this final example, the results will be that workstation "Smythe" will be the primary Security Manager server, while "Terry" will be the backup Security Manager server; if "Smythe" should fail, "Terry" will act as the primary Security Manager server.
It is strongly recommended that you specify the servers and clients by name rather than by IP address. This is particularly important in networks where workstations may be dual-homed, or where dynamic IPs are assigned.
The same configuration of the Config.ini file must be present on every workstation that is running the remote application.
Note: In larger remote applications with a number of workstations, it might be wise to configure the Config.ini file prior to adding the application to all of the workstations that will be running it. This way identical Config.ini files will get copied to each of the workstations when they receive all of the application files from the server during synchronization.
It should be noted here for developers accustomed to earlier versions of VTS that the name of the SecurityManager service has changed from SecMgr to SecurityManager. Any section headers for entries in .ini files that are intended for the former SecMgr service will have to be updated to reflect this change (e.g. [SecurityManager-Servers], not [SecMgr-Servers]).
However, the SecMgr.dat data file remains unchanged. Existing applications with a SecMgr.ini file rather than a SecurityManager.ini file will still work.