Solved: Personal Communicator User Can´t Connect to Presence (Service)

spencercarlos · ‎06-15-2010

Hi to all.

Here is the issue. I have about 40 users currently up and running on a Cisco Unified Comunications Manager 7.1.3 with a Presence Server 7.0.6 and active directory Windows 2008.

I have all working 100%, except for one user. This user can´t get connected to presence, althought it logins correctly to Personal Communicator. Everything works (softphone, calls) but the messaging service does not, and all users are shown as offline.

I logged this user on a machine of another working user, and firewall does not seems to be the issue.

I used Show Server Health on the CUCP and it all shows green (OK) status, except for the presence that remains in connecting status.

Now here is the interesting fact happening at the moment. This user named "MARBELYS", appears with a similar name when i tried to do the search for users, but with a $ in the end (MARBELY$). You can check on he attachment file.

I already checked on the Active Directory Users, also checked on the users from the CallManager list, and also on the Users integrated with the presence server, but this user (MARBELY$) does not appears at all.

What can i do to solve this?...

Thanks in advance

htluo · ‎06-16-2010

Try this:

1) Go to CUCM > System > Licensing > Capability Assigment. Uncheck both CUP and CUPC boxes for marbelys.

2) Go to CUPS > User Management > End User. Make sure CUP and CUPC license was unchecked for marbelys.

3) Go to CUPS > Serviceability > Tool > Control Center - Network Services. Restart "Cisco UP Intercluster Sync Agent"

4) Go to CUCM > System > Licensing > Capability Assigment. Check both CUP and CUPC boxes for marbelys.

It should fix the problem. If not, you need to open a TAC case.

Michael

View solution in original post

spencercarlos · ‎06-15-2010

And By the way i already have tested:

1)Restarting the presence server. (trying to refresh the Presence-Active Directory Integration)

2)Restarting Each of the Services separatedly.

But the problem remains.

Thanks in advance btw.

Jonathan Schulenberg · ‎06-15-2010

I logged this user on a machine of another working user, and firewall 
does not seems to be the issue.

If you log in to CUPC from a known-good workstation as this user, does it work or not? I cannot tell from this statement. If it does, what happens in the reverse senario where a known-working user logs in to CUPC from the problematic workstation? If the swap test fails you are almost certainly facing a firewall issue: something is blocking the SIP messages to CUPC on that one workstation. A packet capture of that switchport would confirm.

Now here is the interesting fact happening at the moment. This user 
named "MARBELYS", appears with a similar name when i tried to do the 
search for users, but with a $ in the end (MARBELY$).

CUPC gets this directly from LDAP. Again you could confirm this with a packet capture; or, a troubleshooting-level log capture from CUPC. The record has to exist; CUPC is not inventing it. It's probably worth noting that this is the CN attribute in LDAP, not the username.

spencercarlos · ‎06-16-2010

j.schulenberg escribió:

I logged this user on a machine of another working user, and firewall does not seems to be the issue.

If you log in to CUPC from a known-good workstation as this user, does it work or not? I cannot tell from this statement. If it does, what happens in the reverse senario where a known-working user logs in to CUPC from the problematic workstation? If the swap test fails you are almost certainly facing a firewall issue: something is blocking the SIP messages to CUPC on that one workstation. A packet capture of that switchport would confirm.

Now here is the interesting fact happening at the moment. This user named "MARBELYS", appears with a similar name when i tried to do the search for users, but with a $ in the end (MARBELY$).

CUPC gets this directly from LDAP. Again you could confirm this with a packet capture; or, a troubleshooting-level log capture from CUPC. The record has to exist; CUPC is not inventing it. It's probably worth noting that this is the CN attribute in LDAP, not the username.

Hi Jonathan. Yeah sorry if i did not especify it correctly. But yeah its not a firewall problem, because i am logging from a PC that belongs to another user, which is working 100% on its Personal Communicator. Add to that is once i log into the user´s PC (Marbelys) with another account it works 100%. So its really a problem with that account only..

j.schulenberg escribió:

Now here is the interesting fact happening at the moment. This user named "MARBELYS", appears with a similar name when i tried to do the search for users, but with a $ in the end (MARBELY$).

CUPC gets this directly from LDAP. Again you could confirm this with a packet capture; or, a troubleshooting-level log capture from CUPC. The record has to exist; CUPC is not inventing it. It's probably worth noting that this is the CN attribute in LDAP, not the username.

I agree that the issue has a lot do with the LDAP-Presence Server integration. The problem is that the CallManager does not list that MARBELY$ username, it only shows the correct user MARBELYS with the associated extension 654, etc...

I will so a screen capture of the Active Directory Users and CallManager users, and even the users show in the Presence Server.

By the way i put how can i overcome the problem with the CN attribute on this time.

