Supported Topologies in Microsoft Office Communicator Web Access (2007 Release)

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

You can deploy Communicator Web Access as a part of any supported Office Communications Server topology, including a branch office deployment. This section describes supported Communicator Web Access topologies.

Deployment of Communicator Web Access is subject to the following constraints:

  • Communicator Web Access servers must be deployed in the internal network, not in the perimeter network.

  • Collocation of Communicator Web Access and Office Communications Server on the same computer is not supported.

  • Installing Communicator Web Access on an Active Directory domain controller is not supported.

Supported topologies for Communicator Web Access are as follows:

  • Separate server arrays for internal and external users

  • Separate single servers for internal and external users

  • One server for both internal and external users

The supported Communicator Web Access topologies are described in the following sections.

Separate Server Arrays for Internal and External Users

In the reference architecture, which is shown in Figure 1 earlier in this guide; internal users and external users access Communicator Web Access on separate server arrays. This physical separation of traffic originating internally from that originating on the Internet improves overall security and availability.

The reference architecture contains two hardware load balancers, one for the internal array and one for the external array. An alternative to this configuration is a single server for one or both of the arrays.

Separate Single Servers for Internal and External Users

In Figure 2, internal user traffic is physically separated from external user traffic by deploying a dedicated server for each type of user.

Figure 2: Separate Servers

b5737ca7-a1b0-48ce-86ec-2adffb817092

All servers in this topology use port 443. The firewall/reverse proxy server is configured to redirect incoming SSL traffic bound for port 443 to port 443 on the Communicator Web Access server for external users.

If you decide to use different port numbers, users may need to specify the port number when they enter the Communicator Web Access URL. For example, if you use port 444 on the internal server, users would need to specify the port number by typing https://im.contoso.com:444.

One Server for both Internal and External Users

In order to reduce deployment costs, you can host both internal and remote users on a single Communicator Web Access server; however, we do not recommend this approach. Hosting all users on a single computer is not as secure as deploying separate servers for internal and external users. In order to deploy all users on a single computer, you must run IIS 6.0 in application isolation mode. For details about application isolation modes in IIS 6.0, see "Application Isolation Modes" at https://msdn.microsoft.com/en-us/library/aa720149(v=vs.71).aspx.

By using application isolation mode, you can run two instances of Communicator Web Access on a single physical server. You create one virtual server instance when you set up Communicator Web Access. After setup is complete, you can create another virtual server instance by using the Communicator Web Access Manager snap-in.

Note

Although using a single computer for both internal and external users reduces hardware costs, we do not recommend it. This approach should be used only in small deployments where Communicator Web Access is not a mission-critical program. Physically isolating internal and external user traffic by deploying Communicator Web Access on separate computers is the most secure mechanism and is recommended whenever your budget permits.

If you use a single computer for both internal and external access, the following considerations apply:

  • Two virtual servers cannot both share the same IP address and also listen on the same port; therefore, you must differentiate the virtual servers on your computer either by IP address or by port number. If both virtual servers use the same IP address, you will need to differentiate them by port number. Many proxy servers accept SSL traffic only on port 443, so you may need to manually configure the external virtual server to use port 443.

  • You must configure your firewall or reverse proxy to map to the appropriate port for each virtual server.

  • Although application isolation reduces security risk, it is still possible for the server to be compromised, which could affect both external and internal users. In contrast, using a separate external server would limit the impact of an attack on the external server to remote users only.

Figure 3 shows an example of a single Communicator Web Access server that is used for both internal and external access by using application isolation.

Figure 3: Single Server for Internal and External Users

f5e5ba17-09ef-4fe1-8bed-9ba9b7b9a63a

Figure 3 shows a way to configure a deployment so that neither internal users nor remote users have to specify a port when they enter the URL of the Communicator Web Access virtual server. The internal virtual server is configured to accept internal requests over the default SSL port 443. The firewall is also configured to accept external requests over the default SSL port 443, but it then redirects these requests to the external virtual server, which is on port 444 in the internal network.