Showing results for 
Search instead for 
Did you mean: 

Attendant Console could not connect to server after upgrade

Level 2
Level 2


I upgraded a BE CUCM/Unity Connection server from to and after the upgrade, the AC client software could not connect to the CUCM server.  After checking all of the obvious things and rebooting the computer on which AC client was running, I finally figured out a workaround.  The CUCM server was configured with a host name of UCM1 and a domain of localdomain.  The AC clients were pointing to UCM1.  If I added a record in the client's hosts file (%WINDIR%\SYSTEM32\DRIVERS\ETC\hosts) which pointed UCM1.localdomain to the IP address of the CUCM server and then pointed the AC client to UCM1.localdomain, everything worked great.  I'm just wondering why this happened.  The client must pass the name of the server in the payload (rather than simply using the name to resolve to an IP address).  So why, all of a sudden, does the server care about the FQDN?  Just curious if anybody knows or has run into this same issue.



5 Replies 5

Hazel Pringle
Level 1
Level 1

Already repointed the IP address in the host file and LMHost still getting same unable to connect to server error. I include pics of both Host on top and LMHost on bottom. Do these look right, also do you have to put a loop back address on the router?


It was a really long time ago but I'd say that if this is the line you put in HOSTS:     usaxrx2up101

Then try this instead:

Then point the AC client to



Changed it to below; I was able to connect with the console on a different client but still getting a connection error.

# localhost name resolution is handled within DNS itself.

#       localhost

#          ::1             localhost           usaxrx2up101           usaxrx2up101


Any chance you could send me a Wireshark capture of the traffic coming to/from one of the affected client PCs during the login process?  Also, please include any log files in the client's AC application folder (or sub-folders) as well as event log data from the system and application event log for the timeframe spanning slightly before and after the login attempt.

Also before doing any of this please clear the DNS and ARP cache of the client PC:

ipconfig /flushdns

arp -d *



Steven- Apologies for the late reply, I will not be able to capture packet info during the login process. Thanks for your help on this matter.