Q100099: Diagnosing the Desktop Manager Application Login

The desktop manager application can be run on the same machine that the JobServer.NET service is installed on. Or it can be run on a remote machine and used to manage the remote JobServer installation. There may be certain situations where the manager application experiences a problem communicating with the JobServer service. This article should help you determine how to identify and fix those types of issues.

Unable To Connect To The Server Error

When you run the JobServer.NET Desktop Manager Application and it responds immediately or within a few seconds with the error message: Unable to connect to the server. Please ensure that it is currently running. like shown in this example.

This usually indicates that the manager application is attempting to connect, but the connection was immediately refused by the server. This usually only happens for the following reasons.

• The JobServer.NET Service is not running on the specified server.
• There is a firewall or other software port blocking application on the server, or the machine you are running the manager application on.

To check if the JobServer.NET service is running, you can open up the Services app in Windows Control Panel. The service is likely to be listed at the bottom of the list. Scroll down until you find the entry for XCENT JobServer.NET. Check the status and if the service is in a stopped state, it should just need to be restarted.

If the service is running, and you are still unable to connect and quickly receive the error message: Unable to connect to the server. Please ensure that it is currently running., then it is likely that you will have to look for any installed firewall software or other similar package and determine how to configure it to allow the default port for JobServer.NET to be allowed for incoming connections. The default port for the service is port 7901. Some anti-virus suites will also contain features like a software firewall.

An example of this is that current versions of Microsoft Windows will have the Windows Defender Firewall installed as part of the operating system. The it the default for current versions. The default security it provides will allow the locally installed version of the JobServer.NET Manager Application to connect to and communicate with the service on the local machine. But if you try to use the manager application to connect to a different machine, or install the app on a different machine to manage your JobServer service, then the Windows Firewall will block that connection. If this occurs, then you want to provide a rule to allow the remote connections through Windows Firewall.

To do that, open the Windows Firewall and navigate to the Inbound Rules node in the left side panel. If there is not already a rule named XCENT JobServer Management, click on the New Rule action on the right side panel. When the new rule wizard opens, click the type of rule to the Port option and then click Next. In the Ports and Protocol step, select the option for Specific local ports and for the value, enter 7901 and then click Next. On the Action step, you will want to accept the default behavior of Allow the connection, and then click Next. For the Profile step, you should leave all the options checked, and click Next. Finally on the Name step, for the name field enter XCENT JobServer Management and then click Finish. When complete, you should now see the new rule listed under the Inbound Rules in the center section like shown below.

The Remote Name Could Not Be Resolved

If you run the JobServer.NET Desktop Manager, and when attempting to login, it sits and hesitates for some time before it finally responds back with the error message: An error occured connecting to the server: Unable to connect: The remote name could not be resolved: like shown in this example.

This error message usually indicates one of two issues. First, that there might be a typographical error in the name of the server you are trying to connect to. Double check the name, or the FQDN (fully qualified domain name) for any mispelling or errant characters in the name. The other most likely issue is that the DNS (domain name server) that the machine running the manager application is configured to use, is unable to resolve the name. An easy test to confirm the problem with the domain name would be to open a command line window and using the ping command to see if it can properly resolve the name. Use the command as shown below, but of course substitute the servername you want to use for the non-existant test server example:

C:\> ping testserver76.example.com

If the name is not being resolved by the DNS your machine is configured to use, you would see a message like shown in the following example screenshot.

You can contrast the bad response above, to the successful response shown in the example screenshot below. In this screenshot, you can see that a valid FQDN is used which should be valid most places around the globe. The fact that the very first line in the response echos back the FQDN we requested, immediately followed by a valid IP address. This alone confirms that the PING command was able to do a successful name lookup in DNS. It does not matter if replies are received by the ping requests or not. Only the status of the first line in the response is all that is needed to confirm if it was able to do a succesful name lookup or not.