If your organization uses Active Directory as its primary directory service, you certainly understand the value of Active Directory. It is worthwhile, however, to understand how the integration of Office Communications Server 2007 with Active Directory is beneficial to the organization and the IT administrator. This integration provides the following benefits:

Office Communications Server stores global settings—information that is needed by every server in the forest—in the system container of the root domain of the forest or in the configuration container. The choice is selected by the enterprise administrator during Forest Prep.

If the first option (system container) is chosen, Active Directory replicates information stored in the system container only among the domain controllers (DCs) and global catalogs (GCs) in the root domain. DCs and GCs in child domains will not have the Office Communications Server global settings replicated to them. Every Office Communications Server deployed in the forest must connect to a root domain GC to obtain this information. Because the best practice is to deploy servers running Office Communications Server in a child domain of the forest, servers will fail to activate if firewalls prevent them from accessing the root domain DCs and GCs—or if already activated, they will fail to start. Figure 3-1 shows this root domain GC dependency.

Figure 3-1. Global settings stored in system container—Root domain GC dependency

The problem just described does not exist if you select the second option—using the configuration container to store the global settings. Data defined in the configuration container is replicated across all GCs in the forest. This implies that servers running Office Communications Server can also contact GCs in their domain for the global settings. This is illustrated in Figure 3-2. If network connectivity between child domains and the root domain is slow, it is also recommended that you use the configuration container to store global settings.

Figure 3-2. Global settings stored in configuration container—Local domain GC dependency

Office Communications Server leverages Active Directory to publish service information. This means every Office Communications Server role is discoverable by querying Active Directory. A visible example of this feature is the automatic population of servers deployed in your Active Directory forest when you open the Office Communications Server Microsoft Management Console (MMC). Office Communications Server publishes this information in Active Directory during activation. This is why activation requires RTCUniversalServerAdmins or RTCUniversalGlobalWriteGroup privileges and membership in the Domain Admins group. The Administrator needs sufficient permissions to write to Active Directory during activation.

During activation, the Setup program creates a service principal name (SPN) and registers this SPN with the service account used to run the service. By default, this service account is a user account called RTCService. The SPN is registered in the servicePrincipalName attribute of this object and is of the form sip/<fqdn>, as shown in Figure 3-3. For a detailed understanding of how SPNs and service connection points (SCPs) work, see the Microsoft TechNet article at http://technet2.microsoft.com/WindowsServer/en/library/8127f5ed-4e05-4822-bfa9-402ceede47441033.mspx?mfr=true.

Figure 3-3. Service principal name

Activation publishes server information in three locations in Active Directory. Following Microsoft's best practices for Active Directory, Office Communications Server creates an SCP on the computer object belonging to the physical server where Office Communications Server is installed. By creating an SCP on the computer object, third-party asset management applications can query the types of services running on each machine. This SCP, called RTC Services, appears below the Microsoft node under the computer object. In the example shown in Figure 3-4 we use the MMC snap-in, adsiedit.msc, to view the SCP on the computer object called SRV. Of the most important SCP attributes (keywords, serviceDNSName, serviceDNSNameType, serviceClassName, and serviceBindingInformation), Office Communications Server 2007 populates only the keywords attribute with globally unique identifier (GUID) values to represent the service.

Figure 3-4. Active Directory global settings

Adsiedit.msc is available as a Web download from Microsoft as part of the Windows Support Tools. You must register the dynamic-link library (DLL), adsiedit.dll, first by running the following command from a command prompt window: regsvr32 adsiedit.dll.

When a Standard Edition Server is activated or when an Enterprise pool is created, Office Communications Server creates a new entry under the Pools container of class type msRTCSIP-Pools in Active Directory. Each entry represents a logical pool and is of class type msRTCSIP-Pool. The msRTCSIP-Pool class defines the fully qualified domain name (FQDN) of the pool, as well as the association between front-end servers and the back-end server to a pool.

