Cross Org Free/Busy with Federation Trust and NETsec GALsync

14 Oct

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.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *