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.

Comments (21)
  1. CJH, thanks for the comment/question.

    I've done a little digging into the source code to try and find the answers for you, and here is my best understanding given what I've found:

    The Enabled value is basically just if we will use that DC or not. It's pretty much based on the DC not being excluded and us being able to write to the DC.

    The PDC value appears to be skipped in 2007 and above, unless the minUserDC registry value (see article 298879 for info)  has been set, which is why it will normally show all zeros. I can't say I've ever seen a 2080 with all the DC's shown as PDC's, unless they're all from different domains in the forest.

  2. Raymond - Not sure why it would not have modified the Default DC policy, but it could have indeed been something permissions related during setup.

    Cindy - It sounds really weird, but it sounds more like somehow the DC policy is not properly getting applied to the DC's after reboot, or are you going to the group policy and finding Exchange Servers group has been removed? There should be no way that the Exchange Servers group just gets removed from the group policy; I would expect it to be more possible that somehow the policy didn't get applied, but that's still very weird.

    When you run RSOP.msc on a DC when the problem occurs, does it show the correct policy was applied to the DC? Then when you go check that policy, is Exchange Servers group now missing from the policy? You're not manually adding the Exchange Servers group to the right in the DC's local policy are you?

  3. chaselton says:

    One confusing element in this is the 2080 event...because all of the events that reference event 2080 don't mention what the "Enabled" column means.  Or why none or all of the domain controllers show up as PDC emulators.

  4. lynn smith says:

    Thanks, i have find the good information for MSExchange ADAccess (DSAccess) errors.

  5. Ersal OZ says:

    thanx. good information ds acseess errors .

  6. Ersal OZ says:

    thanx. good information ds acceess errors .

  7. Mital Shah says:

    Thanks for this post - very useful! After migration to Exchange 2010, I demoted the Exchange 2003 server from its DC Role. The server failed to boot to logon screen - it hangs at "Applying Computer Settings" for hours. I forced it off, booted to Safe Mode, and saw the above errors in the Event Log - which were preventing the server from booting up. In Safe Mode, set all Exchange services to Manual from Automatic, reboot, and the server boots up fine. Once logged in, you still cannot start any Exchange services due to above errors in Event Log.

    Once I added Exchange Enterprise Servers to the "Manage auditing and security log" in the Domain Controllers Group Policy, my Exchange services managed to start fine.

    Thank you again!

  8. Ron Jack says:

    If one DC had errors with the SACL would this cause event ID’s 2114, 2103, 2604, 2102, 1005?

    PODS1.ctrak.local CDG 1 7 7 1 0 1 1 7 1

    PODS2.ctrak.local CDG 1 7 7 1 0 1 1 7 1

    PODS3.ctrak.local CDG 1 7 7 1 0 1 1 7 1

    PODS4.ctrak.local CDG 1 0 0 1 0 0 0 0 0

  9. Raymond says:

    Thank you Richard. This is helpful.

    I faced the same issue and i added the Exchange Server account to the "Domain Admins" group to successfully install Exchange.

    In my environment I had a customized GPO that take precedence on the Default Domain Controller GPO. So on the Domain Controllers OU, I have 2 GPO: Default Domain Controller (with priority 2) and Customized Domain Controller (with priority 1).

    From what i understand, during the setup process, the "Exchange Servers" group is granted right to "Manage auditing and security log" policy in the Default Domain Controller GPO. However in my case i noticed that the Default Domain Controller policy was not modified.

    I think the issue was coming from there but can you please help me understand why the setup did not modify the Default Domain Controller policy?

    Thank you in advance

  10. Cindy says:

    We face an odd issue, Exchange server is missing the SACL (Manage auditing and security log) right on the DC’s every time we apply Windows Updates to our domain controllers.  We run setup /preparedomain again to place the Exchange Servers Group back in "manage auditing and security log".  Has anyone else experienced this issue?  Our Exchange 2010 was a migration from Exchange 2003, same with AD from Server 2003 to 2010.  

  11. Cindy says:

    We would get a string of events on the mail servers application logs, zeros in SACL right field in event 2080 would be the first, a variety of other events would be logged and then the Exchange databases would dismount.  Going to group policy, default domain controllers we could see Exchange Servers group had been removed from manage auditing and security log.  

    we seemed to have found the cause, it was one of our DCs, in Group Policies Event Log it showed an error on the offending DC, event ID 7016 with error code of 1252.  Rather than try to fix it we just demoted that DC and removed it from the domain.  Then everything was fine, we could apply updates & reboot the DCs with no problem.  

    For a few months no issues.  Until a transformer blew and we had to power down our entire server farm.  Now every few hours our default domain controller policy seems to reset and Exchange Servers group is again removed from the default domain controllers policy, manage auditing and security log.  The difference now is it gets removed and no reboot is involved.  I found an article that sound like what is happening to us now http://www.ballblog.net/.../exchange-servers-need-manage-auditing.html

    But I can't find the root cause, going to try changing the security event logging as the article suggests in attempt to determine if something is causing a reset of security.inf

    But I'm not so sure our original removal of problem DC was the complete cause of our issues, maybe during the migration fragments of something got left behind and keeps coming back...Ideas anyone?    

  12. Kjell Blomberg says:

    Thanks !!

    Saved my life.

  13. Vishal says:

    In my case, Additional DC does not exist it was demoted long ago. & the system does not exist in the Active directory domain controller container. But still getting warning event that the server does not exist what to do?

  14. PeanutButter Administrator says:

    This fixed my issue, someone linked another GPO to the DC ou.  Thanks for sharing.

  15. JHK says:

    We had this error in our Exchange 2013 environment and it turned out to be tangentially related, but it was different. Our sysvol directory was not properly replicating and that was causing issues with some domain controllers but not all. Correcting the
    replication issue forced the updated policy object to all DCs and corrected the errors we were seeing.

  16. Nawaz says:

    I faced the same issue in Exchange 2013 and solution was "the computer object of the exchange server was not added in Exchange server group in AD"

  17. Christian - Italy says:

    This fixed my issue. Thanks

  18. BJK says:

    Exchange 2003 running on Server 2003 R2 std. Exchange services started fine, but a few days after log in, would get an error stating Invalid endpoint format trying to log in. Restart solved for a few days, then problem recurred.

    Many errors in the application log, mainly MSExchange ADAccess errors ...

    OP article helped to point me in the right direction. Checked everything as stated and all was correct.

    Also ran POLICYTEST.EXE on exchange server and both DC's appeared as SeSecurityPrivilege correctly assigned

    I our case, it was the result of a corrupt GPO History in the registry on the exchange server.

    There were additional recurring event log errors # 8194 and 1085

    Deleted contents of folder %ALLUSERSPROFILE%Application DataMicrosoftGroup PolicyHistory

    Then deleted content of these registry hives:

    HKLMSOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory

    HKCUSOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory

    Then ran gpupdate /force on exchange.

    ...and BOOM!

  19. antfoo says:

    We had this issue too. It was cause by a couple of problems...

    1. The Default Domain Controllers Policy was not enabled. So this prevented SACL rights to be populated into the Local Security Policy or our Exchange servers. We had to manually add in the servers to the policy on the domain controllers (DC1, DC2, old_DC1)

    To manually add the servers to the policy:
    Start > Administrative Tools > Local Security Policy > Security Settings > Local Policies > User Rights Assignment > Manage auditing and security log... Add "Exchange Servers"
    Run "gpupdate /force" after these settings have been applied and check Event ID 2080 to see if the SACL rights have been applied to your domain controller

    The above issue should have resolved SACL rights issues but for our situation there was something strange... whoever installed our Exchange servers hardcoded the old domain controller (about to be decommissioned). We had to remove this setting...

    2. regedit > HKLM > System > services > MSExchange ADAccess... There should only be Diagnostics, Instance0, and Performance listed here. We had a "Profile" key folder which had the old domain controller in it. We removed it and the SACL rights permissions started
    to populate to the domain controllers.

    ....and BOOM!

  20. SysAdmN says:

    My exchange 2010 had some problems comunicating with my 2003 DC.
    Went to the 2003 DC, just had to run gpupdate and "Manage auditing and security log" updated to the correct values. Didn't try to restart the servers yet, but everything is working now. Thank you for writing this article

  21. Scott says:

    Thanks for the information and associated links. This saved the day when an Exchange update trashed 2016 removing the association between the Exchange server group.

Comments are closed.

Skip to main content