I have a customer with a large Unified Unity configuration, in which there are around 5 sites with multiple Unity clusters. A general site would consist of two or three "pairs" of Unity servers running in failover mode. These servers are all within the same dialing domain and replicate amongst each other. All are running 4.0.5 and are completely stable in their configurations. They are working with a large group of AD/Exchange backend servers, and the user database is probably the most dynamic thing in this network.
The problem they are experiencing, which, not being an SQL guru I can not start to resolve is, sometimes when a user is deleted from the AD system, the Unity server that holds the information of that user gets updated that the user has been removed from the system, and updates it's database with that information. At a later time (can be days or weeks), if a search for the user is completed on other servers within the dialing domain, other servers still show the user active on the unity server the user was originally homed to. A search on the original server shows the user has been removed.
Going through the other Unity servers SQL DB, I can still find the user account within the Global Subscriber database, pointing to the original home server. If I delete the SQL entry in each of the databases' and perform a replicate changes action from the Unity configuration page on all servers within the dialing domain, the user account is then gone from all Unity servers.
Where this problem is truly causing a problem is that if a message store resync is performed on one of the other Unity servers, Unity will re-add the deleted accounts back into AD using the Unityinstall account which runs the message resync.
This has the AD/security team up in arms against Unity as user creation should come from AD to Unity, but since the Unityinstall account has Domain privledge, it can create users. The only time Unity should create users in this network, is when a new server comes on line and needs new Unity_<servername> users.
So in a nutshell, I am wondering if anyone can help me to track down the replication issue. I am not sure how to track or troubleshoot an SQL replication issue. Any advice would be greatly appreciated.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...