For the past several months, Project Real got lost out on microsoft.com – those who wanted the whitepapers and/or samples were pretty much on their own.

The materials have been restored and are now available at:

http://www.microsoft.com/sql/bi/ProjectREAL

In the “news to me” department, we’ll also see a 2008 version of Project Real at some point in the future – and no, I have NO idea when that will be

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.

I don’t know what my mental block around Excel Services is all about – but configuring it just kills me.
After building more Hyper-V and VS images which include Excel Services than I care to count, I still have not managed to get data refresh working right the first time. Ever!

Kind souls often offer tidbits like “did you configure the trusted file location” and other nice-but-useless advice for anyone who has worked with the technology for a little while, and I just grind my teeth. Do I sound bitter? Well, I am. I get particularly aggravated that the error message doesn’t give me more information to go on, too.

Today, while building a new Business Intelligence demo image which relies completely on Windows 2008 & SQL Server 2008, I again ran into data refresh hell. But I also happened to stumble upon a great tool which helped solve my issues after only dropping 2-3 F-bombs.

For the MOSS gurus in the house, this is probably old stuff, but it was an epiphany for me.

The Log View feature integrates an easy way to your MOSS logs right into SharePoint 3.0 Central Administration.

You can download it from here:

http://www.codeplex.com/features/Release/ProjectReleases.aspx?ReleaseId=2502

Once you’ve grabbed it, drop it in the folder below on your MOSS box:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

Then, navigate to the same location on a command prompt and execute the following:

stsadm -o addsolution -filename LogViewer.wsp
stsadm -o deploysolution -name LogViewer.wsp -allowgacdeployment -immediate
stsadm -o execadmsvcjobs
iisreset

That’s it. Jump to the Operations page of Central Admin, and you’ll see View Unified Logging Service under Utilities. Hit it.

Select a log file which covers the period you had a problem with data refresh, choose Excel Services in the This category filter, select Warning in Event Severity and click Go.

I found this:

Unable to establish connection using only the connection string. If a username and password are saved in the connection string, they may not be correct, or the Unattended Service Account may not be configured. [Session: 21.1wTVe6u1xgnzlBvXz6VtM90.5.en-US5.en-US73.+0300#0000-11-00-01T02:00:00:0000#+0000#0000-03-00-02T02:00:00:0000#-0060 User: ATLAS\Administrator

Whoops! Forgot to configure the Excel Services Unattended Execution Account. I knocked it out, bounced IIS, but still had a problem. So I went back to the log, filtered on Information in Event Severity, and found this:

The workbook 'http://atlasone/Reports/FirstTest.xlsx' attempted to access external data using the unsupported provider 'Provider=MSOLAP.4;Integrated Security=SSPI;Persist Security Info=True;Data Source=.;Initial Catalog=Adventure Works DW 2008'. [Session: 21.37RxBqgtK2fX8GRWS68rV90.5.en-US5.en-US73.+0300#0000-11-00-01T02:00:00:0000#+0000#0000-03-00-02T02:00:00:0000#-0060 User: ATLAS\Administrator]

Jeepers! The connection in my Excel worksheet was made with the latest/greatest SSAS provider, which didn’t even exist when MOSS was dropped – So I added MSOLAP.4 to the list of Trusted data providers (under Excel Services Settings in Shared Services), did another IISReset, and I was in business.

Can’t tell you how much time this little tool gave me back.