09-20-2002 12:31 PM - edited 03-12-2019 08:53 PM
When I attempt to forward a voicemail using Outlook, it works without a problem. When I dial-in to access the same voicemail through my IP Phone and then attempt to forward the message, I am prompted to enter the name of the subscriber to whom I wish to forward the message, last name first. No matter what name I type in, it tells me that user does not exist and to try a different spelling. What am I doing wrong? My user claims this worked just a few days ago. . .
09-23-2002 07:08 AM
Argh! It's another dirsync issue!
Voicemail forwarding is working fine from Outlook, but if you dial into Unity from your IP phone and try to do it that way, you can only forward to extensions associated with accounts still located in the old NT 4.0 domain. Accounts that have been migrated to the new W2K domain (and therefore affected by dirsync) are not available. SAWeb Admin. is normal for ALL accounts (yes, "list in phone directory" is checked).
I need to locate the CA that deals with this and I need to know what value is needed. I've already read the document "White Paper: Cisco Unity 3.x Data and the Directory (with Microsoft Exchange) and the answer isn't in there.
Please help!
09-23-2002 04:28 PM
I'm guessing the directory connectors (in this case specifically the global catalog monitor) is not picking those guys up as subscribers and adding them to the global subscriber table - but that's just a guess. You can verify this by opening the enterprise manager for SQL, drilling down to the UnityDB database and opening the "Global Subscriber" table and checking to see if the folks in the old NT 4.0 domain are getting picked up into this database or not... if they are, there's a totally different problem at play. If not, some property is not getting coming through.
Once we determine if that's the case or not, you'll want to open up ADSI edit and look at some specific properties (anything that starts with "ciscoESCBU...") and compare a user in the W2K domain vs. an NT 4.0 domain to get an idea of which property or properties are not making it through.
09-24-2002 04:44 AM
Don't understand your SQL reference. I looked all over my machine for an "Enterprise Manager for SQL" and there isn't one. This is a 2.46.135 box, we don't have SQL installed.
Am I missing something?
Thanks for the reply!
09-24-2002 09:50 AM
Sorry about that. We're so used to 3.X and SQL. So it sounds like you cannot address the subscriber in question with message forwarding. If you call into Unity and dial the DTMF Id of the subscriber, does it attempt to transfer to the subscriber, or does it also not recognize the subscriber's DTMF Id? Does the subscriber show up in the SA?
09-24-2002 11:16 AM
We figured it out. It's Custom Attribute 15. We compated a GAL .csv dump from 8/30 and looked for glaring differences. We noticed that CA 15 was wildly different, so we copied the old info. back in and the user immediately showed up in the auto-attendent when you tried to forward via phone.
What is worrisome now is that we aren't sure which raw properties Unity modifies/needs and which ones it doesn't. The documentation TAC directed us to: "White Paper: Cisco Unity 3.x Data and the Directory (with Microsoft Exchange)" doesn't mention CA 15, but apparently it *is* being used, maybe because we're using 2.46 and not 3.1.
Can anyone give me a *definitive* list of *all* raw properties (not just CAs) that Unity uses?
Thanks!
09-24-2002 02:25 PM
2.x uses considerably more space in the directory than 3.x does... most 3.x data is stored locally in SQL and only a small amount of information necessary to communicate with other Unity servers in the directory is pushed through into AD or Ex55. 2.x, on the other hand, stored everything directly in Exchange 5.5's directory - there was no separate database involved.
We don't have a published doc that maps all of them but since the Exchange 5.5 schema was not extensible (technically - could be done but you'd be sorry for doing it) for hidden objects such as call handlers and interview handlers etc... we just reused all the current visible properties for our own purposes. A call handler, for instance, is just a mail user with no display name (so it wont show up in the address book) that has Unity specific data tucked into properties such as business phone fields, company name etc
For subscribers we used custom attributes #12, 13, 14 and 15 (#11 was not used). These have a number of properties stuffed into each field (theyre compressed into a single string). There are also a series of 9 properties that start with VoiceMail that are used. Outside of that all other subscriber information is stored on their corresponding primary call handler which is stored as another mail user as noted above (i.e. no display name it shows up under the unity folder at the site level under the call handler branch).
Everything else is in straight visible fields you can see in the Exchange administrator if you are locking some of those down you may have a problem. I dont have a full list of the mappings of these fields for call handlers, interviewers, location objects etc that show up under the Unity folder however Id be very surprised if you guys were locking us out of those.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: