When designing your Active Directory environment, you should aim to make it both match the structure of your business, and also be managed by whatever management model your IT organization operates under. Typically, organizations fall into one of three or four common models for managing their IT infrastructure:

When Active Directory first came to market in Windows 2000, it was common to deploy multiple domains to mimic the existing NT4 deployment or for various other reasons, and most large companies that deployed Active Directory early on still have this model today. There is nothing wrong with the early best practices, such as empty root domains or regional domains, but conventional wisdom today says that you should endeavor to have the fewest number of domains possible. That said, by no means are we recommending that you rush off to collapse domains created early on unless you can achieve cost or management savings that exceed the cost of this restructuring.

One of the most common justifications that will be made for an additional domain in the forest is a purely political requirement to separate administration. In reality, determined administrators of any domain in a forest could elevate their privileges to the Enterprise Admin level without too much work. Instead of creating a separate domain in this situation at a relatively high cost (with practically no benefit), use organizational units over which you can delegate the necessary permissions.

As you go through the process in this chapter, keep in mind that, especially in large organizations, businesses frequently reorganize. Develop a design that you feel can survive multiple reorganizations without substantial investment in changes to your Active Directory design. Our experience is that designs based more on geography, location, or support models tend to fare better as the organization evolves.

Although we’ll discuss replication in more depth in the next chapter, you should begin to consider it from a high level at this point, as it can have a substantial impact on the domain design you settle upon. Many large organizations have elected to deploy domains in a regional fashion that matches major divisions in WAN topology. Such models often include domains such as Americas, AsiaPacific, and Europe or EMEA (EMEA is a common acronym for Europe, Middle East, and Africa). The reasoning for this is to segment replication at a high level. Environments with large domains cannot always bear the replication overhead of replicating all of the contents from an Americas domain to a remote site in Asia, for example.

Since Windows 2000, replication has improved greatly (with respect to compression, in particular), and WAN links have gotten faster in some regions. As you explore design options, you will need to consider whether or not your WAN could be impacted by the replication overhead of a large domain and if limiting this replication would be beneficial. Keep in mind that even if you segment your domains on a regional basis, there will still be some interregional replication for the Global Catalog.

In Chapter 11 and Chapter 15, we explain the basics of group policies and how to properly design them. For now, the important thing to understand is that policies are Active Directory objects that reference a number of settings that can be applied to users or computers. These settings are things like a fixed desktop, a certain core set of applications, the ability of users to perform a shutdown, and so on. If you create an organizational unit called Finance and then decide that it needs special settings, you can create a GPO and assign it to the OU. Then the computer settings and user settings in the GPO will be applied to all computers and users under the Finance OU.

We now need to look at what settings have to be applied on a domain-by-domain basis. Here’s a list of what types of settings can be set only on a domain-wide basis:

If a special department or geographical area needs special encryption, security safeguards, certificates, and so on, you may need a separate domain for it.

You now should have your first draft of the list of domains that you think you will need. There is one more very important point on this subject. Domains are very inflexible and unforgiving, and due to the fact that you can host only a single domain on a domain controller, each domain you add means at least one more domain controller you have to support.

Depending on how many domain controllers you would have to deploy for a domain, you can greatly decrease your total cost of ownership (TCO) for Active Directory by limiting the number of domains you support. In general, we recommend that you start with a single-domain design for any new Active Directory forest unless you have a compelling technical reason not to.

There are two ways to go about choosing the forest root domain. The first model is to deploy an empty root domain. The empty root simply contains a small number of domain controllers and accounts for the Active Directory administrators for the forest. The empty root is the most common model you’re likely to see in large environments that have had Active Directory deployed for some time.

The second model is to simply choose a domain that you know will be required for the lifetime of the forest as the forest root domain, which can never be removed. If you are deploying a single-domain forest, this decision is simple. If you are deploying multiple domains, you should keep in mind your namespace requirements as you design the hierarchy, such that the forest root domain is actually at the root of the tree.

