To provide a seamless experience for your staff working remotely outside the corporate LAN in addition to an Edge Server, OCS 2007 R2 (and R1) also requires a reverse proxy in your DMZ/perimeter network to publish your Web Components Server role (IIS) of the Front End Server. This is to provide a few things:
- Address book download (GAL search capabilities) in Office Communicator.
- Distribution group expansion within Office Communicator.
- Meeting content download during a web conference in Live Meeting and;
- Download of device firmware update for Office Communicator Phone Edition (OCPE – Tanjay) devices.
If the client applications (Office Communicator and Live Meeting) can’t retrieve these items, you will experience problems such as:
- The much maligned “Cannot synchronise corporate address book” error in Communicator.
- The inability to expand distribution groups in a users contact list in Communicator.
- PowerPoint presentations, whiteboards and any other uploaded content will not display in Live Meeting and;
- Any OCPE devices external to the corporate LAN won’t be able to get new firmware updates.
In addition to this, a reverse proxy would usually be required to publish other services such as Communicator Web Access, Outlook Web Access/App, SharePoint, etc. ISA Server 2006 is your best weapon of choice for this purpose, but the reverse proxy requirement for OCS can also be achieved using other firewall/web publishing devices you might have.
Today I’m going to focus on a neat trick you can utilise with ISA Server to use 1 less certificate, FQDN and IP address when publishing your OCS IIS directories by utilising an existing URL.
All the requirements and steps for setting up ISA Server are detailed in the Microsoft documentation. The focus of this post won’t be to go into the detail of how to configure rules and web listeners in ISA. I’ll assume you’re all cluey enough to get that bit sorted out. 
I’ll use publishing SharePoint with OCS as an example, but this could be adapted to be used with the other resources as listed above, depending on your publishing method.
Because we are specifying explicit URL paths to forward web requests to OCS, we can layer this on top of a rule that already forwards requests to the /* of your URL and use its FQDN as well. The end product should look like this:
The only requirement for this scenario is that the underlying URL must be using a web listener that supports No Authentication in the Authentication tab of the web listener. You can’t use a URL that is being published using ISA Server forms-based authentication or another type of authenticaiton, because OCS requires No Authentication to work.
Today I’ll go through the process of completing the following tasks:
- Changing your External Web Farm FQDN on your OCS pool to match the desired URL.
- Configuring your OCS web publishing rule to respond to requests on the new URL.
- Specifying explicit required paths on the new URL.
I recommend that you either test this configuration in a lab environment first or schedule an outage window to implement this as it may cause an interruption of service to the existing URL you’re utilising.
Changing your External Web Farm FQDN
Firstly, you’ll want to identify which FQDN you’re going to use for the OCS External Web Farm FQDN from your existing FQDNs published on ISA Server. Let’s say for example sharepoint.contoso.com.
- Log on to the Standard Edition server or Enterprise Edition server in the pool with an account that is a member of RTCUniversalServerAdmins group or has equivalent permissions
- Open a command-line prompt.
- Navigate to the \Program Files\Common Files\Microsoft Office Communications Server 2007 directory.
- To set the external URL for the Web farm, type the following command:
-
Lcscmd /web /action:updatepoolurls /externalwebfqdn:sharepoint.contoso.com /poolname:<poolname>
This will update the WMI parameters for the pool and allow OCS to respond to requests to the FQDN specified.
Configuring the OCS web publishing rule to respond to requests on the new URL
As you progress through the Web Publishing Rule Wizard as detailed in the documentation, you’ll need to configure the fields on the Public Name Details page with the FQDN of the existing service you’re going to utilise (SharePoint in our case).
Specify the path /Abs/* for now, we’ll specify more paths later.
Continue with configuration of the web publishing rule to the Select Web Listener page and select the web listener already configured for the FQDN you want to use.
Continue configuration as detailed in the documentation.
Specifying explicit required paths on the new URL
After you’ve created the web publishing rule for OCS, open the Properties dialog and select the Paths tab.
In addition to the /Abs/* path you added during creation, add the following additional paths for this web publishing rule:
/RequestHandler/*
/GroupExpansion/*
/DeviceUpdateFiles_Ext/*
/etc/*
Your paths should look like this (they might be in a different order, this is ok):
And the rule you have created for publishing SharePoint should look like this:
This rule then effectively becomes a “catch-all”, and must be ordered after the OCS publishing rule in your ISA Server firewall policy (as illustrated in the first image in this post).
By creating these two rules in ISA Server, we ensure that only requests from Office Communicator and Live Meeting to the explicit paths we have specified for OCS are proxied to your OCS 2007 R1/R2 pool/front end server, and all other requests are proxied to your SharePoint server (or whatever other service you choose).
This results in only utilising the one IP address, SSL certificate and FQDN, thus cutting down on costs and management.
Feel free to post any questions to the comments section.
- Justin
