lessons learned in my last sps to moss migration project using gradual approach

I have been doing a fun project for a customer, which asked to have his SharePoint Portal Server 2003 farms upgraded to MOSS 2007 using the gradual upgrade approach. I wanted to share some tips and things to consider when you are facing such a project.

1. remove unused and/or previous versions of webparts fom the SharePoint configuration.

There can still be web parts registered in SharePoint that have been physically or manually removed from the virtual server. Check stsam -o enumwppacks for any webpart packages installed that are no longer registered in the web.config files and so on. Know that when you start the upgrade of the web application, MOSS will try to upgrade all registered webpart packages and that if it cannot find it anymore, the process will fail and you zill not be able to upgrade the web application until you have fixed this. 

2. check if your IIS sites have not been renamed

Another one of those things to keep in mind is the fact that when the farm is created in SPS, it writes down the name of the IIS web site in the configuration database. The MOSS upgrade will use this information to find out which IIS site corresponds to the SPS sites. If these sites have been renamed in the meantime and you want to upgrade a SPS web application, then you can get a message indicating that there is nothing to upgrade or you will also not be able to find your SPS virtual servers in the MOSS upgrade pages in Central Administration v3. If for some reason you are in a farm scenario and your IIS site name has been changed on another front end server and not on the one you are performing the upgrade, then you will not get this warning, but the MOSS upgrade will not update the IIS site with the alternat url or port that you configure and you will therefore need to make the changes manually.

3. consider adding an additional frontend server to be used as the server that performs the upgrades

When you are ready to start upgrading sites, you need to do this on a server running the Central Administration role and the Web Application role. Do not think you can get away by using your index server to do your upgrades. The moss upgrade pages go through your IIS configuration to find the web applications that can be upgraded. If you are going through the upgrade pages on a central admin site hosted on your index server and net having the web application role, you will not find any web applications and/or site collections for which you can start the upgrade. Of course having installed MOSS on top of your existing front end servers, already bring an additional load to those systems and your users will probably start complaining with performance issues. That is why I would advise havin an additional frontend server installed in your SPS farm and use this one for performing the upgrades.

4. beware of the side effects of prescan

Another thing that surprised me in the project is prescan. This required tool suppoedly does not change anything to your sites. However it does. You know when you are viewing a list of all yous Document libraries and lists in your site, that it mentions next to each list when the last modification was done in that library or list (e.g. 6 days ago). Well running prescan will reset that information. So while it does not actually change any documents or lists, it does change the last modified date of the list or library itself. Knowing this may help you when you get your users on the phone complaining that all the document libraries have been changed all of a sudden (after you have run prescan)

5. there is no stsadm command to lock/unlock a site in SPS

damn, this is a bugger. Planning to script the upgrade of each site I found out that you cannot lock a site in SPS using the commandline stsadm tool. Apparently this was only introduced in MOSS. I found the solution in SPSiteManager (see my post about it)

6. Plan your content databases in MOSS

part of my project I was asked to have tha large databases in SPS, split up in multiple databases in MOSS. I did this by using the stsadm -o mergecontentdbs operation right after the site has been upgraded. Unfortunately you cannot choose wher the upgrade porcess needs to put the upgraded site collection. Part of the preparations to your upgrade is the fact that you need to configure a 1 to 1 relation of your existing SPS content databases to your MOSS databases, meaning that if a site is located in a specific content database, that its upgraded version will end up in the configured MOSS database and nowhere else (even if there is a parameter in the stsadm -o upgrade command that allows you to specify the targetdatabasename)

A piece of good advise: If you are planning to have more content databases in a specific web application in MOSS than you have in the corresponding virtual server in SPS, create additional empty databases in SPS to match the number of content databases in MOSS. It will save you a lot of trouble if you need to revert an upgraded site and reupgrade it again.

7. Check your upgrade.log file

Every action that MOSS does which regards upgrades of web applications, upgrades of site collections and even reverts of sites is logged in the upgrade.log file. If you have chnaged the default logging location in Central Administration v3 – Operations – Diagnostics Logging, then do not expect the upgrade.log file to be there as well. This log file does not leave the nest. You need to find it in the 12-hive Logs folder. A good practice would be to clear this file before starting the upgrade of any site.

8. Know how to rollback a failed upgrade of your SPS virtual server.

I had this issue that I was finally ready to start the upgrade of the web application and that during this upgrade process the well-known “unknown error occured” appeared. When I went back to the upgrade page, I was not able to rollback this operation or redo the upgrade. So what do you do next? the answer is very simple: delete the newly created web application in MOSS and every change made to the IIS sites (URL redirection) will automatically be undone as well.

I am sure that I can add some otherpoints to this list, but nothing comes to my mind on this sunny sunday afternoon. If something does come up I will gladly add it to this post and share it with you guys.

