I have been doing some tinkering today with a demo I am preparing for a speaking session in a few weeks and have been working with PerformancePoint in SharePoint 2010.

Trying to show something simple, I was attempting to connect to a data source (a cube on a SQL Server instance running in an Azure Virtual Machine) from a SharePoint farm also running in an Azure VM.

I had no reason to expect this to fail but it just would not work as a direct connection with credentials being supplied that I knew were correct and valid.

Some judicious swerving around ULS logs (after cranking up the verbosity) indicated authentication failures which I was not expecting given the knowledge that the credentials were valid.

<head scratching>

Taking a slightly more “enterprise class” view of the connection I decided to run it through Secure Store (as of course we would in the real world) and without a blink it connected and worked quite happily letting me browse the cube happily to create my demo.

So what’s up then? Some persistent browsing of search results and skimming of documents helped me to find a reference in the “Planning guide for server farms and environments for Microsoft SharePoint Server 2010” (Bing it for the link!) section on “Planning considerations for services that access external data sources” that clearly states that:

“If the Secure Store Service is not used and external data sources do not reside within the same domain, authentication to the external data sources will fail.”

This is exactly the scenario I had encountered .


My SQL Server data source VM resides in a different domain to the SharePoint farm (it’s used in different non-SharePoint test/demo scenarios and does not form part of my “core” demo environment for SharePoint) thus causing the authentication to fail.

Annoying, but documented so no doubt “by design”.

Nuff said.

more to follow…