Active Directory Unity "key" data - Customer question

[srichardson]

My customer's Unity imported some Exchange 2000 users that did not have first names in their profile. These users cannot be accessed or deleted in Unity, nor can they be reimported. My understanding is that these should not have imported, however they did. I found the previous article about how to delete them in SQL and then go into Exchange raw mode to remove the Unity attributes, however it seems that this can only be done on a global basis. My customer asks the following:

"Can you direct me to the location in AD that the "key" data for Unity is stored? I have been talking to a MS engineer that will be able to write a utility to ferret out specific container data (and then we can delete it) rather than deleting the entire schema with all "keys"."

Please help, thank you, Stephanie

[oliviers]

"My customer's Unity imported some Exchange 2000 users that did not have first names in their profile"

What is exactly meant by "names in their profile"?

If they have imported existing AD users, the Unity data is actually on that AD user object.

"go into Exchange raw mode to remove the Unity attributes"

That's only applicable to Exchange55 systems. Can you clarify a bit on what happened and exactly what they are trying to do now?

For some extra information, here's a white paper on how Unity interacts with its particular connected directory...

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/whitpapr/datadir.htm

[srichardson]

Thanks for the white paper. I have forwarded that to the customer. You are correct about Exchange 5.5 raw mode. I was not making the correlation. Here is what happened:

After integrating Unity 4.0 with Call Manager 3.2 we attemted to use the Import Utility to bring over users from the Exchange 2000 cluster. Most worked fine, however two users were imported with no first names. When looking in the Exchange AD Users and Computers, the profile had no entry in the first name field. The alias and display names were populated. When you do a search for users in Unity, you could see the user, but it had a "-" in the first name field. When you clicked on the user, it would come back with an error. We were unable to delete or modify this record in Unity.

I did go into the SQL database and remove the user there, however, because the Unity attributes are still in AD, we cannot reimport them.

[srichardson]

Here is some info from the log when these users were initially imported:

******************* Completed Import of Subscribers **************************

******************* Starting Synker Operation ******************************

Started on February 16, 2003 at 00:21:04.

(Error)

Sync failed: rtannahill. Error: LDAP_INSUFFICIENT_RIGHTS

(Error)

Sync failed: LMorgan. Error: LDAP_INSUFFICIENT_RIGHTS

Objects that failed to sync: 2.

Completed on February 16, 2003 at 00:21:28.

******************* Completed Synker Operation **************************

Also, customer has another user that does not appear in the list of users to be imported when attempting to add a subscriber. The user does not already exist in unity and appears to have all the correct field in the AD profile. Any ideas?

[oliviers]

Looks like there might be a couple of things going on. For the users that were imported from AD that do not have first names, if it's OK for them to add the names in AD, they can do that. Unity will recognize that the name has changed (added really), and it should populate SQL correctly. At that point, they shoukld be able to normally operate that Unity user.

For the users that were missing the names, was it rtannahill and LMorgan?

For the other user that they are trying to import and cannot see, Unity needs to first have read access to that AD object itself. Secondly, that object must have an Exchange Mailbox (AD attribute Home-MDB must be set to something) and the schema-extended Unity AD attribute "ciscoEcsbuUMLocationObjectId" must not be set. Viewing these properties would require a directory editor/viewer utility like AdsiEdit.

[srichardson]

Thank you. Between you and TAC the trouble is solved. The two users objects in AD were not set to inherit permissions from the parent container (Users) and therefore the UnityDirSvc and Exchange Admin account did not have permissions to modify the object. We are not sure why these users were different, but they are corrected now. Thank you very much!