Surprised?  I was this week as well.  I have had a case open with Microsoft since October that we have been playing with back and forth trying to figure out why automated refreshing of a PowerPivot workbook wasn’t working.We let the case go off and on for a quite a while because in the opening days we found that if we ran the PowerPivot Service Application Pool in the context of the farm admin account, that manually refreshing the data would work.  Having a work around in hand threw this issue to the back of the queue for a while.

After much diagnosis, discussion, and many weeks of thinking that the Secure Store Service wasn’t working properly, along came a very simple explanation: PowerPivot requires Classic Mode Authentication.  FBA and Claims are not supported for doing data refresh or usage data collection scenarios.

The answer to our question came via 3 references:

PowerPivot Data Refresh – Everything you always wanted to know  – Page 14 is a good place to start.  Section called “Anatomy of PowerPivot Data Refresh” – written by Mariano Teixeira Neto

Plan PowerPivot Authentication and Authorization – “To support data refresh and usage data collection scenarios, PowerPivot for SharePoint requires Classic mode authentication. PowerPivot requires a Windows domain user to be the identity behind the SharePoint security token, which it will use to create a history of user activity and document ownership, and to connect to external data sources during data refresh.” – quoted from Technet

Why PowerPivot requires ‘classic-mode’ web applications – “The second one (i.e. ‘b’ above) is a bit trickier and it is the core issue for this blog entry. In PowerPivot, when connecting through our front-end web services (aka, the PowerPivot Web Service, or PWS in our architectural design) the underlying protocol is the same as the one that earlier versions of Analysis Services used for the ‘data pump’ feature (http://technet.microsoft.com/en-us/library/cc917711.aspx). That protocol does not know about claims – it relies on getting a Windows identity.” – quoted from Dave Wickert, aka PowerPivotGeek

One of the answers that we got regarding this is that PowerPivot is a part of SQL Server 2008 R2 and not a part of SharePoint 2010, so it wasn’t really a SharePoint authentication problem.  ((Does that sound right?))

We have gone back to Microsoft and are looking to see if this is something they are going to be able to fix so that Claims Based Authentication can truly be the end-all-be-all solution that we are all hoping that it can be, or if this is just one of many things that we are going to run into that aren’t yet supported in CBA mode.  For those keeping count we are now up to 2 major issues that have come back to CBA as the root cause, the other being the Site Directory issue (which we are still waiting to hear if they are going to accept our hotfix request or not… last update from the engineer was yesterday).

I have to give a ton of thanks to the MS TAM (Mike Mitchell) that I work with, the engineer (Jason Haak) who worked on this case with us, and the 2 guys who seem to be the experts in the world on PowerPivot, Dave Wickert and Lee Graber.  We spent so much time focused on the technology of the platform and how cool PowerPivot was to work with, that we forgot rule #1 (which they kindly reminded us of)… RTFM.