Migrate MOSS & MOPS 2007 With Workspaces

Steps to migrate Project Server 2007 with workspaces for the SharePoint Administrator

SharePoint 2007 and Project Server 2007 can be installed together in the same "farm" environment. This can provide a very powerful solution for both collaboration and Project management. But take care, there are a few things you really need to know about this marriage. This post only addresses migrating your Project server instance (PSI) from one SSP to another, both within same farm or a different farm such as; moving from Production to Development, Test or Staging.

For the general SharePoint Admin superhero, project server can be like Kryptonite, in that it makes the stsadm backup/restore feature useless on its site collection. I am going to share a few things that I have learned along the way.

1. When you create a Project server 2007 instance, a managed PATH is created automatically.
2. A site collection is created and visible from central admin in the site collection list. It is not you average site collection though.
http://CentralAdmin:port/_admin/SiteCollections.aspx?ReturnSelectionPage=/_admin/applications.aspx
3. You can not backup this site collection using the Standard STSADM -backup tools.
Now, I am told that a FULL Farm backup does capture Project server, but I have not had to test that theory out.
4. Run the Re-linker tool over and over... and over... and over...

As a SharePoint administrator of such a farm, you will undoubtedly, at some point have to rebuild your SSP, and or migrate your project server instance. This can be very painful, or simply a pain. For me, as I am sure it is for a very many people, it has been a learn as you go process. I have trashed my share of PWA instances before coming up with this procedure. I have searched all over, and found some very basic steps on what to do, but never any full start to finish article.

Migrating a SharePoint Web application from one SSP to another is a fairly straight forward process of reassigning association for the web application. And a PWA instance should follow its it parent web application through this process. But if it doesn't or there are other issues complicating the process. I would greatly suggest having your PWA instance backed up in such a way that you can re-provision it quickly, and lose no data. The procedure I outline below can also be used as your regular backup routine for Project server.

**************************************************************
Disclaimer:This is free advise given in good faith and NO guarantees. You may/maynot follow them. Choose to follow at your OWN RISK only. Always backup the farm and test in non-production environments first before affecting the production. This article assumes MOSS 2007 x64 Standard, Project server x64 2007, running on windows 2003 R2 x64, besides your familiarity with basic SharePoint 2007 Administration.
**************************************************************

1. Backup all databases and sites/workspaces that will be affected.
First thing to do is follow your normal steps for Downtime procedure.

Take the following backups:
a. SQL Standard backups of all Databases.
b. STSADM Full Farm Backup.

I have not found a need to backup IIS settings, or web.configs... The reason is, I force developers to make all changes to the web.config using WSP packaged deployments. But if you have all ready made manual changes to IIS, I would at least back up anything you have modified. But I really really suggest making those changes via package deployment, that makes your life SOOO much easer.

Backup Project web access DBs (Published, Draft, Archive, and reporting) using Standard SQL tools. This is needed mainly if you intend on moving the PWA instance to a new farm or different web application. If you are just moving the PWA instance with it's parent web application to a new SSP in the same farm, this step is not required, but is still advisable.

Export all PWA workspaces - (pick your own options, I use these)

- stsadm -o export -url "http://webapp/site/pwa/workspace URL/" -filename \\UNC\PATH\file.bak -includeusersecurity -versions 4

You can script this action once you determine all of the URLs and file Paths. be sure to catch subsites. However, I would suggest making it a policy not to have subsites on the Project workspaces. It creates added complexity when trying to recover from disaster. And even preparing for DR becomes a nightmare.

2. Create the new SSP

Configure the user profile import connections, and schedule, and any customizations that you may need to have ready to go. But be cognizant of your available storage, if you have the space available, you can go ahead and start up your new content sources, but at the very least, create search scopes, and best bets, keywords, targeted audiences, all of that has to be re-done by hand if you don't/can't restore a previously backed SSP, but backup and restore of the SSP is an entirely different article. DO NOT create a new PWA at this point.

3. Configure search, I hold of on crawling until the SSP is ready to use, but that is really up to you. If you know you have a lot to crawl, you may want to go ahead and start the process. But be sure you have the space for both your SSP search database, but also the search index that is propagated to your web front ends.

