Microsoft Skype for Business Server 2015

Hello Renato, Glad to hear you got further along. Understanding mobile client flow, setting it up and then troubleshooting it can be tough so good luck!

My only advice at this point is to continue to do some research on how to properly set up mobility on the Lync side as well as take a look at the reverse proxy section of our deployment guide for additional tips: https://www.f5.com/pdf/deployment-guides/microsoft-lync-iapp-dg.pdf

Only other thing to mention is if you are still stuck and are fairly confident the F5 configuration is the problem you could open an F5 support case to get official assistance.

Hello James.

Thank you very much for the reply and the technet link.

I have changed some configurations on skype topology like the FE's FQDN and the certificate that I was using on the reverse proxy virtual server.

After changing this configuration, the mobile client still can't login, but now I see at the tcpdump that it's reaching the reverse proxy virtual server. That "Can't connect to server" error is not appearing on the mobile client any more, but it keeps trying to connect forever without showing any error.

Looking at the tcpdump filtering on my mobile IP address, I can see some intial communication with the FE server, but after some seconds the virtual server starts to send Resets to the client.

I will analyse this pcap files and try to understand why is this happening.

If you have any clue about it please let me know.

Thank you again.

am I blind? where is the rc9 download link?

on further review, you have to go to and use your support account to download the 2+MB iapps template, then extract the skype4b template from the zip file. ez pz but inconsistent with the rest of this page.

Hello Renato, Mobile clients should not be connecting to the AV virtual server to login successfully but instead to the reverse proxy virtual server on port 443 which (in single BIG-IP scenario) will in turn load balance traffic to port 4443 on the Lync FE's. To get mobile clients working through F5 using the iApp the reverse proxy section is key to getting this working ("thick" clients do not necessarily need reverse proxy to login and, depending on configuration/client/location, may not even be going through your BIG-IP currently).

Here is a useful technet article that goes through how lync mobility works: https://technet.microsoft.com/en-us/library/hh690030(v=ocs.15).aspx.

Let me know if i can help further once you attempt via reverse proxy Virtual Server.

Hi Folks.

 

I was wondering if any of you could help me with an issue that I'm having on a Skype deployment using iApp. I've searched a lot about it but couldn't find what I am doing wrong here.

 

I am trying to deploy Skype Server using template, but I'm having problems to connect to the Edge Servers using mobile devices. While trying to login from a mobile device I receive a "Can't connect to server" error, but if I use a Windows device with skype client installed it works fine.

 

Looking at tcpdumps on BIG-IP I can see the client trying to connect to AV Virtual Server on port 443 and receiving a reset after some time trying to connect to the server.

 

I am using automap for all the virtual servers, since BIG-IP is not the route for the skype servers. I'm also deploying the virtual servers behind a firewall NAT. On my Edge Server topology I'm using a single IP on the External Interface to handle all the three services on it. I've used the following guide to deploy the environment: https://devcentral.f5.com/s/articles/the-hopefully-definitive-guide-to-load-balancing-lync-edge-servers-with-a-hardware-load-balancer

 

During the iApp configuration I've answered Yes only to deploy Edge Services to the External Interface and to deploy the Reverse Proxy.

 

Has anyone seen a problem like this?

 

Thanks in advance.

 

Glad it worked for you, and thanks for the feedback. This could potentially use some clarification so i will add to our list of things to update.

Thanks very much James!! When I tested with the GET command for the monitor it returned the same 400 value but when I actually configured the iapp with lyncdiscover, both monitor returns successful and the iRule does now include lyncdiscover.

Thanks for your help in clarifying this.

For me personally I would say the iRule should inform you that lyncdiscover.domain.com will be used. But it seems most have not made the same (bad) conclusion that I did. So maybe just a comment under the mobility fqdn field to say what is expected.

Thanks again.

Glad i could be partially helpful, the background is that lyncdiscover.domain.com when this iApp was written was optional in the sense that only mobile clients needed that for auto-discovery and not "thick" clients as they had SRV records. I would definitely make that change in the iApp. If the monitor is still broken at that point then i would suggest opening an SR to get this officially looked at and figure if the iApp needs updating. Will be easier for you then chatting on this page since it sounds like something might actually be broken or incorrectly configured that isn't obvious.

James, well you solved the lyncdiscover issue right here. And, maybe that would also solve the monitor. When answering the iapp question about mobile access I used skype.domain.com. But as you explain the that question, it would have to be lyncdiscover.domain.com. I thought there was likely something that I was not answering as the iapp expected.

For the iRule, just to see if the source of the issue is the same, I tried lyncdiscover. instead of skype. and the return is still 400 URL must be absolute. But this also could be a value I provided the iapp that is not what the iapp is looking for.

Maybe this is just my interpreting the questions, or misinterpreting them. I didn't answer with lyncdisocver.domain.com because I don't believe that is optional.

For the monitor, my issue is that without changing anything the monitor returns 400 and fails, showing my reverse proxy server as down. This is for both virtual servers, 443 and 80. I have not been able to modify the monitor to work so I have used the default f5 https and http monitor.

Hello The-messenger, 1. Are you stating in your first bullet that there is something that should be changed on the iApp? 2. The reverse proxy iRule should account for lyncdiscover because it typically is filled in when answering "What is the FQDN for external Lync mobility access?" - I admit the questioning doesnt lead you to necessarily surmise this to be lyncdiscover FQDN but that is the intent. 3. Depending on the version of the template the http/https monitor has been changed slightly to hopefully show an up status in all environments. - It sounds like that is not the case, so if using latest template feel free to provide more feedback on what is going wrong with the monitor and how you solved it.