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:
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:
- Ensure the Excel Calculation Service is started and running.
- Ensure the SharePoint Session State service is running.
- Make sure the App-Pool that Excel Service runs under is not stopped.
- 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