Yesterday, I had a client call me. They had changed the password of the SharePoint 2007 service account. As I’m sure you can guess, doing so brought on the dreaded “Service Unavailable” message. Here’s what I did to get them back up and running…
Ensure new credentials are changed in IIS and Windows Services
The client understood that after changing the password in AD the app pools in IIS would also need to be updated. However, they did not change any of the windows services associated with that account. After those changes were made, I was confident that would fix the problem. But, it didn’t.
Dedicated WFE for Crawling
I then observed that the central admin and primary web application’s app pools were starting and immediately shutting down. The event log had numerous errors pertaining to the search service not being able to crawl the content database, but seemed to be unrelated. Out of curiosity, I decided to drill in on those errors to see where they’d lead.
I stumbled upon the following KB article that described similar symptoms…
As the article suggests, I looked at the hosts file on the server and sure enough found invalid IPv6 entries. After I removed those entries and saved them, the central admin app pool was able to start. However, if I were to restart the app pool, the hosts file would yet again update with the invalid entries.
With central admin running, I went into the search service and ensured that the setting “Use a dedicated web front end computer for crawling” was disabled. Once I saved this not only did the changes to the hosts file stop occurring, but the primary web application was then able to start.