If you are planning to deploy a single-domain forest—the model that we generally recommend—there is no reason to deploy an empty root simply because it is an option. Making your sole domain the forest root is perfectly acceptable.

As each domain has a DNS name to identify it, you need to consider what names you are going to choose. You can use any of the RFC 1123 standard characters:

Microsoft’s DNS server implementation supports a wider range of characters, such as the Unicode character set, but if you need compatibility with other DNS flavors, be very careful allowing these.

There are currently two schools of thought on how to pick the DNS names for your Active Directory network: root zone or subzone. The root zone method says that you name your root Active Directory domain based on the root zone for your organization. For the Coho Vines forest, this would be cohovines.com. The subzone method suggests that you pick a new subdomain from your root zone and make that the base of your Active Directory namespace. For Coho Vines, this could be ad.cohovines.com.

If you choose the root zone method and wish to have a non-Windows DNS server at your root, you will need to either enable dynamic updates or manually register a number of records in the DNS servers, as discussed in Chapter 8. If you choose the root zone method and wish to have a Windows DNS server at your root, you will need to migrate your existing entries, if you have any, to the new DNS servers. Both methods are fine, but they require configuration or migration at the root.

A less invasive procedure would be to choose a new subzone for your Active Directory network and run your network from that. With this setup, you still have two choices, but they are less disruptive to any existing structure and don’t affect the main root zone. Arguably, the easiest solution is to let two servers on your network run Windows DNS Server and manage this DNS zone. This allows you to have a root that doesn’t allow dynamic updates and a subdomain that does. In this case, your existing main root zone DNS servers would contain a DNS delegation for the subzone. The subzone would be delegated to your Active Directory DNS servers. The alternative would allow a non-Windows DNS server to manage the zone.

Another common extension of the root zone method is to choose a parallel namespace, such as cohovines.net, for your Active Directory network. This allows you to have a root-level namespace and not need to migrate existing DNS entries or manage a split-DNS model if cohovines.com is also your external namespace.

To continue with the planning process, start with the forest root: draw a triangle on the paper and assign a DNS name to the domain, writing the name inside or beside the triangle. You should choose the name very carefully, for two reasons. First, while renaming a domain is possible beginning with Windows Server 2003 Active Directory, it is a highly invasive process and is not generally recommended unless absolutely necessary. Second, you can never remove the forest root domain from Active Directory. If you need to change its name, you must destroy your entire forest and start again.

Having created and named your forest root, you need to consider your other domains. If you have two distinct business units or companies, some analysts may think that they will require noncontiguous names to match the structure. This means that you will need two trees coming from a domain root. Think long and hard about this decision—multiple domain trees in a forest add complexity and often cause support and application confusion for no real benefit. Some common examples that people will use to indicate a perceived need for multiple trees are different email address suffixes, different UPN suffixes, resource separation, and security separation. However, separate trees aren’t actually required to implement any of these requirements.

If you still conclude that you need multiple trees, draw all the other tree root domains that you think you will need as separate triangles at the same horizontal level on the paper and assign them valid DNS names. These domains are all tree root domains, but they should not be confused with the forest root domain.

A real-world example of this scenario is the Microsoft brand name and the MSN brand name (Microsoft owns MSN). Both msn.com and microsoft.com could be separate trees in the same forest. They couldn’t be in the same tree without giving them a hierarchical link, i.e., msn.microsoft.com. However, the only real benefit for having an msn.com and a microsoft.com in the forest instead of an msn.microsoft.com is how it all looks on a PowerPoint presentation.

So far, we’ve been considering domains that will exist in the same forest, but you may have business units that will require two entirely separate forests. How do you know if that is the case? There are a number of common scenarios for this.

If you have business units in an organization that are independent and in fact wish to be isolated from each other, then you must not combine them in a single forest. If you simply give each business unit its own domain, these business units can get the idea that they are autonomous and isolated from each other. However, in Active Directory, this level of isolation can be achieved only through separate forests. This is also the case if you need to comply with regulatory or legal isolation requirements.

