Category Archives: 14955

How to Share Free/Busy Information Without Using Federated Delegation

If you have a two-way forest trust in place between two organizations, such as during a merger, you can share calendar free/busy information between two Exchange organizations without having to configure federated delegation.

Federated delegation is usually the way to go since it offers more than just free/busy sharing.  With federation using the Microsoft Federated Gateway Server service you can share limited details between business partners.  In addition to free/busy information you can share meeting subjects, attendee, and location information.
Federated delegation works by brokering a trust between two different SMTP domains. The following diagram shows how this brokered trust works between and
Federated delegation between and
To see more information about federated delegation see my articles, How to Configure Exchange 2010 SP1 Federation and Exchange Federated Free/Busy doesn’t work in one direction.
Because federated delegation relies on different SMTP domains, it won’t work during a merger/migration where both companies share the same SMTP domain (  The answer is to use the Add-AvailabilityAddressSpace cmdlet in both orgs.  
Be aware that the TechNet documentation for the Add-AvailabilityAddressSpace cmdlet is inaccurate/incomplete. It says this cmdlet is only supported on Exchange 2010 SP2 and Exchange 2010 SP3 when it’s actually supported on all versions of Exchange 2007 through Exchange 2013.  It also misses some crucial steps, which I’ve added below.
Here’s how to configure simple free/busy sharing information when both orgs share the same SMTP domain. For the examples below, the source domain is the one retrieving the free/busy info from the target domain. It is assumed that both domains already have a two-way forest trust configured and DNS forwarding is configured.
  • Run the following cmdlet in the target domain:

Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights “ms-exch-epi-token-serialization” -User “sourcedomain\Exchange Servers”

  • Run the following two cmdlets in the source domain:

Add-AvailabilityAddressSpace -ForestName -AccessMethod PerUserFB -UseServiceAccount $true

Export-AutodiscoverConfig -TargetForestDomainController -TargetForestCredential $Target -MultipleExchangeDeployments $true

After these steps are performed the users in the source domain can see free/busy information for users in the target domain.  Repeat these steps, switching the the source and target domains, to allow bidirectional free/busy look-ups.

Be aware that the source domain relies on Autodiscover and Exchange Web Services (EWS) in the target domain.  If Autodiscover is not configured properly (i.e., missing the record in DNS) it will not work.  It also relies on the externalUrl property of the WebServicesVirtualDirectory in the target domain.  That must be set to a valid URL and the SSL certificate used by this EWS URL must be trusted by the source domain.

How to Configure Exchange 2010 SP1 Federation

Exchange federation allows different Exchange organizations to share free/busy information with each other.  It does this without having to configure a one- or two-way trust between the organizations.

Federation is accomplished using the Microsoft Federated Gateway server, a free cloud-based service offered by Microsoft.  The Microsoft Federated Gateway (MFG) server acts as a trust broker between federated organizations, similar to the way a trusted root CA works for certificates.  All organizations that use federation must configure a one-time federation trust with the MFG, and orgs that share free/busy information must have an Organization Relationship with the other org(s) they want to share with.  Organization Relationships (sometimes called sharing policies) can be one-way, meaning that CompanyABC can share free/busy info with CompanyXYZ, but not necessarily the other way around.  Usually, each org will have a reciprocal Organization Relationship with the other org so they can see each other’s calendar data.

There are a number of articles that explain how to configure federation, but all of them are for Exchange 2007 or Exchange 2010 RTM.  Exchange Server 2010 SP1 simplifies federation configuration, primarily by eliminating the requirement for a trusted-CA certificate and providing most of the federation configuration from the Exchange Management Console (EMC).

Microsoft also changed the Microsoft Federation Gateway servers in Exchange 2010 SP1.  The RTM version uses what Microsoft calls the “consumer instance” of MFG and requires a trusted certificate for federation.  SP1 uses the same Microsoft Online Services MFG used by the Business Productivity Online Suite (BPOS) and Office365, Microsoft’s cloud offerings.  This new Online Services MFG uses self-signed certificates for federation (recommended), but can also still use trusted third-party certs.

The following guide explains how to configure federation between two Exchange 2010 SP1 organizations.

Note: This article assumes there is a working autodiscover record for the partner organization.  Federation uses autodiscover to automatically configure the Organization Relationship for the remote org.  If autodiscover is not working, you will need to enter that information manually.

Create a new Federation Trust

  • Open the Exchange Management Console (EMC) and select the Organization Configuration node.
  • In the Actions pane, select New Federation Trust.  The New Federation Trust wizard will run.
  • Click New to form the new trust with the Microsoft Federation Gateway.  The wizard will create a new self-signed certificate called Exchange Delegation Federation with the subject name of Federation.  The Federation and SMTP services will be assigned to this certificate, but it will not change the default SMTP certificate.  The Microsoft File Distribution service will automatically copy and install this self-signed certificate to all of your Exchange 2010 client access servers.
  • Click Finish to close the wizard.

Create Domain Proof Records
Domain Proof records are TXT records created in your domain’s external DNS zone.  The purpose of these TXT records is to prove the identity of your domain for the trust with the MFG server.  Exchange SP1 requires that you have at least two TXT records, one dedicated for domain delegation (typically, and another for each SMTP domains you use for users (for example,

Run the following cmdlets from the Exchange Management Shell (EMS) to generate the domain proof values:

Get-FederationDomainProof -DomainName
Get-FederationDomainProof -DomainName

Repeat the second cmdlet for additional SMTP domains you want to federate, if any.

Each cmdlet will generate a unique Proof value, based on a hash using the Exchange Delegation Federation self-signed certificate.  If the MFG can read the domain proof value in an external DNS record and it matches the calculated value, it proves domain ownership and validates the trust.

You must create one TXT record in external DNS for each of the Proof values.  How you do this depends on your external DNS management platform.  Here’s how that looks for Microsoft DNS:

And here’s how it may look in a managed DNS web GUI:

Remember, these TXT records should be entered in your external DNS, not internal.  You may need to wait a bit for the new TXT records to propagate across the Internet.  You will be unable to manage the federated domains until the MFG servers can access the domain proof TXT records.

Manage the Federated Domains
Once the domain proof TXT records have propagated you can add the federated domains to the Federation Trust.  But before we can add the federated domains, we must first add the new namespace to the Accepted Domains on the hub transport configuration.

  • Back in the EMC navigate to Hub Transport in the Organization Configuration node.
  • Click the Accepted Domains tab and click New Accepted Domain in the Actions pane.
  • Enter Exchange Federated Delegation for the Name and enter for the Accepted Domain, then click New.  This new authoritative accepted domain will never be used by users – it is only used by the federated trust.

  • Click the Organization Configuration node and select the Microsoft Federation Gateway trust under the Federation Trust tab.
  • Click Manage Federation in the Actions pane.  You will see the current federation certificate status.  You can click Show distribution state to check that the federation certificate is installed on all Exchange 2010 client access servers. 
  • Click Next to bring up the Manage Federated Domains window. 
  • Click Add and select the Microsoft Federated Trust accepted domain you created earlier.  I recommend adding just the Microsoft Federated Trust first, which creates the delegation namespace on the MFG server, the unique Application Identifier (AppID) and Application URI.  Then go back and add the SMTP domain(s) you want to federate (i.e.,
  • Click Next and Manage to configure Microsoft Federated Trust.  When the configuration is successful you will see the federation trust has an Application Identifier and Application URI.

  • If the TXT records you created earlier are incorrect or have not propagated yet to the MFG server, you will get the following error:

Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be “ IN TXT hash-value” where “” is the domain you want to configure for Federation and “hash-value” is the proof value generated with “Get-FederatedDomainProof -DomainName”.
The proof of domain ownership is not valid or is missing.

  • Once you have configured the original Microsoft Federated Trust you can repeat these steps to add your other accepted domains.  You can only add accepted domains that you have created domain proof TXT records for.

Create Organization Relationships
Now that the federated trust has been created and then validated by the MFG, you can create organization relationships.  These are the federation sharing policies that determine what is shared with whom.

  • Click the Organization Relationships tab on the Organization Configuration node in the EMC.
  • Click New Organization Relationship in the Actions pane.  The New Organization Relationship wizard will start.
  • Enter a name, such as Share with CompanyXYZ.
  • Select the Enable free/busy information access checkbox and specify the free busy data access level you wish to share using the dropdown box.
  • You may select a security group for which this relationship should apply.  If you do not select a security group the settings will apply for all users.

  • Click Next to enter the External Organization details.
  • Enter the domain you want to federate with (i.e.,, then click Next and New.  Exchange will create a new organization relationship using the data results from the Get-FederationInformation cmdlet.  If the external domain does not have a valid federation trust with the MFG or autodiscover record, you will see an error:

Federation information could not be received from the external organization.

  • When the organization relationship has been successfully configured you will see it listed under the Organization Relationships tab.  Sharing Enabled and Calendar enabled will show as True.

Testing and Troubleshooting
Use the following command to query for TXT records in DNS:

nslookup -q=txt [DNS server name to query]

Use the following cmdlets to get Exchange federation configuration information:
  • Get-FederatedOrganizationIdentifier – gets the Microsoft Exchange Server 2010 organization’s federated organization identifier and related details, such as federated domains, organization contact, and status.  The Enabled attribute will show as False until the MFG has validated the trust using the domain proof TXT records in external DNS.
  • Get-FederationInformation – gets federation information, including federated domain names and target URLs, from an external Exchange organization.  It does this using the autodiscover record of the external domain.  This cmdlet will not work until you have a valid Federated Trust configured.
  • Get-FederationTrust – displays the federation trusts configured for the organization.  Use with Format-List to display the ApplicationIdentifier and ApplicationUri attributes, details about the federation certificates. and token information.
  • Get-OrganizationRelationship – gets settings for a relationship that has been created for free/busy information access or secure e-mail delivery using federated delivery.

If you’re federating with a mixed-mode Exchange organization with Exchange 2003 users (as in a migration scenario) you will need to populate the TargetSharingEpr attribute of the Organization Relationship with that domain.  If you don’t populate this value the free/busy information for Exchange 2003 users will be unavailable.  Populate the TargetSharingEpr value  in both organizations with the following cmdlet:

Set-OrganizationRelationship “CompanyABC” -TargetSharingEpr

Replace with the FQDN used by the external organization’s Exchange Web Services (EWS) ExternalURL.  For example, run the following cmdlet in CompanyABC:

Get-WebServicesVirtualDirectory -Server ex2010 | fl ExternalUrl

ExternalUrl :

CompanyXYZ should set Organization Relationship’s TargetSharingEpr for CompanyABC to

Continuing the example, run the same cmdlet in CompanyXYZ:

Get-WebServicesVirtualDirectory -Server exchange01 | fl ExternalUrl

ExternalUrl :

CompanyABC should set Organization Relationship’s TargetSharingEpr for CompanyXYZ to

Replacing a Federation Trust Certificate When the Original Certificate is Missing

Exchange 2010 federation allows organizations to share calendar free/busy information (also known as calendar availability) and contact information with external recipients, vendors, partners, and customers.  This is accomplished by creating a trust with Microsoft’s Federation Gateway.  This cloud-based service offered by Microsoft acts as the trust broker between your on-premises Exchange 2010 organization and other federated Exchange 2010 organizations.  For more information about Exchange federation, see Understanding Federation.

To configure federation you install an Exchange certificate, enable the certificate for Federation, and create a federation trust with Microsoft Federation Gateway.  Eventually you will need to replace this certificate, either for business reasons or when the certificate expires.  The usual way of doing this is to install a new Exchange certificate and configure it as the “Next Certificate” in the Manage Federation Certificate wizard, as shown below.

When you’re ready to replace the current federation certificate you simply run the Manage Federation wizard, select the “Roll certificate to make the next certificate as the current certificate” check box, and complete the wizard.  What was the Next Certificate becomes the Current Certificate, and the Current Certificate becomes the Previous Certificate.

I ran into an interesting issue where the process above did not work.  The customer deleted the Current Certificate from the computer’s local certificate store, rather than roll the Next Certificate into the current certificate’s place.  This causes the Manage Federation wizard t break because it can’t locate the Current Certificate.  I was also unable to use the Set-FederationTrust cmdlet in EMS – it would give the same error:

[PS] C:\>Set-FederationTrust -Identity “Microsoft Federation Gateway” -PublishFederationCertificate
Federation certificate with the thumbprint “29FD8FFF241A4317ABAAF326226BC209F682C2F3” cannot be found.
    + CategoryInfo          : InvalidResult: (:) [Set-FederationTrust], FederationCertificateInvalidException
    + FullyQualifiedErrorId : 906B427C,Microsoft.Exchange.Management.SystemConfigurationTasks.SetFederationTrust

To fix this, you’ll need to do it using ADSIEdit.

  • Log into a computer with administrator rights and run ADSIEdit.msc
  • Connect to the Configuration naming context
  • Navigate to CN=Federation Trusts,CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
  • Right-click CN=Microsoft Federation Gateway in the work pane and select Properties
  • Edit the msExchFedOrgNextCertificate property (which contains the thumbprint of the Next Certificate) and copy the entire value.  Close the msExchFedOrgNextCertificate property.
  • Edit the msExchFedOrgPrivCertificate property (which contains the thumbprint of the Current Certificate, which was removed) and paste the value.  Click OK to set the value.
  • Wait for the change to replicate throughout your AD infrastructure.
  • From the Exchange Management Console, run the Manage Federation Wizard.  You will now notice that the Current Certificate and the Next Certificate are the same.
  • Check Roll certificate to make the next certificate as the current certificate and complete the wizard.

Don’t forget to test your configuration with the Test-Federation cmdlet.