通过

Federation problems with vanity domains and other tenants

  • 项目

Most of the issues I see are when the federation system hasn't been set up correctly.  This particulary applies to vanity domains and these being setup manually for P type plans or in E type plans.

Quite often the clients on the machines will report various errors:

This message was not delivered to mymate@contoso.com because the address is outside of your organization and is not federated with your company, or the address is incorrect. Please contact your support team with this information.

The first stop for this isn't the MOSDAL or the SIP for me.  I usually go straight to the DOS prompt and do a nslookup. 

As part of the process, the O365 servers look after your federation, depending on the level you have selected.  There are three levels currently in O365.

Fairly simple stuff I hope you would agree.  For each of the options, the federation process needs to know about your selection and any domains you have allowed or disallowed or even if you have allowed no domain federation.  In order to do this your tenant needs to talk to the destination domain and that domain needs to talk to you.  It does this by using the SRV record that is setup as part of your vanity domain DNS record creation.  In the easiest terms, a SRV record tells a querying body where and how to talk to that domain about a particular service.  For more information on SRV please see here.

Most O365 administrators will correctly add in the DNS records required for the installation of the vanity domain.  You can see my test domain settings here:

As you can see I have highlighted the record above.  This is the record the opposing domain will used to contact your domain about federation and status. 

So its back to using DOS which I mentioned earlier.  The quickest and easiest way to check the DNS record is valid is to use NSLOOKUP.  Open up a command window and type the following:

  • nslookup
  • set type=all
  • server 208.67.222.222
  • _sipfederationtls._tcp.yourdomain.com

Your command window should now look like this:

The key part here is the port number. Most issues are not because the record is missing, but because the port number is not set to 5061. This can be difficult in some circumstances because of the DNS host application. Sometimes the weight, port and server hostname have to be put in a format like:

1 5061 sipfed.online.lync.com

I can't stress enough how important the port number is to have federation working.

Federation can also fail if the other side isn't willing to allow you to federate with them. Federation isn't controlled by a central organisation, but by the organisations using Lync and systems compatible with Lync. Your partner and you decide if federation should take place.

There are other causes of federation failing between two parties, but here I have highlighted a particular one which has been quite "popular".