“Sorry, we couldn’t open ‘randomdoc.xls’ – Fix this Office Document Cache Error

So even though this turned out to actually be more of an Office problem, it is potentially something that a fellow SharePoint Administrator might have to deal with.

The Problem

Recently, one of my users started experiencing an error when he opened certain excel documents from his department’s SharePoint site.  After clicking on the document in SharePoint 2013, Excel 2013 would load and then display this error:

Sorry, we couldn’t open ‘https://sharepointsite.yourcompany.com/Shared Documents/filename.xls’.

The Solution

Turns out that his Microsoft Office Document cache was corrupted.  Simply deleting this folder fixed the problem:

%userprofile%\AppData\Local\Microsoft\Office\15.0\OfficeFileCache

Change the 15.0 to 14.0 if the user is using Office 2010.  More information on how to delete this folder is located here.

Another Problem Solved!

SharePoint 2013: Login failed for user 'DOMAIN\SERVER$'. Reason: Could not find a login matching the name provided

Our DBAs kept seeing error messages in their SQL Server log as follows: 

Login failed for user 'DOMAIN\SERVER$'. Reason: Could not find a login matching the name provided. [CLIENT: xx.255.222.22]
There was an entry for almost all of the SharePoint servers in the farm. It seemed to occur three times per day at the same times: 5:32am, 1:32pm, and 9:32pm.

I looked in the Event Viewer of one of the servers and located the error there too:

SQL database login for 'SPS_SharePointConfig' on instance 'SPSQLSERVER' failed. Additional error information from SQL Server is included below.
Login failed for user 'DOMAIN\SERVER$'.

Using the Correlation ID in the Event Viewer item , I searched through the ULS Logs.

 

 

I found several items in the SharePoint ULS logs:

SQL database login for 'SPS_SharePointConfig' on instance 'SPSQLSERVER' failed.
powershell (0x03AC) 0x1324 SharePoint Foundation Upgrade SPUpgradeSession ajxme ERROR CanUpgrade [SPConfigurationDatabase] failed.

Essentially, the timer job attempts to run an upgrade check using a PowerShell call. For some reason, the PowerShell call does not run as the timer job account but yet the local system account (hence the DOMAIN\SERVER$).

Those local accounts do not have permissions to run PowerShell commands against the SharePoint farm. Therefore one must allow access to these local accounts by adding them as "Shell Admins":

Get-SPDatabase | Add-SPShellAdmin -UserName DOMAIN\SERVER$

This allows the local system account to run shell commands against each SharePoint database.

Once I issued this for each server in the farm, there were no more SQL Server log entries! The DBAs were very happy!