What are the drawbacks of making all of my windows servers domain controllers?

As the question states, what are the drawbacks of making every capable Windows 2003 or 2008 Server in my organization a domain controller for the domain? Is it just overkill? Will many 3rd party applications explode? Something else I'm not thinking of?

Are there any advantages?

• Domain controllers have no local accounts. So everything running on those machines will have to be reconfigured to work with domain accounts.
• Domain controllers should never be snapshotted or reverted to a previous image of any form, or you will encounter USN rollback scenarios. This means that if you run any kind of imaging solution or virtualisation, you will lose the use of snapshotting features.
• Any local administrator of a domain controller is a domain administrator.
• Network and replication traffic will increase significantly.
• Servers located in network segments seperated by switch ACLs or firewalls will require a number of additional access rules configuring to support sufficient replication traffic.
• Your odds of corruption in the AD databases increases
• You're violating the general security principle of least priveledge.
• When in future you wish to upgrade your domain functionality level, you'll have to upgrade every single server you have to the appropriate version, rather than just the dedicated domain controllers.
• The exploitable surface area of your domain will increase by orders of magnitude, as any applications on any of these servers will then become potential attack vectors for your domain infrastructure (e.g. a SQL exploit may subsequently lead to your entire domain being compromised)
• Some services will not function or are strongly discouraged on domain controllers (e.g. Terminal Services).

Best advice I can give you is to run domain controllers as very discrete entities wherever possible i.e. load no services onto a domain controller that is not essential to the operation of the domain controller. This is commonly overlooked with very small shops and especially Small Business Server for practical/cost reasons, but once you scale beyond that you ideally want to be heading towards a point where DCs are JUST DCs, and you only run as many DCs as you realistically need for adequate replication and fault tolerance.

To add to the very good list Chris Thorpe posted, here are some more reasons why doing that is a bad idea:

• Every server will then need to be notified of changes to the Domain.
• Servers that are down for any significant length of time can cause replication trouble.
• Depending on how large your domain is, it can be a quite significant memory suck.
• Every server will then be in DNS as resolvable by the domain DNS-domain. Get enough servers, and some DNS clients will start puking at the size of the DNS Reponse.
• Every server will then host all the Group Policies, which has its own replication traffic, so you will get inconsistent GPO coverage until replication has converged, which can take some hours in a large network of DCs.

Really, the "replication overhead" argument is a really strong one. If you have a small number of servers local to each other, say under 10, it isn't as bad. Once you get to large numbers, especially if they're remote from each other, problems start magnifying. Replication inside an AD Site is one-to-many, and between sites are generally configured with bridge-head hosts funneling the updates. Not just AD information needs to get replicated, so does all the Group Policy information (that's what's stored in "SYSVOL") needs to get replicated to every DC. It's a very complex replication mesh when you get many DCs in an environment, and it's a lot easier for things to go wrong.

From a security stand-point you really do not want potential attackers getting local access to a DC. It is a lot easier to extract the entire domain's password hashes when you're local to a DC, and with Rainbow Tables that's pretty much game-over unless your password policies are much more strict than are commonly used today.