OCS Edge Server Configuration Topologies

Although deploying Office Communications Server 2007 for use internally is quite straight-forward, things begin to get complicated when adding in the components used for external client connectivity. The most misunderstood portions of deployment seem to be the correct configuration of the reverse proxy, and the networking configuration of the Edge Server itself.

OCS Edge Server Configuration

The Edge Server Deployment guide covers a variety of support topologies but the Consolidated Edge Topology is probably the most common, yet least understood. When deploying a single Edge Server role into a test, pilot or production environment it is important to correctly design and configure the networking component of the Windows Server before installing OCS. I’ve seen both first-hand and online many scenarios where an attempt to stray, even slightly, from the recommended deployment parameters can cause major communications problems across the board.

IP Addressing

Most importantly the deployment guide recommends that a different IP address should be assigned to each server role. Unless you enjoy spending an inordinate amount of time reading through tracing logs or troubleshooting strange connectivity errors I suggest you heed this advice. Yes, you can modify default ports for separate OCS communications and pile-on services into a single-IP address, but why? Unless there is some major limiting factor in your specific environment or Santa only gave one IP address to you for Christmas, save yourself some grief and stick to the recommendations as best as you can.

I suggest closely reading Step 1.2 in the OCS 2007 Edge Server Deployment Guide describing the deployment topology. Each of the bulleted items should be fully understood before moving forward. Also, page 102 in the OCS 2007 Planning Guide goes into some detail about the specific requirement of a Public IP address assigned directly to a physical interface on the Edge Server. This is not simply a ‘recommendation’ and has been documented in multiple blogs and forum discussions.

Network Interfaces

The same logic applies to the assignment of network interface cards and IP subnets as well. The absolute bare minimum number of NICs on an Edge Server is two. All of the best practice recommendations throughout the deployment guides define an internal and external interface for a server deployed in a perimeter network between 2 firewalls, an external perimeter firewall and internal perimeter firewall:

The diagram below outlines this topology along with the often misunderstood Reverse Proxy rule which is shown on a completely seperate physical server than the Edge Server:

But since only one public IP addresses is required for the A/V role, and not for the Access Edge or Web Conferencing roles, an additional network interface can be added to the Edge Server to Route to the public IP and NAT the two private IP addresses. If an the external firewall does not have dedicated ports for routing traffic then this configuration can allow for only the A/V Server interface to be connected outside the firewall and not all three Edge Server roles. This is a less secure approach but many smaller environments may not have the ability to directly route public IP addresses through the firewall and will need to connect to the Edge Server directly to the Internet; this configuration can help reduce the attack surface.

One final note I’d like to add about the configuration above is that in a server-class system it’s routine to have a couple dual-port network interface cards so using all four interfaces is probably best from a performance standpoint, as well as potentially side-stepping any other undocumented problems that might arise from services sharing an interface. There are many possible configurations in even a consolidated topology, but it seems that the more resources (both physical and virtual) which can be dedicated to the Edge server, the better.

3-Leg Perimeter (DMZ) Configuration

Let’s say for the sake of argument you have a simpler design of a DMZ network ‘hanging’ off of a single firewall appliance or ISA server in a 3-Leg configuration and you want to deploy a consolidated OCS Edge server with a single interface. On paper this would appear to be possible if assigning IP addresses to the Internal Interface and Access Edge Server in the same subnet and then use NAT on the firewall to publish the Access Edge IP address. Well, I tried this in a pilot rollout and had connectivity working in Windows Server 2003 for all required traffic but OCS would simply fail to correctly pass connections from external client onto the internal Front-End server(s). So the second important lesson is that the Edge Server must have separate Internal and External interfaces.

Given these parameters, here are two choices for valid configurations which are driven by the IP subnet used in the current perimeter network:

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

Perimeter Network uses Private IP Addresses

In this scenario three separate network interfaces are needed on the Edge Server because of two conflicting requirements: (1) the need for separate physical internal and external interfaces, and (2) the use of two different IP subnets between the three external Edge Server roles.

Perimeter Network uses Public IP Addresses

1. ISA Server Network Relationships
   1. Route relationship between the External and Perimeter Networks
   2. NAT relationship between the Internal and Perimeter Networks
   3. NAT relationship between the Internal and External Networks.

1. Edge Server Network Interfaces
   1. NIC1 (Internal) routed directly to the internal network (bypassing ISA Server)
      1. Assign IP Addresses from existing private subnet
      2. Assign to Edge Internal Interface
   1. NIC2 (External) routed to ISA Server
      1. Assign three IP Addresses from existing public subnet
      2. Assign to Access Edge, Edge Web Conferencing, and Edge A/V Servers

