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.
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
Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
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?Anonymous
June 24, 2010
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.Anonymous
August 09, 2010
Thanks, i have find the good information for MSExchange ADAccess (DSAccess) errors.Anonymous
November 22, 2010
thanx. good information ds acseess errors .Anonymous
November 22, 2010
thanx. good information ds acceess errors .Anonymous
January 24, 2011
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!Anonymous
June 04, 2012
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 0Anonymous
August 13, 2012
The comment has been removedAnonymous
November 09, 2012
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.Anonymous
March 03, 2013
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 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?Anonymous
April 02, 2013
Thanks !! Saved my life.Anonymous
July 20, 2013
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?Anonymous
November 14, 2013
This fixed my issue, someone linked another GPO to the DC ou. Thanks for sharing.Anonymous
February 20, 2014
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.Anonymous
September 28, 2014
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"Anonymous
December 30, 2014
This fixed my issue. ThanksAnonymous
April 30, 2015
The comment has been removedAnonymous
May 07, 2015
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!Anonymous
June 01, 2015
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 articleAnonymous
February 17, 2016
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.