Resolving Slow Access or Inability to Log In When DNS is Not Functional

If the master server is being recovered into the original infrastructure where general services are still working, such as DNS, Windows AD, etc., the following procedure is generally not necessary. This procedure is important to master servers hosting large numbers of clients where the master server is brought up in an environment with little or no supporting infrastructure. Of particular importance is DNS resolution for the client nodes.

Shortly after master server Catalog recovery, logging into the management console takes an extremely long time, or times out and fails completely. The cause is attributable to the lack of DNS resolution. The master server attempts to scan and resolve host names and it experiences a time-out for each host name, which prevents the database from initializing quickly. If left alone, the condition eventually clears on its own, but this could take a very long time.

The general procedures are covered in knowledge base articles 43562 and 39304. The first relates to invoking syncui, the other details setting the DONOT_CHECK_DUP_HOST option.

In summary, the syncui utility is used in this procedure. On Windows, open a DPX command prompt to run syncui. On Linux, do this by opening a terminal window with root access, then source the bin/bexenv script, and then run syncui. From syncui issue the following:

c s ip-address

db login sysadmin password

pref add DONOT\_CHECK\_DUP_HOST Y

pref get DONOT\_CHECK\_DUP_HOST

exit

Replace “ip-address” with the IP address of master server and replace “password” with the sysadmin password. The ‘pref get’ statement is intended to print the status of the newly set option to verify that it is active.

Restart the master server cmagent process and then attempt to log in again.