The first and most common reason for this design may be political: certain business units may decide that they want to be as autonomous as possible. It may be that, politically, the Finance Department has to be completely separate, so you end up making a second forest with finance.cohovines.com as the second forest’s forest root domain. In effect, you are treating this business unit as a separate, autonomous, and noncontiguous part of the tree.

Another reason that you may need two forests involves having two businesses that must be separately maintained for regulatory or other legal reasons. Similarly, if you have a business that may be divested or sold in the future, it will be much easier to separate if this business exists in its own forest.

The third reason is one born out of necessity. Remember from Chapter 2 that certain aspects of a namespace are forest-wide in scope. If you want to isolate a separate schema or configuration partition, your only solution is to create a separate forest.

The fourth reason, which is becoming more common, is the need for a separate forest for Microsoft Exchange. Exchange is very tightly integrated into Active Directory and does not always allow for a clean separation of duties through delegation. Additionally, Exchange can have management challenges with multidomain deployments in a single forest. These two considerations can often result in a single-domain resource forest being implemented for Exchange, with trusts configured to the appropriate domains in the primary forest or to the primary forest itself.

Finally, a fifth reason is to separate specific users, servers, or applications. It is not uncommon to deploy a dedicated forest in a perimeter network and join those servers to a domain in the primary forest. A one-way trust from the primary domain(s)/forest to the perimeter network forest enables internal users to access applications in the perimeter network, but it does not allow servers in the perimeter network to access internal resources. A common extension of this model is a specific forest for external users (such as business partners or customers) that need to access an application.

If any of these reasons apply, you need to create a second forest root domain and give it a unique DNS name, as you did for the first forest root domain. In effect, you need to separate your designs and design each forest individually. The best thing to do now is to figure out how many forests you need and which domains from your list are going to be the forest root domains. Once you have determined this, you will name these root domains and then use a separate piece of paper to draw each forest. Maintain separate lists of domains for each forest. You’re now creating x designs, where x is the number of forests you have.

There is one other important point that you need to be aware of. While domains and trees in a forest maintain automatic trust relationships, it is possible to set up manual trust relationships with domains external to a forest. You can therefore set up manual trust relationships between forests. These relationships can be one-way trusts (A trusts B but B does not trust A) or two-way trusts (A trusts B and B trusts A).

The first option allows other domains that are members of another domain tree in a different forest or that do not support Kerberos authentication to have limited access to a domain in the forest. Only resources in that domain will be visible; no other resources in the tree will be available for access. The second option is to create a forest trust between two forests. With a forest trust, all of the domains within each forest will transitively trust each other.

You now have a forest root domain with a valid DNS name. You may have other domains that act as the roots of separate trees in the same forest; you may even have extra forest root domains representing separate forests entirely. Now you need to lay out the domain tree hierarchies. If you have a number of remaining domains listed on your sheet of paper from step 1, these are the subdomains that will form your domain-tree hierarchy.

Start with the first forest. Representing each domain with a triangle on the paper, arrange the domains in a hierarchical fashion beneath one of the domain tree roots in the forest. Name each domain appropriately, according to its position in the hierarchy. Repeat this process for all domains in this forest, then move on to the next forest (if necessary) and repeat.

For example, if we have cohovines.com as a tree root, and the North America, Europe, and Asia-Pacific regions all need separate domains, we can call them northamerica.cohovines.com, europe.cohovines.com, and asiapacific.cohovines.com. If the Asia-Pacific region needs a separate domain for Japan, we’ll arrange this domain beneath AsiaPacific, as japan.asiapacific.cohovines.com.

The easiest way to start a design is to consider the business and administrative models that you sat down with when creating these designs. You now need to recreate that structure in Active Directory using OUs as the building blocks. Create a complete OU structure that exactly mirrors your business model as represented by that domain. In other words, if the domain you are designing is the Finance domain, implement the finance organizational structure within that domain. You don’t create the entire organization’s business model within each organizational unit; you create only the part of the model that would actually apply to that OU. Draw this structure out on a piece of paper. Figure 13-3 shows a sample structure that matches the business’s organization directly. For simplicity, we’ve expanded only the Finance OU here.

