Cross Org Availability using Federation Trust and Organization Relationship

[The_Exchange_Team]

Note: To ensure that you see more up to date guidance related to this scenario, please see this blog post.

Organizations often need to share availability (aka Free/Busy) information with other Exchange organizations. Depending on the version of Exchange Server you're on, there are different ways to do this. Let's take a look at three common scenarios and go through the exact steps required in order to achieve sharing of availability information between two on-premises Exchange organizations. Scenarios:

1. Scenario 1: Both organizations running Exchange 2010 SP1
2. Scenario 2: One (or both) organizations running a mix of both Exchange 2007 and Exchange 2010 SP1
3. Scenario 3: One (or both) organizations running a mix of Exchange 2003, Exchange 2007 and Exchange 2...

This summary table outlines the requirements in order to facilitate Availability lookups between two organizations:

	Exchange Version present in Source organization
Required Components	Exchange 2003/2010	Exchange 2003/2007/2010	Exchange 2007/2010	Exchange 2010
Federation Trust/ Organization Relationship	X	X	X	X
Availability Address Space	-	X	X	-
Public Folder Database on 2010 Sp1 with Replicas of some/all Free/Busy folders*	X	X	--

*refer to “Option A” and Option B” which are discussed later in this post

Scenario 1: Both organizations are running Exchange 2010 Sp1

This is the simplest scenario. Users in both organizations are on Exchange 2010, both organizations can use Federated Delegation and do not require any additional steps.

1. Both organizations must first set up a Federation Trust. The steps to create a Federation trust are documented in Create a Federation Trust. The Federation Trust should be in place and working for both organizations before the organization relationship is set up.
2. Register the DNS TXT records for the federated domain namespace and all other domains you wish to add to the federation trust. The account namespace (this is the federated delegation organization identifier or OrgID) identifies your organization to the Microsoft Federation Gateway. You must use a domain other than your primary SMTP domain (used to receive inbound email) for the account namespace, as documented in Configure Federated Delegation. The current recommendation is to use exchangedelegation.domain.com as the account namespace.
3. Ensure that the autodiscover web service is configured and working for your domain namespace. Although it's possible to manually configure the organization relationship, we recommended that you use autodiscover.
4. Create an organization relationship with the remote organization. The steps to create an organization relationship are documented in Create an Organization Relationship.

Note: Directory synchronization is not required in order to do cross-org availability in Exchange 2010 SP1, except if you have users on Outlook 2007/2003. However, if you choose to configure directory synchronization, it'll not impact the ability to perform availability lookups.

Scenario 2: One or both organizations are running Exchange 2010 SP1 and Exchange 2007

Steps 1-4 in this scenario are the same as Scenario 1. However, with Exchange 2007 in the mix, directory synchronization is requiredbetween the two organizations. You must also create an availability address space for the remote organization. This allows Exchange 2007 users in both organizations to benefit from Exchange 2010's support for federation.

5. For Exchange 2007 to query availability cross org, directory synchronization must be performed for all users for which Free/Busy needs to be shared. This can be performed either manually (create Exchange contacts or Mail-enabled users one at a time), or via an automated process (MIIS, ILM, FIM, other 3rd party dirsync tool, etc.).Dirsync is required in this case because Exchange 2007 requires (and expects) a local object when the availability request is performed. If no local Exchange object is present, the availability request will fail.
6. Create a new availability address space for the remote organization that directs availability request from 2007 users to the 2010 Sp1 server. The syntax for creating the availability address space is included below.

   Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl https://Exchange2010SP1CAS.InternalDomain.com/ews/exchange.asmx -ForestName Fabrikam.com -UseServiceAccount $True

   With this setting, when an Exchange 2007 user requests availability information for a user from the remote org, the request will be proxied through the Exchange 2010 Sp1 server, which then will utilize the Federation Trust and Organization Relationship to send the availability request to the remote forest availability endpoint. Figure 1: Exchange 2007 user requests availability for a user in remote organization
   1. Step 1. Exchange 2007 user requests availability from user in Org B. Exchange 2007 proxies the request to the Exchange 2010 SP1 server.
   2. Step 2 and 3. Exchange 2010 detects it is for a remote org, and detects there's an Organization Relationship. Exchange then validates the Federation Trust.
   3. Step 4. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   4. Step 5. The Availability service in Org B generates a respond and sends back to the Exchange 2010 SP1 CAS server in Org A.
   5. Step 6. The availability response is returned to Exchange 2007, which then returns the response to the client.

Scenario 3: One or both organizations are running Exchange 2003, Exchange 2007 and Exchange 2010 SP1

