Unity Server Finds a "Friend"?

[adam.blomfield]

I work for a large organization with a far spread active directory forest (covers multiple divisions of multiple business units). We have been running on a Cisco CallManager / Unity phone system for about three years now, which is integration into Active Directory. Another unrelated business unit recently started migrating to a Cisco VOIP solution and somehow the two Unity servers managed to "find" each other. If I click on the Servers option in /saweb it shows both my server, and their server. Also it appears that the two servers have started synchronizing their D:\CommServer\Stream Files directories. My server now has OGM files for their users, and their server has the same files for my users. We really don't want our systems interacting with each other. Is this behaviour intentional, and is there any way to stop it? Neither server were ever explicitally made aware of the other. I guess they just found each other by AD lookups? Any suggestions?

My Server is running Cisco Unity 4.0 Build 4.0(3) SR 1

I'm not sure what version their end is running, except I know it is version 4.

[lindborg]

Yes, this behavior is automatic and deliberate. If you don't have Unity configured on either side to allow addressing lookups beyond the local box (or dialing domain) then the users on either box will not know of one andother and will not be able to address messages to each other and such.

You are not seeing outgoing messages (greetings) - only voice names (much, much smaller than OGMs) are replicated around the directory. Yes, Unity is looking in AD and will find objects stamped as Unity users/DLs/locations and will pull that information into the local system. This consists of subscriber, distribution list and location entries in the global tables and their voice names for those objects.

It's not a lot of overhead or space on the HD or in the DB - it's not doing any harm or exposing any functionality out of the box unless you configure Unity to expand it search scopes (which are not on by default).

You can find more details about the digital networking functionality on the docs page here if you want more info:

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html

[adam.blomfield]

Okay, I read through the link that you sent and understand a little better what is going on. This functionality is causing problems for us as we have dial plan overlaps, and the other site cannot add subscribers where the extension already exists on our server. Given the fact that there is no interaction between our businesses the synchronization gives us no benefit, so we would like to just turn it off and make the servers ignorant of each other, but I couldn't work out how to do that, if it is possible. Do you have any pointers, or workarounds for the duplicate extensions if it is not possible?

[lindborg]

First, extensions across multiple Unity servers do not have to be unique unless you've added both systems to the same dialing domain. I have several Unity servers on one AD setup and have overlapping numbers all over the place - so your description isn't quite adding up for me - something else is going on. We've never enforced numbering uniqueness out of the box across servers unless you explicitly set it to be in the same dialing domain which you'd have to go out of your way to do on the location objects page.

Second, no, you can't turn this off - it rides on AD replication so if they're in the same directory, they're going to find each other. But since there should be no harm in this (I believe you are missing something in your description because as stated it's not the case) this is normally not a problem. We have a lot of sites in your situation.

The only issue you may have is public distribution lists. If you've assigned IDs to them then they are global (i.e. you can't have "1234" on a public DL in side A and have an extension "1234" in site B). DLs are the only global objects in the system and normally we don't recommend having Ids on them in the first place - but if you do, you'll have to make sure they're unique.

For handlers (call handlers, interview handlers, name lookup handlers) the IDs are never replicated off the local box and can never conflict.

For subscribers IDs have to be unique on the local box and in the dialing domain. A dialing domain only ever spans more than one box if you tell it to.