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 FilesCommon Filesmicrosoft sharedWeb Server Extensions12BIN>stsadm -o export -url "http://brismithv0832:8080/CAL/Project1 with Workspace in PWA" -filename "Cbackupsavesite.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.