UCCX Agent Unable to Login

[Garrett Hensley]

I recently swapped out phones for an agent. Old phone=7965 new phone=8851. I tested the new phone in my office and was able to successfully login. The old phone started giving login issues saying it could not contact the login service. suspected it had something to do with having the same extension on 2 phones so I removed the DN from the 8851 (still on my desk). The 7965 still couldn't login. So, I decided to go ahead and make the swap. Now the 8851 just shows a spinning icon when trying to login in. I assume it's a similar condition that it has trouble contacting the login service, or there is some kind of error, it's just not giving me any feedback. Other agents have no issue. I can login using Finesse and triple checked the password on the phone service before I made this post. I removed the extension from the old phone and even hooked it back up so I could see it removed. I also since deleted the old phone. Can someone point in the direction of some troubleshooting? Some login error logs would be helpful, but if it's not reaching the service i don't know where to look. 

Garrett

[Sean Lynch]

Without trace logs, there's not much we can do but guess, here...
1. Did you check and make sure the "Allow Control of Device from CTI" check box on the device is enabled in the CUCM configuration?
2. Did you remove the old device from the RMCM application provider's list of controlled devices?

Being able to view the trace logs for the failed registration/login would be beneficial here...

-Sean

[Garrett Hensley]

Deleting the device removed it from the RMCM application provider's list of controlled devices and I have double checked the box. 

Are you talking about enabling trace logs in CUCM? It's been a minute since i've done that. 

Garrett

[Sean Lynch]

Yup; that's where I would start.  CTI Manager and Application Event log should provide a failure message pointing out where the control messages stop.

-Sean

[Garrett Hensley]

@Sean Lynch I did a test login and now i've grabbed the traces...i think. Can you point me in the right direction? I'm looking at the cti folder and the sdl files. I can see calls, but i don't see anything that looks like the phone trying to hit a web service.

Garrett

[Garrett Hensley]

@Sean Lynch I did find the information below:

00293405.010 |14:47:45.064 |AppError |ready_CtiDeviceRegistrationStatusRes - Device=SEPXXXXXXXXXXXX not found in mDeviceNameToLineHandleList

[Anthony Holloway]

Actually, just deleting the phone is known to cause problems. You'll likely need to rebuild the phone, add it back to the app user, then remove it from the app user, then delete it.

You might be able to identify this old phone issue in the Engine logs with the following command:

file search activelog uccx/log/MIVR "MIVR-SS_RM-7-UNK:Terminal SEPXXXXXXXXXXXX"

where you replace the Xs with the old phone mac address. If there are hits (recently, not old ones) then UCCX still thinks the Agent's old phone is king.

[Garrett Hensley]

@Anthony Holloway would i need to rebuild it and get it to register again, or just add it back to CUCM?

[Anthony Holloway]

I don't know for sure if it has to be registered but my gut says no. Alternatively, you can restart the UCCX Engine after hours, in which case it should clear up all stale information/connections. Did you see the old phone in the logs during a failed sign in attempt?

This is what a failed login looks like: note the phone is the wrong/old phone for this user.  You will need to remove this phone from the RmCmUser correctly.

220748965: Aug 26 13:16:33.262 CDT %MIVR-SS_RM-7-UNK:Processing msg: CTISetAgentStateReqMsg (Rsrc:aholloway InvokeID:2 State:LOGIN Forced:False)
220748981: Aug 26 13:16:33.412 CDT %MIVR-SS_RM-7-UNK:Terminal SEPFC3FDB0BBCD4. Will not check IPv4 properties as terminal is unregistered.
220748983: Aug 26 13:16:33.412 CDT %MIVR-SS_RM-3-LOGIN_FAILED:Login of resource failed: Module Name=RM component,The description of a message sent from/to the RM=CTISetAgentStateReqMsg (Rsrc:aholloway InvokeID:2 State:LOGIN Forced:False),A specific description for a trace=problems in JTAPI or CM

This is what a successful login looks like.  The state change is Not Ready (aka UNAVAILABLE) with reason 32760 (Agent Logged In)

221094106: Aug 26 13:45:52.679 CDT %MIVR-SS_RM-7-UNK:Processing msg: CTISetAgentStateReqMsg (Rsrc:aholloway InvokeID:2 State:LOGIN Forced:False)
221094127: Aug 26 13:45:52.843 CDT %MIVR-SS_RM-7-UNK:Terminal SEP0023242282BA is successfully validated.
221094134: Aug 26 13:45:52.847 CDT %MIVR-SS_RM-7-UNK:Rsrc: aholloway New State:UNAVAILABLE Old State:LOGOFF Reason code:32760

[Garrett Hensley]

@Anthony Holloway , no I didn't but I didn't attempt another login yet since i'm remote. I'm not familiar with the activelog and how long it keeps log in attempts.

[Anthony Holloway]

It's variable, but I think it would be reasonable to expect 24 hours of logs on most systems, and anything more than that is subjected to trace level setting, agent counts, call volume, etc..

Activelog is simply "the logs" of the server. The fact that it says active in the name has to do with the active/inactive partitions where the software is installed.

You could just download the logs from RTMT and then search them with like Notepad++, but the file search command on the CLI of the server is faster in my opinion.

[Garrett Hensley · Accepted solution]

After creating a TAC case and spending another full day of going through logs and troubleshooting to no avail....we restarted the Cisco Finesse Tomcat service after hours and that resolved the issue.

[Anthony Holloway]

Thanks for the update. I guess it's not just Windows Servers which need reboots. ;)