Cross Org Free/Busy with Federation Trust and NETsec GALsync

A reply to

"Cross Org Availability using Federation Trust and Organization Relationship" - Published by The Exchange Team 28 Jun 2011 1:30 PM

By

NETsec GALsync - Published at http://netsec.de/products/galsync

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 2010 SP1



[1] see: http://blogs.technet.com/b/exchange/archive/2011/06/28/cross-org-availability-using-federation-trust-and-organization-relationship.aspx

 

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.

 

You need NETsec GALsync in this scenario

1.      If the companies are not able to use Federated Delegation (i.e. no internet publishing of web services) but need a cross-forest sync of directory information.

2.       If the companies need the partner's directory information in its own directory. With GALsync the partner's directory information are stored in your own Active Directory - so it can be used offline. With Federation all required information only are online available. If Internet connection breaks or user work in offline mode no data are present.

 

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.

 

You need NETsec GALsync in this scenario

 

1.      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.

2.      if you need free/busy information only for a small group of users, you might use free/busy feature of our GALsync software. If you use a lot of users for free/busy, do dirsync with GALsync and with Federation you do free/busy sharing.

 

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.

 

You need NETsec GALsync in this scenario

 

1.      If the companies are not able to use Federated Delegation (i.e. no internet publishing of web services) but need a cross-forest sync of directory information.

2.      if you cannot move all free/busy folders to an Exchange 2010 server

3.      If the companies need the partner's directory information in its own directory. With GALsync the partner's directory information are stored in your own Active Directory - so it can be used offline. With Federation all required information only are online available. If Internet connection breaks or user work in offline mode no data are present.

 

 

Option B

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.       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.

 

You need NETsec GALsync in this scenario

 

1.      If the companies are not able to use Federated Delegation (i.e. no internet publishing of web services) but need a cross-forest sync of directory information.

2.      If you want the partners objects stored in your Active directory (done with GALsync) and you use Federation for free/busy. GALsync will set the required LegacyExchangeDN value automatically.

 

 

 

No TrackBacks

TrackBack URL: http://www.publizistik-projekte.de/cgi-bin/mt/mt-tb.cgi/1188

Downloads

About This Blog

Archives