Case Study - Law Firm Intranet Portal

WebKMS recently completed development on a Portal for a leading Canadian Law Firm. The Portal design combined an extremely robust knowledge management system with a feature rich user interface. The Portal has been rolled out to over 1500 employees and the feedback on the system has been tremendous. For more information on this project email info@webkms.com and request our Case Study - Law Firm Portal.

Migrating from 32-bit MOSS server to 64-bit MOSS server.

Migrating an application (both content and code) from an existing environment to a newer environment is always a challenging and at times a daunting task. SharePoint application is not an exception. I would like to share my experiences at WebKMS where I had to migrate the content database and deploy the code from our existing 32-bit MOSS solution in Windows Server 2003 environment onto a newly built 64-bit MOSS environment in Windows Server 2008 R2.

First, let’s start with migrating the content database:

Everything looked good until I tried to attach the content db from within the Central Admin. Taking a full backup of the existing content from the 32-bit SQL box and restoring it on the 64-bit SQL box was smooth. The problem occurred while actually attaching the content db from the Central admin interface on the 64-bit MOSS environment. This is resolved the by backing up the site collection(s) we had and restoring it on the MOSS server using the stsadm commands.

Here is the script that did the trick:

---Backing up the site collection---
set newUrl=http://mymossServer/sites/mySiteCollection
stsadm -o backup -url %newUrl % -filename c:\mySiteCollection.bkp

---Restoring the site collection---
set newUrl=http://mymossServer/sites/mySiteCollection
stsadm -o restore -url %newUrl% -filename c:\mySiteCollection.bkp -overwrite

Please note that in order to restore the site collection, the content database on the server must be brand new! (One can add a blank content database from the Central Admin interface).

Some of the other minor things one would face working on the Windows 2008 server is that the security on the server is more tighter and normally running scripts and other commands would not run. My deployment script didn’t work the first time (if everything works smoothly the first time, we should all pack our bags for good :-). Even though I had logged into the server as an administrator, I had to run my deployment batch file as an administrator! One can either right-click on the batch file and select run as administrator or open the DOS command window itself as an administrator and execute the script in the normal way. I prefer this option as even executing an iisreset needs to be run as an administrator! Imagine having a separate batch file just with iisreset and yet run it as an administrator! We all know how many times during the development process one needs to do iisreset.

An other tweak I had to do with my deployment script is that I had to specify the complete path of my wsp package file in the addsolution operation of the stsadm command syntax. Please note that the batch file is executed from C:\Windows\system32 directory whereas my script and the .wsp files are in C:\Deployment directory.

C:\Windows\system32> stsadm -o addsolution -filename myDeployment.wsp
myDeployment.wsp: The specified file was not found.

Either I modify the batch file to include the complete path like this:
stsadm -o addsolution -filename C:\Deployment\myDeployment.wsp

or

execute the batch file in Command prompt from the correct location (C:\Deployment in my case) like below:

C:\Deployment >stsadm -o addsolution -filename myDeployment.wsp

We also had a set of Web services that were built with WSE 3.0. There have been some discussions that WSE 3.0 won’t be supported in 64-bit MOSS installation and the web services might not be working. This didn’t seem to be a problem in our case though.