General ITCM Troubleshooting Steps

Document ID : KB000099956
Last Modified Date : 04/06/2018
Show Technical Document Details
This document describes some general troubleshooting steps of ITCM.
Client Automation (ITCM) -- any version.
Often times, recycling the services associated with ITCM can resolve a general amount of issues.

Here are the steps to fully stop all ITCM-related product services:
caf stop
caf stop ext
cam change disabled
csampmux stop

Alternate commands:
If "caf stop" gives an error, e.g. "failed to connect to local CAF service", then use: "caf kill all" instead.
If "camclose" gives a timeout error, then use: "taskkill /im cam.exe /f"
If "csampmux stop" gives an error, then use: "taskkill /im csampmux.exe /f"

Once services are stopped, delete the notification server cache file:

To restart services:
csampmux start
cam change auto & cam start -c -l
caf start

If the system has the .NET framework installed, you could also use WinOffline to recycle services.
The latest WinOffline at the time of publication is available here:

For connectivity type issues, ITCM uses the following general communication ports:
UDP 4104 -- CAM Messaging
TCP 4728 -- CSAM Bulk traffic (e.g. file uploads/downloads)

However, it's common place for CAM messaging to be configured to use TCP, in which case there are additional port requirements:
UDP 4104 -- CAM UDP Messaging
TCP 4728 -- CSAM Bulk traffic (e.g. file uploads/downloads)
TCP 7163 -- CSAM traffic for CAM TCP

Note: These ports must be opened bi-directionally!  That is, either side is able to initiate traffic to the other.

If you are using the infrastructure deployment wizard to install new agents, you need the following ports opened, in addition to the normal communication ports:
UDP 4104 -- CAM UDP Messaging
TCP 4728 -- CSAM Bulk traffic (e.g. file uploads/downloads)
TCP 7163 -- CSAM traffic for CAM TCP
TCP 7 -- Echo Request
UDP/TCP 135-139, TCP 445 -- RPC/SMB Share ports

Note: For Unix/Linux deployments, you also need the SSH/telnet port opened, typically TCP 22/23 respectively.

To test CAM connectivity, you can use the "camping" utility:
camping <hostname or IP>

This will send a 64-byte test message from CAM, to the specified host or IP.  If CAM is running/reachable there, it will receive the message and send a reply message.

In a growing number of environments, UDP traffic over a certain size is becoming filtered.  You can test sending various size camping's using a series of commands to find if your environment may have such filtering:
camping <hostname or IP> -s 128
camping <hostname or IP> -s 256
camping <hostname or IP> -s 512
camping <hostname or IP> -s 1024
camping <hostname or IP> -s 2048
camping <hostname or IP> -s 4096
camping <hostname or IP> -s 8192
camping <hostname or IP> -s 16384
camping <hostname or IP> -s 32768

The tests DO NOT have to be even powers of 2.  In some cases, network latency and RTT may prevent a  reply from being received within the 1 second wait time that CAM expects.  To see additional camping options, run camping --help.

If your environment is capping the UDP fragment size, you can add this line to your *CONFIG section in your %cai_msq%\cam.cfg file:
fragment_size = xxx
Where xxx is a fragment size that is comfortably below the maximum you found in your environment by running camping tests of varying packet sizes.

If you don't have a cam.cfg file in your environment, first generate a save.cfg file with:
camsave config

This will create a %cai_msq%\save.cfg file.  Edit it to remove all paths from the *PATHS section, as this will be a dump of running connections from memory, and it is not desirable to have CAM reload these connections every time it starts up.  Once the fragment_size parameter is added to the *CONFIG section, save as cam.cfg and recycle services again.

To test CAF connectivity, which will test both the CAF (application layer) and CAM (messaging layer) connectivity:
caf ping <hostname or IP>

If CAMPING is working, but CAF PING is not working, it can indicate a difference in encryption.  For example, one endpoint is using the out of the box ITCM certificates, while the other is using some custom ITCM certificates.  It could also mean the clocks are different by more than 10 minutes between the two endpoints.

If opening a support case, it's always recommended to attach the DSM/ITCM logs from the affected systems.

The ITCM logs can be found here:

The default location is:
C:\Program Files (x86)\CA\DSM\logs