Exchange Queue & A: Moving online

You’ll have some decisions to make when moving e-mail from on-premises to a cloud-based environment such as Exchange Online.

Henrik Walther

Across the forest

Q. We’re running Exchange 2010 within a large enterprise organization. We have a business partner running Exchange 2007. We need to be able to share calendars and free/busy information with this partner. Because of this, we’ve configured cross-forest availability per the instructions for Exchange 2010 in the TechNet Library.

However, even after having verified we can resolve and perform autodiscover requests between forests, we still can’t retrieve free/busy information. Do you have any idea what’s preventing this?

A. Since Exchange 2007 released to manufacturing (RTM), there has been something of a bug that results in autodiscover using the internal URL of the Exchange Web Services (EWS) virtual directory when looking up free/busy information for cross-forest users (see Figure 1). By default, the internal URL of the EWS virtual directory points to CAS_server.fqdn.com. Therefore, it must be resolvable. This also means the Fully Qualified Domain Name (FQDN) needs to be resolvable.

Figure 1 Autodiscover will use the Exchange Web Services virtual directory internal URL by default.

Although this is far from ideal, there are fixes that change this behavior for both Exchange 2007 and Exchange 2010. When it comes to Exchange 2007, apply the Update Rollup 6 for Exchange Server 2007 SP3. For Exchange 2010, apply the Update Rollup 1 for Exchange 2010 SP2. With the fix applied, you’ll be able to send free/busy requests over the Internet. It will work fine in Exchange proxy site topologies as well. With the fix applied, the source Client Access Server (CAS) will honor the external URL for the EWS virtual directory and won’t default to using the internal EWS URL.

Keep in mind that after you apply this fix, the external URL for EWS must be resolvable between the Exchange forests sharing free/busy information. You can’t configure the availability service to use the internal EWS URL for cross-forest availability lookups.

Online authentication

Q. We’re currently in the planning phases of moving our Exchange 2007 on-premises messaging infrastructure to the Exchange Online component of Office 365. Our plan is to configure an Exchange hybrid deployment and identity federation.

One thing we’re a little unsure about is support for authentication with multiple user principal name (UPN) suffixes. We’ve heard that in order to have some users authenticate against Active Directory Federation Services (ADFS) with alias@domain1.com and other users authenticate with alias@domain2.com, we need one ADFS federation farm per UPN we want to use for authentication purposes. Can you shed some light on this?

A. Here’s the situation. Prior to Update Rollup 1 (note Update Rollup 2 is available and the one you should use) for ADFS 2.0 release to Web (RTW), enterprises that implemented ADFS-based identity federation with Office 365 were required to deploy one ADFS federation farm per UPN that needed to authenticate against an Office 365 service. This meant the enterprise had to deploy two ADFS proxy servers and two ADFS servers per supported UPN. So this would require eight servers to support two UPNs. You could go with one ADFS proxy server and one ADFS server per UPN, but you really don’t want to introduce a single point of failure.

Now Update Rollup 1 or later for ADFS 2.0 RTW supports multiple UPNs per ADFS federation farm. One of my recently published blog postings, "Office 365 – ADFS & Support for Multiple UPNs," walks you through how to introduce support for an additional UPN into your existing ADFS deployment (see Figure 2).

Figure 2 You’ll have to ensure you have the proper infrastructure to support ADFS authentication.

Saving servers

Q. We’re moving from our on-premises Exchange 2003-based messaging infrastructure to the Exchange Online part of Office 365. We’re setting up a hybrid configuration to achieve rich coexistence. We also want to configure identity federation, but we don’t have the budget for four additional servers in our on-premises environment.

We currently have four Exchange 2003 servers. For the Exchange hybrid deployment, we’re already deploying two Exchange 2010 servers. We’re also deploying a server for the directory synchronization. Do you know how we can keep the number of required servers to a minimum while also achieving high availability?

A. There are two options for configuring identity federation. As you already know, you’ll need two ADFS servers on the internal network and two ADFS proxy servers in the perimeter network. If you have fewer than 1,000 users, installing the ADFS component on two existing domain controllers in the on-premises environment is actually a viable solution (see Figure 3). When it comes to ADFS proxy servers, you can use two existing Web servers or proxy servers in the perimeter network. For details, see “Estimation table: Determine the number of ADFS 2.0 servers to deploy in your organization” in the “Plan for and deploy ADFS 2.0 for use with single sign-on” article on the Microsoft Office 365 community site.

Figure 3  There are specific guidelines to support your Office 365 deployment.

If you have more than 1,000 users, you should use dedicated servers both for the internal ADFS servers and ADFS proxy servers. These can be virtual servers. If you have more than 1,000 users and don’t want to deploy dedicated ADFS servers in your on-premises environment, there’s another option. You can create virtual ADFS servers in Windows Azure and establish a Virtual Private Network (VPN) for your on-premises environment. This helps keep the number of servers down without sacrificing high availability (HA), which is a no-go for ADFS. Having ADFS results in users not being able to access Office 365.

You could also just use Windows Azure as a failover site for ADFS. Deploy one ADFS server and one ADFS proxy server in your on-premises environment and the others in Windows Azure. The latter will require a DC in Windows Azure as well. So you have a couple of options for resolving your current deployment blocker.

Preview problems

Q. We’ve set up a new tenant in Office 365 Preview (wave 15). We were able to synchronize user objects to the tenant using the DirSync tool. However, when we try to add the tenant using “Add Exchange Forest” in the Exchange 2010 SP2 Management Console, we get the following error:
“The following error occurred when getting management role assignment information for ‘server.pord.outlook.com/Microsoft Exchange Hosted Organizations/tenant_name.onmicrosoft.com/globaladmin’:
Microsoft.Exchange.Data.Directory.Management.ExchangeroleAssignmentPresentation is not supported by MockEngine!”

Any ideas?

A. You’ll need to apply Exchange 2010 SP3 to be able to add an Office 365 Preview (wave 15) tenant to the Exchange 2010 Management Console. Because this service pack won’t be released before the first half of calendar year 2013, what you’re trying to do isn’t currently supported unless you’re participating in the Office 365 Preview or Exchange Technology Adoption Program.

Henrik Walther* is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 16 years of experience in the IT business. He works as a technology architect for a Microsoft Gold Certified Partner in Denmark, and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services). He’s also a contracted vendor working on various product teams (including the Exchange and Lync teams) at Microsoft.*

Related Content

• Exchange Queue & A: Migrations and Updates
• Exchange Queue & A: Across the Forest
• Exchange Q&A: Workable Work-Arounds