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.  http://www.thirdtier.net/2011/07/when-sharepoint-companyweb-503s-on-you-heres-how-to-fix-it/

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. 

http://social.technet.microsoft.com/forums/en-US/sharepointadminprevious/thread/c396d86b-8c5b-4c01-86eb-6ff64319ef4f

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.
Get Support Blog Twitter Facebook LinkedIN

At first it seems like a mystery. One minute Sharepoint is working fine and the next it’s not. You didn’t even do anything! It’s true you don’t have to do anything to have this problem occur. The only thing that has to happen is that the password for the Sharepoint service accounts expire or otherwise become out of sync with the Sharepoint database.

Things not to do:

• DO NOT reset the password for the Sharepoint service accounts
• DO NOT change the password for the sharepoint services logon account
• DO NOT change the account that the app pool runs as

All of these things will waste you time and just complicate things.

the example I am about the give occurred on an SBS 2011 server but the procedure will apply equally to any Sharepoint Foundation 2010. The only change to the procedure that you will need to make is database name and sharepoint service account names.

In this post I am standing on the  shoulders of Adam Zou and Shawn Song, of Microsoft partner support who helped walk me through the process. There is a case record here: http://social.microsoft.com/Forums/en-US/partnerofficesharepoint/thread/dec8834c-876b-4b22-9f0d-dc213a0f0fac/

Here’s is what you should do:

1. In SBS 2011, the problem stems from an expired password on the account named spfarm. You might have trouble finding this account in your active directory. It is located in Active Directory Users and Computers, under My Business OU – Users – SBSUsers and is called Sharepoint Farm Account. This password has expired and you need to reset it. Reset it to a complex password that you’ll remember.
2. Next open Services.msc and sort by the Logon As column. Change the password to the one you just set for each service that logs on with that account.
3. Open the Sharepoint 2010 Management Shell. This is Sharepoint’s powershell console. Enter the the following: Set-SPManagedAccount -UseExistingPassword -Identity domain\spwebapp  Being sure to put in your domain name where the command string calls for domain. For good measure, I did ran this command for spfarm, spwebapp and spsearch.
4. Still in the shell, run this command: Repair-SPManagedAccountDeployment
5. Open an elevated command prompt and run IISreset /noforce
6. At this point you may want to see if everything is running, it may be and you might be done. Be sure to check your sharepoint website and the central admin site.

If any of the powershell commands gave you an error about permissions (which you’ll get if you’ve restore your server or your databases) then do this:

1. Launch an elevated SQL Management Studio 2010 and look for databases labeled as Suspect.
2. For each database labeled as suspect run the following SQL commands, replacing dbname with the full name of the suspect database:

ALTER DATABASE dbname SET EMERGENCY

GO

ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

DBCC CHECKDB( Dbname, REPAIR_ALLOW_DATA_LOSS)

GO

ALTER DATABASE dbname SET MULTI_USER WITH ROLLBACK IMMEDIATE

GO

ALTER DATABASE dbname SET ONLINE

GO

Immediately following these commands you should see your databases come out of suspect status and sharepoint should now be working fully.

__________

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 like you.

www.thirdtier.net/support