Skip to main content

SharePoint 2013 - Excel Services breaks after Windows Update

Synopsis

I'll go out on a limb here and say that updates and patching is no ones favorite thing to do.  But nonetheless it is a crucial piece of the puzzle in keeping applications/platforms/systems at an optimal level and more importantly - supported!

The scary reality of applying Windows Updates (not CUs or SPs) to servers hosting our SharePoint environment is that you are at the mercy of the changes that are about to be applied.  They frequently go without a hitch, and sometimes they DO NOT.  When that happens you typically spend countless hours scouring the event logs and ULS because those end-user error messages are just sooo helpful, like this one:

"We're sorry. We ran into a problem completing your request. Please try that again in a few minutes"

The Problem

A client of mine was performing some routine scheduled maintenance on their SharePoint 2013 farm, and by routine maintenance I mean installing queued up Windows Updates.  Smooth sailing, right?

Everything seemed to have gone as planned until the following morning, when help-desk was flooded with tickets stating that users were experiencing issues when attempting to access Excel files.  Excel services dashboards were failing, and users were getting the following when attempting to open any Excel files.

"We're sorry. We ran into a problem completing your request. Please try that again in a few minutes"

Turning to ULS logs for help we discovered these entries:

There was an error in communicating with Excel Calculation Services
http://{HostNamespace}/a1e544c38a544ad79a45e79f5e03c1b4/ExcelService*.asmx exception: The remote server returned an error: (503) Server Unavailable.

Unable to reach Excel Calculation Services
http://{HostNamespace}/a1e544c38a544ad79a45e79f5e03c1b4/ExcelService*.asmx

 Seeing as this happened relatively shortly after applying updates, that automatically became the 600 lb gorilla in the room.  However, we didn't automatically rule out other possible causes, so went ahead and checked the following for good measure:

  1. Ensure the Excel Calculation Service is started and running.
  2. Ensure the SharePoint Session State service is running.
  3. Make sure the App-Pool that Excel Service runs under is not stopped.
  4. Check that the App-Pool account running Excel Service in fact has sufficient rights to the existing content databases (SPDataAccess).
Well, it all seems fine on that front.  All of the above checked out as expected.

The Solution

Remembering the fact that Windows Updates tend to make modifications to the entries in the Windows Registry is very important.  On top of that, remember that WSS_WPG group is used on a machine-level to grant all App-Pool accounts necessary permissions.

Per Microsoft documentation, WSS_WPG group needs Read access to local resources, including the root of the SharePoint 2013 registry settings (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0).  For some wild reason, following the patches applied the night before, this wasn't the case any longer.  

Therefore, we went ahead and granted WSS_WPG group Read access to the location mentioned above, and made sure this was consistent with every machine in the SharePoint farm (excluding the DB servers of course).

TIP: In our scenario, the App-Pool account for Excel Services had also gone missing from the WSS_WPG group on a machine that was running the service.  This may not be the case for you but it is worth a sanity check.

Open up the command prompt and perform an iisreset /noforce on the affected machines.
Following these steps we made sure users could now open and manage the Excel files/workbooks and BI dashboards.

Comments

Post a Comment

Popular posts from this blog

SharePoint 2013 - Simple Glossary using "HTML Form Web Part"

Introduction At some point you probably thought about incorporating glossary functionality as a part of a larger solution, or perhaps you were simply looking for providing a more intuitive way of filtering hundreds of items within a List or Library. Now there are countless web parts out there that you can either purchase or download from the SharePoint Store free of charge, and they all come with their own set of bells and whistles.  However, if you are looking at building one yourself, well look no further. To accomplish this we will need three major ingredients: SharePoint Page (either Wiki or Publishing will work) SharePoint List/Library with some content (Files/Items) HTML Form Web Part Let's Implement In this post I’m using a simple Wiki page, but you can also use a Publishing page as well.  We just need a canvas to display our glossary. I presume you already have a list or library that contains some content which is applicable to this concept.  I’m
12 comments
Read more

SharePoint 2013 - Can't access the site externally in Internet Explorer ("Page cannot be displayed")

Synopsis Before we start talking about the problem let's understand the setup here.  We have a SharePoint 2013 intranet site that is also configured for access outside of the corporate network.  Employees use the same URL to visit the site both internally and externally via standard ports (80 and 443). Internal URL: http://sharepoint.domain.com Public URL: https://sharepoint.domain.com The site URL has been added to the Local Intranet zone in Internet Explorer for passing domain credentials. Alternate Access Mappings have been configured in such a way that if a user requests the site over HTTP they are automatically re-directed to HTTPS. Internal URL Zone Public URL for Zone https://sharepoint.domain.com Default https://sharepoint.domain.com http://sharepoint.domain.com Default https://sharepoint.domain.com Web application has been configured to use Kerberos protocol for authenticating incoming c
7 comments
Read more

Remove Orphaned Web Parts - MissingWebPart

At some point you may have encountered an error like this while browsing through the SharePoint Health Analyzer or if you are attempting to test your content database (i.e., Test-SPContentDatabase) prior to mounting it. Message reads something like this: One caveat is that the log message never reveals the Location of the culprit web part.  Luckily we can utilize T-SQL to query the content database and reveal the location of the web part in question.   Query the Content Database To do this fire up the SQL Server Management Studio either locally from your machine or while logged on to the SQL Server back-end of your SharePoint farm, open up the new Query window and enter the following statement: USE < Content_Database_Name > SELECT AllDocs.SiteId,WebId, Webs.Title as 'Web Title', ListId, DirName,LeafName  FROM AllDocs    inner join AllWebParts on Alldocs.Id = AllWebParts.tp_PageUrlID  inner join Webs on Alldocs.WebId = webs.Id  WHERE AllWebParts.tp
4 comments
Read more