You can think of a Standard Edition Server as a pool with a single front-end server collocated on the same physical computer as the back-end server. Every time a new Standard Edition Server is installed and activated, a new pool entry is created. This is not the case for front-end servers in an Enterprise pool. When a new front-end server is installed and activated, it is linked to an existing entry previously established when creating the initial Enterprise pool. The common name (CN) of each object created under the msRTCSIP-Pools container is defined by the name of the pool. Each new pool entry contains a subnode called Microsoft. Under the Microsoft subnode, the following subnodes exist: LC Services, LS WebComponents Services, and GUIDs, as shown in Figure 3-5.

Figure 3-5. Pool representation in Active Directory

The LC Services subnode lists all the front-end servers as distinguished names (DNs) associated with the pool in the multivalued attribute, msRTCSIP-FrontEndServers. The LS WebComponents Services subnode lists all the Web Components Servers as DNs associated with the pool in the multivalued attribute, msRTCSIP-WebComponentsService. Each unique combination of vendor and type set of Conferencing Servers are represented as a GUID subnode of the msRTCSIP-MCUFactoryService type. Each GUID multipoint control unit (MCU) factory links to an entry in the MCU Factories container through the msRTCSIP-MCUFactoryPath attribute. The MCU Factory entry lists all the Conferencing Servers of the particular vendor and type associated with the pool. The logical representation of the relationship between pools, MCU factories, and Conferencing Servers is illustrated in Figure 3-6.

Figure 3-6. Logical representation of Conferencing Servers associated with a pool

The third location where the server information is published in Active Directory is in the trusted server list. The FQDN of every Office Communications Server server role is published. In addition to using server certificates to verify the authenticity of a server that claims to own a specific FQDN, the trusted server list is used to determine whether the server can be trusted. Without an entry containing its FQDN, a server is not trusted by other server roles and therefore cannot establish any communication with these other servers. If you find that users homed on a particular pool are not able to communicate with users homed on other pools, this could be the reason. Check that the pool's FQDN is listed in the trusted server list in Active Directory.

It might seem odd that every server's FQDN is defined again in the trusted server list when it is already available on the computer object. After all, you could determine the set of computers running Office Communications Server by querying all computer objects with the RTC Services SCP. The primary reason that Office Communications Server does not use this approach is security. By default Active Directory allows computer owners to modify the attributes on the corresponding computer object. This permission privilege allows a rogue user to modify the computer object to appear as a server running Office Communications Server. Although this is not necessarily a concern in all organizations, administrators might lock down this privilege, reducing this threat dramatically. By using a trusted server list that only an administrator with RtcUniversalServerAdmin permission can modify, rogue users cannot spoof their computers to appear as trusted servers running Office Communications Server.

Performance of the Office Communications Server 2007 management console is a secondary benefit. In most organizations, the number of computers tends to be at least as large as, if not larger than, the number of users. Querying all the computers in the organization to determine which ones are running Office Communications Server would be time-consuming. Such a query would have a substantial impact on the administrator's experience when loading the Office Communications Server 2007 management console. Searching a smaller list makes it possible for the MMC to load faster.

In previous versions—Live Communications Server 2003, Live Communications Server 2005, and Live Communications Server 2005 SP1—the way the trusted server list is represented in Active Directory is located in the System container under Microsoft/RTC Service/Global Settings as an msRTCSIP-TrustedServer class entry. Each trusted server entry is represented as a GUID under the Global Settings container. The GUID is generated during the activation step. To determine which GUID object matches a particular Standard Edition server or Enterprise Edition front-end server, you must look at the properties of the object in ADSIEDIT.MSC. The attribute msRTCSIP-TrustedServerFQDN contains the FQDN of the server that you can then recognize.

With the number of new server roles introduced in Office Communications Server 2007, instead of storing all trusted servers under a single container (Global Settings), new containers were defined to separate trusted servers based on role. In Office Communications Server 2007, these trusted server entries are located in the System container under Microsoft/RTC Service or in the Configuration container under Services/RTC Service. The various trusted server roles are defined in the following containers (and highlighted in Figure 3-7):

Figure 3-7. Trusted server representation in Active Directory

Note that not all GUIDs under the Global Settings container represent GUIDs of trusted servers. As the name indicates, the Global Settings container contains settings that are global to Office Communications Server.

