This section provides some basic information on enabling Office Communicator Web Access 2007 and Office Communicator Mobile Access 2007. An introduction to the basic topology requirements is provided along with some overview information.
Office Communicator Web Access (CWA) is a Web-based replacement for the Office Communicator client and provides a great way to reach alternate operating systems and nondomain workstations without an install process. CWA provides internal and remote access (if a reverse proxy is set up for it) to the Office Communications Server infrastructure by enabling instant messaging and presence capabilities. File transfer, A/V conferencing, whiteboard sessions, and application sharing are not available with CWA like they are with Office Communicator, however. The Web browsers that are supported by Office Communicator Web Access are shown in Table 6-1.
Table 6-1. Supported Browsers for Office Communicator Web Access 2007
Operating System | Browser | Authentication Mechanism |
|---|---|---|
Windows 2000 SP4 | NTLM Kerberos Forms-based Custom | |
Windows XP SP2 | Internet Explorer 6 SP2 Windows Internet Explorer 7 | NTLM Kerberos Forms-based Custom |
Forms-based Custom | ||
Windows Vista, Enterprise Edition | Internet Explorer 7 | NTLM Kerberos Forms-based Custom |
Mozilla Firefox 2.0.0.3 and later | Forms-based Custom | |
Mac OS X 10.4.9 |
Mozilla Firefox 2.0.latest | Forms-based Custom |
Office Communicator Web Access 2007 has several new enhancements that weren't present in Office Communicator Web Access 2005, including the following:
A robust CWA topology can provide support for Web-based access internally and remotely with load-balanced Web servers hosting CWA. (See Figure 6-11.) However, many topologies are supported. Office Communicator Web Access can be deployed in several different topologies:
A single CWA server for both internal and external users
Separate CWA servers for internal and external users
Separate CWA server arrays for internal and external users (as shown in Figure 6-11)
The following topologies are not supported for deploying CWA:
CWA should not be deployed in the perimeter network.
CWA should not be installed on a domain controller.
Remote access logins using CWA go through the following process when logging in against the topology shown in the preceding example:
The remote user on the public Internet uses her Web browser to connect to the Office Communicator Web Access URL (for example, https://im.contoso.com). This request securely connects through the reverse proxy in the edge network, which routes the connection to the load balancer for the external CWA Web farm.
The Web browser verifies the CWA server certificate comes from a trusted CA, and it validates the name that was connected to (for example, im.contoso.com) is represented in the certificate in the Subject Name (SN) or Subject Alternate Name (SAN) fields.
CWA authenticates the user, validates the SIP URI, and ensures the user is allowed to log in with remote access. Integrated Windows authentication (Kerberos/NTLM for internal users) or forms-based authentication (NTLM for external users and browsers that don't support Integrated Windows authentication) can be used by CWA to authenticate the user.
The mutual transport layer security (MTLS) server certificate configured for CWA is used to authenticate and encrypt connections between the CWA server and the Office Communications Server 2007 server. This connection will be used to transport the user's SIP-based communications to and from the rest of the Office Communications Server infrastructure.
Office Communicator Mobile Access (COMO) gives users the ability to connect to their Office Communications Server 2007 infrastructure remotely via a phone device. The phone device can be a Pocket PC 5.0/6.0 or a Smartphone 5.0/6.0. COMO gives the user the ability to send an instant message to one or more users (such as distribution lists), publish enhanced presence status, look up users from the enterprise global address book, and initiate phone calls and communicate with Public IM Connectivity (PIC) users and federated partners that are provisioned by the enterprise.
COMO leverages the existing Office Communications Server 2007 infrastructure for its functionality. There is not a server role that is specific to COMO—it works just like Office Communicator once it has network connectivity over a wireless data or phone network.
Figure 6-12 illustrates the various ways that Office Communicator Mobile can connect to an Office Communications Server 2007 deployment. COMO clients connect to the internal server or the Access Edge Server based on the network the device is connecting from.
Once you have decided to deploy COMO in your Office Communications Server 2007 environment, there is a client piece that needs to be installed on the end user's phone device. Specifically, the phone device needs to be able to have a certificate installed on it.
Certificates help keep your network secure by authenticating the Office Communications Server to which Office Communicator Mobile connects. To perform authentication, Office Communicator Mobile requires that the root certificate that is part of the server certificate chain be installed on the device. If your organization uses a public CA, it is likely that the root certificate is already installed on your users' mobile devices.
Figure 6-13 explains the steps that are required when deciding what type of certificate should be installed with COMO.
Because Office Communicator Mobile acts so much like a standard Office Communicator client, there really isn't much more to it unless problems show up. If there are problems, the easiest way to diagnose issues is to have the user log in with a standard Office Communicator client from the same network to verify that the problem is specific to Office Communicator Mobile. If there are problems, emulators can be downloaded from http://www.microsoft.com/windowsmobile by searching for "windows mobile emulator".