Re: Moving computer and user accounts over to a new server

From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 08/24/04


Date: Tue, 24 Aug 2004 09:52:06 -0500

Hi Tim,

I apologize if I contributed to the confusing that was apparently building,
let me try to clean up the picture here.

First of all, to get my last brief post out of the way, I said to "snap a
mirror" which isn't actually official language, rather an abbreviated
reference to the idea of creating a mirror of an existing volume exclusive
as a way to get a snapshot of the volume, not for a fault tolerant
installation process. I can expand that thought.

If we are all familiar with the idea that you can mirror a pair of drives,
including OS/system drive and additional partitions, then we also know the
idea is that you get the identical partition contents on both. If you break
the mirror appart, you have the original volume and a separate drive that
contains the same information, either of which can be made to run the
machine.

It may also be a familiar idea, perhaps not, the you can do mismatched
mirroring where you have, for instance, (3) drives of 20G that are not in
any kind of array, and yet you can add a forth drive like an 80G and mirror
against all three of the others. The one drive would then contain the same
partitions on the single drive that the others held on separate drives. If
you split this, you have a way to pull a "snapshot" of the last running
condition of the production drive condition. When you power off, break the
mirror and pull the production drives out, just switch over to run from the
single 80G instead. Now you have the original server hardware running with
the original AD/system configuration, but on a different drive than the
production ones you want to move.

Now you build a different server as you described, and you can use the
production drives again.

<backtracking>

The previous part of the thread that Cris introduced, and then Chris Puckett
elaborated upon, is a fairly technical concept of how to sustain AD via a
migration across DCs. It's no surprise to me that you might find the process
that Chris described to be a little over the edge in either complexity of
unfamiliarity.

Essentially that is the core of a process that I've written a migration
document on that will be released to the public soon, but isn't yet.
However, I put 90+ pages of information into making it a fully rounded
concept as a strategic migration document. My details extend beyond what
Chris described to actually loop the process twice to come back to the
original SBS server name. However, I'm going to tell you that I wouldn't
have put together 90 pages of information on this if I thought it was
trivial enough to be described in 2 pages that anyone could just glance at
and go with it. It really depends upon how much of that if familiar concept
or not. I would say that 1 in 50 SBS techs at most would find the entire
process as familiar, if that. There's a whole lot of "need to know" distance
between what is required to do that whole process and what we all typically
think of as the day to day stuff we make a living doing.

<options>

You asked an original question that was a simple question for which MS,
quite honestly, doesn't have a simple answer that is a great answer. Here's
an outline of options:

ADMT: The closest answer that MS has on official terms it the ADMT based
migration on the SBS website that describes how to migration from SBS 2000
to SBS 2003. That process breaks the namespace of your domain, servername,
therefore Exchange Org....and it is a one-way process because it alters your
original SBS server in the process of migrating it. You have some
significant technical issues there, but the process works. That's how MS
typically answers this question of "moving a domain".
http://download.microsoft.com/download/6/d/c/6dccf9b4-d915-4c95-b5af-100b89e02add/SBS_MigratingSBS2k.doc

Hardware Shove: MS has a KB on how to recover a Domain Controller by moving
to different hardware. This one talks about the idea of lifting the entire
drive contents to another box, then repairing the installation for the
breaks that it causes due to the "shove". You can optimize this process by
preparing the HAL, boot drive controllers, and configuration for the move in
advance if the original server is still operational. However, this doesn't
repair the installation, it just transports it to new hardware. In you case,
this doesn't do what you want.
http://support.microsoft.com/default.aspx?scid=kb;en-us;263532&Product=win2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;249694&Product=win2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;822052&Product=win2000
292175 How to perform an in-place upgrade of Windows 2000

FMSO Transfer: That's what Chris Puckett described. You retain the AD by
replication to another server, then in-place upgrade it to be your new SBS.
Unfortunately, this will break the server namespace, even though the domain
is retained because you can't have two domain controllers in the same domain
with the same name. If you change the name of your server, you change all
the UNC paths from the workstations to the server, you break ISA installs,
Outlook configuration, recently used documents, all related shortcuts. It's
a blunt force trauma to the UNC, but the same AD. You have to knock out the
SBS server, DNS configurations, and Exchange, then reconstruct that again.
216498 How To Remove Data in Active Directory After an Unsuccessful Domain
http://support.microsoft.com/?id=216498

