Welcome to 







Have you heard about Swinging your SBS?
What is a Swing Migration?

The best way to find out it to look at Jeff Middleton's Website (MVP) at www.sbsmigration.com

Here are some facts:

Swing Migration is a process to accomplish either a version upgrade or server replacement migration without giving up the domain, or the server name, or the Exchange Information Store in the process, all while working offline with an open time line.

You get a clean server installation that retains all the critical Active Directory domain information is predictable. It's a method for bringing all versions of SBS, NT4, Win2K, or Win2003-based domains as upgrades to SBS 2003. Swing Migration solves technical issues, business interruption, and scheduling challenges. Construction is performed almost entirely offline, with an open-ended timeline. No repairs are needed if a problem halts the upgrade. Swing migration minimizes the preparations and changes to the production server, and that server remains in operation during the upgrade. Only during the final transition do you move the data and Exchange Stores to the fully constructed new server, which you then slide into service to replace the previous server. The domain accounts remain unchanged, you can keep the server name, and alternate paths in the process use the previous hardware. These upgrades have predictable outcomes; they are safe even for entry level technicians.

What is shown below is a diagram of the process, and further below is a simple outline of the process. [TempDC] Clean install a Windows 2003 Server (using SBS media) as a workgroup server only.
Manually join it to the existing SBS domain, preparing this server as a Temp DC.
Install DNS, perform DCpromo and designate as a Global Catalog Server.
Replicate DNS and AD then shutdown and disconnect
Seize all FSMO roles
Purge the Active Directory metabase and DNS of all previous Domain Controllers, Exchange and DNS Server references
[NewSBS] Clean install Windows 2003 Server just as before, reuse the original SBS Server name and IP. This server will look just like the previous SBS for name, IP, AD, and UNC/URL paths.
Install DNS, perform DCpromo, designate as Global Catalog Server.
Replicate DNS and AD.
Seize all FSMO roles, purge the Temp DC from DNS and AD
Finish normal SBS Setup using this Server
Complete the balance of migration of Exchange, all Data, and shared resources
If desired, perform a migration of the intact Exchange Information Store as a direct mount of the previous Information Store as if it were an offline restore. Reconnect mailboxes.
Perform a direct substitution of the new server for the old SBS
Deploy Applications as normal for SBS.

And now, thanks to Chad (MVP), here is a swing method for Companyweb
"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 going to 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 . . . :^)"

"The idea is quite simple - you have a working companyweb on your current SBS, complete with tons of documents in various document libraries, a few custom lists, maybe a forms library, etc. - you're moving to a new server and you want to move that site completely in tact . . . it's not an unreasonable request by any means - and luckily enough it is rather simple to accomplish - provided of course you know how to do it. That's where this post comes in :^)

Obviously, the first step to making this happen is to backup your existing companyweb site using smigrate as I've outlined in my previous post. The restore part is where everyone seems to be stumbling, so here's what you need to know:

First, it is important to understand part of what the smigrate restore does. When it connects to your SharePoint site to perform the restore, it is going to set the site template for the site based on the template that your backed up site was using. Now, with SharePoint - setting the template for a site is a one-time thing - once you've set a template for the site you can't reset it. The only time a SharePoint site is clean (e.g. does not have a template assigned to it) is right after Windows SharePoint Services has been extended to a website. The first time you access your new WSS site, you have to choose your template before you can begin using the site.

Most people who try to migrate their companyweb site using smigrate (or FrontPage) run in to this problem - their restore fails because the site is already in use. Specifically, the smigrate restore process cannot set the site template for the new companyweb site because it already has a template set. Sure, it's the same template as the one you want to use - but the restore process still needs to set it to be sure. As a result, the restore fails before it ever gets started.

So - how do we get the restore to work? Simple - we take the new companyweb site back to a clean state (where no template has been set). To do so, we simply need to remove WSS from the companyweb virtual server, then re-extend it. Now, before we remove WSS from the companyweb virtual server (on the new SBS server) - you need to be aware that this process is going to destroy this site (and all content). Most of the time this should be an empty companyweb - but just in case you have some content in there, either extract it or back it up first :^). So - your step-by-step process to get your new companyweb in a state that will allow an smigrate restore: (all steps are on the new SBS - assuming you have already completed the smigrate backup on the old server and moved those files to the new server).

1) Open SharePoint Central Administration ( under Start | Administrative Tools )
2) Click on 'Configure Virtual Server Settings'
3) Click on 'companyweb'
4) Click on 'Remove Windows SharePoint Services from virtual server'
5) Click to select 'Remove & delete content databases'
6) Click OK to acknowledge warning that you are deleting all content for the site
7) Click OK
8) When you return to the SharePoint Central Administration page, click 'Extend or upgrade a virtual server'
9) Click on 'companyweb'
10) Click on 'Extend and create a content database'
11) Select to 'Use an existing application pool'
12) Verify that the app pool selected is 'DefaultAppPool (NT AUTHORITY / NETWORK SERVICE)
13) Under the Site Owner section, enter the administrator email address for your domain
14) Click OK to extend WSS to the companyweb virtual server.
15) Once you see the page indicating the virtual server was successfully extended, click OK to return the SharePoint Central Administration
16) Navigate to http://companyweb, and verify that you get the Template Selection page. Be sure and close this window - DO NOT click the OK button as this will apply a template to the site and you will have to repeat these steps before you will be able to restore your existing companyweb site.

At this point, your new companyweb site is in a clean state, and you can use smigrate to restore your existing companyweb backup to the companyweb on your new server. Now, if you were using any 3rd party web parts on your old server, you want to be sure and install those on the new server before starting your restore. And if this is a swing migration, your original AD will be in-tact, and the smigrate restore will also restore all permissions for the site as well. Once the smigrate restore process has completed, there is nothing left to do - your companyweb will be back exactly how you left it - all permissions, settings, templates, etc. will all be there and you'll be good to go"









     ( )





                                                             This page was written and designed by Michael Jenkin 2011 ©