Just another Microsoft MVPs site

Eureka!

I need to come clean – let everyone know my dirty little secret . . .   I’m a procrastinator.  Not just a little one – nope, no-sir-ee . . .  I’m the king of procrastinators.  Sure, I have plenty of work to do and more than enough to keep me busy – but I have a tendency to just put some things off until the last minute . . .


Well, my latest task that I’ve put off until the last minute has been my presentation for SMBTN (which is where I am composing this post . . .  oops).  Lucky for me, there was a schedule change, so my presentation was moved from today (Friday) to tomorrow – which has worked out in my benefit – and here’s why:


My planned presentation was on Backup, Restore & Disaster Recovery of Windows Sharepoint Services.  Now mind you, I’ve done a decent amount of work with Sharepoint, and I’ve even done a couple of restores, and moved a few sites as well.  Now, each of those restores were full-server restores, and the moves were for servers that we swung.  Well, I was working through the various options and realized that there was a scenario that I hadn’t personally dealt with previously.  I had not been in a situation where I needed to perform a stsadm based restore of a site without restoring the entire server – e.g., restoring a Sharepoint site to a different server using stsadm.


So, I loaded up a couple VPC machines – one SBS Premium & one Windows 2003 Std with WSS installed.  Well, I populated a site, took an stsadm backup – no problem.  Then I tried a restore of the site on a different machine, and you know what – it failed.  Well, that couldn’t be – so I googled stsadm restore, and verified I was following the right steps . . .   sure enough, I was – but it still wasn’t working.  I was getting errors about the site not existing, or unable to connect to the config database, or that the website was already in use, blah blah blah . . .


So I did some more research, and the short-story I discovered is that in order for an stsadm restore to work, you have to do a full system-state restore and be sure to restore the STS_Config database too.  So what is the issue with this?  Well – what happens when you have a true disaster such as a fire and your server is toast.  Not only that, it’s a few years old and you can’t get an exact hardware replacement?  Have you tried doing a System State restore to different hardware? 


At this point I had to go for a walk and sort this out.  Surely Microsoft couldn’t have painted us back into a corner like this . . .


All I could think about what FrontPage.  I have used FrontPage to move entire Sharepoint sites between servers via it’s built-in backup & restore, and it works so slick.  The down-side is that you can’t automate FrontPage to use it as a backup tool.  I kept thinking that if there was only a way to use the FrontPage backup functionality without FrontPage . . .  so I could schedule it, and automate it, and have a solution that I *know* works . . .


Well, you know what?  It turns out that you can.  There’s this nifty little command-line tool (very similar to STSADM) that gets installed when you install Windows Sharepoint Services.  That tool is smigrate.exe, and it lives in the same directory as stsadm (c:\program files\common files\microsoft shared\web server extensions\60\bin   by default).  And the cool thing about smigrate?  It is a command-line version of the backup/restore functionality that we find in FrontPage. 


So let’s connect the dots . . .   If I schedule a backup of a Sharepoint site using stsadm, then I can restore that site – but only if the destination server has the same system state and STS_Config database as the original server.  Not normally gonna happen in a disaster recovery scenario.  OR – I could schedule a backup of a Sharepoint site using smigrate, and get a backup set that I can restore to any site on any Sharepoint server at any time, without having to worry about system state or the presence of other databases such as STS_Config.  Take a guess what I’m going to be using for my scheduled Sharepoint backups going forward . . . .   :^)


Now, I still have some testing to do to make sure permissions and security are restored with smigrate, but even if they aren’t – I’d rather have a backup/restore option where I know I can get all of my content back and *maybe* have to reconfigure permissions versus a scenario that should restore permissions, but that I can’t get to restore anything . . .  :^)

6 Comments

  1. Amy Babinchak

    Got a problem, I’m hoping you can point me in the right direction. I’ve used the smigrate to move companyweb from one SBS server to another. I get the error message below when attempting to view the default page. I’ve gone into the web parts manager and disabled any web parts called error. That just leaves the default web parts. Still no go. Then I installed the google web part to the web part library. Still no go. How do I disable this web part so that I can see the home page? Other pages with 3rd party web parts are exhibiting the same behavior. Alternatively what do I need to copy over from the old server to get the web pars to work correctly at the new server? Couldn’t find this in a kb article and was hoping you might know the answer.

    The Castle.WebParts.GoogleSearchWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=37780cc265a3a117 assembly specified in a Register directive of this page could not be found.

    Web Parts Maintenance Page: If you have permission, you can use this page to temporarily disable Web Parts or remove personal settings. For more information, contact your site administrator.

    Troubleshoot issues with Windows SharePoint Services.

  2. Don Murphy

    I used Frontpage to move my Sharepoint to a new server that was configured with swing migration as well. I can restore to any part of the site but the “default site” presumably because of a template?

    Any idea how to remove the template?

  3. satish

    i m too facing the same problem if u got the solution for this then pl do tell me too. thanks satish london
    mail me at
    sddelhi@yahoo.com
    satishdudeja@hotmail.com

    Got a problem, I’m hoping you can point me in the right direction. I’ve used the smigrate to move companyweb from one SBS server to another. I get the error message below when attempting to view the default page. I’ve gone into the web parts manager and disabled any web parts called error. That just leaves the default web parts. Still no go. Then I installed the google web part to the web part library. Still no go. How do I disable this web part so that I can see the home page? Other pages with 3rd party web parts are exhibiting the same behavior. Alternatively what do I need to copy over from the old server to get the web pars to work correctly at the new server? Couldn’t find this in a kb article and was hoping you might know the answer.

    The Castle.WebParts.GoogleSearchWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=37780cc265a3a117 assembly specified in a Register directive of this page could not be found.

    Web Parts Maintenance Page: If you have permission, you can use this page to temporarily disable Web Parts or remove personal settings. For more information, contact your site administrator.

    Troubleshoot issues with Windows SharePoint Services.

  4. Tim Burnett

    I was hitting the “…website is already in use.” message back from stsadm -o restore
    and googled my way here, but then I remembered that if you add the
    -overwrite
    flag it will restore over an existing content database just fine.

  5. Tony Van Vugt

    The problem with smigrate failing, and the gui backup/restore function in FP2003 that also uses it, is that if you have the ‘allow subsite creation’ switch turned off in the virtual server ‘site rights’ all backup and restore functions fail with smigrate. Took me all day to figure that out. Hope this helps others.

  6. Nigel Mahon

    Interesting piece on smigrate.exe – did you find out if security is migrated and did you find any downsides with using smigrate.exe.
    Im looking at automating backups, i’m currently using frontpage to manually backup.

    nigelmahon@hotmail.com

Leave a Reply

Your email address will not be published. Required fields are marked *