Microsoft Skype for Business Server 2015

**NOTE: There seems to be a lack of formatting support in your webpage, but I definitely did add line breaks in this** Some feedback for you on the iApp. First a bug. 1. Creating the iApp the first time works. Go back and edit it to change the SSL certificate and the iApp fails. I found the cause and wrote a blog about it here - http://totalmodding.co.uk/f5-tips-and-tricks/fix-for-f5-error-010717e23-client-ssl-profile-must-have-at-least-one-set-of-certificatekey/ - might just need aligning in your code to avoid it. I believe this was introduced around 11.5.1. Second, some items I consider to be missing features. I'm sure F5 has it's reasons for not supporting some of these features, however I've been operating Lync 2010, Lync 2013, and now Skype for Business as an MSP on F5 hardware and iApps, and have learned that the following are much better included. We therefore have our own internal iApp which we track against the official F5 releases with the following modifications. We've done it this way because we prefer to work with a "strict updates on" environment to make our change management simpler. If a specific deployment needs a tweak for compatibility, it goes in as a drop down box. 1. The reverse proxy section is missing a couple of Skype features. The first, I would class essential. I've added a simple "Yes, Yes deploy mobility"/"No, No, don't deploy mobility" drop down and an additional mobility_fqdn URL string, adding it into the RP iRule accordingly. The second you may as well add when adding the first, since the code is near enough identical. 1.a. Support for Skype Mobility clients via lyncdiscover.domain.com 1.b. Support for IP Phone update services over reverse proxy via ucupdates-r2.domain.com 2. Support for Multiple SIP Domains. Many corporations utilise multiple SIP domains. Using multiple SIP domains, the client connects to the reverse proxy on port 80 (which needs to be reverse proxied through to port 8080 on the Front End Virtual Server - part_name_5/vs_5). This then handles a graceful divert up to the primary SIP domain, reconnecting the user to the reverse proxy on port 443. This is a little more complex to backfill, but I achieved it by adding a drop down in the Deployment section to define that Multiple SIP Domain support is required, and then based on that, show or hide a table for additional FQDNs under each element in the reverse proxy section. 3. I've rewritten the reverse proxy iRule generation from scratch. I manually step through each condition (including checking for Multiple SIP Domain FQDNs) and either "append irule_buffer" with content, or not, based on whether that feature is being deployed. This generates a cleaner iRule without lines which are commented out. It also makes it easier to add in Multiple SIP Domain FQDNs, which otherwise would require further redundant code. 4. SharePoint WAC is required for Lync 2013 and Skype for Business 2015, including a reverse proxy for it. I completely get why this isn't included in the F5 Lync/SfB templates - F5 has a separate template for full SharePoint and the WebApps server. However, in order to deploy that you'd need another publicly addressable IP address. Also, the subset of SharePoint WAC deployed for Lync 2013/SfB 2015 only requires a simple 443 internal server with an internally signed certificate, and can easily share the existing reverse proxy VIP by adding the SAN name to the certificate, and adding a dropdown to the iRule. This saves wasting another public IP, or working in a strict-updates off situation to otherwise co-exist. 5. I note that you don't have WSMAN cookie persistence enabled for SfB (or in the v1.4.0 template for Lync Server 2013 - at least in the version I checked). I know for a fact that Lync Server 2013 requires this at the very least for Multiple SIP Domain conditions, but also for certain Mobility scenarios. I've consulted with my colleagues and at this time we're under the impression that this is still required in Skype for Business 2015 as well. I've therefore backfilled this. I haven't tested this yet so I am prepared to backpedal rapidly if testing doesn't prove this out!

Hi marvn, thanks for the feedback. We will check into the bug. The reverse proxy section of the iApp already includes the question "Do you want to include Skype Mobility services for external clients?" which if you answer yes to, asks you for the Mobility FQDN and adds it to the iRule. Multiple domain and WAC support would be easy to support and I'll add that to the features list for updates. AFAIK, the need for persistence went away completely in Lync 2013, although you can still use it if desired: https://technet.microsoft.com/en-us/library/jj656815(v=ocs.15).aspx

Hi Mike, my error about the Mobility, it was an earlier version in which it wasn't included. I hadn't read my up-port list correctly. Through testing, we found that persistence was still required, the mobile client simply didn't log in on certain platforms. I am pretty certain that this was a Multiple SIP Domain environment, but we just enable it by default for compatibility reasons. If you have a way for me to contact you privately I'd be able to share with F5 the iApp changes I've made for you to refer to, if that's useful.

I am not sure if this iApp was tested with 11.2.0 since it throws an error about "Security-Log Profile" which is an AFM profile and AFM was not a module in 11.2.0.

We'll get that corrected before this is officially released to downloads.f5.com. Thanks for the feedback.

Usually Lync/SFB Scheduler is available on the Web services URL with a /scheduler, however today I had my first request for Scheduler to have it's own sub domain. I'm not sure how common this is and I worked around it by treating it as a Multiple SIP Domain for Web services but it may be necessary to add a drop down or this as well.

I have discovered that this template does not properly set the traffic group on the SNAT Translations if you are using source NAT Pools. If that happens, you may end up with source NAT's on your standby load balancer, while your inbound traffic comes in on your primary, which obviously breaks things. The workaround is to manually assign the same traffic group to your SNAT Translations after configuring or reconfiguring the application. See SR C1982985

Hi James, thanks for the feedback. I reviewed the case and there's a bit of a larger issue than the iApp template. It looks like you had to modify the traffic group settings on the SNAT translation, correct? The iApp doesn't create SNAT translations. It only creates the SNAT pool, which then automatically creates the SNAT translations. There's nowhere to define a traffic group during SNAT pool creation. Question: when you deployed the iApp, did you select the appropriate traffic group from the "Template Selection" section at the beginning of the template?

Mike, correct, I had to modify the traffic group on the SNAT translations. Yes, we are applying the appropriate traffic group from the Template Selection section. I can reproduce the problem anytime. If I reconfigure the application, remove the SNAT Translations and SNAT Pool, and then add them back in, they are created without the correct traffic group, they are inheriting the default "None". Other objects, such as the Virtual Addresses, are created in the correct traffic group, as specified in the Template Selection. If iApp's are not capable of setting the traffic group on SNAT Translations, seems like a frustrating limitation, effectively breaks the application until some manual work is done.

If you go to System ›› Users : Partition List ›› Common, what traffic group is the partition set to use under "Redundant Device Configuration"? All iApps work the same way when creating things like SNAT pools and virtual servers. I can't repro this and I've never seen a case about it in 4 years, so it leads me to believe that you have something wrong with your particular BIG-IP.