Reverse Proxy – A virtual OCS Edge Role to provide three practical solutions

What is Reverse Proxy?

Reverse proxy is a general concept which helps us to publish internal FQDNs to the external world (internet).

Role of Reverse Proxy in OCS environment!

We use reverse proxy to extend following three basic functionalities to the external users (internal users logged in from the internet).

•       Meeting content downloads during Web Conferencing (Live Meeting).

•       Expansion of Distribution List (DL).

•       Address book download.

External users will not be getting above mentioned services if we don’t have reverse proxy configured.

How to configure a Reverse Proxy?

“Configure a Reverse Proxy“ section of the Edge server deployment guide talks about how to configure a reverse proxy. You can download this document from the link http://www.contoso.com/downloads/details.aspx?FamilyID=ED45B74E-00C4-40D2-ABEE-216CE50F5AD2&displaylang=en .

Placement of a Reverse Proxy.

Following are the over all steps to configure a Reverse Proxy for OCS.

1.   1. We need to ensure following things before deploying a Reverse Proxy.

1. Internal users can login to the IM.
2.  Internal users should be able to download the Address Book.
3.  They should be able to expand the DL.
4.  They should be able to download the meeting content.
5.  External users should be able to login through OC2k7 (You need to deploy an Access Edge Server for allow users to login from internet).

2.    2. Get a FQDN registered on the Public DNS Server:  This FQDN will be used as an external web farm. The external clients will use this FQDN in order to download the address book, Meeting content and to expand the DL. This FQDN and corresponding IP address would be assigned to the Proxy device which will be used to publish the internal web farm.

3.    3. Identify the HW/SW for Proxy server: We can use any proxy device which supports web server publishing with SSL Bridging.  Note:  We don’t recommend SSL tunneling.

4.    4. Prepare the Network Adapter on the Proxy server (assuming you have ISA 2006 as a proxy device!).

a.    Install two NICs.

b.    One NIC should have the Private IP Address, the second should have the Public IP Address (NATING can also be done).

c.    The internal NIC should be routable to the internal network

d.    The External NIC should be routable to the external network

e.    Configure the internal DNS Servers on the internal NIC, External DNS   Servers on the external NIC

Note: You can configure both NICs on the same interface but it is recommended to have physical separation of the NIC for better performance.

5. Request and configure a cert for SSL:
   1. The Root CA of the CA that issued certificate on the web component server needs to be present on the ISA server.
   2.  The Certificate subject name should match the published FQDN of the external web farm.
   3. The external FQDN should be the subject name and the first DNS name in the SAN field of the certificate configured on the default web site of the web component server.
   4. ISA 2006 doesn’t handle certificates with Subject Alternate Names.

Note: If you are using ISA 2006 as a proxy device then the external FQDN should be present as subject name of the certificate which is configured on the default web site of the web component server. ISA 2006 has problem reading SAN DNS names. ISA 2006 sp1 has addressed the issue. Service pack 1 of ISA 2006 is scheduled to be released in few weeks, after that you can have external FQDN as one if the DNS names of SAN.

6.    6. Create a Web Server publishing rule: As per the deployment guide (under the section “Configure a Reverse Proxy”).

7.    7. Create SSL bridging: As per the deployment guide (under the section “Configure a Reverse Proxy”).

8.    8. Verify that you can access the external site from internet:

Open a Web browser from the external client, and then in the Address bar, type the URLs that are used by clients to access the Address Book files and the portal site for Web conferencing.

•        For Address Book Server type a URL similar to the following: https://externalwebfarmFQDN/abs/ext  where externalwebfarmFQDN is the external FQDN of the Web farm that hosts Address Book server files. User should receive an HTTP challenge, because directory security on the Address Book Server folder is configured to Microsoft Windows® authentication by default. (Make sure you can download the address book file by browsing the url https://externalwebfarmFQDN/Abs/Int/Handler/FileName.lsabs )

•        For Web conferencing, type a URL similar to the following: https://externalwebfarmFQDN/conf/ext/Tshoot.html where externalwebfarmFQDN is the external FQDN of the Web farm that hosts meeting content. This URL should display the troubleshooting page for Web conferencing.

•        To access the Group Expansion virtual server, enter the following URL in the address bar of a local Web browser on the Communications Server 2007 server:

https://externalwebfarmFQDN/GroupExpansion/Int/Service.asmx

How does an external client download address book?

