Edwin Vriethoff » Errors

Front-end file system cache problems might occur after a SharePoint configuration database restore.

Edwin Vriethoff — Thu, 25 Mar 2010 16:41:57 +0000

Last week I was working at a client who just restored one of their SharePoint environments because of a site error. Everything was functioning like normal, until we discovered a major issue with the InfoPath forms publishing mechanism.

For some of the Infopath forms we received an error while upgrading the form to a newer version. The error statement told us that we could not update the form because of an object in the database with the same ID.

To resolve the error we tried to remove the existing form, but instead of removing the form, SharePoint decided to do the opposite and it tried to start some kind of upgrade process. We had no more options to upgrade or even delete the existing form.

We knew that SharePoint generates a WSP for each InfoPath form that is published in the Central Administration. The deployment status of each WSP file can be seen in the Solution Management section. Right here we found the source of our problem. The Solution Management page informed us that the WSP package of the forms where Globally deployed, but they gave an Error status. The error status blocked every option to retract or re-deploy the WSP. Looking at the error details the following message was displayed:

SharePointServer : C:\WINDOWS\Temp\solution-fc4c343f-f8f7-4724-b6c0-8e658496bda9\form-template_myform.wsp could not be created because the contents could not be found under id 4795693a-2ec7-4a92-810f-eb9931a498e6 in the configuration database.

Somehow the environment was thinking that the content of the missing WSP package was deployed.

Finally the IT Pro of our client found the solution for the problem in KB939308. It turns out that after a database restore, the contents of the file system cache on the front-end servers can be different from that of the contents of the configuration database.

The only way to fix this is by performing some manual steps:

All the XML configuration files have to be removed from the SharePoint config directory.
The contents of the cache.ini file has to be cleared.
The Windows SharePoint Services Timer has to be restarted.

A detailed guide of these steps is provided in the description of KB939308.

So next time if you have to do a database restore of your SharePoint Server, keep in mind some cache problems might occur.

Visual Studio and SharePoint 2010 new SPSite returns FileNotFoundException

Edwin Vriethoff — Mon, 22 Mar 2010 11:26:50 +0000

While writing my first console application to communicate with SharePoint 2010, I was surprised to receive a FileNotFoundException during the creation of a new SPSite.

The line

SPWeb web = new SPSite(”http://localhost/”).OpenWeb();

returned the error statement:

FileNotFoundException was unhandled:
The Web application at http://localhost/ could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

At first I assumed that the error was caused by invalid user rights, but after some searching this forum post at Microsoft Technet came up with the right solution.

By default the console project is build for the .Net 4 framework and and the x86 platform. Because SharePoint is only available as a 64bit version, the console app should also be compiled for the 64bit platform.

By changing the framework to .Net 3.5 and the target platform to x64 the issue was resolved.

SharePoint SP2 activates 180 day trial countdown

Edwin Vriethoff — Fri, 22 May 2009 07:21:47 +0000

The Microsoft SharePoint Team announced that the SharePoint SP2 service pack by mistake activates a 180-day countdown.

“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. The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes. Furthermore, product expiration 180 days after SP2 installation will not affect customer’s data, configuration or application code but will render SharePoint inaccessible for end-users.”

The team is working as hard as possible to release a hotfix to address the issue.

The Work around is also known: Re-enter the Product ID numbers on the Convert License Type page in Central Administration.

More information at the Microsoft SharePoint team site.

Audience compilation via the command line

Edwin Vriethoff — Wed, 13 May 2009 08:58:38 +0000

Last month I had to work a lot with audiences and of course my development environment had an annoying malfunction. The manage audience page (/_layouts/Audience_Main.aspx) contains a nice compilation link, but it didn’t work.

The only other option on the page is to schedule the compilation, but it can only be scheduled to run once a day. Not very useful during development.

After some digging I found the command line application to control the audience job and luckily it wasn’t very complicated to use. Just run the application to get some more information:

c:\Program Files\Microsoft Office Servers\12.0\Bin>audiencejob.exe
AudienceJob.exe [Crawl Type] [Audience Name]
Application Id: Guid corresponding to Search application
Command: 1 = Start, 0 = Stop
Crawl Type: 1 = Full, 0 = Incremental (default = 1)
Audience Name: Specific audience to compile (default = all)

Application Id for SharedServicesProvider1: 23ec9668-ea04-4842-b9ba-8e39cfaeaa3d

The best of it is that the application provides you the GUIDs of available Shared Service providers.

To start a new compilation from scratch for all the audiences, run the command with the given GUID and the two other parameters:

c:\Program Files\Microsoft Office Servers\12.0\Bin>audiencejob.exe 23ec9668-ea04-4842-b9ba-8e39cfaeaa3d 1 1

Find out which process is locking a DLL without extra tools

Edwin Vriethoff — Mon, 26 Jan 2009 10:28:40 +0000

Today I got the “The process cannot access the file … because it is being used by another process” error again, during a development build. And as long as the DLL is locked, it’s not possible to do a successful build.

Most sites and tips on the internet suggest to download some tool to detect which process is using the DLL. It seems that not many people are aware that, since Windows XP, we don’t need to download (or even pay for) a tool to detect this.

Just launch the windows console and navigate to the directory of the DLL. Now type “tasklist.exe /m locked.dll” and it will show you exactly which processes have loaded and locked this DLL.

Happy unlocking