MSSQLServerADHelper

[slc2]

Unity 3.13.

Is this service suppose to be running on the Unity server? It's set to manual and I am getting the following error even though it's running under the local system account:

The SQLSERVERAGENT service failed to start due to the following error:

The service did not start due to a logon failure.

[lindborg]

No, that service doesn't need to be running... it's not running on my 3.1(5) box right now and everything's flying along fine.

The SQLSERVERAGENT and MSSQLSERVER services are normally running under a domain account, not the local system account, at least on all my installs.

[slc2]

I am getting lots of the following errors:

Event Type: Warning

Event Source: AvDirSynch_MC

Event Category: Warning

Event ID: 1056

Date: 10/21/2002

Time: 8:13:53 AM

User: N/A

Computer: UNITY01

Description:

Skipping synchronization cycle due to error connecting to LDAP server. Ensure that the server is accessible, Exchange services are running on the server, and the monitor service account is configured correctly.

Is this related to the sqlserveragent?

[lindborg]

No, that doesn't have anything to do with SQL. The synchronization there is talking about synching with the direcotory (pulling in subscriber/location/DL infromation from AD in this case). If the DirSynch service can't attach to the directory it could be the account you have associated with the directory facing accounts (AvDSAD and AvDSGlobalCatalog if you're using AD with Ex2K - you didn't indicate your back end here) don't have proper rights to the directory.

[slc2]

Unity connected to E2K

The service account which is the account the two services mentioned is in the Enterprise Admin group.

[lindborg]

It could also be a problem with the global catalog server (or more to the point Unity's connection to it). Have you recently moved a domain controller or the global catalog server? Can you check to be sure your DC controller and the GC controller Unity is pointing at are up and flying right?

You can check which GC server Unity is looking at in the resgistry here:

HKLM\SOFTWARE\Active Voice\Directory Connectors\DirSynchGlobalCatalog\1.00\Directory\DefaultGlobalCatalogServer

You can check the DC server for the domain we're looking at here:

HKEY_LOCAL_MACHINE\SOFTWARE\Active Voice\Directory Connectors\DirSynchAD\1.00\Domains\\DefaultDomainController.

[slc2]

You are the man! The DC server Unity is looking for went off-line due to network problems. Can I change those settings or are there other settings that are sychronized? I have a DC sitting right next to the Unity server but, Unity is pointing to a DC on the other side of our WAN. Obviously, if it's pointing to a local DC it makes things work better.

[lindborg]

Yes, you can change them there in the registry... here's a tech tip with the details:

http://www.cisco.com/warp/customer/788/AVVID/domain_controller_global_server.html

[slc2]

Thanks. I will make the changes as soon as I can schedule an outage.

Sabas

[slc2]

If you haven't added this to your list of improvements, I would like to strongly recommend giving the ability to Unity find another DC and GC in the event the one it knows about is not available. In my case, there was a network problem, we lost a blade on the Cisco router that connected this DC to the network but, it's on the WAN. I have changed it to point to the DC and GC that sits next to Unity.

Thanks again for your help.

Sabas

[lindborg]

Yeah, already on the list of stuff to get into the product. It's a little trickier to change on the fly than it sounds but the messaging guys have this on their to-do list already.

[slc2]

At minimum, at least report by name the DC & GC that is not accessible. Unity already captures that in the registry. This save time so that we don't have to go looking in the registry.

[cvain]

Jeff, I've run into a similar issue during migrations from 5.5 to 2000 that caused a lot of problems.

For some reason the default GC server picked by Unity is in a different Site. Because of the replication delays all sorts of problems ensued with the creation of spurious accounts, possible by the syncher service.

I've yet to check the clients Site/Subnet configurations, but is this a known issue or can you think of reasons why this is happening.

Thanks,

Chris Vain