Steps 1-4 in this scenario are the same as Scenario 1. Steps 5-6 in this scenario are the same as Scenario 2. Additionally, since you have Exchange 2003 in the topology, you must choose one of the two options described below in Option A and Option B. With either option, there are considerations that must be made. Please reference the known issues section at the end of this post to better understand these considerations. With both options, it's assumed that you have performed all previous steps outlined in Scenario 1 and Scenario 2.

Option A:

1. Ensure that there is an Exchange 2010 Sp1 Mailbox server that hosts a Public Folder database.
2. Move ALL replicas of Free/Busy public folders to the Exchange 2010 Sp1 Public Folder server, and remove ALL replicas from either 2003 or 2007. This will allow Exchange 2010 SP1 to respond to all Public Folder free/busy requests.As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query, and route the request to the Availability service, which will then process the request as outlined in previous scenarios
3. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the targetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This is done via the Exchange Management Shell by running this command:

   Set-organizationrelationship –identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

   Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. This can be obtained by running Get-WebServicesVirtualDirectory –server 2010cas.contoso.com | fl name, *url*

   Figure 2: Exchange 2003 user requests availability information for user in remote org (Option A)
   1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDN attribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines the Administrative Group in which the object was created and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).For example, Joe User's LegacyExchangeDN is LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou=Exchange 2003 Admin Group is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.
   2. Step 2. The Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
   3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox server intercepts the Free/Busy request and routes it to the Availability service.
   4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
   5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   6. Step 7. The Availability service in Org B generates a response and sends it back to the Exchange 2010 SP1 CAS server in Org A.
   7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Option B

1. 1. Ensure that there's an Exchange 2010 SP1 Mailbox server that hosts a Public Folder database.
   2. If not already present, create the Free/Busy system folder called External (FYDIBOHF25SPDLT) and ensure that the only replica of this Free/Busy Folder is on the Exchange 2010 SP1 server.

      Note:This External free busy folder will only be created on a new Exchange 2010 SP1 install when the option to create the public folders is selected during setup. The option is only presented if it's the first server installed in the organization. If a public folder database was not created during setup, you'll need to manually create this folder. The process to create this External folder is simple.

      1. Connect to the on-premise Exchange 2010 SP1 Public Folder server (this has to be done from the Public Folder server)
      2. Open Windows PowerShell
      3. Type " Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup"
      4. Then Type " Install-FreeBusyFolder"

      This will create the new Schedule Plus free busy folder called "External (FYDIBOHF25SPDLT)".

   3. Modify the LegacyExchangeDN on all mail-enabled objects that reference the remote organization and change the OU value to External (FYDIBOHF25SPDLT). As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query and route the request to the Availability service, which will then process the request as outlined in previous scenarios.
   4. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the TargetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This command populates the TargetSharingEPRproperty:

      Set-OrganizationRelationship –Identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

      Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. You can obtain it by running Get-WebServicesVirtualDirectory –Server 2010cas.contoso.com | fl Name, *url*

Figure 3: Exchange 2003 user requests availability information for user in remote org (Option B)

1. 1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the requesting client mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDNattribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines which Administrative Group the object was created in, and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).For example: LegacyExchangeDN=/o=First Organization/ou= External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou= External (FYDIBOHF25SPDLT)/is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.
   2. Step 2. Since the mail-enabled user has had the legacyExchangeDN modified, and the only replica of the External free/busy folder is on Exchange 2010, the Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
   3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox role intercepts the Free/Busy request and routes it to Availability.
   4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
   5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   6. Step 7. The response is generated by the Availability service in Org B and sent back to the Exchange 2010 SP1 CAS server in Org A.
   7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Known Issues/Concerns

Issue #1 - OWA 2003

When Exchange 2003 users use OWA to schedule a meeting, they will look at “Availability” tab in the form, which will request free/busy from public folders via DAV. A free/busy request for DAV looks like this:

http://ExchangeServer/public/?Cmd=freebusy&
start=2009-10-28T00:00:00-07:00&
end=2009-10-29T00:00:00-07:00&
interval=30&
mbxguid=ea14502f-44cc-41ae-9f1d-df519a16ad20&
u=SMTP:mary@Contoso&
u=SMTP:joe@Contoso.com

