AvDirSynch_MC errors

[admin_2]

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>

[cgulley]

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.