iSharePoint

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