cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
234
Views
5
Helpful
2
Replies

User Directory Shows **LASTNAME**

Callmanager 5.1(2) with an LDAP integration to Active Directory. Some of our records are showing up with their last name changed to **LASTNAME**. I did a recent Bulk Update for device association, though I'm not sure if this is related. Is this a behavior of LDAP integration when you update the CM local database? Do I have to wait until nightly synchronization to see this correct itself or do we have a bigger problem? Any assistance would be appreciated.

2 Replies 2

Rob Huffman
Hall of Fame
Hall of Fame

Hi Brian,

You may be hitting this very odd Bug;

CSCsh53133 Bug Details

BAT overwrites last names with **LASTNAME**

Symptom:

When using Bulk Administration / Users / Update User function, BAT overwrites last names with **LASTNAME**

Conditions:

The BAT file looks as follows:

USER ID,PASSWORD,MANAGER USER ID,DEPARTMENT,PIN,DEFAULT PROFILE,USER LOCALE,TELEPHONE NUMBER,PRIMARY EXTENSION,ASSOCIATED PC,IPCC EXTENSION,MAIL ID,USER GROUP 1,CONTROLLED PROFILE 1,CONTROLLED DEVICE 1

userid,,,test,,,,,,,,,,Standard CCM End Users,SEPXXXXXXXXXXXX

Workaround:

1. Modify BAT file so it includes 'LAST NAME' field set to '*'. This field should be before the user group, user profile and controlled device fields.

Example:

USER ID,LAST NAME,PASSWORD,MANAGER USER ID,DEPARTMENT,PIN,DEFAULT PROFILE,USER LOCALE,TELEPHONE NUMBER,PRIMARY EXTENSION,ASSOCIATED PC,IPCC EXTENSION,MAIL ID,USER GROUP 1,CONTROLLED PROFILE 1,CONTROLLED DEVICE 1

userid,*,,,test,,,,,,,,,,Standard CCM End Users,SEPXXXXXXXXXXXX

2. When using above BAT file, specify '*' in the 'Value for fields to be ignored' field on the BAT job configuration page.

1st Found-In

5.1(1.1000.3)

Fixed-In

5.1(1.2105.1)

5.1(1.9131.22)

5.1(1.9131.23)

5.1(2.1000.11)

6.0(0.9901.136)

6.0(1.1000.37)

6.1(0.39000.15)

6.1(0.39000.16)

Hope this helps!

Rob

Thanks Rob for the info. Sounds like you hit the nail on the head. Fortunately when I checked the records today they've all returned to normal. Presumably the LDAP integration sync took care of the problem.