MSExchange ADAccess (DSAccess) errors and the “Manage auditing and security” right

(Edited 8/8/2011 to add additional error that might be found in the 2114 description.

This is something I’ve ended up having to resolve multiple times with customers, so I felt it would be good to get a post out about it.

In this case, the customer had an environment of Exchange 2003, 2007, and 2010. The Exchange 2007 and 2010 servers, with the exception of one Exchange 2007 mailbox server, were throwing errors such as these:

Event Type: Error
Event Source: MSExchange ADAccess
Event Category: Topology
Event ID: 2114
Description:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=4600). Topology discovery failed, error 0x80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, "Microsoft LDAP Error Codes." Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.

The above event may have the following error instead:
Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).

Event Type: Error
Event Source: MSExchange ADAccess
Event Category: General
Event ID: 2604
Description:
Process MSEXCHANGEADTOPOLOGY (PID=4600). When updating security for a remote procedure call (RPC) access for the Exchange Active Directory Topology service, Exchange could not retrieve the security descriptor for Exchange server object SERVER - Error code=80040a01.
The Exchange Active Directory Topology service will continue with limited permissions.

Event Type: Error
Event Source: MSExchange ADAccess
Event Category: General
Event ID: 2501
Description:
Process MSEXCHANGEADTOPOLOGY (PID=4600). The site monitor API was unable to verify the site name for this Exchange computer - Call=HrSearch Error code=80040a01. Make sure that Exchange server is correctly registered on the DNS server.

At this point, the next thing done was to look for a recent 2080 event and see what the Exchange server was seeing as far as domain controllers were concerned. The 2080 looked like this:

Event Type: Information
Event Source: MSExchange ADAccess
Event Category: Topology
Event ID: 2080

Description:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=2252). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc1.domain.COM CDG 1 7 7 1 0 0 1 7 1
dc2.domain.COM CDG 1 7 7 1 0 0 1 7 1
Out-of-site:
dc3.domain.COM CDG 1 7 7 1 0 0 1 7 1
dc4.domain.COM CDG 1 7 7 1 0 0 1 7 1

For well-versed Exchange folks, the problem in this 2080 is fairly obvious, the Exchange server is missing the SACL (Manage auditing and security log) right on the DC’s.

So, then the question was why is it missing, and this is what trips up many people, and is the reason I decided to write this.

Whenever I get one of these cases, the first thing I like to do is go to one of the Domain Controllers and run Resultant Set of Policy (RSOP.MSC). We then drill down to the User Rights Assignment, as seen below.

image

Here we can see the Manage auditing and security log right, can see what accounts are listed in the right, and what the Source GPO is that it is coming from. By default, the Exchange Servers (Exchange 2007 and 2010) group and Exchange Enterprise Servers (Exchange 2003) group are added to this right in the Default Domain Controllers Policy. This occurs during the setup process. For Exchange 2003, this is done during the setup /domainprep process, and for Exchange 2007 and 2010, this is done during setup /preparedomain.

So, what happens if the Default Domain Controllers Policy is not the policy that is applying this right to your domain controllers, as shown in the RSOP output. If this is the case, you need to make sure that the policy that is responsible for applying the right grants the Exchange Servers (or Exchange Enterprise Servers) group the right, or edit the Group Policy Links for you Domain Controllers OU so that the Default Domain Controllers Policy is applied.

In my latest customer’s case, we saw in RSOP that the Default Domain Policy was being applied instead of the Default Domain Controllers Policy. This was because the Default Domain Controllers Policy link had been removed from the OU and the Default Domain Policy was being applied instead. And in his Default Domain Policy, the Exchange Enterprise Servers (EES) group (Exchange 2003 group) had been granted the right. We also found that his one working Exchange 2007 server had been added to the Exchange Domain Servers group (again, Exchange 2003 group) which is then part of the EES group. The server membership in the Exchange 2003 group(s) is why the one Exchange 2007 server was still working but the other Exchange 2007 and 2010 servers were not. To fix this, we linked the Default Domain Controllers Policy to the Domain Controllers container, removed the link to the Default Domain Policy from the container, and then ran ‘gpupdate /force’ on the DC to apply the policy. Once we did this, all of the Exchange Servers now worked properly.