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.