Upgrading from SPS 2003 to MOSS 2003
Recently I have been involved in upgrading our intranet from SPS 2003 to MOSS 2007 and I know this is something that is going to be increasingly important as more and more companies look to take advantage of the benefits of MOSS. With this in mind I have put together a list of steps that I followed as a set of guidelines to make this migration as easy as possible. This article will only cover the steps that I followed and aims to give you an idea of the steps involved as given the number of SPS 2003 solutions it is impossible to provide a comprehensive all encompassing paper that will adequately cover all scenarios.
In this article I shall be looking at the database migration approach but it’s important to know this is just one of three options you have when looking to upgrade to MOSS 2007. The two other options are the gradual and in-place upgrades, however I shall not discuss these today as there is lot information available on the advantages/disadvantage of each approach.
A few important factors that need to be considered when deciding which approach is the most appropriate are:
· The size of the site
· How often it is accessed
· The number of users.
Putting this into context I was working with a system that was typically accessed Monday to Friday 8am to 6pm. The content database was approximately 60 GB and we had approximately 250 users. The reason I choose the database migration approach was because the SPS 2003 site was running on the one box, including the SQL server, and this was causing some speed issues due to all the resources on the box being consumed. If I then attempted to install MOSS on the same box this would have then caused the site to respond even slower and effectively been usable during the upgrade period. By using the database migration it allowed me to maintain the current site in the short term but crucially gave me the ability to recreate the site on improved hardware.
Once you have decided on the approach that best fits your organization and their needs the next section is how you actually go about implementing the migration and this is what I shall be discussing in the next section. I have broken the database migration down into the various steps I performed and will discuss these in turn.
Install MOSS on server
The first step is to install MOSS 2007 on the new server and this is a very straight forward process simply follow the installation wizard. There is one very important section that can cause all sorts of problems in the future if you don’t choose the right option at this stage. There is a section during the install where it asks you to choose the type of installation. If you are going to have a stand-alone set up you can choose Basic otherwise you need to make sure and choose advanced otherwise you will not be able to scale out infrastructure with additional servers. Next it provides options for the type of install required and in this case I selected Complete. The reason being stand-alone is essentially the same as the basic option on the previous screen. The other two options are Web Front End (WFE) and Complete and the only difference is if you choose WFE it doesn’t install some services that you may need later so the safe options is Complete.
Once the installation has completed I ran the configuration wizard, this will create the central application website. When you run the tool it will ask you if you want to connect to an existing server or you can create a new server farm. At this point I created a new server farm. The next few screens provide confirmation of the details entered so make sure and check them and only proceed if you are happy with them.
Configure farm settings
When I completed the install and configuration the next step is to configure the farm settings. The most common steps are adding any additional servers to the farm, configuring the services on each service, configuring the incoming and out going mail settings and creating a Shared Service Provider (SSP). There should be a helpful list of tasks on the central admin home page so take your time when completing these making sure everything is correct.
Create new website in IIS
Once the farm is up and running I created a website in IIS that I used for the upgraded site. This is an optional step as you can leave this till you are creating the web application and instead of pointing to this IIS website you can tell it to create a new one. The reason you may want to create the IIS site in advance is if you have any custom dll’s you want to drop in the bin folder.
Copy over customizations
This is not something I was required to do as part of my migration I the SPS 2003 site was built mostly out of the box and the only real customizations were made to the styling of the site and therefore didn’t require any changes to the existing templates. On a more complex site there could be many customizations that would need to be copied over to the new server such as custom site templates, lists and web parts so this maybe a step you that you need to do. There are lots of articles on updating site templates etc available to help with this if needed.
Configure upgrade files
Again this is something that I was not required to do when upgrade for the same reasons as above but if you have any custom site templates then you need to create your own custom upgrade files to tell SharePoint how to deal with these templates. You can find prebuilt upgrade files, which you can copy and edit under the 12 hive in Config\Upgrade.
Run the prescan tool on 2003 database
This is one of the most important steps that I performed and one that must not be missed out otherwise you will encounter problems when you try and upgrade. If you don’t run the tool prior to trying to upgrade you will get an error saying that the upgrade can’t be completed as you have not ran the prescan tool on the database.
Backup up 2003 database and restore it onto the new database server
The next stage I took after running the prescan tool on the database was to backup the database on the old server, copy it across to the new one and restore it. This is a common procedure that most support teams and developers know how to do so I won’t cover it in this article.
Mark existing content database as read only
Making sure that the users can’t update the content on the SPS 2003 site while I was doing the upgrade was important as I didn’t want to end up in the situation where I had to try and merge content from the old site to the new one. To achieve this I decided that the easiest way was to change the permissions on the old site so that all users only had read permission. This was the best option in my situation as most sites and areas all inherited their permissions from the portal so it was easy to change, however if you are in a situation where this is not the case then it may be worth while looking into another method.
Create a new web application
At this point I created the new web application pointing to the IIS website created in step 2. There are various different settings at this point which can be tailored to suit your needs such as if the site need to use an SSL certificate, the host header and location of the files on the file system. The most important section is changing the database name to point to the restored version of the SPS 2003 database. What happens when you click ok is it connects to the database and recognizes that it is in the old SPS 2003 format and it automatically starts to upgrade it into the appropriate format. As you might expect this may take some time if the database is quite large.
While testing on our development environment I did encounter one problem. After doing the upgrade a second or third time I started getting an unexpected error during the upgrade. When looking in the log files I found that it was throwing an exception when trying to find the site template with an id of 35. After much investigation on the web I found that the site template in question was the old bucket web used in SPS 2003, which was used as the parent container for areas. I managed to find a few people who had the same problem but there was no solution out there. In the end I decided to start from a fresh environment and uninstalled MOSS and started again. After re-installing and configuring MOSS I never encountered the problem again. Obviously in some cases this may not be an option but if you have no other choice then it may be worth a try.
Another problem I have seen on other blogs that can occur at this stage is that if the database is too large you may get a timeout error if you try and do the upgrade through central administration so if you do have this issue you can also perform the same step using the stsadm command line tool.
When I managed to get the upgrade to complete without and errors it got a screen saying that there is no new site collection create, however when I browsed to the URL the upgraded site was there so if you complete the upgrade and see this screen before attempting to debug what went wrong make sure and double check that it hasn’t actually created the site. If you do encounter any issues then check the SharePoint log files as they usually contained detailed information on the source of the issue.
Create new my site host
Now that I had the upgraded site my next task was to create a my site host for the user my sites. To achieve this I created a new web application then within that I created a site collection. Once the my site web application and site collection had been created I changed the my site settings of the SSP to point to the URL of my site web application. This approach can only be used if you don’t want to migrate any of the existing my site/ audience information. If you do want to keep this information then you need to still create the web application, however instead of creating a new site collection via central admin you need to create it via the command line using stsadm -o restoressp and pass in the name of the restored profile database.
Hopefully by showing you the steps I went through it has given you an indication of what you need to do when upgrading from SPS 2003 to MOSS 2007. As I mentioned at the start this is my own experience and realize it does not cover all possible situations but it should provide a good starting block for you to start analyzing and planning your own upgrade.
In BI and in SharePoint there is a great community which transcends the many partners, contractors etc.