Skip to content

Category: Technology

The Future of Report Integration with SharePoint

Published November 18, 2016

Yesterday, Microsoft made official what many, including myself had been suspecting ever since the release of SQL Server 2016 – that SQL Server Reporting Services Integrated mode would not exist in the future. With the announcement, we now know the timeline of when that will happen. SSRS Integrated Mode will not be included with the next version of SQL Server. Instead, SSRS Native mode will be more tightly integrated with SharePoint for those organizations that use both products. As someone that has always approached Business Intelligence from the SharePoint point of view, I see this is a good thing.

This change is another step in the process of de-cluttering and uncomplicating SharePoint. This process started arguably with the move away from fully trusted code running on SharePoint, to the newer app, add-in and now SPFx development models that run with SharePoint. When Excel Services was removed from SharePoint in SharePoint 2016, with its capabilities moved to Office Online Server this process became obvious. A decreased dependency on SharePoint allows for simpler, more streamlined architectures, better options for upgrade management, and better, more targeted performance management.

SSRS SharePoint Integrated mode has been with us in various forms since it was first introduced in SQL Server 2005 SP2. The original goal was to simplify the integration of the two products, and to take advantage of SharePoint’s storage and authorization capabilities. The integration has always worked well, but the very fact that these two products were delivered by two different product teams on different media, often on different release schedules has typically led to a great deal of confusion. The SharePoint prerequisite for Integrated Mode leads to far too many SQL servers having SharePoint installed on them.

Managing SSRS in SharePoint Integrated mode requires a combined skill set to some degree as well, with knowledge of both SSRS and SharePoint. SharePoint administrators tend to be intimidated by SSRS, and SharePoint simply mystifies SQL DBAs.

The fact that the two different modes did not always maintain feature parity is another problem. PowerView and several other features are only available through SharePoint integrated mode. This results in entire SharePoint farms being created for the sole purpose of providing reporting features. Since those performing these installations are typically not familiar with SharePoint best practices, these farms tend to be unreliable. The latest release of SSRS 2016 contains a massive number of new features, but many of them in Native mode only, leaving the SharePoint integrated folks with a decision whether to favour features or integration.

A strategy that reduces the dependency of one platform on the other is therefore to everyone’s advantage.

The two operating modes also represent two different code streams for Microsoft to maintain. Given the finite set of resources that is any development team, resources must be spent on maintaining both of these streams that could otherwise be applied to features. A single code stream is simply more efficient.

Preventing the wholesale move to Native mode are several SharePoint integration features that have been employed over the years that are only available in SharePoint Integrated mode.

There has been a SharePoint Report viewer web part for SSRS Native mode since SharePoint 2003. The trouble is that while it does work, it is deprecated, and hasn’t been updated since SQL Server 2008 R2. It also doesn’t allow for parameter binding, or interface control. For all intents and purposes, it is an iFrame embed of a report. The web part that is available through integrated mode allows for parameter interactivity, and significant control of the look and feel. It has been widely deployed. Integrated mode also allows for the reporting of SharePoint list data, and the ability to publish reports to a SharePoint library on a schedule. These features are well utilized in the market today.

Power View reports (RDLX) built on top of SSAS tabular models, or Excel Power Pivot models also require Integrated mode. Compounding this is the fact that Power View requires Silverlight, which does not work in either the Chrome nor the Microsoft Edge browsers.

These integration features will need to be added to Native mode before it will be possible to fully abandon Integrated mode. The good news is that the announcement commits to doing just that. Report embed, Report viewer web part, and SharePoint library destination capabilities will all be added. For Power View reports, a conversion tool will be provided to convert from RDLX into Power BI Desktop (PBIX). A technical preview is already availably that demonstrated PBIX rendering in SSRS.

This announcement signals the end of SSRS SharePoint Integrated mode, but it does not spell the end of SSRS SharePoint integration. The single mode architecture should be more approachable, simpler, and more efficient. It’s a win all the way around.

3 Comments

With Microsoft Teams, Office 365 Groups Can Now Have Multiple Planner Plans