External client gets external URL (absExternalServerUrl) to download address book during login process.

External client tires to download the address book using absExternalServerUrl.

The request goes to the Reverse Proxy device (The proxy server is already configured with the external URL).

Reverse proxy has corresponding web publishing rule to get the address book file from the web component server.

The Web component server processes the request of reverse proxy device and makes address book file available to it.

Troubleshooting Reverse Proxy issue:

It’s time to troubleshoot reverse proxy issue when an external user can’t download address book or meeting content, or if they can’t expand DL.

Either we can start troubleshooting from the external client or the web component server. I am going to discuss the first option as that makes more sense to me. I’d follow following steps in order to troubleshoot the reverse proxy issue.

a)   a) Check the communicator logs: Get the uccp log from MOC 2007 and see if external client have external URLs set or not. See how to get the communicator logs.

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="010000007058C404C79C3E7813EDF4A6", srand="7D99A094", snum="3", opaque="319A87FA", qop="auth", targetname="TUK-LSXDR-01.redmond.corp.contoso.com", realm="SIP Communications Service"

Contact: <sip:sin-ocpool-01.southpacific.corp.contoso.com:5061;transport=tls;ms-fe=SIN-OCIM-03.southpacific.corp.contoso.com>

Content-Length: 3795

From: "Ram Ojha"<sip:ramo@contoso.com>;tag=b8fea7b98e;epid=f8660cb645

To: <sip:ramo@contoso.com>;tag=CA540F64

Call-ID: 717f7c7b0cac4b8089d8ddc87efa07f9

CSeq: 1 SUBSCRIBE

Via: SIP/2.0/TLS 192.168.5.100:2533;received=122.167.27.138;ms-received-port=2533;ms-received-cid=7C2A6600

Expires: 0

Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xml

Event: vnd-microsoft-provisioning-v2

subscription-state: terminated;expires=0

ms-piggyback-cseq: 1

Supported: ms-piggyback-first-notify

Record-Route: <sip:TUK-LSXDR-01.redmond.corp.contoso.com:5061;transport=tls;lr;received=157.54.84.54;ms-received-cid=798C0003>

Record-Route: <sip:sipalt.contoso.com:443;transport=tls;lr;ms-route-sig=gt96TDgm3mZjXFoBJJonRmXZB2c2izP6ko_Z3YmAAA>

<provisionGroupList xmlns="http://schemas.Microsoft.com/2006/09/sip/provisiongrouplist-notification">

<provisionGroup name="ServerConfiguration" >

<absInternalServerUrl>https://sin-ocpool-01.southpacific.corp.contoso.com/Abs/Int/Handler</absInternalServerUrl>

<absExternalServerUrl>https://lslm21.meet.contoso.com/Abs/Ext/Handler</absExternalServerUrl>

<ucPC2PCAVEncryption>RequireEncryption</ucPC2PCAVEncryption>

<organization>Corporation</organization>

<consoleDownloadInternalUrl>http://r.office.microsoft.com/r/rlidOCS?clid=1033&amp;p1=livemeeting</consoleDownloadInternalUrl>

<consoleDownloadExternalUrl>http://r.office.Microsoft.com/r/rlidOCS?clid=1033&amp;p1=livemeeting</consoleDownloadExternalUrl>

<helpdeskInternalUrl>http://r.office.Microsoft.com/r/rlidLiveMeeting?p1=12&amp;p2=en_us&amp;p3=LMInfo&amp;p4=supportserver</helpdeskInternalUrl>

<helpdeskExternalUrl>http://r.office.Microsoft.com/r/rlidLiveMeeting?p1=12&amp;p2=en_us&amp;p3=LMInfo&amp;p4=supportserver</helpdeskExternalUrl>

<dlxInternalUrl>https://sin-ocpool-01.southpacific.corp.Microsoft.com/GroupExpansion/Int/service.asmx</dlxInternalUrl>

<dlxExternalUrl>https://lslm21.meet.contoso.com/GroupExpansion/Ext/service.asmx</dlxExternalUrl>

<dlxEnabled>true</dlxEnabled>

 b)    Check the logs at Proxy device: After verifying the above step now its turn to check if you can see the relevant log at the proxy device or not! Ensure that you can see the log which proves that the external client is hitting at the right URL.

c)    c) Check the IIS logs at the web component server(s): Once we verified that the external client request is reaching to the proxy device, ensure that the proxy device is reaching the web component server in order to serve the external clients.