In addition to storing global settings in Active Directory and publishing Office Communications Server information, all Standard Edition Servers and Enterprise Edition pools create an msRTCSIP-Pools object under the RTC Service/Pools container, as shown in Figure 3-8.

Figure 3-8. Pool settings

Each pool entry is associated with an MCU factory. Every MCU factory is defined in the RTC Service/MCU Factories container, as shown in Figure 3-9. An MCU factory is created when the first instance of a unique media type (defined by the attribute msRTCSIP-MCUType) and vendor (defined by the attribute msRTCSIP-MCUVendor) of a Conferencing Server is activated.

Figure 3-9. MCU factories

The currently available media types are as follows:

Chapter 5 covers this area in more detail.

Office Communications Server 2007 defines Voice over Internet Protocol (VoIP) settings used to normalize phone numbers and translate phone numbers to SIP URI where applicable before routing the call to its destination. Figure 3-10 shows the classes used for VoIP. There is additional information on this topic in Chapter 10.

Figure 3-10. Global VoIP settings

The user class that represents a user account in Active Directory is also extended with attributes specific to Office Communications Server. Such attributes define settings that are configurable by an administrator member of the RTCDomainUserAdmins or RTCDomainServerAdmins group. Chapter 15 covers user settings in greater detail.

Before Office Communications Server can add this information to the Active Directory services, the Active Directory schema must be extended. This is the first step in preparing the Active Directory forest. Office Communications Server 2007 requires the following three steps to prepare an organization's Active Directory forest:

These steps are the same in both the Standard Edition and the Enterprise Edition SKUs. It does not matter whether you complete them with the Standard Edition or Enterprise Edition SKU. Setup automatically detects whether any required steps were not run, and it prevents the administrator from activating a Standard Edition Server or Enterprise Edition front-end server until these steps are completed successfully.

Performing the Prep Schema Step

To fully leverage Active Directory, Office Communications Server extends the schema with requirements specific to its needs—similarly to how Microsoft Exchange Server extends the schema. Office Communications Server 2007 extends the schema with 45 new classes and 106 new attributes. A root doman administrator who is a member of the Schema Administrators group must run this step once on a domain controller acting as the schema master in the root domain of the forest. This step is illustrated in Figure 3-11.

Figure 3-11. Prep schema step

All schema extensions start with a unique namespace that is specific to Office Communications Server. This namespace is called msRTCSIP-"name", where name is the name of a class or attribute. RTC, which stands for Real-time Communications, was the original name of the product group at Microsoft responsible for building Office Communications Server. SIP stands for Session Initiation Protocol (RFC 3261). Office Communications Server 2007 is based on this protocol standard. By using a common namespace for all schema extensions, schema administrators can clearly identify which extensions are specific to Office Communications Server and know not to reuse them for other purposes. Setup provides a convenient way to verify that the schema extension has replicated throughout the forest before moving on to the next step, Prep Forest.

Performing the Prep Forest Step

After you extend the forest's Active Directory schema, you must next perform the Prep Forest step, as shown in Figure 3-12. No objects are created in Active Directory with the Prep Schema step. The Prep Forest step must be run from the forest's root domain and is run only once. Until Prep Schema is completed successfully, the Setup program disables this step in the same way that Setup.exe grays out the Prep Schema step.

Figure 3-12. Prep Forest step

Running the Prep Forest step creates an instance of the msRTCSIP-Service class, called RTC Service. This container is the root where all global settings used by Office Communications Server are stored. Under this container are the following additional containers:

• Global Settings This container contains a set of attributes, plus the following three subcontainers.

  • GUID of class type msRTCSIP-Domain. This object defines the default SIP domain name for which this Active Directory forest is authoritative. By default, the SIP domain name is set to the forest's root domain FQDN. Each SIP domain supported in your organization is represented by a different GUID of this class type. This setting is exposed on the General tab of the Forest properties, as shown here:

    

  • GUID of class type msRTCSIP-TrustedServer. Each GUID represents a Standard Edition Server or an Enterprise pool front-end server that is trusted. This list of trusted servers is displayed in the tree view pane of the Admin Tools.

  • GUID of class type msRTCSIP-EdgeProxy. Each GUID represents the internal FQDN of an Edge Server deployed in your organization's network perimeter and trusted by your Office Communications Server infrastructure, as shown here:

    

