Re: Repost: Jeff M's SBS 2003 Migration Process
From: Mark (nospam_at_nospam.nospam)
Date: 08/12/04
- Next message: Geoff: "Re: Best tool for sync'ing contacts from public folders"
- Previous message: Geoff Scholes: "Re: Backing up the Intranet"
- In reply to: Jeff Middleton [SBS-MVP]: "Re: Repost: Jeff M's SBS 2003 Migration Process"
- Next in thread: Shawn Jensen: "Re: Repost: Jeff M's SBS 2003 Migration Process"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 12 Aug 2004 16:01:14 +0930
Hi Jeff,
Thank you for taking the time to reply, and thanks for having the motivation
and perseverance to take on a task such as this document!
I look forward to it's release.
Best regards,
Mark
"Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
news:u93$l$0fEHA.2536@TK2MSFTNGP09.phx.gbl...
> Hello Mark,
>
> Thank you for your persistence in asking, and I apologize for not being
> forthcoming in clarifying this.
>
> The answer to your questions are:
>
> 1. No, I've not published or released a public summary of the upgrade
method
> I've written...yet. Very soon.
>
> 2. I'm pretty sure it is going to become available within the next month
in
> full discriptive format.
>
> 3. It's tentatively set to be included in a book which would be available
> within a few months from now. The dots on i and crosses on t are mostly
all
> that remains...and the production time.
>
> 4. I'm not being coy by not releasing more information yet. The situation
is
> still dynamic. Between the time I started this email and now, I've just
had
> another private conversation concerning this topic with folks at MS. In
> fact, I am very grateful that MS is looking at this for me, and that many
of
> the SBS MVPs are working production upgrades based upon the documentation
> I've written, and giving me feedback, corrections and tuning in the
process.
> I made revisions to the text as recently as yesterday based upon feedback
I
> got in the last few days.
>
> 5. I want to make this information available as soon as possible, but I'm
> also working with MS and other parties to ensure that the process is
> embraced and supported by MS as much as possible. I'm watching as 3-10
posts
> a day are asking about how to migrate an SBS, so I'm very much aware that
> people would like some options like this.
>
> For anyone arriving in the middle of this discussion, Mark is asking about
a
> method of upgrading an SBS domain that's based upon a process I've used
for
> about 3-4 yrs. It's not something I invented out of the blue, rather it's
a
> finesse of the issues that SBS provides in terms of licensing, technology
> and pragmatic domain management. You could figure out the broad process
from
> simply doing a google of stuff I've posted for the last 3 yrs on
migration.
> It's not a secret. It's a DC roles transfer out and back to an new SBS
> server. The challenge is in the details.
>
> Basically it's a method to introduce a new SBS server to an existing
domain
> that retains the original SBS server name, the domain name, the IP, and
the
> AD. It's a very transparent process. It's not hard to do, but it's very
> technical. It's a process that looks more like disaster recovery than an
> upgrade, but it has the number one advantage of being non-distruptive to
the
> production operations...it's done offline. It can also be done with an
open
> timeline. I've done upgrades that spanned weeks from start to finish
because
> that was convenient. I rebuilt my own domain from a 4 months old
> backup....just because I could confirm that it would work.
>
> This NG is where I will be releasing the earliest information on this
topic,
> so it's the place to keep watching.
>
> Mark, thanks again for your interest, and thank you to everyone for
> continuing patience.
>
>
> "Mark" <nospam@nospam.nospam> wrote in message
> news:%23cKhtTzfEHA.3916@TK2MSFTNGP11.phx.gbl...
> > Sorry for reposting, I didn't get a response to the original post. One
> last
> > try to see if anyone knows. :-)
> >
> > Hi All,
> >
> > Has JM made a copy of his SBS 2003 migration documentation mentioned
below
> > publicly available yet?
> >
> > Or is it only going to be available in a book released some time in the
> (not
> > soon enough!) future?
> >
> > I'd find it an interesting read before I attempt to migrate our network,
> > even if the document is only at draft stage.
> >
> > Thanks,
> >
> > Mark
> >
> >
> > "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> > news:%23kb3BBeaEHA.1840@TK2MSFTNGP11.phx.gbl...
> >
> > >
> > > So, I guess that most useful direct contribution I can describe
pending
> is
> > > the documentation and scripting I've been working on. I've been
> perfecting
> > > and documenting a manner of doing SBS 2003 Migrations that I feel
> > > dramatically improves upon the MS documented method. I'm pretty sure
> that
> > at
> > > least 4-5 SBS MVPs have applied the theory if not the draft
> documentation
> > > method to successfully migrate production SBS 2000 servers.
> > >
> > > The migration process is most interesting because it accomplishes the
> task
> > > without losing the AD domain, without changing the SBS server name,
and
> by
> > > preserving and technically migrating just about 95% of the original
SBS
> > 2000
> > > (or 4.5) over to a new SBS 2003 that is based upon a clean install,
but
> > all
> > > the original AD and related technical configuration. If you are a
> > long-time
> > > reader in this NG and it's predecessors, you will recognize the method
> as
> > > one I've used personally for about 4 yrs, but it's on steroids now.
;-)
> > It
> > > makes it possible to accomplish a virtually transparent/replacement of
a
> > > production SBS without working nights or weekends, without taking the
> > > original SBS server down for the duration of the process, and without
> risk
> > > to the production domain as the process is worked. It's an offline
> upgrade
> > > that can span an open-ended amount of time, whatever you need to do
the
> > job
> > > right and with confidence. For instance, I just did a production SBS
for
> a
> > > customer that I started as I was finishing the first draft of the
> > migration
> > > documents, and along the way, discovered new things I wanted to
include
> in
> > > my documentation and method. As a result, the upgrade spanned a total
of
> 3
> > > weeks from when I started, to when I put the new SBS online. I should
> > > mention that the steps involed can be completed in about 5 hrs of
> straight
> > > work, however. The time I took was available to me because I wanted to
> > > refine the process, and I was building tools on the fly. But it's
> > > significant that the new server can just slide into place of the old
one
> > > with little complication, even if the offline process spans weeks.
> > >
> > > Another view on this as a solution. My own server suffered from a
> > electrical
> > > storm that damaged both drive volumes on separate disks in my server.
I
> > had
> > > CRC error everywhere across my Software registry, my BKF disaster
> recovery
> > > backup on the alternate drive, all four primary Exchange store files,
> plus
> > > at least 3 Exchange transaction log files. But strange circumstance,
the
> > > majority of the data files where unaffected. I decided to use the same
> > > migration process I had used on this server the first time I did it in
> > March
> > > this year. Using a 4 month old drive image, I migrated my old SBS 2000
> > > forward again to reconstruct the new SBS again from scratch but with
the
> > > same AD and details. I used a drive recovery tool to scrape the
Exchange
> > off
> > > the old drives intact. When I was done, I mounted my current Exchange
> (in
> > an
> > > "inconsistent" state due to the crash) on my clean server install
based
> > upon
> > > a 4 month old version of the AD. I actually ended up losing _nothing_.
> All
> > > my workstation profiles worked fine, my Exchange was fine, the data
> files
> > > were file, I brought forward my old shared folders and security
> settings.
> > > This was one of those "your mileage may vary" sort of events that
really
> > > demonstrated the worst case scenario of a migration/disaster recovery.
> The
> > > only loss I have is a pair of dead hard drives and a day of
> effort....and
> > > lots of documentation!
> > >
> > > At this point, it looks like it is going to be part of a couple of
> > chapters
> > > I'm writing will probably appear as chapters in a Harry Brelsford book
> > > coming out "soon". I'm hoping to have separate chapters on Migration
and
> > > Disaster Recovery. I hope to get at least some of this information out
> > > before the book publishes because there is so much demand for the
> > > information. I'm also working on scripting tools that relate to this,
as
> > > well as doing other common chores we SBS admins deal with all the
time.
> > >
> >
> >
> >
>
>
- Next message: Geoff: "Re: Best tool for sync'ing contacts from public folders"
- Previous message: Geoff Scholes: "Re: Backing up the Intranet"
- In reply to: Jeff Middleton [SBS-MVP]: "Re: Repost: Jeff M's SBS 2003 Migration Process"
- Next in thread: Shawn Jensen: "Re: Repost: Jeff M's SBS 2003 Migration Process"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
