Deep dive into rich coexistence between Exchange Forests (Part 7)

If you would like to read the other parts in this article series please go to:

 

 

 

Introduction

 

In part 6, we first ran the GALSync MAs in order to verify FIM stages (imports) and exports objects properly for each Exchange forest. Moreover, we configured automatic run profiles for each GALSync MA and then verified that the objects exported to each Exchange forest were properly stamped with required attributes. Lastly, we created two new address lists in each Exchange forest.

 

We have now completed the FIM 2010 based synchronization between the forests, which means that from this part 7 we will begin talking about and configuring availability sharing between the Exchange forests. First, we will look at the cross-forest availability scenarios we have available at our disposal then we will prepare the Active Directory forests for cross-forest availability lookups.

 

Let’s get going! Although we have now covered the GALSync stuff, we still have a long way to the end of this articles series.

 

Cross-Forest Availability Options & Scenarios

 

When it comes to looking up free/busy information across forests, the method that can be used depends on the Exchange versions that are to share this information.

 

With Exchange 2003 and earlier versions, there were no native features that made it possible to share free/busy information across forests. So in order to accomplish this goal, organizations typically used a little tool from Microsoft known as the Microsoft Exchange Server Inter-Organization Replication tool or in short Microsoft InterOrg. The tool serves two purposes:

 

 

  • Migrate public folders between Exchange forests

     

  • Replicate free/busy information between Exchange forests

 

The InterOrg tool follows the same support lifecycle as Exchange 2003 and because of this it’s only supported when one of the Exchange forests run Exchange 2003. Said in another way, the following is supported:

 

 

  • Exchange 2003 <> Exchange 2003

     

  • Exchange 2003 <> Exchange 2007

     

  • Exchange 2003 <> Exchange 2010 SP1 or later (RTM didn’t support this)

 

The following scenarios are NOT supported:

 

 

  • Exchange 2007 <> Exchange 2007

     

  • Exchange 2007 <> Exchange 2010

     

  • Exchange 2010 <> Exchange 2010

 

The InterOrg tool is public folder based and works by replicating free/busy information between Exchange forests. More specifically, it replicates the content of the “SCHEDULE+ FREE BUSY” system  folder.

 

When using InterOrg to share free/busy information between Exchange forests, the users in the remote forest must be represented in the local Exchange forest in the form of a mail-enabled contact or user object. This object must have  the primary SMTP address of the mailbox it’s representing configured as the external e-mail address (aka targetAddress) as the primary SMTP address is the unique key that is used to match a mailbox with a mail enabled contact or user object.

 


Figure 1: External email address for a contact object in Exchange 2003

 

With Exchange 2007 the InterOrg was no longer required (if both ends ran Exchange 2007 or later that is) as this version introduced the availbility service, which besides being used for local forest free/busy lookups for Outlook 2007 (and later as Outlook 2003 doesn’t support this service), also had support for cross-forest availability. To get it up and running you had to configure GALSync and then add the domain of the other Exchange forest to the availability address space domain list.

 

With Exchange 2010 things improved further as this version not only has support for cross-forest free/busy lookups via the availability service, it can also be configured to used a Windows Live based service known as the Microsoft Federation Gateway or in short MFG to share free/busy information and other things across Exchange forests. Since MFG is supported by Exchange 2010 only, you must have Exchange 2010 in both ends to configure cross-forest free/busy lookups. But it doesn’t need to be pure Exchange 2010 forests. You see Exchange 2010 has download-level proxy support, which means that you would be able to deploy one or more Exchange 2010 Client Access servers in an Exchange 2003 or 2007 forest and this way be able to share free/busy information between Exchange 2003 or 2007 users in one forest with 2003 or 2007 Exchange users in another. Pretty neat eh?

 

When you configure a federation trust between an Exchange on-premise environment and Office 365, it’s also MFG that in part is used behind the scene. This means that you could configure free/busy sharing between Exchange 2003 or 2007 users in an on-premise environment and Exchange users in Office 365 as long as you have at least one Exchange 2010 CAS server in the on-premise environment. We’ll look closer at how you configure free/busy sharing between an Exchange 2010 on-premise forest and Office 365 later, however the steps on how this is accomplished is outside the scope of this articles series.

 

