PowerPivotGeek » Bug

Health rule error reports: “PowerPivot: The deployed farm solution is not up-to-date.”

powerpivotgeek — Mon, 25 Oct 2010 03:57:29 +0000

I recently ran into this in scanning through some forum problem reports. Typically this health rule violation is reported on a large farm installation. The health rule reports the app servers that do not have PowerPivot installed on them as being out of date. Can you read “bug?” Yes, this is one. You can either safely ignore the error report or you can disable the health rule. The problem is solved in CU3.

As always, sorry for the inconvenience. We should have done a better job in our error reporting.

_-_-_ Dave

Installation error: “System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances.”

powerpivotgeek — Mon, 25 Oct 2010 03:48:17 +0000

Occasionally I’ve ran into this problem as part of a SharePoint installation. Typically this is with Excel Services – but since Excel Services is so central to the PowerPivot architecture, we run into this too. The ULS shows something like:

Medium             ExcelServiceBase.BeginProcessOperation: Caught an exception: System.TypeInitializationException: The type initializer for ‘Microsoft.Office.Excel.Server.CalculationServer.ExcelServerApp’ threw an exception. —> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0×80131401)     at Microsoft.Office.Server.Diagnostics.ULS.SendWatsonOnExceptionTag(UInt32 tagID, ULSCatBase categoryID, String output, Boolean fRethrowException, TryBlock tryBlock, CatchBlock catchBlock, FinallyBlock finallyBlock)     at Microsoft.Office.Excel.Server.CalculationServer.ExcelServerApp..ctor()     at Microsoft.Office.Excel.Server.CalculationServer.ExcelServerApp..cctor()     — End of inner exception stack trace —     at Microsoft.O…       555ec6e6-4a53-49cf-8cb7-4b8614a8fa21
10/14/2010 11:56:42.20*            w3wp.exe (0×1E38)                                     0×25B8              Excel Services Application           Excel Calculation Services            ecd1              Medium                …ffice.Excel.Server.CalculationServer.ExcelServiceBase.SafeSetContext()     at Microsoft.Office.Excel.Server.CalculationServer.ExcelServiceBase.BeginProcessOperation(CommandParameter parameter, WebMethodBehaviorAttribute webMethodBehavior, WebMethodType webMethodType, AsyncCallback callback, Object state, UserOperation operation)          555ec6e6-4a53-49cf-8cb7-4b8614a8fa21
10/14/2010 11:56:42.20              w3wp.exe (0×1E38)                                     0×25B8              Excel Services Application           Excel Calculation Services            d64g              Medium             UserOperation.Dispose: Disposing Microsoft.Office.Excel.Server.CalculationServer.Operations.EmptyOperation, WebMethod: . 555ec6e6-4a53-49cf-8cb7-4b8614a8fa21

Solution: Reboot

What I believe is happening is that as part of the installation process, an object is being registered in a different app domain (if you follow the long convoluted threads on this topic from the web). On a reboot this is cleared up. I’ve never been able to discover the circumstance root cause – but always a reboot has solved it.

Enjoy!

_-_-_ Dave

A Peek Inside: Getting the most from data refresh

powerpivotgeek — Wed, 08 Sep 2010 19:30:26 +0000

Recently there was a forum post concerning how PowerPivot parallelizes data refresh . . and I thought this might be an interesting topic for a “Peek Inside” blog posting. The first question is: Why are we doing this? What is the purpose of parallelizing data refresh? Why is this so important? Well . . there are two reasons. The first reason is that we want to get the maximum throughput from all of the compute resources that we have in the farm. We paid a lot for the servers and we want to keep them busy. However, secondly, particularly as users start deploying more and more workbooks, the number of jobs will increase as well. We expect that the automatic refresh capabilities of the PowerPivot system will be a popular feature. Information workers like to keep their workbooks up-to-date – and data refresh is a powerful new feature of PowerPivot. For a large farm with tens of thousands of Excel workbooks, there might be thousands of PowerPivot embedded data workbooks (10:1). And of these there might be hundreds of workbooks that need nightly data refresh (again, using a 10:1 ratio). If we did the data refresh one-by-one and each one took 10 minutes, this means it would take almost 10 to 20 hours to refresh them all. Obviously we need to perform many of them at the same time to fit within a reasonable nightly window.

As the steps that we do to accomplish this ‘parallelization’ isn’t talked too much in the regular BOL (there is a bit, but mostly around the setting dialog boxes), I thought that it would make a good blog posting.

First, let’s start off with the basic PowerPivot overall architecture: (I will let other postings cover the details; here is a basic overview)

