• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 476
  • Last Modified:

Migrating messy single-DC 2000 domain to squeaky 2003...looking for a strategy

I'm in a pretty small environment where I have one (count 'em) Windows 2000 Domain Controller.  It's working OK, merrily handing down the edicts of management via Group Policy (no old emails for you! Ha!), setting up Office on PC's via AD, doing a yeoman's job of DHCP/DNS, and otherwise slicing bread just fine, thanks.

However....the AD itself is a little messy.  This is a case of a "Test Environment" that, due to lack of resources and time, got pressed into production duty.  Huzzah.  

Specifically, PHB's (Middle Management for non-Dilbert fans) wanted to evaluate Exchange, which is really where this now-tired DC started its existence.  So on went a trial copy of Exchange, and everyone was happy with it...until The Proposal.  Sticker shock is not the word.  Needless to say, we are not at present an Exchange house.  But our domain is.  The 'schema' is extended for Exchange.  Lots of funny attributes, lots of funny-looking accounts.

So fast forward a while, and now we're getting a bit bigger.  The hardware the DC is running on is getting a little wheezy under the strain of all the cool things we've dreamed up for it to do.  And since this now-humble domain will soon stretch across a vast new network of VPN and Frame-Relay lines due to a new corporate partnership, Windows Server 2003 becomes the obvious choice.  

As I write this, a big brown truck is bringing me a shiny new Dell server, and I am pondering how to get my fancy new 2003 domain running, as clean as it can be, "Adding Lightness" as famed engineer Colin Chapman was fond of saying.  

So what's the best approach?

Should I --

1 -- Build the 2003 box as a sole DC 'in parallel', with the same domain name....and somehow get the client workstations to move over to it (including the users' profiles)?  This sounds like LOTS of time on each workstation, and some possible strangeness with the c:\documents and settings\%username% names turning to odd things like fsmith.000 or somesuch.  This makes all sorts of scripts very difficult to use.

2 -- Upgrade the existing 2000 DC to 2003, join the new box to the domain as a DC, let the current domain structure replicate, and then 'retire' the current (by then upgraded) box by means of various command line entrails-readers...this I have fears of making for not the cleanest or nicest domain, but it's something I can concievably do in a weekend and not have to bother users' machines.

3 -- Anybody else got a more elegant solution?

This is something I want to do right.  This new domain is 'for real', and having it right from the start, clean as can be, is important to a large transition for our company from being in one building to being in 10.  I'm not under huge time pressure to get it done, but there are several other projects that can't move forward effectively until this is working...so I have all the time in the world, so long as I hurry up....right?  We've all been there...we're all there all the time, really.

Suggestions?  Been there / done that?  Please, let me know.
1 Solution

Right then here we go, hand on it will be a rocky ride...

There isn't anything elegant about this - blame it on PHB and make sure he knows it :)

If you build the new machine on the existing domain, you will get all the crap replicated across. You wont have the programs, but you will have the schema nasties and all the accounts and dodgy GPOs. Not the best solution for you perhaps, but the easiest and least painful. You can do this in a weekend.

If you build a new domain it MUST NOT be te same name as the old as the machines won't migrate any easier and you'll have a whole lot of "duplicate machine and domain name" crap to deal with.

So we are left with the "build a new domain from scratch" solution oh, dear.

Going with this option, I recommend you create a new domain and create a trust between the two, this will allow you to alter the permissions structure on your shared resources to allow members of both domains to access resources hosted on either and therefore means your migration can be a leasurely affair and not a mad weekend of stress and caffiene. You will need to create every account again from scratch, but if you backup the user profiles using the profiles dialog on each workstation (or use moveuser.EXE from the resource kit) you will at least get to keep them. Pay attention to the permissions on the profiles as the reg hives are tied to the old user account and will need to be reset using the "permission to use" settings in the dialog or in the moveuser command.

Consider your DNS and OU design carefully, you will probably not want the same thing again. Use the GPMC.MSC tool to backup your GPOs and take reports of them for creating them again on the new domain.

Make a note of all the services the current DC is running (DNS, DHCP, WINS, QUAKE, etc), install these clean on the new machine and configure them as required. You can then cut over each service individually and still have a backout point if it doesn't go to plan.

Buy a few more question points on EE as you might have an emergency!!

This should get you started, let me now how you get on.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now