Sharepoint Service Unavailable 503 Revisited

Post to Twitter Post to Facebook Post to StumbleUpon

Back in July I wrote a blog post on how to fix 503 errors in your Sharepoint web apps, like Companyweb in SBS. That post shows you how to resync the service account passwords for spfarm, spweb and spsearch so that Sharepoint can starting using them again. The symptom is two fold: You get a 503 and in IIS one or more of the sharepoint app pools is stopped.

It was always a mystery why those accounts stopped synchronizing. Small business server runs a script that is supposed to change the password and sync it with Sharepoint and sometimes that stops working. In the intervening months I’ve found some reasons for that.

These accounts are by default in the SBS Users OU. That OU has a password policy applied to it. If you set that password policy to a shorter than default time frame the password on the accounts will change and sharepoint will fall out of sync with those passwords. Since those accounts are always logged in you  might not see the problem anywhere else than in your event logs until you reboot the server. If the Sharepoint password sync runs before that occurs then you’ll be fine, if not your sharepoint web app will be unavailable. If conversely you’ve crippled your password security policy by modifying it so that passwords never expire you have an opposite problem with the same result. The script is unable to do it’s job and so eventually your sharepoint webapp fails too. I’m still trying to figure the why of this one out. I just know that it occurs.

I’ve run across another reason that the app pool aren’t able to start that doesn’t have to do with passwords. So if the password solution doesn’t work for you, it could be that local security account permissions have changed in the Default Domain Policy. This happened to one of my own server and for the life of me I can’t figured out how that occurred but this is IT and odd things occur every day. This Sharepoint TechNet forum post saved the day and make a potentially long day of troubleshooting a quick fix.

It points out that the farm accounts require logon a Batch right. On your domain controller this is found in the Default Domain Policy in the following location.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a batch job

Add that right to your farm accounts. Do a gpupdate /force afterwards and sharepoint will be happy again.

So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Third Tier Get Support BlogFeed Blog Twitter Twitter Facebook Facebook LinkedIn LinkedIN

Leave a comment

Your email address will not be published. Required fields are marked *

This blog is kept spam free by WP-SpamFree.