Skip to content

Tag: SQL Server Reporting Services

Business Intelligence in SharePoint 2019

The recent availability of the SharePoint 2019 public preview, and the supporting information that accompanies it has clarified the status of Business Intelligence features in SharePoint 2019. This release, with one exception, is the culmination of the process of decoupling BI from SharePoint which began in SharePoint 2016 through the removal of Excel Services. This decoupling strategy was initially articulated in the fall of 2015 with the document Microsoft Business Intelligence – our reporting roadmap which stated that SQL Server Reporting Services was to be the cornerstone of their on-premises BI investment (and not SharePoint).

The embedded BI features now run with SharePoint as opposed to on SharePoint. These changes do however require some planning and some effort on behalf of those that have already invested in the current platform and wish to move forward on-premises. With this in mind, and the fact that concise information around these changes is a bit difficult to find, I wanted to put this reference together. This post does not get into migration strategies, only the changes themselves.

The source for much of the below comes from discussions with the relevant product teams, and official information is found (today) in two primary places. The document What’s deprecated or removed from SharePoint Server 2019 Public Preview
which was published concurrently with the SharePoint 2019 public preview, and Christopher Finlan‘s presentation at the Microsoft Business Application Summit 2019 entitled Self-service BI and enterprise reporting on-premises with Power BI Report Server.

A summary of the changes to BI features, and a brief discussion of each is below.

Feature Status
SQL Server Reporting Services Integrated Mode Removed
Power View Removed
BISM file connections Removed
PerformancePoint Deprecated
PerformancePoint – Decomposition Trees Removed
Power Pivot for SharePoint Removed
Scheduled workbook data refresh Removed
Workbook as a data source Removed
PowerPivot management dashboard Removed
PowerPivot Gallery Removed

SQL Server Reporting Services Integrated Mode

SSRS Integrated mode was deprecated in November 2016, as was not a part of SQL Server 2017. However, organizations could continue to use SSRS versions from 2016 and prior in SharePoint 2016. This is not supported in SharePoint 2019, which means that integrated mode isn’t an option at all with SharePoint 2019. The good news is that the recent Report Viewer web part fully replicates the capabilities of the SSRS Integrated mode web part.

Power View

Power View was a feature of SSRS Integrated mode and is available in Excel. When Excel Services was removed in 2016, Power View in Excel required SSRS Integrated mode to work. Both supporting platforms are now gone, and thus Power View is not supported in SharePoint 2019.

BISM file connections

The BISM file connection type was used by Excel and SSRS to connect Power View reports to SQL Server Analysis Services data sources. This connection type has been removed along with Power View.

PerformancePoint Services

PerformancePoint is a combination of capabilities that includes dashboarding, scorecards, and analytic reports. Very few new features have been added to PerformancePoint in the last few versions, and this one even loses a few. Many of of these features are also available in Power BI and Power BI report server, and Microsoft has taken the decision to deprecate this product. This gives customers with a PerformancePoint investment time to migrate their assets but is a clear indication that it will also be removed in a subsequent release.

PerformancePoint – Decomposition Trees

The Decomposition Tree feature in PerformancePoint came originally from ProClarity – one of the three products that made up the original PerformancePoint product. These visuals are based on Silverlight, and have been removed from the product accordingly.

PowerPivot for SharePoint

PowerPivot for SharePoint is not supported in SharePoint 2019. PP4SP was originally a combination of two technologies – a specialized version of SQL Server Analysis Services, and a SharePoint service application. In the 2016 version, these two parts were split into two – the SSAS component became a part of the SQL Server installation media as SSQL – PowerPivot mode, and the service application, which continued the name PowerPivot for SharePoint. To be clear, it is the second of the two that has been removed. SSAS PowerPivot mode continues to be an important component and is used by Office Online Server for working with Excel files that have embedded models.

Scheduled workbook data refresh

This feature allowed for the automatic refresh of the data stored within Excel workbooks in SharePoint. It requires a PowerPivot data model to work, but the refresh operation would refresh all connected data in the workbook on a scheduled basis. This was a component of PowerPivot for SharePoint. It has recently been announced that this capability will soon be available in Power BI Report Server.

Workbook as a data source

