This week, I was talking to two customers about their business intelligence needs. We spoke about reporting services, Power View, Microsoft SQL 2012, and SharePoint-related components. As the conversation turned to existing dashboards and potential migration to SharePoint 2013, both customers—independently, states apart—reported to me they heard about a demise of PerformancePoint in SharePoint 2013.

I could have titled this article with the famous Mark Twain reference, but instead found it more appropriate to use Monty Python. The reason (besides my sense of humor) is in the perception that PerformancePoint is dead. It may be slimmed down, and the planning component died a few years ago, but Microsoft did not kill this product.

Microsoft has listened to the feedback regarding this product over the last five years and has addressed one of THE biggest pain points in PerformancePoint. Toward the end of my article, I will delve into this.

PerformancePoint lives because it addresses a true business pain. The tool is used in the evaluation of data from your data warehouse and a myriad of disparate data sources. With this tool, you can then mold data via Key Performance Indicators (KPIs) and create revealing interactive dashboards.

The biggest obstacle to PerformancePoint is PerformancePoint itself. Installing it and configuring it is not overly complex. The complexity is in the use of the tool. I like to compare it to writing a dissertation: Everyone knows how to take a pen to paper, but the enormity of the task is daunting.

The very first task you must confront is how to get at your data stored in a SQL Server Analysis Services (SSAS) data warehouse (commonly referred to as a cube). But it’s not just about getting to the data, it’s about pulling only the data you are allowed to see. To add one more requirement, users do not want to have to authenticate (again) when reaching the cube since they already authenticated once by logging into their machines. This is what is commonly referred to as the double-hop problem.

How does any company allow this data retrieval with single authentication? This is done in one of the following ways:
1. By Proxy Account, otherwise known as the Unattended Service Account. The proxy account obtains the data in SQL on your behalf
2. By Proxy Account with the user’s login details in a connection string.
3. Via Kerberos, per user identity

The first method is not granular enough to filter the cube by user. The second method is done by using a CustomData() function. Unfortunately, this is a security concern since it is possible to change the CustomData component.

The third method—Kerberos—solves the issue. Kerberos handles the use case where credentials must be passed over a hop. In our case above, the user’s credentials would be passed to the cube, so now the user would be known.

By far, the biggest pain point in dealing with PerformancePoint is that customers will not install Kerberos due to the complexity of its setup. Enter EffectiveUserName via SharePoint 2013 PerformancePoint. This is a setting on the PerformancePoint service application setting page that the administrator may check. What this does is add the EffectiveUserName property to the connection string that is passed to the cube.

When setting up your data source, you must choose Per-User Identity. This will pass the value of the username of the SharePoint user making the call. This property also works with Excel Services (but not PowerPivot data sources).

This is a huge win for those of us dealing in the Microsoft business intelligence world. PerformancePoint is alive and well and now just a bit easier to sell to customers.

While this is not the Holy Grail, I daresay PerformancePoint is getting better. Take it for a walk.

Peter Serzo is a published author of “The SharePoint 2010 Administration Cookbook,” a founder of the SouthEastern SharePoint group, a speaker, and SharePoint architect for High Monkey Consulting.