![]() ![]() ![]() You could add authentication mechanisms and security features with ASM/APM, but when we certified BIG-IP for Lync Reverse Proxy, we achieved validation using a FastL4 virtual translating 443 to 4443 only. The client also initiates a secondary connection to the web services namespace (lyncwebservices.fqdn listening on 443/80 in Fig. Primary client login is achieved via SIP registration through edge services (access:443). 1 shows the mobile client initiating two separate connection points into our Lync/Skype environment. When deploying reverse proxy services at F5 (and certifying our functionality for Microsoft), we simply CNAME’d the meet, dialin, and lyncautodiscover namespaces to the FQDN of the web service IP. (this name is up to you and added to topology builder during deployment).Services managed through reverse proxy are required for mobile, autodiscover, and extended collaboration services presented via the following public DNS entries: External connections are port redirected to internal front end pools, listening on 44 respectivly (if you don't redirect 80 to 443 as we do). Deploying reverse proxy starting with simple configurations and working up to your more complicated requirements will significantly reduce headaches down the road.Īt it’s core, the reverse proxy functionality for Lync/Skype is a simple public endpoint listening on port 80 and 443. Looking at support call metrics, we bundled a rather high percent of support cases into two specific issues certificate deployment problems and misconfigurations with port redirection. Regardless if you deploy Lync/Skype via iApps or manually define your BIG-IP elements, there’s rumbling suspicion of witchcraft around how this works. At F5’s Agility conference, I spoke briefly about troubleshooting Lync/Skype for Business Reverse Proxy at the request of our support people. ![]()
0 Comments
Leave a Reply. |