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?
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.
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 dont even think this is possible. Well slurp in the business phone field as a default into the primary extension field for a user being imported from AD but thats 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 theyre mistaken I reproed the same tests on my 4.0(4) pre release system and again dont 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 Thats how it is currently. That said, theyre right we shouldnt be updating the display name on the fly (again, this is a known bug noted above).
We dont 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 Ill enter a DDTS on that for the DB folks and see if we can get the ball rolling on that.
As follow-up to this thread, here's the solution my customer opted for....
OK... I withdraw the update to the telephoneNumber attribute...it'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.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.