Note: The above text is actually a single line string, it was broken down into multiple lines for easy reading. DAV can only retrieve free/busy for users in the local public folder database. When OWA loads pages and scripts in the browser, it passes the URL to the public folder corresponding to the user mailbox. If the is no local replica for the folder corresponding to the first user provided in u= entry in the URL, DAV will do HTTP redirect (status 302) for the entire request to a public server that has that replica. Note this implementation assumes that free/busy for all other users provided in the request can also be found in the same server. The implication is that free/busy folders for different administrative groups must have replicas in all public folder databases. In our case, some or all free/busy folders will only have replicas on Exchange 2010, however Exchange 2010 does not support the DAV protocol, so OWA redirects to 2010 will simply fail. With Option A, this will cause ALL OWA Free/Busy requests (both internal and external) to fail, as the Exchange 2003 server will not have replicas of any Free/Busy public folders. With Option B, if the free/busy request is for a local mailbox user, the request will succeed. If the request is for a user from the remote org, the request will fail.

Issue #2 - Internal Free/Busy for Exchange 2003

Option A for Exchange 2003 requires that the only replicas for all free/busy folders must reside on Exchange 2010 SP1 servers. In environments where Exchange 2003 Public Folder databases are located in multiple physical sites, if Exchange 2010 Sp1 Public Folder databases are not located in the same physical sites, this may lead to issues with excessive latency and possible performance issues as internal free/busy queries may have to traverse WAN links.

Issue #3 - Queries for Exchange 2007 users cross-org fail

By default, Exchange 2007 allows availability queries for 42 days of information. Exchange 2010 bumped up that limit to 62 days. When Exchange 2010 performs the request for a user on Exchange 2007 in the remote organization, the request may fail because Exchange 2010 is requesting 62 days of information, which exceeds the default limit of 42 imposed by Exchange 2007. To address this issue, you can adjust the maximumQueryIntervalDays value in the EWS web.config (located in the \Program Files\Microsoft\Exchange Server\ClientAccess\ExchWeb\ews\ folder) on the Exchange 2007 servers. Add the value under the AppSettings section. This example configures the availability service on Exchange 2007 server to provide availability information for 62 days.

<appSettings>
<add key="maximumQueryIntervalDays" value="62" />
</appSettings>

Note: The maximumQueryIntervalDays value is not present by default. If this value is not present, Exchange uses the default interval of 42 days.

After you do this, you will want to do an IISReset on the Exchange 2007 CAS servers to make sure the new setting takes effect, as this value is only read on startup.

Issue #4 - Queries for Exchange 2003 users cross-org fail

By default, an Exchange 2010 CAS performing a cross-org free/busy lookup will query the autodiscover service for the user you're attempting to view Free/Busy for. If the target user is an Exchange 2003 user, autodiscover will fail because Exchange 2003 users are not autodiscover-enabled. This issue is scheduled to be fixed in Exchange 2010 SP1 Update Rollup 4. To work around this issue, manually set the targetSharingEPR on the Organization Relationship for the remote organization with Exchange 2003. Example:

Set-OrganizationRelationship –identity -targetSharingEPR https://mail.contoso.com/ews/exchange.asmx/WSSecurity

Update: The issue has been fixed in Exchange 2010 SP1 Update Rollup 4. See KB 2506820. The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server.

An additional issue with queries for remote Exchange 2003 users is that the remote organization will return the Free/Busy response in the format of a MergedOnly string. Exchange 2010 cannot convert this string to store the result in public folders, so no information is returned to the Outlook client.  A fix is available for this issue. See KB 2567863 Free/Busy information may not be returned when a Cross-Org query is performed from a legacy Exchange user.

Issue #5 - Federating with another Organization that has both on-premises and cloud users

If you federate with another organization that subscribes to a cloud service such as Office 365 or BPOS, availability lookups for remote users that have been moved to the cloud will fail. The reason is that your organization relationship is with the on-premises Organization. That on-premises org has a completely separate Organization Relationship with O365/BPOS. When an availability call is made from a separate org via an Organization Relationship, it'll be made to the on-premises org, where a mail-enabled user or contact will be found. There's no functionality to proxy the availability call through the Organization Relationship from the on-premises Org to the cloud, so this call will fail. Ben Winzenz

[#2]

Thank you very much for this! I currently have a test environment for rich coexistence Exchange 2003 (hybrid) with Office 365. Whenever I remove the free/busy replica from Exchange 2003 and I try to access the availability page using OWA 2003, it completely fails! Now I know why! Issue #1 says it all!

[#3]

Based on the release of Exchange 2010 SP1 Rollup Update 4 and the fix for federation using SSL offloading in TMG I think a scenario of sites having TMG in place should be added to this article.  There are some definite hurdles that TMG adds to this configuration and it would be nice to see them addressed.

[#4]

@PeteKr - I would have loved to included a scenario for TMG, but I did not test that configuration. Perhaps that is something we can put in a future blog post. Thanks for the suggestion!

[tomacfrmrMSFT]

Is there a similar article for OnPrem + O365  <---> OnPrem + O365 calendar sharing, different orgs?