Unity servers can be networked together and form a global directory which is further explained in the Networking guide (http://www.cisco.com/en/US/docs/voice_ip_comm/unity/8x/networking/guide/8xcunet010.html)
Potential Problems
If the digital network is not accurately represented on every Unity server in the environment, problems can and will eventually surface with tools that rely on digital networking such as the Global Subscriber Manager (GSM) and the License Pooling feature.
1. When Global Subscriber Manager (GSM) is used to move users you may not have any resulting servers to move users to, or it may show incorrect/old/inactive servers in the tool. This is because its reading the data straight from the GlobalLocation database table which is inaccurate as a result of data synchronized in from Active Directory.
2. When using the License Pooling feature between several Unity servers, user license counts may reflect incorrectly across servers. This can cause Unity to stop answering due to license violations and restrict other administrative tasks such as adding new users, etc. You will see “Corrupt license data excluded from pool” message in the Unity License Info Viewer tool under the Alerts.
| License Pooling Error |
|---|
Problem Details: Event Type: Warning |
Background
Each Unity server in the environment is assigned its own unique system ID upon installation. This can be found in SQL. The easiest way to find this system ID is from Unity Tools Depot>Diagnostic Tools>Data Link Explorer. Scroll down to the UnitySetupParameters table and find the @SystemId row. Here is an example of a Unity server’s system ID: 7588453f
During installation, the Unity server creates the corresponding “location object” out in Active Directory. This object contains crucial data that allows Unity to function properly. You can view this location object by launching the Active Directory Users and Computers snap-in>Click View>Advanced Features.
Clicking this option will expose the default Organizational Unit (OU) Unity>Locations, which contains all Unity server location objects (this location can be customized during installation by administrators so this can vary if you choose). Here you'll see that the System ID’s all have the word “default” prepended. In addition to Unity location objects, you'll also see delivery locations if you've got any configured (AMIS, VPIM, Bridge). The defaultXXXXXXXX objects represent all Unity servers that currently exist, or once existed in the environment, or even from past upgrades. The below screen shot shows a total of 3 Unity servers that exist with an AMIS delivery location configured named "AMIStest" which you can see belongs to the 2nd Unity server in that list since the System ID's match.
Now that this relationship between SQL and AD has been explained, each Unity server needs to keep track of all other Unity servers that exist in the environment. Each Unity server pulls in these location objects that exist in this OU and stores them in SQL in a table called “GlobalLocation”.
Solution
The most important thing to remember is that Unity’s GlobalLocation table should always accurately reflect the same amount of locations that exist in the Locations OU out in Active Directory. When there starts to become an issue with location object descrepancies (due to past failed installs, upgrades or other problems) other aspects of Unity’s functionality will break.
Here’s the process to clean up the locations in both Active Directory and SQL.
1. Visit the desktop of EACH Unity server in your environment and find its unique System ID using Data Link Explorer. Unity Tools Depot>Diagnostic Tools>Data Link Explorer. Scroll down to the UnitySetupParameters table and find the @SystemId value.
a. If you have a failover pair, the secondary server shares the same System ID as the primary server. When the failover configuration wizard was run to create the failover pair, it took care of this process.
2. Once you have these System ID’s of all Unity servers documented, launch the Active Directory Users and Computers snap-in>Click View>Advanced Features and navigate to the OU that contains your Unity locations (Unity>Locations by default).
3. Compare your System ID list with all of the defaultXXXXXXXX locations (where X= Unity’s SystemID)
**********CAUTION - READ BEFORE PROCEEDING**********
At this point, you've made sure all Unity servers are accounted for in the environment. If there are any unaccounted-for production Unity servers that you may not know about, deleting their location objects can break those servers’ functionality.
4. Delete from Active Directory any extra location objects that don't match up with your total Unity server list from Step 1. Once this is done, this change will need to replicate throughout all domain controllers so it may take a while before it’s fully replicated depending on the size of your environment.
5. At this point AD is now clean so Unity will no longer sync in these stale/incorrect locations anymore.
6. Now it’s time to clean up SQL on each Unity server
a. In Data Link Explorer within the GlobalLocation table, there is a checkbox “Undeletable”, the equivalent of value “1”.
b. This field cannot be modified in Data Link Explorer since this tool is Read Only. This field will need to be marked as a “0” in order to allow Unity to automatically purge these. This has to be done in SQL Enterprise Manager manually.
c. The column in the GlobalLocation table we're concerned with:
**********CAUTION - READ BEFORE PROCEEDING**********
These changes require modification of the SQL database directly and can result in permanent failure if not done properly.
d. Change the 1 to a 0 for whatever locations need to be automatically purged
e. If the locations don't eventually purge themselves after a couple synchronization cycles, the full rows of the bad locations need to be deleted from the GlobalLocation table manually. Just highlight the entire row and delete only once you've confirmed it’s the correct one(s):
Once both SQL and AD are cleaned up and location counts match, after a few synchronization cycles with Active Directory (Domain Controllers and Global Catalogs) the proper location objects will be updated and GSM will correct itself and license counts will re-align. The “Alerts” section of the License Viewer will empty and no longer contain stale location messages.
Feel free to comment, rate and ask questions if you have any!
