Where to Publish

To know where to publish services in Active Directory, you first must understand and observe the following guidelines:

• A service needs to publish its information in the domain hierarchy, and never in the configuration hierarchy.

• A service needs to create service-specific objects in the same domain as the computer running the service, and in locations that are convenient for the administration of the service and maintenance of those objects. The recommended location is the computer object on which the service is installed.

If a client is able to access a computer running a service, that client should be able to access a replica of the domain containing that computer.

Note

The client can rarely identify the computer on which the service is running. The client normally finds the service from the keyword attribute The keyword attribute may contain the GUID that is specific to the vendor and application. However, the service that publishes the information must publish the keywords attribute. For more information on the keywords attribute, see the Microsoft Platform SDK link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Therefore, it is sufficient for a service to publish information to the domain that contains the computer running the service. Publishing service information to the configuration hierarchy does not make the service more available or easier to access. It does, however, cause extra replication traffic. To maximize efficiency, do not publish service information to the configuration partition.

Clients find service objects by querying the directory. The client can scope the query to its domain, or it can search the entire forest using the Global Catalog. In either case, the specific location of the service object is irrelevant to the client. Therefore, the client does not influence the location to which to publish service objects. Instead, the key consideration is the ease with which the service can be administered.

In the domain hierarchy of Active Directory, service-related objects occur in three places, which are the following containers:

• Computer

• Organizational-Unit

• System or one of its children

Note

In Active Directory (and many other directory services), any object can be named as a valid parent, defining it as a container. This allows a directory to have an intuitive structure. For example, objects that relate to exactly one computer should appear in the directory as children of that computer, where an administrator expects to find them.

Computer Object

When you publish services for a computer, create service-specific objects as children of the Computer object where the service is installed.

For ease of installation, many services use a "default" location in which to create their objects, but most services allow their objects to be moved after creation. The Computer object where the service is installed is a convenient and intuitive location for these objects, because when a Computer object is moved to a different location, Active Directory also moves the service objects to the new location. Also, when a Computer object is deleted or joins another domain, the service objects are also deteled. Therefore, there is less likeliness of having an orphan service. A process running on a computer that is a domain member can always find the computer object in the directory

Note

Only computers that are domain members have valid Computer objects in the directory.

Organizational Unit Container Hierarchy

Active Directory allows you to create a container hierarchy that meets the needs of your organization. The object class for building these hierarchies is organizationalUnit . It is a general purpose container that you can use to group together most object classes, including computer objects, for administrative purposes. You might want to also group service-specific objects together for administrative purposes. Active Directory enables you to set permissions on all of the objects in a container or a subtree with a single ACL. Windows 2000 uses a permissions model that allows you to apply very fine-grained access control to objects in the directory and to delegate administrative authority to other users.

All of the standard service-related object classes are valid children of the organizationalUnit object class. This means that a service does not require its objects to reside at a fixed location in the directory.

For sample code that creates a service object, stores its objectGUID, and locates the service object using the objectGUID, see the MSDN link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Users and Computers Containers

When you upgrade to Windows 2000 from Windows NT, the upgrade process places users, groups, and computer accounts in the containers for users and computers. User and group objects are stored in the Users container, and computer objects are stored in the Computers container. Windows NT and APIs (such as the Net API) that create users, groups, and computer accounts, use tools that create these objects in these containers automatically.

Do not move service-specific objects directly into these containers, or create new containers in these containers. However, services can publish objects as children of a computer object, whether or not the computer object is stored in the Computers container. Create service connection points under the computer object on which the service is installed.

System Container

The System container stores operational information, organized by domain. This information includes the default local security policy, file link tracking, network meetings, and containers for connection points to RPC and Windows Sockets (Winsock). By default, the System container is hidden, and it provides a convenient place for storing objects that are of interest to administrators but not to users.

Services that use the Winsock RnR or RpcNs APIs to advertise themselves automatically create the proper objects in the WinsockServices and RpcServices containers . Do not explicitly create or move objects in these containers .

Services that create service-specific objects in the System container must perform the following operations:

• Create a subcontainer of the object class container, which is an immediate child of the System container, and give it a name that clearly relates it to the service.

• Publish the service-related objects in the System container. For example, Microsoft® NetMeeting® uses the Meetings container to publish network meeting objects. When multiple products from a single vendor publish objects in this manner, the containers for each service need to be created as children of a container (an object of the class container), and the container needs to be given a name that clearly relates to the particular vendor. The vendor-specific container must be created as a child of the System container.

You need to publish services in a container beneath the System container when your service, like NetMeeting, is not strongly tied to a single computer.