(This refers to MOSS 2010 and PPS V2)

Today I needed to make an internal PPS demo available via the internet, so some alternate access mapping within SharePoint was in order.

I added an AAM entry for my default web site, essentially converting http://foo into http://demoname.domain.com inside MOSS.

When I fired up the dashboard via http://demoname.domain.com, my analytical grids/charts, scorecards and filters worked correctly. However, the PPS reports which are based on SSRS RDLs living in an integrated-mode SSRS server were broken. I got “Internet Explorer cannot display the webpage” errors instead of my reports.

It appeared to me that PPS Services wasn’t “checking in” with MOSS AAM to see if it needed to “fix things up” when it came to SSRS reports.  To validate this hunch, I used Fiddler while launching the dashboard. All of the calls to render my charts and filters dutifully hit demoname.domain.com. However, I saw a lone call to “foo”. The URL was:

http://foo/ReportServer?http://foo/Report%2520Library/WWReach_ClickThroughRate.rdl&rs:Command=Render&rc:Toolbar=false&rc:Parameters=false&rc:DocMap=false&rc:Zoom=100&rs:Format=HTML4.0

Bingo! I also tested an SSRS report embedded directly into a MOSS Reporting Services Web Part. It worked fine, too.  Looks like a problem with PPS only.

And I’m actually dealing with two reports – one with parameters, one without. I went into PPS Dashboard Designer and updated the Report Server URL and Report URL property for both. For example:

http://foo/ReportServer became http://demoname.domain.com/ReportServer …and… 

http://foo/Report%20Library/ReportName.RDL  became  http://demoname.domain.com/Report%20Library/ReportName.RDL:

Each time I made the change, DD threw this error:

Unable to find report server specified by URL. Please verify that both Server URL and Report URL are correct.

So it looks like the Dashboard Designer isn’t attempting to be “AAM-aware”, either.

Anyway, I re-published both modified reports from Dashboard Designer and checked the dashboard again. The report which did not use parameters worked fine. However, the parameterized report (which accepts input from PPS filters) still failed, but with a new error:

Unable to get filter values from “Filter Name”. You do not have permissions to view this data.

Sigh.

Back in Dashboard Designer, I saw the problem: By plugging in http://demoname.domain.com instead of http://foo, I had essentially “zeroed out” the parameters for my report. The only way I could get the parameters for this report to populate correctly was if I pointed  to http://foo, which obviously wasn’t going to do me any good.

The solution:

When in doubt, try notepad.  First, I used Dashboard Designer to “re-point” the Report Server URL and Report URL values of the still broken report back to http://foo so I could get my parameters populated again. I saved my changes.

After that, I opened the DDWX file up in notepad. I did a search for the property names “ServerURL” and “ReportURL”.  When I found the entries for my “broken” report, I swapped in demoname.domain.com for foo in both places and saved once again.

After that, it was time to open up the DDWX one more time in Dashboard Designer. I used the Mark Differences command to verify that PPS “saw” a change between what was on the server and in DD, then I did a Save All.

Lo and behold, the dashboard now worked…both SSRS reports were happy.

The title says it all!

x86: http://www.microsoft.com/downloads/details.aspx?FamilyID=90c596a5-aca4-4ded-9072-facf834bc0c6&displaylang=en

x64: http://www.microsoft.com/downloads/details.aspx?FamilyID=3ad75ae5-d2cd-4953-87cf-5f74d79804c6&displaylang=en

docs: http://technet.microsoft.com/en-us/library/cc514367.aspx

I’m currently working on a project which leverages many PerformancePoint reports. The dashboards I’ve built use a fair number of analytic chart report objects on a single dashboard page  (at least 4, sometimes more).  When I ran many of these pages, Internet Explorer 7 generally pegged my CPU at 97%, and it was taking at least a minute for the page to render. Often, more than half of the report objects failed to render at all (“an unexpected error occured”).

I’m working in a single integrated environment (IE/SQL/SSRS/SSAS/PPS/MOSS all on one box), and I could tell that IE hogging up CPU wasn’t even allowing SSAS, SSRS, PPS and MOSS to do their work. While IE was sitting @ 97%, msmdsrv.exe or reportingservicesservice.exe might hit 2% CPU for a moment then drop back down to %0 when they usually used more CPU cycles.

Clueless and confused, I appealed to those smarter than I for help. Josh Unger, a PPS SDET at Microsoft suggested I try IE 8 on the image. I dutifully installed it, and whammo, problem solved.  My slowly running dashboards now rendered in no more than 15 seconds (and these were pages which included PAS and SSRS reports – the analytic charts returned within moments when they had been the problem children earlier).

I circled back and asked Josh exactly why life was so good in IE8, and he explained that IE 7 ( adhering to standards) only allows two concurrent connections, and therefore 2 AJAX requests made to the server at the same time. Perhaps that didn’t do a lot of good when I had 4, 6, 8, or more  AJAX controls on a page all wanting to do stuff? In IE 8, we can have up to 6 connections. 

I guess in my case getting more reports “working” on the server at the same time allowed them to begin returning more quickly. And once a report had returned, I suspect that the particular AJAX-based control that hosted it didn’t need any/as much CPU vs. having it sit there waiting for a connection to become available.

Thanks to Josh and thanks to IE8!

As a BI Technical Specialist at Microsoft, PPS is (was?) my bread and butter – It’s how I eat. So the changes to the Microsoft’s strategy around the product hit pretty close to home for me. (What? You don’t know what they are? Go here.)