User Profile imports, I would run this in the new SSP just before actually moving the web applications over... Depending you situation, you can decide.

Also, any Special BDC settings, and other customization should be replicated in the new SSP.

4. Change association of the web application that the project server instance uses to the new SSP.

If all you want to do is move the current PWA instance and parent web application to the new SSP, then you can follow the normal process of changing the SSP association in the Shared service administration page "http://centraladmin:port/_admin/managessp.aspx" Once the association is changed it takes the PWA instance 5-10 minutes to re-provision/re-sync with the new SSP... Depending on your hardware, this could take longer, but remember, you shouldn't be doing this in a live system, you should be in a downtime window so that no users are affected. And that is that for a simple SSP migration, since you finished so early, you can take that backup from section 1. and restore it to a sandbox or another test system. Just to show off. :)

You may have restart the project server Queue service in windows if the Queue gets stuck because of the move.

5. Restoring a PWA instance to a New location or farm.

To this point we have been having fun... but now comes the pain.... Not really, but it all really depends on how many projects have been loaded in your instance... For a very large installation, I can see this being a very very big PITA.

So once you have all your databases, workspaces, and such backed up from step one. We must now look at the new location. If it is with in the same FARM, then most things are taken care of, but if you are moving to a new FARM, You are gong to need to verify a few things.

A. Check the Farm version, this can be done by accessing the Servers in farm page here: "http://Centraladmin:port/_admin/FarmServers.aspx"

Be sure that the destination farm is at least the same version or higher than the source FARM, SharePoint Products and technologies can upgrade incoming Databases, but will refuse databases with a newer schema than it is currently operating. But it would be best if the versions matched, much less likely to run into any issues that way. But if it is unavoidable, then it is what it is...

B. Verify project server is installed and the service is running on all WFE and APP servers in the farm. this can be done here:

"http://Centraladmin:port/_admin/Server.aspx"

Once you decide on the location, and have restored the project server databases to farms database server. You can go in and provision the new PWA instance using the Database names and server of the new farm. Once it is provisioned, its time to check a few things before having a Project Server Functional resource verify the configuration.

1. Verify cube build, if this is the 1st time you have setup project server in this new farm, then you will need to follow the original setup procedures of setting up the DSO share or using the OLAP database method... You can read about both here:

otherwise, just verify all the cube build settings, and run a test build.
2. Verify user accounts, and that the proper accounts are active. And that any AD sync is working properly.

C. Restore Project workspaces.

The is the task that I have found to be the "real" pain... if there are only a small number or projects with workspaces, then its not too bad. But most likely, as I have found almost every project has a workspace. And the PIC will want to keep them, even if they only have 1 document. But that's another battle entirely. For this article, we will presume that all workspaces have valid data and need to be migrated. There are several ways to go about this, but I am going to share my preferred method, as I think its the best way. :)

1. Create or run a script to create the blank project workspaces.
2. Run the Project workspace re-linker tool. - And run it, and re-run it, and run it again, until all sites are re-linked. It is necessary to run the relinker tool 1st because if run after the import, it will reset all the welcome pages to the default settings and look & feel. (based on themes, templates) RelinkAllWSSSites http://myWSSserver:80 http://myProjectserver/pwa
3. Import the workspaces using the STSADM tool.

D. Disaster recovery.
I must 1st stress the need for all SharePoint Administrators to know how to successfully back and restore their farms. The best method is the FULL method, FULL farm back and FULL farm restore. Get to know this process and set yourself up to be able to do it any anytime. It will take at least a few try's to get it right, but I would not feel comfortable until this procedure is stable and in place for the farm. Should you be in a position that you have to recovery all the project workspaces, and all you have is a DB backup or even a PWA site collection, This will work for you... But basically what you need to do is to restore the backup, either recreating the site and using the restored DB, or restoring from the site collection backup. The trick is to restore it to a new location, and export the workspaces from there, and importing them into a new PWA instance created using the backups of the PWA DBs.