I have an Exchange 2007 Server (All Service Packs and CU's installed) running in a Windows Server 2008 (SP2) Domain.
It has been working fine for more than a year now, but today I found that the Microsoft Exchange System Attendant Service would not start after a reboot. This is the second reboot after installing the Update Rolup 2 for Exchange 2007 Service Pack 2. The first reboot was a complete hash - most of the Exchange Services failed to start and had to be kicked off manually.
Now, it's just the System Attendant Service (mad.exe) - after this reboot all others started successfully and no other errors were logged.
Manually starting the service does not work. the following Event is logged in the Application Event Log:-
Event ID: 1005
Message: Unexpected error Logon failure: unknown user name or bad password. Facility: Win32 ID no: 8007052e Microsoft Exchange System Attendant occurred.
I checked the Logon account used by the service and it is LOCAL SYSTEM. I changed this account to a DomainAdmin account and tried to start the service. Failed with the same error.
I changed it back to LOCAL SYSTEM and still the same error.
Checking the DNS configuration on the NIC on the Exchange Server shows no problems. Primary DC/DNS Server shows successful logon's for the Exchange Server machine account when the service attempts to start so it doesn't appear to be a DC communication issue. This is backed up by the fact that successful DC Discovery event are being logged by the Exchange Active Directory Provider - it is picking up the primary DC happily.
Running Procmon during an attempted manual start doesn't reveal any ACCESS DENIED events being fired.
A Wireshark capture while attempting a Service Start shows LDAP chatter between the Exchange Server and the Primary DC. Interesting point though is that it also shows a DNS Query being made to the Primary DC, asking for a Forward Lookup on the FQDN of the secondary DC machine, which the primary DC happily responds to with the correct IP.
The Exchange Server then Does a bit of Kerberos chatter with the Primary DC and gets a KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN response with regard to the ldap service on the seconday DC.
What's up with that? Could this be part of the problem or is this just a red herring to waste my time on?
Any ideas? ...please...