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.
This summary table outlines the requirements in order to facilitate Availability lookups between two organizations:
*refer to “Option A” and Option B” which are discussed later in this post
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.
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.
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.
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.
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.
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.
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
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*
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.
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.
This will create the new Schedule Plus free busy folder called "External (FYDIBOHF25SPDLT)".
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)
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.
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:
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.
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.
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.
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.
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.
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.