Published November 10, 2016

Microsoft Planner went into general availability in June of 2016. It allows basic project and task management for organizational teams. Like most products in the Office 365 suite, Planner makes extensive use of Office 365 Groups, which provides membership services through Azure Active Directory, and Storage through SharePoint. Creating a new Plan in Planner is one of the ways to create and Office 365 Group – each plan gets a Group. Conversely, each Group gets a Plan.

Adding Members to a Plan – Adding to the Office 365 Group

One of the more requested features on the Planner User Voice site is to break this 1:1 relationship so that a Group could contain multiple Plans. It’s currently marked as “Thinking About It” in user voice, but it appears that far more work has gone into it than that.

Microsoft Teams was released into preview earlier this month, and included in Teams is very tight integration with Planner. Teams is also tightly coupled with Groups (each Team gets Group), and adding the Group’s Plan to the interface is relatively straightforward. Simply click on the “add tab” icon, and choose Planner.

And then give the plan a name and save it.

However, there’s more to it than that. From the Teams interface, it’s possible to create additional Plans. To do so, simple add another tab and repeat the process.

How is this possible? If there is a 1:1 correspondence between Groups and Teams, and a 1:1 correspondence between Groups and Plans, then there must also be the same correspondence between Plans and Teams. As it turns out, that the relationship between Groups and Plans is no longer limited to 1:1. The plans created in Teams are not (or do not appear to be) a part of the group. This can be seen if you open Planner on its own, and these plans will not appear in the “All plans” list, because this is just a list of Groups. The Group itself has a Plan associated with it, but it’s not any of the plans that are created in Teams. However, if you have tasks from these Plans assigned to you, they will appear in the My tasks list.

Conversely, in the Teams interface, I cannot find a way to have this default plan appear in the Teams interface. This is something that could be very confusing for any users that use bot the Planner ands the Teams interfaces. Given that Teams is only in preview now, I can only assume that these user interface inconsistencies will be remedied.

The bottom line to all of this is that it appears that the bulk of the work has been done to allow multiple plans in a single Office 365 Group. You simply need to use Microsoft Teams in order to access them.

2 Comments

Microsoft Teams and the New Microsoft Social Landscape

Published November 2, 2016

Today, Microsoft debuted Microsoft Teams. Microsoft Teams allows teams of people to quickly get together to collaborate in real time. If you’re keeping count, this represents Microsoft third tool in the Social Computing space.

Why would Microsoft want to introduce yet another social computing tool? They already have Yammer, Skype (for business and personal), and Outlook Group conversations. What would be the reasoning for this new product? At one level, Microsoft Teams is aimed at the same group of users that find value in Slack, which is a social tool that has grown in popularity recently and is particularly popular with developers.

I was first exposed to Slack a little over a year ago. I had heard about it, and the buzz around it was that it was the “next big thing”, so my expectations were high. When I did first use it, my thoughts were, “That’s it? That’s all there is to it?”. Functionally, Slack doesn’t really bring anything to the table that we didn’t have 30 years ago with IRC chat. Now, given the demographic that Slack is popular with, they are likely not old enough to remember IRC. Of course, none of this really matters, what matters is that Slack fills a need for immediate, almost synchronous communication with very little structure. Slack doesn’t even support threaded discussions. However, it’s simplicity is its strength and its value proposition, and Microsoft hasn’t had anything in the market quite like it. Until now.

So how does this product compare with its existing Social tools, Yammer and Outlook Groups? When would you use one vs the other?

Microsoft bought Yammer in 2012 and quickly championed it as the cornerstone of its social computing strategy moving forward, replacing the social features of SharePoint Online, and making them optional in SharePoint on-premises. However, at Ignite 2015, Microsoft introduced Groups for Office 365, which included a conversation platform based on Exchange (Outlook conversations). This was essentially a group inbox with a number of social features added such as likes, etc. It was pretty clear that Groups were going to be the underpinning of the next generation of features in Office 365, and this led to quite a bit of uncertainty about Microsoft’s social strategy. The recent Ignite 2016 made it pretty clear that Microsoft is doubling down on Yammer as its social strategy, but that does little to clear up the confusion. What happens now with Outlook conversations? Microsoft Teams would seem to only make it worse.

