Active Directory Disaster Recovery: Expert guidance on planning and implementing Active Directory disaster recovery plans with this book and eBook

When designing an Active Directory, you need to be completely clear of what each element or part actually means and how it fits into the overall design. The old saying goes: You can't see the forest because of the trees, and you can apply this to Active Directory as well. It is all about trees and forests and leaves and branches.

This is the most common design version for small-and medium-size businesses, that have offices within one country or that are geographically close. It involves a single hub site and several small sites. A hub site is defined as a big data center where the majority of your infrastructure is housed. So if you have the headquarters and development...

Even though this architecture is no longer recommended, there are still quite a lot of companies that either use it or implement it. This is almost the same design as the previous one, except that it includes an empty root domain. Basically, it implies that the root of your forest is empty, meaning that there will be no computer accounts and no user accounts other than the Enterprise Administrators located in this domain. Within AD, a domain is not a security boundary. A forest, however is, so a multi-forest architecture would provide more security. An empty root domain has good and not-so-good points. The point is that this is a fairly safe design, which still adds layers of security. The other domain under the root domain - the child domain-will contain all of the user and computer accounts. This setup is beneficial from a security perspective in that the Enterprise and Schema Administrators groups are isolated from the...

This design is used a lot in larger corporations and companies that do a lot of Quality Assurance testing for software, or software development. It has a forest and multiple trees under this. This is also very good if your company has expanded a lot through acquisitions and you need to ensure that the acquired companies can access cross-domain files.

This design approach needs to be designed from the beginning because you cannot create a new forest on top of an existing one. Windows 2003, however, makes moving domain information and migrating between two Active Directories easier, with the tools that it provides.

This design, while administratively more complex, provides the best security. It also raises support costs and makes collaboration a little more difficult, but it definitely has its benefits. This design will have standalone forests for all of the business units or departments. This also means that by default they cannot see or access each other. Administrators then create trust relationships between the different domains that are within the forests. This will give the granularity needed. To visually understand this, please see the following image:

These sites are also often called RLS (Replication Lag Site), DRS (Delayed Replication Site), and just plain lag site. Officially, there really isn't a "correct" name as Microsoft and AD experts have referred to this concept in all four ways.

A lag site is a site in your AD that will contain at least one DC. This site is configured so that the replication only happens at a delayed schedule compared to all the other sites. This can be anything from one day to one week.

The purpose of lag sites is primarily to restore deleted objects quickly without having to go through the process of authoritative restores or even start working with tapes. If something gets inadvertently deleted, all that is needed is a replication in the opposite direction, from the lag site to the production DCs, and the deleted data is recovered. It is a clean, fast, and efficient way to recovery.

The other feature that is a natural by-product of a lag site, and used by quite a few organizations,...

In most corporations and large organizations, there are people with job titles such as "Network Architect", "Windows Server Configuration Owner" or "Network Designer". These people do not have these titles just for fun. In large organizations, there is an actual need for people whose sole purpose is to design or optimize the networking topology according to how technology progresses. This is also valid for people who work in the Security and the actual Business Solutions sections of large corporations.

There are always new ways of doing things and new designs surfacing in the IT world, and those people need to stay on top of their respective fields. If you are a medium to small-sized company, you can probably combine all of those roles into one person or have several roles distributed over few people.

This is especially true for Windows Server architecture and Active Directory. When designing your Active Directory, you need to really open your mind and focus on...

Now that we have gone through designing your Active Directory, and looked at some of the models available, we need to address security and documentation. These are both points that are just as vital as your design and migration. During the dot-com bubble, everyone that ever turned on a PC could call themselves a Systems Specialist or Systems Engineer. Crazy things, like Platform Designers, because they had a Windows 2000-based computer at home, were not unheard of either. The problems during the bubble were that people who really knew what they were doing were too expensive for a lot of companies to afford, and cheaper "specialists" were hired instead. These people then messed up most networks and network services and in the end were let go. The company then hired a more expensive person to fix the old issues, and so on. Because of this, and the rapid growth and changing markets during the bubble times, documentation was always ignored and backup solutions were...

In this chapter, we went through some of the key elements in Active Directory and then over to the actual design work. A few design models were dissected, and this should give you a good starting point for your own design. There are more in-depth books available and the aim of this book is not to help your design your Active Directory but to give you some guidance along the way. Finally, we looked at some of the crucial points to consider with your infrastructure, which included scalability, security, and documentation.

This should give you a good running start and good points to discuss with your management, or at least bring to their attention because they need to be aware of all of this, and they need to see some benefit in your work. Short-term winnings or savings are not always the best and cannot be applied to everything, and the things discussed in this chapter are prime examples of this.