Best Practice for FSMO Roles, DNS, DHCP

More or less looking for advice/opinions.

We have a server that we pretty much can't rely on as it BSODs with "registry errors" upon any login attempt at the console or through RDP.  Other than that it functions, but that just isn't sitting right.  This server happens to have all 5 FSMO roles, DHCP for our main office and is our Primary DNS.  Which are all still functioning and manageable through snap-ins, RSET, etc.

It's a 2008 R2 box and we are just a single domain/forest.  So I know I'm good to transfer all FSMO roles to another 2008 R2 DC.  But what is everyone thoughts for DHCP and DNS?  This just seems like an example of why you wouldn't want all this stuff on one box when you have the option of spreading them out.  And any trouble with having any of these roles virtualized?  Thanks for the thoughts.

-Scott
sseiferAsked:
Who is Participating?
 
Mike KlineConnect With a Mentor Commented:
DNS I'd also run on the DC  so you get the benefits of AD Integrated DNS.  DHCP I've seen both ways.  If you have a spare box (non-DC) then I'd rather have DHCP there than on the DC

Yes all those roles can be virtualized.  At my last job we virtualized 95 percent of our member servers (including DC/DNS and DHCP.

Thanks

Mike
0
 
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
A Domain Controller has to have DNS installed on it to be a domain controller, so you're not going to cause problems by having a DC as your primary DNS server, and you lose some functionality by having DNS on a dedicated server. DHCP isn't really resource intensive and can be handy to have on a DC, but as Mike said you can go either way with it. You can virtualize any role you want, to be honest, but I tend to avoid Virtualizing Domain Controllers because having a Physical DC removes the temptation (and possibility) for someone to do a snapshot restore of the DC, which can be a little deadly to an AD environment. But again, that's just a matter of personal preference and what you have available in the way of hardware.
0
 
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
Also, as long as you're using AD Integrated Zones already, you don't even have to worry about transferring the DNS information to the new DC you're planning on using, since that info is replicated automatically and it already has it. DHCP would need to be transferred over manually, though, and there is a process for doing that.
0
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
DrDave242Connect With a Mentor Commented:
If you've got more than one DC, I'd highly recommend putting DNS on at least two of them (and making the zones AD-integrated so you don't have to worry about zone transfers).  I'd make multiple DCs global catalog servers as well, though you didn't specifically ask about that.

You can't have more than one DHCP server handling the same address range, but you can split the scope into two smaller scopes, each managed by a different server, for some degree of redundancy there.

You can certainly virtualize them all.  Be careful with that too, though: if you virtualize multiple servers but host all of the VMs on the same physical box, failure of that box means they all come crashing down.  You can use Hyper-V failover clustering to mitigate that, but be advised that the cluster service has to be able to contact a DC in order to start, so if you virtualize all of your DCs and the cluster goes down, you've got yourself a nice little catch-22 in which the cluster won't start because it can't find a DC, and you can't start a DC until the cluster starts.  There are ways to recover from that, but it might be better to leave one DC on dedicated hardware.
0
 
ChiefITConnect With a Mentor Commented:
I am sure you realize, when troubleshooting on EE, it is usually automatically assumed that the FSMO roles all reside on one DC, and that then becomes the (PDCe). Dividing the roles isn't really a measure of making your domain trustworthy. That's because all FSMO roles are important. If  a server goes down, it goes down. By dividing the roles, now you risk one of the two, (or three), servers going down, You will still have to transfer/seize the roles from that downed server.

By dividing the roles, you are effectively increasing the change of a problem, not circumventing it.

0
 
sseiferAuthor Commented:
Thanks all.  Exactly what I was looking for.
0
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.

All Courses

From novice to tech pro — start learning today.