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 R2 with Active Directory is beneficial to the organization and the IT administrator. This integration provides the following benefits:
Global information that will be shared by all servers running Office Communications Server can be stored in Active Directory instead of replicating the information across servers.
Server information can be published in Active Directory for easy discovery and asset management. This makes it possible to remotely manage servers running Office Communications Server from any computer joined to the Active Directory forest by using the administrator’s tools that are installed as part of Office Communications Server.
Users can sign in to Office Communications Server by using their Windows credentials, which provides a single sign-on experience. With single sign-on, users do not have to manage separate credentials.
One thing that has changed in Office Communications Server 2007 R2 is the location of global settings. Global settings provide information that every server in the forest needs. The default location for the settings is now the Configuration container instead of the System container of the forest’s root domain.
If you decide to have the global settings in the System container, Active Directory replicates information stored in the System container among only the domain controllers and global catalog servers in the root domain. Domain controllers and global catalog servers 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 global catalog 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 domain controllers and global catalogs in the root domain. Or if already activated, they will fail to start. Figure 4-1 shows this root domain global catalog dependency.
Figure 4-1. Global settings stored in the System container and the dependency on the root domain global catalog
The problem just described does not exist if you select the default option to use the Configuration container to store the global settings. Data defined in the Configuration container is replicated across all global catalogs in the forest. This implies that servers running Office Communications Server can also contact global catalogs in their domain for the global settings, as shown in Figure 4-2.
Figure 4-2. Global settings stored in the Configuration container allows contact with the global catalog in the local domain
Before Office Communications Server can add server- and service-specific settings to Active Directory, the Active Directory schema must be extended. This is the first step in preparing the Active Directory forest. Office Communications Server 2007 R2 requires the following three steps to prepare an organization’s Active Directory forest.
Prep Schema. This step extends the Active Directory schema with new classes and attributes specific to Office Communications Server 2007 R2.
Prep Forest. This step creates the global settings in the System container in the root domain or the forest’s Configuration container, which are used by all Office Communications Servers. Universal groups are also created during this step.
Prep current domain. This step must be run in every Active Directory domain where Office Communications Server 2007 R2 servers will be deployed or where users will be enabled for Office Communications. This step creates domain-level global security groups in the domain where it is carried out. These groups are used to manage Office Communications Servers deployed in the domain. Domain Prep gives permissions to the Universal groups created during Forest Prep to properties on user objects in the domain.
These steps are the same in the Standard Edition and the Enterprise Edition of Office Communications Server. It does not matter whether you complete them with the Standard Edition or Enterprise Edition. 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.
To take full advantage of Active Directory, Office Communications Server extends the schema with requirements specific to its needs. This is similar to how Exchange Server extends the schema. Office Communications Server 2007 R2 extends the schema with 45 new classes and 106 new attributes. A root domain 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 4-3.
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 stands for Real-Time Communications, and SIP stands for Session Initiation Protocol (Request for Comment [RFC] 3261). Office Communications Server 2007 R2 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.
After you extend the forest’s Active Directory schema, you must perform the Prep Forest step, as shown in Figure 4-4. No objects are created in Active Directory during the Prep Schema step. The Prep Forest step must be run from the forest’s root domain and is run only once. The Prep Forest step is unavailable until Prep Schema is completed successfully.
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 Office Communications Server uses 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-TrustedServer 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 fully qualified domain name (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 Office Communications Server Global Properties, as shown in Figure 4-5.
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 in Figure 4-6.
Policies. This container lists all global policies defined by the administrator. Users the administrator has assigned to a policy are subject to the restrictions defined in the policy. Office Communications Server 2007 R2 exposes two types of policies: a Meeting type policy and a Unified Communications (UC) type policy. Each policy type contains a different set of configurable settings.
Location Normalization Rules. This container stores the set of rules the administrator has defined for how Office Communications 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. For more information about normalization rules, see Chapter 11.
Location Profiles. This container lists all the locations the administrator has defined. Each location is associated with a set of normalization rules that represent the dialing habits users for that region are accustomed to. For more information about normalization rules, see Chapter 11.
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. For more information about phone route usage, see Chapter 11.
Phone Routes. This container contains all the phone routes 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. For more information about phone routes, see Chapter 11.
Note
All the aforementioned settings are available in Office Communications Server Admin Tools. To access them, open the Office Communications Server 2007 R2 link from the Administrative Tools folder. Right-click the forest node, select Properties, and then select Global Properties or Voice Properties.
Application Contacts. This container contains special-use contact objects called application contacts. The msRTCSIP-SourceObjectType attribute specifies the purpose or type of the contact object. Server applications such as an Enterprise Voice application (see Chapter 13) use these objects for routing. These types of server applications need to be addressable through SIP with a SIP Uniform Resource Identifier (URI) or a phone number, similar to a user. However, a user account would not be appropriate to assign to an application. Because a user cannot log in using a contact object, these objects are recommended for use by applications for security purposes. To uniquely represent these contact objects, their common name (CN) is a GUID. The attribute, msRTCSIP-ApplicationDestination, on the contact object specifies the server application this Application Contact points to. Chapter 13 provides more details on the use of these contact objects.
Location Contact Mappings. This container contains objects of type msRTCSIPLocationContactMapping. These objects serve the purpose of associating an application contact to more than one location profile. In particular, the Enterprise Voice application Conference Auto-Attendant uses this facility.
Pools. This container stores all Standard Edition Servers and Enterprise pools.
Conference Directories. This container stores all instances of Conference Directory. A conference directory links all Public Switched Telephone Network (PSTN) dial-in conferences created on a specific pool to that specific pool. When users create a conference for PSTN dial-in, the meeting ID issued for the PSTN dial-in is based off of the conference directory. This makes it easy to move existing and recurring conferences to a different pool. A conference directory provides a level of indirection to make it possible to move conferences from one pool to another.
MCU Factories. This container stores all instances of an MCU Factory. An MCU Factory is created when the first instance of a specific vendor and type of multipoint control unit (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 the Conferencing Server. Office Communications Server 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 that is presented by the 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 the proxy server. Instead of storing all server roles in the same container, Office Communications Server 2007 R2 creates separate containers for each server role.
Trusted Services. This container is meant to list trusted SIP servers, including third-party SIP servers, Microsoft Office Communicator Web Access Servers, and Mediation Servers.
Trusted Web Components Servers. This container lists all the trusted servers that have the Web Components Server role installed.
On the Companion Media
A complete list of all classes and attributes that are created can be found in the "Office Communications Server 2007 R2 Active Directory Classes and Attributes" document on the companion media in the Chapter 4 folder.
After creating the global objects, Prep Forest creates universal security groups. For administrators to manage the Office Communications Server infrastructure systems, they will have to be made members of the appropriate universal groups. These universal security groups are created in the Users organizational unit (OU) and can be found by using the Active Directory Users and Computers console. They are summarized in Table 4-1.
Table 4-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. |
Members of this universal security group are service accounts used to run the Office Communications Server 2007 R2 Standard Edition Servers and Enterprise Edition front-end servers. This group enables servers to have 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 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 R2 Archiving 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 R2 proxy server. |
RTCComponentsUniversalServices | Members of this universal security group are service accounts used to run the Office Communications Server 2007 R2 Conferencing Server, Web Components Server, and Mediation 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 controlAccess-Right. They are defined under the Extended-Rights object in the Configuration container, as shown in Figure 4-7.
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-UserPolicy
msRTCSIP-UserEnabled
msRTCSIP-ArchivingEnabled
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-OriginatorSid
msRTCSIP-Line
msRTCSIP-LineServer
msRTCSIP-SourceObjectType
msDS-SourceObjectDN
msRTCSIP-ApplicationDestination
msRTCSIP-ApplicationOptions
msRTCSIP-UserLocationProfile
msRTCSIP-ApplicationPrimaryLanguage
msRTCSIP-ApplicationSecondaryLanguages
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 Office Communicator 2007 R2. 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-PrimaryUser-Address.
After Prep Forest is successfully completed, the Prep Domain step becomes available in the Setup program, as shown in Figure 4-8. 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.
The general rule for knowing when to run Prep Domain is simple. This step must be run in every Active Directory domain in which Office Communications Server 2007 R2 will be deployed and in Active Directory domains in which users will be hosted on Office Communications Servers. 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.
Office Communications Server takes advantage of 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 RTCUniversal-ServerAdmins 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 4-9. For more information about how SPNs and service connection points (SCPs) work, see the related Microsoft TechNet article at http://go.microsoft.com/fwlink/?LinkID=133666.
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 that belongs 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 computer. This SCP related to Office Communications Server services installed by the administrator appears below the Microsoft node under the computer object. In the example shown in Figure 4-10, adsiedit.msc is used to view the SCPs on the computer object, OCS-FE. Eight services are installed:
LS ACP MCU. This service corresponds to the Telephony Conferencing Server.
LS AS MCU. This service corresponds to the Application Sharing Conferencing Server.
LS AV MCU. This service corresponds to the Audio/Video (A/V) Conferencing Server.
LS Data MCU. This service corresponds to the Web Conferencing Server.
LS IM MCU. This service corresponds to the IM Conferencing Server.
LS WebComponents Service. This service is a Web application running on IIS.
RTC Services. This service is the SIP server.
UC AppServer Services. This service hosts server applications such as Response Group Service and Conference Announcement Service, as well as third-party server applications.
Adsiedit.msc is a standard tool in Windows Server 2008 and is installed on any server on which you install the Active Directory Domain Services role. However, if you are using Windows Server 2003 x64, it 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 at a command prompt:
regsvr32 adsiedit.dll
It also is installed as one of the support tools that is on the Windows Server 2003 x64 media in the SUPPORT directory.
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 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 that was previously established when the initial Enterprise pool was created. The 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 Web-Components Services, UC AppServer services, and four GUIDs representing an MCU Factory service for each type of media (Telephony, IM, Web Conferencing, A/V, and Application Sharing), as shown in Figure 4-11. The GUID in the CN of the MCU Factory service matches the CN of an MCU Factory listed under the MCU Factories container. Looking at the properties of the corresponding MCU Factory object will indicate which type of Conferencing Server it is.
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 that are associated with the pool in the multivalued attribute msRTCSIP-WebComponentsSer-vice. Each unique combination of vendor and type for the set of Conferencing Servers are represented as a GUID subnode of the msRTCSIP-MCUFactoryService type. Each GUID MCU Factory links to an entry in the MCU Factories container through the msRTCSIPMCUFactoryPath 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 4-12.
The third location in which the server information is published in Active Directory is the Trusted Server list. The FQDN of every Office Communications Server 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 in a particular pool are not able to communicate with users in 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 that have the RTC Services SCP. The primary reason that Office Communications Server does not use this approach is security. By default, Active Directory enables computer owners to modify the attributes on the corresponding computer objects. This permission privilege enables a malicious 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, malicious users cannot spoof their computers to appear as trusted servers running Office Communications Server.
Performance of the Office Communications Server 2007 R2 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 R2 management console. Searching a smaller list makes it possible for the MMC to load faster.
In earlier versions of Live Communications Server, the Trusted Server list is represented in Active Directory 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 R2, instead of storing all trusted servers under a single container (Global Settings), new containers are defined to separate trusted servers based on role. In Office Communications Server 2007 R2, 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 4-13):
Trusted Standard Edition Server and Enterprise pool front-end server entries are located in the RTC Service/Global Settings container. This location is the same as in Live Communications Server 2003 and 2005.
Trusted Conferencing Server entries are located in the RTC Service/Trusted MCUs container.
Trusted Web Components Server entries are located in the RTC Service/Trusted-WebComponentsServers container.
Trusted Communicator Web Access Server, Mediation Server, and Enterprise Voice Application (Response Group Service, Conferencing Announcement Service, Conferencing Attendant, and so on) entries are located in the RTC Service/Trusted Services container. Third-party SIP servers should create a trusted server entry in this container as well; otherwise, Office Communications Servers will not trust their servers and any mutual transport layer security (MTLS) connections will be refused.
Trusted proxy server entries are located in the RTC Service/Trusted Proxies container.
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 4-14.
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 4-15. 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.
The currently available media types are as follows:
Meeting
Instant messaging (IM)
Phone-conference
Audio/video
Note
For more information about media types, see Chapter 6.
Office Communications Server 2007 R2 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 4-16 shows the classes used for VoIP. For more information about VoIP, see Chapter 11.
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. For more information about user settings, see Chapter 18.