The reality, in my opinion, is that these tools are not exclusive. Although there are some areas of overlap, I see them at complementary, with each serving a niche depending on requirements, or at the same time. The problem is that they tend to be positioned as competitors. In my opinion, we have an “or” vs an “exclusive or” situation.

I have used Yammer, Outlook Groups and Slack (used here for comparison purposes) of these platforms fairly heavily in the past year. At UnlimitedViz, we have moved most of our collaboration and document management away from Team sites and into Groups. On a side note, we’re very happy to see Team sites now following us over. Yammer is the platform that we primarily used for our threaded discussions. Slack is used by the MVP community for quick and easy chats. I like all three and dislike all three for different reasons.

Once we moved most of our customer focused content into Groups, the value of having an inbox for each group became readily apparent. When going through email, I could simply forward important ones to the group, where it would be retained, and accessible to other members of that group. I could now delete customer email with impunity. From a feature standpoint, this is gold. We also decided to run one of our more significant projects using Outlook conversations alone, and that aspect wound up being a very poor experience. The email infrastructure simply wasn’t built for threaded conversations.

Yammer can infuriate me from time to time, particularly with its unread mark handling (which has admittedly gotten better) and its poor to non-existent search capabilities. Content stored in Yammer is effectively gone as far as I’m concerned, which makes it particularly difficult to have conversations around context. Keeping the content in Office 365 Groups requires a lot of URL copying and pasting if you want to socialize or discuss it in Yammer. A “group” in Yammer is not the same thing as a Group in Office 365. With all of that said, Yammer delivers a superior threaded discussion experience. Its similarity to Facebook makes adoption relatively easy, and its threading keeps relevant content at the top.

Slack is the simplest of the bunch, which makes it the easiest to get up and running. It is almost totally unstructured, meaning that while anything goes, it’s not too long before it disappears. Messages are kept, but I grow weary of scrolling back through the pile of previous messages to find something that I think that I saw. Slack lives in the “now”, and the more current the content is, the more appropriate Slack is. However, it doesn’t take long for a Slack channel to become noisy, with several conversations going on at the same time. It’s like having ADD while being at a noisy cocktail party.

None of these tools on their own deliver everything necessary for a complete social experience, although they are suitable on their own for their own niche. I think that my biggest pet peeve about using these different tools is that I need to jump from interface to interface to complete the experience. This, I believe is where Groups comes in.

Office 365 Groups is (I so badly want to use “are” here… but Groups is the name) designed to be an integrating construct. Groups really has no interface of its own, but when it was originally released, it backed the interfaces of Outlook, OneDrive, and OneNote. Outlook Groups is the Exchange based conversation interface. Shortly afterward, Office 365 Groups became an integral part of Power BI and Planner as well. Integration of Modern SharePoint Team Sites with Office 365 Groups provides a logical entry point for the Group, as SharePoint can integrate disparate UI elements. At Ignite 2016, both Yammer and Power BI content was shown in pages in a Modern Team Site through web parts. It’s not hard to see how these things can coexist in the same container.

Yammer embedded in a Modern Team Site

Power BI embedded in a Modern Team Site

The introduction of Microsoft Teams would seem to muddy the water a little. The important thing is to understand which tool to use under which circumstance. This is a much-discussed topic, and there are hours of presentation material available that discuss it. The decision is a combination of personal preference and applicability to the task at hand, but far too often it becomes a matter of familiarity. When you have a hammer, everything looks like a nail. I wince every time that I’m asked to build click throughs into an SSRS report, or to design a Power BI report to optimize printing – these are two different tools that are good at doing different things. Often, if it can be done with the tool that you know, often time we don’t look elsewhere, even when that other tool is better at that task. Further to this, the “difference” can often be a matter of perception, and in the case of an online service like Office 365, of branding.

