This article outlines troubleshooting steps to take when encountering a "Test Connections to Agent" button that fails to test successfully.
When attempting to connect to a Communications Agent service with the ’Test Connections to Agent’ button on the General tab of the Computer, the test fails with the following error:
"Failed to connect from [machine1] to the Status Service on [machine2] via TCP Port 7033, TLS with Certificate. The Communications Service may not be running, communications may be blocked, or you may have specified the DNS name or IP address incorrectly."
and
"Failed to connect from [machine1] to the Status Service on [machine2] via TCP Port 7033, Basic256. The Communications Service may not be running, communications may be blocked, or you may have specified the DNS name or IP address incorrectly."
There may be additional error text after these messages.
This message can be caused by a number of configuration issues. Possible causes are:
- Make sure the Software Pursuits SureSync MFT Communications Agent service is started on the remote machine you’re attempting to connect to. This can be done through the Services MMC.
- Expand the Computers node of the SureSync MFT Desktop and click on the Computer in question. This will be under Servers or Workstations depending on operating system type. The name in the list must be the NetBIOS name of the machine. If you used a name other than the NetBIOS name of the machine, delete the entry and add the machine again using the correct name.
- Check the connection details under Listen Configurations for the computer in question. The defaults are a TCP, Port=7033, TLS with Certificate connection used for data transfer and a (Config) TCP, Port=7033 connection used for Agent configuration data exchange. On the Options tab of each connection is the Default Access Name used to access the machine. This can be a NetBIOS name, IPv4, IPv6 or fully qualified domain name (FQDN). If no name is defined, the computer name is used. The same Default Access Name should be defined for both connections.
- You could also be missing the advanced user right "log on as a batch job" on the Communications Agent machine. Verify that this right is assigned to the account you have listed under "Login Name" for the machine you’re trying to test to. This is assigned in Local Security Policy under Administrative Tools. Under Local Policies | User Rights Assignments is the "Log on as batch job" right.
- Ensure that the clocks on the computers in question are accurate. .NET cryptography will reject requests when the clocks are greater than 5 minutes apart. An error from .NET should be logged in the Application Event Viewer indicating that problem.
- On the problem remote Communications Agent, you can try resetting the configuration file back to default. This will only make a difference if you have launched the Local Agent Configuration Utility and made changes. To reset, on the remote machine go to Start | SureSync MFT | Local MFT Communications Agent Configuration Utility. Click on the 'Local Agent Options' tab. Click on the 'Reset to Default Configuration' button. Answer 'Yes' to the prompt and the utility will close. Bring up the Services MMC and restart the Software Pursuits SureSync MFT Communications Agent service. Test the connection again from the SureSync Desktop.
- Confirm that the Software Pursuits SureSync MFT Communications Agent service is running as Local System. To do so, launch the Services MMC and right click on the Software Pursuits SureSync MFT Communications Agent service. Click on the "Log On" tab and confirm that "Local System account" is selected. If you had to change this setting, stop the service and start it again for the change to take effect.
- The final possibility is that there is a router or firewall somewhere between the main SureSync MFT installation and the Communications Agent, which is blocking traffic on SureSync’s port. The default port is TCP 7033. Please make sure the port is open on any hardware firewalls/routers between the machines that might be blocking our traffic.
The Windows Firewall has become a very common cause of this error message. By default, the SureSync MFT installer will attempt to configure an exception to allow the Communications Agent traffic through. However, you should verify this is setup correctly and add a rule if needed. It is often helpful to turn the Windows Firewall off as a test. If the connection is then successful you know the issue is with the Windows Firewall.
Another potential issue relates to NAT forwarding in firewalls. Assume you have SureSync MFT installed on ServerA in OfficeA. OfficeA is located in San Francisco and is connected to OfficeB in New York. The New York office has a firewall. In OfficeB are ServerB and ServerC which you want to synchronize with ServerA using the Communications Agent. This two destinations can be a problem if you don’t have multiple public IP addresses because firewalls can only forward traffic from one IP address/Port to one internal destination. In this case, you need separate public IP addresses for each of the machines or define different port numbers in the Inbound Connections for ServerB and ServerC in the SureSync MFT Desktop. The other option is to install SureSync in New York. This allows you to access the one machine in San Francisco via a public IP that is properly forwarded to ServerA by the firewall in OfficeA. The other New York machine can be accessed via a local IP address or DNS name which gets around the NAT firewall issue.
Open Port Checker Tools
A number of different web sites can be used to test if a port is open. You can visit one or more of these sites, enter the IP address being used to reach the Communications Agent and port 7033 to test and see if the port is really open. If this test fails, the port is not open and is still being blocked by a firewall or security device of some type.