External Live Meeting Only with OCS

One of the biggest cost-saving benefits of Office Communications Server 2007 has been the integrated Web Conferencing features, a.k.a. Live Meeting. Many companies currently pay for off-site host conferencing services like Microsoft’s own hosted Live Meeting, or WebEx just to name a few. In the same way that R2’s Dial-In Conferencing can reduce costs by eliminating the need for a hosted phone bridge service, all versions of OCS can offer the same cost-cutting advantages by bringing Live Meeting services in house.

One example are organizations who already have a limited LCS deployment in-house but due to various internal political issues are not able to deploy IM services to the company as a whole, either inside or out. With the addition of a simple, yet robust OCS deployment it is possible to configure OCS to support only Web Conferencing for external users.

The approach used for a specific OCS 2007 R2 deployment included:

Internal Deployment

The internal deployment follows the standard installation and configuration steps; nothing out of the ordinary is required here. The basic SRV and A DNS records are setup to support Automatic Configuration and a pool record (using the IP address of the Front-End server itself). Certificate deployment is standard. If migrating users from LCS then make sure to install a certificate on the LCS server (if not already deployed) so that MTLS server-to-server communications will work correctly between LCS and OCS services.

Once everything is installed then you will need to configure the Web Conferencing policies to allow users rights to start conferences and (if desired) allow anonymous users to join.

The one major caveat during server configuration is to make sure and do not leave the External Web Farm FQDN blank during the Enterprise Pool creation (or Standard Edition server configuration). Even though there will not be a reverse proxy configured and thus no connectivity into the internal Web Components IIS site, and thus no real need for a defined external URL, it wont work. Once everything is deployed external clients will simply not be able to login to Live Meeting as the lack of a defined external Web Farm FQDN causes OCS to ‘give up’ and basically not allow external Web Conferencing connections. External Communicator sign-in and IM/Presence will work, just not Live Meeting. In this example the internal FQDN was simply duplicated into the external field. You could probably put any string in there, valid or not. Just as long as it is NOT blank.

External Deployment

As with anything in OCS, the external user access is where it can get tricky. Because this specific client was licensed for only Standard Edition a single consolidated Edge server was deployed, even though the A/V roles will not be utilized. This was done for two reasons, (1) licensing, and (2) future expansion. If they want to later open up external Communicator access and support features like Desktop Sharing, even though A/V sessions would still not be officially supported, the A/V functionality would need to be in place to get Desktop Sharing to work between internal and external clients. This point is worth reiterating. Desktop Sharing works via media communications.

The R2 Technical Reference details the Desktop Sharing Architecture explains that because the RDP sessions inherently run into the same challenges as media communications Microsoft decided to use A/V functionality in OCS, which already solved the previous issue. So basically Desktop Sharing is an RDP (Remote Desktop Protocol) session over SRTP (Secure Real-Time Protocol). The main difference is that Desktop Sharing uses TCP while standard media typically uses UDP, but the ports are the same.

But now back to our scenario; we only want Live Meeting supported externally, no audio, video, Communicator sign-in, and thus no Desktop Sharing. The reason I point this out is that when testing a deployment like this it would be a mistake to use Desktop Sharing to validate connectivity when it works completely different then Web Conferencing does.

First off, with any Edge deployment the firewall rules are most important. Let us assume a best practice deployment with the following IP subnetworks:

And here are the IP addresses and FQDNs to be used throughout this article:

It is important to point out here that the Access Edge FQDN has a specific requirement depending on if SRV records are used/supported and if anonymous access is desired for external Live Meeting clients.

• If the _sip._tls.domain.com SRV record is published externally, then the Access Edge FQDN it points to can be named anything you want (within the same domain name). It is still best practice to use sip.domain.com but it does not have to be.
• If SRV records are not supported by your external DNS server, then the Access Edge FQDN must be either sip.domain.com or sipexternal.domain.com.

This requirement is related to supporting Live Meeting connections from anonymous users which are not OCS-enabled users in your organization. If only corporate users need to use Live Meeting externally, then you can still use any FQDN you like and then Manual Configuration must be set on the workstation so that the OC/LM clients can locate the Access Edge server. But any third-party that wishes to join a hosted Live Meeting can only be invited via the meet:sip: URL that is typically sent in an email.

This URL includes the SIP domain name of the meeting scheduler:

meet:sip:jschertz@domain.com;gruu;opaque=app:conf:focus:id:3e068dc431be4509d1c3bb7…