Figure 13-3. The Mycorp domain’s internal organizational unit structure

Once you have drawn an OU structure as a template for your Active Directory hierarchy within the domain, you can begin to tailor it to your specific requirements. The easiest way to tailor the initial OU design is to consider the hierarchy that you wish to create for your delegation of administration.

First, identify any areas of your hierarchy where you need to grant administrators autonomous access over their branch of the tree. Each OU should have at least two administrators who will look after that organizational unit. These administrators will take care of the structure below the organizational unit, creating whatever OUs, users, groups, and so on that they desire. They will not, however, have administrative access to any other part of the tree.

You need to note two pieces of information about each of the organizational units that you identify:

Having noted these two pieces of information for all organizational units that need full administrative access, you next need to identify those organizational units that require some users to have a more restricted set of permissions. You may want to set up account administrators that have the ability to create and delete user accounts, and to set passwords and account details. We’re interested in rights only in general terms at the moment, so just note the following:

It is possible to set access rights of any sort down to the individual property level on a specific object if you require. That means you can allow a user named George Washington to change the password or telephone number of a user named James Madison (and only that user) if you wish. Obviously, the more granular the access, the more complex things can get, especially since permissions are inherited down a tree by default. To make things easier, Microsoft provides a simple Delegation of Control Wizard that allows you to set these access rights in a fairly easy manner. Active Directory permissions are covered in much greater depth in Chapter 16; all we’re concerned with at this stage in the design is delegation of control at the organizational unit level. From experience, we can tell you that assigning access rights at the organizational unit level is always much simpler to manage than tracking permissions to individual objects and properties.

When you are planning for user accounts, the only thing you really have to worry about is the username or user identifier that the client logs on with. Each username (the sAMAccountName property of a user object) must be unique throughout each domain. If you have decided to delegate administration within your organization, and you allow delegated administrators to create user accounts, you need to create a naming convention that each administrator will adhere to so that unique usernames are generated for all users throughout your forest.

Another name that you assign to all Active Directory users is the user principal name (the userPrincipalName attribute of the user object). This property looks like an RFC 2822 email address, i.e., [email protected]. In reality, this property is not the email address but is a unique identifier for the user across the entire forest. The value must be unique as it uniquely identifies a user across an entire forest. So, while having a user with a sAMAccountName value of George.Washington in cohovines.com and in executives.cohovines.com is perfectly valid, the UPNs for each user account must be unique.

Often, UPNs are created by simply appending an @ symbol and the domain onto the end of the username. This ensures uniqueness because the username is unique in the domain, and appending the domain forces a unique forest-wide UPN. This makes [email protected] and [email protected] the UPNs for the two user accounts in the preceding example.

However, while it is conventional to construct the UPNs in this way, you can in fact make the UPN of a user anything you wish as long as it follows the format specified in RFC 2822. We could, for example, append @cohovines.com to all our users, eliminating the need to rely on domains at all. If we do this, though, we should ensure that all of our usernames (sAMAccountName) are unique forest-wide. In the previous example, we wouldn’t be able to have two users with the username George.Washington. For such a scheme to work, a central database or allocating authority needs to be set up to uniquely generate and allocate names. If this database or authority can generate unique usernames via a reliable algorithm, you can make use of a much simpler UPN.

UPNs are very important. Imagine a user sitting down at a client anywhere in a forest and being presented with the logon dialog box. Here, the user can type in her username (sAMAccountName), password, and domain, and be authenticated to the forest. However, it is perfectly valid to authenticate with the UPN. If the user, presented with the same logon dialog box, instead types a UPN in the username field, she will no longer need to specify a domain.

In other words, a UPN and a password are all that is needed to authenticate to Active Directory. This makes sense since the UPN is unique forest-wide; apart from a password, nothing else should be needed. You now should be able to see that even with a very large and complex set of domains in a forest, you can use a simplified UPN form that does not contain a domain component and then simply instruct users to log on with a UPN and a password. This means that users never need to care about what domain they are in.

