OCS R2 Edge Topologies Explained

Byron Spurlock has a blog article that briefly talks about the different topologies for Edge servers in R2 but I wanted to go into a little more detail and highlight a few seemingly small, but important changes introduced in R2 that sort of flew in under the radar as all the other neat features in R2 took center-stage.

Pre-R2 Topologies

Firstly, anyone versed in OCS should know that when deploying an Edge Server you could select what roles you wanted to install, with a few limitations. The following table shows the different Edge Server configurations supported by OCS 2007 pre-R2 as described in the Edge Server Deployment Guide.

The different Edge roles were allowed to be installed on different physical hardware, resulting in many different (and potentially confusing) scenarios. Basically you could have (1) a dedicated server for each role, (2) separate servers with the Access Edge and Web Conferencing together with another server hosting the A/V Conferencing role, or (3) all three Edge roles on the same system. Then you could install multiple arrays of these different scenarios. Lost yet? Yeah, me too.

Microsoft acknowledged that this flexible, albeit overly complex set of configurations was rarely used in practice. Nearly every enterprise level deployment we performed prior to R2 simply used one or more Consolidated Edge Server. The requirement to break up SIP and Media traffic on dedicated systems was never important enough to warrant separating all those roles out as usually physical space, available IP addresses, and cost were the driving factors.

Enter Release 2

The supported Edge topologies for OCS 2007 R2 have been greatly simplified by changing one key requirement: Only Consolidated Edge Servers are supported. In fact, the deployment wizard (whether run from the Standard Edition or Enterprise Edition media) only allows for the installation of all components. There is no longer an option to choose which Edge role(s) to install on the server. Regarding support, the R2 documentation states the following:

Supported Topologies
Each Edge Server always runs all three Edge Server services: Access Edge service to validate external users and enable instant messaging (IM), Web Conferencing Edge service to enable external users to join on-premises meetings, and A/V Edge service to enable the sharing of audio and video with external users, and enable Desktop Sharing with external users.

You can configure one or more Edge Servers on your network, according to your performance needs. Three Edge Server topologies are supported: single consolidated edge topology, scaled consolidated edge topology, and multiple-site consolidated edge topology.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

What is important to clarify is that all three different topologies still utilize Consolidated Edge Servers. By having all three Edge roles in a single server you simply add additional hosts to create and expand a pool of servers as bandwidth requirements increase. The previously supported Consolidated and Single-Site scenarios are affectively merged into the same scenario now, leaving just 3 unique topologies.

For example, here’s the diagram of the Scaled Consolidated Edge Topology that shows a pool of consolidated Edge Servers:

So the simple take-away is that with R2 forget what you know about previous Edge role collocation and just think that there is now only one type of Edge Server.

Multiple Access Edge Roles

Ok, so now you may be saying to yourself “I thought multiple Access Edge servers weren’t supported in a multi-site topology” and you’d be correct. If you are deploying multiple consolidated Edge Server in different sites that all support users for the same SIP domain (read: single DNS SRV record for Automatic Configuration) then the primary site’s Access Edge Server roles should be configured to handle external client login. The other server’s Access Edge roles will still be deployed and configured with unique FQDNs, but they will not be used and basically sit idle. The remote site’s Edge server’s will handle Web Conferencing and A/V traffic though, which is considerable more bandwidth intensive the basis SIP traffic that the primary site handles.

A/V Edge with NAT

As Matt and others have previously discussed NAT works when used on the A/V Edge Role in R2, the different support statements throughout the documentation can be read in ways that might seem confusing.

The Security section makes a this statement:

If the edge server is a single consolidated edge server, Office Communications Server 2007 R2 allows the use of NAT for all three edge services.

The first time I read that I assumed (thinking back to what I knew was true with pre-R2 topologies) that it meant the NAT limitation hinged on the word ‘consolidated’ not realizing that the keyword was actually ‘single’.

Meanwhile the Operations portion of the R2 documentation has a clearer definition that better calls attention to the fact that a single server versus multiple servers is where the limitation on NAT stands.

To allow the external IP address to be translated from a public IP (NAT), select the External IP address is translated by NAT check box. This option is valid for a single A/V Edge service deployment. Multiple A/V Edge services that are deployed behind a load balancer do not support network address translation (NAT).

So, I hope this helps clear up any confusion people might have on the change in Edge topologies.