PowerPivotGeek » Architecture

A Peek Inside: Why are domain accounts needed?

powerpivotgeek — Thu, 19 Nov 2009 04:39:40 +0000

Have you ever had to do something that you knew (you just KNEW) that lots of folks were going to scream – and scream loud – about? This is one of those cases – I can just feel it!

Ok, here goes. There have been several recent newsgroups postings concerning why we require domain accounts to install PowerPivot for SharePoint. Why must the farm account and the various service accounts be domain accounts. This causes lots of heartache for users that want to install demo or evaluation servers because we don’t support a standalone server. Well, we do support standalone, but it a different kind of standalone. Let’s get right into it.

First, let’s compare and contrast this requirement with SharePoint. SharePoint has two types of installations: standalone (which they do NOT support in production) and complete/farm. The standalone installation is for demo and evaluation purposes only. It has uses NETWORK SERVICE as the service account for many of its internal processes. It is right up front that it is NOT expandable into a production system; it has security issues acting across servers; etc. However, it gives you a nice “toy” to play with. Let’s be right up front about it – PowerPivot does not install nor does it support a SharePoint standalone server installation. And, oh while we are on the subject, SharePoint does not support local machine accounts within a farm configuration. In the SharePoint world, once you go to domains – you go all of the way with domains.

PowerPivot’s philosophy for the NEW FARM case is that it is a complete farm that just happens right now to be on a single machine. We take a production-view of the single server. We would expect that it would natural that at some time in the future that the SharePoint administrator would move the content and config databases off of this server and put them on their own dedicated SQL Server machine. After all, this is a best practice for SharePoint to have a dedicated (or consolidated) SQL resource off of the WFE and App Servers. And just as the RDBMS traffic is very likely to grow beyond a single combined “all-in-one” server; so would the app server requirements continue to grow and it is perfectly natural for a second, third or more app server to be added to the farm; likewise as the server becomes more main stream, there is a high-availability requirement that will become more important and multiple WFEs will be come important.

The bottom like is that proper capacity planning begins with your first installation. And thus we require domain accounts right from the very beginning.

Yes, this does impact those folks who are doing demos and evaluation. You have two options: (1) install a domain controller on your image and thus local accounts are domain account; or (2) install the server into a domain and possibly then disconnect from it (see an earlier posting from me on this topic). Approach #1 is what most users do. If you look at all of the “All-Up” VMs that Microsoft produces for other products, you will see that a self-contained domain within the VM is the way that most folks go. I personally use technique #2 because I do demos in a very constrained environment and having to modify the workbooks that I am demoing with is fine.

< OK – Let the screaming begin >

A Peek Inside: The client architecture

powerpivotgeek — Wed, 11 Nov 2009 08:15:00 +0000

Well, I have a fun one today. We get asked all of the time about how the PowerPivot add-in works. Particularly how it relates to the SSAS components that BI Pros are used to, e.g. making connections to SSAS. As I am getting ready to write an architecture overview blog posting for the PowerPivot team blog, I decided to take the client architecture out for a spin and attempt a more detailed drilldown here . . .

Here is a block diagram of the PowerPivot client component architecture:

As this is a geek discussion, I will spend a bit more time on how some of these components are implemented. As most of these components (with the exception of the ‘transports’ in the msolap OLEDB provider) are likely already known to you geek’ie SSAS pros, I will just make a few observations:

Notice how the addin interfaces with the VertiPaq engine – it uses AMO and ADOMD.NET. This is one of the most powerful aspects of PowerPivot. While we expose a tabular interface to end users, the underlying model is multidimensional. It is based on the UDM and well-known and established SSAS interfaces. We use AMO and ADOMD.NET (and their resulting languages, MDX and XMLA) as the components to implement the multidimensional objects.
As the addin is written exclusively in C#, we use the managed libraries to interface with the VertiPaq engine. Excel itself is still native code, so when Excel pivot tables want to ‘speak’ to PowerPivot, they use the msolap OLEDB provider.
Inside the msolap OLEDB provider are four transports. A transport is a module that provides the physical channel used for sending messages back and forth to the server. In the case of the client addin, there are three possible transports:
1. TCP/IP – this is used for normal client-server connections. In this case, the SERVER= is used in the connection string.
2. HTTP – this is used for http access, e.g. using the data pump in SSAS, or making a connection to the PowerPivot for SharePoint PWS component (PowerPivot Web Service) – more on the PWS in the full architecture blog posting coming next week. For the data pump, the connection string is SERVER=http://server/virtual_directory/msmdpump.dll. For the PWS, the connection string is: SERVER=http://sharepoint_server/webapp/site/subsite/doclib/file.xlsx
3. INPROC – this is the transport that is being used here to make a connection to the in-memory VertiPaq engine. The key that indicates that this is an in-proc connection is the SERVER=$EMBEDDED$ or DATA SOURCE=$EMBEDDED$ value.
4. There is a fourth transport, called the CHANNEL transport, but it is used on the SharePoint farm to route requests directly to the PowerPivot System Service (PSS) – so I will put off a detailed discussion of it until we talk about the midtier architecture (likely next week).
AMO and ADOMD.NET have a similar transport mechanism inside the http client, but it is much more straightforward as it is written in managed code and has a less complexity as the msolap provider does.
Notice that the entire component stack is in-proc within the Excel process – Excel, the msolap provider, AMO, ADOMD.NET, and even the VertiPaq engine are all together. Can you spell 64-bit?
Not to point out the obvious, but a downside to this approach is that we have no process little separation between the components, i.e. a VertiPaq crash is also an Excel crash and the reverse. We are all one happy or unhappy family (together).
As a dev team – and a supportability champion – the beauty of this architecture is that we were able to get a ton of reuse from the existing SSAS infrastructure (for example, the client libraries, and the in-proc code path is similar to SSAS local cubes).
The transport mechanism makes it transparent to the pivot table how the actual messages flow – everything is driven by the format of the SERVER= (or DATA SOURCE=) parameter on the connection string. So, in a way, the user does control the message flow – because he or she is the source for where the SERVER= parameter points to.

So, I hope you enjoyed the slight detour in to the client ‘realm’, I hope to get back to the midtier and the server soon but then it was fun. So maybe I will stay here for a while. You never know . . .

Way cool SharePoint topologies poster

powerpivotgeek — Sat, 07 Nov 2009 01:20:03 +0000

Now this is a cool poster. SharePoint 2010 has a new shared services architecture that PowerPivot uses extensively. We have written both a new web services service and a Windows service wrapper around the SSAS msmdsrv.exe. I thought you might find it useful, or at least fun, to see how SharePoint is approaching the distributed systems problem. Here is a thumbnail of the poster:

And here is a link to the full thing – which is HUGE.

http://go.microsoft.com/fwlink/?LinkID=167089

Enjoy.