Communicator Web Access supports a number of different deployment scenarios. In a smaller organization you can install Communicator Web Access on one computer and run Office Communications Server 2007 R2 on another. In larger organizations, Communicator Web Access can be deployed as an array of servers located behind a hardware load balancer.

Communicator Web Access supports two types of virtual servers: internal (designed for authenticated users logging on behind the organization firewall) and external (designed for authenticated users logging on from outside the organization firewall). When you deploy Communicator Web Access, you can deploy one or more internal virtual servers or you can deploy one or more external virtual servers. Alternatively, you can deploy both types of virtual server, thus providing a way for users to log on to Communicator Web Access either from the internal network or from the Internet. You can even host both an internal virtual server and an external virtual server on the same computer, although this is not recommended for security reasons.

If you are planning to deploy an external virtual server it is recommended that you also deploy a reverse proxy server. In this scenario, external users initially connect to the reverse proxy server rather than connect directly to your Communicator Web Access server. After the user has been authenticated, the reverse proxy server then directs them to a Communicator Web Access server or server pool.

As a general rule, Communicator Web Access supports any reverse proxy configuration for creating a perimeter network, including Microsoft Internet Security and Acceleration (ISA) Server. However, there is one exception to this general rule. Communicator Web Access supports single sign-on authentication. With single sign-on, a user who needs to access more than one Web-based service can log on once and automatically be granted to each of those Web-based services. For instance, a user can log on and simultaneously be authenticated for both Microsoft Outlook Web Access and Communicator Web Access.

Communicator Web Access supports single sign-on, but only if ISA Server 2006 is used as the authenticating server. No other single sign-on method is currently supported.

If you want to enable audio conferencing and desktop sharing for Communicator Web Access, you will need to deploy both the A/V Conferencing Server and Mediation Server. (You will also need to deploy the A/V Conferencing Edge Server if you want to provide these capabilities to external users.) If you need to keep a record of your IM sessions (a legal requirement in some industries), you must deploy and configure Archiving Server.

Communicator Web Access must run on a dedicated computer. Collocating Communicator Web Access with any other Office Communications Server server role is not supported.

Communicator Web Access supports hardware load balancing; software load balancing is not supported. In theory, it is possible to use a single load balancer to handle both Office Communications Server connectivity and Communicator Web Access connectivity. Although this works, it does not guarantee that connection requests will be shared equally among all the servers in the Communicator Web Access array. Because of that, it is recommended that you dedicate a load balancer solely for use with Communicator Web Access.

Any load balancer that supports client affinity can be used with Communicator Web Access. Client affinity helps ensure that an entire session takes place on a single Communicator Web Access server; Communicator Web Access does not allow a session to begin on one server and then somehow be transferred to another server. If a user is logged on to Server A at the beginning of a session, the user will continue to use Server A for the duration of that session. If Server A fails, the user will have the session terminated. (That user can then sign on again, and the load balancer will route the user to a server that is still running.) Users connected to Server B or Server C will not have their session disrupted in any way if Server A fails.

For optimal performance, load balancers used with Communicator Web Access should also support the following:

• You should be able to set TCP idle time out to 1,800 seconds. If you are using Microsoft Internet Security and Acceleration (ISA) Server as a reverse proxy or single sign-on server, you should also set the idle time out on the ISA server to 1,800 seconds.
  
  
• If your load balancer is expected to handle more than 65,000 simultaneous connections, you should use source network address translation (SNAT).
  
  

  Note:
  Use of destination network address translation (DNAT) is not supported for Communicator Web Access.

• To help ensure client affinity, your load balancer should support cookie-based load balancing. It is recommended that you use HTTP Cookie Insert when creating the load balancer’s cookie persistence profile.
  
  

For details about general load balancer requirements, see Planning Load Balancing.

No special hardware is required for a Communicator Web Access server. (However, if you are setting up a pool of servers you can use a hardware load balancer to direct clients to a specific server.) For details about the recommended minimum hardware for a Communicator Web Access server, see Internal Office Communications Server Component Requirements.

As a general rule, increasing the speed of the processor, the hard disk, or the network card has a minimal effect on Communicator Web Access performance. If you want to increase the performance (and the capacity) of your Communicator Web Access servers, adding additional memory is the best approach.

For details about the operating systems that are supported for the 2007 R2 version of Communicator Web Access, see Internal Office Communications Server Component Requirements.

In addition, the following software must be running before Communicator Web Access can be installed:

• Microsoft Visual C++ Redistributable
  
  
• Microsoft .NET Framework 3.5 with Service Pack 1
  
  
• Office Communications Server Core Components
  
  
• Microsoft SQL Server Native Client
  
  
• Microsoft Unified Communications Managed API Redistributable
  
  
• Internet Information Services (IIS)
  
  

If you are installing Communicator Web Access using the Office Communications Server 2007 R2 Deployment Wizard, the Setup program will verify that each of these applications have been installed; if they have not, the wizard will notify you and offer to install any missing programs for you. If you are installing Communicator Web Access from the command line, you will need to install each of these applications before beginning the Communicator Web Access setup.

These same software requirements apply to any computer where you want to install Communicator Web Access Manager, the primary tool for administering your Communicator Web Access infrastructure. You do not have to install Communicator Web Access Manager on a computer that is running Communicator Web Access itself; this enables you to set up an administrative computer separate and distinct from your Communicator Web Access servers.

As a planner, you do not need to know the step-by-step procedures for creating a DNS record or for enabling users for remote access. However, it is useful for planners to understand the basic tasks involved in deploying Communicator Web Access in an organization. Because of that, these steps are briefly described in the following table.

Table 1. Communicator Web Access Deployment Process