A few basic questions about replacing 2003 DC with 2008R2 DC

If both sevrers are GC, then your DC will stil lbe available and be able to serve logon request/authentication. It can still provide access to the network and resources.

You don't always need to transfer the roles across, You probably wont notice that some arent working unless your performing a specific action/task, for e.g, the schema master, you wont know until say, you were going to deploy Exchange and you coundt update the scheme. As well with config. These are forest wide roles. The only issue I can see you may have is with the PDC emulator which you can seize and move via NTDSUTIL. Depends on the state of the DC failure.

If one server goes down, then you should be OK. As your other DC should continue to provide services, Need to make sure this DC is alos a DNS/DHCP too.

Sukh

For DHCP depending on your ranges you also have the ability to split the scope across multiple DHCP servers (but this maybe OTT for your needs)

Make both servers DNS and have this Active Directory intergrated.

All these suggestions might seem over the top, because you might be thinking "we've been running ok on 1 server long enough"

But as with everything, it works great...until it dies lol had my fingers burnt before, now I build in resiliency whereever I can.

For the FSMO roles - as mentioned

Schema Master - only really needed for when you wish to make Schema updates
Domain naming - if you're not planning on making any new domains hardly used.
RID - very critical
Infrastructure Master - pretty much negated if all your DC's are GC's
PDC - critical role, but easily seized if it was to fail.

Quote:

---

Also, if it is a single server then need to ensure that it FT all around, i.e network cards, teamming, CPU's, RAM etc..

---

On my planet, that or a second DC replicating all the data, or hyper-v failover or whatever would cost a "heck" of a lot more in terms of equipment, routine management effort and energy usage than a single DC w. RAID and next day on-site h/w cover. That a single-DC Primary system may be out of action until tomorrow once every few years if they're unlucky, just doesn't seem to bother them much and nor should it.

Quote:

---

I think I am more worried about AD corruption

---

I've had a 3-figure number of systems under my radar and have seen genuine AD corruption just twice - a single DC one I fixed via a system-state restore in < 30 mins, the other was one of a multi-DC but would have been similar except the dodgy RAID system had made "holes" in lots of files so a large full backup needed restoring... and with multi-DC you have a lot more "is everything happy now" checks to do afterwards. The thing I have seen much more often is faux-corruption i.e. typically someone deleted or changed something (or ran something that did that) and then lied about it being a complete mystery - and that is the kind of corruption that replicates to other DCs.


Do whatever you feel is best for the school, but I'm on Michaels "side" and would contemplate potential use as a member server with shares for all the photos/videos or something... and subject to the spec we don't know, perhaps just get rid.

PiqueABoo Thanks for your advice. lots to think about.

@PiqueABoo

That is interesting, but your post seems to be based on probabilities. If this is acceptable to the school then it's fine. If a school can tolerate downtime for whatever length of time, then make sure you have that agreement in writing or is known. Where I have deployed DC, it's always been a min of 2. It not only MSFT best practise but industry best practise. However, if you're limited to budget or hardware, then I guess you cant do much.

Sukh

In my case the old server is not that old. DELL PE2900 with 2 years still on the warranty.

Quote:

---

your post seems to be based on probabilities

---

Precisely: They're based on the risks I've experienced in the bit of the real-world I experience. They're also based on my default "less is more" approach - add a second DC and your system is now more complex, it can break in interesting new ways etc.

YMMV, I'm not claiming mine is the only approach.

Quote:

---

It not only MSFT best practise but industry best practise

---

::shrug:: No one ever asked me, so "best practice" (BP) according to whom and where did they get their extensive hands-on experience of every sector and size? I haven't seen that much BP that hasn't been forged in, or for, genuine Enterprises. I reckon a lot of BP exists to get people who don't thoroughly understand what they're doing, to do something that should work well-enough in most scenarios, but there can be an even better way in some of them.

And of course MSFT want to sell you more licences (preferably over and over again), h/w vendors want to sell you boxes, support organisations want to sell you their time configuring and managing the former on the latter. Note: MSFT clearly weren't worried enough about violating BP to stop some of those licences being for SBS.

PS:

Quote:

---

if you're limited to budget or hardware, then I guess you cant do much.

---

When it's public money I take cost-benefit very seriously and if I don't see a notable benefit for them, won't add something that increases the cost even if there is ample room in the budget.

"Precisely: They're based on the risks I've experienced in the bit of the real-world I experience. They're also based on my default "less is more" approach - add a second DC and your system is now more complex, it can break in interesting new ways etc."

I hear you, BUT the risk is still there. Like I say, if youre scholl doesnt mind the downtime then do it. Adding a second DC may involve more admn, i,.e backups, patches, SP, upgardes, but these out weigh the fact that if a DC is down and you have no other, then you simply can work, users or staff. Having 2 DC than one is always good, I cant hink of a reason not to. In my experience, having one DC when you have a chance to have two, you should do so. A system doesnt just break, espicially DC. Some makes a change to the DC then they break.

Industry best practise is from all sectors and industires, public and private. In this case, we are referring to a DC, which clearly in my opinion is best practise.

Sukh