Many organizations choose to use their users’ email addresses as UPNs. The benefit to this strategy is twofold. The first benefit is that users can be instructed to log in with their email addresses and thus are required to remember one less piece of information. The second benefit is that email addresses are unique identifiers, so the UPNs will be too.

Your choice of where you place the user accounts in each domain’s hierarchy is really affected only by who is to administer the accounts and what GPOs will be applied on the OUs the accounts are in. Other than that, it makes little difference.

Groups need unique names, too, so a naming scheme for groups should also be laid out in the design. Where you put groups is less important. In effect, groups can go almost anywhere in the hierarchy. The GPOs that determine your placement of users, for example, do not apply to groups.

Much like users, groups also have a sAMAccountName field that must be unique within the domain. If you are delegating administration such that delegated administrators can create groups, we recommend that you devise a naming convention that establishes the department or organization that owns the group in the name. For example, you might prefix all group names with a two- or three-letter code that refers to the group’s owner.

If possible, we highly recommend that you consider an external tool for managing group objects if you are going to delegate the ability to create and manage groups. This will allow you to establish group purpose, ownership, audit trails, and lifecycles for groups. This helps limit the sprawl of groups in the directory that have no known purpose or owner. Microsoft Forefront Identity Manager (FIM) is one example of a tool that can help meet this recommendation.

Given the small size of the organization, and connectivity requirements, Tailspin Toys elects to deploy a single-domain Active Directory forest. There are no requirements identified where a separation of replication would be necessary. Likewise, there are no concerns that require any resources to be separated into a separate forest.

This domain/forest will be called tailspintoys.com with a NetBIOS name of Tailspin. Given the simple design, there is no need to worry about tree structures or naming beyond the name of the root domain.

Tailspin Toys manages almost all of the objects in Active Directory centrally. Since there is limited need for complex permissions delegations, Tailspin Toys focused on Group Policy when designing its OU structure. After reviewing the organization’s needs, a location- and object-based OU structure was developed. This allows policies to be targeted to physical locations as well as specific types of objects (e.g., desktop computers versus laptops). Figure 13-4 shows the top-level OU structure for Tailspin Toys.

Figure 13-4. Tailspin Toys top-level OU structure

Due to the business-critical nature of machines that support manufacturing activities, a separate Manufacturing OU structure was established for shop-floor computers to isolate them from management of end user machines.

Figure 13-5 shows the OU structure under the Locations OU for the San Francisco office, as well as the parent structure. Organizing the machines hierarchically by geography allows the IT Department to apply group policies targeting users globally, regionally, or at a per-location level. The IT Department has also assigned a location code to each site to identify the site on the network. For simplicity, location codes are a combination of the three-letter airport code for the city as well as a two-digit number, in case there are multiple offices in a given city.

Figure 13-5. Tailspin Toys Locations OU

To keep management straightforward, a similar structure was developed for the Manufacturing OU. Since the Manufacturing OU will only contain machines used to support shop-floor activities, a consolidated version of the structure in Figure 13-5 was developed, as shown in Figure 13-6. Manufacturing machines are simply placed in the site’s OU.

Figure 13-6. Tailspin Toys Manufacturing OU structure

Once the OU structure was finalized, a permissions delegation plan was developed. Based on Tailspin Toys’s centralized IT organizational model, there are only two sets of permissions that need to be delegated in Active Directory:

Both of these tasks were easily delegated using the Delegation of Control Wizard in Active Directory Users and Computers.

Since Tailspin Toys places its workstations in OUs based on the physical location of the machine, the type of machine (e.g., desktop or laptop), and the function (client computer, kiosk, or manufacturing machine), it decided to incorporate all of these data points in its naming convention. Additionally, based on input from desktop technicians in the field, the location (e.g., office number or cubicle) of the machine at an individual site is incorporated as well.

Tailspin’s naming convention is documented in Figure 13-7. The naming convention documents each possible character within the 15-character maximum limitation Active Directory imposes.