Swing Migration: This is what I have documented, but it has complications
that are solvable if you have the right steps, in the right sequence, with
the right planning. I think it's the best way to do an upgrade, and it's a
very nice way to rescue a dead SBS configuration, or a damaged one if you
don't have a System State backup you can use to roll-back prior to the
damage event.

System State Migration: This last idea is functional, but it doesn't solve
your problem. It's valuable when you can move your intact configuration
because the hardware is totally hosed, perhaps stolen. In this case, you
build a baseline Windows Server installation, then do a System State DSRM
restore of the old server to the new hardware. From there, you next repair
problems with the network bindings and IP assignments, clean up DNS as
needed, and repair whatever problems you have in mounting the Exchange, if
you are dealing with that at the same time.
http://support.microsoft.com/default.aspx?scid=kb;en-us;249694&Product=win2000
810161 Network adapters are missing or incorrect in Device Manager after you
run NTBackup to restore system state data
292175 How to perform an in-place upgrade of Windows 2000

The last part of what you asked about refers to the Exchange information
migration. If you want to do an Exmerge, you have an entire answer there. If
you were looking to move it intact, then ADMT can do that for you, so can a
Shove, so can Swing, so can System State Migration. Making that happen with
FSMO transfer means you have to get creative and us LegacyDN to solve the
change in namespace.

At this point, that's just over 2 pages of summary statements on the options
you have. But as you can see, the options you have all have strings
attached. IMO, MS doesn't have a good answer to this problem, and that's why
I spent the time to research and document the Swing Migration process. My
documentation will be available quite obviously when the book is published
with that chapter included. I will be presenting a session at SMB Nation on
the Swing Migration process. In addition, I believe that in some manner, it
will be possible to get this chapter in electronic form before the release
of the book, perhaps even at SMB Nation itself.

I hope that I've answered more questions for you than I have raised, but I'm
afraid that if you want a really short answer to your question, it's the
link to the ADMT migration at this point. All the other answers are longer,
even if they have desirable options provided.

"Timothy Morris" <tim@online.kingswoodhouse.e7even.com> wrote in message
news:Om3lraZiEHA.3608@TK2MSFTNGP09.phx.gbl...
> All points taken and I perfectly understand that my question is confusing.
> Apologies, it is late here (now 04:32am) and it has been a long day.
>
> I understand what a mirror is, but the term "snap a mirror" is foreign to
> me.
>
> I have four ATA-133 120Gb HDs (Maxtor 6Y0P0s) connected to a Promise Ultra
> IDE controller. The first is split into two partitions - the first third
> (C:) houses Windows and Program Files, and the remainder (D:) has folders
> containing the contents of all the install CDs (SBS, Office 2003, NAI
etc).
> E: is a Combo DVD Rom/ CD-RW, and F: is the remaining 3 HDs striped in a
> RAID 0 configuration for performance purposes.
>
> I'm upgrading the mainboard, CPU and RAM (ABit NF7/AMD 3200 XP+/2Gb
Corsair
> 3200 400MHz RAM. The new machine will have a 400Gb Ultrium tape drive, but
I
> do have a 500Gb LaCie USB 2.0 that I can back up the contents of the
> existing system's HD to.
>
> Now perhaps we can start again (please)? I want to start again using the
> same disk configurationbut wiped clean (apart from D:). The one thing that
> will make life easy for me is if I can maintain the machine and user SIDs
> rather than have to set them all up again from scratch.
>
> Apologies and thanks!
>
> Tim.
>
>
> "Cris Hanna (SBS-MVP)" <crishannanospam@computingpossibilities.net> wrote
in
> message news:ulaqVRYiEHA.2908@TK2MSFTNGP10.phx.gbl...
> > Nor are we suggesting that you are being dense but if the term mirror is
> > foreign to you, then its understandable that none of this is making
sense
> >
> > But the question you've restated here is not the question you ask in
your
> > subject line
> >
> > Your subject says moving to a new server, now you're asking about fresh
> > install on the same hardware.
> >
> > These are two different things. Do you have a tape backup that you can
> > restore from? Are your drives configured as a Raid 5 or each drive a
> > separate single drive?? Are these SCSI, IDE or SATA??
> >
> > --
> > CRIS HANNA
> > SBS-MVP
> > --------------------------------------------------------
> > Please do not respond to me directly by email but only in the newsgroups
> so
> > that all can benefit from the information
>
>



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: 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.smallbiz)
  • 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)
  • 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.windows.server.sbs)