I will be going deeper in this posting, particularly on the scenario of moving just the databases and then re-provisioning the site. But don’t expect me to be mentioning every single dialog box and permission that you require. I will be writing at a level whereby if you don’t understand what I am saying then perhaps you shouldn’t be doing this – or at least you need to read around a bit and then come back. For permissions see this blog posting, and for full details of full farm restore go here. Remember that any additional Process Accounts added to the SSP must still exist and be verifiable in the new system. Forgotten this one? Then go here.
So the only extra I intend to say about full farm backup and restore is that it does not keep such things as LDAP forms based authentication extended sites and settings (Thanks Boris Bazant for this tip!). As I mentioned in my part 1 post – some external customization will need to be re-applied (e.g. additional web parts, server side event handlers in the GC).
The scenario for the main part of the post is moving from my Production Server (BriSmith620) to my test system (A Hyper-V image called BriSmithV0832). I already have a working site which I don’t want to break, so this is a partial move – and the projects in my Production Server have workspaces both in the root site under PWA (the instance I am interested in is actually called CAL – created to troubleshoot some Calendar issues) and in another web application at Port 94. So I will be moving over 4 project databases and 2 content databases. I can’t move my port 80 to port 80 as it will break existing stuff – so I will move 94 to 94 and 80 to 8080. I have Issues lists with items in several projects – the aim will be to see these still working post migration…
I’ve already backed up my 6 databases – and restored them with names Blog_Archive etc for the Project ones and Blog_80_Content and Blog_94_Content (actually on the same server with different names) so on with the restoration of my PWA site and content. First I just provision a site against the 4 databases. If you have restored the content db at this point it will fail – if you use the same name for the site – as a collection will already exist. And if you delete the site away goes your content – Catch 22. So we are leaving the content stuff for now…
Usual stuff is entered for creation of a site
Click OK and wait for it to be provisioned…
And here we have it! (Must get round to those timesheets) Any customizations we had made in SharePoint would be gone (themes, top links etc.) but customizations in PWA would be retained (Notice the My Timecard edit to the menu name in the left nav bar). But of course none of the workspaces are found, and the issues and risks link also find no active issues for me.
Next I will add the port 94 content db to a new Web Application on Port 94. I create a new Web Application and name the database the one I have restored. Didn’t bother with a screen shot, just changed the port to 94, put in a suitable account for the new application pool and put in the Blog_94_Content database name. Once this is active I can browse to the workspaces (assuming I know the names) and the issue is there – but clicking through to the issue detail gives a File Not Found SharePoint error.
The workspaces listed on the home page don’t link to port 94, but port 80, and the Project Workspaces page shows blank for the sites. By going to the Edit Site Address option the site can be entered for the project.
Once this is set and the workspace provisioning setting matched to the port 94 address that was in use on the other server the home page then shows the correct links and sees that I have active issues.
If I follow the link to the workspace, then the issues and click through to the issue detail it works – the file not found is resolved!
For larger jobs than this simple set of Projects the RelinkAllWSSSite tool from the Project Resource Kit comes in very handy. Now we have our port 94 sites all sorted – and we could just do the same for our ones that were on port 80 – and leave them on port 8080 – but that doesn’t get them back were they started. Stsadm export and import comes to our rescue. First I will add a new web application on port 8080 and use the port 80 content database from the original server. At this point we can browse to the sites just substituting http://brismithV0832:8080 for http://brismith620 to confirm they are there. To export and import we use stsadm –o export –url <full url> –filename <path to save site> –includeusersecurity –nofilecompression. In this case
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\BIN>stsadm -o export -url "http://brismithv0832:8080/CAL/Project1 with Workspace in PWA" -filename "C\backup\savesite.bak" –includeusersecurity –nofilecompression
***UPDATE*** Flag –includeusersecurity was not in the original posting. This ensures the same security applies to the site and this then means any assigned issues, risks will be flagged on the users home page.
If on Windows Server 2008 then your command prompt will need to be running as administrator to avoid an Access Denied.
You will get a long listing of progress (or you can use the –quiet flag) and hopefully it should finish with success!
Now we can import, just using the default port 80 address to get our site where we want it (just change the URL and export to import. In my case I can also change CAL to Blog in the URL as my PWA site has changed. Once this is complete we have the site where we want it – we edit the site address as we did earlier and all should be working!
Along the way with the export/import we lost the task links – I will dig into this a bit more but I guess you might expect this as the export probably has nowhere to keep that information, and also I see my Active Issues count isn’t picking up the moved workspace issues. The best approach is certainly keep the workspaces away from your PWA site to start with. But the issue is still there – it still understand which project it belongs to.
I’ve stepped through with a single project so you understand the idea – you can speed things up with Powershell or just creating a batch file. If you go this route then stsadm –o enumsubwebs –url <url where sites are> >> c:\sitelist.txt will enable you to get a quick list of sites into a text file.
Every requirement will be slightly different – full farm backup/restore will hopefully work for most, but the details I’ve given here should help when you want perhaps a partial move of single instances. Always consider customization too – usually you will need some manual steps for those.
Let me know how this works for you.
***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.
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!
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.
Christophe has a great blog with full details of the KB’s for WSS (KB956057) MOSS (KB956056) and Project Server (KB956061) which are now available. Everything you need to know about the August Cumulative Update is there – links to articles, links to the hotfixes and some guidance on installation!
***UPDATE*** Now public - see http://blogs.msdn.com/chrisfie/archive/2008/09/26/announcing-the-release-of-the-august-cumulative-update-for-project-and-project-server-2007.aspx
The overall KB for the August Cumulative update has been updated, and now includes the KB article numbers for each individual product in the suite of clients and servers. It is titled Cumulative update packages for August 2008 for the 2007 Microsoft Office core suite applications and 2007 Microsoft Office servers and can be found at the following location.
Please note that not all of the referenced KBs have ben published yet (WSS 956057, MOSS 956056, and Project 956060 and 956061 are not published as of 9/11/08) so not all are live links - but this would be a good KB to bookmark and visit to get the latest on the details of what went in to the August CU.
I know it has delayed some of our customers from deploying this hotfix as the documents detailing the fixes have not been available and please accept my apologies - but the change in process to the cumulative updates has put a bottleneck into the KB production as so much needed documenting in one go. Hopefully by the time we release the October CU we will have ironed out this problem and will sync the release and the docs much better.
We had a question recently regarding having multiple servers each with some custom server-side event handler code registered and running the Project Application service. Should this work? My immediate answer was yes, and I was fairly sure I had done this in the past but wanted to double check. So I installed the event handler I blogged about recently that did the automatic publish after status updates were applied - http://blogs.msdn.com/brismith/archive/2008/05/06/how-to-ensure-your-accepted-updates-get-published-in-project-server-2007.aspx. This handler does its stuff but also writes to the application event log. So In my twin application server farm I pushed through a few updates and accepted and applied them - and each of my servers took a turn at the event handling. I saw the application event log entries alternating between the two servers - so everything was working just fine.
But remember - it might make more sense for any logging in a complex farm to go to just one central location, or at least duplicated. Another thing to ensure in this type of scenario (which I think was the problem the customer may have been seeing) is that any other files the custom event handler needs should be applied on both servers. So if the event handler needs a setting file to get a URL or GUID to ensure it is working on the right site or entity - the setting file had better be where the event handler is expecting it to be - on each server - or one network location available to each. And for both settings and logs - ensure your code copes with any contention if you do centralize to a single log or settings file.