And what do I think? I think it’s a smart move.

Why?

It’s easy for customers

By consolidating M & A into MOSS, we give customers the ability to create impressive, powerful scorecards and dashboards without the purchase of additional “stuff”.  Sure, if you’re running MOSS Standard, you’ll need to have an Enterprise CAL, but we’re not talking about a wholesale introduction of new products into your infrastructure.  The ability to install PPS as a MOSS shared service (in MOSS14) vs. running yet another setup.exe is good thing – BI is just “in the box” – it is part of your core infrastructure!

It’s good for most customers

Customers I talk to want to deploy scorecards, dashboards, and analytics broadly. I’d guess that < 20% of the people I work with want to do Planning, and are only doing so for a small number of users.  While dashboards are pretty darn easy to create and deploy, planning takes quite a bit more work. You generally need hire to consultants to help you create a solution which will only service a relatively small population of your users.

With a limited amount of development time on our hands, I think it makes sense to focus on scenarios that affect the largest number of customers. Microsoft is all about “BI for the masses”, not “BI for the 15 business analysts”.  We can now focus on what we do best – creating good, inexpensive software for everyone.

Moving forward, competitors will clearly attack our offering for having no ready-bake planning solution, and they’ll be on target with their criticism. I bet analysts like Gartner will ding us, too. But, so what?  The planning audience is not what we’re about, and in this economy, who wants to pay for features they don’t need?

It makes our BI story easier to understand

OK, I admit it – we have some feature overlap across our products. ?   Every vendor does.  Before this change, when a customer thought “KPI”, he could do it in Excel/Excel Services, MOSS, Reporting Services, PerformancePoint, and soon, Gemini.  That’s quite a selection of hammers!

With PPS Services inside MOSS, we’re simplifying things – you use MOSS to do this work. Using Excel, SSRS, etc. clearly become edge-case solutions because the MOSS offering is so strong by comparison.

If I need to do an “elevator” pitch on Microsoft BI, I now can say, “Microsoft BI is SQL Server, Office and SharePoint. Fat client data visualization is inside Excel, thin client data visualization is inside SharePoint.”

Done.  End of story.

I’m greedy

I’m an MSFT shareholder and employee. By making MOSS even more attractive, I think the net gain in revenue we’ll realize as a result people adopting it and/or upgrading to the MOSS enterprise CAL  (don’t forget additional indirect SQL Server and Windows Server sales) will be far greater than the bucks we see  from a stand-alone PPS product. That’s money in my pocket.

OK, I was a few days off on my guesstimate….and the landing page I pointed to earlier still doesn’t have links directly to the files…but SP2 was released late yesterday afternoon and can be downloaded here (x86) and here (x64)

There’s also tons of good documentation here. Have at it.

The landing page for PerformancePoint SP2 just appeared at http://office.microsoft.com/en-us/performancepoint/FX102380591033.aspx. While as of yet there are no download links on the page, I think it’s safe to guess that we’ll see the distro in the next day or so.

Happy patching!

Sorry, couldn’t resist!

Yesterday (or maybe it was the day before, I forget), the next rev of AllUp was released internally at Microsoft. It includes 3 new demos including a “deep dive” around PPS Planning, and new stuff for the manufacturing and hospitality sectors.  The image will expire around 12/4/2009.

The super-awesome product manager responsbile for this work of art says that it still needs to get a buy off from our legal department, so isn’t available to partners quite yet – but it will be soon!

I spent a chunk of time this morning scratching my head when I couldn’t get PerformancePoint Monitoring & Analytics display actions working in MOSS. They worked fine in certain dashboards I had  already published, but different dashboards published to the same site were broken – display actions didn’t work at all.

I finally got my “misbehaving” dashboards working by employing the following tactics in the Dashboard Designer:

1. Open the Scorecard that contains the KPI your display condition will leverage.

2. On the Edit tab, Update the scorecard.

3. Go back to your dashboard and add/remove/whatever the display condition in question.

4. Publish/Save.

5. Repeat for each display condition you want to work with.

I don’t know if step 5 is strictly necessary, but I spent so much time on this I didn’t want to experiment any more – just needed to get on with my life! I haven’t tested to see if this is fixed in SP1, but hopefully it is!

While building out some dimensions today, I ran into the following error while using Planning Business Modeler. The error occurred when I selected the name of a table/view in my data source:

Server failed to return the table schema from source database. (Error code: PerformancePoint_225000210). Getting table schema for table <table name> from database <database> on server <server> failed.

Turns out PPS can’t handle any tables or views which are not part of the dbo schema. I had a few of them, and had to use the command below to swap the schema each object belonged to before I could get them into PPS.  I suppose I could have created a dbo.View on top of each object, but I was being lazy:

 ALTER SCHEMA dbo TRANSFER someschemaname.tablename

There has been quite a bit of internal discussion here at Microsoft around this topic since so many of us use the AllUp VPC. 

Long story short, you won’t be able to (easily) install SP1 on an “out of the box” AllUp image. Howard Morgenstern, another BI Technology Specialist has created a quick and dirty guide at http://hmorgenstern.spaces.live.com/blog/cns!28A6BE83102A0EB3!279.entry  on how to approach this scenario.

Its not a tough thing to do, but you do need to be aware of a couple issues. Thanks, Howard!