On this post i attached some screen captures. Also in the first post there are a couple of Presence Server configuration captures!.

htluo · ‎06-15-2010

Could you set CUPC trace level to detail (CUPC > Help > Enable Detailed Logging) and recreate the problem?

Then upload the CUPC problem report here.

Thanks!

Michael

http://htluo.blogspot.com

spencercarlos · ‎06-16-2010

htluo escribió:

Could you set CUPC trace level to detail (CUPC > Help > Enable Detailed Logging) and recreate the problem?

Then upload the CUPC problem report here.

Thanks!

Michael

http://htluo.blogspot.com

Here i Attach the log you requested.

Thanks in advance Michael!

htluo · ‎06-16-2010

Here's what we got from the traces:

Username = marbelys

CUPS IP = 192.168.9.4

cupc IP = 192.168.30.10

Proxy Domain = domosa.com

CUPC tried to register to CUPS and got "503 Service Unavailable".

Without the server logs (SIP Proxy and Presence Engine), it's very difficult to tell. But have you rebooted the CUPS server?

Michael

http://htluo.blogspot.com

spencercarlos · ‎06-16-2010

htluo escribió:

Here's what we got from the traces:

Username = marbelys

CUPS IP = 192.168.9.4

cupc IP = 192.168.30.10

Proxy Domain = domosa.com

CUPC tried to register to CUPS and got "503 Service Unavailable".

Without the server logs (SIP Proxy and Presence Engine), it's very difficult to tell. But have you rebooted the CUPS server?

Michael

http://htluo.blogspot.com

Hi Michael. Is there a way to create those server logs?. And yeah i already rebooted the server, and even while it is up i tried to restarting all services. Trying to get the rid of the duplicated user in the search "MARBELY$"..

Here i attach the active directory users.

Thanks in advance.. Tell me what else you need..

htluo · ‎06-16-2010

What we need are:

1) Set "SIP Proxy" and "Presence Engine" trace level to "debug" and enable all options.

2) Start packet capture on CUPS with CLI command "utils network capture file cups count 1000000 size all host all 192.168.1.100". Please replace 192.168.1.100 with the CUPC(client) IP address.

3) Restart CUPC and wait until it stablized.

4) Press Ctrl-C on CLI to stop capture.

5) Use RTMT to collect "SIP Proxy", "Presence Engine" and "Packet Capture Logs" from CUPS.

If you need further assistance, feel free to open a TAC case.

Thanks!

Michael

http://htluo.blogspot.com

spencercarlos · ‎06-16-2010

htluo escribió:

What we need are:

1) Set "SIP Proxy" and "Presence Engine" trace level to "debug" and enable all options.

2) Start packet capture on CUPS with CLI command "utils network capture file cups count 1000000 size all host all 192.168.1.100". Please replace 192.168.1.100 with the CUPC(client) IP address.

3) Restart CUPC and wait until it stablized.

4) Press Ctrl-C on CLI to stop capture.

5) Use RTMT to collect "SIP Proxy", "Presence Engine" and "Packet Capture Logs" from CUPS.

If you need further assistance, feel free to open a TAC case.

Thanks!

Michael

http://htluo.blogspot.com

Hi Michael, here are the logs. Please tell me if you need anything else and of course if the logs got captured correctly.

Thanks in advance!!

htluo · ‎06-16-2010

I don't see any logs. What are the file names?

Michael

spencercarlos · ‎06-16-2010

Here they are.. I have no idea why it did not upload on thje previous time..

Thanks in advance!!!

htluo escribió:

I don't see any logs. What are the file names?

Michael

spencercarlos · ‎06-16-2010

Sorry but they are all queued and then deleted.

Here a rapidshare link.!!!

http://rapidshare.com/files/399841700/logs2.rar.html

Please tell me if you received them correctly or if you need me to upload it via another site.

Thanks

htluo · ‎06-16-2010

Try this:

1) Go to CUCM > System > Licensing > Capability Assigment. Uncheck both CUP and CUPC boxes for marbelys.

2) Go to CUPS > User Management > End User. Make sure CUP and CUPC license was unchecked for marbelys.

3) Go to CUPS > Serviceability > Tool > Control Center - Network Services. Restart "Cisco UP Intercluster Sync Agent"

4) Go to CUCM > System > Licensing > Capability Assigment. Check both CUP and CUPC boxes for marbelys.

It should fix the problem. If not, you need to open a TAC case.

Michael

spencercarlos · ‎06-17-2010

Hi Michael. This did not solve but i think this is the most that we can do in the CUP and CUCM side.

We are now going to dig deeper in the active directory and see if this is a problem related with active director DB username error.

Thanks for the help.

I will update this once i have finished with the Domain Controller checking.