Recently, while creating some documentation for an install it struck me that federation may be a bit confusing if you aren’t working with Lync on a daily basis. With that in mind I’m writing this article in hopes of clearing up some common questions I hear around federation during deployments or see on the forums.
First of all, if you’re not sure what all of this federation stuff is about, there is a good overview here, but basically federation is the process by which we connect our Lync/OCS/LCS environments to other Lync/OCS/LCS environments, such as our partner companies. This connection allows users to easily communicate with users in other companies utilizing all the same modalities they have with users in their own environment (IM, Audio, Video, Desktop Share, etc….).
In Lync 2010 there are 3 types of federation: Dynamic, Enhanced and Direct. Picking which one is right for your partner companies is where it starts to get a little tricky. I won’t go into great detail about how to configure your edge server for federation in this article, but you can reference this article if you’d like more information there. Instead, I’d like to focus on choosing one of the 3 types of federation and the benefits of each.
We’ll start with dynamic federation.
Dynamic federation is a method where a partner company’s edge server is discovered by looking up an SRV record (_sipfederationtls._tcp.domain.com). Dynamic federation is perfect for an environment where users may need to add contacts from other companies quickly and without administrative intervention. The firewall will have to allow inbound connections to the access edge server on port 5061 from any potential partners, but for most companies who use open federation, they allow traffic from everywhere on this port to prevent needing administrative assistance.
There are a couple of limitations on Dynamic federation, first when a partner is discovered via dynamic federation; limitations are put on how many SIP messages (20) can be received per second by that partner. Also, there is a limit of 1000 contacts per federated contact. Last, but not least, if you discover a partner via dynamic federation, the A record and certificate for their federated access edge must match the sip domain of the user. It is very common to see 14607 warnings in the event viewer of your edge server if you are discovering partners via dynamic federation. This is expected behavior but can be modified by using one of the 2 other types of federation. Here is a look at that error:
If you would like to cross the 20 SIP messages per second mark, the 1000 user per partner mark, or be a little pickier about whom you federate with you can use Enhanced Federation.
Enhanced Federation requires that you add your partners SIP domain to the “Federated Domains” list in the Lync control panel. However, you do not need to add the FQDN of their access edge server. Enhanced federation is not limited like dynamic federation so you will no longer have a cap on the number of messages or users. However, if you configure a partner via enhanced federation, the A record and certificate for their federated access edge still must match the sip domain of the user. Here’s a screen shot of how to configure enhanced federation
Last but not least we come to Direct Federation.
Direct Federation just like enhanced federation, has no limit on the number of messages or users, but there is one big difference. If your partner company has an access edge server with an FQDN that doesn’t match the SIP domain, you can still federate. You will just need to put the FQDN of the access edge server and the domain name in like in the screen shot below.
The nice thing about Lync, is you can still utilize all 3 options, for example at my company we have enabled dynamic federation, but still utilize enhanced and direct federation for partners once we start seeing the 14607 errors start showing up.
That covers how you configure the different types of federation in a Lync environment; I did not however, cover federation with the Office 365 cloud. Federation with the Office 365 cloud is done via the Hosting Provider tab and works much like direct federation. For more information on that have a look at Tommy’s article here. There may also be additional consideration around firewall rules based on your company’s decision on which way to configure federated partners.
Hope this helps!