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!