Configuring federated sharing (free/busy calendar information) between on-premise Exchange Organizations
In this post I want to show how you can set up federated sharing between two on-premise Exchange organizations.
With federated sharing, users in your on-premises Exchange organization can share free/busy calendar information with recipients in other Exchange organizations that are also configured for federated sharing. Free/busy sharing can be enabled between two organizations running Exchange 2013 and also between organizations with a mixed Exchange deployment. To learn more about federated sharing, see Sharing.
A bit of history of the Availability service
For many years now we have allowed different organizations to share calendar availability between each other. It really started with the Availability Address Space feature in Exchange 2007, later moving on to the Microsoft Federation Gateway (Now called the Azure Authentication System) with Organization Relationships in Exchange 2010, 2013, and 2016. This set of features allows an organization to share limited free/busy details with another organization without an AD Trust in place. The main point of this article is to understand what to do when one of these organizations deploys a hybrid configuration with Office 365. Will free/busy sharing still work? However, before we get into why this could be a problem when you deploy a hybrid configuration, we need to make sure you have a general understanding of how the cross-organization free/busy works.
Source: https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910
Configure a Federation Trust
The first thing we must configure in order users can share free/busy calendar information with recipients in other Exchange organizations, is to configure a federation trust between your on-premise Exchange organization and the Azure Active Directory authentication system (fka Microsoft Federation Gateway).
A federation trust establishes a trust relationship between a Microsoft Exchange 2013 organization and the Azure Active Directory authentication system. By configuring a federation trust, you can configure federated sharing with other federated Exchange organizations to share calendar free/busy information among recipients. Federated sharing can be configured between two federated Exchange 2013 organizations or between a federated Exchange 2013 organization and federated Exchange 2010 organizations. You can also set up sharing with a Microsoft 365 or Office 365 organization.
Source: https://learn.microsoft.com/en-us/exchange/configure-a-federation-trust-exchange-2013-help
Azure AD authentication system
The Azure Active Directory authentication system, a free cloud-based service offered by Microsoft, acts as the trust broker between your on-premises Exchange 2013 organization and other federated Exchange 2010 and Exchange 2013 organizations. If you want to configure federation in your Exchange organization, you must establish a one-time federation trust with the Azure Active Directory authentication system, so that it can become a federation partner with your organization. With this trust in place, users authenticated by Active Directory (known as identity providers) are issued Security Assertion Markup Language (SAML) delegation tokens by the Azure AD authentication system. These delegation tokens allow users from one federated Exchange organization to be trusted by another federated Exchange organization. With the Azure AD authentication system acting as the trust broker, organizations aren’t required to establish multiple individual trust relationships with other organizations, and users can access external resources using a single sign-on (SSO) experience. For more information, see Azure Active Directory.
Both Exchange organizations in a federated sharing relationship must use the same Azure AD authentication system for their federation trusts. This requirement applies when configuring federated sharing between two on-premises Exchange organizations or between an on-premises Exchange organization and an Exchange organization hosted by Microsoft 365 or Office 365.
When you create a federation trust with the Azure AD authentication system for your Exchange 2013 organization, the federation trust will use the business instance of the Azure AD authentication system. However, other federated Exchange organizations with previous versions of Exchange and existing federation trusts may be using either the business or consumer instance of the Azure AD authentication system.
Source: https://learn.microsoft.com/en-us/exchange/configure-a-federation-trust-exchange-2013-help
Before configuring federated sharing between the two Exchange organizations, you need to verify which Azure AD authentication system instance each Exchange organization is using for any existing federation trusts. To determine which Azure AD authentication system instance an Exchange organization is using for an existing federation trust, run the following Shell command.
Get-FederationInformation -DomainName <hosted Exchange domain namespace>
The business instance returns a value of <uri:federation:MicrosoftOnline> for the TokenIssuerURIs parameter.The consumer instance returns a value of <uri:WindowsLiveID> for the TokenIssuerURIs parameter.
So for my Exchange Server 2019 in my lab environment I will have the business instance as expected.
The business instance will be used by the following Exchange Organizations by default:
- Exchange 2010 Service Pack 2 (SP2) and later
- Exchange Online
The consumer instance will be used by the following Exchange Organizations by default:
- Release to manufacturing (RTM) version of Exchange 2010
- Exchange organizations hosted by Microsoft Live@edu
To configure a federation trust we can use either the EAC or the Shell.
In the EAC navigate to Organization –> sharing and click on the Enable button.
If there is not still configured any federation trust
After the wizard completes, click Close
In the Federation Trust section of the Sharing tab, click Modify.
Set your first primary shared domain. You can add additional domains for which you want to enable sharing for the federation trust.
When you create a new federation trust, an organization identifier (OrgID) is automatically created with the Microsoft Federation Gateway (now Azure AD authentication system). This OrgID is a combination of a predefined string and the first accepted domain that’s selected for federation. For example, when editing sharing domains, if you specify the federated domain contoso.com as your organization’s primary SMTP domain, the FYDIBOHF25SPDLT.contoso.com account namespace will be automatically created as the OrgID for the federation trust.
Make a note of the federated domain proof that’s generated for the primary shared domain. You will use this string to create a TXT record on your public DNS server.
The federated domain proof is a string of alphanumeric characters.
If the TXT record is created by using an incorrect federated domain proof string, the Azure AD authentication system won’t be able to verify proof of domain ownership, and you won’t be able to add it to the federated organization identifier.
You can always use the shell command below to return the proof of domain ownership TXT record that’s required for any domain that you’ll configure for the federation trust.
Get-FederatedDomainProof -DomainName
As mentioned above when you create a new federation trust, an organization identifier (OrgID) is automatically created as shown below.
Federated organization identifier
https://learn.microsoft.com/en-us/exchange/federation-exchange-2013-help#federated-organization-identifier
Further a self-signed certifcate is created for the federation trust as shown below.
As mentioned you can also use the Shell to create the federation trust. About how to you will see in the following article https://learn.microsoft.com/en-us/exchange/configure-a-federation-trust-exchange-2013-help#use-the-shell-to-create-and-configure-a-federation-trust.
To verify that you have successfully created and configured the federation trust, you can run the following two Cmdlets.
Get-FederationTrust | Format-List
Get-FederationInformation -DomainName
Create an Organization Relationship
Now after we configured the federation trust with the Azure Active Directory authentication system (fka Microsoft Federation Gateway), which acts as the trust broker between our on-premises Exchange organizations, we finally have to set up an organization relationship between both organizations.
An organization relationship is a one-to-one relationship between businesses to allow users in each organization to view calendar availability information. When you set up the organization relationship, you are setting up your side of the relationship and specifying the level of information that the users in the external organization can view. The external organization may set up the same or different settings on their side.
For example, if Contoso creates an organization relationship with Tailspin Toys, the users at Tailspin Toys will be able to schedule meetings with the users at Contoso by adding their email address to the meeting invitation. The availability of the invited Contoso user would display to the Tailspin Toys user.
However, before Contoso can also see availability for users at Tailspin Toys, their administrator needs to set up an organization relationship with Contoso.
Source: https://learn.microsoft.com/en-us/exchange/organization-relationships-exchange-2013-help
Note: Finally on both sites the organization realationship needs to be created in order free/busy calendar information is working. The article above implies, if just one site configures the organization relationship, the other site is able to access its free/busy calendar information. Regarding my test, also the other site who wants to access needs to create the organization relationship to be able to access the information.The point is: the organization relationship must be set up at both ends for calendar availability information to be shared.
There are three of levels of access that you can specify:
- No access
- Access to availability (free/busy) time only
- Access to free/busy, including time, subject, and location
If users don’t want to share their free/busy information with others, they can change the Default permission entry in Outlook.
To do this, users go to the Calendar Properties > Permissions tab, select the Default permission, and select None from the Permission Level list. Their free/busy information won’t be seen by internal or external users, even if an organization relationship exists. The permissions set by the user will apply.
In case the user set this to None below, no free/busy information could be retrieved despite what is configured for the organization relationship.
Before we configure a new organization relationship, check that the external organization also already have configured a federation trust with the Azure AD authentication system.
The external organization you want to configure in the organization relationship must also have a federation trust established with the Azure AD authentication system. You will use the primary federated domain for the external Exchange organization when configuring the organization relationship.
To configure an organization relationship we can also use either the EAC or the Shell.
In the EAC navigate to Organization –> sharing
Under Organization Sharing, click New .gif)
In the Domains to share with box, type the federated domain or federated subdomain for the Microsoft 365 or Office 365 or Exchange on-premises organization you want to let see your calendars. If you need to enter multiple domains for the external organization, separate the domains with a comma. For example, contoso.com, service.contoso.com.
As mentioned you can also use the Shell to create an organization relationship. About how to you will see in the following article https://learn.microsoft.com/en-us/exchange/create-an-organization-relationship-exchange-2013-help#use-the-shell-to-create-an-organization-relationship.
From now on my prod environment (only on-premise braincourt.com) can access free/busy calendar information from my on-premise lab environment (braintesting.net).
Both organizations are configured for Exchange classic full hybrid where mailboxes hosted in on-premise and online.
More about Exchange classic full hybrid you can read in my following post.
In order also users from my on-premise lab environment can access free/busy calendar information from the prod environement, I have to configure the same on the on-premise prod Exchange Server.
Below I will accessing the free/busy calendar information from the on-premise mailbox fred.nurk@braintesting.net in my lab environment. I am accessing the information from an on-premise mailbox in my prod environment.
Troubleshooting
If the configuration seems to be fine but free/busy information still not available, first check some security settings.
Below should return True for both.
Get-AutodiscoverVirtualDirectory | fl *wssecurity*
Get-WebServicesVirtualDirectory | fl *mrs*In case not run the following commands:
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurity $true
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true
If it is still not working, try to reset WSSecurity for the virtual directories as shown below.
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$false
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$false
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true
Restart-WebAppPool MSExchangeAutodiscoverAppPool
Restart-WebAppPool MSExchangeServicesAppPool
Source:
Users from a federated organization cannot see the free/busy information of another Exchange organization
https://support.microsoft.com/en-us/topic/users-from-a-federated-organization-cannot-see-the-free-busy-information-of-anotherexchange-organization-938f0ba7-1303-de00-57a0-6ff73ccceece
Test-FederationTrust
Use the Test-FederationTrust cmdlet to verify that the federation trust is properly configured and functioning as expected.
Test-FederationTrust -UserIdentity <RecipientIdParameter>
The UserIdentity parameter specifies a mailbox user in your own organization to request a token for. You can use any value that uniquely identifies the mailbox.
- Name
- Alias
- Distinguished name (DN)
- Canonical DN
- Email address
- GUID
Source: https://learn.microsoft.com/en-us/powershell/module/exchange/test-federationtrust?view=exchange-ps
Test-OrganizationRelationship
Use the Test-OrganizationRelationship cmdlet to verify that the organization relationship is properly configured and functioning as expected.
Test-OrganizationRelationship -Identity <OrganizationRelationshipIdParameter> -UserIdentity <RecipientIdParameter>
The Test-OrganizationRelationship cmdlet doesn’t include any functional tests of federated sharing features, such as accessing user free/busy information or moving mailboxes between organizations. It only verifies that the configuration will allow these features to work correctly.
The Identity parameter specifies the organization relationship to be tested. You can use the following values:
- Canonical name
- GUID
- Name
The UserIdentity parameter specifies the mailbox for which a delegation token is requested to access the external organization’s configuration information. This is a mailbox hosted on the Exchange Organization where you will run the cmdlet.
- Name
- Alias
- Distinguished name (DN)
- Canonical DN
- Email address
- GUID
RefreshMetadata
You can use the Set-FederationTrust cmdlet to manage the certificates used for the federation trust. You can also use the Set-FederationTrust cmdlet to refresh the metadata document from the Microsoft Federation Gateway and download its certificate.
Get-Federationtrust | Set-FederationTrust –RefreshMetadata
The RefreshMetadata switch specifies that the metadata document and certificate is retrieved again from the Microsoft Federation Gateway. You don’t need to specify a value with this switch.
Keep your Federation Trust up-to-date
https://techcommunity.microsoft.com/t5/exchange-team-blog/keep-your-federation-trust-up-to-date/ba-p/2088788
Source: https://learn.microsoft.com/en-us/powershell/module/exchange/set-federationtrust?view=exchange-ps
Test-FederationTrust Cmdlet – Failed to request delegation token
Below I was testing the federation trust on one of my prod Exchange Servers and was running into the following error.
Failed to request delegation token.
The cmdlet was just running on one of my Exchange Servers into this error, on all others it runs successful. So the federation trust in general must be configured correct.
Test-FederationTrust -UserIdentity <RecipientIdParameter>
The UserIdentity parameter specifies a mailbox user in your own organization to request a token for. You can use any value that uniquely identifies the mailbox.
Further on the same Exchange Server also the Test-OrganizationRelationship cmdlet was running into the following error.
WARNING: An unexpected error has occurred and a Watson dump is being generated: Cannot access a closed Stream.
When trying to update the federation trust on the above affected Exchange Server, I was further running into the following error.
An error occurred while attempting to provision Exchange to the Partner STS. Detailed information “An error occurred accessing Windows Live. Detailed informations: “The underlying connection was closed: An unexpected error occurred on a send.”.”.
This error indicates that there are some connection issues with the Azure Active Directory authentication system (fka Microsoft Federation Gateway).
On all other Exchange Servers the above test cmdlets runs without any error, just the notification that the Proof of domain ownership has failed appeared.
So the connection to the Azure Active Directory authentication system from this Exchange Server was not the problem.
The Proof of domain ownership is as mentioned above a TXT record on your public DNS server.
After updating the record at my public DNS registrar for the prod environment, the update from the federation trust on a server where the previously test cmdlets also runs successfully, works.
So but what was finally the issue on the affected Exchange Server where all test cmdlets and the update from the federation trust failed?
Finally it was just the TLS configuration on the affected Exchange Server, the Azure Active Directory authentication system (fka Microsoft Federation Gateway) only accepts TLS 1.2.
To force Windows and in my case the affected Exchange Server to use the new TLS Protocol, I need to set the following two registry settings.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
SystemDefaultTlsVersions=dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
SystemDefaultTlsVersions=dword:00000001
The SystemDefaultTlsVersions setting allows .NET to use the OS configuration. For more information, see TLS best practices with the .NET Framework.
Renew the Federation Certificate
Another real nasty trap is when you renew the federation certificate. Because of the above TLS issues and before I really knew that all the issues before were just because of the TLS version, I removed the federation trust including the corresponding certificate.
When you re-create the federation trust, the certificate will also be re-created automatically and you do not have to care about.
In case your certificate will expire soon, you have to renew it as shown below in the article.
Renew the Federation Certificate
https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2010/mt779252(v=exchg.141)
But now back to my issue after I re-created the federation trust and therefore also the federation certificate was re-created.
Directly after re-creating the trust and certificate, I was running into the following error when I was testing the federation trust by running the Test-Federation cmdlet as shown below.
WARNING: Could not retrieve orgPrivCertificate from GetOrganizationCertificates
Error: GetOrganizationCertificates(federationTrust) returned null when called in Process()Message: Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired.
So regarding the above warning and error messages, the federation certificate is expired.
How could this certificate be expired when it is just re-created?
The certificate is valid till February 2028, so what’s the real issue here?
The federation certificate will be used to create a trust between the on-premise Exchange and Azure Active Directory authentication system (fka Microsoft Federation Gateway).
The Test-Federation cmdlet of course will just work if this trust is established between both sites.
As mentioned this is really a nasty trap, because the Active Directory authentication system will use UTC time and my Exchange Server which was creating the self-signed federation certificate is using UTC +1 (Germany winter time), the certificate here is valid from exactly Thursday, 02/23/2023 2:04:46 am.
Remember, I was executing the Test-Federation cmdlet immediately after the re-creation of the federation trust and certificate.
At this time, the Active Directory authentication system which uses UTC time, is one hour behind the time zone of my Exchange Server, so something like Thursday, 02/23/2023 1:04:46 am.
In this case actually the certificate is not expired but predated which finally for the Active Directory authentication system is the same as expired.
So to solve this issue, finally I simply have to wait one hour to re-run the Test-Federation cmdlet in order to compensate the difference between the different time zones.
Fortunately to get an idea what here was the problem, nearly one hour was over 🙂 and I just had to wait 3 more minutes, till the date and time was in the valid range from the Active Directory authentication system.
About 3 minutes later the Test-Federation cmdlet was running successfully.
Remove Federation
Remove Federation with Exchange Shell
https://learn.microsoft.com/en-us/exchange/troubleshoot/administration/federation-trust-sharing-errors#resolution
Remove-FederatedDomain -DomainName <your federated domain> -force
Remove-FederatedDomain -DomainName <your account namespace> -force
Get-FederationTrust | Remove-FederationTrust
Remove Federation with ADSI
https://learn.microsoft.com/en-us/answers/questions/1081125/removing-the-last-exchange-2019-server-in-clients
Links
Configuring federated sharing between Exchange organizations
https://learn.microsoft.com/en-us/exchange/configuring-federated-sharing-between-exchange-organizations-exchange-2013-helpFederation
https://learn.microsoft.com/en-us/exchange/federation-exchange-2013-helpOrganization relationships in Exchange Online
https://learn.microsoft.com/en-us/exchange/sharing/organization-relationships/organization-relationshipsFederation procedures
https://learn.microsoft.com/en-us/exchange/federation-procedures