Difficulty is encountered when configuring a remote Distribution Center (DC) for use with a LiveUpdate Administrator 2.x (LUA 2.x) server. What are the common points of failure?

Messages displayed when connections are tested::

"Connection failed." instead of the desired "Connection to lua2313_test was successful." (if lua2313_test is the name of the remote DC)

One LiveUpdate Administrator 2.x server is usually all that is required, even in large environments. A well-resourced LUA 2.x server can successfully distribute contents in up to one hundred Distribution Centers (DCs) throughout the corporate network. Endpoints and other Symantec products can then download their necessary updates from these convenient DCs.

LUA 2.x has capabilities built-in to ensure it can communciate with its DCs. When "test connection" is clicked in the LUA console, the LUA server will attempt to post a small file called minitri.flg to the Distribution Center using the configuration provided.

There are many possible causes of failure, but the most common are (1) misconfiguration of the path, and (2) permissions.

Recommended Resources

Links to the official Symantec knowledgebase articles on creating DCs can be found at the bottom of this page. Following these procedures will enable a remote DC to be created.

There is also an excellent illustrated article in the Symantec Connect forums on Configuring Distribution Center in LUA (https://www-secure.symantec.com/connect/articles/configuring-distribution-center-lua) - merely examining how a LUA 2.x server's example DC was correctly configured will help to confirm the correct procedure has been followed.

Is the URL Correct-?

One very common cause of failure is that the path to the DC, as configured in the LUA, is wrong. Navigate to the "Edit Distribution Center" screen, and simply copy the URL and paste it into the address bar of an internet browser window. Does that URL actually exist? Can that configured URL be accessed and opened from this computer?

Misconfiguration is common, especially if the DC is a new HTTP or FTP site hosted on a remote IIS server. (When creating a new site on an existing IIS server, a unique port number must be used. Attempting to connect to the pre-exiting IIS server site's default port 80 will fail.) In the example shown below, the IP and port were corrected for the environment, and the status of this DC changed to "Ready."

Logs from the Remote DC Examining the LUA server's logs alone will not provide all the answers. Assuming that the remote DC is on an IIS server with IP 10.10.8.94: examining that IIS server's logs may provide some clues. (Also consult Microsoft's article: The HTTP status codes in IIS 7.0 and in IIS 7.5 to learn what the code numbers mean!)

In this case: there was a misconfiguration. When the administrator attempted to configure the DC ("Edit Location" screen), they entered in a "Root Directory" called "LUAtypoDC." These IIS logs show that when the LUA server attempts to test the configured connection, it cannot find any directory of that name.

In the example below, examining the IIS log made it clear that the username was entered incorrectly in the LUA console:

Not all of the fields are manditory on the "Edit Location" screen where the DC is configured. If the contents are not located in a subdirectory, leave "Root Directory" blank. If a proxy server is not involved, leave those fields blank.

When supplying "login credentials for distribution access to remote location," it is generally just necessary to provide the username. Attempts to also add the domain name may cause the connection attempt to fail.

Playing with the Proxy

After any changes are made to the proxy configuration (Configure > Source Servers), stop and restart the LUA Tomcat service of the LUA 2.x server. This will confirm that new credentials and other details about the proxy are in effect at all levels of networking. Changing proxy-related details in the GUI and saving them is not sufficient.

If Technical Support's assistance is required:

This is one of the few situations where it is preferable to put the LUA 2.x server into DEBUG: ON mode. By default, the lua-application logs will record only if there was a success or failure without any extra details.