SPSiteManager - important bugfix!
Someone notified me of a problem in the current public release of SPSiteManager that is currently available in the SharePoint Utility Suite at https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724
There are three main steps to repartition sites as follows:
- Backup the current site
- Delete the site from the SharePoint Virtual Server
- Do wicked change on content database management settings to prepare to target the site into a specific content database (See the SPSiteManager documentation in the package if your curious)
- Restore the site from the backup.
- Reverse wicked content database management settings changes.
When your using SPSiteManager to repartition sites, if you specify the -backupdirectory option, then all site backups are preserved into that directory.
If you DONT specify the -backupdirectory option, the temporary backup made in step 1 is deleted after it is restored in the targeted content database. This happens in the finally{} section of the try{} block surrounding this operation to cleanup.
The problem, is if say the Restore failed (for whatever reason!) The temporary backup would be removed regardless. Thus, you loose your site completely (Now you have to revert to previous backups to get it back YUCK!)
The Site Backup(), Delete(), and Restore() methods do not return until they are completely finished, thus you have no idea of the progress, or if there was a problem until the return to the caller. Then it can be too late :). If it fails, it throws an exception.
I added a boolean to check to ensure that the restore REALLY did succeed before removing this temporary backup right after the Restore() call.
There are other changes in the attached files to implement Site Locking of the site before backing it up (Based on recent recommendations in the Admin Guide)
Attached to this post is an updated AppClass.cs file to update SPSiteManager with these extremely important changes, until I can get the updated SharePoint Utility Suite package updated on the web. You can also update the AssemblyInfo.cs file with the following to match the current internal version.
[assembly: AssemblyVersion("1.3.*")]
The changes are minimal but important, and I still need to do throughough regression testing before I update the package, but felt this was important enough to share at this time.
Cheers,
Keith Richie