If you would like to read the other parts in this article series please go to:
- Deep dive into rich coexistence between Exchange Forests (Part 1)
- Deep dive into rich coexistence between Exchange Forests (Part 2)
- Deep dive into rich coexistence between Exchange Forests (Part 3)
- Deep dive into rich coexistence between Exchange Forests (Part 4)
- Deep dive into rich coexistence between Exchange Forests (Part 5)
- Deep dive into rich coexistence between Exchange Forests (Part 6)
- Deep dive into rich coexistence between Exchange Forests (Part 7)
- Deep dive into rich coexistence between Exchange Forests (Part 9)
- Deep dive into rich coexistence between Exchange Forests (Part 10)
- Deep dive into rich coexistence between Exchange Forests (Part 11)
- Deep dive into rich coexistence between Exchange Forests (Part 12)
- Deep dive into rich coexistence between Exchange Forests (Part 13)
- Deep dive into rich coexistence between Exchange Forests (Part 14)
- Deep dive into rich coexistence between Exchange Forests (Part 15)
Introduction
In part 7, we talked about the different cross-forest availability options and scenarios we have at our disposal. More specifically what method is supported for the respective Exchange versions. We also talked about the differences when it comes to per-user and per-organization free/busy information cross-forest. Finally, I explained which Outlook client versions are supported and how.
In this part 8 (wow are we already at part 8?), we will begin on the configuration steps necessary to establish free/busy sharing between Exchange forest 1 (Exchange 2010 forest) and Exchange forest 2 (Exchange 2007 forest). We will do so using the per-user free/busy method so that users in each org can see detailed free/busy information for mail users cross-forest.
Let’s get going!
Configuring Exchange Forest 1 (Exchange 2010)
In this section we will go through the configuration steps necessary to make it possible for users in Exchange forest 1 (Exchange 2010) to view free/busy information for users in Exchange forest 2 (Exchange 2007).
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 2 (Exchange 2007) to the availability address space list. To do so, open the Exchange Management Shell (EMS) on an Exchange 2010 server in Exchange Forest 1 and then enter the following command:
Add-AvailabilityAddressSpace -ForestName e2k7forest.dk -AccessMethod PerUserFB -UseServiceAccount $true
Figure 1: Add the SMTP domain from Exchange fores 2 to the address space list in Exchange forest 1
In this case we use the PerUserFB access method since we want users to see detailed free/busy information for users in Exchange forest 2 (Exchange 2007). Remember that for this to work you need to have established a trust realtionship between the forests (refer to part 2 of this articles 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 2010 documentation on Microsoft TechNet.
Set Required Permissions in Exchange Forest 2 (Exchange 2007)
Now in order for the Availability service in Exchange Forest 1 (Exchange 2010) to retrieve free/busy information for users in Exchange forest 2 (Exchange 2007), we need to give special permissions to the “Exchange Servers” group. To do so open an Exchange Management Shell (EMS) in Exchange forest 2 (Exchange 2007) and then enter the following command:
Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights “ms-exch-epi-token-serialization” -User “e2k10forest.dk\Exchange Servers”
Figure 2: Assigning special permissions to the Exchange Servers group in Exchange forest 2 (Exchange 2007)
Configuring Autodiscover support for Exchange forest 2 in Exchange Forest 1
When a user in Exchange forest 1 (Exchange 2010) requests free/busy informtion for a user in Exchange forest 2 (Exchange 2007), the following logic takes place:
-
Exchange 2010 user finds the Exchange 2007 user in the GAL in form of a mail user object and adds it to the scheduling assistant
-
Outlook sends free/busy request to the Exchange 2010 Availability service
-
The Availability service sends the request off to the forest on the Availability address space lists that have a domain name matching the external SMTP address of the mail user
As most of you probably know the Availability service is based on autodiscover, so guess how Exchange 2010 will try to reach out to the Availability service in the Exchange forest 2 (Exchange 2007)? Yes using autodiscover. Said in another way, the Exchange 2010 Availability service must be able to connect to the Autodiscover service in the Exchange 2007 forest. 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 2007 and import it to the Exchange 2010 forest. Steps on how to achieve this are explain here. The other option is to rely on DNS. More specifically make it possible for the Exchange 2010 Availability service to resolve autodiscover.e2k7forest.dk via local DNS.
Since I’m a big fan of keeping things simple, I prefer the DNS based approach.
Create autodiscover DNS record in 2007 forest
Since we already have DNS resolution working beteween the two forests (refer to part 1), we just need to create the autodiscover in the “e2k7forest.dk” DNS zone in Exchange forest 2 (Exchange 2007). To do so we’ll log on to a domain controller in Exchange forest 2 and open the DNS Manager. In here right-click on the “e2k7forest.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 1 (Exchange 2010) and verify that you can ping or do a NSLOOKUP for autodisocver.e2k7forest.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 1 (Exchange 2010)
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 and therefore 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 2007 CAS server, so it won’t be an issue here.
If you would like to read the other parts in this article series please go to:
- Deep dive into rich coexistence between Exchange Forests (Part 1)
- Deep dive into rich coexistence between Exchange Forests (Part 2)
- Deep dive into rich coexistence between Exchange Forests (Part 3)
- Deep dive into rich coexistence between Exchange Forests (Part 4)
- Deep dive into rich coexistence between Exchange Forests (Part 5)
- Deep dive into rich coexistence between Exchange Forests (Part 6)
- Deep dive into rich coexistence between Exchange Forests (Part 7)
- Deep dive into rich coexistence between Exchange Forests (Part 9)
- Deep dive into rich coexistence between Exchange Forests (Part 10)
- Deep dive into rich coexistence between Exchange Forests (Part 11)
- Deep dive into rich coexistence between Exchange Forests (Part 12)
- Deep dive into rich coexistence between Exchange Forests (Part 13)
- Deep dive into rich coexistence between Exchange Forests (Part 14)
- Deep dive into rich coexistence between Exchange Forests (Part 15)