With PowerPivot for SharePoint deployed, it is possible to use the data model in a published Excel workbook as the data source for another workbook. This feature will no longer be available, and there are no plans at present to reintroduce it.

PowerPivot Management Dashboard

Originally a part of SharePoint Central Administration, the management dashboard provided status updates on all PowerPivot for SharePoint operations. Being a part of PowerPivot for SharePoint, this has been removed accordingly.

PowerPivot Gallery

The PowerPivot Gallery is a modified SharePoint Document library form that displays worksheet thumbnails contained in published Excel workbooks. This component is Silverlight based, and part of PowerPivot for SharePoint. It has been removed accordingly.

Power View, Decomposition trees, and the PowerPivot gallery were the last remaining features that carried a Silverlight dependency. SharePoint 2019 no longer has any Silverlight dependencies.

These changes are significant for anyone with an existing Business Intelligence investment that plans to move to SharePoint 2019. I intent to write more about migration strategies and will be addressing these topics at various conferences in the future.

5 Comments

Power BI Report Server Completes the Vision for On-Premises Reporting

Microsoft today made available the August 2017 preview of Power BI ReportServer 2017. This preview includes the long awaited support of embedded data models, as well as the ability to render Excel reports natively. This is a major step forward, because with this release, Microsoft has completed its vision for its on-premises reporting platform that it first articulated in October of 2015.

Excel content being rendered in Power BI Reporting Server

The big news at the time was that the platform was stated to be SQL Server Reporting Services (SSRS). Not SharePoint, not PerformancePoint, but SSRS. SSRS was a mature product that quite competently provided a platform for operational reports. What it needed was some modernization and the addition of some analytical and self-service reporting capabilities. Several of these capabilities were subsequently included with the release of SSRS 2016.

Gone would be the days of configuring complex SharePoint farms just to be able to work with analytical reports (ie Power View, Excel). New Features were being added to SSRS to make it a complete platform for both analytical and operational reports.

The Vision

The roadmap articulated four different report types, 3 of them analytical (by my definition) and one of them operational. These three types line up with reporting tools in the Microsoft BI stack:

Name Type Primary authoring tool ext
Paginated Operational SSRS Report Builder
SQL Server Data Tools
.RDL
Interactive Analytical Power BI Desktop .PBIX
Mobile Analytical Mobile Report Designer .RDLX
Analytical Analytical Excel .XLSX

Therefore, reading between the lines, in order to be a complete reporting platform, SSRS needed to be able to render all of these report types. Paginated reports were of course always native to SSRS, and the roadmap announced that Mobile reports would be included in SSRS 2016 through the integration of Datazen. The roadmap further committed to SSRS being able to render Power BI files in the future.

SSRS 2016

SSRS shipped with some significant modernization improvements, including a much awaited HTML5 rendering engine, and it included Mobile Reports. Mobile reports are delivered through the Power BI mobile application, and SSRS visuals can be pinned to Power BI dashboards.

Significant plumbing was done to move the platform forward in 2016, but it still only rendered 2 of the 4 report types.

In November 2016, it was further announced that the 2016 version of SSRS running in SharePoint Integrated mode would be the last. Moving forward, Reporting Services will only run in Native Mode. In the same announcement. In the same announcement, as I noted in another post, for the first time, the SSRS team committed to providing Excel report rendering capability as well.

Power BI Reporting Server

We first saw the on premises rendering of Power BI reports in the first community preview of SSRS V.Next in the fall of 2016. Those previews required that the reports be directly connected to SSAS tabular models, but they were ground-breaking just the same. A user could be totally disconnected from the web, and still render Power BI reports.

In May of 2017, Power BI Report Server (PBIRS) was announced. A less confusing name could have potentially been SSRS Premium, because that is in essence what it is. PBIRS is everything that SSRS is, plus the ability to render Power BI reports. SSRS will continue forward as a product without Power BI rendering capabilities. It is just a licensing distinction.

The release today of the August 2017 preview of PBIRS allows for embedded data models, and therefore a much wider breadth of capabilities. These models cannot be automatically refreshed yet, but they will upon release. This is, after all, just a preview. If you need automatic refresh of these data models in the meantime, there is an excellent third party solution to do this: PowerPivot Pro’s Power Update.

