• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

any gotcha's for installing R2 on 2003 SP2 DC's?

OutHouse

OutHouse

Lifer
hey, i need to put R2 on my 3 2003 SP2 domain controllers. I have tested this on my test bed and it seemed to go ok no issues with users logging on in the test environment. but the difference is i only have 1 DC in the test domain.

my production domain has 3 DC's, i have made a VM snapshot of one of our DC's just incase things go south. the process is simple just run /forestprep to update the schema then run the setup on disk 2 to install R2

are there any gotchyas on doing this with 3 domain controllers that i should be aware of?
 
I wouldn't mess with snapshots and a DC. Too many things could go wrong if you restore that snapshot.

I personally would build up new DCs and transfer the roles to them.
 
stlcardinals said:
I wouldn't mess with snapshots and a DC. Too many things could go wrong if you restore that snapshot.

I personally would build up new DCs and transfer the roles to them.
Click to expand...

build new DC's just to put on R2?

its a VMWare snapshots, so if something should go wrong all i have to do is turn on the VM. i other than changing the MAC i dont see what could go wrong. if i am missing something please let me know. today is friday and we do not make ANY changes on friday and monday is a holiday so I would like to do this on Tuesday.
 
Turn off one of the DC's, upgrade one, upgrade the other, turn on the other DC, upgrade and be done. We did that here where I work. Did the same thing when we went to 2008 r2 from 2003 r2.
 
OutHouse said:
build new DC's just to put on R2?

its a VMWare snapshots, so if something should go wrong all i have to do is turn on the VM. i other than changing the MAC i dont see what could go wrong. if i am missing something please let me know. today is friday and we do not make ANY changes on friday and monday is a holiday so I would like to do this on Tuesday.
Click to expand...

Yes, I've never known anyone to do an in-place upgrade on a DC and for good reason.

And you especially don't want to roll back a DC with VMware snapshots. AD is very time dependent, rolling back a snapshot will possibly undo AD replication and other things. And since you're going from 2003 there will be schema updates that happen during the upgrade, these are things you don't really want to mess with.
 
Nothinman said:
Yes, I've never known anyone to do an in-place upgrade on a DC and for good reason.

And you especially don't want to roll back a DC with VMware snapshots. AD is very time dependent, rolling back a snapshot will possibly undo AD replication and other things. And since you're going from 2003 there will be schema updates that happen during the upgrade, these are things you don't really want to mess with.
Click to expand...

im staying on 2003 im not upgrading to 2008.
 
Yup as the other guys said, Snapshots are not a good idea. and as nothingman said, AD is time dependent in terms of syncing.

If you left two DC's running, updated one, and decided it didnt work, then rolled the one back, and started it up, your domain would basically be screwed. You'd have to go in and manually change records which would be nearly impossible to keep straight and take forever.

When you do an upgrade, you need to turn all machines off, take them off the network as well, then upgrade all at the same time, and start them up together.

If you do them all at the same time, and it doesnt work, you MIGHT be able to roll them all back at the same time, but its too risky. Take it from me, I have first hand experience 🙂
 
dawks said:
Yup as the other guys said, Snapshots are not a good idea. and as nothingman said, AD is time dependent in terms of syncing.

If you left two DC's running, updated one, and decided it didnt work, then rolled the one back, and started it up, your domain would basically be screwed. You'd have to go in and manually change records which would be nearly impossible to keep straight and take forever.

When you do an upgrade, you need to turn all machines off, take them off the network as well, then upgrade all at the same time, and start them up together.

If you do them all at the same time, and it doesnt work, you MIGHT be able to roll them all back at the same time, but its too risky. Take it from me, I have first hand experience 🙂
Click to expand...
This is not the way we did our 2003->2008R2 migration. Granted we had new hardware to start from. What we did was:
  1. update the schema
  2. promote new servers to DC's
  3. move FSMO roles to one (or more) new servers
  4. demote old servers
  5. change functional level of domain

