Microsoft Skype for Business Server 2015
Problem this snippet solves:
New release candidate iApp template and deployment guide for Microsoft Skype for Business Server 2015 (formerly Lync Server 2010/2013). For more information and complete guidance on configuring the iApp template, see the associated deployment guide: http://www.f5.com/pdf/deployment-guides/microsoft-skype-for-business-dg.pdf
f5.microsoft_skype_server_2015.v1.0.0rc9: posted to downloads.f5.com in 11/2017
RC-9 was posted to downloads.f5.com (as will most new versions of this template). It contained the following changes: new BIG-IP AFM IP Intelligence threat categories to support BIG-IP v13.1 and support for route domain 0 from non-Common partitions.
f5.microsoft_skype_server_2015.v1.0.0rc7: posted 09/21/2016
RC-7 provides additional SIP domain support within reverse proxy, a monitor schema change for reverse proxy to make use of the 200 OK response when querying lyncdiscover/lyncdiscoverinternal, support for the director service standalone use case(separate LTM from Front End service), added support to ask for the IP phone update url to allow connections through reverse proxy and added a port 80 Virtual Server in addition to the existing 443 Virtual Server for reverse proxy.
RC 5 and 6 were never released to the public, this includes changes as a part of those RC's
f5.microsoft_skype_server_2015.v1.0.0rc4: posted 02/16/2016
RC-4 Fixes a security log profile error when deploying on versions of BIG-IP earlier than 11.4, where AFM is not available.
f5.microsoft_skype_server_2015.v1.0.0rc3: posted 01/22/2016
RC-3 attaches a supplemental ICMP monitor to the Edge internal UDP virtual server. See https://support.f5.com/kb/en-us/solutions/public/6000/100/sol6143.html for more information.
f5.microsoft_skype_server_2015.v1.0.0rc2: posted 01/11/2016
RC-2 contains only a small correction to the iRule produced by the iApp template. The iApp will now always force the FQDN written to lowercase in the iRule, even if the user enters CAPITAL letters.
f5.microsoft_skype_server_2015.v1.0.0rc1: posted 07/06/2015
New iApp template for Skype for Business.
Code :
70782
Published Jul 06, 2015
Version 1.0
- The-messenger
Cirrostratus
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.
-
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
 
- The-messenger
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.
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?
- The-messenger
Thanks for the clarification. I see the 50k range from the paloalto firewall, outside the edge. The palo has NATs configured for vips on the Big-IP. I see it when trying to share files, screen share to federated contacts.
Hi The-Messenger, if your Edge servers weren't using the LTMs as the default GW, you don't need to create the wildcard virtual server. In that case, you shouldn't need to create ephemeral port VS either, as the traffic should be set up directly between the Edge and clients.
Can you clarify which side of the Edge LTM was seeing the requests on port 52722?
- The-messenger
So I created a new fastL4 profile and wildcard server using the protocol, with F5 services help online - I created it set to disabled. I would need to wait for a change window to set the skype edge server's default route through the big-ip.
After this I could not connect to my portal/Remote Desktop. I've spent hours trying to see what I had changed that the RDP portal quit working, till I found someone else with the same issue. The wildcard VS, even though it was disabled, broke my RDP application.
I hope this skype iapp is developed further, at this point there is too much maintenance. I'm going to have to point the firewall directly to the edge and reverse proxy servers for now.
- The-messenger
Thanks Joe - this makes sense from what I see in the traffic. Is development going to continue for this iapp to include the FastL4 VS?
Hi Messenger, Have you created the forwarding virtual server for Edge server to client communication (see page 31 of https://www.f5.com/pdf/deployment-guides/microsoft-skype-for-business-dg.pdf)?”
- The-messenger
Skype has been working fine with the iapp for awhile now. Today tried to do a file transfer with a federated contact and it fails, from inside the network. If I connect outside it is successful. Skype diagrams call for UPD 50000-59999, the iapp has not created a VS to provide this. I can see the external client trying to make a connection on 52722.
