If you are having Active Directory issues and think it's too big of an issue to fix, take heart. There is a way.
Group Policy object (GPO) Loopback processing is a cool way to force user settings from a GPO applied to a computer account rather than receiving the settings from GPOs applied to the user account. This way lets the computer control the user settings. But, did you know that there is a very cool reason to use Loopback processing as a primary Active Directory (AD) design component? Furthermore, why in the world would you want to?
Consider one company whose business requirements were such that it had dedicated computers -- workstations and servers that ran specific applications. This company had several of those business-critical applications and each ran on a specific set of workstations. When employees needed to use a particular application, they would log on to one of these machines, either at the console or via terminal services. Remote users, of course, used terminal services. Each application had a unique environment including a specific desktop configuration, specific rights and certain desktop applications and versions. Even the operating system on the workstations varied from application to application. Thus, when employees logged in to one of these machines, they would get the desktop environment forced on them for the particular business-critical application they were using.
The company had a number of administrative and technical issues, and I was asked to review its AD design.
Analyze your AD design and fix it
We decided to evaluate the existing domain structure and then see how we would redesign it if we could turn back the clock and do it over again. Figure 1 shows the existing OU structure. This is pretty much a classic structure where we have departments divided up into OUs, each OU with sub-OUs of users and computers. In this structure, they had implemented Loopback processing in GPOs on each computer OU. In addition, they implemented GPOs at each User OU that applied settings to the user accounts. Thus, when a user in the AppA User OU logs into a workstation in the AppA Computer OU, he gets the user settings from the GPO in the computer OU due to Loopback processing.
This seemed quite inefficient, since the user processed the GPO from the User OU, then processed the GPO from the Computer OU. Loopback processing in "Replace Mode" guarantees that the user will never apply settings from the User OU. In addition, it made no sense that users are assigned to the several OUs but must log on to computers in other OUs.
Figure 2 shows the new design. Note the several improved design points:
All users are in a single OU. Since users log on to computers in all OUs and receive policy from those computers, it only makes sense to gather them all in a single OU.
- The User OU has no GPOs applied for reasons stated in point number 1.
- A top-level OU, called Applications, will be the parent for the individual OUs for each application. This allows for a better structure, putting similar OUs such as Exchange, Servers and so on as peers. In addition, we can apply GPOs to the Applications OU that will define common settings to all subordinate OUs, making GPO management easier.
- Additional OUs can be added for new applications.
- A single GPO defining Loopback processing in Replace Mode was implemented at each Applications OU to avoid conflicts with other GPOs they had experienced.
- All workstations will be included in each specific Application OU. For instance, workstations supporting App-A will be in the App-A OU. That is how it is currently configured in the old design.
- IT Staff user accounts exist only in the Users container at the Domain level. This permits the separation of those accounts from other users for GPO and administration purposes without adding another OU.
We designed the entire OU structure to accommodate GPO Loopback processing, which, in turn, allowed the creation of pristine environments for business-critical applications. This achieved the greater goal of an AD structure designed to support business needs.
The interesting thing is that this was a production environment, not a migration to a new structure. It was possible and acceptable to modify the structure of an existing AD environment and morph it into a new, better one. I have worked cases where we have made significant changes causing a redesign of the domain structure and replication topology in order to fix a broken design. This process means you don't have to live with a broken environment -- you can fix it instead.
Gary Olsen is a systems software engineer for Hewlett-Packard Co. in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.
