My last post provided an overview of the available options to move PWA from one farm to another. In this post, I will walk through in more detail how to use the five database restore method to migrate a PWA instance from one farm to another.
First off, a disclaimer….if you plan to use this in a production environment, stop right now and look at using the Central Admin backup/restore method instead. In my opinion, that gives you a much better fidelity reproduction of your source environment.
If you’re only looking to move data to a virtual environment to provide a proof of concept or a demonstration environment….or if for some reason your other disaster recovery techniques have failed and all you have are the five databases to rebuild your environment, then continue reading.
You should also make sure to read Brian Smith’s blog post on caveats with this approach. This may give you a heads up on potential issues you may face. Once you’ve done that, feel free to proceed.
So the challenge I set before myself was to pull the five databases from the Contoso demo image and restore the full PWA instance to a target environment that I had built myself. The target environment was a slightly higher patch level.
1) Backup your source databases.
Open SQL Server Management Studio and identify the five required databases (Archive, Draft, Published, Reporting and Content):
Right click on the source databases, and select Tasks > Backup.
Save the files in a place you will be able to find them again.
Afterwards, you should have all of the databases in one location.
2) Restore the databases to the target environment.
Open SQL Server Management Studio in the target environment, right click on the Databases heading, and choose the option to restore the database.
Choose a new name for the restored database. In this case, I enter the name “PWA_Contoso_Archive.” Select the option to restore from a device, specifically the location where you have stored the source data.
3) Create a new Web Application.
In my target environment, I already have a PWA site created at http://demo/pwa. Hence, I need to create a second Web App to host the restored PWA. In this case, I will create a second Web Application at http://demo:81 and then I will put my new PWA at http://demo:81/pwa.
Note that creating the new Web App creates a new content database to contain the Web Application data.
As a best practice, you should always create a site collection at the root of the Web App. If you don’t you’ll run into issues when saving from Office applications or publishing forms from InfoPath.
4) Attach the restored content database to the new Web App.
Follow the instructions here to restore the content database to the new Web App. Kind of feels good to use STSADM again, I must admit. Thankfully, this is the closest I’ll ever get to being a developer.
5) Provision a new PWA site.
When provisioning the site, ensure two things:
- You use the same database names as the ones you restored.
- You use the same URL as the original….i.e. if the original was http://source/pwa, you’re restoring to http://target:81/pwa. Do not restore to something like http://target:81/pwa2.
6) Validate the new site.
At this point, you’ll want to take a tour of your new PWA site to ensure that all of the data transferred.
Navigate to the Project Center and click on a project to ensure the PDP page appears.
Next, click on the Server Settings and review the Project Sites.
Observe that all of the sites appear to be properly linked.
Finally, navigate to one of the project workspaces and click around to ensure everything works.
I noticed that adding a new issue or risk doesn’t seem to work immediately. Clicking on the link to add a new item yields an error.
To fix this error, simply click on the InfoPath Form option on the list ribbon, and then republish the form. The list will now work.
….and there you are, a restored PWA site using the five database backup/restore method.