This is part of my ongoing AD Design series. Check here for primer on the intent. As mentioned in my last post, I'm going to assume a certain level of knowledge about Active Directory is held by the readers of this series. One of those assumptions is you can navigate the wizards necessary to promote a couple domain controllers and get a base domain up and running. Again, if that's outside of your abilities, there are many, many guides for that online. For this post, I'm going to assume you're starting with a brand new domain. It may seem elementary, but two of the most important things to consider in AD design are: How your configurations will affect existing systems within the domain.  How your configurations will affect future efforts within the environment. How long you've been managing domains and your knowledge of how your systems integrate with your domain will determine how well you're able to guess at those (and make no mistake, you are ...

Active Directory (AD) is one of the more flexible products provided by Microsoft. While they have spreadsheets and white papers for how many users should be in each on-prem Exchange database or how you should structure your site collections in SCCM, guidance on AD design is kind of sparse. My assumption is because directory designs are so environment-specific as to be resistant to generic instructions. This flexibility means two things: You can tailor the configuration and security of a domain to precisely and efficiently match the requirements of the environment it's there to support, making maintenance easy and allowing for future expansion.   You can screw things up really, really badly and not even know it. You see, the assumption in AD overall is you know what you're doing. There are very few warnings, no popup to let you know you just granted Bob in Accounting the keys to the kingdom or an easy wizard that lets you review your configurations before deploying them to ...