Microsoft Office Communications Server 2007 R2 has a simple administration model. After you complete your deployment by using the Setup program, which provides wizards to facilitate the configuration of your servers, ongoing administration of those servers is performed using the Admin Tools Microsoft Management Console (MMC) snap-in called Office Communications Server 2007 R2. This management console automatically discovers all the Office Communications Servers in the deployment by querying Active Directory.
Office Communications Server also provides a Windows Management Instrumentation (WMI) interface that abstracts the underlying provider whether it is Active Directory, Microsoft Server, or the WMI repository. This WMI interface simplifies the effort to write management tools and scripts. The Admin Tools MMC uses this WMI interface. A graphical representation of this logical structure is shown in Figure 18-1.
Note
Not all WMI settings are exposed via the Admin Tools MMC. The design philosophy of the Admin Tools MMC is to expose approximately 80 percent of the configurable settings that administrators will most commonly use. For more advanced configuration scenarios or less commonly used settings not exposed in the Admin Tools MMC, administrators must use the WMI interface.
The design philosophy behind the Office Communications Server management infrastructure is to store in Active Directory any information that needs to be available to all servers deployed in the forest, such as global settings and user information. Settings that must be available within the scope of a pool (that is, all servers associated with a pool) are stored in SQL. Server settings (that is, information specific to a server) are stored in the local server’s WMI repository. The WMI interface exposes all these settings in an object model representation that provides semantic validation to prevent administrators or developers from creating an invalid state that the system cannot recover from. Office Communications Server exposes more than 100 different WMI classes, and the organizational structure of these WMI classes is described in the following sections.
Office Communications Server leverages Active Directory to store settings that are used by all Office Communications Servers deployed within a forest. Office Communications Server provides two options for storing global settings:
Global settings can be stored in the Active Directory Configuration Partition. (This option can be used for new installations only.)
Global settings can be stored in the Active Directory System Container in the root domain partition. (You must use this option if you are already running Office Communications Server 2007 or Microsoft Office Communications Server 2005 SP1.)
When using the System Container to store global settings, Office Communications Servers connect to root domain Domain Controllers (DCs) to retrieve this data. When using the Configuration container, Office Communications Servers connect to servers DCs in their local domain to obtain global settings.
For distributed topologies, the recommended default is to use Configuration Partition for storing global settings. Note that if Office Communications Server 2007 or Office Live Communications Server 2005 SP1 is already installed in a forest, Office Communications Server 2007 R2 will not permit you to change the global settings’ location from System Container to the Configuration Partition or vice versa. However, Office Communications Server 2007 provides a tool that does a one-time migration of global settings from System Container to Configuration Partition. This tool must be run before the Office Communications Server 2007 R2 schema has been extended in the forest. This tool can be found at http://go.microsoft.com/fwlink/?LinkID=133735.
The servers retrieve its global configuration data via WMI. This data is not to be confused with user data, which is retrieved via the user replicator (UR) process. These global settings are created during the Forest Prep step in Setup.
Global Office Communications Server settings are configurable from the Admin Tools MMC by right-clicking the forest node and selecting Properties. Three settings are available: Global Properties, Voice Properties, and Conference Auto Attendant Properties, as shown in Figure 18-2. Voice properties are global settings that are applicable only to Enterprise Voice scenarios. Similarly, the Conference Auto Attendants properties are applicable only for PSTN dial-in scenarios.
Office Communications Server 2007 R2 exposes these global settings via WMI. Administrators should access these settings from the WMI interface instead of directly modifying them in Active Directory via the Active Directory Services Interface (ADSI) or Lightweight Directory Access Protocol (LDAP). The WMI interface builds in a safety measure to prevent setting values that are invalid.
The following is a list of the most commonly used WMI classes for global settings configuration. Note that this is not a complete list. The complete list can be found at the Microsoft Developer Network (MSDN) website: http://msdn.microsoft.com.
MSFT_SIPDomainData. This WMI class defines the Session Initiation Protocol (SIP) domains authoritative for the Office Communications Servers deployed within the forest. In our example environment, Litwareinc.com is the SIP domain. Messages to users with SIP Uniform Resource Identifiers (URIs) of username@litwareinc.com, will be routed internally to the user’s home pool. If a message is addressed to a user with a SIP URI of username@fabrikam.com, for example, the request will be routed outside the organization’s network through the federated connection as defined by the administrator on the Federation tab. The Admin Tools MMC exposes the settings from this class on the General tab of Office Communications Server Global Properties. One (and only one) of the SIP domains must be marked as the default routing domain. The default domain is used in constructing Globally Routable User Agent URIs (GRUUs) for each Office Communications Server in the deployment. Figure 18-3 shows how to configure SIP domains using the Admin Tools MMC.
MSFT_SIPESGlobalSearchSetting. As the class name indicates, all global search settings are configurable through this WMI class. This class is exposed in the Admin Tools MMC on the Search tab of the Global Properties page.
MSFT_SIPESGlobalRegistrarSetting. This WMI class defines the restrictions for searching the registrar (database) to maintain system performance. Part of the class’s configuration settings are exposed on the User tab of the Global Properties page.
MSFT_SIPGlobalFederationSetting. This WMI class exposes the global federation settings. This global configuration setting enables the administrator to centrally disable federation without going to every server to block federation traffic in the case of a virus or worm outburst. Also, this class enables the administrator to configure an outbound route for federation without having to configure this same setting on all Office Communications Servers. Typically, this setting is set to the Director pool so that all other pools funnel their outside traffic via the Director. The Admin Tools MMC displays these settings on the Federation tab of the Global Properties page, as shown in Figure 18-4.
MSFT_SIPGlobalArchivingSetting. This WMI class exposes the global Archiving settings, and it is enforced by every Office Communications Server Standard Edition server and Enterprise Edition pool front-end server deployed in the forest that is configured to archive user communications. Settings from this class are available from the Admin Tools MMC on the Archiving tab of the Global Properties dialog box.
MSFT_SIPGlobalCDRSetting. This WMI class exposes settings to configure Call Detail Records (CDRs). These settings can be found in the Admin Tools MMC on the Call Detail Records tab of the Global Properties dialog box.
MSFT_SIPEdgeProxySetting. This WMI class defines the list of trusted Edge Servers. This list includes the Web Edge Servers and Access Edge Servers. (Note that the Audio/Video (A/V) Edge Servers can be found in the MSFT_SIPTrustedMRASSetting class described in the section titled "Configuring Trusted Server Settings" later in this chapter.) This list serves as an added measure of security. Internal Office Communications Servers establish mutual transport layer security (MTLS) connections with Edge Servers in the organization’s perimeter network only if they are registered in this class. The Admin Tools MMC exposes this list of trusted Edge Servers on the Edge Servers tab of the Global Properties page, as shown in Figure 18-5.
When a user enabled for Enterprise Voice places a call by dialing a phone number, Office Communications Server needs to know how to route the call to the correct destination. The administrator must configure this routing logic, configure who is allowed to use this route, and define the different phone number patterns that can be interpreted to use this route. (For more information about how phone routes are defined, see Chapter 11.)
Configuration of Voice over Internet Protocol (VoIP) settings is exposed by the WMI classes listed next. These settings are also exposed in the Admin Tools MMC in the Voice Properties section located under the forest node.
MSFT_SIPPhoneRouteUsageData. This WMI class defines a list of usage names that the administrator creates. A usage name is a friendly name that is associated with a phone route to indicate its intent or usage. For example, a Litware, Inc. administrator might create the following usages in his organization: local, domestic long distance, and international long distance.
MSFT_SIPPhoneRouteData. This WMI class defines a phone route. A phone route is composed of a phone pattern that is associated with one or more Mediation Servers (and therefore a media gateway). If a dialed phone number matches the pattern, the route specifies the call to be routed to the associated Mediation Servers.
MSFT_SIPLocalNormalizationRuleData. This WMI class defines a list of 2-tuples. A 2-tuple, or pair, is composed of a matching regular expression and a transform regular expression. When a user dials a phone number, the number is checked against all the matching regular expressions that are associated with the location profile assigned to the user. If a match is found, the regular expression transforms the phone number. This process is called normalization of the phone number because a phone number can be interpreted in different ways depending on the context (such as country, state, county, and city). These are called local normalization rules. The normalized phone number is then used to match a phone pattern to a phone route, and then it’s routed to the correct Mediation Server.
MSFT_SIPLocationProfileData. This WMI class defines location profiles. A location profile is simply a name that describes a collection of normalization rules to translate a phone number into E.164 format. Location profiles can be assigned to users or pools. If a user object doesn’t have a location profile directly assigned to it, it will use the location profile assigned to the pool that it belongs to.
To ease the administrative burden, instead of requiring administrators to configure each user individually, Office Communications Server exposes the concept of policies. A policy is simply a collection of user-specific settings abstracted by the name of the policy. Once the administrator configures the values of the settings to her needs, she can assign users to this policy. If the administrator later modifies settings in the policy, these updates are automatically enforced on all users assigned to this policy without needing to configure each user individually.
Every policy type must have one instance defined as the default instance. Office Communications Server will not permit the deletion of this instance. Policies are stored in Active Directory in XML format. Policies can be assigned to users in one of two ways:
Any one policy instance can be applied to all users in the organization at the global level. In this case, if the policy instance that is globally assigned to all users is subsequently deleted, all users will automatically be assigned the default policy instance.
Any policy instance can be assigned to individual users. To do this, the administrator specifies at the global level that policy assignment will be done on a per-user basis. In this case, if the user is not assigned a policy or if the user is assigned a policy that is subsequently deleted, Office Communications Server will automatically assign the default policy instance to that user object.
Office Communications Server has three types of policies:
Meeting policy. The WMI class MSFT_SIPGlobalMeetingPolicyData enables the administrator to create new Meeting policy instances as well as list, modify, or delete existing instances. The MSFT_SIPGlobalMeetingSetting WMI class defines the default global Meeting policy. This class lets the administrator assign one instance of the Meeting policy to all users in the organization or specify that each user will individually be assigned a Meeting policy. The Meetings tab of the Global Properties dialog box is shown in Figure 18-6.
Enterprise Voice policy. Similar to the Meeting policy classes, the MSFT_SIPGlobal-UCPolicyData WMI class lets the administrator manipulate instances of the Enterprise Voice policy, and the MSFT_SIPGlobalUCSetting WMI class lets the administrator assign one instance of the Voice policy to the entire organization. This class is also available in the Admin Tools MMC. The Policy tab of the Voice Properties dialog box is shown in Figure 18-7.
Presence policy. The Presence policy has a class called MSFT_SIPGlobalPresence-PolicyData that lets the administrator manipulate instances of the Mobility policy and a class called MSFT_SIPGlobalPresenceSetting that lets the administrator assign one instance of the Presence policy to the entire organization. This class is not available in the Admin Tools MMC.
When installed, each Office Communications Server (with the exception of Edge Server roles) creates a service connection point (SCP) on the corresponding computer object in Active Directory. The SCP marker registers in Active Directory the type of service installed on the computer joined to the Active Directory forest. This makes it possible for administrators and monitoring services (e.g., SMS, HP OpenView, IBM Tivoli) to determine what types of services are running on every computer. When the Office Communications Server is uninstalled, the SCP is removed from the corresponding computer object in Active Directory. This is part of Microsoft’s best practice standards for Active Directory.
The following WMI classes are used for configuring SCP settings:
MSFT_SIPESServerSetting. This WMI class defines the SCP for Office Communications Server 2007 R2 Standard Edition Servers and Enterprise Edition pool front-end servers. The ES in the name of the class stands for Enterprise Services.
MSFT_SIPMCUSetting. This WMI class defines the SCP for Conferencing Servers.
MSFT_SIPWebComponentsServerSetting. This WMI class defines the SCP for Web Components Servers.
MSFT_SIPMediationServerSetting. This WMI class defines the SCP for Mediation Servers.
MSFT_SIPArchivingServerSetting. This WMI class defines the SCP for Archiving Servers.
MSFT_SIPMonitoringServerSetting. This WMI class defines the SCP for Monitoring Servers.
MSFT_SIPApplicationServerSetting. This WMI class defines the SCP for Application Host service. The Applications property of this class contains a list of all applications hosted on this instance of Application Host. The following applications ship with the Office Communications Server 2007 R2:
Conference Auto Attendant
Conference Announcement Service
Response Group Service
Call Control Service
To avoid the scenario of a rogue server inside the organization posing as a legitimate Office Communications Server and therefore gaining access to other users’ data, Office Communications Server uses a trusted server list. This list prevents rogue servers from spoofing as Office Communications Servers. If a server’s fully qualified domain name (FQDN) is not on the trusted server list, none of the Office Communications Servers will accept MTLS connections from it.
All internal Office Communications Servers create an entry in the appropriate trusted server list during activation. This is one of the reasons administrators must be members of the RTCUniversalServerAdmins group to run activation. Rogue users with insufficient permissions are not able to add their server’s FQDN to this trusted server list.
Most trusted server entries contain an FQDN, port, type, and version. The FQDN, port pair uniquely identifies a service installed on the machine. If a port is not present, it is assumed to be 5061. The type is used only on classes that contain entries from multiple trusted server sources. For example, the type on the MSFT_SIPTrustedMCUSetting class tells which type of multipoint control unit (MCU) is installed on the <FQDN:port> specified in the entry. The version represents the version of the SIP protocol that this server talks.
The following WMI classes are used for configuring trusted server settings.
MSFT_SIPESTrustedServerSetting. This WMI class defines the list of Office Communications Servers to be trusted. This list contains FQDNs for each Standard Edition Server, Enterprise Edition Server, and Enterprise Edition pool. This is a read-only class. Instances are written to this class during activation and, after that, they can be read via WMI. Office Communications Server doesn’t support modifying these instances after the initial activation step.
MSFT_SIPTrustedMCUSetting. This WMI class lists all the Microsoft trusted conferencing servers (Web Conferencing Server, Instant Messaging (IM) Conferencing Server, A/V Conferencing Server, Application Sharing Server, and Telephony Conferencing Server). This is a read-only class.
MSFT_SIPTrustedWebComponentsServerSetting. This WMI class defines the list of trusted Web Components Servers. This is a read-only class.
MSFT_SIPEdgeProxySetting. This WMI class defines a list of trusted Edge Servers. This is a writable class. Instances of this class can be written to from the Edge Server tab of the Global Properties page.
MSFT_SIPForwardingProxySetting. This WMI class defines a list of all trusted forwarding proxy servers. This is a read-only class.
MSFT_SIPTrustedServiceSetting. This WMI class defines the list of services that other Office Communications Servers trust. The following servers and services are represented in this class:
Communicator Web Access Servers
Mediation Servers
A/V Edge Servers, referred to internally as Media Relay Access Servers (MRASs)
Monitoring Servers
All services hosted by Application Host: Conference Auto Attendant, Conference Announcement Service, Response Group Service, and Call Control Service
This is a read-only class. However, certain service types represented in this class are writable. Office Communications Server provides two other classes (described in next chapter), which are writable views of this class.
MSFT_SIPTrustedAddInServiceSetting. Third-party independent software vendors (ISVs) can create SIP servers that Office Communications Server trusts by creating an entry in this trusted service list. In reality, this class is a view on top of the MSFT_SIPTrustedServiceSetting class. That is, internal instances of this class are stored at the same location as instances of MSFT_SIPTrustedServiceSetting. Office Communications Server doesn’t provide a generic user interface (UI) for writing instances of this class. However, instances can be written to by accessing WMI directly.
MSFT_SIPTrustedMRASServer. This WMI class lists all trusted A/V Edge Servers. This is also a writable view on top of the MSFT_SIPTrustedServiceSetting class. Instances of this class can be written to from the Edge Server tab of the Global Properties page.
Office Communications Server 2007 R2 leverages existing user information available in Active Directory, plus it adds more attributes to the user object that are specific to Office Communications. These additional attributes are made available through the schema extension performed during Schema Prep and hold Office Communications Server–specific information such as SIP URI, home server FQDN, federation setting, Remote User setting, public IM connectivity (PIC) setting, Remote Call Control (RCC) settings, and Enterprise Voice settings.
In addition to the user attributes stored in Active Directory that need to be available to every home server in the forest, the user’s home server stores user settings that need to be available only to the user’s endpoint (for example, Microsoft Office Communicator, which can be considered an endpoint for communications from user to user across various systems). These settings are often large and change more frequently than the user settings stored in Active Directory. Storing these settings in Active Directory is not the right use of this technology. These settings are stored in the pool’s back-end SQL server. Settings stored in SQL Server are contacts, contact groups, permissions, and user options (call-forwarding rules, notes, and so on).
The Office Communications Server–specific user settings are exposed to administrators via the four WMI classes listed next. Unlike the client application programming interfaces (APIs) offered—such as the UC Communicator Web Access (AJAX) APIs and Communicator APIs—the advantage of these WMI APIs is that the administrator can administer a user’s contacts, groups, and permissions without needing to sign in with the user’s credentials. These WMI APIs do not expose the full functionality that the client’s APIs offer, though. For example, an administrator can prepopulate a user’s contact list with the peers from her working group or organizational structure.
The following WMI classes are used for configuring user-specific settings.
MSFT_SIPESUserContactGroupData. This WMI class exposes the user’s contact groups.
MSFT_SIPESUserContactData. This WMI class exposes the user’s contact list.
MSFT_SIPESUserACEData. This WMI class exposes permissions that are applied on the user’s contacts. Note that this class is obsolete for users that are enabled for enhanced presence.
MSFT_SIPESUserSetting. This is the main WMI class that exposes the user’s settings stored in Active Directory. Settings in this class can be divided into four main categories:
Basic settings Configure these settings to indicate whether the user is enabled for SIP, the user’s SIP URI, and the pool that the user is homed on. These are mandatory attributes that must be set before the user can start using Office Communications Server.
Meeting settings These settings are related to scheduling and participating in meetings, such as the Meeting policy assigned to the user.
Voice settings These settings are related to voice communications. This category contains settings such as whether the user is enabled for Enterprise Voice, the Voice policy and location profile associated with the user, the phone number for the user (also referred to as the line URI), and so on.
Miscellaneous entitlement settings This category contains settings that determine whether the user is enabled for various functionality such as archiving, federation, and so on.
Figure 18-8 shows the User Property dialog boxes that can be accessed either from the Admin Tools MMC or from the Active Directory Users and Computers snap-in.
Office Communications Server 2007 R2 introduces a new concept, Conference Directories. They are used for generating and resolving personal identification numbers (PINs) used for Public Switched Telephone Network (PSTN) conferencing. When a new pool is set up, exactly one Conference Directory is associated with the pool. The MSFT_SIPConferencingDirectoryData WMI class lists all Conference Directories in your deployment. The PoolD property of this class indicates the pool that each directory is associated with. The list of Conference Directories associated with a pool can be found by clicking the Assigned Conference Directories node under the pool node in the Admin Tools MMC.
Each Conference Directory contains a unique number in the ConferencingID attribute. This number is used to construct the PSTN dial-in PIN generated when a conference enabled for PSTN dial-in is scheduled. When a dial-in request for an audio conference is received, the Office Communications Server extracts the ConferencingID from the PIN that the user supplied and looks up the pool where this conference is hosted. When a pool is decommissioned permanently, the Conferencing Directory associated with that pool must be moved to a different pool. This ensures that meetings that were already scheduled on this pool can be serviced by a different pool in the future. The Conference Directory can be moved to a different pool by right-clicking the Conference Directory object in the Admin Tools MMC and launching the Move Conference Directories Wizard.
New with Office Communications Server 2007 R2, administrators and third-party application writers can create SIP endpoints that represent server applications in an Office Communications Server deployment. For example, if a third-party application writer creates a SIP application, such an application can be provisioned so that Office Communications Servers can both receive and route SIP traffic to these applications.
The following steps describe the process for registering a third-party server application with Office Communications Server.
To deploy a server application, the application needs to create an entry in the MSFT_ SIPTrustedAddInServiceSetting WMI class (described in the section titled "Configuring Trusted Server Settings" earlier in this chapter). This will ensure that Office Communications Servers will trust network traffic that comes from this server application.
If the application contains a SIP endpoint that needs to be routed to, the application needs to create an entry in the MSFT_SIPApplicationContactSetting WMI class. This class contains all the attributes that the MSFT_SIPESUserSetting WMI class has (SIP URI, telephone number, and so on).
The ApplicationDestinationDN property of the MSFT_SIPApplicationContactSetting instance has to be set to the instance of the application in the MSFT_SIPTrustedAddInServiceSetting class.
Once these three steps are completed, Office Communications Servers can route SIP traffic sent to the application’s SIP URI or telephone number to the application instance specified by the FQDN, port pair of the MSFT_SIPTrustedAddInServiceSetting class instance.
The Admin Tools MMC doesn’t provide a UI for directly manipulating these settings. Therefore, configuring server applications for Office Communications Server 2007 R2 requires using WMI directly. Note that all of the applications hosted by the Application Host use this method to route SIP traffic addressed to them.
The Conference Auto Attendant feature enables meeting participants to dial in to meetings. The following WMI classes are used for configuring these numbers:
MSFT_SIPApplicationContactSetting. As described in the section titled "Configuring Application Contact Object Settings" earlier in this chapter, this WMI class lists all the SIP-enabled server endpoints. The Conference Auto Attendant access phone numbers are defined by creating instances of this class. The Access Phone Numbers tab of the Conference Auto Attendant dialog box is shown in Figure 18-9.
MSFT_SIPLocationContactsMapping. This WMI class maps a location profile to one or more Conference Auto Attendant access numbers. When an Office Communications Server conference is scheduled, an email is sent out to the meeting participants that contain instructions on how to join the meeting. If the meeting has PSTN dial-in capability, the mapping defined in this WMI class is used to generate a list of phone numbers to call into the meeting with. The Regions dialog box of the Conference Auto Attendant Properties is shown in Figure 18-10.
