The Excel Web Part error on the SharePoint site is: "An error has occurred. Please contact your system administrator"

When looking in the application log on the server I saw:

Event ID: 5226 - Excel Calculation Service
Unable to create or access workbook cache at C:\Windows\TEMP\Excel server\FileCache\SharedServices1-942760090\Ranges. Excel Services is unable to function without a workbook cache.

Googling the error will present you with posts to check that the disk is not full, that the account running the application pool tied to Excel Services has appropriate permissions to TEMP and to try restarting the Excel Services service. Great places to start, but I found my issue was much simpler:

It turns out previous to the error I ran CCleaner on the server, which goes through the system and removes "unneeded" files...which included some of the subfolders in temp. I did have all the structure down to C:\Windows\TEMP\Excel server\FileCache\SharedServices1-942760090\ but missing subfolders. It seems that it's OK to delete all of TEMP (it will simply recreate the cache), but if the subfolders are missing Excel Services gets confused.

So browse to the directory in question under \FileCache\[SSP Path Name]\ you should create 3 subfolders: \Ranges, \Charts, and \SavedWorkbooks.

I recently got the below error message across all of my sites in a farm; every web part was displaying this message instead of the content. Very scary:

Web Part Error: One of the properties of the Web Part has an incorrect format. Windows SharePoint Services cannot deserialize the Web Part. Check the format of the properties and try again.

You'll quickly find the following MS KB article for the error message: KB 826786.

It boils down to SharePoint needing to work out of the WinDir\Temp and WinDir\System32\logfiles directories. Which may be a permissions issue as noted in the KB article.

This can also be caused by your virus scan software. For example, McAfee's On-Access Scanner may be blocking executables from being written to the Temp directory: SharePoint writes .dlls to temp which will be blocked, which would be blocked from functioning and cause the noted error.

So in short, if you are getting the above error message it might be a good first step to disable your virus scan and see if the message goes away, if it does work from there to readjust your virus scan settings.

From the SharePoint Team Blog:

During the installation of SP2, a product expiration date is improperly activated. This means SharePoint will expire as though it was a trial installation 180 days after SP2 is deployed.

Read more »

This one might scare you pretty good the first time you see it. When you launch IIS Manager either on a MOSS WFE or remotely connecting to a WFE nothing populates under your server name in the left pane: not even showing folders for App Pools, Web Sites or Web Service Extensions.

This is fairly common (haven't had a chance to see if it was fixed in SP2). It looks to be a memory leak of some sort as it seems to happen over time.

Luckily the fix is very simple: simply restart "Windows SharePoint Services Search" and "Windows SharePoint Services Timer". No iisreset is needed afterwards from all the cases I've seen.

NOTE: Reader Richard suggests the hotfix KB946517 may resolve the issue. I will try shortly and confirm. Thanks Richard!

SharePoint MOSS 2007 has introduced a great feature set in My Site and My Links. Unfortunately there seem to be some kinks in keeping the My Links in sync so they actually show you all the sites you are a member of.

I recently did a WSS2.0 to MOSS2007 database migration. The new server had MOSS installed well before the migration and it was used as a dev instance before moving the production databases over to it.

Here is the problem: after moving the prod DBs over and renaming the new server with it's PROD name all the My Links still pointed to sites using the dev url. Even new sites I added myself to would not show up under My Links.

Read more »

Often software will request a certain service pack level or version of SQL Server. (IE: MOSS 2007 requires SQL 2005 SP2). There is no simple Help > About to see the version of SQL you are running.

For SQL Server 2000 and up, run the below query (2000 - open Query Analyzer, 2005 - right-click a DB and select New Query):

SELECT 'SQL Server '
+ CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - '
+ CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' ('
+ CAST(SERVERPROPERTY('edition') AS VARCHAR) + ')'

This will return your version. You can see the build charts for more detailed information:

SQL Server 2000 Build Chart
SQL Server 2005 Build Chart

When dealing with some large ldf log files I started investigating the best methods to backup/compact/just generally deal with them.

Since the "shrink database" command within SQL 2000 Enterprise Manager doesn't always seem to do what you'd expect, here is the command to run in Query Analyzer.

backup log db_name_here with truncate_only
dbcc shrinkfile(db_log_filename_here,truncateonly)

You could script this to run on a regular basis or just as a one-off while doing manual maintenance on your dbs.

I recently put a question out to the internet on what needs to be done if you upgrade a server that acts as a DFS namespace server and is pointed to by several DFS folders.

If the new server has a new name, you will need to remove the old server as a Namespace Server for each domain-based DFS namespace it is a member of. In addition, you will have to remove and re-point each folder target to the new path.

In my scenario we were doing an in-place upgrade and the server would keep the same name. But since the upgrade results in the machine having a new SID in AD there is some work that needs to be done. I found in this situation you only need to remove the server as a Namespace Server and re-add it once the new server is in place so the new SID is used in AD's DFS configuration. All the DFS folder targets can be left alone as SID is not used here, just the path.

We are not using DFS-R on these folders, but I believe if you were, you would need to redo the replication partners as DFS-R relies on the SID information stored in Active Directory.

This past weekend we migrated a file server to new hardware. The file server presents 2 SAN luns and shares on an MSA20 array. In the past when we moved the SAN luns + the array storage between servers we have had to manually reshare all the shares on the new server. Here are the steps to bypass that by migrating the share information.

- On the current server, navigate to \HKLM\SYSTEM\ControlSet001\Services\lanmanserver\Shares

- Export this into a reg file and copy the file to the new server

- Ensure the drives use the same drive letters when presented to the new server

- Import the reg file on the new server

- Restart the server service

It's a quick and easy process that will save you from resharing all your shares and eliminates the human errors associated with that.

On a default install of IIS you will receive the below error when trying to access hosted mdb files via a website:

Server Error in '/' Application.
--------------------------------------------------------------------------------

This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.mdb' may be incorrect. Please review the URL below and make sure that it is spelled correctly.

Requested Url: /directory/file_requested.mdb

So reading this error you can assume there is a place where you explicitly forbid different file extensions from being served from your IIS sites. So I started Googling this since I did not know where these settings were. 9 out of 10 results suggested zipping the mdb up and having the user download the zip. Of course that is always a work around, but not what I was looking for.

- Launch the IIS Management console
- Right click your application or the root of your website(s)
- Go to the Home Directory Tab and click "Configuration"
- Go to the Mapping tab and delete the association of the file type MDB

You do however need to keep the MDB extension as an allowable MIME type on win2003, so you do not need to make any setting changes there as this would result in a 404 error.