These components can be used within team sites as appropriate wherever suitable. With the team site providing the “glue”, it will be possible to surface content from any or all of these tools as appropriate. All the products already require, or use an Office 365 license already, so that is not a consideration. The question is where would you use one versus the other?

As mentioned above, Outlook Groups makes for an excellent Group inbox, but is not great as a conversation platform. This Group inbox also provides the destination for content brought in from Office 365 Connectors. It’s a logical and effective landing spot for content that is sent to the group. If the group needs an inbox, this is it – straightforward. Less straightforward is the difference between Microsoft Teams and Yammer.

I’ve been using Slack thus far as an example of group chat simply because it’s what I have experience with. Microsoft Teams is new, and while it compares favourably with Slack, it also includes threaded discussions. Threaded discussions are something that Slack does not have, but Yammer does, and this makes the decision between the two a little less clear than between Yammer and Slack. IN fact, looking at the UI, it’s a little difficult to spot the difference.

Microsoft Teams threaded conversation interface

Even with threaded discussions, Microsoft Teams has more in common with Slack than it does with Yammer. Microsoft Teams is highly appropriate for small groups that get created, have a relatively short or defined life, and are then retired. Yammer groups are more structural – they are typically managed by someone to help foster participation. Microsoft Teams follow a bottom up approach, where Yammer is more top down. Small groups will participate in a single Team, but too many users will likely make it too noisy to be useful. Conversely Yammer groups can reach the entire enterprise, and like most networks, their value increases with the number of nodes. Microsoft Teams are focused of chat, and Yammer is focused on conversations. If you need to get a quick group of collaborators together around a specific goal, Microsoft Teams is likely the right tool, but if you’re trying to build a community, Yammer is likely a better choice. There are of course other technical factors that may dictate one versus the other, but these factors are subject to change.

This leads me to my suggestion. We can see that the technology is emerging that will allow us to work with these tools simultaneously, as appropriate. Office 365 Groups along with Modern SharePoint Team Sites will become the containers for this convergence. However, if these products maintain their own identity, there will continue to be confusion around which one Microsoft is “betting on” or which one is “the best”. I believe that a rebranding exercise is in order.

  • Outlook Conversations becomes Group Inbox
  • Yammer becomes Group Conversations
  • Microsoft Teams becomes Group Chat

While this branding may not become a reality, I think that it’s helpful to think of the 3 tools in this manner.

7 Comments

How to Migrate a WordPress site to Azure Using In-App MySQL

Published October 25, 2016

Did this site load a little faster than it normally does? You may not have a basis of comparison, but I have noticed that pages load between 2x and 5x faster since I moved the site to Azure hosted WordPress using an In-App MySQL database. Previously I was running it on Azure as well, but it was using the 3rd party ClearDB database server. The performance increase is therefore entirely due to the difference in the database engines.

I have been running this blog as a web app on Azure for the last couple of years, ever since it became available. In fact, I wrote about how to enable hosting for multiple users on the same database when I first set it up. At the time, setting up a WordPress web app involved also provisioning a MySQL database through a third-party hosting provider, Clear DB. The initial offering was free, but as I quickly found out, the initial offering also doesn’t provide much, and I needed to upgrade it through the third party. This arrangement was fraught with difficulty. Aside from the unwelcome additional costs, managing the billing cycle was difficult. In addition, all my WordPress sites were a little to a lot sluggish, and increasing Azure resources didn’t seem to help much.

Over time, I learned that I wasn’t the only one, and the performance problems seemed to be with latency between Azure and the third-party provider. However, I didn’t want to start messing around with standing up my own, and it was usable if a tad expensive. However, a month or so ago I was listening to my friends Andrew Connell and Chris Johnson on the Microsoft Cloud Show, and they mentioned that Azure had put out a preview of a native MySQL implementation. This was of course music to my ears, so I tried it out, and it appears to work quite well.

