As I mentioned in my previous post: https://blog.terenceluk.com/2011/01/quick-note-about-changes-to-how-lync.html the GUI of Lync Server 2010’s Control Panel only allows you to put in a domain and not a path after the URL. In OCS 2007 R2, we were able to modify the URL to include sub paths thus enabling us to reuse the same domain (i.e. downloads.someDomain.com) similar to the following in a OCS 2007 R1 and R2 coexistence scenario:
OCS 2007 R1: https://someName.someDomain.com/Abs/Ext/Handler
OCS 2007 R2: https://someName.someDomain.com/R2/Abs/Ext/Handler
Now with Lync Server 2010, when we browse to the External web services section, we are only allowed to put in a URL without a path:
One of the ways I found to get around this without setting up a new sub domain is to change the port number that is published for the external web services. As shown in the above screenshot, the publish ports are configurable and therefore can be changed to whatever port you would like it to be. The default is 443 and we can see this reflected in our Lync client’s Configuration Information:
The thought I had was whether I could simply change the published port number within the external web services field to push out these settings to the Lync client and then modify the ISA server to accept connections from this port. After being able to publish the port but had problems with some of the settings in my publishing rule, I finally got it going. The following outlines the steps on how to do this:
The first step is to change the HTTPS port for the external web services:
For the purpose of this example, I choose port 9999.
Once you’ve changed the port, proceed with publishing your topology so that your client will receive the new settings. It took me a few sign out and sign in attempts to get the new settings:
Note that the external URLs now have the port listed as “:9999”.
From here, what you need to do is follow the steps outlined in the following TechNet article: Configure Web Publishing Rules for a Single Internal Pool (http://technet.microsoft.com/en-us/library/gg429712.aspx). The only changes you need to make is the web listener port where you’re supposed swap out the port 443 for port 9999.
I won’t include every screenshot from every tab but here are what some of the tabs will look like for your web publishing rule in ISA:
——————————————————————————————————————————————————————
Note that in OCS 2007 R2, you did not have to check the Forward the original host header instead of the actual one (specified in the Internal site name field) but for Lync Server 2010, if you don’t, you will most likely get a lot of Unauthorized 401 errors when trying to download the address book via the /abs/handler directory (i.e. /abs/handler/F-0e59.lsabs). The errors in ISA/TMG would look something like this:
Allowed Connection
RP01 1/22/2011 6:50:32 PM
Log type: Web Proxy (Reverse)
Status: 401 Unauthorized
Rule: Lync WEB Downloads Rule
Source: External (198.337.39.11)
Destination: (lync01.domain.com 172.16.1.40:4443)
Request: GET http://rp01.domain.com/abs/handler/F-0e59.lsabs
Filter information: Req ID: 07fa7f4c; Compression: client=No, server=No, compress rate=0% decompress rate=0%, Range=0-0
Protocol: https
User: anonymous
- Additional information
- Client agent: OC/4.0.7577.0 (Microsoft Lync 2010)
- Object source: Internet (Source is the Internet. Object was added to the cache.)
- Cache info: 0x40020040 (Request includes the RANGE header. Response includes the CACHE-CONTROL: PRIVATE header. Response should not be cached.)
- Processing time: 281 ms
- MIME type:
——————————————————————————————————————————————————————
During the configuration of your web publishing rule, you’ll also need to configure a new listener. The following shows what the web listener should look like:
Note that the Enable HTTP connections on port 9999 isn’t required. I just put it in during the troubleshooting.
Once you’ve completed configuring the web publishing rule and placed and applied the settings in ISA:
… your Lync client should now be able to download the address book when connected through edge. Hope this helps anyone out there that needs a quick solution to get this going without having to register a new sub domain and obtain a new public certificate.
