Share via

Reattaching a Content Database Containing Project Server Project Workspaces

  • Article

There’s occasions where you’ll find it necessary to reattach a content database containing a PWA site and its associated Project Workspaces. This is essential for Disaster Recovery, migration across farms, or repairing accidental contentDB detachments (or intentional ones – a lot of folks recommend disconnecting most/all contentDBs before applying a WSS/MOSS upgrade. I waive that best practice when the contentDB contains a PWA site – it’s not worth the hassle & risk). I’ve used two methods for reattaching following one of the above actions. They’re both imperfect, and both a little risky. Make sure to do a full system backup before proceeding, try it out in a Test/Dev environment if possible, and leave yourself sufficient extra time in your maintenance window for unexpected “fun”. Remember, there are 6 database references to any PWA site:

1-4: The obvious content: your 4 PWA databases. I usually name them

  • PWA_{PWA Site Name}_Archive
  • PWA_{PWA Site Name}_Draft
  • PWA_{PWA Site Name}_Published
  • PWA_{PWA Site Name}_Reporting

5: The content database containing your PWA site + and any project workspaces

6: Your SSP contains links to PWA sites

When you move or reattach your PWA site, you need to move, restore, or recreate all 6 of these databases.

 

Method 1: Quick and Dirty

Create a new contentDB or reuse an existing one. In the desired SSP, use the PWA admin section to create a new PWA (make sure to delete any existing ones that have been orphaned by your actions above). When filling in the name of the new PWA’s DBs, enter the names of your existing 4 PWA DBs. Watch your spelling (to avoid creating a new PWA DB set) and capitalization (to avoid cryptic ‘can’t find the DB’ errors). If you match exactly, the SSP will create a clean PWA site attached to your existing PWA DBs. If not, you’ll get a set of 4 new DBS and a squeaky clean PWA, or a failure message.

Method 2: The PWA Shuffle

1) Create a new temporary contentDB and attach it to the target web app

2) Recreate your PWA by going to the target SSP and creating a new PWA w/ the original URL, but pointing to the existing PWA DBs as in “Quick & Dirty” above.

3) Now you have a PWA, with broken Project Workspace links because the Project Workspaces were in the same site collection as your original PWA site… so, let’s get the workspaces  sites back by adding your original contentDB back to the target web app. If you look through the logs, it will fail to add your PWA site (since you created a new one in its place), but the Project Workspace sites will come back since they don’t have corresponding sites in the temporary contentDB, and your links will work

4) To clean up, use stsadm –o mergecontentdbs to move the new PWA site collection from the temporary contentDB into your new main one. Verify things look good and delete your temporary contentDB

5) Try to sleep at night, knowing that there may be vestiges of the original PWA site in your contentDB, duplicating your new PWA site. You should probably work with PSS to see if stsadm –databaserepair will identify the dupes as orphans, or see if they will help you do the necessary direct DB action to clean up (such as deleting the site entry in the DB, followed by a stsadm databaserepair to clean up orphan objects). Note – failure to clean this up may bite you in the future – especially when doing an upgrade or a future detach/reattach. Solve the problem now (with PSS) rather than experiencing a “cannot add duplicate site” error during a maintenance window.

6) You may also need to use the PWA relinker tool to re-establish missing links.

 

Technorati Tags: MOSS,Project Server 2007,SharePoint 2007,Tips and Tricks,Disaster Recovery,Uglier than I Wish