Recently I had a client start using Excel Services on their SharePoint site. I was very confident that it would work since we had already expected this and had configured excel already.
The client went ahead and added excel web parts to pages, and they got a wonderful Microsoft error:
“The workbook cannot be opened”
What made this even more wonderful was the lack of correlation ID that we are so used to accompanying the errors.
After a bit of head scratching, I remembered permissions. We had forgotten to give the service account running the Excel Services access to the content databases for the appropriate web application.
So after a big face palm moment in the office, we run the following two lines of Powershell script, which is the very simple fix for this issue:
$web = Get-SPWebApplication –Identity <URL of the Web application>
$web.GrantAccessToProcessIdentity("<insert service account>")
All you need is the URL of the Web Application that the excel files live in, and the account that runs the Excel Services. Make sure you put the domain in as well e.g: “domain\account”.
Once this runs then you should just refresh the page and your excel files should show in the Excel Services Web Part.
Make sure you have configured the trusted locations as well.
If you are a SharePoint consultant in South Africa and you work at a Microsoft Partner then you more than likely have a GP team at the office, and will be asked at one point to help them with an upgrade to GP 2013.
One of the first catches is that GP 2013 doesn’t support SharePoint 2013, which you think is strange since it was released in 2013 and Microsoft surely develops their product stack correctly. Apparently Service Pack 1 will add SPS 2013 support but I will believe it when I see it.
This user site is setup on SharePoint and requires the BCS to be configured and running. At a client site we found that the BP install was failing with an “Access Denied in BCS” message. We checked all the usual suspects and came up short. Our next stop was checking to see if the BCS service could be managed. Turns out that we could not configure the metadata store in the BCS. Checking the services running on the server I noticed the ClaimsToWindowsToken wasn’t started, so started this up and we could now configure the metadata store in BCS, tried the install again and it went through.
While this sounds like a few simple steps to resolve it took us a bit of time and head scratching since the client had setup the SharePoint environment and had run the farm config wizard which should have started that service. So I just wanted to save someone a bit of time on this.