Microsoft Skype for Business Server 2015

Skype clients will prefer to communicate directly with the Edge servers. Is that allowed through the firewall, or are you forcing everything through the VIPs?

Currently using the iapp, I have everything going through the VIP. So, do you recommend the skype av IP be directly NAT'd and not use the VIP on the Big-IP?

If so, would this be a different recommendation is I were using the Big-ip as the default gateway? Would I also need the Big-IP beside the firewall, without a NAT?

Note- we've had an ongoing discussion here about whether F5 devices should be behind the firewall or not? To this point there's been no issue with it being behind configured NATs for each VS.

You should use the VIP, but you need to allow direct communication between clients and the Edge servers as well. The initial connection will hit the VIP(s), and most everything else after that is direct.  

 

This blog post goes into more detail:  https://devcentral.f5.com/s/articles/the-hopefully-definitive-guide-to-load-balancing-lync-edge-servers-with-a-hardware-load-balancer

 

I have the skype for business running via the iapp but I have to make changes to it.

• In the iapp configuration, I select do not deploy Big-IP for A/V services. I don't like this, I've made the statement to my team that the f5 only, and no server, should touch the internet. I've had to back track on that.

   

• The reverse proxy iRule does not allow for lyncdiscover. I have to add a line for lyncdiscover.doman.com and it's good.

   

• The HTTP/HTTPS monitors for the revers proxy do not get what they expect. The return on the monitor is 400 URL must be absolute. I've seen a few others here with the same issue, I haven't had time to get into it more so using the http/https monitor resolves.

   

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.

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.

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.

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 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.

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.