I have since moved all our WordPress properties over to this new architecture, and documented the procedure. The approach that I tool should work for any WordPress site, whether it is hosted on Azure or not, but the examples I use will of course be going from Azure to Azure. I essentially create a new WordPress site, migrate the site assets to it, configure the new site to match the old one, then point the address to the new web app. There are quite likely third party add-ons that facilitate this process, but this process is manual. I am in no way saying that this approach is a best practice, only that it worked for me. Finally, as noted above, the In-App MySQL is in Preview, not production, so if your WordPress site is critical, it would likely be a good idea to hang on for a bit. I however like to live dangerously, and if my blog goes offline for a few hours, it’s not the end of the world.

Here are the steps required to accomplish this.

1. Upgrade the existing site

The new site that will be created will use the latest version of WordPress, and any plugins that get installed will also be the most recent. To avoid any version mismatches, it’s a good idea to make sure that your WordPress version, and all your plugins are up to date.

2. Retrieve the WordPress Assets from the existing Site

You can use the built-in export feature in WordPress to retrieve all the database assets. Open the tools section, select “Export”, and choose “All Content”.

The types of content will vary depending on your WordPress installation, plugins, etc., but make sure that you select all of them. When ready, select “Download Export File”. You’ll get prompted to download an XML file – put it somewhere safe – you’ll need it later.

Next up, you’ll want to retrieve your file system based assets. These will be all your uploaded files, unless you currently use and externally hosted provider, your WordPress themes, and your plugins. Strictly speaking, this step isn’t necessary. You should be able to re-download your themes and plugins, but I have found that they aren’t always available, and that this process is faster. However, if you don’t have access to the file system of the existing site, you may not be able to do this. The upload files can be gathered through the import process later as well, but this approach provides an added level of safety.

For Azure, you’ll use FTP to connect to the file system and copy the files locally. For Azure hosted sites, you can set the FTP credentials by logging into the “new” Azure portal, selecting the web app for your site, then navigating to “Deployment Credentials”. You then enter a user name and a password, and save them.

Next, scroll down to “Properties” for the web app, and take note of the “FTP Host Name” and the “FTP/Deployment user”. You will use these values to connect to the file system.

Now open Explorer on a Windows PC, right click in the “This PC” node, and select “Add a network location”.

Follow the prompts entering the FTP host and the user name when prompted. Do not attempt to log in anonymously. Also, take note – the user name has the form web app name\username. When the node opens, enter the password, and you should see 4 folders. Open “site”, then “wwwroot”, and finally “wp-content”. The folders that you need are here.

Specifically, you are looking for the plugins, themes and uploads folders. Copy these folders locally and keep them handy.

3. Create the new WordPress Site

From the Azure admin portal, select “Create New”, and search for “WordPress”. There are several WordPress options to choose from, but the one we’re pursuing is published by WordPress.

Once selected, you will be prompted to fill out the details. Give the new app a name, select the Resource Group, and most importantly, the Database Provider. ClearDB is the one that we are moving away from, so “MySQL In App” is the one that we want to select.

Once you click OK, the App will be created, and WordPress will be deployed to it. The App creation happens almost immediately, but it takes a few minutes for WordPress to be fully deployed. Don’t be alarmed if there’s nothing there for a little while.

Once deployment is complete, you can simply click on the URL of the app in the “Overview” section. The URL will take the form of http://webappname.azurewebsites.net.

A browser will open and you will be prompted to complete the initial WordPress installation. One that complete, you will be able to login to the WordPress administration portal.

4. Upload the Older Assets to the new WordPress Site

The next thing that we want to do is to upload the assets that we downloaded in step #2 to the new site. To do this, simply connect to the new file system via FTP by following the same steps that were used to connect to the old site in step #2. Once connected, upload the 3 folders to the wp-content folder of the new site. If there are folders that already exist, or that you don’t want to use in the new site, simply omit them from the upload. Once uploaded, we can activate the features.

5. Activate Assets in the New Site

It is important to activate and configure the plugins before the content from the existing site is imported. This is because some plugins extend the schema of the WordPress database, and any content that depends on those schema extensions will fail to import if they are not present.

