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

Popular posts from this blog

SharePoint Server Search - Error Starting

Problem I recently ran into this snag at a client site while setting up the Search Service Application.  I was able to create the service application without a problem however when I attempted to start the SharePoint Server Search service (Manage services on server page) I kept getting Error Starting . After taking a peak at the logs I found the following: An attempt to start/stop instance of service SharePoint Server Search on server did not succeed. Re-run the action via UI or command line on the specified server. Additional information is below. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) I double/triple checked the permissions and made sure that my Farm Administrator account was a member of WSS_WPG and WSS_ADMIN_WPG groups, and that those groups had full control permissions to the C:\Windows\Tasks and C:\Windows\Temp folders. Resolution I nearly lost hope when I remembered my old lost friend called STSADM.EXE. Just like in the old da...

SharePoint 2013 - Creating and Applying Composed Looks (PowerShell)

If you are a SharePoint administrator looking to quickly apply some basic branding to a site-collection in your SharePoint 2013 environment then you've come to the right spot. Before we begin I assume you have a basic understanding of what Composed Looks are, and perhaps you spent some time playing around with this concept in SharePoint 2013. If not, then don't worry.  Here is a basic primer: Composed Look is basically a package which contains elements used for controlling the overall look and feel of a SharePoint site.  This includes but not limited to Colors, Fonts, Background Image, CSS files, and Master Page files. Once created, Composed Look can be packaged by using the Design Manager feature, or we can use PowerShell to apply it across one or multiple site collections. NOTE: In this post we will be focusing on creating a composed look from an .spcolor file then using PowerShell to apply the design to a site-site collection of our choice.  We wil...

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 incom...