Once again another article from the field, what I do or other Lync experts does to troubleshooting Lync Federation problems.
Will be covering in this article:
- · Unknown Presence of Federated Partners.
- · LS Protocol Stack event ID 14501
- · LS Protocol Stack event ID 14502
- · LS Protocol Stack event ID 14603
- · LS Protocol Stack event ID 14428
- Lync Skype Connectivity
So there are many reason why federation might not work as expected, although we are all expert and deployed Lync solutions a lot in our carrier, we might end up making a mistake or missing / overlook / forget something while deploying, after all we are all human 🙂
So before wasting anytime with logging and trying to troubleshoot the problem, there is a number of things to do first, consider it a “Check List”
Make sure you enabled federation route for your topology
- · Start the Lync Topology builder and download the topology
- · Go to your Lync Site and check that “SIP federation” is enabled and showing your Lync Edge / Director server name or pool name and is not “Disabled”
- · If it is disabled as shown in the screenshot above, then right click the site name >> edit Properties
- · In the Edit Properties Page, go to “Federation Route”
- · Check the box says “Enable SIP Federation”, and from the drop down menu choose your Edge server / Director server or pool you want to use.
- · Click Ok
- · Don’t forget to publish your Topology.
Double check your Edge Server/Pool configuration
“As I said we can all be expert in Lync and deployed it many many times, but sometime when working for 3 days in a row with only 5 hours of sleeping, mistakes happens, I for once put the IP-address of Edge services instead of the FQDN of the services, and discovered it when tried to assign certificate to the services and got the error it doesn’t have all the SAN 🙂 , then I checked the topology builder and I found that I didn’t put sip.domain , av.domain and webconf.domain, I put the public IP-address. I guess I wanted to finish the job and I jumped ahead 2 steps (in my mind) and thought I’m already in the assign IP-addresses for services step 🙂 ”
I know I ended up with no problem, but sometime there might be a miss typo
Check Topology Configurations for your Edge
- · So in your Topology Builder expand your Edge Folder
- · In the “General” double check that “Federation (port 5061) is enabled
- · Check that next hop pool is configured and pointing to either your Frontend server/pool or Director server/pool
- · Under External Settings double check that the FQDN of the external services are configured correctly (access.domain or sip.domain / webconf.domain or webcon.domain / av.domain)
- · Make sure that sip.domain or access.domain, not using port 5061 and pointing to port 443
Check Control Panel configurations of “Federation and External Access”
Before going more into this subject, I would like to state in a nut shell the different between “Open Federation” and “Closed Federation”. Open federation , Lync Edge will use DNS records to discover partner domain that is not listed in the “Allowed Domain List”, while closed federation, you will have federation only with domains that are added to the “Allowed Domain List” of your Access Edge.
- · Log into your Lync Control panel or start Lync Management Shell console
- · Using the Control Panel, go to “Federation and External Access” >> choose the “Access Edge Configuration” tab
- · Double click on the “Global” policy
- · Make sure that “Enable Federation and Public IM connectivity” is selected
- · If you configuring open federation, then you should have “Enable Partner Domain Discovery” box selected
- · Using PowerShell, run get-CsAccessEdgeConfiguration cmdlet and check for the value of “EnablePartnerDiscovery” set to “True”
NOTE: in case you have number of Policy configured, then you need to do the previous steps for all of them depending on your design
- · In case of Closed Federation, then make sure that the SIP domain of the partner you want to federate with is added as “Allowed” to the “SIP Federated Domains”.
Troubleshooting Network & Firewall
For Lync Federation to work, there are a number of DNS records and firewall roles need to be created and configured in your infrastructure.
Check Required Public DNS records
- · Make sure you configured an internal DNS server to be used by your Edge in the edge NIC or added the IP-address of the frontend nodes / Directors to the edge server host file.
- · Start cmd.exe and enter nslookup
- · Set the DNS server to be used by typing: server 184.108.40.206
- · Set the type to all by typing: type=all
For Federation to work, you must have two DNS SRV records created in your public DNS zone
_sipfederationtls._tcp.sipdomain listing on port 5061
_sip._tls.sipdomain listing on port 443
- · So check those DNS SRV records and they should be pointing to your “Sip.domain” or access.domain records with the above mentioned ports
- · As you see they should be pointing to your sip.domain or access.domain DNS A records, so you need to also double check that sip.domain or access.domain is pointing to the correct public IP-address
Check Required Firewall Rules
- · Make sure you created static routing to route to all internal network something like following
C:> Add route -p 192.168.0.0 mask 255.255.255.0 220.127.116.11
- · For IM, A/V, Conference and Presence with Federated Partners, you need the following Firewall rules to be created in your firewall appliance this diagram shows required ports for federation
External (Internet) -> Public Leg of Edge Server
You need the following ports to be open for federation to work (including the media traffic for AV and Webconf services), Lync uses TLS connection to secure traffic between the Client and the Server, while using MTLS to secure traffic between Servers.
- · Access Edge public IP-address = SIP/TLS port 443
- · Access Edge public IP-address = SIP/MTLS port 5061
- · Access Edge public IP-address = XMPP/TCP port 5269
- · A/V Edge Public IP-address = SRTP/TCP 443 and UDP 3478
- · Webcon Edge Public IP-address = PSOM/TLS 443
- · A/V Edge Public IP-address = STUN/TCP 443 & UDP 3478
Internal Leg of Edge Server -> Frontend Server / Pool
You need to insure following port is allowed from Lync Edge internal NIC to the Frontend server / pool
- · SIP / MTLS 5061
From Frontend Server / Pool -> Internal leg of Edge Server
You need to insure that Frontend servers can establish and communicate with the internal leg of Edge server using the following ports
- · SIP/MTLS 5061
- · SIP/MTLS 5062 (when frontend & Mediation running on same box)
- · STRP,ICE:STUN, TCP 443 & UDP 3478
- · HTTPS/TCP 4443
- · PSOM/TLS 8057
- · XMPP/MTLS 23456
Lync Users -> Internal Leg of Edge Server
You need to insure the following is enabled between Lync Clients (of all kinds) to the Lync Edge internal leg
- · SRTP,ICE:STUN, TCP 443, UDP 3478
LS Protocol Stack event ID 14501 / 14502 / 14603 / 14428:
- · Check the SSL certificate mentioned in the error by going to DigiCert tool and type the sip domain name in the search bar.
- · If check is a success you should see a SSL Certificate part with all the SANs
- · If this an allowed SIP federation partner, add it to the allowed list of your Access Edge.
- · If this is a Blocked SIP federation partner, add it to the blocked list of your Access Edge.
- · If you running Lync 2010 Edge, according to Microsoft Support article here you need to apply Lync 2010 October CU here
- · After checking with the DigiCert tool and made sure the certificate authority is trusted proceed with step 2 and 3 down
- · Make sure that the Root Certificate of the Public Authority the certificate from is installed on the Edge server under the “Trusted Root Certificate Authorities”
- · Make sure also that the intermediate Certificate of the Public Authority is also installed under the “Intermediate Certificate Authorities”
this sometime occur to me with Infrastructure with mixed windows server platforms (server 2008, 2008 R2 and 2012).
- Most of the time I just ignore it until I migrate the whole Lync from 2010 to Lync 2013, which after that it disappear.
- · If it bother you, you can use the following Article by Tom Rimala showing how to change the encryption Algorithm.
This occur when you have Hardware load balancing deployed and used by a pool in your Lync infrastructure and didn’t specify the HLB Monitoring Ports, HLB perform a check to make sure it is balancing traffic between the member of
The pool, resulting in a number of 14502 events logged in your server.
To fix this problem you need to change the port used by HLB monitoring in your Lync pool configuration to point to another port than 5060
- · Start Topology Builder
- · Right click the Pool you fixing “Frontend pool”
- · Check the “Enable hardware load balancer monitoring port” box
- · Change the port from 5060 to another port (some suggested 5061 if you have mediation server collocated in the frontend)
- · Publish the topology
- · Log into your HLB
- · Reconfigure it to use the new same port.
This should fix it
Lync – Skype Connectivity
By this I tried to cover most of the problem points I faced in the field regarding External federation and some of the annoying event logs you see in Edge servers.