SharePoint 2013 (and previous versions) shipped with Excel Services, allowing Excel workbooks to be viewed in the browser. SharePoint 2013 integrated with Office Web Apps (OWA), which also had the capability to show Excel workbooks in the browser. The complication in 2013 was that the two services had somewhat different functionality, resulting in some organizations having to use Excel Services to gain access to specific BI functionality. In SharePoint 2016, Excel on Office Online Server (OOS), formerly known as Office Web Apps (OWA), has been enhanced and now has the capability to work with Excel workbooks that utilize BI capabilities, such as data models.
Microsoft is now recommending that organizations move away from Excel Services and to use OOS instead. This has a couple impacts on clients:
- Smaller implementations, such as organizations using SharePoint as a platform for Project Server and that support a limited number of users, will now need a second server. Excel services was a service that ran on SharePoint, but OOS is a separate server product that cannot be installed on the same server as SharePoint.
- The list of requirements to support BI is still quite complicated, and will be challenging to communicate to clients. (perhaps a good infographic would help). For example, Excel files with Power View will require SSRS in SharePoint integrated mode to be viewable in the browser. Also, refreshing connections in Excel files with data models will require the PowerPivot add-in.
Microsoft Blog Post about this is here
(see the word doc that is linked in the first paragraph for details on deploying PowerPivot and Power View in 2016)
A good document that compares Excel Services and the Excel Web App from 2013 is here
One user was getting an error while trying to view the Resource Availability report in Project 2010, though the report worked fine for all other users. It turns out that the error message in the log file was one of the generic messages that didn’t mean too much: “operation timed out”. So, it wasn’t reporting any sort of permission issues, it was just reporting that the database wasn’t able to finish the queries in the default time of three minutes. So, one option is to go change the config file on the server and allow it to run for more than three minutes. But before doing that, there’s another possibility. On the Resource Availability report page, there’s a section that allows you to change the date range and the units from weeks to days or months:
When a change is made to the above, the server remembers that change and defaults it to that for the next time. So, if a user changes the dropdown to “days”, the next time they navigate to this page, “days” will already be selected. However, if the system can’t handle reporting on days within the allotted three minutes, then the error occurs. And, when the user navigates back to that page, it will default to days again, generating the error again, without giving any opportunity to change the selection back to weeks or months.
In light of the above, try the following:
- Navigate to the resource center
- Make sure that no users are selected
- Select one resource that does not have any tasks in the next couple months. Perhaps an old resource that shouldn’t be in the system?
- Click on “Resource availability”
If my guess above is correct, then the report will run fine, as there is no data for the user, and as such the timeout won’t be hit. If the report runs, then check the units drop-down. If it says “days”, change it back to weeks. Also, check the date range. If the range is large, make it smaller.
If the above doesn’t work, then the next step will be either troubleshooting the SQL server, or working with IT to get the config file modified to change the default timeout value to a higher number.