Upgrading NT4 domain to 2003 AD

pax · 25 May 2006 at 15:29

Hey guys and gals,

I've done some research on this, but there doesn't seem to be anything specific to my circumstances.

We've currently for 1 NT4 PDC and 2 NT4 BDCs. All are older than the hills and we will be eventually taking the other roles away from the machines before decommisioning them.

We want to upgrade the existing domain and integrate it into the global AD. Currently there are no trust relationships between any domains.

I've decided to plan this into two stages, as we have a few clustered boxes already in place, and these are mission critical services.

I've never done this before, so can those who've done similar things please point out any glaring mistakes, or provide other options to that which is listed. This is only an outline BTW. The other "sister" companies have not done this, and from what I've spoken to them about are going to start from scratch, but we've decided to do an inplace upgrade.

Stage 1)
Create a new temporary server and put it in the current NT4 domain. Once done, add the new Windows 2003 servers, which will become the domain controllers, and their clustered notes as standard members in the domain.

When this is working and the clustered notes are created, then promote the temp server through the steps to become PDC. Take one of the BDCs offline as a last time fallback. Plug the new PDC and the existing AD parent server into their own seperate switch on their own. Upgrade the PDC to Windows 2003, integrating it into global AD as a child domain (They won't have access to DNS here, but I think that will only report errors, and will be fine once integrated back into the live environment).

Plug both servers back into the live environment, and test logons, and clustered services.

Stage 2)
When stable, and Stage 1 signed off as success, demote existing NT4 BDCs to member servers, and change AD mode from Interim Mode to Windows 2003 Mode.

Once done, promote the permanent Windows 2003 servers(clustered nodes) to Domain controllers.

Transfer the FSMO roles from the temporary server to the new servers, and then demote the temporary domain controller to a member server role, then remove server from the domain.

Pax

edit: I should add, we have a couple of existing NT4 TS running Metaframe 1.8 which will be still running after the domain gets upgraded. I don't think this will make any difference, but thought I'd mention it incase.

J1nxy · 25 May 2006 at 16:47

OK, personally I would not do an In Place upgrade as its one of the worst things you can do. All you end up doing is bringing all the "junk" from the NT4 environement over into a nice new AD.

Without DNS you will not be able to perform any DCpromo as it uses DNS to locate the existing domain etc.

If you want me to discuss this further then chuck me an email in my trust as this is not a quick thing to type out...

Steve

^^Gord^^ · 25 May 2006 at 18:51

I've done two NT4 to AD migrations for two multi-nationals. One was a root AD and the other was a child into a Global AD so I should be able to give you a few pointers.

J1nxy has a point about inplace upgrades, they CAN take problems into AD (such as NT4 and Exchange 5.5 account mismatches) but you should perform a cleanup of the NT environment before upgrading. As long as you do this all will be fine.

One point I do notice in your plan is no mention of Exchange. Do you use it? If you do you need to do a lot of work on that front.

I'd also question why you want to cluster the domain controllers? You do know you can't install AD on a shared drive so in effect you can't have fail over.

http://support.microsoft.com/?id=281662

I also don't understand why you want to plug the PDC to be upgraded into a seperate switch?

pax · 25 May 2006 at 21:35

^^Gord^^ said:
I've done two NT4 to AD migrations for two multi-nationals. One was a root AD and the other was a child into a Global AD so I should be able to give you a few pointers.

J1nxy has a point about inplace upgrades, they CAN take problems into AD (such as NT4 and Exchange 5.5 account mismatches) but you should perform a cleanup of the NT environment before upgrading. As long as you do this all will be fine.

One point I do notice in your plan is no mention of Exchange. Do you use it? If you do you need to do a lot of work on that front.

I'd also question why you want to cluster the domain controllers? You do know you can't install AD on a shared drive so in effect you can't have fail over.

http://support.microsoft.com/?id=281662

I also don't understand why you want to plug the PDC to be upgraded into a seperate switch?

Hey Gord,

I'll email J1nxy seperately, but we don't use Exchange.

The reason why I am going to cluster the DC's is that they will provide, as a side function some fileshares, clustered DHCP and print services. This will be provided as a seperate project, but on these hosts.

As for the switch thing. EVERY document I've read about doing the upgrade says you should isloate the PDC you upgrade on a hub or switch, just so the host has network connectivity, but is isolated from the live network. Incase something goes wrong, then you can promote one of the remaining BDC's to PDC and live on.

In my case it would mean I can promote the server that was a PDC before the temp server became PDC back to its original role.

I don't envision that happening as I plan to do the same upgrade as a test in our dev/test environment, albeit on different hardware.

