Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Cisco Unity and Active Directory Integration with Cisco expert Adam Fuller. Adam is a Unity technology lead at the Technical Assistance Center (TAC) in RTP, North Carolina. He joined Cisco in 1998 as a coop and became a customer support engineer in 2000. Adam handles Unity escalations within TAC. He has a background in LAN switching, wireless, and all AVVID products. His certifications include the MCSE, CUSE, and CCNA. He graduated from the University of North Carolina at Chapel Hill with a degree in Journalism and concentrations in Philosophy, Religion, English, and Computer Science. Prior to joining Cisco, Adam was a UNIX System Administrator at UNC. Remember to use the rating system to let Adam know if you have received an adequate response.
Adam might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through February 13. Visit this forum often to view responses to your questions and the questions of other community members.
Hi Adam -
With transitive forest-to-forest root level trusts coming in Windows 2003, will Unity servers in these separate forests be able to communicate via Digital networking?
Thanks in advance!
Well, it looks like somebody was chomping at the bit to get started on this! On top of that, this first question is quite a doozy.
Let me start off by saying I haven't had any experience with Active Directory 2003 yet, and my exposure to Exchange 2003 has been limited. But I won't shy away from taking a couple of educated guesses:
1. Knowing what I know about the developers who put out Unity, this won't be supported right off, if at all. Extensive testing will need to be done first, and that may have to wait until after 4.0.4 is released in a couple of months. 4.0.4 will be the first release that will support being installed on Win2k3. The developers are going to want to take babysteps to make sure this first part works before we pull open the floodgates.
2. The basis of digital networking is active directory. Unity servers don't communicate directly, they watch for other unity location objects in AD. Then they take that location object and check active directory users in the global address list (GAL) for any associations to those location objects. This is how Unity servers can tell which users go with which servers. If the user belongs to a Unity server, all of his unity attributes can then be soaked up and stored in the GlobalSubscriber table in each Unity server.
The question now becomes: what information is passed over a forest trust in AD 2k3? Some cursory searching through Microsoft's site gave me this information:
"You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool. Common data types that need synchronization across forests include:
* GALs (Exchange)
* Public folders
* Directory objects
Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest."
This certainly looks promising! Will this be supported then? Not without a lot of testing that hasn't happened yet. If you do decide to try this, you're on your own for now.
Hi Adam -
Thank you for a very indepth reply, including the MS links! Sacramento County has at least two distinct Windows 2000 forests that I know of and I could envision the ability for Unity to recognize subscriber attributes between these forests in the future.
Many of my customers are asking when Unity will be able to be dynamically aware of Global Catalog servers across a domain, similar to how member workstations behave. As far as I know Unity currently can only point to a single Global Catalog server, causing issues if that server becomes unavailable. I thought I heard Unity 4.0(4) may support this.
Thanks for your time.
This is bug CSCdw14838. The bug hasn't been updated in a while, but it is indeed in the work queue for 4.0.4.
I would like to make a quick note about this, just so everybody knows why this might be a little tricky to implement:
The USN we use to check how up-to-date our information is compaired to Active Directory is domain-specific. If we need to switch global catalog servers, there's the potential we could end up pointing to one in another domain in the forest. At that point we'd have to do a complete resync to be sure we're not missing anything and to also get the new USN. I think the plan for this situation is to have the resync scheduled during a period of low activity (like during the early mornings). This means there may be lags in the replication of changes of objects between Unity and AD.
Mind you, the fix for CSCdw14838 isn't out yet (nor 4.0.4), so I'm speculating on how the developers are going to deal with that lag. There's a few other proposals about what to do about this resyncing that I'm not sure have been hashed out yet (since the bug hasn't been updated in a few months).
I'll jump in here because I helped on the design of the feature (CSCdw14838) and I'm doing the QA work on it.
Unity 4.0(4) will support dynamic reconnect of a new DC/GC should the current one that Unity is communicating with become unavailable. Reconnect will occur when a specified number of consecutive attempts to connect to a specific DC/GC has been met. As Adam said, the USNs are the biggest issue we have with doing this. Once a DC/GC reconnect occurs, a full re-sync between SQL and AD will need to occur as well. Until this full re-sync is complete no reads or write will be allowed in the SA. This is required to ensure database integrity. For this reason you wouldn't want Unity to reconnect just because you rebooted a DC/GC so by default a DC/GC will need to be down for 30 minutes before Unity starts to reconnect.
The feature will be highly customizable however most customers should never need to change it from the default settings as the defaults provide the highest possible level of availability.
There is another issue with the GC going down where messages aren't deleted. The DDTS is CSCea26846 and it too will be corrected in 4.0(4).
When Unity attempts to submit a message to Exchange via MAPI, it is required to authenticate and resolve the message recipient which requires it to access the GC. When Unity starts, it will place the name of a GC into its MAPI profile which it is forced to hold for the lifetime of the AvCsMgr process. If the GC goes down, MAPI will not automatically detect the GC going down, nor will it detect changes in the profile if the GC entry were to change. Because of this, Unity would have to be restarted so the MAPI profile will find a new GC.
To resolve this issue, Microsoft created hotfix 823719 which must be applied to the Unity server. This patch must be obtained directly from Microsoft. When a GC goes down with 823719 in place and Unity 4.0(4), the first call into MAPI which accesses the GC will undergo a referral. This involves MAPI asking the partner Exchange server for another GC in the list it maintains which can be viewed in the directory access tab in the Exchange Server manager, when the server properties are viewed. Note that if the GC is not in the list, it won't be eligible for referral. The referral can take anywhere between 30 seconds to a few minutes. During that time, the TUI port that the call is coming in on will hear dead air. If the patch is working right, calls coming in on other ports will hear 15 seconds of dead air and then fail safe during the referral. Event log messages will appear explaining a referral is in process and once the referral is completed, a message will be logged in the event log denoting success. At that point, subsequent calls will proceed.
It is important to note that Microsoft has coded this patch in such a way that the Unity Partner Exchange Server must be in the same Domain that alternate GC's are for the referral to work. This means that GC's in peer, child, or parent domains to the partner exchange server domain will not be referred to.
Hope this helps...
Sorry -- little type-o in here that makes a big difference.
There is another issue with the GC going down where messages aren't deleted.
There is another issue with the GC going down where messages aren't **DELIVERED**.
One of our are going to implement Unity UM (with failover) to integrate with Nortel PBX and MS Exchange 2000/AD 2000. Total number of uses = 3000 and a MCS7855 server is used. Since the customer currently have more than 30 message store on one Exchange server, just want to know if unity could support this config.?
Based on the design doc., an unity server could only support up to 5 Message store. Is this limit due to the fact that Exchange 2000 Enterprice is not used?
please advise if there is any workaround or doc.?
Wo is referring to "Voice Messaging Configuration 3" at this link:
This limit is based on the performance of the Unity system with multiple exchange mailstores. This isn't as big a limitation as it sounds like at first. Unity *currently* has an upper limit of supporting 7,500 subscribers. That limit will increase with subsequent releases. And the 3,000 users he has should be able to fit into just two or three mailstores on one server without any problems (as long as the box is beefy enough).
I recommend reading this whitepaper from Microsoft to understand capacity planning with Exchange 2000.
Also, Exchange 2000 Standard supports one mailstore and one public folder store. Exchange 2000 Enterprise supports four storage groups with five databases per storage group, making for a total limit of 20 mailstores on one box. To have 30 mailstores, he'd need to use two Exchange servers.
thanks for your info. Actually, our customer have two exchange 2000 enterprise server with 15 message store on each. In this case, what should we do if unity have a limit on support 5 message store per server?
Customer say that they will not change their environment for implement Unity!
Your customer doesn't necessarily need to change their Exchange environment for Unity. The limit pertains to the maximum number of mailstores Unity refers to for voice mail subscribers. They can have thirty mailstore databases spread across two Exchange servers as long as they understand that only five of those mailstores can house Unity voice mail subscribers.
This limitation of five mailstores for Unity subscribers isn't an arbitrary number. After 2 1/2 years of integrating with Exchange 2000, Cisco has learned a thing or two about our product, Exchange 2000, and that wonderous Microsoft protocol called MAPI. This limit of five mailstores was found to be the farthest to the right on the performance bell curve that the developers and QA folks felt comfortable supporting with this latest version of Unity.
I have Unity 2.4.6(161) and going to upgrade to 4.0(3) with Exchange 2003, what is the easiest way of doing it?
Assuming u are moving from 2.4.6(161)EX5.5 to 4.0(3)Exchange2003. And at the same time upgrading the Exchange from 5.5 to Exchange 2003.
If so, it is kind of a little tricky on the way we go about this.
Full Import/Export Tool would normally do the trick.
However, the tool supports only upto Unity 4.0(2) and that only supports Exchange 2000.
Recommend doing the following
- Perform the backup of 2.4.6
- Install 4.0(2) on a local box with exchange onbox
- Restore data from 2.4.6
- Upgrade to 4.0(3)
- Use latest DIRT to take the backup of the 4.0(3)
- Wipe clean the box and install Unity 4.0(3) with Exchange 2003 offbox
- Restore using DIRT
Be sure to also review the official documentation: