iSharePoint

I had a problem at one of my projects with a Sharepoint Timer Job. It was running fine for a while but after two months it started throwing errors. The code that creates sharepoint sitecollections is relying on the Enterprise library for things such as exception handling.

Since the unit test and web application ran fine I had not checked that the timer job processed the exceptions correctly. Turned out that exceptions did not get logged because the timer jobs run on their own context rather than in context of a webapplication. Hence the web.config settings for the Enterprise library could not be loaded. The unit tests have their own app.config but where would you place such settings for a SPTimer job?

Turns out it is pretty easy! Since the SPTimer job runs in context of the owstimer.exe in the bin directory of the Sharepoint 12 Folder you can add your own config settings file. If you already had a unit test in VS.NET with a correct app.config, then just copy that one to the Sharepoint 12/BIN folder, rename it to owstimer.exe.config and hey presto all your Enterprise Library settings will now load correctly. Remember to copy it to all Sharepoint servers where the timer job is running.

Thanks to Henk Drent and http://www.thesug.org/Blogs/mossmania/archive/2007/12/19/Using_a_Config_File_for_Windows_SharePoint_Services_Timer_Jobs.aspx.aspx for helping out on this one!

roelhans SPTimerJobs Enterprise Library, sharepoint, SPTimerJob

A client of the company I work for asked my collegue Ron (@ronlagerwaard) to move all sharepoint databases for two Sharepoint 2007 farms from a SQL Server 2005 db to a new SQL Server 2008 db. The procedure described in the Word document at http://www.microsoft.com/downloads/details.aspx?FamilyID=65686896-c171-46a8-a95f-54f43ad79952&displaylang=en did not work for him.

I had to do this for Sparked, the company I work for as we had a problem with our new SQL 2005 install so I had some experience with the difficulties involved. I tried a backup at farm level and then restore the backup on the newly created farm after detaching the farm and creating a new firm using psconfig.exe. Did this not work for me as the timer job for the backup restore never ran. This left me with the painful recreation of all config and webapplications by hand. It worked but it took a long time and is probably not workable for a big farm.

Ron came up with the alternative of using stsadm -o renameserver. Now I checked the documentation and it wasn’t exactly clear that this is used for the database server renaming. Turns out it was a great idea and it worked like a charm except for the index and search server settings messing up. We were able to fix that as well and here is the procedure we followed:

1. server 1: create backup of all databases that are to be moved
2. server 2: make sure that all accounts used for db access and rights as used on server exist on this server
3. server 2: restore all databases on this server, making sure that right are correctly set
4. Stsadm –o renameserver -oldservername server1 -newservername server2
5. Reboot sharepoint and take all moved sharepoint databases offline on server 1
6. stsadm -o osearch -action stop
7. stsdm -o osearch -action start -role index
8. Edit SharedService provider and provide the index settings
9. reboot server
10. Recrawl all content

This worked very well for us. There are some alternatives: Gary Lapointe on using sql alias as an alternative:
http://stsadm.blogspot.com/2008/06/moving-databases-easy-way.html.

roelhans Geen rubriek migration, MOSS, sharepoint, SQL

One of my collegues called me as she had a problem with a Sharepoint Designer Workflow. Three of the five workflows had a problem. When you logged in as a user and tried to edit the workflow task Sharepoint was throwing an access denied error.

I had a look and told here to restore rights inherintance. Unfortunately this did not solve the problem. So it was time to have another look. Nothing I could see was out of the usual in the workflows nor in the permission settings (task list, workflow history list etc). Even assigning full control to all users did not help. In this case: Google is your friend! Googled it and came up with this

Turns out that if you add a workflow with Sharepoint Designer, assign tasks to users in that workflow and add users afterwards, the rights are not properly set for those new users. Solution is to republish the workflow through Sharepoint Designer. Even if you publish to c: the workflow will run fine with proper rights afterwards. I am not sure if this is a bug or by design…

roelhans Geen rubriek Sharepoint Designer

I usually use Subversion plus CruiseControl.NET and WSP Builder for automatic builds of WSP files for the Sharepoint DEV and TEST environments. Recently I have started a project for a customer that uses Team Foundation Server (TFS). Of course I wondered how to set up the same. Lo and behold it got twitted. So here is the link: http://blog.brianfarnhill.com/2008/12/30/how-to-get-tfs-to-automate-your-wsp-builds-with-wspbuilder/. Thanks @waldekm for bringing it to attention!

The thing that really shines for me is in step six: referencing if you have no MOSS installed on the build server. I have always used the first approach; dump the referenced dll in the GAC. I did not know about the possibilty of adding an extra reference path in the build project for TFS. Much more elegant than dumping it on the GAC.

roelhans Build Automation sharepoint, TFS, WSPBuilder