Figure 13-7. Tailspin Toys computer naming convention

The fields are:

Based on the correlation of the naming convention to the OU structure, a script is developed to automatically move any machines in the default Computers container to the appropriate OU. The script is scheduled to run every five minutes. This alleviates the need for IT to manually move computers in the directory.

The server naming convention illustrated in Figure 13-8 is straightforward and similar to the desktop naming convention.

Figure 13-8. Tailspin Toys server naming convention

The fields are as follows:

Given the relatively small size of Tailspin Toys, a simple user naming convention comprised of the first initial of the user’s first name followed by the user’s last name is devised. For example, George Washington’s username would be gwashington. In the event of a conflict, a two-digit sequential number is appended to the end of the username to guarantee its uniqueness.

Since all groups will be centrally managed by the IT Department, names are assigned on an ad hoc basis that best corresponds to the purpose of the group. A policy is in place that requires the purpose of the group as well as two functional owners for the group to be listed in the notes attribute of each group. The group’s functional owners are responsible for approving additions of users to groups as well as reporting on what the group is used for.

Given Contoso’s plans to include students in the central Active Directory forest, there is a great deal of debate surrounding whether or not student accounts should be placed in a separate child domain or even in a separate forest. A separate student account forest is quickly ruled out, given the need for a central directory for applications to interact with, as well as the need for straightforward management. After reviewing the facts, including the reality that child domains do not create security boundaries, Contoso College decides to move forward with a single-domain forest that will contain all of the user accounts.

Contoso already has an existing DNS infrastructure running on Unix BIND servers. Since the Windows administration team will manage Active Directory, and the Unix BIND environment is not configured to support dynamic updates, Active Directory will be deployed in a subzone of Contoso’s root domain (contoso-college.edu). The subzone will be delegated to the Active Directory domain controllers and hosted in an Active Directory–integrated DNS zone. In order to provide a generic name for the domain, the DNS name of net.contoso-college.edu is chosen. The NetBIOS name of NET will be used.

Contoso needs to satisfy a number of sometimes competing demands while planning the OU structure. The first is for a domain that is manageable by central IT resources while also being flexible enough to meet the needs of delegated administrators in various departments at the college. In order to meet these needs, Contoso develops the top-level OU structure shown in Figure 13-9.

Figure 13-9. Contoso College top-level OU structure

Here is a description of each top-level OU in Figure 13-9:

The structure for each delegated OU is a blend of a fixed structure that is common across the environment with the flexibility for delegated administrators to create OUs in certain locations. Figure 13-10 shows the fixed structure that is created under each delegated OU.

Figure 13-10. Contoso College department OU template

Within each delegated OU, there are a number of child OUs:

Due to the distributed nature of Contoso College, there is no well-defined workstation or server naming convention in use across the organization. Departments are required to register a prefix of two to five characters with the central IT organization when they receive a delegated OU. All workstation and server names must be prefixed with this code. Computer accounts are automatically moved to the correct OU based on the prefix on the computer object’s name.

Contoso College assigns a unique username to every user when they are entered into the college-wide enterprise resource planning (ERP) system. This username is reflected in Active Directory by the identity management system when the user’s account is provisioned. If a user wants to change her username, she must request this change via the Human Resources or Student Affairs Department. If the change is approved, it will be entered into the ERP system and then automatically reflected in Active Directory.

In the case of manually created accounts such as guests, Contoso’s security policy states that guest account usernames must be prefixed with g-. Additionally, these accounts must have an expiration date defined in Active Directory. Central IT automatically disables guest accounts that do not have an expiration date defined on a nightly basis.

Service accounts must be prefixed with sa- and the description field must explain the purpose of the account.

Groups may be named however the creator desires; however, the name must be prefixed with the two- to five-character code that is registered with IT when an OU is requested. This ensures that group names will not conflict.