As to J1nxy's main issues, and I'll list this for other's efforts who may reply, we don't really use the existing domain, except to run services on certain machines, and for a few HO citrix hosts. Most of our environment runs on local servers/logins, so there isn't much junk to carry across.

Our AD design should align itself with new EA guidlines, so we've got signoff on that already. I've got a more techincal outline on what I am planning to do, but thought that not including specifics would be best for a public forum.

J1nxy, I'll email you tomorrow from work,

Pax

^^Gord^^ · 25 May 2006 at 22:49

I have a number of clusters and one is a file, print and DHCP cluster but I would keep your DCs / GCs on a dedicated box if you can. Although there is nothing stopping you from doing it.

The isolation of the PDC will indeed make the back out procedure a lot easier. I tend to view AD upgrades as a one way process and as long as no clients are using the domain at the time you can still back it out so tend to ignore that step.

One thing to watch out for in the upgrade is to make sure you remove any utilities or drivers not supported in Windows 2000 / 2003. Compaq / HP have a primer tool that does it for you:

http://h18004.www1.hp.com/support/files/server/us/download/10776.html

I'm not sure about Dell etc.

When you do the upgrade you will need an account in the AD you are joining with enough privledges to connect (an Enterprise Admin account would be ideal).

You will also need to get your part of the DNS zone e.g child.root.com deligated to one of your DNS servers. You usually do this at the dcpromo point.

Once you have your AD don't forget you will need to authorise your DHCP server (you will be suprised how many people forget!) and add your subnets / sites to AD.

Gord.

pax · 26 May 2006 at 07:21

^^Gord^^ said:
I have a number of clusters and one is a file, print and DHCP cluster but I would keep your DCs / GCs on a dedicated box if you can. Although there is nothing stopping you from doing it.

The isolation of the PDC will indeed make the back out procedure a lot easier. I tend to view AD upgrades as a one way process and as long as no clients are using the domain at the time you can still back it out so tend to ignore that step.

One thing to watch out for in the upgrade is to make sure you remove any utilities or drivers not supported in Windows 2000 / 2003. Compaq / HP have a primer tool that does it for you:

http://h18004.www1.hp.com/support/files/server/us/download/10776.html

I'm not sure about Dell etc.

When you do the upgrade you will need an account in the AD you are joining with enough privledges to connect (an Enterprise Admin account would be ideal).

You will also need to get your part of the DNS zone e.g child.root.com deligated to one of your DNS servers. You usually do this at the dcpromo point.

Once you have your AD don't forget you will need to authorise your DHCP server (you will be suprised how many people forget!) and add your subnets / sites to AD.

Gord.

Hey Gord,

Thanks for the second reply. I see your point about keeping your DCs off the nodes and on the real as opposed to virtual server. I'll make that change.

The server which will act as temporary PDC will have no utils on it. Infact I built it over the last two days, so I know it is fresh.

We will unfortunately have clients using the system, as we are a 7 day business, so I think as a precautionary measure I'd rather keep the upgrade process offline so as not to possibly break anything that way.

Our DNS is done by another server in the domain, not one of the PDC or BDCs. I've already tested it can handle dynamic updates when I installed AD on what will be the parent for the domain I am upgrading, and I've made sure the necessary domain names are in place. The new AD DCs will only be a secondary to this box, so there should be no problems on that front. *fingers crossed*

I've got the enterprise account to add the parent(local parent in place above the NT4 domain I am upgrading) into the tree root, and from then on I can upgrade my NT4 as a child into the parent, and will have full control over the local enterprise admin account for the entire arm of the tree.

I haven't as yet told you the main reason I've decided to do an in place upgrade. I've basically inherited a major mess as the people doing my job prior had setup scripts, SQL jobs and windows services all over the place to run as the domain administrator account. I don't have a list and it would take me 6 months to compile a list and possibly rectify it. It is basically a project on its own. I've been time constrained on this to get the upgrade done as quick as possible without breaking anything (who the hell gets the SQL server service to run as a domain administrator account, then sets the jobs to run as domain admin. They only need to get the jobs to run as SA because they will interact with anything outside the SQL environment as the service account which is running it).

Yes I wish I had more time, and could migrate this across, but as we've got critical services and this is my first time attempting such a feat as this, and hopefully last time, then I think that dealing with each screw up seperately will be the easiest,

Pax

^^Gord^^ · 26 May 2006 at 09:31

It's not an uncommon position to be in. 99% of the time when people do an inplace upgrade it's because they have a tight timeline or are limited on resources.

From your posts it looks like you have it all pretty much in hand I'm sure it will all be fine.