The inclusion of Excel report rendering capabilities means that PBIRS is a complete report rendering platform, more complete even that the Power BI cloud service.

Moving Forward

Now that the basic on-premises capability has been provided, SSRS/PBIRS needs to pay attention to paying back the debt that it incurred when SharePoint Integrated mode was deprecated. Chief among these features is the SSRS web part. The lack of a decent web part is a blocker for many organizations to move forward with this strategy. Some migration tools to move from Integrated to Native mode (like this one that migrates in the other direction) would be highly useful as well.

Now with on-premises covering all the bases, it’s easy to spot a glaring hole in the cloud Power BI offering. While it supports all three types of analytical reports, there is currently no way to render operational reports in the cloud. Until this capability is provided, it appears that on-premises will have the most complete solution.

2 Comments

Where we are with the BI Workload in SharePoint 2016 – BI Focal #4

This past week, on March 24 2016, My co-host Jason Himmelstein and I had the privilege of hosting Kay Unkroth and Gregory Appel from Microsoft on our monthly BI Focal web show. Kay and Gregory are both Senior Product Managers at Microsoft. Kay is responsible for both the PowerPivot for SharePoint and SQL Server Reporting Services service applications, and Gregory is responsible for Excel Online in Office Online Server (or as we’ve come to affectionately call it, Excel Online On-prem). We titled the show SELECT From On-Prem WHERE version=’2016′. The recent release of SharePoint 2016 RTM, and the imminent release of Office Online Server and SQL Server 2016 make this topic particularly relevant.

What transpired was a frank, hour long (almost) discussion on the current state of the On-premises BI story from Microsoft. We discussed a number of burning topics such as

  • The implications for the deprecation of Excel Services
  • The new focus on SSRS as a BI platform
  • How SharePoint fits in to the new Microsoft BI vision
  • The status of PerformancePoint and Visio Services
  • Where Power BI fits into the on-prem picture
  • The upgrade story for 2016 BI, and version dependencies

I had a great time participating in this discussion, which was jam packed with great information. The recording of it is now available from IT Unity, or below.

[embedyt] http://www.youtube.com/watch?v=FZi7B1sl5Ts[/embedyt]

As always, Jason and I would like to thank IT Unity for all of the logistical information for the show, and our guests who graciously donated their time.

Leave a Comment

Integrating SharePoint 2016 with SSRS Native Mode

Why on earth would I want to write an article on this topic? Surely, if I am using SharePoint and SQL Server Reporting Services, I should be running in in SharePoint Integrated mode, right? That’s certainly the message that I have been delivering for quite some time. However, the game has changed significantly with SSRS 2016. Last October, Microsoft outlined their reporting roadmap, and that roadmap included a significant investment in SSRS. The roadmap was very clear as to Microsoft’s intentions.

“Reporting Services is our on-premises solution for BI report delivery”

Reporting Services is the solution, not SharePoint with Reporting Services, or PerformancePoint with Reporting Services, just Reporting Services. For several years now, the path to any new features in SSRS led through SharePoint Integrated mode. Features like Power View reports were only made available in Integrated mode as an example. While that was great for those invested in SharePoint, it presented an adoption issue for those that were not. This issue has prompted Microsoft to remove the SharePoint dependency, while still providing solid integration. In short, the goal for SSRS is to run with SharePoint, not on it.

In my opinion, this is all to the good. By making SharePoint integration pluggable, the product team can focus on one codebase instead of two, and spent more energy on features. This does however have some negative impact on administrators that will need to again manage two security models, but in the ideal world, it should be transparent to end users.

The immediate impact of this refocusing is that Native mode now receives new feature priority. If we look at the current state of SSRS 2016 (RC0 at the time of this writing), only a few of the major new features will be available in SharePoint integrated mode.

SSRS New Features

Native SharePoint Integrated
HTML 5 Based Rendering Engine

Customizable Parameters Pane

New UI for Report Builder

New Web Portal

Mobile Reports

New Chart Types

PDF replaces ActiveX for printing

PowerPoint rendering and export

KPIs

Pin to Power BI Dashboard

Render Power BI Desktop files

HTML 5 Based Rendering Engine

New UI for Report Builder

New Chart Types

PDF replaces ActiveX for printing

PowerPoint rendering and export

