I thought I would take a moment to explain how the internal certificates need to be configured on an OCS Edge Server and how the edge server needs to be specified within the OCS system as a whole - specifically in an environment where the OCS Edge servers are load balanced.

For some reason there seems to be a general misunderstanding as to how edge works for Remote Access/Federation and for WebConferencing (LiveMeeting).

I often get sites that have Remote Access, Federation & PIC working fine but they cannot get their LiveMeeting working externally - they get the ‘Live Meeting cannot connect to the meeting’ error.

There are a myriad of reasons why you may get this but there is one common reason that I keep coming across that’s affectively a misunderstanding as to how LiveMeeting works through edge servers - especially if the edge servers are load-balanced.

Consider this infrastructure for now.

You can download a bigger version here in PDF format.

This is the usual scenario where I get asked ‘Access Edge, federation & PIC works, but LiveMeeting won’t. It’s usually accompanied by some techy hair pulling and much anguish.

Let’s look at what the documentation says about the load-balancing port requirements for the internal edge interface of the servers.

Notice that only the ‘Access Edge Server’ and the ‘A/V Edge Server’ has a load-balancing requirement? This is important. You do not load-balance outgoing connections on LiveMeeting - they hit particular servers, not the load balanced address.

To see the significance of this we need to look into the set up a bit more. Let’s look at what the documentation says for the certificate requirements for the access-edge server’s internal interface.

Certificate Requirement for the Internal Interface of Edge Servers

Each Edge Server must have a certificate on the internal interface, between the perimeter network and the internal network. All three Edge Server services on that server share this certificate. The subject name of the certificate must match the internal FQDN of the Access Edge service of that Edge Server.

Now, the above seems to indicate that each edge server must have a certificate with a subject name that matches the server name. In our infrastructure example this would indicate that the subject names of the appropriate certificates would be:

EdgeServer1.deathstar.local

EdgeServer2.deathstar.local

Fine, let’s go with that for a few minutes.

Next, let’s look at the DNS requirements for the internal interface.

The important bit to note here is:

An internal DNS A record that resolves the internal FQDN of the Access Edge service array to the virtual IP (VIP) of the Access Edge service array on the internal load balancer.

This would indicate you also need a DNS entry for the load-balanced address. In our example scenario this would be:

OCSEdge.deathstar.local

So, a quick summary of where we are:

DNS

EdgeServer1.deathstar.local    ---> 10.1.1.1

EdgeServer2.deathstar.local    ---> 10.1.1.2

OCSEdge.deathstar.local        ---> 10.1.1.3 (Virtual Load Balanced Address)

Certificates

Server 1: CN=EdgeServer1.deathstar.local

Server 2: CN=EdgeServer2.deathstar.local

Make sense? Now, let’s have a look at how I’m finding a lot of systems have been configured - incorrectly.

Specifying the Edge Servers

Start the OCS admin tool and get the global properties of your forest.

Select the ‘Edge Servers’ tab. You’ll generally see something like this.

(Remember OCSEdge.deathstar.local is our load-balanced edge DNS).

Path for Federation

Next, select the ‘Federation’ tab. You’ll have something similar to this.

Next, we need to specify the meeting configuration on the pool. Get the properties of the Web Conferencing of either your Enterprise or Standard edition pool.

Select the ‘Web Conferencing Edge Server’ tab and you’ll see something like this.

Result

What’s the result of the above? Well, the general result is that nothing works. Access edge doesn’t, federation doesn’t and nor does LiveMeeeting.

Let’s look at the reasoning.

Certificate Requirements

Up the top we detailed the certificate requirements from the manuals as being:

EdgeServer1.deathstar.local

EdgeServer2.deathstar.local

Now, you may have spotted that these certificates do not have the load-balancing address of OCSEdge.deathstar.local in them - bingo, MTLS will fail. Instead, our certificates need to be as follows:

Server 1

Subject Name: EdgeServer1.deathstar.local

Subject Alternative Name: OCSEdge.Deathstar.local

Server 2

Subject Name: EdgeServer1.deathstar.local

Subject Alternative Name: OCSEdge.Deathstar.local

Quite a significant error. It is in the manuals to include the SAN but it’s buried away - to the point that I can’t find it at this minute.

If you want to see how to create a SAN Certificate, have a look at this article.

So, you create the appropriate certificates and install them on the edge servers - not forgetting that if the edge servers are standalone (which they should be) to install the root certificate as well.

Where are we now? Well, now you should find that remote access, federation, and A/V authentication now work... But you still get the pesky ‘can’t connect to LiveMeeting’ error... Again much techy anguish induced.

Why? Well, remember this bit?

Remember how I said connections to the Access Edge for Web Conferencing are not load-balanced? Typically, this is where people go wrong - the Edge Servers for web conferencing must be the server FQDN, not the load-balanced DNS.

Let’s look at each relevant tab and how they should be configured....

Global Properties - Edge Servers

Pull up the global properties and select the ‘Edge Servers’ tab. What we’re entering here is what servers are available to OCS - we’re not saying which to use for outgoing - this is an important distinction at this point.

Unfortunately you can’t quite see in the tab above what’s set, so let’s run through it:

Access Edge & Web Conferencing Servers

ocsedge.deathstar.local            -        Our load balanced DNS entry

edgeserver1.deathstar.local      -        Server 1

edgeserver2.deathstar.local     -        Server 2

A/V Edge Servers

ocsedge.deathstar.local            -        Our load balanced DNS entry

edgeserver1.deathstar.local      -        Server 1

edgeserver2.deathstar.local     -        Server 2

Next, select the ‘Federation’ tab.

Now this is the global default outgoing route for federation so we must specify the load-balanced DNS entry.

Pool & Front-End Properties

Next, get the properties of your pool.

For the A/V authentication service, make sure the load-balanced address for you A/V authentication service is selected.

Next, get the properties of the Web Conferencing, and select the ‘Web Conferencing Edge Server’ tab. This is the wrong setting.

Remember how I said you cannot load-balance connections to the edge for web-conferencing? We’ve entered the load-balanced address above - and it doesn’t work. What it should be is the FQDN of each individual edge server as shown below.

Note that the external FQDN can be the same as this is load balanced on the incoming.

Summary

Setting the certificates appropriately and ensuring that the entries for edge/AV and Web Conferencing are correct will go a long way to resolving your comms issues for the edge server.

It’s not as complex as it looks - unfortunately the documentation is not massively clear on the matter.

This article is more aimed at somebody fault-finding an existing installation - I’ll do another one detailing how to configure a new pool for edge access shortly.