Installing Exchange 2010 SP1 Hub Transport keeps failing with an error "Service 'MSExchangeTransport' failed to reach status 'Running' on this server"

Log Name:      Application
Source:        MSExchange ADAccess
Date:          11/11/2011 9:34:07 AM
Event ID:      2604
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      localhost
Description:
Process MSEXCHANGEADTOPOLOGY (PID=2536). When updating security for a remote procedure call (RPC) access for the Microsoft Exchange Active Directory Topology service, Exchange could not retrieve the security descriptor for Exchange server object localhost - Error code=80040a01.
The Microsoft Exchange Active Directory Topology service will continue starting with limited permissions.

or 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.

Other Solution:

For the issue, we can troubleshoot via the following steps.

1.    we can run NLtest /dsgetsite to verify the subnet of the site

2.    Check if we have enable IPV6 on connected NIC and in registry

3.    Under manage audit and security logs, we need have Exchange servers security group

4.    We can run rsop.msc to verify which GPO is applied currently, ensure that “Exchange server security group” has been applied the GPO.

5.    We can force DC replication to ensure that all the DCs are in the same status.

Issues that may occur when the "Manage auditing and security log" permission is removed from the Exchange Enterprise Servers group in Exchange 2000 Server