This new disparity is likely to leave some in the SharePoint world feeling left behind. The reality is that although this may seem like the case in the short term, Microsoft stated that “We will continue to support embedding of BI content into SharePoint”. For the record, that statement is open ended enough to include both SSRS and Power BI. The improvements to integrated mode in SharePoint 2016 are a testament to this support. It would have been just as easy to leave Integration mode in its previous state (like PerformancePoint). My view is that ultimately Native mode reports will work with SharePoint in much the same manner that current Integrated mode ones do. In fact, it’s possible to do some of this today – to embed Native mode SSRS Reports into SharePoint. That’s what the remainder of this article describes.

The ability to embed Native mode SSRS reports has actually been available since SharePoint 2003. It fell by the wayside after Integrated mode was introduced in SQL Server 2008 R2, but it has continued to be there. What is needed is a Native mode SSRS Server, and the Native mode SharePoint web parts.

Installing and Configuring SSRS Native Mode

Native mode SSRS is installed from the SQL Server media. It should be installed on a NON SharePoint server. Run the SQL Server installer, and eventually you will be taken to the feature selection screen.

Native mode SSRS installs as a SQL Server instance, and it is the only option necessary to install. The SharePoint add-in is only used for Integrated mode.

Once installed, it is necessary to run the Reporting Services configuration tool. The first step in configuration is to set up the web service URL.

Once the desired options are set, click Apply and the SSRS web service will be set up. Next, click on the Database node to configure the SSRS database. If the SQL Server database is installed on the same machine, you can use it, but you can use any SQL Server at your disposal. The only restriction is that the database engine must be at least the same edition level as SSRS (ie Standard vs Enterprise).

To create a new SSRS database, click the “Change Database” button and provide the database parameters.

Two databases will actually be created, one of them a Temp database. I recommend using the word “Native” or some other identifier in the name, particularly when both Native and SharePoint Integrated mode servers may be used. Complete the database creation process, and move to the Report Manager URL node.

Click Apply to create the SSRS Report Manager. The initial URL will always be based on the machine name, but once complete, you can click on the Advanced tab to add additional URLs. This is how you can add a Fully Qualified Domain Name (FQDN) to your SSRS server, which is strongly recommended if you will be integrating SSRS with Power BI. Power BI users will need to connect directly to the SSRS server to view SSRS reports, and this requires an FQDN.

There are other steps to be performed at this point, including Power BI integration and exporting the Encryption keys, but this is all that is necessary for basic configuration. You should now be able to navigate to your Report Manager URL and create reports. The next step is therefore to integrate them with Sharepoint.

Integrating with SharePoint

Native mode ships with a pair of web parts that allow SSRS web parts to be embedded into a SharePoint page. The web parts are embedded in an installable .cab file that can be found in the folder “C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Reporting Services\SharePoint” where C: is the installation drive, and “130” is the major installation version for SQL Server (130, or 13.0 corresponds to SQL Server 2016). The name of the file is RSWebParts.cab. Copy this file to a SharePoint server in the farm, and from there, it can be installed from either PowerShell, or the gool ol’ STSADM command. With PowerShell, the command is:

Install-SPWebPartPack -LiteralPath “D:\Software\RSWebParts.cab” -GlobalInstall

Where “D:\Software” is the folder that the file was copied to. The corresponding STSADM command is:

STSADM.EXE -o addwppack -filename “D:\Software\RSWebParts.cab” -globalinstall

Unfortunately, I and many others have found that the version of the .CAB file distributed with SQL Server 2012 and above are incompatible with SharePoint 2013 and 2016 – the web parts fail to deploy. The good news (and the bad) is that the web parts are unchanged from SQL Server 2008 R2, and that version of the .CAB file will work with modern SharePoint. Of course, not everyone has a SQL Server 2008 R2 server lying around, so if you happen to need the file, I include it here:

RSWebParts.cab from SQL Server 2008 R2

Using the Web Parts

Once deployed, the two web parts, Report Viewer and Report Browser will appear under the miscellaneous section when a web part is inserted into a page. Report browser allows the browsing of reports on a server, and Report Viewer renders them. By connecting the two, it is possible to provide a highly interactive navigation of the report server right in a SharePoint server. However, editing the Report Viewer web part reveals that it is lacking some very fundamental capabilities.