Login to the administrative portal in the new site, and activate all the required plugins. If you don’t know which plugins should be activate, simply login to the administrative portal of the old site for reference. It’s a good idea to have these portals open side by side as you complete the next few actions. Once the plugins are active, go to the appearance section, and select the same theme as the original. Once the theme is selected, it needs to be configured. Walk through all the configuration options for your theme matching with the original site. Any options that depends on content will need to be set after the content is imported. Once the theme is configured, the plugins should all be configured. This is a very manual process of going through all the configuration screens and comparing the settings to those of the existing site.

Finally, recreate all necessary users from the old system. You will need to match blog posts with authors during the import step. The import step will offer another opportunity to add new users, but it’s a good idea to do this prior so that complete information is added for each user.

6. Imports Content from the Existing System

From the administration portal of the new WordPress site, navigate to the Tools section, and select import. A number of options will be presented, the option that you’re interested in is “WordPress”. If you don’t already have the WordPress Import Plugin, you’ll need to select “Install Now” and allow the plugin to install and activate. Once activated, select “Run Importer”, and the Import dialog will appear. Select the export file that was downloaded in Step #2 above, and then click the “Upload file and import” button to see the Import WordPress dialog.

WordPress Import is author aware, and will automatically assign posts to users that exist in the new environment based on who they were in the old, you simply need to map them at this point. If you forgot to add a user in Step #5, you can do so here as well. Once authorship is assigned, the only other decision is whether to select the “Download and import file attachments”. Strictly speaking, if all assets were brought across in step #2, this shouldn’t be necessary. What this option does is to download all referenced assets from the existing blog during the import process. This doesn’t always work, particularly on larger blogs, which is why step #2 is so important.

In addition, if the content of the site results in a particularly large export file (as was the case with this one), you’ll need to increase the upload limit for your WordPress site. This can be done by creating a “.user.ini” file in the root of your WordPress installation as described here. Additionally, you may also need to increase some of the application timeout values.

7. Test

Test the new site to ensure that it works. This cannot be stressed enough. Open all the sections to ensure that everything looks right. Ideally, use browser windows open side by side with the new and the existing sites

8. Make URL Changes to the Existing WordPress Site

It is important to follow these steps to avoid being locked out of the existing site. There are ways to correct it if it happens, but the situation is beast avoided.

Open the administration portal of the existing site, and navigate to “Settings”, General. If the WordPress Address (URL) and the “Site Address (URL)” values do not match the default URL for the Azure Web App, they will need to be changed to that value here.

The address will take the form http://azurewebappname.azurewebsites.net. It’s also a good idea to navigate to that URL to ensure that it works before saving.

8. Make URL Changes to Azure

If your existing site isn’t running on the default Azure address, you’ll need to repoint it to the new site. This will cause your site to be unavailable for a few moments. To begin, you need to remove your custom domain from the existing (now “old”) site. Navigate to the Web App for the old site in the Azure portal, and select “Custom domains”. Your custom domain should appear there along with the default address (that was used in step 8).

Click on the ellipsis beside the domain, and select “Unassign”. This will remove the custom address from the old site, freeing it up to be used by the new site.

At this point, you will need to make changes to your domain with your domain registrar. You will need to change any references (A records and/or CNAME records) that you currently have for your custom address to point to the new Azure Web App. Details for those settings can be found under “Custom domains” for your new Azure Web App. Once complete, navigate to “Custom domains” in the new Web App and click on the “+” button beside “Add hostname”. Enter your custom address and the click the “Validate” button. The custom address will be tested, and if there are any issues with it, remediation steps will be provided. The Azure portal is quite good at helping to manage this step.

Once the new URL has been registered, it should be tested to ensure that it is accessible from the outside environment. Prior to testing, the old site should be stopped (but not deleted!) to ensure that it is not responding to any requests.

If SSL was used on the old site, at this point they should be brought in to the new Web App and bound to the site.

9. Make URL Changes to the New WordPress Site

If the custom domain is working, follow the steps in step 7, but on the new WordPress site, and use the custom address for the URL values. Save, and login again.

10. Final Testing

At this point the site is live, but it is worthwhile to do another round of testing with the old Web App in a stopped state. This will identify any URLs hardcoded with the old Web App default URL, and missing assets, etc.