Traditionally, if Fabrikam were designing its Active Directory installation in the Windows 2000 time frame, it would likely have opted to deploy an empty root domain with a series of child domains organized by region (e.g., domains for North America, Europe, South America, and the Asia-Pacific region). Considering the size of the directory and the network connectivity challenges that Fabrikam faces in South America and Asia, it is not out of the question that segregating replication by deploying child domains in some regions may be an appropriate and necessary solution.

Considering the relative cost and complexity of deploying a multidomain forest, as well as the lack of complete performance data and impact analysis around the network, Fabrikam decides to move forward with a single-domain forest. When considering the impact of replication, Fabrikam recognized that the benefits of a multidomain forest would be somewhat limited in the branch offices with domain controllers, as they would still require local Global Catalog presences. In the event that it becomes apparent that performance in South America or Asia is adversely impacted by using a single global domain, Fabrikam will deploy a child domain in that region and migrate users, computers, and other resources into the child domain.

Trey Research is an independent subsidiary of Fabrikam that Fabrikam intends to maintain as a separate company. Trey Research has contracts with Fabrikam competitors, and management feels there is a potential that Trey Research may be divested in the future. As a result, Trey Research will continue to maintain a separate forest with a two-way trust to the Fabrikam forest.

Fabrikam has an existing DNS infrastructure, and the cost of moving to a split-brain DNS model for the fabrikam.com zone is prohibitive. Currently, Fabrikam owns the fabrikam.net domain name, but the namespace is not being used for anything. Consequently, Fabrikam decides to deploy its forest root domain as fabrikam.net with a NetBIOS name of FABRIKAM.

Once the forest is operational, a two-way forest trust is established with the treyresearch.com domain.

Given Fabrikam’s semi-decentralized model of IT administration, a good number of permissions will need to be delegated to technicians at branch offices that manage IT resources locally. All of the IT personnel across the company are ultimately accountable to the headquarters IT staff in Chicago, so control will not be delegated such that local personnel have carte blanche access to their respective locations.

Instead, a standardized structure will be put in place for each location. Local personnel will have access to perform tasks relevant to their jobs, and IT personnel at the headquarters office will have access across all locations in the company.

Figure 13-12 shows the top-level structure for the Fabrikam domain.

Figure 13-12. Fabrikam top-level OU structure

Here is a description of each top-level OU:

The Sites OU is shown in Figure 13-13. Each location-specific OU is organized by region, country, and then site. This allows administrators to delegate control at each level of the hierarchy (for example, to grant helpdesk analysts in Singapore the ability to reset user passwords for all users in Asia), as well as to apply group policies at any level of the hierarchy.

Figure 13-13. Fabrikam site-level OU structure

Fabrikam is using a desktop management solution to keep track of all its desktops and laptops. Machines also move around the company fairly frequently, and employees often do not stay employed with the organization for long periods of time. Consequently, Fabrikam doesn’t want to encode information about the location of the computer or the employee using the machine in the name. At the same time, Fabrikam needs to ensure computer names are unique on the network and have a way of correlating a given machine to its record in the desktop management database.

To achieve this, Fabrikam decides to name each machine based on its manufacturer’s serial number. Since Fabrikam uses multiple suppliers for desktops and laptops, it decides to prefix the machine’s serial number with a two-character code for the machine’s manufacturer, as shown in Table 13-2. This naming convention is easy for technicians to implement, never requires a change in the machine’s name, and guarantees correlation of the machine name with the asset management database.

For servers, Fabrikam maintains information about each server and what its role is in a configuration management database (CMDB). Since all of this information is tracked in the CMDB, Fabrikam decides to name servers based on a location code for the site hosting the server followed by a sequential four-digit number that uniquely identifies the server at that location. For example, a server at the SEA01 site might be named SEA01-0096.

User accounts will be provisioned automatically from the central human resources (HR) database maintained at the Chicago headquarters. Due to the sheer number of employees and the potential for duplicates, the provisioning system constructs a unique username for each user that is comprised of portions of the user’s first name, middle initial, and last name.

Groups are named arbitrarily by the user that creates the group through the central group management system.