Native Mode Web Part

Integrated Mode Web Part

The Native mode web part is missing all of the view control features that are available to the Integrated mode part, which means that when it comes to Native mode reports, you get what you get. However, more concerning is the fact that it is also missing parameters. There is no way to configure parameters for, or pass parameter values to Native mode reports embedded on a page.

Add to this limitation the fact that these web parts are approximately 10 years old – they were designed for SharePoint 2007. They are able to render the new chart types, but not through the new HTML renderer. These limitations make it very difficult to recommend their use, except in a few very specific scenarios.

Recommendations

So what is a Report driven SharePoint administrator to do? All of the cool new features are showing up in Native mode, but except in certain circumstances, there no really good way to embed those reports in Sharepoint pages. It seems a difficult question, but the reality is that these choices are not necessarily mutually exclusive. SSRS Integrated mode is getting many of the modernization improvements and continues to be a totally viable platform moving forward. If you want or need to take advantage of the new SSRS features like mobile reports, parameter pane customization, or Power BI integration, you can stand up a separate SSRS Native mode server, and even integrate it with SharePoint using the older web parts.

Taking this dual approach means that you’ll be well positioned to gradually move assets from Integrated mode to Native mode as the embedding story and capabilities improve.

17 Comments

Configuring SSRS 2016 Integrated Mode with SharePoint 2016

SQL Server Reporting Services (SSRS) has experienced some very significant improvements in the 2016 version. As has been the case Since SQL Server 2005 SP1, it runs in either Native, or SharePoint Integrated mode. Integrated mode (the subject of this article) requires SharePoint 2016, and it is required for SharePoint to be able to render Power View reports in a browser.  This article walks through the setup and configuration of SSRS 2016 Integrated mode in a SharePoint 2016 farm.

The process for setting up SSRS in Integrated mode is little changed with 2016. The process consists of installing the bits on the SharePoint server(s), creating and configuring the service applications, deploying the solution, and configuring document libraries to contain report elements.

Installing SSRS 2016 on Sharepoint Servers

When running in integrated mode, SSRS MUST be installed on a server that is part of the SharePoint farm. This only makes sense because it is deployed as a SharePoint Service Application. Unfortunately, the fact that is distributed as part of the SQL Server media causes confusion for some.

As of this writing, SSRS must be installed on a SharePoint 2016 that is configured in a Custom Role. MinRoles are new to SharePoint 2016, and SSRS does not support any other role than the Custom role. If your server is not running the Custom role, installation will succeed, but SSRS will be shut down by the roles engine during the next maintenance window. In order to check which role your server is using, and to possibly change it, you can use either PowerShell or Central Admin. With Central Admin, the setting is found in “System Settings”, under the “Servers” category as “Convert server role in this farm”.

Selecting this option opens the role configuration dialog, which is quite simple.

If the role is already set to Custom, you are good to go. Otherwise, it can be changed with the “New Role” drop down dialog.

Once the correct role is in place, SSRS can be installed. The first step is to mount the SQL Server media on a SharePoint server, and run the standard SQL Server installer. SSRS Integrated mode is part of the Shared Features collection (ie no SQL instances are installed), and it consists of two parts.

The first option, “Reporting Services – SharePoint” is the actual SSRS Service application. This should be installed on any SharePoint servers allocated to doing the heavy lifting of rendering reports – the “app” servers. The second option “Reporting Services Add-in …” is used to connect a SharePoint server to an instance of the SSRS Service application. This should be installed on any SharePoint front-end servers at a minimum, but I recommend installing it on all of them as a convenience.

After a few “Next”s and “OK”s, the SSRS bits should be installed on a server. The next step is to Create and configure the Shared Service Application itself.

Creating the SSRS Shared Service Application

Once the bits are installed, an SSRS Service application is created in the same manner as any other service application. From the Service Applications interface in Central Administration, select “New” from the ribbon, and then select “SQL Server Reporting Services Service Application”.

You will then be presented with a configuration dialog where you will need to specify a name for the service and a few other configuration parameters.

