I have SharePoint 2010 installed locally on my laptop where I do my development. I don’t develop for SharePoint all the time so there are gaps between when I might be looking at my local SharePoint. Getting back to SharePoint development I attempted to deploy my new solution from Visual Studio for testing.

Complete failure! VS could not find the expected instance of SharePoint to deploy the solution.!

Is SharePoint still there? I tried browsing to my local SharePoint instance. Of course,  there was a problem: the dreaded HTTP Error 503, Service Unavailable. Visual Studio wasn’t lying! 🙂

I got the same Service Unavailable error when I tried to open the Central Adminstration site.

Ok, what about IIS.

Checking the Application Pools I see that the ones for SharePoint and Central Administration were stopped. I restarted them and tried opening SharePoint again. Unfortunately the Application Pools stopped as soon as I tried to access the SP site. Since I was also having issues with SQL Server I thought that perhaps the issues were related. They weren’t, but it was a distraction.

In my SharePoint testing and production environments I follow the Microsoft recommended best practice of using domain accounts that aren’t user accounts for application pool identities and managed accounts. Once in place you really don’t think about these accounts in SharePoint, at least I haven’t.

So in my local instance of SharePoint I was using my own domain account as the “Identity” for the Application pools.

Application Pool Advanced Settings

This had been working just fine so I never went back to change it. Well, moving forward a couple months my password changed. Seasoned (and maybe not so seasoned) SP Developers will see the problem: Identity account passwords are not synchronized to the domain account. So, when the password is changed for the domain account, as it did in my case, the password entered for the Application Pool Identity remains the same. The result was that the credentials for these pool identities were no longer valid!

Had I not been having an issue with the underlying SQL Server I might have discoverd the cause sooner. And, of course, reviewing the System Log would have revealed that all the services related to the application pools were failing because of a logon failure.

Lesson Learned: Departure from best practices can lead to problems as this issue reminded me!