Exchange Queue & A : Configuration Conundrums
Replication, configuration and migration continue to be on the minds of Exchange administrators.
Henrik Walther
Replication Routes
Q: We’re currently deploying an Exchange 2010 messaging infrastructure. We’re planning our migration later this year. We’re configuring the Mailbox servers in one large database availability group (DAG). The DAG member servers will be spread across multiple Active Directory sites and subnets. Each DAG member server will have two network interfaces—one for Messaging Application Programming Interface (MAPI) and one for replication.
During testing in our lab environment, we’ve noticed replication always happens over the MAPI network. We’ve configured static routes for the replication network per the instructions in one of your previous Exchange Queue & A columns. Do you have any idea what would cause this?
A: You mention you have DAG member servers from different Active Directory sites and subnets. This means that a DAG network will be created for each network interface/subnet holding DAG member servers (see Figure 1).
.jpg "There are multiple networks for each DAG member server")
Figure 1 There are multiple networks for each DAG member server.
At first glance this looks OK, but there’s a hidden issue. This will result in all replication traffic running over the MAPI network. To resolve this issue, you must collapse the DAG networks. If you have a DAG member server located in two Active Directory sites, for example, and each server has two network interfaces as shown in Figure 1, you’d need to collapse the four DAG networks into two (see Figure 2). At the same time, it would be a good idea to rename the DAG network accordingly.
.jpg "Collapse the DAG networks into smaller groups to resolve traffic routing issues")
Figure 2 Collapse the DAG networks into smaller groups to resolve traffic routing issues.
Dynamic Memory
Q: We’re a midsize shop running Exchange 2010. All Exchange 2010 servers are virtual, running in a Hyper-V-based virtualization infrastructure. We recently upgraded the Hyper-V root servers to Windows Server 2008 R2 SP1. As you probably know, one of the new Hyper-V-specific features in this service pack is dynamic memory. This helps us use physical memory more efficiently.
Do you know if it’s supported and/or recommended to enable dynamic memory on Hyper-V-based Exchange 2010 servers in order to use the memory resources on the Hyper-V root server more efficiently?
A: Unfortunately, the support stance is still the same: It’s not supported (check here for more details). Even if it were supported, it really wouldn’t make much sense for an application like Exchange.
Dynamic memory makes sense for applications designed for workloads where memory is needed for brief periods of time. Exchange Server is designed to use memory on an ongoing basis. For example, the Store.exe process on an Exchange 2010 server with the Mailbox server role installed will allocate most of the available memory (for the database cache) in the physical or virtual server.
The logic behind this is to be able to deliver better performance to the user, while still placing the databases on relatively slow storage like SATA 7200 spin disks in a JBOD configuration. Even if the databases were placed on superfast disks, the performance would never be as good as when data is read directly from the virtual address space. You always want to be reading as much data as possible directly from the database cache rather than from the underlying storage subsystem.
When it comes to the other Exchange server roles (Client Access, Hub Transport and Edge Transport), dynamic memory still wouldn’t make much sense because of the way Exchange has been designed to use memory. One more note: Virtualizing the Unified Messaging server role is not supported either.
Consolidating Forests
Q: We’re in the process of consolidating multiple Active Directory forests with Exchange 2003 to a new Active Directory forest with Exchange 2010. The migration approach we’ve taken is to first use the Prepare-MoveRequest.ps1 script to prepare the source mailboxes for a cross-forest move. We use the “LinkedMailUser” parameter to create a linked MailUser object in the target forest.
Then we move the mailbox and have it configured as a linked mailbox, so the user can log on to the Exchange 2010 mailbox using his Active Directory user account from the source forest until his Active Directory user account is migrated to the target forest. Because of this migration approach, we sometimes need to convert a mailbox to a linked mailbox, and convert a linked mailbox to an unlinked mailbox.
We’re aware of the steps in the Exchange 2010 documentation on TechNet that explain how to convert a mailbox to a linked mailbox, but it isn’t a very elegant approach. You disable the mailbox and connect it to a user in the respective source forest. This approach removes all Exchange attributes, and leaves the mailbox disabled for a period of time. Do you know of a more elegant way to do this?
A: Exchange has evolved into a massive product, so the documentation repository is quite extensive. There’s a dedicated and passionate Exchange writer team that develops new content and keeps existing content updated, but some topics are forgotten—which is what has happened when it comes to converting user mailboxes to linked mailboxes and vice versa. With Exchange 2007 SP1, the Exchange developers improved the Set-User cmdlet, so it can take care of scenarios where a user mailbox needs to be converted to a linked mailbox and vice versa.
If you want to convert a UserMailbox to a LinkedMailbox object, you can use the following command:
Set-User -Identity <mailbox> -LinkedDomainController<DC in account forest> -LinkedCredential $(Get-Credential <Domain Admin account in account forest>) -LinkedMasterAccount<User account in account forest>
This adds the msExchMasterAccountSid attribute to the account in the target forest and changes the recipient type, and other details, as appropriate. To convert a LinkedMailbox object to a UserMailbox object, use the following command:
Set-User -Identity <linkedMailbox> -LinkedMasterAccount $null
This will convert the recipient type to a UserMailbox and clears the msExchMasterAccountSidattribute as appropriate. Note: You must enable the Active Directory account manually. The Set-User command given here doesn’t do this for you. Thanks to William Rall on the Exchange team, from whom I originally learned this trick.
ADFS Authentication Support
Q: We just upgraded our messaging infrastructure from Exchange 2003 to Exchange 2010. We’re also in the process of implementing single sign-on (SSO) through the use of claims-based authentication delivered by Active Directory Federation Services (AD FS). I was wondering if you know whether AD FS-based authentication is supported by Exchange 2010 or if it will be supported in an upcoming version?
A: Currently, Outlook Web App (OWA) 2010 can benefit from claims-based authentication (and the WS-Federation protocol) via AD FS 2.0. You time this question quite well, because Microsoft France recently published a great step-by-step white paper that walks you through the process of configuring OWA 2010 to leverage claims-based authentication.
.jpg "Henrik Walther")
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 TimengoConsulting (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). You can e-mail Walther at v-henwal@microsoft.com.*