Codeplex SPIEFolder

Pfff, it’s been a while again since my last post. I promise you guys that I will have some time soon to write more. Anyway…

This post to write about a cool tool that my colleague Pascal Rocheteau found today: SPIEFolder from codeplex.

Project Description
Allows you to either Import a file system folder (And all files and subfolders) into a SharePoint Document Library, and also export a SharePoint Document Library to the file system for
WSS 2.0/SPS2003 or WSS 3.0/MOSS 2007. This tool completely replicates the document libraries folder hierarchy to the file system when exporting, and replicates the folder hierarchy from the file system to the document library when importing.

Sounds really cool and usefull. Thanks Pascal for this

 

SPS2003 Lock site using command line: SPSiteManager

yeah yeah, if you are used to working with MOSS, then you will probably tell me to use the command stsadm -o setsitelock -url <url> -lock readonly or something like that.

Unfortunately back in the SharePoint Portal Server 2003 and WSS 2.0 days, this operation was no yet available with stsadm…..along with a lot of other usefull commands

I needed to lock the sps 2003 sites in a gradual upgrade project to MOSS. Of course I want to script the complete migration, which also includes locking the SPS site before starting the upgrade.

Searching the web, I found my way to the SPSiteManager project on Codeplex 

In addition to the opeartions I was looking for, you also get the following operations:

Operation

Description

analyze

Enumerate all Content Database information and generate a Site Distribution Document

repartition

Re-partition sites to different content databases

enumsites

Enumerate Site Collections

Enumsitecrawl

Enumerate URL references from the list of sites to crawl

Enumsitedirectory

Enumerate URL references from a portals site directory

enumdatabases

Enumerate Content Databases

backup

Backup site(s)

restore

Restore site(s)

deletesite

Delete site(s)

adddatabase

Add content databases to a virtual server

addfromcrawl

Add site(s) to list of sites to crawl for SharePoint Portal Server 2003

removefromcrawl

Remove site(s) to list of sites to crawl for SharePoint Portal Server 2003

addfromdirectory

Add site(s) to Portal Server 2003 Site Directories

removefromdirectory

Remove site(s) to Portal Server 2003 Site Directories

locksite

Lock site(s)

unlocksite

Unlock site(s)

resetquota

Reset quotas on site(s)

purgeversions

Purge document versions from document libraries

Although these operations look a lot like the ones we get with MOSS, nowadays, they actually are much better. For example the operation to backup a site will actually also lock the site for read/write for you and unlock it when done. So before using this tool with all the operations, be sure to check out the well written manual that is included explaining each operation.

 

SPS2003 Add Link to Site not working

Why might this be relevant to a MOSS admin. Well, you might be busy upgarding a SharePoint Portal Server 2003 environment to MOSS using the gradual approach, like I am. Off course you would test thjis on a test farm and reproduce your production environment in a somewhat representative way. In my case a imported only a couple of production sites in my test environment, which could be considered as logical.

Now, the thing is that I tried crawling the SPS content with my new MOSS farm and the crawl uses the Site Directory on the SPS Portal to anmalyze which sub sites it needs to crawl. Clearly the Site Directory was not reflecting teh istes I had on my test environment. So I cleaned out the Site Directory and wanted to add Links to the actual sites on the SPS application.Guess what, I was unable to. Apparently this is due to SP2 for SharePoint Portal Server 2003.

Thanks to this blog post I found the solution:

1. Open this file in a text editor:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\[LCID]\SPSSITES\LISTS\SITESLST\NewForm.aspx
(Replace [LCID] with your locale identifier, 1033 for English)

2. Find this code fragment:

<SPSWC:InputFormButtonSection runat=”server”>
<SPSWC:InputFormButtonAtBottom ID=”ButtonOk” runat=”server”
TextLocId=”Page_OkButton_Text”/>
<SPSWC:InputFormButtonAtBottom ID=”ButtonCancel” runat=”server”
TextLocId=”Page_CancelButton_Text” visible=”false” />
</SPSWC:InputFormButtonSection>

3. Replace it with this code fragment:

<SPSWC:InputFormButtonSection runat=”server”>
<!– Workaround for WIN2003SP2 issue: http://support.microsoft.com/kb/934229
–>
<input type=”button” value=”         OK         ”
onclick=”document.forms[0].submit()” />
<!– <SPSWC:InputFormButtonAtBottom ID=”ButtonOk” runat=”server”
TextLocId=”Page_OkButton_Text”/> –>
<!– End workaround –>
<SPSWC:InputFormButtonAtBottom ID=”ButtonCancel” runat=”server”
TextLocId=”Page_CancelButton_Text” visible=”false” />
</SPSWC:InputFormButtonSection>

4. Thats it;-)