1. Round-robin (the default) – This algorithm selects first one app server; then the next; then the next; until it loops back around. Since the actual marker for what is “the next” is kept in the proxy for the PowerPivot service application, the net-effect of this in practice is that the selection looks different from what you would expect. The behavior is a lot closer to random rather than sequential. Being random, and with a low number of servers to pick from (for example, 2), you should naturally expect that one app server might seem to be biased. Add more servers and you will see less bias.
2. Health-based – This is the one that most large shops will likely choose. The idea behind health-based is that the system will decide which is the ‘best’ app server for a machine. So when the allocation appears bias, it seems like health-based isn’t working. In reality, health-based may be doing exactly what was intended. If all machines have memory available (i.e. none of them are under memory pressure), then health-based uses CPU to break any ties, i.e. which ever CPU has the most CPU free wins. Let’s take an example:Suppose you have two machines “A” and “B”. Both are running PowerPivot. They both have 32GB on them with four quad-core processors. Rather than being dedicated to PowerPivot, “A” also doubles as the backend app server for Excel Services. Likewise, “B” doubles as the backend app server for PerformancePoint Services. So long as Excel Services and PerformancePoint consume similar CPU time, then databases will be loaded back and forth between “A” and “B” as one is more lightly loaded than the other. However, if PerformancePoint is lightly used and “B” is consistently less loaded (CPU-wise), then you will see PowerPivot databases being allocated to “B” until it becomes under memory pressure, and then allocation will shift to “A”.

All-in-all, health-based is still the best algorithm for large shops. Remember that the PowerPivot engine is an in-memory system. Our first goal is to get databases allocated wherever memory is available – balancing across the farm is not a priority.

Enjoy.

1. The result set must have a name associated with each column. If you are not returning the column name, then you must assign an SQL alias to the column. Some query tools allow you to work with ordinal numbers for the columns; some query tools assign a name based on the ordinal (e.g. COLUMN_42); some query tools use a combination of the two. The add-in (and the SSAS engine) does not not – it directly binds to the column name.
2. You cannot have duplicate column names. Each column name must be unique.
3. You cannot return multiple rowsets. The client add-in only deals with a single rowset. Some tools allow you to return multiple rowsets but only deal with first one; or the last one. In the client add-in, you must have only a single return rowset. If you are entering queries via SQL then this is typically not a problem – but it has serious complications if you are using stored procedures. If you don’t use “SET NOCOUNT ON” at the beginning of your stored procedure, then a rowset is returned for each SELECT expression, even if that expression is just setting a variable. Thus you must have a “SET NOCOUNT NO” at the start of your stored procedure or the stored procedures are likely to fail with the client add-in.

I am just sharing the love here . . . the end result is that you might not be able to use all of your existing queries and stored procedures with the PowerPivot Excel client add-in. Being for-warned is for-armed.

And “Oh…” another possibility issue that you might run into is support for variant datatype. The rowset previewer can handle variant data — but the Engine cannot.

Enjoy.

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.

The implications of this is when creating a SharePoint web application, you must ensure that you select the ‘classic-mode’ for the web application authentication:

If you select “claims-based’ then SharePoint will pop up the forms-based authentication dialog box when a client application that does not expose the user’s claims identity to SharePoint. SharePoint pops up the dialog box even if Windows is the authentication provider. The idea is that if the user is a Windows user, then they type their Windows user name and password into the FBA login dialog box. This is all well and cool – except for our front-end web service – it needs the Windows identity to continue. For backend web services such as the PSS (PowerPivot System Service) and the channel transport used by ECS (and others) to route requests to the PSS – they run perfectly fine. The claims identity flows with their WCF calls. This issue is between the client and the web application – how is the user’s identity established right at the front-door?

If you select ‘classic’ and you are coming in the front-door then the SharePoint infrastructure uses standard IIS capabilities to get the user’s identity and then translate that identity into a claims token. For our front-end web service, this means that the user’s Windows identity is moved up from the client to the IIS server, or IIS uses basic authentication, or some other IIS mapping is done to get to the Windows user.

Claims-based on the other hand tells the SharePoint infrastructure that the client will provide the claims identity directly. If it does not, then the SharePoint system has no option other than to ask the user to provide them which it does so by popping up the FBA login dialog box. But some systems, like our front-end web service, cannot respond to the login properly. If you select ‘claims-based’, then the PowerPivot front-end web service will return a ‘Too many automatic redirections were attempted. (System)’ error. Why is that? The issue is that since our service needs the user’s identity, the FBA dialog box will try to be rendered to try and get the user’s credentails. The FBA fails and our code asks for the user’s identity, then FBA fails, and the system keeps repeating until the ‘too many redirects’ error is returned.

One of my favorite jokes is “A man walks into a doctor’s office. He says ‘Doctor, doctor, my arm hurts when I move it like this!’ The doctor replies ‘Then don’t move it like that’ “ — Well . . . maybe it isn’t too funny, but gosh it applies in lots of places. And one of those places is here. To re-phrase: “Doctor, Doctor, my PowerPivot web application tells me that it has too many redirects” – the doctor replies “Then don’t do that – set it for classic mode.” Any funnier now?

Enjoy.

1. Click on Start and type “gpedit.msc” into the Start Search box
2. Navigate to “Computer Configuration – Windows Settings – Security Settings – Local Policies – User rights Assignment”
3. Click on “Allow log on through Terminal Services”
4. You will notice that only Administrators are listed. Add “Remote Desktop Users”

Here is a screen shot:

Enjoy!

“Diagnostic Guide for Usage and the PowerPivot Management Dashboard” by Ankur Goyal
http://powerpivotgeek.com/troubleshooting/diagnostic-guide-for-usage-and-the-powerpivot-management-dashboard/

Enjoy!

_-_-_ Dave

In the %ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log you will see a list of folders with Date-like names. Search inside them for a file called detail.txt (easiest way is probably “dir /s /b detail.txt”). You want to go to the most recent directory with this file and open up this file and search for the string ”Running Action: ASSPI_Install_ASSPIInstallStartupFinalize”. This is the beginning of the section in which we do our configuration of SharePoint with Analysis Services. I will admit that the logging has not been “scrubbed” so grammatical errors might abound, however you should be able to glean some potentially useful information from it. I tend to look for exceptions with stacks. Even if you can’t figure out what the error means, it will be useful to include in any “help” postings and might get you faster turnaround.

Please make sure, even if you figure out what is happening and are able to “workaround” it, that you report any issues so that we can continue to improve the experience.

Thanks
Lee

Thanks.