Participating Live Meeting clients will perform an initial SRV lookup against domain.com for the Access Edge FQDN, followed by a fallback A record lookup. Only the default sip, sipexternal, and sipinternal A records are checked for, so you can see here that having an Access Edge FQDN of ocs.domain.com without an SRV record pointing to it is not sufficient to support Automatic Lookup. This behavior is the same for both the Office Communicator and Live Meeting clients. Once the client successfully connects to the Access Edge role, whether or not any authentication is happening (OCS user vs. Anonymous user) the Web Conferencing FQDN is passed to the client in-band (e.g. webconf.domain.com).

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

Now on to the fun stuff. I have chopped down the Microsoft diagram to include only the communications we need to support external Live Meeting clients. The two inbound rules (4,6) from the Internet are pointing to the separate IP addresses for the Access Edge and Web Conferencing Edge. The internal communications (5,7) are all happening between the internal Front-End server and the perimeter Edge server.

Firewall Policy Rules:

Since the A/V Edge role is deployed as part of a consolidated Standard Edition server, it must be configured during setup or the wizard will not advance. Clearly there will be no external access to the A/V Edge and Authentication roles, so an internally-issued certificate will be fine here as the Access Edge and Web Conferencing roles would get third-party certificates (Entrust, Digicert, etc). The nice thing about this configuration is if a later pilot rollout of external A/V is requested all that is needed is a certificate and some firewall changes and everything is already set to go.

Testing

Once all the rules are setup and the Edge server is deployed and configured each can be tested via telnet. From the internal Front-End server you should be able to telnet to both ports 5061 and 8057 on the Edge’s internal IP. You can also perform the same test from the Edge server to 5061 on the internal Front-End server. Additionally any public host should be able to telnet to 443 on either the sip or webconf IP addresses to verify the external rules as well.

Connecting directly to the port via telnet will both confirm that the firewall rule is correctly defined and that the service is active and listening.

A failed connection to any of the ports would be pretty clear:

C:>telnet 10.1.1.100 5061

But a successful connection to either ports 5061 and 443 would not be as obvious as nothing appears to happen. The blinking cursor indicates a connection to the port; there is just no interaction:

C:>telnet 10.1.1.100 5061

Meanwhile a successful connection to the PSOM service on port 8057 at the Edge internal interface would at least spit out a few characters:

C:>telnet 10.1.1.100 8057

Internal Configuration

First verify if the External Web Farm FQDN needs to be populated or updated by checking the current value, which can be viewed (but not modified) from the OCS Management Console as shown below. If the External URL value needs to updated then follow the instructions in Appendix E of the OCS documentation.

Pool Properties > Web Components Properties > Address Book tab

By default web conferencing is not enabled in a fresh installation. There are a couple ways to turn it on, depending on if you want everyone in the organization to have the same features and permissions, or if you need to have separate groups of users with different policies.

The simplest approach is to just edit the Default Policy and enable Web conferencing and any other desired options.

Alternatively you can elect to choose from different set policies for each SIP-enabled user account. The built-in policies offer different levels of permissions but can each be customized, as well as removed or replaced by other new policies.

External Configuration

Now even though external Communicator support is not part of this deployment, user accounts must still be SIP-enabled in order to schedule and initiate Live Meeting sessions and thus invite attendees. If Communicator must still be blocked, then limiting the ability to install the Communicator application on corporate systems is one approach. Another would be configuring global policy settings to limit the types of communications (block IM, peer-to-peer audio, etc) in the client. Make sure to follow the standard post Edge deployment configuration by adding the Edge server settings in the various Global and Pool level properties

For this deployment all OCS features would be used internally, so only external user login was undesired. But In order to first allow access to Live Meeting externally the Edge Server properties must be configured to allow any external access. There is no way to allow for external access to Web Conferencing without also allowing external access, since the Live Meeting client must first connect to the Access Edge service to initiate a conferencing session.

Edge Server Properties > Access Methods

The next step is to enable rights on each user account for remote user access. This inherently also grants the user the ability to sign-in to Communicator remotely; these rights cannot be separated. So if only anonymous access to Live Meeting sessions is desired for all remote users, whether they are corporate employees or a third-party, then this step can be skipped. But since most deployments would want corporate users to be able to sign-in as themselves to conferences regardless of their location that permission must be enabled on each account.

User Account Properties > Communications Additional Options: