***Update – for a detailed step by step document for moving from one domain to another take a look at http://blogs.msdn.com/brismith/archive/2009/06/22/project-server-2007-migration-from-one-domain-to-another.aspx ***
This is a request I have had a few times, most recently from Dan, and I have decided to do this in two parts. The first here, is a high level view, and I will follow this, hopefully within a week or so, with a more detailed description of the steps involved. Ever system has its own idiosyncrasies and customizations so no guarantee that these steps will get you exactly where you need to be, but it should get you pretty close.
I will present a couple of options, the first based on the SharePoint full farm backup and restore – then the second based on taking the 4 project databases and the content database containing the project workspaces and provisioning a new site against the project databases and linking to the sites in the content database.
The key to both is having an image (Hyper-V would be ideal) ready to accept the restore method which works best for you, then always return to this image when you want the next transfer of production to test. Obviously the image needs to be kept up to date with patches etc. to at least match the production system.
Full Farm Backup and Restore
This really offers the best option to get almost all of your farm across in a way that matches your production system. Any basic customizations will come across with the backup – such as tailored menus, change of theme etc. Problems will be encountered if you use host headers. In this case you receiving image should just have Project Server installed and the SharePoint configuration wizard completed to the point that Central Administration is available – from here you just do you restore, and substitute the URLs and database server names for your test system. This assumes the same user names will be accessible from your test environment – if not see Part 2 for some workarounds we use when recovering customers’ systems for testing.
I have never seen partial farm restores work for me – so when you next want a snapshot of production do the whole thing again – starting with a saved image ready with Central Administration ready to go!
Database Copying and Re-Provisioning
If you can live without the project workspace functionality (Issues, risks, documents and deliverables) then this is really easy. Just restore your 4 project databases to the test system then provision a new site and point the provision job at the 4 databases you have restored. The user you name will get created, so no issue with different domains – then with this user you can update any others you want to test with.
If you do need workspaces then this fits into the “I wouldn’t start from here” type of directions. The default location of workspaces will mean they are created in the same content database as the PWA site itself. So if you copy the content db from production to test you have all workspaces readily available – but of course PWA will not work as the site is not plumbed into all the right places until you provision a site. The action of provisioning the site needs /PWA to be removed first – so goodbye to all the workspaces if they happen to be under /PWA (which by default we lead you into this bad situation). Options here are to provision the site somewhere else – but then it doesn’t match production so isn’t a good test platform. So better to start from the right place – on the production server have the workspaces in a different content DB from the site itself – then both the workspaces and the /PWA are independent and can be brought together in test without breaking anything.
With this type of restore and re-provision you will not maintain any WSS customizations on themes etc. but Project customizations will be kept (menu changes etc.)
Some things don’t come across with either of these approaches and will have to be handled manually. A couple of examples are server side events, which will need to be re-installed in the test environment, and any custom web parts will also need to be re-installed.
I will get into more detail with Part 2 – but hopefully this has given you some ideas of the best approach – and both are approaches we do on a daily basis for those cases where we need to reproduce customer’s problems with the customer’s actual databases – either full farm or limited set of databases.