PowerPivot for SharePoint has two shared services: one service called the PowerPivot System service is responsible for all back-end PowerPivot work (except the Engine itself); and we have a second shared service that is (you guessed it), the SSAS Engine itself. The Engine service is the regular SSAS Windows service wrapped as a SharePoint shared service. It is set to Vertipaq mode and is ready for loading, querying and processing of embedded PowerPivot datasets that are part of your Excel workbooks. When you install PowerPivot you get both services installed on the SharePoint app server. Across the SharePoint farm, you have “x’” pairs of services (i.e. where you have installed PowerPivot for SharePoint). This might be all app servers in the farm; one app server in the farm; or anywhere in-between. As an administrator you get to decide which app servers will be providing PowerPivot services.
Associated with the PowerPivot System service is a service application database. There is one service application database per PowerPivot System service application. Here is how you find out which RDBMS is created:

The service application database holds:

The ‘instance map’ which tells the system which app server has a given workbook’s data is loaded, or cached
The data refresh schedules that have been created by end-users. It also contains the ‘run queue’ for those data refresh jobs that are now runable, or being ran.
Lastly, the service application database contains data refresh history, i.e. when jobs ran and their status (success, failure, or informational messages).

There is no “Master” PowerPivot app server. All of our code assumes that each PowerPivot app server is independent and is always looking for work. When a data refresh job is put into the run queue, any of the PowerPivot machines can pick up the work and assign it to themselves. Where we need to control concurrency (since each service instance is independent of each other), we use locking capabilities of the SQL RDBMS for the service application database, e.g. we place write-locks on the run queue table to ensure that no other server attempts to update the run queue at the same time.

To configure data refresh jobs, there are two Engine service instance properties. To see these settings, run Central Administration and click on the SSAS Engine service instance. In this case, here is a server in my office at Microsoft. I went to Central Admin “Services on Server” for the machine DWICKERT-RTM and clicked on the “SQL Server Analysis Services” service at the bottom:

And here are the data refresh settings for the SSAS Engine service instance on DWICKERT-RTM:

The first checkbox tells the system that DWICKERT-RTM can be used for querying, i.e. loading read-only databases on the machine. If the checkbox was not enabled (unckecked), then this machine would have been dedicated to data refresh. The second checkbox is a similar setting for data refresh. If neither is enabled, then the instance will not be used. It is installed and configured, but it won’t be used. The default setting is that both options are enabled, i.e. that a server can be used for both querying and data refresh – but if you want to change it and dedicate the server for one or the other activity, here is where you set the role.

If you have enabled data refresh on this machine then you get to decide how many workbooks can be concurrently refreshing at the same time. We call these data refresh units of work a slot. In the case above we have enabled 4 slots on DWICKERT-RTM. The default setting is the amount of memory divided by 4GB (thus a 16GB machine should result in default setting of 4 concurrent jobs) – although there is a current bug in the system where the setting is always set to 1 regardless of how large the server memory is. The maximum value is the number of CPUs. To get the most use from your machine resources, I strongly recommend that you set the maximum concurrency if the machine is dedicated to data refresh. If you are running on a quad core machine, then the maximum number is 4. The way the system is designed is a bit complication. The UI allows you to enter any value you wish for this dialog box (e.g. you could enter 100 instead of 4 if you wished), but when the system goes to actually run the data refresh jobs, it will generate errors if the maximum concurrent jobs is larger than the number of cores on the machine. While this is not the best behavior, we would have like to stop you from entering a wrong number in the dialog box right up front, but given the fact that it is difficult to monitor remote machines, this was the most effective approach.

So . . . now we have things running, we are all done, Right?? Well as it turns out, No. The one remaining thing to talk about is how a data refresh job gets ‘kicked off’ to begin with. The “kicker” is the PowerPivot Data Refresh Timer job: (again, running Central Admin, PowerPivot Management Dashboard, here it is:)

As you can see, the timer job runs once a minute. This means that the timer job calls into the PowerPivot System service (on each machine where data refresh is enabled) giving it a ‘kick’ to take a look at its scheduled jobs every minute. The PowerPivot System service looks to see if any of the scheduled jobs is now ‘runable’ and if so, the job is placed in the run queue. At the end of each timer job (i.e. each minute), the PowerPivot System service looks to see if there are any runable jobs waiting, and if there are any ‘slots’ available for this machine. If so, the PowerPivot System service starts the refresh process.

All SharePoint interactions, i.e. reading the workbook from the SharePoint content database, saving the file back to the content database, are done in the same calling thread from the RPC call from the timer job into the PowerPivot System service, but when the job is ready to actually do the SSAS processing (where the Engine goes out and refreshes the cube data from the original data sources), then that work is requested in parallel on separate threads within the PowerPivot System service (one thread per ‘slot’). Remember that the actual processing is done by the local Engine service. Remember that in PowerPivot for SharePoint, the PowerPivot System service and the local SSAS Engine instance are always installed and operate as pairs. The PowerPivot System service acts as a ‘gatekeeper’ for the local Engine service. We never have the situation where the data refresh is done by a PowerPivot System service, but executed on a remote Engine service. The local Engine is all that PowerPivot System service knows (or cares) about.

