Tuesday, March 4, 2014

Meet URL Gives 404 error

I was recently at a company that did a big switchover from Lync 2010 to 2013.  The new environment consisted of 3 Enterprise Edition front-end servers with an F5 load balancer taking care of web services load balancing.

On the first business day of full Lync 2013 operations, some people were complaining they could not join meetings.  When some users clicked on the Join Lync Meeting link in the email, they were greeted with a 404 - File or directory not found error in IE.  If they tried several times, eventually they got in.  

Further analysis showed that one specific front-end server was serving up the 404 errors, while the others were working fine.  Thanks to the F5, we were able to easily remove that server from the load-balanced pool while we troubleshooted (troubleshot?) the problem. 

The first thing to note about troubleshooting issues with the meet URL on an Enterprise Edition pool is that you can't connect directly to a specific server in a pool and expect to get the proper meeting join experience.  For example, if your meet URL is meet.contoso.com and your Lync pool members are FE01.contoso.com, FE02.contoso.com etc, you would normally connect to a meeting via something like https://meet.contoso.com/user.name/FY3DFSE4.  You can't troubleshoot issues with a specific server by connecting to https://FE01.contoso.com/user.name/FY3DFSE4.  You'll get a 404 error, thanks to the way the URL Rewrite module processes URLs. 

To get around this, you need to add a temporary HOSTS entry to your testing workstation for meet.contoso.com pointing to the server having the issue. This will bypass the load balancer and allow you to connect directly to the server you want to test.

Back to the problem....

After setting my HOSTS file to point directly to the "bad" server, I found I could browse to https://meet.contoso.com successfully, but not to a specific meeting like https://meet.contoso.com/user.name/FY3DFSE4, which threw a 404.  Event logs didn't show anything wrong. 

I'll spare you the hours of dead ends I tried and just give you the solution (because that's why you're here, right?)

I went to Control Panel and removed the IIS URL Rewrite Module 2.  Then I re-ran Lync setup via the Lync 2013 Deployment Wizard, which re-added the URL Rewrite Module and reset the default URL rewrite rules Lync put in place.  All this was done without reboots or service interruption.  As soon as Lync setup completed, meeting joins happened without error. 

So, it appears that something went wrong with one or more of the URL rewrite rules, which wasn't cleaned up by simply re-running Lync setup, or Enable-CSComputer, which was things other people suggested in various places I looked. 

I hope this helps others who are having this issue.

5 comments:

  1. Hi Ken, I am unable to use lyncdiscover for mobility, full details of my problem is here: http://social.technet.microsoft.com/Forums/en-US/ab8a8ac8-85ce-4fe2-adf5-5114e77836ba/error-on-lync-discover-test?forum=ocsmanagement please can you have a look and give me some troubleshooting steps? Thank you.

    ReplyDelete
  2. Glad I found this blog. Getting ready to upgrade our OCS 2007 system to Lync 2013. I do have one question though. You mention in many entries, as well as the beginning of this one, that you have Enterprise Edition front-end servers. Everything I read indicates that there is no longer different editions of the server software. Just different levels of client CALs. Can you elaborate on that?

    ReplyDelete
    Replies
    1. Hey Chuck,
      There are two editions of Lync, Standard and Enterprise. Standard is a completely self-contained server suitable to up to 5000 users. Enterprise pools can contain up to 12 servers and support up to 80,000 users. In terms of licensing, there is no price difference between Standard and Enterprise server CALs, so that's probably what you're thinking.

      Ken

      Delete
  3. Thank you so much for posting the solution - It worked and solved the problem. I was going crazy over this one.

    ReplyDelete

Note: Only a member of this blog may post a comment.