Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Installing 2 Unity servers into 1 Exchange Site

Here is my question:<br>We have a customer that has an Exchange site that services 2 locations through one exchange server. There is an ICS-7750 at the location where the Exchange server is located as well as a Unity 2.4.5 server. We are in the process of installing a Call Manager system at the second location, and we have been asked to locate another Unity server at this location. This means that they will coexist in the same Exchange site. Is this supported? I would think that both servers would identify the subscribers in the DS and contend for ownership and the networking feature is only for different exchange sites and orgs.<br><br>Any thoughts?<br><br>Matt Slaga <img src="/images/icons/wink.gif"><br>Dimension Data US<br><font color=red>MCNE</font color=red>, <font color=blue>MCSE2k</font color=blue>, <font color=purple>CCNP/DA</font color=purple>


Re: Installing 2 Unity servers into 1 Exchange Site

Yes, this is supported since 2.4.0 build 120... it was a feature tagged as MUSLIES (Multiple Unitys Separate Locations Identical Exchange Sites)... hey, it was late, I needed an acronym... I'm not proud of it.

The short story is each Unity server installed in the Exchange site is in it’s own “location”. This is what install is doing when it asks you to “join an existing location” vs. “create a new location”. You ALWAYS want to create a new location unless you’re doing a “simple fail over” scenario, which is reasonably rare.

Each Unity location tags all objects (including subscribers in the mail store) with a unique “system ID” that identifies that user as belonging to that particular Unity server. This way multiple servers in the same site don’t step over each other’s objects in the directory.

Networking will fly OK as long as the total number of users in the GAL is sufficiently small… lookups have to pop up to the GAL since we can’t know if the remote Unity user you’re looking for is in the local site or another site in the organization so we have to fall on the side of caution. These lookups can be rather slow since Exchange’s directory is slow, there’ll be many more objects at the organization level than at the site and we don’t cache the objects in the GAL to memory as we do objects in the site. All in all, proceed with caution on the networking option.

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems (new page for Unity support tools and scripts)

jns Cisco Employee
Cisco Employee

Re: Installing 2 Unity servers into 1 Exchange Site

We will be creating a new Unity location in our current site. Our GAL has about 2000 entries, about 1500 Unity Subscribers. What type of lookup response should we expect?

I think we would be interested in using the Global addressing scheme so we can minimize steps for callers. How do we enable it?

When creating a new Unity object in a site that already has a Unity location is there a new Exchange Unity folder created? or are the new location objects stored in the existing Exchange Unity folder?

Instead of creating a new site, maybe joining the existing location sounds appealing inorder to have a simple failover. Any discussion on how this works and what we would have to do further to support it?

I havent seen any other threads on the topic of Installing 2 Unity servers in the same Exchange site. Is there any other issues that we need to be aware of? Any white paper that discusses it further?



Re: Installing 2 Unity servers into 1 Exchange Site

The lookup response for global messaging isn’t based on just the number of users in your site, it’s actually affected by the number of users in your GAL, which is many times a problem and is why very few folks use it. When we go to search for a user that someone wants to address a message to, we have no way of knowing if that Unity server is installed into the same site or a different site so we have to pop up to the GAL and search everything. This is a double-whammy since, obviously, there’s a lot more objects at the GAL level and we also don’t maintain a cache of items at the GAL level as we do at the site level. If you have more than, say, 2500 objects in your GAL, I’d be cautious. Yes, we have a better scheme in place using SQL to handle essentially caching the entire GAL (or GC for you AD folks) locally to do very speedy lookups across very large directories, but for 2.4.x that’s not the case.

That said, you can certainly try it out and if it doesn’t work smoothly enough for you, you can go back to local plus locations addressing. To change the addressing mode from the default of local plus locations to global, you need to edit the registry. Go to HKLM\Software\Active Voice\Conversations\1.0\Address Searcher\ and go to the “Sub Network Addressing Mode” key and change it to “2” (the default is 1… remember that if you need to change it back). After you restart Unity you should be in global addressing mode.

No, when adding a 2nd or 3rd etc… Unity server to the same Exchange site, we don’t create a new Unity folder, the objects for each Unity server are all put in the one folder at the site level. We keep the objects separate by stamping all objects (subscribers, call handlers, COS objects, etc…) with a “system ID” value that’s unique to each Unity server. This way when the SA fires up on a Unity server it’ll only show you objects associated with it and not all other users/handlers etc… in the site. There’s no white paper on this, it’s a pretty straight forward object identification scheme we’ve employed. If you want a white paper on the networking plan in general moving forward into 3.0, I’d be happy to pass it on to you.

Simple failover is a special case and is not what you want here (unless you want to install 4 Unity servers). The failover box is essentially a mirror of the primary and is only used when the primary goes off line. So if you need to install two Unity servers today and you wanted simple fail over services, each of those will need a backup Unity server installed. That’s the only reason for joining an existing site with the existing version of Unity.

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems (new page for Unity support tools and scripts)

CreatePlease to create content