Sharing mailboxes and data across forests is possible, but it requires some fancy configuration footwork.
Q. We’re a large company running Exchange 2010. Our Exchange clients are a mix of Outlook 2007 and Outlook 2010. We’ve just acquired another company running Exchange 2007, and using Outlook 2007 clients. We’re eventually going to merge the infrastructures, but because each company consists of more than 100,000 users, we need to establish rich coexistence before moving on to the actual migration.
Could you provide us with some recommendations on how to approach coexistence for Exchange with this specific mix of Outlook clients? We’re aiming to share free/busy information and calendars between the Exchange forests.
A. This is a somewhat complex topic, but you essentially have the following options:
The MFG service is a relatively new service (see Figure 1), introduced with Exchange 2010. The federation features in Exchange 2010 take advantage of this new Windows Live-based service.
Basically, MFG acts as a trust broker between Exchange 2010 organizations that want to share data. It’s important to stress that although it uses a Microsoft gateway to establish federation trusts between Exchange 2010 organizations, no data from any of the involved Exchange organizations is shared with Microsoft. The MFG simply ensures security when publishing domain information and enabling domain access to data.
Figure 1 The Microsoft Federation Gateway helps share data between domains.
The new federation features don’t require any trust relationships or data replication between the involved Exchange forests. In your case, for an Exchange 2010 user to view the free/busy status for a user in another organization, the Outlook 2007/2010 user would simply type that person’s e-mail address in the scheduling assistant.
Using sharing policies, you can specifically set what data you want to share and at what level that data should be shared (see Figure 2). Within the organizational sharing policy, you can create a sharing policy. Here you can specify how much information and with which domain users should be able to share.
Figure 2 When establishing a new share relationship, you have granular control over the extent of sharing.
You mention the company you’ve acquired uses Exchange 2007. It’s important to note that Exchange 2007 doesn’t directly support MFG. You can deploy an Exchange 2010 Client Access server within the Exchange 2007 forest, and take advantage of down-level proxy support.
MFG doesn’t require a mailbox user from the other Exchange forest to be represented as a mail-user object, so that isn’t required to configure GALSync between the forests. It would, however, make sense in a coexistence scenario where you want to provide your users with a unified Global Address List (GAL) experience.
If you use the built-in availability service, you must configure GALSync (to represent mailbox users in the remote forest as mail-enabled user [MEU] objects in the local forest) and use the Add-AvailabilityAddressSpace cmdlet to add the respective namespace.
You should also note that each Exchange forest should be able to connect to the availability service in the other org using the Fully Qualified Domain Name specified for the Internal URL of the Exchange Web Services virtual directory. You should establish a forest-wide trust relationship between the forests. This will let you configure the availability service to retrieve free/busy information on a per-user basis. For more information on cross-forest availability topologies, see the Exchange 2010 TechNet documentation.
In your scenario, you don’t have Outlook 2003 clients in the mix. If so, you would also need to configure InterOrg to replicate free/busy information across the forests, as Outlook 2003 doesn’t support the Availability service. Because you want to configure temporary coexistence between two Exchange forests on private networks, I would recommend using the Availability service.
Q. We’re planning on configuring cross-forest availability between two Exchange forests using the Add-AvailabilityAddressSpace cmdlet. Is this supported if the Exchange forests share the same SMTP address space?
A. Yes, this scenario is supported, but there’s an important detail. When using the Add-AvailabilityAddressSpace cmdlet to configure free/busy and calendar sharing between two Exchange forests, you must deploy GALSync to represent mailbox users in the remote forest as MEU objects in the local forest (see Figure 3). As you probably know, an MEU object forwards all e-mail to an external e-mail address (the target Address attribute of the object).
Figure 3 Sharing calendar data across forests requires the proper configuration.
When an Exchange mailbox user in one forest requests free/busy information for a mailbox user in another forest, the availability service sends the request to the external e-mail address of the MEU object that represents the mailbox user in that other forest.
When using the same SMTP address space in both Exchange forests, the domain part of the target Address will obviously be the same in both forests. For this reason, the availability service won’t know how to reach the other forest. Exchange uses auto-discover to determine where it should send the availability request. Because auto-discover uses the primary e-mail address for a mailbox user or the external e-mail address for an MEU object, this needs to point to the address space of the forest where the user’s mailbox is located.
So in order to get this working properly, you must use a unique primary SMTP address space for each organization. Then include the shared SMTP address space as a secondary proxy address on the MEU objects. You must also configure auto-discover for the two unique address spaces and configure cross-forest connectors so mail flow works accordingly.
Q. We’re an Exchange 2010 shop, and our users often access a shared mailbox. We added the shared mailbox as an additional mailbox in each user’s Outlook profile.
This works fine, except for the fact that e-mail messages sent from the additional mailbox go into the “Sent items” folder of the primary mailbox within a user’s profile. In order for the other users accessing the shared mailbox to keep track of the activity in the shared mailbox, it’s important for us that outgoing messages are stored in the “Sent items” folder of the shared mailbox. We’re using Outlook 2010 clients. Do you know if this is possible?
A. This is a common situation, and not just with Exchange 2010 and Outlook 2010. Although it isn’t well known, you’ve been able to change this standard behavior using an Outlook client-specific registry key. When adding the registry key, when you reply to or forward e-mail messages located in the shared mailbox, they actually go into the expected “Sent items” folder.
To change the “Sent items” behavior, you need to create the following registry key:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\PreferencesName: DelegateSentItemsStyleType: DWORDValue: 1
Note that it needs to be created on HKEY_CURRENT_USER.
Q. We’re in the planning stages of deploying Exchange 2010 in our company. We have approximately 130,000 mailboxes on Exchange 2007. When we transitioned to Exchange 2007, we found a Microsoft white paper that explained how Microsoft IT designed the Exchange 2007 solution for Microsoft. Do you know if a similar white paper for Exchange 2010 exists?
A. One of my colleagues, Kay Unkroth at Biblioso Corp., wrote the Exchange 2007 solution for Microsoft paper for the Microsoft IT Showcase. He also wrote many other Exchange 2007-specific white papers, some of which I actively worked on as well. You can find all the Exchange 2007-specific white papers published by Microsoft IT Showcase over the years in the TechNet Library.
Microsoft IT has also published Exchange 2010-specific white papers. These were published when Exchange 2010 was released. You can find them on the same TechNet Library page.
Microsoft IT Showcase also publishes white papers describing other technologies such as Lync Server, Microsoft Forefront, Office 365 and so on. You might want to consider subscribing to the Microsoft IT Showcase RSS feeds to keep up on what has been released.
Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years experience in the IT business. He works as a technology architect for Timengo Consulting and as a technical writer for Biblioso Corp. (a U.S.-based company specializing in managed documentation and localization services).
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.