We received the following error. The symptom was that we could not reset any passwords either over the tui or the sa/aa. Everytime we restarted the dsad service, the error below appeared and of course also at the 2 minute synch interval. After examing the registry, under<br><br>HKEY_Local_Machine<br>Software<br>Active Voice<br>Directory Connectors<br>DirSynchAD<br>1.00<br>Domains<br>[domain name, i/e internal.forgedmetals.net]<br>DefaultDomainController:REG_SZ:servername.domainname.com<br><br>it was pointed at DC1 which is not a GC. I repointed it at DC2 which is a GC and wa la, synchronization worked and we could change passwords. Out of curiosity, I pointed it at DC3 which is NOT a GC and it still worked. I pointed it back at DC1 and it failed. All three servers are online.<br>Can you tell us for future reference and to solve these issues in the future how is the server name that this key points to originally set when Unity is installed. And is there something we do that updates it? What if the particular DC it is pointed to goes down or is removed?<br><br>AvDirSynch_MC<br>Event ID 1056<br>Skipping synchronization cycle due to error connecting to LDAP server. Ensure....<br><br><br>
The DCs under the DirSynchAD key do not need to be GC servers (only the one under DirSynchGlobalCatalog does), so I think the fact that DC1 is not a GC is a red herring (especially since it works fine connected to DC3). There is something going on that is preventing us from connecting to DC1. If it is still failing with that server, try firing up ADUC and connecting to DC1 and see if that works. If that works, but the AvDSAD doesn't, you can turn on DSAD diagnostics to see what kind of error code we're getting when we try to connect to DC1 (I beefed up the Event Log error for Coppola so that in future versions it will include the error code).
We pick the original DC with the Win32 call DsGetDcName, which is documented on MSDN. It basically tries to pick the best DC based on site (and maybe some other secret things).
We don't currently handle the case where the DC goes down--you'll just get lots of errors and you'll have to do it by hand. I know it seems a little lame, but it is a little trickier than just picking a new server, because whenever you change servers you also have to do a full resynch with the new server because USNs are only meaningful on a particular server. For really large sites, it might be undesirable to put this kind of load on the DC, the Unity server, and the network every time the DC gets bounced.
We are working on requirements now for how failures should be handled, though (in fact, I reviewed some of them yesterday), so it will show up in a future release.
In the meantime, you should change it in the Registry as you did. Also, you should force a full resync with DohPropTest after changing it in the Registry, to be sure the USNs in the database get updated for the new DC server.
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...
[toc:faq]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 discusse...