Today I updated a SharePoint Server 2010 test virtual machine with service pack 1 (SP1; Foundation and Server) and the August 2011 cumulative updates for SharePoint Foundation and SharePoint Server. I ran the SharePoint configuration wizard after installing all the updates.
When I rebooted the server (suggested when encountering the User Profile sync problem after applying the patches) and tried to open one of the team sites, I received a 503 Service Unavailable error (as shown in the picture below).
Service Unavailable – HTTP Error 503. The service is unavailable.
Once I got over the “what did I do??!?” moment, I of course recognized this as an IIS error, not a SharePoint error. I opened the Internet Information Services (IIS) Manager MMC and noticed that none of the SharePoint Application Pools were running. After starting all the needed Application Pools, everything is back to normal.
After applying a new master page and related theme components, we have been receiving reports that users were being presented with 403 ‘forbidden’ errors when trying to load our intranet site. After refreshing the screen four (4) times, the page would finally load.
I checked the web server’s Application log and found that every time a user received a 403 error, there was an “Information” Web Event message logged with a source of ASP.NET and an ID of ID 1314. The body of the event included, among other information:
Event code: 4011
Event message: An unhandled access exception has occurred.
After doing research and knowing this was most likely a security issue, I came around to fixing permissions on the Bin and _app_bin folders for the IIS virtual server that was hosting my SharePoint Web Application. I added the server’s local group “users” (which includes the domain group users) to both folders with READ permissions.
After an application pool restart, there have been no more reports of 403 errors and not a single 1314 report has been shown in the Application log.
I recently needed to add an account to an IIS6 Application Pool, but I did not know the password. No one else knew the password either.
However, I found out that the account was being used by an IIS6 application pool on another Windows Server 2003 machine. So I loaded the IIS 6.0 Resource Kit Tools, which includes the lovely tool “Metabase Explorer”.
After I launched the Metabase Explorer application, I navigated my way to the application pool that was using the password I needed to obtain. Select the option to “View Secure Data” and bingo! there is the password.
Download the IIS 6.0 Resource Kit HERE