james mckay dot net

Sharepoint has two ways to transfer sites from one server to another: a web-based interface in Sharepoint Central Administration, or a command line tool called stsadm.exe. One of these methods is straightforward, reliable and simple; the other is a complete nightmare. Which do you think is the easier one?

“The web-based one!” I hear you all guess. “We don’t live in the dark ages any more! The days of typing obscure and arcane strings into a command prompt went out with the dinosaurs! Command prompts are for Linux hackers and Luddite nerds with too much time on their hands!”

Well, um, yes, that’s the theory. However, as with all things Sharepoint, it doesn’t work out that way in practice.

The web-based interface looks fairly straightforward at first. The backup option presents you with a long list of esoteric looking options on what you can back up and restore, but apart from that there’s not a lot to it, and within about ten minutes or so you have a directory on your server containing a stack of files that comprise ye backup.

So, you zip them up and deposit them on the new server and start up the restore wizard, and that’s where the fun begins. Chances are, straight away you’ll find it telling you that the backup doesn’t contain anything. It turns out that the backup directory contains a file called spbrtoc.xml which has buried in its innards the path to the subdirectory containing all the backup files. For some reason it is an absolute path, and in view of the fact that it is highly likely that this is different on the new server from what it was on the old one, you need to edit it. Go figure.

It doesn’t get any easier. Once you get it recognising that the folder you’re pointing it to does, in fact, contain a backup after all, it presents you with another bewildering array of options. You have to specify which URL to restore it to and umpteen IIS applications, application pools, databases, user names, passwords, and even where on the server to restore the databases to, and so on and so forth.

Once you’ve entered all the information into this great long convoluted form, you press OK and wait for the wizard to work its, erm, magic. The chances are that it’ll turn out to be a bit of a damp squib. Sharepoint needs write access to the backup directory to tweak the restore log files; if Sharepoint and your database are on different servers you need to be using a UNC path, otherwise one or the other of them won’t have access to the backup files in the same place; and there are a raft of other fiddly permissions issues that you need to sort out. So you correct them, and find that the next time you try it fails again because you hadn’t deleted the previous attempt from the list of tasks. Delete task, start over, make another mistake/discover another strange error, lather, rinse, repeat. On one occasion, we restored the content database and checked its contents in SQL Server Management Studio, only to find Sharepoint claiming adamantly that it didn’t contain any websites.

The fact is, there is so much scope to make a mistake here that it beggars belief, and if you’re not careful, you can spend literally days scratching your head over the event logs trying to figure out what on earth the problem could possibly be.

Now let’s look at the command line option, which you had probably written off in the first place thinking that command line options are for Linux hackers and Luddite nerds with too much time on their hands. It actually turns out to be deceptively simple. Once you’ve sorted out the small matter of finding stsadm.exe in the first place, and installed all the shrapnel that goes in strange places such as the GAC, obscure subdirectories of Program Files, web.config, and so on, you do

stsadm -o backup -url http://mysite/ -filename backup-filename.bak

on server A. This produces a single file containing your site and all the subsites, and you simply copy it over to and do

stsadm -o restore -url http://myothersite/ -filename backup-filename.bak

on server B.

Yes, that’s right, that’s it.

No XML files to edit. No permissions to set. No convoluted database options to put in. No failed previous attempts to delete from all over the place.

Just the backup filename and the URL, and you’re done.

The only thing I found was that for some reason I needed to create an empty web application and a site collection first, and restore on top of that using the -overwrite option of stsadm.exe, but apart from that, it worked perfectly. So perfectly, in fact, that we had to triple check that it hadn’t missed anything out or come up with some other strange gotchas.

Come on Microsoft, if you can make the command line option that straightforward, how come the web based version is such a minefield?!

[Update: It turns out that there is one particular permission issue that you need to watch out for. When you are restoring a backup onto an already existing site collection, you need to make sure that you are running stsadm.exe as a site collection administrator. Apart from that, it’s quite straightforward.]

Comments (4) »

Posted at 20:34 in SharePoint