Federation has been around for more than a decade. First introduced in Microsoft Office Live Communications Server 2005, it's still a popular feature in Skype for Business Server 2015. Users like it because they can use their Lync or Skype client to call or send IM messages to people in another organization. They can even share a document through the conferencing feature if desired. Administrators like it because federated partnerships let them better control their Lync or Skype environments.

Administrators who want to set up federation often ask me about which type to use. The types most commonly used are:

  • Discovered Partner Domain (aka Open Enhanced Federation)
  • Allowed Partner Domain (aka Enhanced Federation)
  • Allowed Partner Server (aka Direct Federation)

I'll discuss the main differences between them.

Discovered Partner Domain (Open Enhanced Federation)

Users really like Discovered Partner Domain federation because it's easy to use. Let's say that Sally wants to send IM messages to a new contact in a partner organization. She simply specifies the person's phone number (the Session Initiation Protocol Uniform Resource Identifier, or SIP URI) in her client's contact list. If that organization is setup for partner domain discovery, the person's name will appear in her contact list. She can then begin sending IM messages to that person.

There is one caveat with this type of federation, though. There's a limit of 20 SIP messages received per second from a partner organization.

With Discovered Partner Domain federation, Skype or Lync accepts any SIP domain name and uses DNS records to locate the partner organization's Access Edge server. What makes this possible is the interaction with the public DNS records that are created by the partner organization. The partner organization needs to create two DNS records:

  1. A DNS SRV record specifying the domain. It should follow the format _sipfederationtls._tcp.domain.com. The port value for the SRV record should be TCP 5061.
  2. A DNS A record containing the Fully Qualified Domain Name (FQDN) of the Access Edge server. It should follow the format sip.domain.com.

Note that the SIP domain listed in the DNS A record and the certificate for the federated Access Edge server must match the user's SIP domain. In a nutshell, that's all you need for Discovered Partner Domain federation in regard to DNS records, without turning this article into a discussion about firewall ports for the Access Edge server.

You can use the Lync Server Management Shell's Get-CsAccessEdgeConfiguration cmdlet to determine whether your organization is currently setup for partner domain discovery. Simply run the command:

Get-CsAccessEdgeConfiguration

In the results, you should look for the EnablePartnerDiscovery entry, as Figure 1 shows. If EnablePartnerDiscovery is set to True, your users will be able to initiate communication with users in partner organizations, as previously described. In addition, users in partner organizations will be able to add an SIP URI to their contact list to initiate communication with your organization's users.

Figure 1: Determining Whether an Organization Is Currently Setup for Partner Domain Discovery in the Lync Server Management Shell

You can also determine whether additional parameters have been defined, such as MaxContactsPerDiscoveredPartner. You can use this parameter to specify how many contacts in partner organizations your users are allowed to add to their contact list. The maximum limit is 1,000 contacts per partner organization.

You can also use the control panel to determine whether your organization is setup for partner domain discovery, as Figure 2 shows. In this case, it isn't enabled, which matches the results returned from the Get-CsAccessEdgeConfiguration command.

Figure 2: Determining Whether an Organization Is Currently Setup for Partner Domain Discovery in the Control Panel

Allowed Partner Domain (Enhanced Federation)

With Allowed Partner Domain federation, you specify the partner's SIP domain name as a federation partner for your organization and use DNS records to find the partner organization's Access Edge server. It allows partner domain discovery, but it takes a little more work to set up.

To set up Allowed Partner Domain federation, you need to add your partner organizations' SIP domains to the list of federated domains in the control panel. The Access Edge servers' FQDN isn't required for this type of federation, as seen in Figure 3.

Figure 3: Adding a Partner Organization to the List of Federated Domains

Like Discovered Partner Domain federation, Allowed Partner Domain federation requires that your partner organizations create DNS SRV and A records. Once again, the SIP domain listed in the DNS A record and the certificate for the federated Access Edge server must match the user's SIP domain. Unlike Discovered Partner Domain federation, a partner organization in an Allowed Partner Domain federation can send an unlimited number of SIP messages through the Access Edge server.

Allowed Partner Server (Direct Federation)

With Allowed Partner Server federation, users can only contact people in partner organizations specified in the control panel's list of federated domains. It doesn't allow partner domain discovery.

Setting up federation rests solely on your shoulders because you need to know and add each partner organization's SIP domain and Access Edge server FQDN to the federated domain list, as Figure 4 shows. There are no DNS records involved.

Figure 4: Adding a Partner Organization's SIP domain and Access Edge Server FQDN to the List of Federated Domains

It is important to correctly configure each partner organization's SIP domain and Access Edge server FQDN. If they are incorrect, the partner organization will get an error message stating that the authentication failed. Because of this failure, your users won't be able to federate with the users in that partner organization.

It is also important to update the Access Edge server FQDNs as needed. An FQDN might change if a partner organization goes through a merger, acquisition, or migration.

Federation Going Forward

Although the different types of federation might seem similar, there are important differences. Now that you know about those differences, it should be easier to decide which type to use.

This decision is really a matter of preference. Discovered Partner Domain federation is great if you don't mind your users talking to people in any other organization (even competing organizations) set up for partner domain discovery.

If you want to be more selective, Allowed Partner Domain federation is better. Your users will be able to talk with people in any partner organization that is set up for partner domain discovery and has its SIP domain specified in your list of federated domains.

Allowed Partner Server goes a step further. Your users will be able to talk with only those people in partner organizations whose SIP domains and Access Edge server FQDNs are specified in your list of federated domains.