If the current Perimeter network uses public IP addresses and 3 addresses can be spared, then a consolidated Edge Server can be deployed with just two interfaces, placing three public IP addresses in the same subnet on the External interface.

Certificates

To take this one-to-one theme a step further, Certificates should also be a dedicated to each service. The deployment guide mentions in a couple spots that the A/V Edge Server does not require a certificate, and wildcard certificates are currently not supported in OCS. Special attention should also be paid to the Subject Alternative Name field of certificates and how OCS uses that information, and how ISA doesn’t!

Below is an outline of how the certificates can be deployed:

• Edge Server
  • Internal Interface
    • Issued by internal Windows Enterprise CA
    • Subject Name is the server’s FQDN (e.g. ocsedge.internal.contoso.com)
  • Access Edge Server
    • Issued by trusted third-party certificate authority
    • Subject Name is the FQDN used by the client to connect (e.g. sip.contoso.com)
  • Web Conferencing Edge Server
    • Issued by trusted third-party certificate authority
    • Subject Name is unique FQDN (e.g. webconf.contoso.com)
  • A/V Authentication Edge Server
    • Issued by either internal Windows Enterprise CA (recommended) or trusted third-party certificate authority
    • Subject Name is unique FQDN (e.g. av.contoso.com)

• ISA Server Reverse Proxy
  • Internal Communications (OCS to ISA)
    • Issued by internal Windows Enterprise CA during Front-End deployment
    • Subject Name is the server’s FQDN (e.g. ocsfe1.internal.contoso.com)
  • External Communications (ISA to external client)
    • Issued by trusted third-party certificate authority
    • Subject Name is the external Web Farm FQDN (e.g. abs.contoso.com)

OCS Reverse Proxy with ISA 2006

Using ISA Server 2006 we need to create a publish a web site rule to allow external clients access to address book and meeting information which is hosted on the internal Standard or Enterprise server via the IIS Default Web Site. Following the instructions under section 2.1 of the Edge deployment guide can be a little tricky at first, but makes much more sense once a few specifics are more clearly understood.

The paragraph below is very confusing as it’s actually referring to two different certificates but reads like they are talking about just one:

Request and Configure a Certificate for Your Reverse HTTP Proxy

The root certification authority (CA) certificate for the CA that issued the server certificate on the Web server (the IIS server running your Office Communications Server Web components) needs to be installed on the server running ISA Server 2006. This certificate should match the published FQDN of the external Web farm where you are hosting meeting content and Address Book files.

The first statement basically says that you need to export the root CA certificate from your internal CA and import it into the Trusted Root Certification Authorities store on the ISA computer; simple enough. But the second sentence is now talking about a second certificate that should be requested from a third-party CA and will be used by external clients to connect to ISA via the published External Web Farm FQDN. What this ‘Web Farm" FQDN actually refers to is the external name that clients will use to connect to the IIS web site which is running on the internal OCS front-end server. This is NOT the FQDN used by clients to connect to the Access Edge, A/V service, or Web Conferencing service. In this example I will use abs.domain.com as the external FQDN, which will be configured in the OCS Edge deployment wizard and is part of the in-band configuration information to is passed to the external client once it makes a connection to the Access Edge service.

So to summarize that, the internally issued certificate which is assigned to the Front-End server’s default web site will be trusted by the ISA Server, and a second third-party certificate needs to be installed on the ISA Server in order to assign to the web listener for the external client to accept. ISA will terminate the connection from the requesting external client using one certificate and then create a second connection (using the other certificate) to the internal web site, essentially bridging the entire connection.

And if it’s not completely clear by looking at the first diagram in this article, then let me restate the obvious: the Reverse Proxy is not configured on the Edge Server itself, it’s simply a way to allow external users access to a web site running on the internal OCS server. Installing ISA on the Edge Server for this rule is not advisable (and probably not even possible; I can’t imagine even attempting to host both ISA and OCS on the same physical server!)

Once these important points are understood then working through the rest of the deployment guide should be pretty straight-forward. The resulting ISA publishing rule and web listener configuration would look something like this:

Update: Microsoft has recently released a white paper on how to design a perimeter network with OCS 2007 in mind. I haven’t had a chance to read the entire document yet but it includes a number of scenarios with detailed diagrams and IP addressing examples.