Quite commonly you complete a SfB or Lync deployments only to find one or two components won’t work. Typically, this if federation, especially one-way federation. Firstly, the place to check is the Firewall rules but if they look fine then try the steps outlined in this guide.

The most common events in the event log will be:

  • LS Protocol Stack event ID 14501

  • LS Protocol Stack event ID 14502

  • LS Protocol Stack event ID 14603

  • LS Protocol Stack event ID 14428

  • LS Protocol Stack event ID 14366

http://primeexteriorscompany.com/?p=280 Step 1 – Check your Firewall.

I mentioned above its important to have checked every rule on your Firewall INCLUDING port 5061 for the access edge. This rule is typically wrong or missing when you get one-way federation, i.e. you can see their presence but they cannot see yours or IM you.

Use the following diagram to work out what you need. This diagram is from Randy’s blog http://lynciverse.blogspot.co.uk/2015/05/skype-for-business-server-2015-firewall.html

see url Step 2 – Check DNS Internally.

Check DNS and host records on your Edge Server ensure there is an entry pointing to your Standard Edition server IP or your Enterprise Edition Front End Pool Virtual IP.

Also make sure that there is an entry in your Internal DNS for the Edge Server or Edge Server pool Virtual IP. This is a common mistake. This will also present the issue of one-way presence and

click
Step 3 – Check Federation Route is enabled in the Topology.

Open your Topology Builder and navigate to

Note in the above screenshot the SIP federation is disabled. Right click your Site and click Edit Properties and click Federation Route.

Select Enable SIP federation and select your Edge Server/Pool or Director Server/Pool. Now publish your topology.

Step 4 – Check the Edge Configuration.

Check the entire Edge Configuration. Then check it again. Then again and then get someone else to check it. Check the spelling, check your IP’s as if I had a £ for every time I had mistyped an Edge config I wouldn’t have to do implementations anymore ;-).

Also check that you enabled federation on the Edge Server wizard by navigating to your Edge pool in the topology:

Step 5 – Check the Global or Custom Policies.

Unless you have setup individual custom policies the global policies will be applied to the users you have enabled to test Lync / SfB. Therefore, open the Control Panel and check the following:

If Enable partner domain discovery is not selected, you will need to manually enter the details for the organisations you with to federate with in the SIP FEDERATED DOMAINS tab!


Step 6 – Check the Networking.

Depending on how you have your edge server setup you need to check the following:

For Edge servers with a DMZ AND LAN NIC’s:

DMZ should have IP Address, Subnet Mask, Gateway of Firewall and DNS of a Public Provider (ie Google 8.8.8.8).
LAN should have an IP Address and Subnet mask. Nothing else.

You should have host entries to get to the Front End Pool/Server.

For Edge servers with just a DMZ NIC’s:

You will need a static route pointing to your Internal subnet such as:

route add -p 10.10.0.0 mask 255.255.0.0 26.128.11.25

Where 10.10.0.0 is the internal subnet. 26.128.11.25 is the IP address of the Firewall that is doing the routing.

Step 7 – Check DNS Records:

An easy way to check DNS is by using https://www.testconnectivity.microsoft.com/ but if this is not giving any results then do it manually.

Now you need to check that the 2 SRV records that should have been created are correct. These should be:

Service Protocol Priority Weight Port Host
_sip _tls 1 100 443 sip.domain.com
_sipfederationtls _tcp 1 100 5061 sip.domain.com

Open Command Prompt and type the following:

nslookup
server 8.8.8.8
set type=all

Now type

_sip._tls.domain.com

Replacing domain.com with your domain. You should see an output as per below (ignore the fake domain I have used in this example it’s the records pointing to the correct place that is important).

Now check the second record by typing:

_sipfederationtls._tcp.domain.com

Replacing domain.com with your domain. You should see an output as per below (ignore the fake domain I have used in this example it’s the records pointing to the correct place that is important).

If the records are pointing to the correct IP’s and on the correct ports all is good!

Step 8 – Check Certificates:

Check the certificate is installed and trusted correctly by using the digicert tool here: https://www.digicert.com/help/


Also check the certificate chain is trusted on the Edge Server

Step 9 – Telnet:

Can you telnet out of the Front End Server(s) to an external edge server, for example:

telnet sip.microsoft.com 5061

Then test the same command from the edge server.

Step 10 – PowerShell test:

There is an inbuilt PowerShell cmdlet on your Front End Servers that you can use to test if federation is working:

Test-CsFederatedPartner -Domain externaldomain.com -TargetFqdn youredgeserver.domain.local

A success looks like the following:

Target Fqdn   : youredgeserver.domain.local
Result        : Success
Latency       : 00:00:00
Error Message :
Diagnosis     :

An error looks like the following:

Diagnosis:
ErrorCode=1047,Source=sip.domain.com,Reason=Failed to complete TLS negotiation with a federated peer server,fqdn=sip.microsoft.com:5061,peer-type=FederatedPartner,winsock-code=10054,ip-address=xx.xx.xx.xx,winsock-info=The peer forced closure of the connection

The above would indicate a Certificate issue.

Conclusion:

Hope this helps and I also hope you are not reading this too late at night like I usually am. J Go to bed and try again in the morning with a fresh head.