PowerPivotGeek » Management Dashboard

Bug: Management Dashboard .odc file is broken

powerpivotgeek — Mon, 26 Apr 2010 17:28:00 +0000

OK, here is our first ‘bug’. As part of the PowerPivot Management Dashboard, we ship a .odc file that is used to point to the PowerPivot dashboard data workbook (the data you see in the dashboard reports). You can click on the .odc file and Excel desktop will popup pointing to the dashboard data. Unfortunately the file has a connect string property that you have to remove – i.e. the “;Embedded Data=False” at the end of the connect string.

To locate the file click on:

“All Site Content”, then
“PowerPivot Management” (under Document Libraries), then
a GUID subfolder (you should have one for each PowerPivot service application – normally there is only one)
You will see a series of subfolders with locales (1028-3082) and a “PowerPivot Management Data.xlsx” file. Click on your locale language (1033 is English (U.S.).
You will see a series of files which are the contents of this Reports web part. You want to edit the “PowerPivot Management Data.odc” file.

In the RTM bits, the .odc file contains an improper reference to a property on the connect string. Edit the file (I downloaded the file, edited it locally with Notepad and saved it back to the SharePoint document library with the name “PowerPivot Management (fixed).odc”) removing the “;Embedded Data=False” string:

Provider=MSOLAP.4;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=;Data Source=http://dwickert-rtm:55000/PowerPivot Management/6dac39ac-290a-4a2d-a41f-72a209ad01ce/PowerPivot Management Data.xlsx;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error;Edit Mode=0;Embedded Data=False

to:

Provider=MSOLAP.4;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=;Data Source=http://dwickert-rtm:55000/PowerPivot Management/6dac39ac-290a-4a2d-a41f-72a209ad01ce/PowerPivot Management Data.xlsx;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error;Edit Mode=0

(your server, ports, and service application guids will vary)

And now the .odc file works. Just click on the fixed .odc file. The net-net is that you just have to remove the “;Embedded Data=False” at the end of the connect string.

Enjoy!

Dashboard Bubble Chart Shows a Red X (fails to load)

powerpivotwahoo — Mon, 08 Feb 2010 23:39:24 +0000

If there is any error trying to load the bubble chart data for the dashboard, instead of getting a page load failure, the bubble chart simply displays a red X. Whenever you get a red X in the bubble chart there will be an associated log entry in the ULS log on the machine running the Central Admin site. It will look something like this:

SSAS Mid-Tier Service Administration 106 High Error loading history for workbook history bubble chart

SSAS Mid-Tier Service Administration 99 High EXCEPTION: Microsoft.AnalysisServices.AdomdClient.AdomdUnknownResponseException: Unsupported data format : application/vnd.ms-excel.12

at Microsoft.AnalysisServices.AdomdClient.HttpStream.GetResponseDataType()
at Microsoft.AnalysisServices.AdomdClient.CompressedStream.GetResponseDataType()
at Microsoft.AnalysisServices.AdomdClient.XmlaClient.EndRequest()
at Microsoft.AnalysisServices.AdomdClient.XmlaClient.SendMessage(Boolean endReceivalIfException, Boolean readSession, Boolean readNamespaceCompatibility)
at Microsoft.AnalysisServices.AdomdClient.XmlaClient.Discover(String requestType, String requestNamespace, ListDictionary properties, IDictionary restrictions, Boolean sendNamespacesCompatibility)
at Microsoft.AnalysisServices.AdomdClient.AdomdConnection.XmlaClientProvider.Microsoft.AnalysisServices.AdomdClient.AdomdConnection.IXmlaClientProviderEx.Discover(String requestType, IDictionary restrictions, InlineErrorHandlingType inlineErrorHandling, Boolean sendNamespaceCompatibility)
at Microsoft.AnalysisServices.AdomdClient.AdomdConnection.ReadDataSourceInfo()
at Microsoft.AnalysisServices.AdomdClient.AdomdConnection.ConnectToXMLA(Boolean createSession, Boolean isHTTP)
at Microsoft.AnalysisServices.AdomdClient.AdomdConnection.Open()
at Microsoft.AnalysisServices.SharePoint.Integration.WorkbookHistoryDataProvider.GetHistory(WorkbookHistoryDataSet& historyDataSet)
at Microsoft.AnalysisServices.SharePoint.Integration.WebServices.PowerPivotOperationsServiceImpl.GetWorkbookHistory(WorkbookHistoryDataSet& history)    1118bdcb-bf75-4f0d-b560-ede92ed25d1b

The key string that you are looking for is “Error loading history for workbook history bubble chart”. The exception causing the error should immediately follow that entry for logging on that thread and should hopefully give you some indication as to why the chart didn’t load (it is what I look at). In the majority of cases I have seen, the issue is simply not having the latest version of the ADOMD.Net client library and all you need to do is upgrade your version of the library to that of SQL Server 2008 R2 and the error will go away. Our code is actually meant to provide a user friendly error when SQL Server 2008 R2 Analaysis Services ADOMD.Net library is not installed on the server hosting SharePoint’s Central Administration site. However, as of the most recent RC build (and so most probably the RTM build), SharePoint is installing ADOMD.Net from an earlier version of SQL Server and so this user friendly error is not always coming through and users might simply get a red X. To know if that is what you are hitting, you can either look in the Control Panel’s Programs List and see if the SQL Server 2008 R2 Analysis Services ADOMD.Net library is installed (look for a version number of 10.50.XXXX.X … I don’t know what the final RTM version will be) or you can look in the ULS log. The above (cryptic) example is what you will see if you have an older version of Analysis Services ADOMD.Net client library installed on your machine. If you have installed PowerPivot for SharePoint on the same machine as Central Admin, then we will have automatically installed the latest bits of ADOMD.Net and so this would not be the root issue.

I am not sure what other errors would be “expected” misconfigurations, but as I(we) find them I will try to add them. HTH

Lee

How to manually update your PowerPivot Management Dashboard

powerpivotgeek — Tue, 19 Jan 2010 02:02:52 +0000

We have gotten lots of feedback about the new CTP3 PowerPivot Management Dashboard feature. Most folks are excited about the new reports and can see how the reports give you an unparalleled ability to ‘peek’ inside the running services. However the default “wait-a-day” update cycle can see a bit long. A day-long cycle period seems OK for long-term analysis of data, but for demoing the system and investigating how to use the capabilities work you might want a shorter cycle, or want the ability to refresh the data during the day. This post is all about how you do that.

First, you have to determine if the Usage file collection is long enough for you to wait. By default, it takes 30 minutes for your actual usage of the system (clicking here; clicking there) actually end up in a Usage file. If you can wait 30 minutes, then leave the system as it is. If you need usage information sooner, then you will need to tweak two settings:

As a property of the PowerPivot service application (there is a link to the service application(s) on the Dashboard page, top right corner), is the Query Reporting Interval. Its default value is 300 (every 5 minutes). This means that every 5 minutes the PowerPivot system service writes using information to the SharePoint Usage subsystem. If you want the interval smaller you can reduce it to every couple of seconds, but this means that there will be more information kept in PowerPivot database. You might reduce it to every 10 seconds if you want to see the data as soon as possible.

For the Usage file itself, there is as a property of the SharePoint Usage collection service which every 30 minutes (by default) the events are flushed to a new file. To modify the collection interval so data is flushed to a new file more often: Open “SharePoint 2010 Management Shell” and run this command (in administrator mode, from an SP farm administrator account) which reduces the interval down to every minute:

Set-SPUsageService –UsageLogCutTime 1

Now that the data is being logged into the Usage files(you can see these in the ULS folder), all you have to do is to manually run 3 timer jobs to get the data from the Usage files to the reporting database. To run a timer job manually, click on it and then click on “Run Now” button at the bottom of the page. Run these timer jobs in the following sequence: (Important: you must run these in this sequence!)

SharePoint Usage Data Import (this is run every 30 minutes by default) – this timer job moves the Usage data from the Usage files to the centralized SharePoint Usage collection database.
SharePoint Usage Data Processing (this is run daily by default) – this timer job moves the Usage collection database to the PowerPivot database associated with the service application.
Microsoft PowerPivot Dashboard Processing (this is run daily by default) – this timer job actually processes the Management Dashboard workbook that holds the data for reporting. The reports and charts are built from this workbook.

As a “geek’ish” implementation note, the workbook itself is kept in a document library in the Central Administration web application:

There is a subfolder for each of the localized languages that PowerPivot supports (which is where the reports themselves are kept).

So . . . after all of this.

Now you can refresh the Dashboard page and you will see updated data/reports!
Again, if you can live with the 30 minute delay, then all you need to do is run those 3 timer jobs in the sequence specified and you can refresh the page.
All is golden!

Enjoy.

_-_-_ Dave