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:
- Primary – Reference Architecture 1: Single consolidated Edge
- Primary – Reference Architecture 2: Scaled consolidated Edge
using NAT and DNS load balancing
- Alternate – Reference Architecture 3: Scaled consolidated Edge
using public IP and hardware load balancing
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
- Communications Server 2010 supports virtualization of Edge
servers but the reference architectures assume physical servers are
- 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
- Edge internal interface is on a network that is different from the network where Edge external interface is located.
- Windows Server 2008 Strong Host model is used on all Edge
- 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
- 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
- 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
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.