Cisco Support Community
Community Member

Bulk Import schema changes using CSV and AD


We are doing an UM 4.0.3 installation with W2K and Exchange 2003 and AD. My customer has some questions that I cannot answer and didn't see in this forum. Can you enlighten us?

Thanks much!

OK... I was able to use the CSV to perform the bulk import... the utility still -blindly- over-wrote the following AD (not Cisco Unity) attributes.




I would like answers to the following from Cisco:

1. Why does the utility overwrite already populated attributes that are NOT part of the attributes introduced by the Cisco Unity schema changes. Specifically, the following occurred.

-changed telephoneNumber which was (xxx) xxx-yyyy to yyyy

-changed givenName from Jeffrey to JEFFREY (it pulled the value

'JEFFREY' from the csv file.. this is the only reason I know that it overwrote this attribute.. same with sn)

-change sn from Edgington to EDGINGTON (again from the csv file)

-I'm also suspicious that it is overwriting 'mailNickname' (what the utility is calling your alias)

2. What attributes are needed in order to 'subscribe' a user to Unity... specifically, what happens if we pre-populate the attributes that unity is using (for example ciscoEcsbuDtmfld among others) via a perl script using LDAP?

The current version of this bulk import utility is very poorly written and the best case would be for Cisco to provide a utility that will not molest AD attributes that are already populated. For example the value for telephoneNumber... this is supposed to be a user-friendly display of a persons phone number... if I'm in Ohio and looking a phone number up via a phone listing that is coming from AD.. I need more than just the 4 digits that the utility placed into the telephoneNumber attribute. Additionally, the value 'telephoneNumber' is what is displayed by Outlook when you look a person up in the Global Address List... so, someone from my remote that wants my number would only see '6724' instead of

'222-555-6724' with the way this utility is currently behaving.

Cisco Employee

Re: Bulk Import schema changes using CSV and AD

I went ahead and forwarded this post to the DB group (the folks responsible for CUBI) – they did some testing on 4.0(3) to be sure but we are definitely not writing phone number (extension) information through to AD – I don’t even think this is possible. We’ll slurp in the business phone field as a default into the primary extension field for a user being imported from AD but that’s about it – we have no connection at all to the phone number field in AD. Not sure what to say to your customer about that particular finding other than it appears they’re mistaken – I reproed the same tests on my 4.0(4) pre release system and again don’t see us doing anything like this.

CUBI does update the display name on an import which is a bug (CSCdz00857) – a similar bug in the SA was fixed in an ES for 4.0(3) but a fix for CUBI is not yet available.

The first and last names are, indeed, synced – the first/last and display name data is also changeable in the SA – That’s how it is currently. That said, they’re right – we shouldn’t be updating the display name on the fly (again, this is a known bug noted above).

We don’t change the alias field and, again, our tests indicated that field is left alone.

Ideally the CSV import would only require the alias and extension fields for users that are being imported “standing” and then would not have any of the fallout of updating the first/last/display names – I’ll enter a DDTS on that for the DB folks and see if we can get the ball rolling on that.

Cisco Employee

Re: Bulk Import schema changes using CSV and AD

Just to follow up - the DDTS I entered for this particular issue is CSCed60399.

Community Member

Re: Bulk Import schema changes using CSV and AD

As follow-up to this thread, here's the solution my customer opted for....

OK... I withdraw the update to the telephoneNumber's just looking at it.. not updating it.

When it comes time to do the bulk import for all staff and faculty (2000+) I'll just use perl and LDAP to export the information needed for the CSV file and then parse 'telephoneNumber' into the 4 digit number that is supposed to be placed in DTMF_ACCESS_ID.

CreatePlease to create content