When trying to configure an Active Directory server in ServiceDesk, on the Edit Active Directory Server window when trying to click on the Next button, the error "The server is not operational" occurs. Or, the Active Directory sync no longer works.
The following error may appear in the ensemble2006 logs:
Error,Tuesday, October 26, 2010 1:02:00 AM,[unknown] Cannot connect to the server
[unknown] -- error.ToString() --
[unknown] System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
[unknown] at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
[unknown] at System.DirectoryServices.DirectoryEntry.Bind()
[unknown] at System.DirectoryServices.DirectoryEntry.get_AdsObject()
[unknown] at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
[unknown] at System.DirectoryServices.DirectorySearcher.FindOne()
[unknown] at LogicBase.Ensemble.Userman.ServiceCore.ADUtilities.GetDirectorySearcherForServer(ActiveDirectoryServer server, String _adAdminPassword, String container)
The AD server itself/the network (such as the DNS), the ServiceDesk AD Server entry, or its values, may be the cause.
Depending on the root cause, several issues can cause this behavior.
"AD Server in ServiceDesk" refers to the Admin menu > AD Servers > The AD Server that has been set up for your Active Directory "AD server" refers to the Active Directory server on the network
The "Sync Only Users" setting is enabled. This is known to result in sync issues. Disable this and reset server extensions to correct this. For more information, refer to the following knowledge base article:
The AD Elevated User Name in AD Server in ServiceDesk does not/no longer has sufficient rights to access Active Directory (AD) data. This can result in the error "The server is not operational" when clicking on the Next button while editing the AD Server in ServiceDesk. Edit the AD Server in ServiceDesk. Temporarily change the AD Elevated User Name to a domain administrator. Add the AD Elevated User Password, then click on the Next button, select the OUs to sync, then click on the Save button. Then perform a reset sync. If this resolves the issue, the previous user does not have necessary rights to access AD. Use this new user account instead, or try a different one that should work. Note: There is no list of what rights a user needs to have to be able to access AD data. Generally, this should be a domain user. Group policies and other restrictions, however, can result in this not working. This is why a domain administrator should be used as a test at the least, as they usually have less restrictions on what they can access on a network.
The AD Server in ServiceDesk has stopped working. There is no known cause of this, Symantec is looking into the issue. This can result in the error "The server is not operational" when clicking on the Next button while editing the AD Server in ServiceDesk, or, AD syncs no longer bring in users. Create a new AD Server in ServiceDesk and enter in the same information from the original, then click on the Next button, select the OUs to sync, then click on the Save button. Then perform a reset sync. If this resolves the issue, the previous AD Server in ServiceDesk has become corrupted or is otherwise not working. Use the new one instead. This may also be able to be resolved by adding the AD server's IP address to the ServiceDesk server's hosts file. (This may also resolve the second issue, above.)
On the ServiceDesk server, edit the hosts file which should be located in C:\WINDOWS\system32\drivers\etc.
At the bottom, add a new entry for the IP address of the AD server. For example, "126.96.36.199 symantec.com". Note: You may need to run a nslookup for the domain NETBIOS name or FQDN to be able to obtain the correct IP address first, especially if there is more than one AD server on the network.
Save the file.
Refresh the AD Server list in ServiceDesk. Under the Server Path column in Active Directory Servers, the IP address that was specified in the hosts file should now appear.
Perform a reset sync.
Also, manually syncing users may work. Go to the Admin menu > Users > AD Users. Verify if a user can be manually synced or not from here. If not, this may then be caused by the last issue, below.
The AD server has issues that are causing this. Review the Windows System Event log on the AD server for verification. For example, similar errors as the following may be seen in its logs:
"The session setup from the computer <computer_name> failed to authenticate. The name(s) of the account(s) referenced in the security database is <computer_name>. The following error occurred:Access is denied."
To resolve this issue, check the DNS and also contact your network administrator or to Microsoft for assistance with any issues found on the AD server.
Is Microsoft Distributed File System (DFS) in use? This has been seen to cause this in some instances. Edting the HOSTS file as above can resolve this.