Most people have discovered by now that in order to use Windows 2008 as a “client” in BI demonstrations that you need to install the “Desktop Experience” feature of the OS. Without it, you’ll have problems getting into SharePoint from Office.

During a recent POC,  I was working with an “all 2008 image” (SQL 2008/Windows 2008/MOSS SP1/PPS SP1/Office 2007), and had a bear of a time getting Excel to browse MOSS libraries. Desktop Experience was installed, but when I attempted to browse to a MOSS library in Excel, the Web Query dialog would pop instead:

If I just plugged the URL of a report or document library into the Open: dialog, Excel was actually importing the page as HTML!

Office 2007 leverages WebDav in order to open MOSS libraries as folders, so I figured that was the problem – I found I was unable to Map a Network Drive to any of the MOSS libraries so I knew I was on the right track.

After several un-install / re-installs of the Desktop Experience component with no change in behavior,  I went ahead and  installed the IIS 7.0 WebDav Extension: It adds some additional configuration UI to InetMgr, and I thought having access to those extra knobs and dials might solve my problem. No joy.

Long story short, I took off my geek hat, put on my consumer hat and got the help of Rakki from PSS. After noticing that I had the IIS 7.0 WebDav Extension installed, he mentioned that MOSS uses its own implementation of WebDav and we didn’t need the extension. He suggested we remove it. I frankly didn’t think it would make a difference since I had the problem before I had installed it and putting the component on the box was an attempt to solve the issue to begin with, but whatever.

So, we un-installed it, and lo and behold, I was able to map drives to my MOSS libraries and Excel / Office was able to browse them. Why? We’re not sure – perhaps the un-install of IIS WebDav did something to nudge the “broken” MOSS WebDav implementation back to life. Complete speculation on my part.

But, if you run into the same issue, maybe this will save you some time (or maybe not, who knows).

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!