Microsoft Skype for Business Server 2015

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?

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

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

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?

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

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!

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

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.

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

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?