I typically use the same application pool as most of the other SharePoint services, and I always change the name of the database. The default database name contains a GUID, and nobody likes GUIDs in their database names. The SSRS will actually create 3 databases, one with the name specified, and two others that use this name as a base. Also, if you’ll be using other Reporting Services databases on the same SQL Server – for Native mode as an example, it’s a good idea to name it so that it’s easily distinguishable. In this example “Integrated” is added to the end.

Scrolling down, you’ll see options for activating the SSRS features in all of the farm’s site collections. The features can be activated from the site collections as well; this is simply a convenience.

Once saved, additional SSRS configuration items can be configured, and should be. At the very least, the subscription options should be configured, and the encryption key should be backed up, but these operations are not essential for basic setup, so they will not be done here. The next operation will be to enable a document library for SSRS reports.

Creating a Reporting Library

Enabling a document library in SharePoint for SSRS reports is unchanged from the past several versions. The first step is to add a new document library by going into “All Content” for a site, and selecting “Add an App”. You may be tempted to select “Reports” or “Report Document Library” at this point – don’t. The “Reports” library template that ships with SharePoint 2016 and prior contains content types for creating Excel documents in prior versions, web pages – that’s it. It has nothing to do with SSRS reports.

Select a Simple document library, give it a name (something like SSRS Reports, or SSRS library), and let it be created. Then, go into the library settings, click Advanced settings, and enable the use of content types. Next, add the SSRS content types to the library by clicking “Add from existing site content types”, selecting the “SQL Server Reporting Services Content Types” category, and then selecting “Data Connections” and “SSRS Report”. Unless you have a specific need, do not add the “Report Builder Model” content type. Models are a deprecated artifact and exist only for backward compatibility.

Once added, click OK, and you will be returned to library settings. At this point I like to remove the “Documents” content type from the list to restrict it to reports, but that will depend on your requirements. At this point you should be able to create a new report or data source by selecting new in the library’s ribbon and choosing the appropriate item. This library can now be used to store reports.

The final step is to enable and confirm support for Power View.

Power View Support

Power View support in SharePoint 2016 is provided through SSRS Integrated mode (and ONLY through SSRS Integrated mode). It is manifested in 3 different areas:

  1. Creating and viewing a standalone Power View report from a data connection
  2. Creating and viewing a standalone Power View report from an Excel workbook in a PowerPivot gallery
  3. Using a browser to view a Power View report contained in an Excel workbook

1. Creating and viewing a standalone Power View report from a data connection

Standalone Power View reports utilize BISM (BI Semantic Model) connections. BISM connections can be added to a SharePoint library by adding the “BI Semantic Model Connection” content type to the library – this would normally be done for a connections library. A BISM connection can also be created through an SSRS data source by selecting “Microsoft BI Semantic Model for Power View” as its data source type.

Creating a Power View report from either connection type follows the same process. In the library, click the ellipsis for the connection, and then the second ellipsis. From there, select “Create Power View Report”

Provided that Silverlight is available on the client, Power View should launch, and you should be able to build a report on the underlying data.

2. Creating and viewing a standalone Power View report from an Excel workbook in a PowerPivot gallery

Creating a Power View report is significantly simpler. Once SSRS is installed, it adds a small Power View icon to every workbook that is in a Power Pivot gallery.

Simply click on the icon, Power View will launch, and you can build a report on the data model that is contained in the workbook. There is however one additional step necessary for this to work. Because the data model is actually stored in the SSAS PowerPivot mode server(s), and it is SSRS (remember, Power View is part of SSRS) that is working with the model (not OOS), the service account for SSRS needs to be added to the Administrators list on the SSAS PP mode server(s). In our case, the service account is NAUTILUS\spServices.

3. Using a browser to view a Power View report contained in an Excel workbook

Power View reports that have been embedded in an Excel workbook require no additional configuration, they should “just work” once SSRS is configured. However, as with the PowerPivot gallery, SSRS needs access to the data models, and therefor its service account needs to be in the administrators list (see above).

Wrapping Up

Once installed and configured, you will have access to the new HTML5 based rendering engine and new visuals available to SSRS 2016. You will also be ale to work with your existing Power View investments. However, you will not be able to use the new mobile reports, Reporting Dashboards, Parameters customization, and Power BI integration. For that, you’ll need a Native mode SSRS instance, and yes, it can be connected to SharePoint. That will be the topic of an upcoming article.

37 Comments