The detection failed, this can be due to a corrupted installation database

If you ever encounter the above error when trying to install a hotfix or service pack for SharePoint (as I did), then there's a lot of possible answers around, but the right one is quite hard to find, so hopefully, I can help with pointing you in the right direction.

This site helped me a lot with solving the issue, so just go there, follow the second solution and if you're as lucky as I was, it will solve the problem and you'll be able to install hotfixes and all other stuff on your server again!

Thanks to KbNk for posting this!!

Unable to select different display modes in picture library

Just a quick one this time... When you add a Picture Library to SharePoint, you usually can choose between three display modes: filmstrip, details and thumbnail. You can select these through a small menu that appears when you hover over the "All Items" view in the view picker. But what if you don't get this little menu?

This was the case in the environment I was working in. Turned out that this was a bug caused by the installation of the WSS Infrastructure Update. Luckily for all people with this problem, there is a hotfix for this:

http://support.microsoft.com/kb/959644

Just request the hotfix through this page and install it on your front end server and everything should work as it is supposed to work again!

Unable to locate the xml-definition for FieldName with FieldId ...

If you're trying to deploy some custom site columns using a feature and the feature activates fine, but the columns don't show up and your logs give you the above error, then the solution is pretty simple: when you're defining your columns, you have to make sure to use brackets around your column guid, like this: {GUID}. Deploy your feature again, deactivate it, activate it again and everything should work fine! You also have to use the brackets when you're referencing the column in a content type!

Thanks to Edwin Vriethoff for posting this!

Modify the default scope for your search box

Today I got asked how to modify the search box on a MOSS site so that it displayed "People" by default in stead of "All Sites". The customer already figured out a way to do this with code, but they weren't 100% sure about it. I had to search for this myself too, cause to be honest, I hadn't done this before, even though I'm already working with SharePoint for almost 3 years now... That's why I'm making this short post, so that all the other people who are trying to do this, know how easy it really is.

To modify the default scope, go to your home page and navigate to "Site Actions” --> “Site Settings” --> “Modify All Site Settings". On this page, pick "Search scopes" under the Site Collection Administration. Here you'll see some different "Display groups", one of them is the "Search Dropdown", which is the search box you see on your SharePoint site. If you click on the "Search Dropdown" link, you'll be taken to a page with some settings for this group and the bottom one is where you set your default scope. So modify this to whatever you want, click OK and you're done!

The path specified cannot be used at this time

When I opened my IIS manager (on a server with SharePoint 2007 installed) today and tried to connect to the localhost (which had always been possible in the past, without any changes done to the server), I suddenly got the error "The path specified cannot be used at this time". The solution for this is quite simple luckily... Just go to the services on your server and restart the Windows SharePoint Services Timer service. Then refresh your IIS manager and everything should be back to normal again!

Service stuck in "stopping" state

A couple of days ago I wanted to restart the Windows SharePoint Services Timer service on one of our SharePoint servers because some timer jobs seemed to be stuck. When I tried this though, the state of the service became "stopping" and it stayed that way for hours. I tried stopping it with NET STOP, but this gave me an error that the service "could not be controlled in its current state". I read online that rebooting didn't help with most people and this also wasn't an option since this was a live server, but then I read about PsTools. This set of command line tools contains a little something called PsKill. This little tool kills the process for you, allowing you to start it again. In my case, I used it the following way:

PsKill.exe \\moss-server owstimer

This killed it immediately and I was able to start the service again.

You do have to be careful with this though, since not all services can be killed without any risk (for example when a process is writing things to a database).

One last thing, for your convenience: the link to PsTools: http://download.sysinternals.com/Files/PsTools.zip.

OWSTIMER error when restoring a SharePoint site

When I was trying to restore a web application with a single site in it and one content database, I received the following two errors:

Error: Object OldIntranet (89) (previous name: Intranet (80)) failed in event OnRestore. For more information, see the error log located in the backup directory.
SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=OldIntranet (89) Parent=SPWebService is being updated by svc_moss_sql, in the OWSTIMER process, on machine MP-MOSS-INDEX01. View the tracing log for more information about the conflict.

Error: Object SharePoint _OldIntranet89_Content (previous name: SharePoint _Intranet_Content) failed in event OnPostRestore. For more information, see the error log located in the backup directory.
SPException: Cannot attach database to Web application. Use the command line tool or Central Administration pages to attach the database manually to the proper Web Application.

I tried every possible solution I found on the internet, but nothing worked. Then I decided to try the update with stsadm through the following command:

stsadm -o restore -directory "\\fileshare\backupfolder" -restoremethod new -item
"Farm\Windows SharePoint Services Web Application\Intranet (80)"

After doing this, I first got a new, different error about the Administration Service. I restarted this service and after that, the stsadm command also gave me the two previous errors. So then I decided to just turn off the Windows SharePoint Services Timer service... and what do you know, it worked! Afterwards, I also noticed that I had turned off the WSS Administration service, so if turning off the Timer service doesn't work, you can also try this one.

I do know that turning off the Timer service in a live environment probably is not such a good idea, but well, if nothing else works, you might be forced to do so...

I also didn't test doing the restore through Central Administration (since it had already been succesfully restored through stsadm), but feel free to give it a shot and let me know if it also works! (Although I doubt it, since I think the procedure through the Central Admin uses a timer job for this, which won't work if the Timer services has been stopped.)

Workflow task: Value does not fall within the expected range

If you get the above error when trying to open a task form in a workflow, then read on!

Here's the situation where I got this error: I have a custom approval workflow where one user adds an order request through an InfoPath form. When the form gets submitted, the "IT Approval" group gets assigned the task to approve or reject the order. Also important is that security has been broken so that only the right people can see and approve the tasks. The whole thing is a bit more elaborate than this, but this is basically all you need to know to understand the problem and hopefully recognize it...

Now, if someone in the IT Approval group goes to check his "My Tasks" page, he sees all the tasks assigned to the group. So far, so good... But when he tries opening a task, he gets an error page displaying the "Value does not fall within the expected range" error message.

I've tried many different things, making sure the IT Approval group had contribute access to the task, read access to the site, the task list and the workflow history, but nothing seemed to work. However, there was one place that I missed: the original document.

So if you're facing this problem and you're using custom security, check your InfoPath form (or any other kind of document that triggered the workflow) and make sure the approval user has read access to this file too. I don't know the exact reason for this, but I guess this is because the workflow is copying fields from the original file into the task form and apparently, this only works when the user can read the original file too.

Debugger: No symbols have been loaded

Just a quick post that can save you a lot of time.... I was debugging a SharePoint workflow that had already been deployed and everything, but it needed some extra changes. I never succeeded in debugging it though and it always gave me the "no symbols have been loaded for this assembly" message. After trying almost everything (restarting the server, rebuilding and deploying everything, clearing the .Net cache, ...), I found a post of someone saying something about "debug mode". Turned out my Visual Studio project was set in "Release" mode by the one who installed the application and you can't debug when it's in Release mode. To reset this, simply right click on your solution name, choose properties, click on "Configuration Properties" and under "Configuration", select "Debug" for all your projects. Then rebuild and deploy again (make sure you use the .dll files from the "debug" directory in stead of the "release" directory) and everything should debug fine again...