Re: Migration from SBS 2000 to SBS 2003 on new machine?

From: Jeff L (***jeff_at_availabletech.net)
Date: 08/12/04 

Date: Thu, 12 Aug 2004 16:22:59 -0400

Jeff...

If you want another reviewer. I would gladly spend a weekend running through
the process three or four times. Thanks for the information.

Regards,

Jeff Loucks - jeff @ availabletech dot net
       Available Technology ®
            Solutions For Professionals ®
                  www.availabletechnology.com

"Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
news:ueLtT7HgEHA.3536@TK2MSFTNGP12.phx.gbl...
> Yeah, I've touched on the use of VPC (or server) as part of a migration.
> There's really not a lot special about the process of using VPC that
> differentiates it from the larger plan. Wayne Small (SBS MVP) has done
some
> migrations using a VPC as the pivot, and I've explained briefly how that
can
> be done in my text. It's sort of nifty to bring in a new box and use VPC
to
> solve the pivot point without yet another computer.
>
> Right now, the main thing I'm focused on is pushing MS to designate the
> "method" as a supported upgrade process. That will make all the difference
> for the real-world professional. I should add that not only am I getting
> cooperation from many people in the SBS team, the attitude is very much a
> desire to support this if they determine that it can be supportable for
> them. But therein are a lot of considerations. Not the least of which is
> whether or not they feel that can/would train all the SBS PSS team to take
a
> call on this and respond with "oh, sure, ok...let's see where you are
> stuck". I'm not sure it's really apparent to the public how complicated it
> is to get MS to embrace something like a new migration method without some
> exhaustive investigation, and even then, to decide if it fits their
support
> model. I'm really fortunate to have some good friends and contacts across
> the SBS team looking at this from Dev, Test, PSS and Marketing viewpoints.
> In the end, it's really not going to be a question of does this technical
> process to move a server installation work. It's a reasonable possibility
> that MS arrives at a conclusion like "yes it works, no we won't support
it",
> or "yes it works, but only in the nn% of our customer base and that's not
> high enough".
>
> For MS the challenge there is somewhat less a question of whether or not
the
> method provides a reproducible solution, rather, it's a question of how
many
> problems can be created by starting down the path and getting it wrong
> somehow, or having an infrequent pre-condition as a complication...what
are
> the recovery processes, how to get back on course, how to determine where
> the break from the process occurred, and if all of those can happen in a
> manner that looks supportable. There's a big difference for MS between
> whether an expert can perform a method vs. if MS wants anyone with an SBS
> license to have the expectation that if they get in trouble, MS will pull
> them out of the ditch and _then_ help them complete an expert method, as
> opposed to just saying "we can only help you do a Disaster Recovery back
to
> a supported condition".
>
> The way that I've outline the upgrade process, it's extremely safe, that's
> pretty clear once you see the outline. In general, 90% of the steps are
> performed in a manner that if you get totally hosed, your fall back is to
> abandon the migration by doing nothing more, or start over. You production
> SBS remains in a supported condition the whole time. The migration is 90%
> offline and parallel construction, so the production SBS is operational
the
> whole time in an unincumbered condition you could run in forever, or
choose
> a different migration option from there, such as ADMT.
>
> As such, I've documented a process that preserves a fallback to all the
> alternative migration options you had before you started, it can be
> abandoned if you feel like you are way over you head, or run into
something
> that you can't overcome. Essentially, until the day you decided to put the
> new server in service, the only modifications you have made to the
> production SBS 2000 (or whatever) is to add Win2k SP3 or higher, Exch2k
SP3
> or higher, removed Exch IM, and run Adprep to add a Win2003 DC. Those are
> really trivial changes. With the balance of the path defined as offline,
you
> can pursue it however you like, including VPC as your preferred tool, or
> not.
>
> The bottom line is that, short of MS identifying something I've documented
> as being a flatly illegal process or a liability to me on a personal level
> (neither of which are likely), the documentation of this method will be
> published, even if MS doesn't want to support the process. It's an expert
> method, that's how it is presented. If MS embraces it, I'm ecstatic for
what
> that means to a lot of people out there. If MS doesn't embrace it, it's
> still going to be used by many people regardless, and not because I
document
> it, rather because there are experts besides me who are figuring out how
to
> do this because it makes sense to do it this way if you have the skill to
do
> it. I'm just trying to reduce the skill level required to discover a
> relatively safe and workable path.
>
> I believe there are too many people who want an option like this, and who
> would be totally willing to live with proceeding with a method that
doesn't
> include the option to call MS for help if you get stuck. I didn't document
> this with the expectation MS _would_ support it, I've only hoped that to
be
> the case. But from my perspective, it's more valuable if MS will get on
> board. Therefore, it's possible that a debate on steps may yet occur, "do
> you install DNS here, or not until here...do you do this step and reboot,
or
> just go to that step and wait for an event log item to post first" ....any
> such little item could become a recommendation I get back from the MS
review
> currently in progress. Therefore, I'm holding back on describing literal
> steps for now because some of the most experience people MS has in the SBS
> team are reviewing this. Obviously I want to include their thoughts and
> guidence before releasing details on the web. It's sort of difficult to
undo
> a post in Google. :)
>
> Let me cover some stuff I can talk about now.
>
> Once it becomes available, what you will see is (currently final at) just
> under 100 pages of total related documentation. But for comparison, it's a
> much more detailed reference than the MS whitepapers for ADMT, you won't
> mistake this for an MS whitepaper. It includes comparitive analysis to the
> alternative migration methods, looking at pro's and con's. I've outlined
an
> expert summary in a couple of pages you can read in under 10 minutes,
> followed then a total vision of the process as an educational background
> reference, and then again separately as a step-by-step guide. By the time
> you finish, you have seen it described three times, just in different
> context with each pass. A lot of the information covers familiar ground
> regarding baseline Windows installation steps required, as well as
> documenting your existing domain and such preparations. There's probably
> less than 8-10 pages of information at the heart where you will look at as
> "new" process you probably haven't actually done before. Those steps are
> described quite literally as keystrokes.
>
> It's fair to say that the very first time you go complete an upgrade by
this
> method, you probably will need 8-10 hrs time to get comfortable moving
> through the steps, but that also includes about 3hrs of watching SBS
> install. Several of us have then done the second attempt with no advanced
> preparations in about 4-6 hrs, plus whatever time for moving data you
need.
> Stating that differently, figure it takes about the same time a clean
> install to a new server, plus about 2-3 hrs of migration process steps,
plus
> the data transfer time dependent upon your preference of transfer method
and
> volume of data you are moving.
>
> The flipside insight is that I've done migrations myself that spanned a 1
> day sequence like I just identified, and I've also:
>
> - Spanned 3 weeks of transition on a production domain (time from when I
> pulled the AD off until the day I put the new server online) because I was
> coordinating the installation with other stuff, so I was able to get the
SBS
> migration completed in advance and just sit on it. That migration included
> reusing the original server chassis and drive arrays, but upgrading the
> motherboard from Uni-Processor P3 to Dual Xeon.
> - I've done migration preserving an NT4 domain where I literally didn't go
> on-site until after the new SBS was built...this by building a VPN to
> effectively establish a remote site-to-site domain link. This included a
> required namespace change due to non-conforming characters in the server
> name, but we preserved everything else.
> - In support of similar upgrades, I've alternately moved data with XCOPY,
or
> snapped the previous production drives over, or used drive imaging, or a
> tape restore. That's wide open. How you handle Exchange shift isn't
actually
> fixed in this process...you have options. I've discussed a forklift move,
as
> well as Exmerge. How you handle the timeline, really up to you. I've tried
> to illustrate a core path from which you can flesh out your own comfort
> level on a feature by feature basis...but I'm showing how to build in an
> existing domain, keep the original SBS servername, domain name, and IP the
> same, and keep the AD effectively intact, and a technical option for
moving
> the Exchange Store intact.
> - My production original SBS 2000 server sits in a cold drive with an AD
> that is beginning to look like a Borg. I've intentionally not cleaned it
up,
> yet I've done about 4 different passes of this migration against the same
> original AD. In doing one migration I actually tried doing it without the
> documentation in front of me, just to see if my instincts took me in a
> different direction. In fact, I missed something and ultimately completed
a
> full migration despite experimenting with a full DCpromo demote and
> promotion again on my new server during the transition steps. All of this
> was to try breaking it. Along the way, I just keep taking notes of what
> happened and what resolved it.
> - As an experiment last month, I rebuilt my own domain from a 4 month old
> drive image of the SBS 2000 as a disaster recovery implementation. In my
> case, I'm using the Exchange Org namespace I originally defined in SBS 4.0
> which isn't what SBS 2000 or 2003 use, but I have the same Information
> Store...now itsn running on it's 4th platform/version change. In this
> instance, my Information Store was sitting on a drive damaged in a
lightning
> storm that would neither backup or xcopy, and went BSOD on startup because
> the System hive was corrupted. I had to used Steve Gibson's SpinRite to
> scrape the Exch log files and databases off the drive in the first place,
> but the registry and an incremental Disaster Recovery backup on the drive
> were both damaged beyond repair. (the backup on the same drive was a
matter
> of convenience, not a best practice.) I decided to see if I could save the
> Exchange in that "as last mounted" state, rather than roll-back to a
> previous backup. I pulled the MDBDATA intact from the old platform, then
> completed the ESEUTIL repairs after rebuilding the server. In process, I
was
> also shifting from PIII /EIDE server to P4/SATA hardware. So that was a
> simultaneous hardware shift, SBS 2000 to SBS 2003 platform upgrade, data
> drive repair, Exchange version shift, direct mount of different store
> version, followed by an Exchange repair, all with non-standard Exch Org
> namespace. Other than the old drive image I had on hand, no recent
> backup/restore was used at all, I migrated the data (from a separate
drive)
> using XCOPY. Not withstanding that I was talking notes and tuning some
> custom VBScripts while I did this, I finished in about 10 hrs. The only
loss
> was downtime of the server for email transactions to the web, and a
> half-dozen password changes I had to redo. That's about as exotic
challenge
> as anyone is going to need to do. Your mileage may vary.
>
> All of these were remarkably transparent, and in all cases, there was zero
> impact to the workstations, user profiles, data paths, etc. A couple of
> workstations might need to be disjoined and rejoined to the domain to
> refresh a stale machine account password, but that's not a biggie for most
> of us.
>
> Each of the migrations I just described could have been done by a
different
> method, but would have been less transparent, both as a result and as a
work
> process. In total, I don't know of a more transparent result or convenient
> processavailable for an IT Pro other then using scripts like what I've
been
> developing to automate the steps rather than using the various editors of
> NTDSutil, ADSIEdit, and the various snap-in consoles required. My
> documentation intentionally doesn't call for using custom scripts, it
stays
> with the MS production tools all the way. I'm doing the scripts because I
> can. :)
>
>
>
> "Jeff L" <***jeff@availabletech.net> wrote in message
> news:eA12H2CgEHA.1656@TK2MSFTNGP09.phx.gbl...
> > Kevin,
> >
> > When you read a post from Jeff Middleton regarding migration... you are
> > reading a post from the guy who is rewriting the book on Migration...
> >
> > Just so you know I have started the post-Jeff Mddleton solution but I am
> pre
> > Beta... Jeff's has a solution that is operational.
> >
> > Note to Jeff: "Microsoft Virtual Server 2005"... let's talk. My solution
> is
> > just past the "I can do it phase".
> >
> > Best regards to all,
> >
> > Jeff Loucks
> > Available Technology ®
> > Solutions For Professionals ®
> > www.availabletechnology.com
> >
> >
> >
> > "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> > news:#69QHhBgEHA.3024@TK2MSFTNGP10.phx.gbl...
> > > SBS has no specific conditions for moving to new hardware that aren't
> > > present in moving a DC to new hardware in general. Basically it's a
> > process
> > > that MS has documented in KB...I posted on this in the last week, and
> the
> > > issue is that when you do a System State restore of a previous DC, you
> may
> > > find that the NICs conflict even if you solve the HAL problem.
> > >
> > > As for the issues with moving from SBS1 to SBS2 where hardware is the
> same
> > > or different....it's just a question of you willingness to commit
> working
> > on
> > > a deadline.
> > >
> > > If you want to do a migration that retains the original SBS server
name
> > and
> > > domain, then you are going to be doing two moves, one to move off the
> > > server, then one to move back to it. Therefore, the only issue in
moving
> > > back to the same hardware is going to be that you have to take the
> > original
> > > SBS offline at the point you want to put the new version OS on that
> > > hardware. I don't really see a difference other than that.
> > >
> > > I think that moving to knew hardware is more intuitive to most people
> > > because it seems to justify the effort. :)
> > >
> > > In the end, the use of the old hardware is just a function of your
> > interest
> > > in reusing $2000-$4000 worth of old hardware. If your hardware was
more
> > > expensive, or if you hardware is newer, you are going to find a way to
> > make
> > > that move back happen.
> > >
> > >
> > > "Keith Vinson" <Me@nothere.com> wrote in message
> > > news:%23XtHq$%23fEHA.384@TK2MSFTNGP10.phx.gbl...
> > > > Which would be better
> > > > 1) Do a domain migration SBS2000(old machine) -> SBS2003 (new
machine)
> > > > 2) SBS2000(old machine) -> SBS2003(old machine) -> (new machine)
> > > >
> > > > also I look and could not find a doc source for moving SBS2003 to
new
> > > > hardware, any links?
> > > >
> > > > thanks
> > > >
> > > > Keith V
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Help with Swing Migration
    ... from anyone who has used Jeff Middleton's Swing Migration Kit. ... includes the tools) to do a SBS 4.5 to SBS 2003 migration to new server ...
    (microsoft.public.windows.server.sbs)
  • Re: How can I back up SBS 2008 VM inside Hyper-V Server 2008 R2
    ... which is the USB drive plugged into Hyper-V Server 2008. ... After it was created, I went into Disk Manager in SBS, activated it, ... the drives being swapped but Server 2008 won't. ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS 2008 Backup - restore utility?
    ... If you've already installed a fresh copy of SBS 2008 on another server, ... the Recovery Wizard in Windows Server Backup to recover files and folders ... On the Specify location type window, choose "Local drives" and clik ...
    (microsoft.public.windows.server.sbs)
  • Re: slow disk response
    ... Same for the SBS CALs. ... once i have the new server up i will add a note to this ... great with PATA HD and mobo driver is unlikely to improve things much. ... drives passed. ...
    (microsoft.public.backoffice.smallbiz2000)
  • Re: << SMB Nation - THE get together for SBSers>>
    ... > SBS MVPs expected to hang out there: ... > looks like a session on SBS Migration will be added. ... and bringing the new SBS server in almost transparently. ...
    (microsoft.public.backoffice.smallbiz2000)
Loading