• Policies This container lists all global policies defined by the administrator. Users assigned by the administrator to a policy are subject to the restrictions defined in the policy. Office Communications Server 2007 exposes two types of policies: a Meeting type policy and a UC type policy. Each policy type contains a different set of configurable settings.

• Location Normalization Rules This container stores the set of rules defined by the administrator for how Office Communication Server clients should normalize phone numbers input by users to conform to the E.164 format. Each rule is composed of a pair of regular expressions (regex): the first regular expression is the match, and the second regular expression is the transform. This topic is covered in more detail in Chapter 10.

• Location Profiles This container lists all the locations defined by the administrator. Each location is associated with a set of normalization rules that represent the dialing habits that users for that region are accustomed to. This topic is covered in more detail in Chapter 10.

• Phone Route Usages This container stores all usages defined by the administrator. A usage is an arbitrary string that describes a set of routes. A phone route usage is associated with one or more phone routes. This topic is covered in more detail in Chapter 10.

• Phone Routes This container contains all the phone routes as defined by the administrator. A phone route is a rule that defines which Mediation Servers should be routed to by phone calls that match a specific number pattern. This topic is covered in more detail in Chapter 10.

  Note

  All the aforementioned settings are directly exposed in the Office Communications Server's Admin Tools. To access them, launch the Office Communications Server 2007 link from the Administrative Tools folder. Right-click the Forest node, select Properties, and then select either Global Properties or Voice Properties.

• Pools This container stores all Standard Edition Servers and Enterprise pools.

• MCU Factories This container stores all instances of MCU factories. An MCU factory is created when the first instance of a specific vendor and type of MCU (such as Conferencing Server) is activated. An MCU factory manages the set of MCUs of a specific type that belongs to a Standard Edition Server or Enterprise pool.

  • The MCU factory is associated with one, and only one, Standard Edition Server or Enterprise pool.

• Trusted MCUs This container lists all trusted instances of Conferencing Server. Office Communications Server 2007 creates an entry in this list when a Conferencing Server is activated. Office Communications Server blocks any communications with a Conferencing Server that are not listed in this container. It does this to prevent spoofing attacks (such as another server posing as a Conferencing Server). Office Communications Server validates that the FQDN listed in the Subject Name or Subject Alternate Name field of the certificate presented by Conferencing Server is listed in this container. If the FQDN of the Conferencing Server is not present in this list, the server is not trusted.

• Trusted Proxies Similar to the Trusted MCUs container, this container lists all trusted instances of Proxy Server. Instead of storing all server roles in the same container, Office Communications Server 2007 creates separate containers for each server role.

• Trusted Services This container is meant to list trusted SIP servers, including third-party SIP servers, Communicator Web Access servers, and Mediation Server servers.

• Trusted Web Components Servers This container lists all the trusted servers of the server role type Web Components.

After creating the global objects, Prep Forest creates the universal security groups that administrators need to be members of, Administrator servers, and users of Office Communications Server. These universal security groups are created in the Users organizational unit (OU) and can be found using the Active Directory Users and Computers console. They are summarized in Table 3-1.

Table 3-1. Universal Groups Created by Office Communications Server

