Publishing Office Communication Server and Communicator Web Access with UAG

Publishing Office Communication Server (OCS) and Communicator Web Access (CWA) with UAG has been a source of confusion for some UAG customers, mostly because these products offer a wide range of functionality. Some of this is pretty simple to configure, and some takes more planning.

When planning OCS publishing with UAG, one must take into consideration the fact that OCS has many features, functions and roles. Not all of them were planned with publishing in-mind, and UAG was not designed to publish all the features either. Essentially, UAG includes a special template for Communicator Web Access (CWA) 2007, and for other features, UAG does not include built-in functionality, and something “else” needs to be used.

Virtually any firewall product in the market can be used to publish internal servers to the outside world. Some companies may refer to this as “port forwarding” or “Reverse-proxying”, or even simply as “routing”. At Microsoft, we divide this into sort of functionality into two categories. The 1^st is “Web publishing”, in which an edge device gives computers on the internet access to web servers inside the organizational network. The 2^nd is “Server publishing”, in which the access is to services that are not necessarily web services (for example, RDP access). The difference is that web services are a narrow type of service, which is very clearly defined. This clear definition allows us to offer additional features that go beyond just moving the packets from one “side” to the other. For example, with Web Publishing, we can do more advanced content inspection, and can block certain file-types from being transferred.

If you purchased UAG to publish certain applications, good chance you’d prefer not to purchase any additional devices to publish the non-web OCS features, and the good news is that UAG does, in fact, include something else…TMG! If you read your documentation carefully or ever spoken to Microsoft Customer Support, you are probably aware that trying to use the UAG server for “other” things is not supported. You’re not supposed to tack-on an additional website on the IIS that’s on UAG to publish your cafeteria’s lunch menu, or use the SQL that’s there to store your inventory database. We do, however, allow for a certain, limited list of things to be done with TMG, as stated here in the support boundaries for uag (https://technet.microsoft.com/en-us/library/ee522953.aspx). This list includes publishing OCS features other than CWA.

When you publish something with TMG, you select whether you want to use Web Publishing or Server publishing by the type of task you select in the task list. There are actually some more variations for types of publishing, but for our purposes, the “Publish Non-Web Server” is the relevant one for OCS’s features. Using this wizard will allow you to specify which ports you need to publish, which depends on the type of service you need to publish. For example, you may need to publish port 5063 for incoming SIP listening requests or port 8057 for direct PSOM connections from Live Meeting clients.

I will not cover this in high detail here, as this blog is about UAG, but you can read more about server publishing in one of many books that are available about TMG, such as this one. For more information about ports used by OCS, refer to this article.

To publish CWA itself using UAG, what you need to know is that CWA needs to be published as a non-HAT application (a.k.a AAM-Like application). If you are not familiar with HAT and what it does, you might want to take a peek at this blog post. Like SharePoint, CWA cannot be published with the HAT mechanism, and requires its own public hostname, which brings the following considerations into play:

1. The public hostname needs to be based on the same public domain you are using for your UAG trunk. For example, if your trunk is published as https://uag.contoso.com, then you need to use something like https://*.contoso.com for CWA.

2. If your UAG trunk is an HTTPS trunk, it has to have a certificate, and that certificate needs to certify both the trunk’s hostname and the CWA’s. Most UAG customers use a wildcard certificate for this, and others prefer a more economic SAN certificate. I should mention that wildcard certs don’t have to cost an arm and a leg. Some websites like https://www.sslcatacombnetworking.com and https://www.rapidssl.com offer them for as low as $199 a year.

3. Both hostnames need to be publicly resolvable to the UAG trunk’s external IP. This is not absolutely mandatory, as you can use static HOSTS file entries on your client computer, but if your intended audience is the general public, setting up the DNS correctly is very important.

4. The authentication settings on the CWA server need to be adjusted to allow UAG to perform Single-Sign-On. With UAG, you need to publish the “External” CWA site, and use custom authentication, as described in the lab guide https://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=0e21123a-8452-4b25-8cde-57f750cd7803

So, the 1^st step is to choose the name that you want to use. The 2^nd is changing your certificate, if you are using an HTTPS trunk and your current cert is not a SAN or Wildcard cert. The 3^rd step is to add the appropriate host name to your domain’s public DNS server. The 4^th step is to adjust the CWA site settings, or re-publish it according to the specifics in the above-mentioned guide. Once this is done, you can start the UAG wizard.

On the UAG application wizard, the key element is setting the public host name in step 5 of the wizard:

Setting the internal website is also important, because that tells UAG with which internal server it talks to. That server has to be resolvable and reachable on the appropriate ports. This part is no different than publishing other applications, but some users are iffy about it still. In case the publishing does not work, one of the first troubleshooting steps would be to try to access the server directly from the UAG server (open a browser on the UAG server, and browse to https://CWA01/quicksignin, in our case). If it does not work from UAG, it cannot work through UAG.

Blog Post written by Ben Ari

Comments

• Anonymous
  December 30, 2010
  The comment has been removed