Menu déroulant pour mobile

Category : Unified Communications

CUCM Dirsync Troubleshooting

One of my customer told me that one of its end user was not appearing in its CUCM database. I think it is worth to make a blogpost about it.

There are already plenty of resources on the subject (Example) but I will mainly focus on the troubleshooting section here.

There are 2 ways to configure your users on a Cisco CUCM, you can either configure them statically or you can synchronise your CUCM with your Active Directory Domain.

If you want to make sure that your AD – CUCM synchronization is working, you first need to check that the DirSync Service is activated on the CUCM Publisher:


Then you need to select which AD Attributes will be used as the USERID field within the CUCM. The best logical choice to me is the sAMAccountName since it will be used by the users to authenticate themselves. (Browse to System => LDAP => LDAP System)


Now you need the following:

    • a Service Account to browse through the Active Directory Domain
    • Search base : Where the CUCM will sync all the OU that are located at under the Search Base OU.
    • LDAP Server Information.


I would advise you to use the AD “mail” field as the Directory URI CUCM field. This will be used by as a SIP URI that will be linked to the user extension. You can change this on the go if you are running 10.5.2. Otherwise you have to create a duplicate LDAP sync and then remove the old and obsolete one.

Now I can check if my users are created but I noticed that indeed, one of them was missing and I would like to understand (and fix) why !


If I want to troubleshoot this, I need to activate the debugs into the CUCM serviceability menu.


From here you have 2 options : RTMT or CLI.

I’m not an RTMT fan so I will show you the CLI way to find DirSync logs into CUCM.

The logs are located into /cm/trace/dirsync/log4j

Now you have  to search for “roy” into your debugs to find why the user is being rejected:

You can see that there is another EndUser that has the same MailID field so the CUCM does reject the synchronisation for the real user named “Roy”.

There are many other reason why the CUCM can reject a user from the synchronisation process. The most common one is when you do not enter one of the mandatory field: FirstName of LastName.

Also I recommend to read some really important LDAP Design considerations from the Cisco 10.x SRND Design Document

  • Ensure that the LDAP directory attribute chosen to map into the Unified CM UserID field is unique within all synchronization agreements for that cluster.
  • The LDAP attribute sn(lastname) is a mandatory attribute for LDAP Synchronization of users.
  • The LDAP attribute sn(lastname) is a mandatory attribute for LDAP Synchronization of users.
  • The attribute chosen as UserID must not be the same as that for any of the Application Users defined in Unified CM.


If you have any comments or questions, do not hesitate to post a comment.


CUCM 10.5 Upgrade issue

Hey everyone.


I have just finished my upgrade to CUCM 10.5.2 and I faced an issue at the end of the ugprade.

Of course this always happen after you spent some hours waiting for the upgrade to be successful 🙂

According to the very good Cisco DocWikiVMware Tools are specialized drivers for virtual hardware that is installed in the UC applications when they are running virtualized. It is very important that the VMware tools version running in the UC application be in sync with the version of ESXi being used.

This clearly states that it is kinda mandatory for you to install or ugprade your VMware tools after every upgrade.

Depending of the version and application you are running, there are several methods to upgrade your VMware tools:

  • Method 1: Using a COP File: This is deprecated and used only for 8.0 UC servers. Definitely not something you will deal with if you are deploying a new UC infrastructure
  • Method 2: Using the CLI: This method will be used if you run UCCX 8.5(1)+ or 8.5 UC Servers or CUCM IM and P version 9. This is disruptive and the server will reboot twice.
  • Method 3: Upgrade from VI Client. Very easy method. Will install while the server is in production and it is not disruptive at all. 
  • Method 4: Auto Upgrade during a server power cycle. Not disruptive at all and will auto upgrade.

Please bear in mind that most of the recent UC applications are compatible with either Method 3 and 4. I generally like to enable auto upgrade.

So let’s get back to our issue.

After I completed my upgrade, I went to the vCenter client to install the VMware tools but I faced a problem. It was just not working. I even rebooted my server twice but still nothing .. I still had that same issue (image below is just representing a similar issue)


I gave a look at the excellent support community and bug search tool… and I was lucky enough to find that I was not the only one facing that issue 🙂

Indeed there is a recent bug hitting CUCM 10.5 (and other apps I believe). CSCul78735

SElinux is preventing the VMware tools to be installed on the server. It is regulating access control security policies to the server and has been introduced in CUCM 8.6 (in fact it replaced Cisco Security Agent).

What we need to do is to bypass SElinux policies and here is
the (very complicated) procedure:

As soon as we do that, you need to install again the VMware tools and it worked for me.


Do not forget to enforce SElinux after you are done with the VMware tools installation.

Hope it can help you in your future upgrades 🙂



Cisco Expressway Setup

I am currently working on a Cisco Jabber project and my customer main requirement is that every users must be able to place calls in an easy way regardless from their location. Since the BYOD and Mobility are the trends I recommended the Cisco Expressway product line. I won’t go deep on how the expressway is working (this will be part of another blog post/series) but I’d rather share my experience regarding how to install an expressway. First and foremost I would like to say that I  have deployed 2 expressways for other customers and for my own lab and that I had no issue so far :). The problem here is specific to a particular ESXi version. I don’t have vCenter in this environment so the procedure slightly differs and I would heavily recommend to use the following documentation: Cisco Expressway VM deployment guide (8.2) When it comes to finalize the deployment I had this error :

  After a quick lookup I found many issues like that on the internet (always feel good when you are not alone right ? 🙂 ) VMware OVF Deployment KB They basically say that there is maybe an issue with the cert file when it is a multiple of 1024 and it is !!

  The workaround would be to deploy the .ova with the Open Virtualization Format Tool What I did is the following, I used that tool to recreate the OVA template from Cisco.

Let’s check both OVA files to see what it changes:


The certificate is gone from the template and you can see that ESXi can not verify the publisher


As opposed to the original OVA Template


The ESXi is running 4.1 and this issue has not happened on version 5.1 … I guess it was time to upgrade anyway 🙂 

My customer wanted me to open a TAC case to confirm that we could go live using that “hack” and Cisco told us that they are ok with that, obviously.