At this point, the new WordPress site is set up and working with the In-App MySQL database. I would recommend waiting a week or so before going back and deleting the old site and its assets, just in case.

8 Comments

SharePoint and Power BI – Better Together

Published September 30, 2016


Ever since 2007, SharePoint has included Business Intelligence amongst its core workloads. There have been a variety of approaches to the workload over the years, but today those core workloads include Excel Services/Excel Online, PerformancePoint, SQL Server Reporting Services Integrated Mode, and Power Pivot for SharePoint.

Power Pivot for SharePoint and Excel Services go hand in hand and can really be considered as one of the main pillars, leaving us with three. If we quickly examine these three pillars in SharePoint 2016, it’s pretty easy to spot an emerging trend. Excel Services is gone from SharePoint 2016, its capabilities being added to Excel Online. Excel Online connects to, but does not run on SharePoint. PerformancePoint still exists in 2016, but it has received precisely 0 new features – it is identical to the version in SharePoint 2013, and remains a part of product for legacy reasons. For all intents and purposes, I consider PerformancePoint to be deprecated. SSRS Integrated mode has been greatly improved in 2016, but contains nowhere near the improvements that the Native Mode version of SSRS has in 2016.

At the same time, the past year has witnessed the spectacular rise of Power BI. Power BI is clearly the focus area for Business Intelligence within Microsoft for cloud based BI delivery. Last fall the SQL team announced that on-premises customers were not being ignored, and that SSRS was the platform for on premises BI delivery They also sketched out a roadmap that showed both platforms being able to deliver the same type of reports. In June 2016, the team delivered on a portion of this vision with SQL Server 2016 Reporting Service.

So where does this leave SharePoint in the Business Intelligence ecosystem?

In my opinion, it leaves it right where it should be – as an integrating platform, and NOT as a runtime platform as it has been in the past. SharePoint provides in context BI by connecting content to reports, and providing dashboards connected to multiple sources. In 2016, SharePoint connects to Excel Online to deliver Analytical reports. Excel runs with SharePoint now, not on it. SSRS Integrated mode still runs on SharePoint, but the investments in Native mode are a clear indication to me that this will be the direction here as well. Unfortunately, Sharepoint has been lacking tight integration with Power BI.

The recent Ignite 2016 conference was the first public appearance of the Power BI web part.

Figure 1: Insert web part dialog with Power BI web part

The Power BI web part works with Modern Sharepoint pages and is based on the new SharePoint Framework (SPFx), which means that it is completely client-side. Why does this matter to us? The fact that it is completely client side means that it will work both in SharePoint Online and on premises. Initially, it will only work with SharePoint Online, but that is because the SharePoint Framework is currently unavailable on premises.

To use the new web part, first create or edit a Modern SharePoint page. The Modern pages support the new Modern web parts. Click on a “+” icon to open the insert part control (Figure 1). Once inserted, add the report URL, and the page. The report page should immediately render within the context of the SharePoint page.

Figure 2: Power BI Report page rendered within a SharePoint page

Since the web part is rendering client side, the consuming user obviously needs to have access to the report. This means that the source report must have been shared with them through Power BI dashboard sharing, or the report is in a group within which the consuming user is a member. This latter case makes the most sense given that all Office 365 Groups will have a corresponding Modern Team site. Embedding the report within group pages should “just work”.

The devil is of course in the details, and all of these details are not yet available, but Given the number of questions that I have received over the past year about Sharepoint/Power BI integration, I expect that its existence will come as welcome news. Over time I would expect to see it picking up support for parameters and the ability to work with individual report items (this is speculation, but it makes sense). It’s also not much of a stretch to see how SSRS could make available a Modern web part that worked in the same fashion with on premises SSRSs. That web part could conceivably work both on premises an Online, bringing SSRS to SharePoint Online for the first time.

SharePoint is still very much a platform for integration and for Business Intelligence content delivery. SSRS and Power BI will be the de facto reporting engines for on-premises and the cloud respectively, and Sharepoint will be the dashboarding/integrating platform for both environments.

15 Comments