I upgraded a BE CUCM/Unity Connection server from 22.214.171.1240-13 to 126.96.36.1990-3 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.
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.
# 127.0.0.1 localhost
# ::1 localhost
192.168.4.13 usaxrx2up101 usaxrx2up101.na.xerox.org
192.168.4.10 usaxrx2up101 usaxrx2up101.na.xerox.org
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:
arp -d *