So, like many things in PowerPivot, while data refresh seems simple and straightforward, there is actually a fair amount of technology underneath.

I hoped you enjoyed the geeky tour.

Enjoy!

“Unsupported features” warning message from Excel Services

powerpivotgeek — Sat, 22 May 2010 00:03:00 +0000

(Thanks to Ankur Goyal, one of the PowerPivot mid-tier testers, for this detailed write-up)

You might have noticed that Excel Services sometimes complains about how the PowerPivot workbook is organized. It reports an warning error like this one::

In this posting, I’ll talk about why these rectangles exist (i.e. what they do) and how you can have this error come up – along with a fix for how to stop them.

Let’s start with the fix – and then I’ll explain how this error arises and how the fix works.

1. Open the workbook in PowerPivot client and click on the any Pivot chart in the workbook and click on Selection Pane from the Format menu.

2. You will see a new pane “Selection and Visibility” right next to Field List. . In the pane I selected objects with name “Rectangle…” and deleted them. In the selection pane you see all shapes on the sheet: charts, slicers, rectangle shapes etc. You need to delete all rectangle shapes in order to get rid of the warning. Sometimes when you delete rectangle shape new one gets created, you can leave these new shapes alone. When you save workbook, they will be removed by our add-in. In CTP3 we used to create rectangle shapes with name O…, in the RTM build they have default name “Rectangle …”.

3. Save your workbook and upload it back to SharePoint. Clear your browser cache and you will notice that the warning message is gone. Don’t worry if rectangles come back after you delete them. This is expected behavior (because of the way that the add-in works – it always needs the rectangles to be there – our goal here is to delete the old ones.

———————————————————————————————————

Ok. The fix is done. Now let’s get our geek hats on and talk about what is happening and why.

First, what is the purpose of these rectangle areas? You will notice that each rectangle area surrounds a slicer area. The PowerPivot addin uses these rectangles to auto-position the slicers. When the add-in starts up, it create a rectangle for each slicer area. When Excel closes, the add-in removes the rectangles that it added. The add-in won’t touch other rectangles – it just deletes the ones that were added. Thus the normal condition is that the workbook with embedded PowerPivot data does not have rectangles in it.

This is good because Excel Services does not support rectangles. In fact it does not support any ‘shapes’ in the workbook. If they appear, then an error message is generated. This is the famous “Unsupported feature in workbook” error message.

Things are all well and good – The PowerPivot add-in does its thing – and Excel Services does its thing –> all is great.

Now along comes a bug in the PowerPivot add-in. There is a sequence of steps (in fact, a commonly used sequence of steps) that can cause the add-in to not remove the rectangles. And once they are in the workbook, there is no automatic way to remove them. You have to use the fix above to remove them manually.

So, Dave, don’t hold us in suspense any longer! What’s the root cause?

(do you know you know how many PowerPivot developers it takes to screw in a light bulb?)

Ok, Sorry.

The bug is that if you hit Close in Excel with a dirty workbook, then when the data is saved to the workbook, but the rectangles are not removed (it is caused by a weird way that the Excel OM raises events). If you hit Save and then Close things are OK. So whether or not you get into this situation is not related to if you save or not – but rather it is HOW you save.

Always Save and then Close – never just Close Excel.

Enjoy.

SharePoint Timer Service error

powerpivotgeek — Thu, 13 May 2010 05:06:28 +0000

In another one of those “oh heck, I just spent a couple hours of my life chasing my tail” and in an effort to ‘prepare everyone for RTM’, you might notice the following error pop up from time to time.

And in the NT Event Log you might seen entries like:

An unhandled exception occurred and the process was terminated.

Application ID: DefaultDomain
Process ID: 1852
Exception: System.Security.Cryptography.CryptographicException

Message: Keyset does not exist

StackTrace:    at System.Security.Cryptography.CryptographicException.ThrowCryptogaphicException(Int32 hr)
   at System.Security.Cryptography.SafeProvHandle._FreeCSP(IntPtr pProvCtx)
   at System.Security.Cryptography.SafeProvHandle.ReleaseHandle()
   at System.Runtime.InteropServices.SafeHandle.InternalFinalize()
   at System.Runtime.InteropServices.SafeHandle.Dispose(Boolean disposing)
   at System.Runtime.InteropServices.SafeHandle.Finalize()

There is a known problem with SharePoint RTM. The warning happens whenever the SharePoint Timer Service OWSTIMER.EXE recycles, typically every 24 hours, but it’s just a warning and can be safely ignored. The underlying exception happens on all systems but is only noticeable with the development tools installed since it causes the JIT debugger to fire. The underlying issue is being caused by the GC and has no bad impact unless you have a debugger installed which will trigger the popup.

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!