[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-18

Three reference architectures are provided to highlight the Microsoft Communications Server 2010 topologies that have been tested and are therefore supported. There are two primary Edge topologies and one alternate:

The recommended approach for deploying Communications Server 2010 Edge is to use the planning tool to generate an input file for Topology Builder. The reference architectures in this section are not a replacement for that process, but instead are a set of drawings and tables designed to assist with it.For best results, use the topology flowchart in Planning for External User Access to select a topology and then review the reference architecture section that corresponds to it. The assumptions below apply to all three topologies, and you will want to review them first.


There are a number of network and environmental factors that can affect Edge Server performance. The reference architectures are designed using best practices to help prevent common configuration issues and are based on the assumptions defined below. If you choose a different configuration (for example, 3-leg perimeter network), you may still be able to make it work, but it is not a configuration that has been tested or supported.

  • Dedicated perimeter network (also known as a DMZ, demilitarized zone, and screened subnet) with internal and external firewalls.

  • Communications Server 2010 supports virtualization of Edge servers but the reference architectures assume physical servers are used.

  • Two NICS configured as follows:

    • Edge internal interface is on a network that is different from the network where Edge external interface is located.

    • The Edge external interface NIC has 3 IP addresses bound to it (Access, Web Conferencing and A/V, with the Access IP address set to primary and the other two IP addresses set to secondary.

    • Only one default gateway is configured and it is assigned to the Access Edge external interface and pointed to the external FW IP address.

  • Windows Server 2008 Strong Host model is used on all Edge servers.

  • Director is not shown for simplicity but a Director would typically be deployed to reduce the risk of a DOS attack.

  • A static, persistent route is configured from the network containing the Edge internal interface to all the corporate networks containing Communications Server 2010 servers and clients.

  • Split brain DNS (for example, the same domain hosted on internal and external DNS servers) is not used in the examples specifically to highlight the workarounds required for this configuration but typically it is deployed.

  • Edge servers are pointed to a DNS server in the perimeter because host files do not natively support DNS load balancing.

  • All Edge external interfaces use either Network Address Translation, with destination IP addresses changed inbound (half-NAT) and the source IP addresses changed outbound (full-NAT, combined with DNS load balancing). Or they use publicly routable IP addresses combined with hardware load balancing.

    A hybrid configuration with Access and Web Conferencing Edge services behind NAT and the A/V Edge service configured with a publicly routable IP address, is not supported in Communications Server 2010.

  • Router and Firewall functions are integrated into a single device and for reference, the Edge and reverse proxy server(s) in a perimeter network that is in between an external and internal integrated router/firewall.

  • Only a single reverse proxy server is shown but if there was a pool of reverse proxy servers deployed in the perimeter network, they would be load balanced using a hardware load balancer because DNS load balancing does not work with client to server web traffic.

After you have selected a topology and determined your certificate, port and DNS requirements, you can use one of the three reference architectures to see how a typical deployment will look. You should then be able to modify the existing tables with your production FQDNs and IP addresses and use them to assist with your production deployment.