Introduction

Active Directory domain controllers host exactly three predefined partitions. The configuration naming context is replicated to all domain controllers in the forest and contains information that is forest-wide, such as the site topology and LDAP query policies. The schema-naming context is also replicated forest-wide and contains all of the schema objects that define how data is stored and structured in Active Directory. The third partition is the domain naming context, which is replicated to all of the domain controllers that host a particular domain.

Windows Server 2003 introduces a new type of partition called an application partition, which is very similar to the other naming contexts except you can configure which domain controllers in the forest replicate the data contained within it. This capability gives administrators much more flexibility over how they can store and replicate data contained in Active Directory. If you need to replicate a certain set of data to only two different sites, you can create an application partition that will only replicate the data to the domain controllers in those two sites.

For more details on application partitions, see Chapter 3 in Active Directory, Second Edition (O'Reilly).

Application Partitions are new to Windows Server 2003, so this entire chapter applies only to Windows Server 2003 domain controllers. Windows 2000 domain controllers cannot host application partitions.

The Anatomy of an Application Partition

Application partitions are stored in Active Directory similar to domains. In fact, they consist of the same two objects as domains, a domainDNS object and a crossRef object that resides under the Partitions container in the Configuration Naming Context (CNC). Application partitions are named like domains and can be virtually anything you want. You can create an application partition that uses the current namespace within the forest. For example, in the rallencorp.com (dc=rallencorp,dc=com) forest, you could create an apps.rallencorp.com (dc=apps,dc=rallencorp,dc=com) application partition. Alternatively, a name that is part of a new tree can also be used, for example, apps.local (dc=apps,dc=local). Application partitions can also be subordinate to other application partitions.

Table 17-1 and Table 17-2 contain some of the interesting attributes of domainDNS and crossRef objects as they apply to application partitions.

Table 17-1. Attributes of domainDNS objects

Attribute	Description
dc	Relative distinguished name of the application partition.
instanceType	This attribute must be set to 5 when creating an application partition. See Recipe 17.1 for more information.
msDs-masteredBy	List of nTDSDSA object DNs of the domain controllers that replicate the application partition. See Recipe 17.4 for more information.

Table 17-2. Attributes of crossRef objects

Attribute	Description
cn	Relative distinguished name of the crossRef object. This value is generally a GUID for application partitions.
dnsRoot	Fully qualified DNS name of the application partition.
msDS-NC-Replica-Locations	List of nTDSDSA object DNs of the domain controllers that replicate the application partition. See Recipe 17.4 for more information.
msDS-SDReferenceDomain	Domain used for security descriptor translation. See Recipe 17.8 for more information.
nCName	Distinguished name of the application partition's corresponding domainDNS object.
systemFlags	Bit flag that identifies if the crossRef represents an application. See Recipe 17.2 for more information.