on 06-Jul-2015 08:25
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
With RC4 I see that in pure Reverse-Proxy deployment
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?
Thx
Alex
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.
yes, it's deployed as reverse proxy only (fwd traffic to skype servers). I've updated the tmpl to rc6 and the Irule is still the same:
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::host]] {
sfbpoolemeaext.xyz.com* { pool create_reverse_proxy_front_end_4443_pool }
{ pool create_reverse_proxy_front_end_4443_pool }
meet-emea.xyz.com* { pool create_reverse_proxy_front_end_4443_pool }
dialin-emea.xyz.com* { pool create_reverse_proxy_front_end_4443_pool }
{ pool create_reverse_proxy_front_end_4443_pool }
}
}
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?
thanks
LH
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.
thanks
LH
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.
thanks
LH
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.
best regards
LH
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.
thanks
LH
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?
regards
LH
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.
regards
LH
Hello LH, If you take a look at the following link that shows the HLB ports for front end services it has 8080 on there for client/device retrieval of root certs. https://technet.microsoft.com/en-us/library/gg398833.aspx
So that is why the port exists, however the sharing issue you ran into is also fixed, please download the template and retry with shared IP's.
Thanks,
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.
Thanks
Alex
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.
Thanks,
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.
thanks
LH
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.