01 June 2011

Changing Cisco UCM's LDAP Field Mapping

Just had another request from a Cisco UCM customer that is using the LDAP synchronization feature (DirSync) where they initially set up the field mapping between "Phone Number" field to the Active Directory "telephoneNumber" field. They have other plans for the "telephoneNumber" field and want to change the mapping to something else, but they found that the field mapping cannot be edited once sync has been setup. I've been asked by several colleagues the method I use to resolve this.

Background
CUCM uses DirSync service to perform one-way replication from a LDAP directory (such as AD).  I'm not going to go into detail about it but you can find more about it in the Cisco SRND UCM 8.x.  If you do a search you will also find a few blog posts on the subject because most Cisco UCM engineers do not have a background with Microsoft products.  Especially getting the correct X.500 search base can be unfamiliar to most network engineers.

Problem
Whenever I put in a Cisco UCM solution from scratch or setting up LDAP synchronization for the first time I choose to sync "Phone Number" in CUCM to the "ipPhone" field in AD.  The "ipPhone" field has been in the AD schema since version 2000 and you may not have even noticed it on the standard user properties sheet, but it is there.

The issue is that Microsoft products like Exchange and OCS/Lync make considerable use of the telephoneNumber field for different things.  Exchange will use this field when users receive voice mail notifications from internal users. If you are a mobile user, you want to see the DID of the calling user on the Email, not a 4-digit extension that you cannot dial from your cell phone.  Exchange GAL is another use case where a company has multiple locations with a consolidated Exchange organization, but still have a partially distributed call processing architecture. It doesn't make sense to have CUCM hijack the telephoneNumber field for the purposes of the "Corporate Directory" for just those locations where CUCM is deployed.

Solution
Anyone who has gone to the LDAP configuration settings notices that they cannot simply modify the mapping.  So the next logical thing an engineer will do is A) Screen shot the 5-6 lines of configuration, B) delete it, and C) re-create it. That will work, right?

So you get to step B and you see this warning, "You are about to permanently delete this Directory Configuration. This will delete all users from Cisco Unified Communications Manager that were synchronized by this configuration. This action cannot be undone. Continue?"

Scary Message
If you read all the gory details of the SRND and its past iterations you would know that when sync is down it doesn't delete the End-Users, it simply flags their state as "inactive".  When an account is "inactive" it disables PIN/Password (that is the impact).  At 3:15am cluster time, if an account has been "inactive" for more than 24-hours, THEN it is deleted (and you loose CUCM group membership, PIN, Controlled Device associations, IPCC Extension, User Device Profile associations, etc.).

I just did this on a production 7.1(5) system last week. Now, if you click "OK" on the Scary Message above what happens in real life is that all user accounts immediately switch to the "inactive" state.  Now you have at least 24-hours to re-configure the LDAP configuration with your new field mapping, this time the way you want, before they get deleted.  In this window where the accounts are in an "inactive" state, all authentication with the accounts is DOWN so plan accordingly.

With the UserID field, same rules apply as if you are setting up LDAP with a pre-existing End User database. The UserIDs MUST match up or else the account will be deleted.  So don't think you can use this method to go from sAMAccountName to UPN.  If you want to switch from sAMAccountName to UPN or Email, do a BAT Export, delete the sync, delete the users, re-sync with the new field mappings, and use BAT import to get all the CUCM elements back into the End-User config.

As with all changes like this with CUCM, run a full backup before you do anything.  With CUCM you never know when some bug will show up and ruin your evening plans.  I also like to do a BAT User Export All Details, just in case :)