SharePoint 2007 - Backup and Restore via stsadm.exe and a Warning About Using the -o setsitelock Flag

For a presentation to a client the other day, I used my "swiss army knife" VMWare image with SharePoint 2007 on it. However, I quickly needed to move a site collection from my MOSS instance to a new machine. There are several options to do this, including:

• Doing a SQL DB backup
  
• Using SharePoint Designer 2007 (which I occasionally use as it offers the most granular backup and restore options.
• Using stsadm restore functionality.
  

For backups of less than 15GB, stsadm is the simplest option. However, the simplest option isn't without its complications, even (or especially) if you follow the MSDN recommended steps:

1. As per the link below, the site should be made read only otherwise the backup may be corrupted (due to partial or incomplete writes to the content databases) . I normally just do a backup with stsadm without locking it first and it has never been an issue. Just to make sure, I followed the step by step instructions as per http://technet.microsoft.com/en-us/library/cc706871.aspx. One of the steps used: "stsadm -o setsitelock -url -lock readonly". The backup appeared to complete successfully (as I've done many times before).
   
   
2. Problem was that when my Oakton colleague Paul Rowland moved the site collection over to another virtual machine image (on MS Virtual PC) and tried to restore it, it was impossible to log in. Originally I thought the problem was due to the domain settings being different - but he couldn't log in even after changing the site collection administrator. The account was definitely not locked out and the password was correct as he had logged into and out of the machine with those same Administrator credentials.
   
3. I tried to log back into my original machine (where I made the backup) and I couldn't log into it at all - even Administrator gave "Access denied" on the site.
   

My knee-jerk response was "what on earth did the backup tool do to my backed up site?".

This problem occurrs because the backup process doesn't reset the readonly flag for you (which is fair enough). If you follow the steps exactly, you will have the same issue. What mainly concerns me is that I would expect a user to be able to log in at least - just not to manipulate the site at all - not to be denied completely. In summary, it would appear that there is no real difference between -lock readonly and -lock noaccess when setting a lock on a site. When the site is readonly, you simply cannot log in at all.

So the fix after restoring the site to the other machine (and my original VM image) was simply to set the readonly flag to none via "stsadm -o setsitelock -url -lock none"

After doing this, I also had to reboot for me to be able to log in to the site.