Depending on the size and complexity of an organization that uses Microsoft Office Communications Server 2007 R2, administrators must configure, maintain, and manage a variety of Unified Communications desktop clients and telephony devices. At times, client computers must be configured for specific purposes that range from limited to full use.
This chapter covers common methods for managing Unified Communications clients and devices. Most organizations that deploy Office Communications Server 2007 R2 also deploy Microsoft Office Communicator 2007 R2 and Microsoft Office Live Meeting 2007 R2 to their organization’s client desktops. Depending on the Client Access license (CAL) that an organization has purchased, there are varying degrees of client function available to users. In addition, many organizations are deploying Microsoft RoundTable communications and archival system along with Microsoft Office Communicator Phone Edition devices across their networks. Therefore, this chapter also discusses how to manage the combination of Unified Communications clients and devices in your organization so that you get the most benefit from each.
On the Companion Media
Links to information related to the topics addressed in this chapter can be found on this book’s companion CD.
To deploy Office Communicator 2007 R2 across your organization, you can use any method that supports the Microsoft Windows Installer package (.msi file). In addition, you can control key features and settings by using installation scripts or Active Directory Domain Services Group policies.
This section assumes that you have already deployed Office Communications Server 2007 R2 Enterprise Edition or Standard Edition.
Log files are important tools for diagnosing and troubleshooting issues with Office Communicator 2007 R2 setup and operation. You can generate a log file during Communicator 2007 R2 setup by adding /l*v followed by a file name to the Windows Installer command prompt. For example:
msiexec /qn /i Communicator.msi /l*v logfile.txt
The asterisk specifies that all possible errors, warnings, and status messages are written to the log file. The v specifies that all messages are verbose.
Other log file flags are also possible. For example, /lem generates a log file that contains error messages as well as out-of-memory and fatal exit information. For a complete list of log file options, see the Windows Installer documentation on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkID=133739.
You can also configure event trace log (ETL) files to be generated on your computer in the <username>/Tracing folder. ETL files enable administrators and Microsoft support technicians to troubleshoot problems. For more information, contact your Microsoft support representative.
Table 19-1 summarizes the Group Policy settings that you can use to control certain features in Communicator 2007 R2. For more information about Meeting policies, see the section titled "Configuring Meeting Policy" in the Microsoft Office Communications Server 2007 R2 Administration Guide.
Table 19-1. Group Policies for Telephony
SERVER SETTING | GROUP POLICY SETTING | |
|---|---|---|
Standard (basic computer-to-computer calling) | None (TelephonyMode 0) | Not present, or TelephonyMode 0 |
Voice (also called Standard with Voice) |
|
|
Enterprise | In the Meeting section of Global Policies:[*]
|
|
Enterprise with Voice | See the settings in the Voice and Enterprise rows earlier in this table | See the settings in the Voice and Enterprise rows earlier in this table |
[*] Using the Office Communications Server 2007 Administrative Tools snap-in. | ||
Table 19-2 summarizes the set of functions that are available for each telephony mode.
Office Communications Server 2007 R2 can operate with the telephony infrastructure that is commonly found on users’ desktops. With Office Communications Server 2007 R2, users can send and receive calls by using the Public Switched Telephone Network (PSTN) and also integrate with a company’s Private Branch eXchange (PBX) system.
Office Communications Server 2007 R2 also combines VoIP with open standards to provide the platform for the telephone menu–based part of the Unified Communications strategy. This combination enables integration features that bridge the VoIP standards supported by Office Communications Server 2007 R2 with implementations that use older standards.
At the center of this integration is the Mediation Server role in Office Communications Server 2007 R2. This server role provides a single interface and uses open-standard Session Initiation Protocol (SIP) for signaling interoperability. The Mediation Server takes calls from third-party IP PBX systems or SIP/PSTN gateways and moves them through the network by using the adaptive codec, remote user, and security models that are the basis for call setup and media in Office Communications Server 2007 R2.
The following are common configurations for Office Communications Server 2007 R2:
A standalone configuration that is based on Office Communications Server and that uses Communicator 2007 R2 (TelephonyMode=1)
A coexistence configuration that uses a mixture of Office Communications Server 2007 R2 and PBX capabilities (TelephonyMode=2)
A dual forking configuration that enables a user to share a single phone number with Office Communications Server 2007 R2 and the organization’s PBX (TelephonyMode=3)
The following sections explain how calls are routed based on the configuration.
In a standalone configuration, users replace their legacy phone systems with Office Communicator 2007 or Office Communications Server 2007 IP phones. This configuration enables Office Communications Server 2007 R2 users to use Office Communicator 2007 to make and receive calls. PBX users can use the PBX to make and receive calls. Each group continues to have a smooth calling experience, including extension-based dialing capability. This configuration works especially well for organizations that have mobile employees. The standalone configuration can be implemented by using either a SIP/PSTN gateway or a direct SIP connection to the PBX.
A peer-to-peer call using Communicator 2007 R2 occurs when one Communicator 2007 R2 client places a call to another Communicator 2007 R2 client. In this case, the call is a direct VoIP call and is handled exclusively by Office Communications Server 2007 R2. The presence status (in a call) is broadcast to other Office Communicator 2007 R2 endpoints. The call is a SIP INVITE from one client to another and audio is established.
Notice also that when a PSTN gateway and Mediation Server are present, PSTN calls can be made to Communicator clients, and Communicator clients can place calls to the outside PSTN network.
Figure 19-1 demonstrates how a call is routed in an environment configured for the TelephonyMode=1 server setting when a Communicator 2007 R2 client (Client A) places a peer-to-peer call to another Communicator 2007 R2 client (Client B).
Coexistence occurs when an incoming call is forked between the PBX phone and the Office Communicator 2007 R2 endpoints that the user is logged on to. Both the PBX phone and Office Communicator 2007 coexist for the user. The result is a mix of PBX and Office Communications Server 2007 R2 communication capabilities that are configured for call routing by using IP PBX integration between the user’s legacy phone and Office Communicator 2007 R2.
Remote Call Control (RCC) enables Office Communicator 2007 R2 to control a user’s PBX phone line and indicate their presence based on the status of their phone. Using Office Communicator 2007, users can answer their PBX phone and update their presence to In A Call.
Figure 19-2 demonstrates the TelephonyMode=2 server setting for a call placed from a PBX phone and received using either the recipient’s PBX phone or the recipient’s Communicator 2007 R2 client.
As shown in Figure 19-2, the following occurs.
PBX phone User B places a direct call to PBX phone User A. The PBX phone for User A rings. The PBX phone can be answered.
At the same time the PBX phone for User A is ringing, User A receives an alert from Communicator 2007 R2 that they can receive the call by using Communicator. The Communicator client can be used to answer the call via RCC.
Most IP PBXs support dual forking. Dual forking enables a user to share a single phone number with Office Communications Server 2007 R2 and the organization’s PBX. Additionally, the PBX can support direct SIP for certain numbers that are managed by Office Communications Server 2007 R2, or it can enable users who are not enabled for voice via Office Communications Server 2007 to manage numbers themselves. It is also possible to configure dual forking with RCC. Remote Call Control provides information to Office Communications Server 2007 R2 about the state of PBX-connected lines. This enables presence updates when the user is on the PBX-connected station set.
Figure 19-3 demonstrates how a call is routed in a dual forking configuration (TelephonyMode=3).
In Figure 19-3, the following scenarios demonstrate dual forking for sending and receiving a phone call:
Scenario 1: User A uses a PBX phone to place a direct call to the PBX phone for User B. The PBX phone for User B rings. User B can answer the PBX phone. However, the call is also forked to a Mediation Server, and the call simultaneously displays an alert on the Communicator client for User B. User B could also choose to use Communicator to answer the call.
Scenario 2: A Communicator call is placed from User A to User B. The Communicator client for User B receives an alert to receive the call from User A. Simultaneously, the PBX phone for User B rings.
When a user initiates the sign-in process, Communicator must determine which server to log on to by using the user’s Uniform Resource Identifier (URI; for example, [email protected]) and any manual settings that are configured on the client. If manual settings were provided, it is clear which server to use. But if the URI is the only indicator provided, some discovery is necessary.
Communicator discovery varies based on configuration. After the client discovers the server to which to connect, it attempts to connect by using Transmission Control Protocol (TCP) or Transport Layer Security (TLS) over TCP. If TLS is used, the server provides a certificate to authenticate itself to the client. The client must validate the certificate before proceeding. The client negotiates compression if using TLS over TCP, and then the client initiates a SIP registration.
Next, the client sends a SIP REGISTER message to the server without any credentials. Office Communications Server 2007 R2 then prompts the user for credentials and specifies to the Communicator client the authentication protocols that it accepts.
When it comes to providing credentials, Communicator has two options. Communicator can use the user’s current Windows credentials to log in, or it can prompt the user for credentials.
Note
You can also use the Credential Manager in Windows to manage credentials. For more information about the Credential Manager, see the Microsoft TechNet article "Windows XP Resource Kit: Understanding Logon and Authentication" at http://go.microsoft.com/fwlink/?LinkID=133674, in the "Stored User Names and Passwords" section.
Due to the order in which Communicator tries to satisfy the server’s request for credentials, authentication failures can occur during the first part of logon processing. This can happen when credentials are not already saved or if the desktop credentials do not match the account that Communicator is trying to use. This can also happen when the SIP URI, account name, or password is typed incorrectly or when credentials and the SIP URI do not match. An example of this is if Jeremy tries to log in using the URI sip:[email protected], but he uses the user account and password for LITWAREINCvadim instead of the account owner’s own credentials, LITWAREINCjeremy.
When the client is set to use automatic configuration, it discovers where it should log on by using the SIP URI that was provided. Communicator does this by using Domain Name System (DNS) Service Record Locator (SRV) records published for the domain portion of the SIP URI. For example, if sip:[email protected] is the URI that is provided, Communicator takes litwareinc.com and tries to use DNS to discover a SIP server. Communicator can query for the following SRV records in its search for an appropriate server:
_sipinternaltls._tcp.litwareinc.com
_sipinternal._tcp.litwareinc.com
_sip._tls.litwareinc.com
The first query looks for an internal server in the litwareinc.com domain that has ports that support TLS over TCP for clients. The second query looks for an internal server in the litwareinc .com domain that offers TCP ports for clients. The third query looks for an Internet-reachable server for the litwareinc.com domain that has ports that support TLS over TCP for clients. Communicator never looks for an Internet-reachable server that supports TCP because clear-text SIP on the Internet is not secure. In other words, Communicator is not aware whether the network that is being used is internal or external. Communicator queries for all DNS SRV records; however, it tries TLS over TCP connections first. TLS over TCP is forced through an Edge Server. There is not an option to allow for unsecured TCP connections.
If Communicator fails to find the correct server by using these files, it falls back to host (A) record queries:
sipinternal.litwareinc.com
sipexternal.litwareinc.com
If no DNS SRV records exist (not if they fail to be valid; only if they do not exist), the client queries sipinternal.<URI domain> and attempts to resolve that host name. If the host name resolves to an IP address, Communicator tries to connect using TLS over TCP, TCP, or both, depending on what the policy allows. If this fails, Communicator will try one last query with sipexternal.<URI domain>.
Communicator policies can be put in place to prevent TCP from being used, and this prevents the second query from being issued. You can also specify a policy that requires strict names for the computers that Communicator discovers. In this case, the only server name allowed is sip. If this policy is not imposed, any server name in the form of <servername>.<URI domain> is allowed. For example, for sip:[email protected], the host sip.litwareinc.com is always allowed whether strict policy is implemented or not. Server77.litwareinc.com, sipfed. litwareinc.com, and ap.litwareinc.com are also allowed if a strict naming policy is not enabled. The following server names are never allowed because they do not closely fit the domain that the user’s URI specified, and therefore the client does not trust these servers as valid logon points: sip.eng.litwareinc.com, sip.litwareinc.net, sip.com, sip.litwareinc.com.cpandl.com, and so on.
This close validation between the host name and the URI is done because the only configuration with which the client is provided is the SIP URI. Because of this, the client must be careful not to allow DNS attacks that enable the client to connect to any middle point that could thereby intercept Communicator traffic. By having close validation between the URI and the host names that are allowed for logon, Communicator can be more certain that the certificate the user is validating has authority for the domain to which he is trying to log on.
After the host name is identified, Communicator also resolves the host name to an IP address. This usually happens as the result of the DNS SRV request, but until the IP address is resolved, Communicator cannot connect.
In the latest version of Communicator, you can manually specify an internal and external server to which to log on. Communicator always attempts to connect to the internal server if it is available, but it will connect to the external server as an alternative. Earlier versions of Communicator have only a single manual entry, which makes it difficult to accommodate mobile workers. With the ability to specify an internal and external server, administrators can configure and enable portable computers and other mobile devices to work across internal and external networks. This increased functionality also accommodates companies where the domain in the user’s URI is not the same as their SIP enterprise server’s domain. Because the administrator can configure Communicator (for example, on a laptop), the user does not need to remember the internal or external servers, and administrators do not have to publish DNS SRV records for all the domains they want to support for remote access users.
Real World: Role of SRV Records in Office Communicator Log
Indranil Dutta
Premier Field Engineer
The Office Communicator client enables the user to automatically connect to the appropriate Office Communications Server 2007 R2 server without putting in the server name. Whether the client is inside the internal network or is working externally, this feature redirects the client and enables it to authenticate and connect to its own Office Communications Server 2007 R2 server (in the case of Standard Edition) or home pool (in the case of Enterprise Edition). This ability to automatically connect has a significant DNS dependency. For this to work successfully, the appropriate SRV records must be published internally and externally.
When the Office Communicator client first starts and the user tries to connect, Office Communicator always tries to connect to the server or home pool in its same domain or to one that uses the same SIP URI that is in the sign-in address. For example, if the sign-in name used is [email protected], Office Communicator looks for the home pool or Office Communications Server 2007 R2 server that is in the same DNS namespace, which is fabrikam.com. This process is facilitated by using DNS SRV records that point the client to the fully qualified domain name (FQDN) of the home pool or server in the correct domain. The process works the same whether the client is in an internal or external network. Figure 19-4 illustrates the automatic server discovery process.
In Figure 19-4, the client starts querying SRV records and, by default, it always tries to use TLS for authentication. If TLS fails, the client uses TCP as an alternative. Either of the following DNS records should be published and available in the internal DNS namespace:
_sipinternaltls._tcp.fabrikam.com
_sipinternal._tcp.fabrikam.com
The client gets the host name back and directly connects to the home pool or to the Office Communications Server 2007 R2 server. Or, the client continues its query process in the external network by using the following DNS records:
_sip._tls.fabrikam.com
_sip._tcp.fabrikam.com
If either of these queries is successful, the client is redirected to the Access Edge Server and subsequently to the internal home pool or the Office Communications Server 2007 R2 server. However, if these queries fail, the client makes a final attempt to look up the host records directly by using the following DNS records:
sip.fabrikam.com
sipinternal.fabrikam.com
If this attempt to configure its settings automatically fails, Office Communicator requires manual intervention to resolve the failed sign-on process.
Figure 19-5 shows an actual network trace that was filtered on port 53 to show only DNS queries. It illustrates the lookup process that the Communicator client uses during the logon process.
This section describes the way in which Office Communicator 2007 R2 is compatible with previous versions of Office Communicator, Microsoft Office, Microsoft Exchange Server, and Microsoft Windows. The following topics are discussed:
Office Communicator 2007 R2 and Office Communicator 2005 compatibility
Office Communicator 2007 R2 and Microsoft Office compatibility
Office Communicator 2007 R2 and Exchange Server compatibility
Office Communicator 2007 R2 and Windows compatibility
Exchange Server Communication interfaces
Table 19-3 describes the features supported in Communicator 2005 and Communicator 2007 R2.
Table 19-3. Communicator 2007 R2 and Communicator 2005 Compatibility
COMMUNICATOR 2005 | COMMENTS | |
|---|---|---|
Instant messages | Supports only plain text in IM | Office Communicator 2007 R2 has an 8-kilobyte (KB) limit on IM message size and supports .rtf and .ink extensions |
Multiparty IM | Can receive multiple IM and perform sentGroup IM dial-out | Office Communicator 2007 R2 can receive mesh-based multiple instant messages but can only create IM multipoint control unit (MCU)–based group IM |
File transfer | Supported | Supported in Office Communicator 2007 R2 |
Table 19-4 describes the features supported in various versions of Microsoft Office and Office Communicator 2007 R2.
Table 19-4. Communicator 2007 R2 and Microsoft Office Compatibility
MICROSOFT OFFICE VERSION | SUPPORTED IN OFFICE COMMUNICATOR 2007 R2? | COMMENTS |
|---|---|---|
Office 2000 | No | Office 2000 does not support Office Communicator 2007 R2 |
Office XP SP3 | Yes | Contacts are supported; however, there is no Persona menu (only INFO line) |
Office 2003 SP3 | Yes |
|
Office 2007 SP1 | Yes |
|
Table 19-5 describes the features that are supported in various versions of Exchange Server and Office Communicator 2007 R2.
Table 19-5. Office Communicator 2007 R2 and Microsoft Exchange Server Compatibility
EXCHANGE SERVER VERSION | SUPPORTED IN OFFICE COMMUNICATOR 2007 R2? | COMMENTS |
|---|---|---|
Exchange Server 5.5 | No | Not supported |
Exchange Server 2000 | Yes | MAPI only |
Exchange Server 2003 | Yes | Extended MAPI only |
Exchange Server 2007 | Yes | Time-of-the-day forwarding is available only with Exchange Web Services; note that public folders are optional in Exchange Server 2007 |
Note
Office Communicator 2007 depends on Microsoft Office Outlook to install the Extended Messaging Application Programming Interface (MAPI) on the client computer. Thus, all the features in Table 19-5 require Office Outlook.
Table 19-6 describes the features that are supported in various versions of Windows and Office Communicator 2007 R2.
Table 19-7 describes the various versions of Exchange Server–related communication interfaces for Office Communicator 2007 R2.
Table 19-7. Exchange Server Communication Interfaces
COMMUNICATION INTERFACE | EXCHANGE SERVER VERSION | SUPPORTED FEATURES |
|---|---|---|
Outlook object model | N/A |
|
MAPI | Exchange Server 2000, Exchange Server 2003, and Exchange Server 2007 |
|
Exchange Server 2007 |
|
Office Communicator 2007 is available in several languages, each with its own installer package. In addition, a Multilingual User Interface (MUI) package for Office Communicator 2007 is available. The MUI package for Office Communicator 2007 contains the localized resources for the user interface in Office Communicator.
The following issues must be taken into account when installing the Office Communicator 2007 MUI package:
The MUI package installs 36 languages (Listed in Table 19-8).
Table 19-8. MUI Package for Office Communicator Languages
LANGUAGE COUNTRY/REGION
LCID HEX
LCID DEC
Arabic, Saudi Arabia
0401
1025
Bulgarian
0402
1026
Chinese, People’s Republic of China
0804
2052
Chinese, Taiwan
0404
1028
Chinese, Hong Kong SAR
0c04
3076
Croatian
041a
1050
Czech
0405
1029
Danish
0406
1030
Dutch, Netherlands
0413
1043
English, United States
0409
1033
Estonian
0425
1061
Finnish
040b
1035
French, France
040c
1036
German, Germany
0407
1031
Greek
0408
1032
Hebrew
040d
1037
Hindi
0439
1081
Hungarian
040e
1038
Italian, Italy
0410
1040
Japanese
0411
1041
Korean
0412
1042
Latvian
0426
1062
Lithuanian
0427
1063
Norwegian (Bokmål)
0414
1044
Polish
0415
1045
Portuguese, Brazil
0416
1046
Portuguese, Portugal
0816
2070
Romanian
0418
1048
Russian
0419
1049
Serbian (Latin)
081a
2074
Slovak
041b
1051
Slovenian
0424
1060
Spanish, Spain (Modern)
0c0a
3082
Swedish
041d
1053
Thai
041e
1054
Turkish
041f
1055
Ukrainian
0422
1058
No custom installation option is available.
The MUI Setup will automatically determine the language used by the computer operating system and display that language during setup.
You can select any of the 36 languages to be displayed by Office Communicator 2007 independent of the language that is installed for the Office Communicator 2007 client. For example, if the Spanish version of Office Communicator 2007 is installed on your computer, you can select the French language from the MUI pack to display Office Communicator 2007 in French.
When Office Communicator 2007 is removed from your computer, the MUI package for Office Communicator 2007 remains on the computer and must be removed separately.
To install the MUI package for Office Communicator 2007, visit http://go.microsoft.com/fwlink/?LinkID=133740.
Table 19-8 lists the languages and regions installed with the MUI package for Office Communicator 2007 R2 in their locale identifier (LCID) hexadecimal and decimal format.
To select a language for MUI for Office Communicator 2007, do the following.
In the Office Communicator 2007 title bar, click the down arrow, click Tools, and click Options, as shown in Figure 19-6.
Click the General tab and then, under Language, select a language, as shown in Figure 19-7.
You can also use the Microsoft Registry Editor to configure the language for the MUI pack. To use the Registry Editor to select a language, perform the following steps.
Click Start, click Run, and type Regedt32.
Under My Computer, click HKEY_CURRENT_USER.
Click Software, click Microsoft, and then click Communicator.
Double-click Language and (referring to Table 19-8) type the LCID for the language/ region.
Click OK and close the Registry Editor.