Microsoft Exchange System Attendant Service Will Not Start

Spensley
Spensley used Ask the Experts™
on
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:-

Source: MSExchangeSA
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...

Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
AkhaterSolutions Architect

Commented:
is your exchange server a domain controller ?

how many domain controllers do you have ?

try running this

netdom resetpwd /s:server /ud:domain\User  /pd:*

where server is the name of one of your DCs

restart your exchange server afterwards

Author

Commented:
Nope - Exchange Server isn't a DC, it's got a machine all to itself.

There are two DC's on the network

Point of interest- following up on the Kerberos error thing, I ran an SPN listing query on both the primary DC and the Secondary DC for the secondary DC machine name (setspn -l SECONDARYDCNAME).

The secondary DC lists a fairly comprehensive list of SPNs for itself, but the same query on the primary DC for the SPN's of the secondary DC return a very short list.

The list of registered SPN's for the primary DC is comprehensive and identical on both DC's.

Which password is being reset by the netdom resetpwd command in your reply?
AkhaterSolutions Architect

Commented:
it is resetting the password of the exchange server
Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Commented:
Problem fixed - it was the missing SPN's for the secondary DC - they weren't registered on the Primary DC so I used ADSIEdit to register them manually and then manually kicked the Microsoft Exchange System Attendant Service into life.

It started without a single complaint.

I'll watch it over the next few days and see how it behaves.

Akhater: checked out the netdom command here: http://technet.microsoft.com/en-us/library/cc785478(WS.10).aspx and it loks like it would have reset the Machine password on the DC, not the Exchange Server? Is that right - as your last reply indicated that it would reset the password for the Exchange Server? I wasn't sure that the password was the problem as the Exchange Server was authenticating fine with the Primary DC.

Author

Commented:
How do I refund the points? I'm guessing that I can't give them to myself (smells like a system cheat!).
AkhaterSolutions Architect

Commented:
It would reset the password of the machine on which you are running the command so if you run it on exchange server it would reset it on the exchange server.

I thought your problem was exchange rather than a DC but well done, glad to know it is working again.

For the refund just click on the "request atttention" link and ask for the refund an Admin will take care of it

Author

Commented:
Thanks for your prompt responses Akhater - good to see that someone reads these posts!

Interesting about the netdom command - the Microsoft article doesn't really make it clear that it can reset the password for the machine account on the machine that it is run on - it just talks about it resetting the DC's password which isn't terribly helpful of it.

The SPN's must have failed to replicate back up to the Primary DC when the Secondary DC was added to the Domain. I hope that there isn't anything else that it missed in AD ... there might be some more icky problems to come.

I've fired of a Request For Attention to get the points refunded.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial