Microsoft Skype for Business Server 2015
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 : 70782Troubleshooting Lync/Skype for Business Reverse Proxy
At F5’s Agility conference, I spoke briefly about troubleshooting Lync/Skype for Business Reverse Proxy at the request of our support people. 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. Well settle down there Salem. 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. Deploying reverse proxy starting with simple configurations and working up to your more complicated requirements will significantly reduce headaches down the road. Reverse Proxy’s Port Redirection At it’s core, the reverse proxy functionality for Lync/Skype is a simple public endpoint listening on port 80 and 443. External connections are port redirected to internal front end pools, listening on 4443 and 8080 respectivly (if you don't redirect 80 to 443 as we do). Services managed through reverse proxy are required for mobile, autodiscover, and extended collaboration services; presented via the following public DNS entries: Meet.yourdomain.com Dialin.yourdomain.com Lyncwebservice.yourdomain.com (this name is up to you and added to topology builder during deployment) Lyncautodiscover.yourdomain.com (required for mobile) 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. Fig. 1 shows the mobile client initiating two separate connection points into our Lync/Skype environment. Primary client login is achieved via SIP registration through edge services (access:443). The client also initiates a secondary connection to the web services namespace (lyncwebservices.fqdn listening on 443/80 in Fig. 1). 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. Microsoft’s certification process ensures the device(s) responsible for reverse proxy functionality allow their services to work, any extra features added are secondary and up to the admin for ownership and support. Remember, we’re starting simple to make sure we get it working first. From here let’s build certs to get this listening on 443. Building/Installing your Certificate We now have published public DNS records, all used by the reverse proxy, only one name requires a host record binding, the FQDN defined in topology builder for the external web services (in our example lyncwebservice.domain.com). You’ll still add all other CNAME’s to the SAN certificate and Lync/Skype’s cert builder will configure this for your public and private domains. I purchased my Entrust certificate and it included two bonuses, the CA root and intermediary chain certs; they're super important later. Seeing that I use a fastL4 for the reverse proxy functionality, there’s no SSL termination/bridge required at the external LTM in Fig. 1 and instead I’ll bridge SSL at the internal front end pool virtual listening on 4443; again for simplicity and testing. We also install this certificate chain on the external web services defined within the Lync/Skype installation wizard, allowing us to separate certs for internal and external features. Microsoft makes this fairly easy so don’t try to deviate TOO far from recommended configurations. If you want to do this on two separate certificates (one for web services and one for edge services) that’s fine, if you want to create one mega SAN cert, go for it. Microsoft’s cert creation wizard will potentially add more names than you need, so just pay attention. Places of Potential Failure (read: where everything blows up) The previously mentioned secondary connection our client makes to the Lync/Skype web services in Fig. 1 houses a potential hidden evil; A SECONDARY AUTHENTICATION! Breath deep! It’s ok. The secondary authentication creates a client session token from a front end server via the web service's Certificate Provisioning Services published URI (a great write up on this is found here). This authentication is critical to all reverse proxy web services and will cause very odd behavior in a failure scenario, I’ll give examples later. To validate this URI, initiate a browser connection to https://lyncwebservices.yourdomain.com/CertProv/CertProvisioningService.svc and if it’s listening properly, you’ll get a login dialog. It will accept your domain credentials and give you a basic landing page stating “You have created a service”. If you can authenticate from a public connection, you’re most of the way there. If this doesn’t work, check the following: Are you SNATTING the reverse proxy (or is outbound traffic for web services is going back out via the same device; MSFT isn’t going to help with this) Is the node for the reverse proxy pool is listening on 4443 (configure a monitor for this port because the same IP will listen for services on 443 and could cause false positive/negative results) The perimeter LTM cannot reach the internal front end pool; time to check/blame the firewall if you have one separating internal and DMZ networks; Lync/Skype’s planning tool will show you all of the ports required between various entry points. 443 isn’t listening on the public IP or your DNS is pointing to a black hole. …. you get the idea.... basic pathway troubleshooting Start with networking basics; NMAP, Dig/Host/NSLookup, and curl are your friends here. It takes 5 minutes to run NMAP to validate listening ports, Dig public records to validate DNS is publishing proper namespaces, and curl to validate URL’s responses (even if auth prevents full HTTP connections, for that you could OpenSSL s_client). Once you get the web service public URL responding, the next step is testing with a client, and here's where certificates have the potential to cause major headaches. Lync/Skype is one of the few applications who's client logs are actually useful and will prevent hours of packet capturing at your LTM and front end servers. Enable your client logs from within the app and locate them in the following locations: OSX: /Users//Library/Logs/Microsoft-Lync-0.log (OSX provides a generic log location for applications so there’ll be quite a few) Windows: C:\Users\\AppData\Local\Microsoft\Office\15.0 (or whatever)\Lync\Tracing\ Login to Lync/Skype and your newly generated logs will display a plethora of piñatas… a.k.a. client communication data. Search for one of two things: the FQDN of the published web services, OR the phrase WWW-Authenticate. Both will get you to the web service authentication token creation as shown below: WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="feserver.fqdn", version=4 WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname=“feserver.fqdn", version=4, sts-uri="https://lyncwebservices.yourdomain:443/CertProv/CertProvisioningService.svc" WWW-Authenticate: TLS-DSK opaque="3AFFA71F", gssapi-data="FgMBDKsCAA ......AAA4AAAA=", targetname="feserver.fqdn", realm="SIP Communications Service", version=4 WWW-Authenticate: TLS-DSK opaque="3AFFA71F", gssapi-data=”XXXXXXX", targetname="feserver.fqdn", realm="SIP Communications Service", version=4 This log shows us the client connecting to public web service URI and completing authentication. If you validated previous steps 1-5… and you see the connection completing… but it still doesn't work.... turn your anger towards certs. Remember that Entrust certificate I purchased that included a cert chain file and CA root file? If those are not installed within the client OS, the authentication will fail because Lync/Skype will run it’s own internal certificate validation (similar to issues with Lync/Skype requiring a valid non-self-signed certificate for Exchange UM). Lync/Skype is not a dumb client and will ONLY work if the certificate being used is a proper CA-owned certificate; this can be an internal CA or public CA (choose a CA who hasn't run afowl of the internet law). Troubleshooting this stage of reverse proxy is best done with Microsoft’s Remote Connectivity Analyzer. Run the Lync/OCS Autodiscover Web Service Remote Connectivity Test and the results will show your certificate information, including cert chain information. If you have cert issues, they’ll show up here. This should be the end of the story, but you’re a smart admin and nothing just “works”. In F5’s case, we had a lot of OSX users complaining of the inability to search for users within Lync for Mac. Well, smart admin, we know client search policies default to file download and web search (for the record, MSFT corporate uses web search only). In my case, the Lync for Mac client was ONLY trying to use web search functionality, and because these were non-standard machines, they didn’t include the Entrust L1K intermediary chain certificate within the OSX keychain. This prevented the web services certificate from validating against the CA root of the public certificate and only in certain connection behaviors, caused search to fail because the previously mentioned web service authentication failed. In this case, the client log only showed the failure to authenticate and we had to determine the cert as the root cause on our own, but the logs did narrow down the issue significantly. In all, this wordy article condenses down to 4 primary troublshooting points: Make sure the public listener 443 redirects to 4443 on the internal front end pool Make sure you have valid certificates answering for internal and external web services defined in Lync/Skype Make sure your clients HAVE THE WHOLE CERT CHAIN for internal and external services Make sure to validate the network path between client and front end server; it can be a few hops or complicated 10+ hop massive network pain in some cases The mentioned certificate issue I troubleshot with MSFT Tier III Premier support went much longer than I care to admit and from that ticket they did add improved logging to the Lync for Mac client but really it was an oversight on my part. We did our due diligence on a specific set of client machine connection variables, but we didn’t have several alternate connectivity scenarios in our testing plan. Oops. ITIL to the rescue and the new admins won’t make that mistake again. Let me know your experiences and thoughts on this subject; I’ve spoken to several people at various conferences and even hopped on a few support calls for F5 to help out with this specific feature of Lync/Skype. Our awesome PD team added support for reverse proxy in our Lync/Skype iApp templates so deployments should go much smoother (check out the current release candidate here). I hope this helps your troubleshooting, if it does(n’t), let me know and I'll be glad to help where possible Cheers!Microsoft Lync Server
F5 deployment guides and associated iApp templates for Lync Server (and now Skype for Business) are the result of collaboration and interoperability testing between Microsoft and F5 Networks using Microsoft Lync Server and the BIG-IP LTM. Microsoft requires hardware load balancing for Lync Web Services. Organizations using the BIG-IP LTM benefit from mission-critical availability, intelligent traffic management, simple scalability, and enhanced security for Lync Server deployments. You can also use the BIG-IP system as a reverse proxy for Microsoft Lync, eliminating the need for a separate reverse proxy device. F5 also provides deployment guidance on configuring the BIG-IP Global Traffic Manager (GTM) for Lync site resiliency. BIG-IP GTM uses topology-based load balancing to direct internal clients to Lync Front End Server resources, and external clients to Edge Server and Reverse Proxy resources. The following configuration example shows what this configuration might look like. See the deployment guide for specific details. See https://devcentral.f5.com/s/articles/microsoft-lync-server-2013-2010-iapp-templatefor information on using the iApp template to configure Lync server. Seehttps://devcentral.f5.com/s/articles/microsoft-skype-for-business-server-2015for information on Skype for Business (new name for Lync) See https://f5.com/solutions/deployment-guidesto find the appropriate deployment guide for quickly and accurately configuring the BIG-IP system for Microsoft Lync Server or Skype for Business. If you have any feedback on these or other F5 guides or iApp templates, leave it in the comment section below or email us at solutionsfeedback@f5.com. We use your feedback to help shape our new iApps and deployment guides.
Microsoft Lync Server 2013/2010 iApp template
Problem this snippet solves: Use this latest iApp template to configure the BIG-IP Local Traffic Manager to provide mission-critical availability, intelligent traffic management, simple scalability, and enhanced security for Lync Server deployments. The iApp also enables you to use the BIG-IP system as a reverse proxy, eliminating the need for a separate reverse proxy device. Note f5.microsoft_skype_server_2015.v1.4.0rc7: posted 09/22/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(seperate 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. A deployment guide with detailed instructions for using this iApp template and configuring your environment is located at http://www.f5.com/pdf/deployment-guides/microsoft-lync-iapp-dg.pdf For the latest fully supported iApp template for Lync Server 2010/2013, see https://support.f5.com/kb/en-us/solutions/public/15000/600/sol15655.html for instructions downloading and using the iApp. Code : 70794
Lync iApp - only reverse proxy for Lync Web Services
if i just want to do reverse proxy for internet based clients. then i need to follow the "Using a single BIG-IP LTM as a reverse proxy for Lync Web Services" chapter. it makes two remarks about what you be turned on / off 1) Yes to "Would you like to create a BIG-IP virtual server to act as a reverse proxy for Lync external web services?" 2) No to "Are you deploying a reverse proxy as part of your Edge topology?" well 2 is a bit unclear for me as you first need to enable either the front end or director server part. but does that mean you have to also enable fill in and use that front end / director server part? because if i understand the situation and the further text in the chapter fine then it is just a matter of replacing the single IP from the "What is the port 443 virtual server IP address that forwards traffic to the Front End Servers? " question into the front end server IPs. can't imagine i need all the further front end or director server part.Placing Lync 2013 Outbound Calls to a SIP gateway
Hello all. I'm in the process of setting up a simple Lync 2013 system as a small PBX replacement. We have an external SIP trunk provider that serves as our interface to the PSTN. This is a known good trunk/PSTN gateway as Lync can place and receive outside calls with the mediation server's interface exposed directly to the Internet. However, I would like to hide the mediation server behind an F5 BIG-IP LTM for security reasons. I was able to download and install the most recent Lync iApp, and this took care of inbound calls to the mediation server without any issues. However, I can't seem to place outbound calls; I get SIP 503 Service Unavailable errors when I try using a Virtual Server facing the inside interface, with the external PSTN gateway set as a TCP pool member on port 5060. Setting the SIP profile makes no difference, and neither does the network translation setting. Is there anyone familiar with this kind of scenario for Lync 2013? I can provide more details if someone here understands what I'm trying to accomplish. Much appreciated. Gerard
