No Excel Calculation Services is available in the farm

In the course of building my new SharePoint 2010 farm, when attempting to view an Excel Spreadsheet in the browser, I received the error below:

Not exactly helpful.

I dug into the log files and found an error that stated "No Excel Calculation Services is available in the farm". The next step was to figure out where this service was located and why it was not available.

A bit of digging in Central Administration led to Central Administration > Services on Server. Once there it was obvious what the problem was. The Excel Calculation Service was stopped.

I started the service and attempted to open the original spreadsheet. This time, I got a different error message, indicating that the operation could not be completed, and asking me to wait a few minutes and try again.

While I waited, I recycled the application pool and restarted the browser. This time, my spreadsheet loaded as expected. Problem solved.

Disabling the Upload Button on a Document library

I have a document library that houses InfoPath forms. When a new form is submitted, a series of workflows are triggered and tasks assigned, etc. I had an issue where workflows were getting started multiple times, creating multiple tasks, and generally causing chaos.

I traced the issue to the fact that users were not only using the "New Document" button to create a form, but were also saving old forms and re uploading them using the "Upload" button; resulting in duplicate files, duplicate workflows, etc.

I resolved the issue by simply removing the Upload button from each page that linked to the document library. Here are the steps to do this:

1) Use SharePoint Designer to open the page in question.

2) In Design View right-click the List View Web Part and select convert to XSLT Data View  from the context menu.

3) Switch to Split View and locate the "New" button ,and you will see the XSLT code""

4) Set the "td" visibility as "hidden" as shown below:

Additionally, to prevent an unsightly 'blank space' in the menu, I moved the location of the now hidden button to the be the last button on the right of the menu.

Now users have to use the "New" button to create a new document and cannot use the upload button. Keep in mind that you'll have to do this for each view that the users have access to, as each view has it's own page that will need editing.

SharePoint 2010 List View Differences

In the course of upgrading my farm from 2007 to 2010, one of the differences I've encountered is in the List View webpart.

In my 2007 farm, I have several List Views that are filtered by user. Basically they are designed to show only 360 Reviews by others of myself; whereas the list contains all employee reviews.

This is what it looks like in SharePoint 2007:

After upgrading to 2010, this is what it looked like:














After doing a little digging, I determined that this error was caused by the Ajax settings in the new list view. I edited the webpart and enabled the two settings below:

At this point, the List View displayed the data properly, but the style was different:

I checked the Style settings by editing the current list view, and I verified that the webpart was set to use the "Document Details" on both the 2007 farm and the 2010 farm. Evidently, the "Document Details" style behaves differently in 2010 than it does in 2007. I also made sure the default setting of "collapsed" was selected.

A little experimentation showed that if I set the list view to use the "Default" style, the webpart displayed  as I wanted, as shown below:

SharePoint 2010 Page Viewer Web Part Forcing Download of .htm Files

I recently ran across an issue after upgrading from SharePoint 2007 to SharePoint 2010 where a page that contained a Page Viewer Web Part that displayed a .htm file. Every time the page was rendered, the user was prompted to download and save the file. The page would not display properly, and the site would hang.

I found the answer at Impossible as Possible. This solution saved me hours of digging.

SharePoint 2010 has an enhanced security model. One aspect of this is that the setting for browser file handling is set to strict by default. As explained by Microsoft here, this is by design to prevent malicious scripts from exploiting security.

To resolve the issue simply open Central Administration\Application Management\Manage Web Applications. Scroll down until you see "Browser File handling". Change it from Strict to Permissive as shown below.

You can now view html files in the iFrame as desired.

Identifying Problematic Features After Upgrade

In the course of upgrading my SharePoint 2007 farm, one of the more frustrating experiences was identifying problematic features or items that failed to upgrade properly.

One of the issues I recently dealt with was an error produced when I selected "Site Actions", then "Manage Content and Structure". This would immediately produce an error with a cryptic correlationID message. Searching the internet produced a consensus that I had a corrupt list on the site. Here is how I tracked it down and eliminated it.

The first step was to edit the web.config file to produce a more usable error message. In the web.config, alter it so that "customErrors mode = off", and CallStack = True". Do an IIS Reset and you should now get a more usable error message.

In my case the call stack indicated that the error was because List Template ID 432 was not installed. So, I knew this was a corrupt list, and it was a list on the main page of my site. A quick Google search turned up the fact that that List Template 432 was the KPI List template, which was deprecated in SharePoint 2010. Any list in my production farm built using this template would have to be deleted.

Now that I knew what type of list it was, I went back to my production 2007 farm to identify the lists in my farm built on this template. I used ControlPoint to run a report that identified every site in my farm that had one of these lists on it.

Using this information, I set about deleting the corrupt content on my 2010 farm. Some people have indicated that you can use SharePoint Designer 2010 to connect to the site and delete the content. I was unable to do this, as SharePoint Designer would not display content for pages that contained the corrupt list.

I finally resorted to using stsadm -o forcedeletelist -url to get rid of the lists. Once I deleted the offending content, I was able to open the Manage Content and Structure page and browse site content normally.

One last tip. Once you get Manage Content and Structure working, you can simply click through every site in your Site Collection. If a site contains any corrupt items, it will produce an error rather than expanding the treeview. This is a fast way to check sites for corrupt content.

SharePoint 2010 Database Upgrade - Partial Success

In my last post I detailed how my SharePoint upgrade attempts have failed because of a lack of sufficient drive space in my test environment.

I attached a 500 GB external drive to my test server, truncated the transaction log to 1Mb, moved the transaction log file to the external drive, and restarted the upgrade process. Hopefully this would be more than enough disk space.

After 10 hours, Central Administration reported that the upgrade had once again failed! However, when I checked the log files, there was no mention of drive space errors, and the hard drives had plenty of room left on them. Further review of the log files indicated that the database upgrade process had reached 100% and was complete, but that there were 76 errors. Evidently these errors were the cause of the failure.

Upon restarting SharePoint I was able to open the web app successfully.  My data was intact and I was able to browse, open documents, etc. The errors were very apparent, as certain webparts and features were causing errors or not displaying.

After the "failed" database upgrade, the log file had grown from less than 1 Mb to 130 GB. The mdf file had grown from 140 GB to 250 GB.

The content database was still in Simple Recovery Model, so I truncated the transaction log by running

DBCC Shrinkfile(@LogFileLogicalName,100).

Next, I ran DBCC ShrinkDatabase(@DataBaseName)

At this point the content database was close to it's original size of 140 GB. As with any upgrading testing, the next step is to identify and resolve the logged errors, and repeat the upgrade process until it's successful.