Had been running a hectic project for the past 3 months and is now drawing close to the final stage to bid good bye. And part of the final stage, I’d to run some test cases on Lync Web App (aka Online Meeting) where the each user would be connecting within the Organization network and the other would be using a portable Internet dongle.

After the sending an Calendar Invite via Outlook to my another account, upon clicking on the invite link, my Internet Explorer shows 404 File or Directory Not Found. OK, another 1 of my favorite error code thrown by the web services. So, time to roll-out some sheelves and troubleshooting here I come!

First of all, I’d to test whether the web services is running fine within internally, this is something that I’d held on whenever running any test cases within Lync – MAKE SURE internal works, before even talking about external. So, by clicking the invite from the internal network, everything seems to be working fine, Lync Web App launched perfectly and all functions are working as expected. So now, here comes the tricky part, as I’m having a Director Role installed in the environment, almost all traffic hits the Director Role from the DMZ segment: Access Edge and the Reverse Proxy.

So before drilling into the details, these are the configurations that I’d in my environment:

===================================================================================

Public Certificates

  • Type: Unified Communications Certificates (1 CN with Multiple SAN)
  • FQDNs: sip.domain.com; meet.domain.com;dialin.domain.com and webconf.domain.com

Lync Server Topology Layout

FE Pool (192.168.1.2) <—> Director (192.168.1.1) <—> Access Edge & Reverse Proxy <—> Firewall <—> Internet

===================================================================================

I’d to rule out Access Edge being the culprit here as clicking on an Online Meeting invite basically comes from the Web Services part, which is the Front-End pool, proxied through the Director Role from the Reverse Proxy (oh, I almost forgot, the RP is a Forefront TMG 2010). So to isolate this matter, let’s try to manually typing in the URL from the IE’s address URL, but this time, I’ll tried accessing the Address Book Service virtual path (ABS) https://meet.domain.com/abs outcome a 404 File or Directory not found as well.

So I’d figure likely it could be a Publishing Rule issue as the RP is unable to locate the virtual directory that has been directed. So let’s take a look at my publishing policy for Lync Web Services:

1. Confirm the redirected port, when publishing Lync Web Services, the ports must be redirected to port 8080 for HTTP traffic and 4443 for HTTPS traffic

2. Next, is to confirm the publishing paths

3. Run the Test Rule

 

 

OK, the rule looks fine, but wait a minute! Basically what happen here is TMG validates across the certificate that has been assigned for this reverse publishing against the CN and also checks whether the Machine is online (using pathping) and returns the results as Pass. But wait a minute…sip.domain.com, that doesn’t sound right – there shouldn’t be any traffic with this FQDN that is coming into the RP, only meet.domain.com & dialin.domain.com. The sip.domain.com only travels to the Access Edge.

So to prove the theory, I’d make some changes on the publishing rule by switching the Address to meet.domain.com

 

 

 

 

 

 

 

 

 

 

 

 

And ran the Test Rule function

 

 

 

 

This time, the TMG shows me an error that the https://meet.domain.com:4443 has an error to it because it doesn’t match the certificate chain name. Although TMG supports SAN publishing but it strangely, the Test Rule doesn’t validate SAN names, hope that the TMG Product Team could fix this in the upcoming releases.

Test drive! Vroooom……….and Walla! The Lync Web App was able to be launched after the change.

Lesson learned:

  1. Make sure that the URL address entered is according to the published name
  2. Mapped the URL to the correct IP address
  3. If you’re using UCC certificates, make sure the SSL listener has all of the FQDNs in the CN and SANs
  4. Running the test against TMG Rule maybe a good practice, but with UCC in the picture, you may want to opt to use the OCS Remote Analyzer Tool