When an instance of Active Directory is installed, the service installer creates service connection point objects (SCPs) in Active Directory. The primary objective should be to minimize replication traffic and to enable efficient administration and maintenance of objects.
Be aware that client applications find SCPs by searching the directory for keywords in the SCP. The keywords attribute of an SCP is included in the Global Catalog; clients can search the Global Catalog to find SCPs in the forest. For this reason, the client does not influence where to publish SCPs.
To minimize replication traffic, create SCPs in the domain partition of the domain of the service host computer. For example, you can create SCPs as child objects of the computer object on which the service is installed. A domain partition of Active Directory, sometimes called a domain naming context, contains domain-specific objects such as the objects for the users and computers of the domain. A full replica of all objects in the domain partition is replicated to every domain controller (DC) for the domain, but it is not replicated to DCs of other domains.
Do not create SCPs in the Configuration partition (also known as the configuration naming context), because changes to the Configuration partition are replicated to every DC in the forest. As noted above, clients throughout the forest can query the Global Catalog to find SCPs anywhere in the forest, so creating SCPs in the Configuration partition does not make them more visible to clients; it only generates more replication traffic.
Consider the following guidelines for object administration:
A good default location that satisfies both goals is to create SCPs and other service-specific objects under the computer object of the host computer of each service instance. For more information, see Publishing Under a Computer Object.
A good alternative for services not tied to a single host is to create a container for the service objects under the System container in a domain partition. For more information, see Publishing in a Domain's System Container.
The following diagram shows part of the default container hierarchy for a domain partition.
The diagram shows the default domain hierarchy included with Active Directory. However, many enterprises create a hierarchy of organizational unit (OU) containers to group object classes, such as users and computers, together for purposes of administration. Administrators can then apply policy and inheritable access-control entries (ACEs) to an OU to delegate administrative authority for objects in the OU. This enables administrators to efficiently manage an enterprise, but it has a few consequences for service programmers:
Service-specific objects should not be created in the following areas: