The key consideration is that when CUCM completes a DirSync operation what you have is a local database table (enduser) fully populated with the user information. This table stores attributes replicated from LDAP along with attributes that are locally significant to CUCM. Further, there are several other tables that are linked to the enduser table for things such as mapping user group membership, device ownership, and profile assignment (to name a few).
A related consideration is how the DirSync process works. In pre-9x releases, when you execute the first DirSync synchronization, all local accounts are flagged as in-active. The DirSync process runs a LDAP query and then evaluates each user object. Specifically, DirSync checks the attribute mapped to the UCM user ID. If an in-active account matches the LDAP user object, that account is re-activated and attributes are updated according to your LDAP attribute mapping. This process continues until all LDAP user objects are synchronized. Any user objects that remain in-active will be removed (completely) during the next garbage clean up cycle. I think this occurs every 24 hours. The time? Don't recall but 2am rings a bell (I could be wrong here).
In UCM 9x, you have the ability to have local active and LDAP active accounts. So, the DirSync process is different. If a user is already a local active account, it doesn't get flagged as inactive. However, a local active account can be converted to a LDAP active account. Local accounts that aren't converted will not be removed. The same isn't true for LDAP active accounts. If you have an LDAP active account and perform a sync, an account that isn't successfully found during the sync will be marked as inactive.
If you were to change the attribute mapped to the enduser user ID attribute (i.e. changing from samAccountName to UPN) then the challenge you will have is that CUCM will see the user objects from LDAP as new users. Moreover, you have to delete sync agreements before you can modify the LDAP attribute associated with the user ID. Deleting the sync agreement will delete the users associated with the sync agreement.
So, those are the challenges and considerations. What you need to do is find a way to carry information associated with the current end user objects in CUCM to what is essentially a new instance for the end users. One method would be:
1. Bulk Export all user information.
2. Open the bulk export file in Excel (or similar program)
3. Modify the user attribute in Excel from samAccountName to the UPN for a user.
If the UPN incorporates the samAccountname (e.g. samAccountName=wbell / UPN=wbell@ucguerrilla.com) then you can use simple formulas to clean the data. If it is more complicated then I would use a LDAP query to get the samAccountName and UPN attributes in another worksheet and then use vlookup to make the "swap".
4. Since the new LDAP synchronization is pulling in net-new accounts, you will be doing a Bulk User Update. So, you can then modify certain fields in the Bulk Export file to be ignored on import. This is relevant if you used Bulk Export All Details (which is just how I do things). If you go this route then you can use a character (e.g. #) in the cell values you want ignored. You can pick another character because CUCM will allow you to specify the character on Bulk Import (later step in the process).
5. Save the file as a CSV
6. Execute your LDAP changes to get the new user object info.
7. Upload the Bulk Import file.
8. Perform a Bulk Update on user objects to re-establish associations, group memberships, etc.
The thing that might get skipped with the above process is the Owner User ID attribute on phones themselves. This is different than the relationship established when you associate a device to an end user. I know it is funky but the database schema stores these relationships in different places and there is no dependency between them (unless done so programatically). Owner User ID is consideration if you are using ELM and UCM 9.x.
Which brings me to an idea around UCM 9.x and the challenge you face. UCM 9.x has the ability to convert active user IDs to Local accounts. I haven't researched this yet (though, I may try to test later as it is an interesting problem). I think it should be possible (if running UCM 9x) to do the following:
1. Convert end user objects from LDAP Active to Local Active. I didn't see a way to do this via BAT but it may be feasible using SQL to update the status. Some research is needed here.
2. Once converted, then you should be able to use a SQL query to update the userid attribute in the enduser table. This will be really simple if the UPN incorporates the samAccountName. One SQL update query can knock it out (depending on the number of user objects).
3. Then you can re-establish the LDAP agreements and perform a sync.
Assuming the above process is feasible then what would happen is that the DirSync process should recognize that a local active account (now defined with UPN) matches a LDAP user object and is converted to a LDAP active account in UCM.
I have used the first process I outlined on multiple occassions. I have not had the opportunity to test out the second process. It is just a thought (a hypothesis, if you will) that I have concerning UCM 9x and LDAP.
HTH
-Bill
(b) http://ucguerrilla.com
(t) @ucguerrilla
Please remember to rate helpful responses and identify helpful or correct answers.