Note:
Like is the case when using InterOrg, when using the Availability service to share free/busy information between Exchange forests, the users in the remote forest must be represented in the local Exchange forest in the form of a mail-enabled contact or user object. This object must have the primary SMTP address of the mailbox it’s representing configured as the external e-mail address (aka targetAddress) as the primary SMTP address is the unique key that is used to match a mailbox with a mail enabled contact or user object.

 

Cross-Forest Free/Busy Sharing using the Availability Service

 

When using the availability service to share free/busy information between two Exchange 2007/2010 forests, you can either use an untrusted (meaning a trust relationship isn’t configured between the Exchange forests) or trusted (meaning a trust relationship is configured between the Exchange forests) approach.

 

If a trust relationship hasn’t been configured, you need to configure free/busy sharing between the Exchange forests using the so called “organization-wide” method. When using this method, the Availability service is limited to making cross-forest requests on behalf of the organization, which means that the queried users default free/busy information is returned. This should be sufficient for most organizations, but some organizations want users to be able to set the level of detail. This is where the trusted approach comes into the picture. When using the trust approach, you can configure free/busy sharing on the “Per-User” level. When doing so the Availability service can do a cross-forest request on behalf of a particular user. This makes it possible for the requesting user to see detailed free/busy infromation for a user in the other Exchange forest.

 

An Exchange user can set the free/busy permission level using an Outlook client as shown in Figure 2. The default permission level is “Free/Busy time”, but it can be changed to “Free/Busy time, subject, location which is also known as detailed free/busy information.

 


Figure 2: Detailed free/busy setting in Outlook

 

Outlook Client Requirements

 

So when you want Exchange users in one forest retrieve free/busy information for Exchange users in another forest and vice versa, there are some clients-side details you need to incorporate into the bigger picture before you decide which approach you want to go with.

 

So if all users use Outlook 2007 or 2010, you have nothing to worry about as these Outlook versions support the Availability service, MFG and InterOrg based approach.

 

First of all the Exchange forest in which you have Outlook 2003 clients of course requires public folders since this Outlook client version can only use the “SCHEDULE+ FREE BUSY” system  folder to retrieve free/busy information.

 

Second, if you have users in an Exchange 2007 and Exchange 2010 forest and the users (or a set of users) in each forest use Outlook 2003 and need to to be able to lookup free/busy information cross-forest, the users in the Exchange 2010 forest will be able to do so for users in the Exchange 2007 forest. Only requirement is you add the SMTP domain of the Exchange 2007 forest to the availability address space list in the Exchange 2010 forest and do the other required cross-forest Availability service configuration steps we will cover in this article series. The way this works is shown below:

 

 

  1. An Exchange 2010 user using Outlook 2003 request free/busy information for an Exchange user in the Exchange 2007 forest.

     

  2. Outlook 2003 connects to the “SCHEDULE+ FREE BUSY” system  folder in a public folder database in the Exchange 2010 forest.

     

  3. The RPC Client Access service on an Exchange 2010 server intercepts the free/busy request and sends it to the Availability service on an Exchange 2007 Client Access server in the Exchange 2007 forest.

     

  4. The Exchange 2007 CAS server retrieves the free/busy information in the respective mailbox and returns it to the RPC Client Access service in the Exchange 2010 forest.

 

So as you can see, the key thing here is the RPC Client Access service.

 

If you have an Exchange 2007 user using Outlook 2003 in a pure Exchange 2007 forest requesting free/busy information for an Exchange user in an Exchange 2010 forest (or Exchange 2007 forest for that matter) this will not work since the RPC Client Access service was introduced with Exchange 2010. More specifically, there’s no logic in Exchange 2007 that will intercept the free/busy request going to the “SCHEDULE+ FREE BUSY” system  folder and send it off to an Exchange 2007 or 2010 Client Access server in the other forest.

 

In order to resolve this issue, you will need to introduce an Exchange 2010 Client Access server in any Exchange 2007 forest.

 

Oh and just so we’re all on the same track, this is only an Outlook 2003 client thing. Not so with Outlook 2007 or 2010.

 

This concludes part 7 of this articles series. Hope you learned something new.

 

If you would like to read the other parts in this article series please go to:

 

 

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top