You could adapt this to your setting by starting with one DC and demoting it PROPERLY, upgrading it, then promoting it again. Rinse and repeat until all are done. Just don't forget your FSMO roles before you demote the server(s) with them on it.


Edit to re-iterate: snapshots are bad, mmkay
 
Wow, there's a lot of mis-information in this thread.

For the love of God (or chosen $diety or lack thereof), whatever you do, STOP TAKING SNAPSHOTS OF YOUR DOMAIN CONTROLLERS, and delete any snapshots you currently have -- they're useless to you if you value your domain and domain. USN Rollback is a resume-generating event. You don't want to go there. Snapshots should never be used with domain controllers.

Also, I can't think of any reason at ALL why you would want to power off any of the DCs while you're upgrading a different DC.

What do these servers do *besides* DC services? Anything?

Regardless of what server upgrade approach you take, you definitely want to prepare the forest and domain schema (read up on adprep), and verify that replication has been successful between all domain controllers, before commencing with upgrading any server.

I personally have a policy of no in-place upgrades on DCs. It may be overkill, but I demote and disjoin, then format, rebuild, and promote. It really doesn't take that long, and it makes me much more comfortable that there won't be any lingering problems from any former operating systems.

If you are going to format and rebuild, then as phoenix79 said, promote new servers to DC, transfer FSMO roles, and then demote old servers. If you're going to insist on an in-place upgrade, then I recommend that you upgrade a DC that does not hold FSMO roles first. Once it has been upgraded, and replication has been completed between the upgraded servers and the others, then I would transfer the FSMO roles to it, and then upgrade the others. Finally, transfer the FSMO roles back to the original server if needed. I'm particularly wary of upgrading a server that holds FSMO roles; if something were to go wrong, you'd have to deal with seizing FSMO roles, etc.

Finally, I recommend making a full backup of one domain controller that holds a global catalog. If something should happen such that you need to restore it (you should only reach that point if ALL of your domain controllers are dead), you'll first want to read up on how to restore a domain controller. It's not as easy as starting a snapshot. Be careful. 🙂
 
GeekDrew said:
Wow, there's a lot of mis-information in this thread.

For the love of God (or chosen $diety or lack thereof), whatever you do, STOP TAKING SNAPSHOTS OF YOUR DOMAIN CONTROLLERS, and delete any snapshots you currently have -- they're useless to you if you value your domain and domain. USN Rollback is a resume-generating event. You don't want to go there. Snapshots should never be used with domain controllers.

Also, I can't think of any reason at ALL why you would want to power off any of the DCs while you're upgrading a different DC.

What do these servers do *besides* DC services? Anything?

Regardless of what server upgrade approach you take, you definitely want to prepare the forest and domain schema (read up on adprep), and verify that replication has been successful between all domain controllers, before commencing with upgrading any server.

I personally have a policy of no in-place upgrades on DCs. It may be overkill, but I demote and disjoin, then format, rebuild, and promote. It really doesn't take that long, and it makes me much more comfortable that there won't be any lingering problems from any former operating systems.

If you are going to format and rebuild, then as phoenix79 said, promote new servers to DC, transfer FSMO roles, and then demote old servers. If you're going to insist on an in-place upgrade, then I recommend that you upgrade a DC that does not hold FSMO roles first. Once it has been upgraded, and replication has been completed between the upgraded servers and the others, then I would transfer the FSMO roles to it, and then upgrade the others. Finally, transfer the FSMO roles back to the original server if needed. I'm particularly wary of upgrading a server that holds FSMO roles; if something were to go wrong, you'd have to deal with seizing FSMO roles, etc.

Finally, I recommend making a full backup of one domain controller that holds a global catalog. If something should happen such that you need to restore it (you should only reach that point if ALL of your domain controllers are dead), you'll first want to read up on how to restore a domain controller. It's not as easy as starting a snapshot. Be careful. 🙂
Click to expand...

thank you. I sent a email to my boss suggesting we start planning to upgrade with new hardware to server 2008 R2 or wait until 2010 is released.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top