Universal Group	Description
RTCUniversalUserAdmins	Members of this universal security group can manage users within the Active Directory forest who are enabled for Office Communications Server. Prep Domain grants this group read/write permissions to RTCPropertySet.
RTCUniversalReadOnlyAdmins	Members of this universal security group have read-only access to server and user settings in Active Directory.
RTCUniversalServerAdmins	Members of this universal security group can manage all aspects of Office Communications Server within the forest, including all server roles and users.
RTCUniversalGlobalReadOnlyGroup	Members of this universal security group have read-only access to Office Communications Server global settings in Active Directory.
RTCUniversalGlobalWriteGroup	Members of this universal security group have write access to Office Communications Server global settings in Active Directory.
RTCUniversalUserReadOnlyGroup	Members of this universal security group have read-only access to Office Communications Server global settings in Active Directory.
RTCUniversalGuestAccessGroup	Members of this universal security group have read-only access to certain Office Communications Server settings in Active Directory.
RTCUniversalServerReadOnlyGroup	Members of this universal security group can read server-related settings in Active Directory.
RTCHSUniversalServices	Members of this universal security group are service accounts used to run the Office Communications Server 2007 Standard Edition servers and Enterprise Edition front-end servers. This group allows servers read/write access to Office Communications Server global settings, as well as to user objects in Active Directory. This group has full access to RTCPropertySet. The name of this group might seem a bit cryptic. The "HS" in the name of the group refers to Home Server, which represents a Standard Edition server or an Enterprise pool.
RTCArchivingUniversalServices	Members of this universal security group are service accounts used to run the Office Communications Server 2007 Archiving and CDR Servers. This group provides permission to access the service's database.
RTCProxyUniversalServices	Members of this universal security group are service accounts used to run the Office Communications Server 2007 Proxy Server.
RTCComponentsUniversalServices	Members of this universal security group are service accounts used to run the Office Communications Server 2007 Conferencing Server, Web Components Server, and Mediation Server.

Direct from the Source: Infrastructure Groups

The infrastructure groups that are used by Office Communications Server 2007 to build the other groups are as follows:

• RTCUniversalGlobalWriteGroup

• RTCUniversalUserReadOnlyGroup

• RTCUniversalGuestAccessGroup

Administrators should not modify permissions on these groups or add members directly to them.

—Nirav Kamdar

Senior Development Lead, Office Communications Server

Prep Forest defines two new property sets. With a property set, you can group a number of attributes into a set. You can apply security permissions to the property set, instead of to each individual attribute, through a single access control entry (ACE). These property sets are called RTCPropertySet and RTCUserSearchPropertySet and are of class type controlAccessRight. They are defined under the Extended-Rights object in the Configuration container, as shown in Figure 3-13.

Figure 3-13. Office Communications Server property sets

The property set RTCPropertySet contains all the user attributes extended by Office Communications Server. To configure users for Office Communications Server, administrators must have read/write privileges to this property set. The RTCUniversalServerAdmins security group is given read permissions to this property set, so administrators of this group can view user configuration details but cannot configure users. The RTCUniversalUserAdmins security group is given read/write permissions to the property set, so administrators of this group are able to configure users for Office Communications Server. The RTCHSUniversalServices security group is given read/write permissions to this property set.

The RTCPropertySet property set is composed of the following attributes:

• msRTCSIP-PrimaryUserAddress

• msRTCSIP-PrimaryHomeServer

• msRTCSIP-TargetHomeServer

• msRTCSIP-OptionFlags

• msRTCSIP-UserEnabled

• msRTCSIP-ArchivingEnabled

• msRTCSIP-FederationEnabled

• msRTCSIP-InternetAccessEnabled

• msRTCSIP-OriginatorSid

• msRTCSIP-Line

• msRTCSIP-LineServer

• msRTCSIP-UserExtension

The property set RTCUserSearchPropertySet is used to determine whether a user is authorized to search other users in the organization by using the Find functionality available in Microsoft Office Communicator 2007. By default, domain users are allowed to search each other without restriction, and only the RTCDomainUsersAdmins group has full permissions on this property set.

RTCUserSearchPropertySet is composed of a single attribute: msRTCSIP-PrimaryUserAddress.

Performing the Prep Domain Step

After Prep Forest is successfully completed, the Prep Domain step becomes available in the Setup program, as shown in Figure 3-14. Unlike Prep Schema and Prep Forest, Prep Domain remains available to run again in another child domain where Prep Domain has not been run yet.

Figure 3-14. Prep Domain step

The general rule for knowing when to run Prep Domain is simple. This step must be run in every Active Directory domain where Office Communications Server will be deployed and in Active Directory domains where users will be hosted on Office Communications Server. It needs to be run only once per domain. If no servers running Office Communications Server will be deployed in the domain, running this step is not necessary. Domain Administrator privileges are required to run Prep Domain.

Prep Domain adds permissions for the universal security groups created in the Prep Forest step to manage its domain users.