Amy blogs about an issue I’ve seen a couple of times with SharePoint — a “503” error.

So here’s the setup… I’ve seen two issues with SharePoint – the first has to do with Patching.  As you should know by now when you install updates on SharePoint they don’t automatically run the psconfig command anymore.  The reason is that SharePoint 2010 products as a rule do not do this as they expect their SharePoint admins to manually run that command.  That’s why I’m not convinced that I want to ask the SBS team to ask for an automatic routine that runs that command.  We already know how many times that didn’t work for prior versions of SharePoint.  So I’m not sure I want the risk of running that command.  So make sure after all SharePoint updates and after Service Pack 1 that you run the psconfig command.

Now for the other issue that I’m seeing in SOME not all SBS.  Behind the scenes in SharePoint is a routine that kicks password changes in SharePoint for the managed accounts like spfarm.  There have been times that I’ve seen someone report that they are seeing an error 503 when they open up SharePoint and the issue was not caused by patching, in fact they couldn’t figure out exactly why it happened.  If they reset the passwords, then SharePoint works.  So something is happening with the routine that syncs up the password changes.

But it’s the why that we need to get to the bottom of.

So here’s my ask of you.  And keep in mind there are two separate issues.  One is the lack of people psconfig-ing after SharePoint sp1.  Already documented, already blogged.

The other is the “503” Error.  If you suddenly see a SharePoint in this condition, ping me at as I’ll need to see if the resolution Amy posted works for you (it should) and then to get log files from you to investigate why.  Not everyone will hit this.  There’s a specific fact pattern/trigger of cause.

As in any investigation to prove without a doubt, additional data points are needed.


Comments are closed.