Problems with display name, phones registering after replication rebuild

[RickKulackiJr1518]

First of all, thanks in advance for dealing with my relative new-ish knowledge of the Cisco systems. Yesterday working with Cisco support, they helped with a replication relationship rebuild with our servers here. For the record we are using CUCM Version 10.5.2.11900-3 if that helps. We had a few issues prior to this rebuild, namely that of devices not displaying the correct display name, even when changed in the CUCM. I recently added a phone, and while it pulls an IP, its registration is rejected in the CUCM. 

Prior to this issue occurring, we had an issue in our server room with the HVAC unit, and the servers were shut down gracefully. After restarting the servers, a recovery disk ended up needing to be used on the server to get the VMWare back up and running. While it appears that the two servers to check CUCM show the same data, and are in sync 

[jason-mcgee]

Rick,

Let's go over one issue at a time. What is the model of the phone that is being rejected? Can you attach screen shots of the phone configuration page and the directory number configuration page. Top and bottom of the directory number configuration page and top of the phone configuration page.

Jason 

[Anthony Holloway]

If the phones registered, but wont take a configuration change, like display name, it sounds a little like an ITL issue. To verify, go into the settings on the phone itself, and somewhere in the settings erase the Security Settings or specifically the ITL entry. You may just have to google "cisco ip phone XXXX erase itl" where XXXX is your phone model.

For what it's worth, the ITL is basically like a white list of servers your phone will take configuration changes from. If the identity of your servers change for one or more reasons, and the phone wasn't told, then the phone will continue to register and function, it just wont take any further config changes.

[RickKulackiJr1518]

Thanks for that information. I just tried that with one of the phones in question, and the config change still did not take. The phone is showing the old Display Name, and not the updated one.

[TONY SMITH]

Maybe try a factory reset just as a test, to clear everything out of that phone.

[RickKulackiJr1518]

After trying that, now that phone is having it's registration rejected. I believe that there is a bigger issue at play, and have put a call in with Cisco TAC on this issue. Thanks for the advice all.

[Anthony Holloway]

Ooo, sorry to hear it got worse. Please post back what the solution was. It kind of sounds like DB replication issues. I.e., You make a change on the Pub, but the phone pulls its config from the Sub, and the Sub doesn't know about the changes happening on the Pub.

[RickKulackiJr1518]

So after working a bit on the phones I was finally able to get the two phones with the display name/Caller ID issue fixed. I did a security reset on those phones, followed by a factory reset, followed by a re-naming of the extension in CUCM and applying the changes. That got the phones to register the name correctly.
What I'm stuck with now is the phone that is not registering. I grabbed a second phone to test with this morning, set it up in the CUCM, and it also will not register. I ran the RTMT to check what was going on, and got the following error for both phone (copy and pasting one as an example):
Aug 16 08:18:30 BALUCM01 Error Cisco CallManager : 24323: BALUCM01 Aug 16 2019 12:18:30 UTC : %UC_-3-LastOutOfServiceInformation: %[DeviceName=SEP5017ff777e3a][DeviceIPv4Address=10.60.20.175/24][IPv4DefaultGateway=10.60.20.1][DeviceIPv6Address=][IPv6DefaultGateway=][ModelNumber=CP-6941][NeighborIPv6Address=][NeighborIPv4Address=10.60.100.12][NeighborDeviceID=HPGMD01385002.highpoint.local][NeighborPortID=GigabitEthernet2/0/30][DHCPv4Status=1][DHCPv6Status=1][TFTPCfgStatus=1][DNSStatusUnifiedCM1=1][DNSStatusUnifiedCM2=0][DNSStatusUnifiedCM3=0][UNKNOWN_PARAMNAME:DNSStatusUnifiedCM4=0][VoiceVLAN=20][UnifiedCMIPAddress=10.60.20.10][LocalPort=35795][TimeStamp=1858][ReasonForOutOfService=105][LastProtocolEventSent=0x1][LastProtocolEventReceived=0x9d][ClusterID=StandAloneCluster][NodeID=BALUCM01]: Information related to the last out-of-service event
Checking the Error Code 105 I see it means The device closed the TCP connection due to a restart triggered internally by the device because device failed to download the configuration or dial plan file.

[Anthony Holloway]

Did you end up opening that TAC Case?

[RickKulackiJr1518]

Yes I did, have played phone tag with the tech so far.

[RickKulackiJr1518]

So an update. Spoke with the TAC today, and after checking RTMT, Wireshark and resetting a phone I am testing with that will not register, he has sent a firmware upgrade for the 6941. I did discover on RTMT that our TFTP was not running on the server here, and started that. After starting the TFTP, both of the phones that will not register now are getting ReasonforOutofService error 24: The device closed the TCP connection due to receiving a registration rejection from the Cisco Unified CM

[Anthony Holloway · Accepted solution]

I'm a little shocked the TAC engineer didn't help you past that last error and get your phone registered. Keep posting the journey, this is interesting. Good luck.

[RickKulackiJr1518]

And the resolution: The TFTP Server Service was not running on the CUCM. After re-starting it, deleting and re-adding the phones, all the phones in question now are registered and working properly.