Problems with Management Agents

Symptom: The Management Agent does not connect to the Management Server

Possible reasons:

Managed hosts with an encrypted file system (or another feature that stops a login screen from appearing when a host is restarted) do not connect to the Management Server after restarting until the user provides authentication credentials to allow the machine to proceed. This may cause situations where for example a software installation with the "Restart host" option enabled requires user interaction on the managed host.
Software installations and uninstallations on managed hosts are likely to fail if other software installations or uninstallations (not started from the administration interface) are running at the time when the Management Agent starts the installation or uninstallation operation.
On Unix, changing the network settings on Unix hosts may cause the Management Agent to lose the management connection, and requires restarting the Management Agent.

Symptom: The Management Agent on Windows does not connect to the Management Server

If this is the first installation of the Management Agent, check that there is a valid icb.dat file in the directory where ssh-mgmt-sysmonitor.exe is installed. By default, this is C:\Program Files\SSH Communications Security\Tectia Manager. If there is no icb.dat file in this directory, obtain a valid ICB file and copy it there. The agent will connect automatically within a couple of minutes. Once the icb.dat has been used successfully, Management Agent creates a router.dat and the icb.dat is deleted.
If you want to connect immediately, restart the Management Agent by running stop-mgmt-agent.bat and then start-mgmt-agent.bat or from the services control panel. Note that you have to have administrator privileges on the host to successfully restart the Management Agent.
If there is an icb.dat file in the directory, check that it is valid and intact by viewing it in a text editor. You might need to generate and download a new icb.dat file and follow step 1.
If the connection has been working in the past, but does not work now, try the following. Browse to the location where the Management Agent is installed. Stop the Management Agent by running stop-mgmt-agent.bat (or from the services control panel). Delete router.dat and icb.dat, if it exists, from this directory. Download a host specific icb.dat file from the server and start the Management Agent. Using host specific ICB downloaded from the host details view will not create a new entry for the host on the Management Server, instead the existing identity of the host is preserved.

Symptom: The Management Agent needs to connect to a new server

Remedy:

Stop the Management Agent.
Copy a new icb.dat file to the location where Tectia Manager is installed.
Wait until the new ICB is automatically loaded, or restart the Management Agent to connect immediately.

Symptom: The Management Agent recreates manually deleted Tectia Client connection profile desktop shortcuts

The user monitor module is responsible for creating the desktop icons, and it does so when it notices changes in certain directories or at specific time intervals.

The user monitor module checks the %ALLUSERSPROFILE%\Application Data\SSH directory and the %USERPROFILE%\Application Data\SSH directory of the current user for Tectia Client connection profiles, and reads comment lines in the connection profile itself, checking for flags that indicate whether a desktop icon should be created. If these flags are found, it checks for the appropriate shortcuts, and if they are not found, it creates them. It does the same thing for startup shortcuts.

The user monitor module runs separately from the rest of the Management Agent, just to perform these sort of synchronizations. Because of this, it is unaware of whether the client is connected to a server or not. Hence, it recreates shortcuts even if you remove the machine from management.

Remedy:

If you "uninstall" yourself from Tectia Server and want to delete the Tectia Manager -managed profiles, desktop icons, and so on, do the following:

Delete the profiles from %ALLUSERSPROFILE%\Application Data\SSH
The %ALLUSERSPROFILE% path will normally be either C:\Documents and Settings\All Users or C:\WINNT\Profiles\All Users.
Delete the corresponding profile from your %USERPROFILE%\Application Data\SSH.
The %USERSPROFILE% path will normally be either C:\Documents and Settings\<username> or C:\WINNT\Profiles\<username>.
Delete the corresponding shortcut from your desktop.
Check also Start → Programs → Startup for shortcuts to that profile.

Note on pop-up messages

The Management Agent currently uses the Windows Messenger Service to send pop-up messages to all users logged onto the system. If the Messenger service is stopped, Tectia Manager tries to start it before sending the message. After the message is sent, the service is stopped. If the service had already been running, it is left running. If the service cannot be started, the message is not sent.

To avoid receiving pop-up messages from the Management Agent, set the Messenger service to Disabled via the Control Panel. On Windows XP this can be done under Start → Settings → Control Panel → Administrative Tools → Services.

The service name is Messenger. To disable the service, double-click it and select Disabled in the Startup Type.

Symptom: Problems with Management Agent remote deployment on Unix

During Management Agent remote installation, file transfer is done over the terminal connection (rlogin/telnet) or by the scp2 secure file copy application (ssh2).

Remedy: If there are problems with the remote agent deployment, try using the selected connection method manually from Management Server to the managed host with the sshmgmt user account:

rlogin

mgmt-server$ su -l sshmgmt
mgmt-server# rlogin -l remoteuser remotehost

telnet

mgmt-server$ su -l sshmgmt
mgmt-server# telnet remotehost

ssh2

mgmt-server$ su -l sshmgmt
mgmt-server$ touch tempfile
mgmt-server# scp2 tempfile remoteuser@remotehost:
 <check that the file was transferred correctly>
mgmt-server# ssh2 remoteuser@remotehost