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
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.
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
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.
**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.
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.
can we add the capability to add a password for the certificate to this iapp? without it the wizard doesn't finish. and even when i use the default cert and key and attempt to add the cert after i use the default to finish, it still fails because there is no place to put the password.
Loaded the template onto a v11.3 LTM and got the following error :
Error parsing template:can't eval proc: "script::run" iapp_get_items -norecursive -filter NAME !~ ca-bundle.crt|f5-irule.crt sys file ssl-cert: extra characters after close-quote while executing "error "$error_msg $err"" invoked from within "subst $rval($do_binary,$tmsh_rval,$nocomplain)" (procedure "iapp_get_items" line 76) invoked from within "iapp_get_items -norecursive -filter NAME !~ ca-bundle.crt|f5-irule.crt sys file ssl-cert" invoked from within "tmsh::run_proc f5.iapp.1.4.0.cli:iapp_get_items -norecursive -filter NAME !~ ca-bundle.crt|f5-irule.crt sys file ssl-cert" (procedure "script::run" line 3) invoked from within "script::run" line:1
Any thoughts?
Hello Rox, in the current iteration of the iApp, the way to include a certificate/key that requires a password is to create a Client SSL profile outside of the iApp template (Local Traffic > Profiles > SSL > Client) There you can include the passphrase. When you are in the iApp, simply select the profile you created from the question "Do you want to create a new client SSL profile for Front End services, or use an existing one?"
Steve A- I am able to load and run the template on 11.3 without issue. The error message that you posted seems to indicate that the iapp is having trouble listing your ssl certificate names. Do any of your cert files have a name with quotes or spaces or special characters in it? Are any of them in a partition other then /Common?
Hi to all. I've just tryed to deploy this iAPP in a guest running 11.2.1 (LTM module only)...so no AFM.
and i'm facing this error
script did not successfully complete: ("security-log-profiles" unknown property
while executing
"tmsh::create [string range $args 7 end] "
("create" arm line 1)
invoked from within
"switch -exact -- [string range $args 0 5] {
create { tmsh::create [string range $args 7 end] }
modify { tmsh::modify [string r..."
(procedure "iapp_conf" line 14)
invoked from within
"iapp_conf create "/ ltm virtual" "$vs_name destination $destination $snat_action pool none profiles none profiles replace-all-with \{ $http_profile_na..."
(procedure "configure_microsoft_skype_server_reverse_proxy_deployment" line 145)
invoked from within
"configure_microsoft_skype_server_reverse_proxy_deployment"
invoked from within
"if { $provisioned } {
if { $::front_end_ip__deploying_front_end_ip == $::YES_ANSWER } {
configu..." line:1424)
I think the problem is the lack of AFM. How can i fix that? I'm not intrested to use AFM,
Hi Folks. I am playing around with trying to make this work at the moment. (rc4 template) It seems even if you answer NO to the question "Should the system monitor the internal SIP virtual servers?" it still creates the monitors and adds them to the _reverse_proxy_front_end_4443_pool... Disabling strict updates and removing the monitor from the pool sorts that out but I figured I'd share what I've found.We only have firewall rules from the edge server to the front end servers on 5061, not from the self IP's to the front end servers on 5061. Had us scratching our heads for a while but we worked it out. I'll have a look at the template more closely and see if I can work out what's amiss.
If I have the wrong end of the stick here and we really do need the firewalls opened on 5061 to the front end pools from the self-ip's please let me know. Anyway I'm off to see if it all wants to play nicely now. 🙂
Jon, that is expected behavior. We need to mark every FE service down if 5061 is unreachable, so because of that you will need the firewall open for 5061 between the self-IPs and FE.
Hi, we encountered a missing SSL client profile when trying to use this template for the Microsoft Skype Server Edge Virtual Servers: External Interface. The virtual servers are all created correctly but the one listening on port 443 does not use HTTPS. When creating and assigning an additional SSL client profile to this server it worked as expected.
Hi ChristianH, this is by design. We don't decrypt this traffic, so the virtual server only uses a TCP profile and no SSL profiles. What issues were you seeing?
Antoine, as a Release Candidate, the Microsoft Skype for Business Server 2015 iApp was developed by F5 and is waiting on final testing to become a gold release. As a release candidate, and an iApp developed by the F5 iApp team, it is supported. We expect to incorporate any additional features and complete to "gold" status in the last summer of 2016.
When you say "Type the IP address the BIG-IP system will use for the Edge Servers - External Interface Access service virtual server. This must be a unique, publicly routable IP address.. Can this be a private IP address that is NATed to a unique, publicly routable IP address?
I am running BIG-IP 11.5.1 Build 10.0.180 Hotfix HF10, and the iRule settings were a little off on page 38 of the document.
I had to put the pool name in quotes in order to get the iRule to select the pool. Also why is there an asterik after the host entry? If the F5 pulls the host name and matches it against the string in the iRule, it shouldn't need the wildcard given the host name is fully defined.
As a heads up to other users, it is well worth it to include :
log "host info: [HTTP::host]"
log "pool info: [LB::server pool]"
between the second to last and last "}" at the bottom of your iRule. Then at least it will put an entry into your local traffic logs, and can be commented out after initial testing.
Hi aclease, the asterisks are required in cases where the hostname includes a port number. Regarding the quotes around the pool name, that's never been a requirement of the pool command: https://devcentral.f5.com/s/articles/irules-101-05-selecting-pools-pool-members-and-nodes
Do your pool names have TCL special characters in them, by chance?
We had only underscores and the port number, so Skype_for_business_4443 as the pool address. The pool would not select without the addition of the quotes, which was odd to me, as I had never had to do that before. Figured it was worth mentioning in the event anyone else has the same issue.
Thanks for the info on the asterisk, were not calling anything by port number, so it seemed odd, but makes perfect sense!
With RC4 I see that in pure Reverse-Proxy deployment
lyncdiscover is missing in the irule
What about the suggestion from marvn to include the WAC (office web apps) in the Skype iApp as an option? His remark about the VS IP / Certificate makes sense.
More important, what about the support of multi SIP domains?
By "pure reverse-proxy", which scenario are you using for"Are you deploying this BIG-IP system for Skype web services (reverse proxy)?" The lyncdiscover hostname is present for me in the RC6 template that's on when I choose to either forward RP traffic to Lync/Skype servers or forward it to another BIG-IP.
For Office Web Apps, we can update the guides with manual steps for colocating on the application virtual server, similar to what's in the SharePoint guide today. However, we believe that most organizations will use a dedicated WAC environment to be shared between SharePoint, Lync/Skype, and Exchange, that uses a unique IP. Also, creating separate configurations for WAC in each iApp is problematic, since the configurations in each template will drift.
I'll create an RFE for the multiple SIP domain work, but we don't have an ETA on it at the moment.
To confirm, you answered "Yes" to "Do you want to include Skype Mobility services for external clients?", and typed the FQDN into the "What is the FQDN for external Skype Mobility access?" field, and still not in the iRule?
Hi,
I am just trying to configure the S4B VIPs using the v1.0.0rc6 version of template and have discovered that the "Microsoft Skype Server Director Virtual Servers" section is part of the "Microsoft Skype Server Front End Virtual Servers" section which prevents me to do a separate configuration for the director pool which I would like to run in different trafic group thus being active on other LTM node.
In Lync template there it was possible to separate the config, so my question is simple.
Is this on purpose or it's a bug and it might be fixed?
Hi LH, both the Lync and Skype templates work the same way-if you choose to deploy FE services, then the question about Director services appears and you should be able to enter in whatever node address you like in the Director Pool section. Which version of the Lync template were you using?
Hi mikeshimkus, well, I have no issue with choosing the right director node. My issue is that I can't use the template to configure just the director pool without the need to configure the enterprise pool first, which means I cant run each of the pools on different LTM node (box).
I hope it is more clear now.
In the template such configuration is possible.
Hello LH,
The issue is understood now. Thanks for clarifying, the most typical use case seen when deploying director services is to also deploy FE services. So for the purpose of hiding questions unless they are needed the director services section was made dependent on FE services being set to yes as you observed. It appears however that you have a unique edge case where you would like those two sets of services managed by different iApps on different LTM's. We will take this under advisement and update the iApp accordingly.
As it sits for you now my suggestion is to simply fill in the FE services with a placeholder VS ip and pool member ip. I know that is not ideal but that will allow you to use the iApp without modifying it and making it unsupported.
Hello James,
I am still just in the testing environment with my S4B upgrade, so you have plenty time to update the template. In the worst case I will use the workaround with dummy FE IPs also in production environment.
LH, as noted in latest RC released on this page this includes the enhancement for separating director role from front end role dependency. Thanks for the feedback!
Thanks for the changes which make it possible to host the Director and Frontend pool on different BigIP machines.
Nevertheless it looks like I drove in another deathend 😉
With the upgrade to Skype4Businness I wanted to get rid of the TMG reverse proxy so I tried to configure the "Microsoft Skype Server Reverse Proxy" part of the template.
But there again is the Director and Frontend part bound together.
OK, so I tried to put a dummy IP in the FE VIP and backend fields which did create all the frontend dummy and 8080 director but not the 4443 virtual server for director pool.
Is this on purpose?
Because otherwise I would preffer to forward the 4443 trafic to Director too.
I have also tried to create the iApp with just the Reverse proxy configuration for both the frontend and director pools, but it ended up with an ilegal sharing error, although the ports 8080 and 4443 are not being used in any other iApp. What could be wrong here?
I have used following options in both cases
- Yes, receive the reverse proxy traffic from another BIG-IP system
- Yes, forward reverse proxy traffic to Director servers
I am also wondering if it would be possible to do the SSL passthrough here without a need to import certificate and key.
Hello LH,
As far as the reverse proxy deployment goes, those objects are still tied together. The reason being is it is presenting the reverse proxy section as a whole. The objects created for reverse proxy are the same whether director role is enabled or not, the only difference is if director role is enabled then a pool is created based on the director pool member IP field in the iApp and the iRule attached to the 80/443(on external) VIP passes the majority of the traffic through to the director pool/big ip instead of the front end. Now the exception is when using split LTM's(as you are) where different sets of objects are created in different places. But in either case the only "dummy" fields would be including a front end fake pool member ip potentially, and depending on single/split some unnecessary LTM objects. But for reverse proxy this is not on our roadmap to break out.
In the case of the reverse proxy the best practice is to terminate SSL, this is for various reasons. So the iApp does require a valid cert and for ssl ports will use that cert selected.
For the 4443 objects not getting created, please download a slightly newer version of the rc posted here and retry, thanks! I was not able to reproduce the error you got about illegal sharing so if it still occurs with the new template then could you provide more details on the errors received?
Hi James,
I have tried the latest version of the RC7 and with the version from afternoon 27.9.2016 everything seems to be OK.
Both the missing Director 4443 issue and the illegal sharing issue while creating separate iApp just for the reverse proxy are gone.
It looks like I will split the config in 4 iApps (director, director_RP, frontend and frontend_RP), director iApps in one traffic group and frontend iApps in another one, which allows me the flexibility I wanted achieve.
I was too fast :(
the dummy FE IPs allowed to create the iApp for the director_RP config.
But when I have tried to create the frontend_RP iApp, I got following error:
01070333:3: Virtual Server /Common/frontend_RP.app/frontend_RP_reverse_proxy_front_end_8080 illegally shares destination address, source address, and service port with Virtual Server /Common/frontend.app/frontend_front_end_ip_8080.
So I checked the frontend iApp and there is really an 8080 VS and pool, which isn't supposed to be there, unless I would have chosen to configure the reverse proxy section of the template, right?
The front end section of the iApp does in fact create a port 80 and port 8080 set of VS's and pools as part of the front end server services. So if you are trying to use the same IP for your front end VIP as well as the same IP for your RP reverse proxy virtual server in the secondary iApp then it will throw the error you got. You need to make sure each service has a unique IP preferably. Does that explain your issue?
Hi James, I think I understood the issue and that another IP would solve that.
What I don't understand is why there is 8080 being created as part of the reverseproxy-less frontend iApp.
IMHO the 8080 is supposed to be used just in the reverse proxy scenario.
Hello James
would it be possible to make the SIP monitor optional in future version? Some customers do use the iApp exclusively for Reverse Proxy and do not run sip services on their pool, which makes them remove the strict update and remove that monitor.
Hello Amolari,
This is not in our roadmap as of now... thanks for bringing this edge case to our attention though and we will log it for possible inclusion in future versions of the iApp as suggested.
Hello James,
finally I have used the latest template, so I can confirm, there is no more a ilegal sharing error.
But I have noticed that the name of the Virtual server is ending with _reverse_proxy_front_end_8081.
Is this the solution or a typo?
Also there is a double underscore in both the pool names.
Correct, to fix the port sharing issue the solution(in this scenario of split LTM's and shared IP) will use 8081 in between the LTM's to carry that traffic, but front end and back end ports will stay as expected. Thanks for pointing out the double underscore.
