Well, we’re off to a great start here at EKI.  What I mean by that is that I have plenty to do that keeps me very busy.  You may have noticed quite a few changes to this site, but I wanted to write about my first issue that I had to troubleshoot and resolve now that I’m all settled in here.

We’ve got an internal SharePoint 2010 Development server and today was my first time remoting into it to take a look around.  I was told that “it’s not being used for anything anymore.”  Knowing what I know, I was fairly suspicious of that statement.  I could write an entire separate post about the repurposing of servers and how that can go badly, but I’ll focus on the topic at hand for now.

The first thing that I noticed was that Central Administration would not come up at all, as shown in the screenshot below.

I opened IIS and saw the following:

No big deal.  I right-clicked the application pool and started it.  As soon as I tried to browse to Central Administration, I saw this again:

After refreshing IIS, I saw that the application pool was stopped again!  Trying this several more times of course yielded the same results.  Looking through the SharePoint logs indicated a problem with SQL, but everything on the SQL side was functioning properly (I know because we were using it for another dev app).  However, in looking through the IIS logs, I first came across this error:  “Application pool [applicationPoolName] has been disabled.  Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.”

You can see that’s the “Error” entry in the log.  My next step was to open the Services console (services.msc) and restart the Windows Process Activation Service (WAS).  Long story short, that didn’t fix the problem either.  Looking at one of the “Warnings” listed in the IIS log, I saw the following message:  “The identity of application pool [applicationPoolName] is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request.  If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number”.

This prompted me to talk to my AD friend and ask him to check on the service accounts for SharePoint to ensure that they were all still active.  It turns out that the password had expired for all of them.  Since this is a development-only box, my AD friend set the passwords on the SharePoint service accounts to never expire.  Once that was done, Central Administration and all of the other SharePoint sites (which were also down due to the same issue) came back up without a problem after I restarted their corresponding application pools.  Of course, if you’re running into the same issue, I can’t advise you to set your passwords to never expire; you should always follow the security guidelines within your organization.

I know I’m not the first to encounter this or write about it, but my search efforts did not yield any very helpful results and I wanted to get my documentation out here.  After all, I like to use this blog to document issues/tips/tricks as they happen so that I do have a solid point of reference going forward.  If you found this helpful, then it’s a win-win scenario.