Chapter 8. Designing the Namespace

The basic emphasis of this chapter is on reducing the number of domains that you require for Active Directory while gaining administrative control over sections of the namespace using Organizational Units. This chapter aims to help you create a domain namespace design. That includes all the domains you will need, the forest and domain-tree hierarchies, and the contents of those domains in terms of Organizational Units and even groups.

There are a number of restrictions that you have to be aware of when beginning your Active Directory design. We will introduce you to them in context as we go along, but here are some important ones:

• Too many Group Policy Objects (GPOs) means a long logon time as the group policies are applied to sites, domains, and Organizational Units. This obviously has a bearing on your Organizational Unit structure, as a 10-deep Organizational Unit tree with GPOs applying at each branch will incur more GPO processing than a 5-deep Organizational Unit tree with GPOs at each branch.

• Under Windows 2000, you cannot rename a domain once it has been created. Fortunately, with Windows Server 2003, this limitation has been removed, although the rename process is tedious. You can even rename forest root domains once you've reached the Windows Server 2003 forest functional level.

• You can never remove the forest root domain without destroying the whole forest in the process. The forest root domain is the cornerstone of your forest.

• The Schema Admins and Enterprise Admins groups exist in the forest root domain only. So if you are migrating from a previous version of NT, be cognizant of the fact that the administrators of the first domain you migrate can have control over these groups and over Active Directory.

• Lack of a regional catalog is problematic. Imagine that you have 20 printers in your office in Sweden and 12 printers in your office in Brazil. The users in Sweden will never need to print to the printers in Brazil, and the users in Brazil will never need to print to the printers in Sweden. However, by default, details of all printers are published in the GC. Thus, whenever changes are made to printers in Sweden, all the changes get replicated to the GCs on the Brazil servers because the GC replicates all of its data everywhere. You have three options. You can decide not to replicate any printer data and force printer seraches to hit Active Directory each time, you can replicate all printer data everywhere, or you can create an application partition to host printer data and replicate it to designated domain controllers.

• Multiple domains cannot be hosted on a single DC. Imagine 3 domains off a root located in the United States, which correspond to 3 business units. Now imagine a small office of 15 people in Eastern Europe or Latin America with a slow link to the main site. The 15 users are made up of 3 sets of 5; each set of 5 users uses one of the 3 business units/domains. If you as an administrator decide that the slow link is too slow and you would like to put in a DC for the 3 domains at the local server and to ease replication, the small office will have to install 3 DCs.