In my current job, I have been using Federation connections for many Lync meetings. My meetings include internal company participants and external participants that are Federated. I love having Lync meetings, and just making Lync phone calls to external users. Presence, Instant Messaging, Desktop and Application sharing and Audio and Video connects all work perfectly.
I was tasked with making sure that we can add external anonymous users. Of course, that should not be an issue. However, during testing, I found that there were many issues. I was able to get some anonymous users connected and send and receive Instant Messages. Well, it appeared to work, but there seemed to be some intermittent issues.
Anonymous users were complaining that they had to try multiple times to make the connection to the Lync conference and that they kept losing their connections. After doing some extensive testing, I was finally able to get some captures of the errors. Anonymous users were receiving errors like the one below when trying to join as a guest:
The connection to the server was lost. Check your network connection and try again.
After multiple retries, they were able to join the meeting. However, they were not able to view the shared content. After a short time, they were no longer able to participate in the IM session, either. You can see, from the reproduction of the error, that the first message was fine, but the second message that was sent a couple of minutes later failed. Obviously, this is not by design.
Now, I fully admit that I am sick person because I was excited to get these screen shots and to have a chance to troubleshoot this issue.
- Check the Conferencing Policy. Obviously, the meeting organizer needs to be assigned a policy that allows anonymous users. I verified that that the policy allowed anonymous users and allowed application and desktop sharing.
- Cuss at the computer. Cussing is a big part of how I work as an administrator when troubleshooting.
Try to connect to the meeting using LWA (like an anonymous user) from the same computer where the meeting is initiated. In this case, I was able to reproduce the issue on the internal network. I copied the URL from my meeting to a browser window on my desktop, i.e. https://meet.infrastructurehelp.com/russ.kaufmann/AMEGYW4M and then added the suffix of ?sl=1 to the end of it to force the connection via the browser. The URL used looks like this: https://meet.infrastructurehelp.com/russ.kaufmann/AMEGYW4M?sl=1
If you don’t add the suffix, then the Lync client will try to connect to the meeting, and the goal here is to test LWA, not the Lync client.
In this case, the browser connected properly, initially. When clicking the link to Join the meeting using your web browser, it would take me to the next screen where I could select the radio button to Join as a guest.
The same issue appeared and the connection failed. If this had worked, I would have tried using another computer inside the network to see if I could reproduce the issue there as well.
At this point, this looked like an issue with a hardware load balancer. I jumped to this conclusion because I could establish a connection (intermittently) and then would see a failure when trying to send subsequent IMs (which sounds to me like a reconnection to the same session).
Now, I needed to verify that it was actually an issue with the hardware load balancer.
I used a second computer and configured the hosts file for the meet.infrastructurehelp.com address pointing it to a single server in the pool rather than the load balancer’s IP address, and I also did the same with the pool name and set it up in the hosts file as well. Remember, you need to use FQDNs.
Once the hosts file was set up, I retested the LWA connection and it worked like a charm. No issues. I was able to share apps, share the desktop, and IM for an extended length of time. It was rock solid.
So, how did I know for sure it wasn’t a problem with one of the front-end servers in the pool instead of the load balancer? Easy, I just repeated the process for each of the front-end servers by setting the IP for each one in the hosts file and testing the connectivity. Every single front-end worked wonderfully.
Once I removed the hosts file entries, and went back to using the load balancer, it was easy to reproduce the problem. Yep, definitely the hardware load balancer.
Of course, every load balancer is a bit different. In this case, following the guidance of the vendor, the load balancer was reconfigured and the issue was resolved.
Another happy ending in the world of troubleshooting Lync.