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

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

 

 

 

Introduction

 

In part 9, we exported the root and intermediate certificates from Exchange forest 2 (Exchange 2007) and imported them to the Exchange 2010 CAS server in Exchange forest 1 (Exchange 2010). We also modified the EWS Web.config file so that free/busy queries larger than 42 days don’t fail. Finally we tested free/busy from OWA 2010 and Outlook 2007 and also had a look at the possibilities available when it comes to looking up availability information cross-forest.

 

In this part 10, we will perform the configuration steps required to look up free/busy information from Exchange forest 2 (Exchange 2007) to Exchange forest 1 (Exchange 2010). The steps are very similar to those we already been through in order to configure free/busy lookups from Exchange forest 1 to Exchange forest 2, but I’ll included them (although with fewer figures) as this article series should be considered a complete walkthrough for cross-forest availability scenarios.

 

Configuring Exchange Forest 2 (Exchange 2007)

 

In this section we will go through the configuration steps necessary to make it possible for users in Exchange forest 2 (Exchange 2007) to view free/busy information for users in Exchange forest 1 (Exchange 2010).

 

Add SMTP domain to the Availability Address Space list

 

Okay so the first thing we want to do is to add the SMTP domain for Exchange forest 1 (Exchange 2010) to the availability address space list. To do so, open the Exchange Management Shell (EMS) on an Exchange 2007 server in Exchange Forest 2 and then enter the following command:

 

Add-AvailabilityAddressSpace -ForestName e2k10forest.dk -AccessMethod PerUserFB -UseServiceAccount $true

 


Figure 1: Add the SMTP domain from Exchange forest 1 to the address space list in Exchange forest 2

 

In this case we use the PerUserFB access method since we want users to see detailed free/busy information for users in Exchange forest 1 (Exchange 2010). Remember that for this to work you need to have established a trust realtionship between the forests (refer to part 2 of this article series). If you can’t set up a trust relationship you should replace “PerUserFB” with “OrgWideFB” and set an organization-wide account on the Availability service configuration object. Since this is outside the scope of this article series instead see this section in the Exchange 2007 documentation on Microsoft TechNet.

 

Set Required Permissions in Exchange Forest 1 (Exchange 2010)

 

Now in order for the Availability service in Exchange Forest 2 (Exchange 2007) to retrieve free/busy information for users in Exchange forest 1 (Exchange 2010), we need to give special permissions to the “Exchange Servers” group. To do so open an Exchange Management Shell (EMS) in Exchange forest 1 (Exchange 2010) and then enter the following command:

 

Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights “ms-exch-epi-token-serialization” -User “e2k7forest.dk\Exchange Servers”

 


Figure 2: Assigning special permissions to the Exchange Servers group in Exchange forest 1 (Exchange 2010)

 

Configuring Autodiscover support for Exchange forest 2 in Exchange Forest 1

 

When a user in Exchange forest 2 (Exchange 2007) requests free/busy informtion for a user in Exchange forest 1 (Exchange 2010), the following logic takes place:

 

 

  1. Exchange 2007 user finds the Exchange 2010 user in the GAL in form of a mail user object and adds it to the scheduling assistant
  2. Outlook sends free/busy request to the Exchange 2007 Availability service
  3. The Availability service sends the request off to the forest on the Availability address space list that have a domain name matching the external SMTP address of the mail user

 

Just like it’s the case with Exchange 2010, the Exchange 2007 Availability service is based on autodiscover, so Exchange 2007 will reach out to the Availability service in Exchange forest 1 (Exchange 2010) using the exact same method – Autodiscover. Said in another way, the Exchange 2010 Availability service must be able to connect to the Autodiscover service in the Exchange 2010 forest. As with Exchange 2010, we have two options to accomplish this. If there’s a trust relationship in place between the forests, we have the option of exporting the service connection point (SCP) configuration from Exchange 2010 and import it to the Exchange 2007 forest. Steps on how to achieve this are explained here. The other option is to rely on DNS. More specifically make it possible for the Exchange 2007 Availability service to resolve autodiscover.e2k10forest.dk via local DNS.

 

As you already know, I’m a big fan of keeping things simple, so once again we’ll use the DNS based approach.

 

Create autodiscover DNS record in 2010 forest

 

Since we already have DNS resolution working between the two forests (refer to part 1), we just need to create the autodiscover in the “e2k10forest.dk” DNS zone in Exchange forest 1 (Exchange 2010). To do so we’ll log on to a domain controller in Exchange forest 1 and open the DNS Manager. In here right-click on the “e2k10forest.dk” forward zone and select “New Host (A or AAAA)” in the context menu as shown in Figure 3.

 


Figure 3: Right-clicking on the respective forward zone in the DNS Manager

 

In the New host dialog box enter autodiscover and the IP address of a Client Access server or a virtual IP address pointing at a load balancing solution then click OK.

 


Figure 4: Creating the autodiscover record

 

With the record created let’s switch back to Exchange forest 2 (Exchange 2007) and verify that you can ping or do a NSLOOKUP for autodisocver.e2k10forest.dk. You may need to flush DNS using “ipconfig /flushdns” in order for this to work.

 


Figure 5: Ping the new autodisocver record/FQDN from Exchange forest 2 (Exchange 2007)

 

Since we use conditional forwarding based DNS resolution between the forests and only have one Active Directory site and domain to deal with, we can look up all servers from one forest to the other and vice versa.

 

Impotant:
Back since Exchange 2007 RTM, there has been what can be considered a bug which results in autodiscover to use the internal URL of the web service virtual directory (EWS) when looking up free/busy information for a user cross-forest. By default the internal URL of the EWS virtual directory points to CAS_server.fqdn.com which means it must be resolvable, which means that this FQDN needed to be resolvable. Well while I wrote this article series a fix for this issue was released for both Exchange 2007 and Exchange 2010. It’s inlcuded in Exchange 2007 SP3 RU6 and Exchange 2010 SP2 RU1 respectively. With the fix applied, you can now send the free/busy requests over the Internet and it will work just fine in Exchange proxy site topologies as well. This is because with the fix applied the source CAS server will honor the external URL for the EWS virtual directory (if one is specified).

 

In this lab we just have one Exchange 2010 CAS server, so it won’t be an issue here.

 

Okay with this part 10 of this article series ends.

 

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

 

 

About The Author

Leave a Comment

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

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

Scroll to Top