Note:

It is recommended that you deploy global settings to the Configuration container over the System container. If you are migrating from an earlier release and have used the System container but plan to use the Configuration container, you MUST move the settings in the System container BEFORE you do any upgrade preparations. To migrate your System container settings to the Configuration container, see Microsoft Office Communications Server 2007 Global Settings Migration Tool at http://go.microsoft.com/fwlink/?LinkId=145236 .

When deploying Office Communications Server, the first step is to prepare Active Directory Domain Services. Preparing Active Directory Domain Services for Office Communications Server consists of the following three steps:

• Prep Schema. This task extends the schema in Active Directory Domain Services to include classes and attributes specific to Office Communications Server 2007 R2. Prep Schema can be performed only by schema administrators or by a local administrator on the schema master.
  
  
• Prep ForestThis task creates global settings and objects in the forest root domain, along with the universal service and administrative groups that govern access to these settings and objects.
  
  
• Prep Domain. This task adds the necessary access control entries (ACEs) to universal groups that grant permissions to host and manage users within the domain. Prep Domain is required in all domains where you want to deploy Office Communications Servers and any domains where your Office Communications Server users reside.
  
  

For detailed information about each of these Active Directory preparation steps, see Preparing Active Directory Domain Services for Office Communications Server 2007 R2in the Deployment documentation.

During Prep Forest, Office Communications Server creates various universal groups within Active Directory Domain Services that have permission to access and manage global settings and services. These universal groups include:

• Administrative groups. These groups define the fundamental administrator roles for an Office Communications Server network. During Prep Forest, these administrator groups are added to Office Communications Server infrastructure groups.
  
  
• Infrastructure groups. These groups provide permission to access specific areas of the Office Communications Server infrastructure. They function as components of administrative groups, and you should not modify them or add users to them directly.
  
  
• Service groups. These groups are service accounts that are required to access various services provided by Office Communications Server.
  
  

The following table describes Office Communications Server universal groups and their privileges.

Table 1. Universal Groups Created by Office Communications Server 2007 R2

During activation, Office Communications Server publishes server information to the three following locations in Active Directory Domain Services:

• A service connection point (SCP) on each Active Directory computer object corresponding to a physical computer on which Office Communications Server is installed.
  
  
• Server objects created in the container of the msRTCSIP-Poolsclass.
  
  
• Trusted server lists.
  
  

Each Office Communications Server object in Active Directory Domain Services has an SCP called RTC Services, which in turn contains a number of attributes that identify each computer and specify the services that it provides. Among the more important SCP attributes are serviceDNSName, serviceDNSNameType, serviceClassname, and serviceBindingInformation. Third-party asset management applications can retrieve server information across a deployment by querying against these and other SCP attributes.

Each Office Communications Server role has a corresponding Active Directory object whose attributes define the services provided by that role. When a Standard Edition server is activated, or when an Enterprise Edition pool is created, Office Communications Server creates a new msRTCSIP-Poolobject in the msRTCSIP-Poolscontainer. The msRTCSIP-Poolclass specifies the fully qualified domain name (FQDN) of the pool, along with the association between the front-end and back-end components of the pool. (A Standard Edition server is regarded as a logical pool whose front and back ends are collocated on a single computer.)

During Prep Forest, Office Communications Server creates containers for holding lists of trusted servers. During activation, Office Communications Server publishes the FQDN of every server to its appropriate container. A trusted server is one that meets the following criteria:

• The FQDN of the server occurs in one of the trusted server lists stored in Active Directory Domain Services, as described in the preceding section.
  
  
• The server presents a valid certificate from a trusted CA. The FQDN on this certificate matches the FQDN for that server in one of the trusted server lists. For details about how Office Communications Server uses certificates, see Public Key Infrastructure for Office Communications Server 2007 R2.
  
  

If either of these criteria is missing, the server is not trusted and connection with it is refused. This double requirement prevents a possible, if unlikely, attack in which a rogue server attempts to take over a valid server’s FQDN.

The use of multiple trusted server lists represents a departure from earlier versions of Live Communications Server, which maintained only a single trusted server list. Each server in the list is represented as a globally unique identifier (GUID) in the Global Settings container. With the addition of new server roles in Office Communications Server 2007 R2, new containers are defined to hold the GUIDs of different server roles. These new containers and their respective trusted server lists are shown in the following table.

Table 2. Trusted Server Lists and Their Active Directory Containers

Trusted server lists duplicate FQDN entries that are also found on individual Office Communications Server objects. The purpose of this redundancy is to prevent possible spoofing of trusted servers. This can conceivably occur because Active Directory Domain Services allows individual users to modify the attributes on the computer objects corresponding to their personal computers. Most organizations do not allow users to make such modification on their work computers, but trusted server lists add an additional layer of security by making such modifications available only to members of RTCUniversalServerAdmins.