Exchange Queue & A: Migrating Mailboxes
Moving and securing Exchange mailboxes can be tricky business, especially across forests or from one domain server to another.
Henrik Walther
Virtualized Exchange
Q: We want to deploy our Exchange 2010 messaging solution on clustered Hyper-V servers, and were planning to protect the mailbox databases with database availability groups (DAGs). We noticed the following statement in the Exchange 2010 Requirements section in the TechNet documentation, so we wanted to hear your take on this:
“Microsoft doesn’t support combining Exchange high-availability solutions (database availability groups [DAGs]) with hypervisor-based clustering, high-availability or migration solutions. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers.”
A: As the above passage states, combining Exchange 2010 DAGs with virtualization high availability (HA) is not supported. You must use application-level HA or virtualization HA. When it comes to Exchange 2010, application level HA is recommended.
If you only have clustered root servers and require the use of DAG, then you can have DAG members stored on a clustered Hyper-V root server—as long as you’ve disabled all virtualization HA for the respective virtual DAG member servers. By the time you read this, the TechNet documentation should have been updated to reflect this new support stance.
Load Balancing Exchange
Q: We’re currently designing our new Exchange 2010 infrastructure and have decided to use a hardware load balancer to provide high availability and load distribution across the Client Access servers in our CAS array. To reduce the SSL workload on our CAS servers and take advantage of affinity methods like cookie and SSL-ID, we want to offload SSL to the hardware load balancer.
We know offloading SSL for Outlook Web Access (OWA), Outlook Anywhere (OA) and Exchange Web Services (EWS) is supported, but what about Exchange ActiveSync (EAS)? I ask as I know this wasn’t supported back in Exchange 2007 per (How to Configure SSL Offloading for Outlook Web Access in Exchange Server 2007).
A: Actually, offloading SSL for EAS both for Exchange 2007 and Exchange 2010 is supported. The Exchange 2007 documentation was never updated to reflect this support statement.
It’s important to bear in mind that it’s only supported at the ingress point (for CAS servers in the Internet facing site) not in a CAS-to-CAS proxy scenario.
Migrating Across Forests
Q: We’re currently getting ready to perform a cross-forest migration from Exchange 2003 to Exchange 2010. We’ve built a lab environment that simulates our production environment to make sure things work as expected.
First, we prepared the target forest with valid Active Directory objects using the instructions provided in the Exchange 2010 TechNet documentation (Prepare Mailboxes for Cross-Forest Moves Using the Prepare-MoveRequest.ps1 script in the Shell). The script runs successfully and we can see the AD objects are created in the target forest, but we receive the error shown in Figure 1 when we try to move a legacy mailbox using the using the following command:
New-MoveRequest -Identity 'cotestuser1@contoso.com -RemoteLegacy -TargetDatabaseMDB01 -RemoteGlobalCatalog 'DC1.contoso.com' -RemoteCredential $Cred -TargetDeliveryDomain 'fabrikam.com'
.jpg)
Figure 1 Cross Forest Mailbox Move Error
Do you have any idea what could cause this error?
A: Excellent timing—I experienced this a few months ago myself during a cross-forest migration from Exchange 2003 to Exchange 2010. With the help of Dmitri Gavrilov (who’s a principal development lead on the Exchange Mailbox team in the Exchange Product group), I found this was because there’s no NetBIOS resolution between the two Active Directory forests.
When performing a cross-forest mailbox move using the New-MoveRequestcmdlet, the Exchange 2010 server in the target forest from which the command is run must be able to reach the source mailbox server in the Exchange 2003 organization using its NetBIOS name. This is because the New-MoveRequestcmdlet will attempt to connect to the source server using the server LegacyDN, which usually contains the NetBIOS name only. So you must either setup WINS or use host files in order to get rid of this error message.
Any Port in a Storm
Q: I’ve read in several sources that when using a hardware load balancer to provide HA and Outlook client load distribution across all Client Access servers on the internal network, I have to open the following ports for Outlook connectivity to work properly: TCP Endpoint Mapper (TCP - 143) and the dynamic RPC range TCP/UDP -1024-65535. Is this correct? I thought Exchange 2010 didn’t support User Datagram Protocol (UDP).
A: You are right. With Exchange 2010, it no longer supports UDP. You don’t need to open UDP—only TCP. This is also true for Outlook 2003, even though Outlook initially tries to use UDP notifications. If it sees the Exchange server doesn’t respond to UDP, it reverts to polling the Exchange server using TCP. The problem is that Outlook 2003 clients in online mode only poll every 60 seconds, which results in the following symptoms:
- Outgoing e-mail messages stay in the Outbox for up to one minute.
- New e-mail messages do not arrive in the Inbox for up to one minute.
- Items deleted from folders do not disappear from the folder for up to one minute.
- Items that are moved from one folder to another folder take up to one minute to disappear from the original folder.
If you have Outlook 2003 clients in online mode, you would need to fix this issue by following the steps in the following Knowledge Base article: In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox.
Mailbox Protection
Q: I’m currently designing our Exchange 2010 infrastructure. One of the requirements is to have HA at all levels, so we will protect mailbox databases using DAGs and the Client Access servers using a Client Access array and a redundant hardware load balancer.
We also plan to publish the Client Access server to the Internet using a Forefront Threat Management Gateway (TMG) array. I’m a little unsure on how to publish the CAS servers to the Internet in the proper way. Should we just point the ISA Web publishing rules at the hardware load balancer on the internal network and then let the hardware load balancer distribute the client traffic across the CAS servers?
A: This is a great question. Let me explain. When using TMG (or UAG for that matter) to publish the Exchange 2010 CAS servers, use the Web server farm load-balancing capabilities included with TMG. Don’t simply point the Web publishing rules at the hardware load balancer on the internal network.
In a typical scenario, when TMG receives a client request, TMG will change the source IP address field in the IP header to the IP address configured on its internal interface. This means all client requests proxied from TMG to the hardware load balancer will appear to come from the same client IP. This causes the HLB to send all client requests to the same CAS server instead of distributing them across the CAS servers in the Exchange 2010 CAS array.
Some might say you could just change the proxy request behavior from “Requests appear to come from the ISA Server computer” to “Requests appear to come from the original client” as shown in Figure 2, but it’s not that simple. If you do, you have to set the TMG as the default gateway (or use static routes, see Figure 2) on each CAS server, which can bring on other issues. Most enterprises also use NAT anyway, which means the source IP will appear to come from the same client (IP address of the NAT device), even if you set the TMG as the default gateway on the CAS servers.
.jpg)
Figure 2 TMG Proxy Request Behavior
Although TMG provides an additional layer of security and lets you pre-authenticate clients before they’re proxied to the CAS servers, it’s important to bear in mind that the TMG Web server farm load-balancing functionality has the same limitations as Windows Network Load Balancing when it comes to affinity. It actually uses the Windows NLB component, which means you’re limited to source IP-based affinity and can’t take advantage of affinity methods like cookies or SSL-ID.
Mailboxes on the Move
Q: We’ve deployed Exchange 2010 in an Active Directory forest consisting of a root domain and multiple child domains. There are Exchange 2010 servers in each child domain, and sometimes we need to move mailboxes between mailbox servers in different domains. We use Exchange Management Shell commands as much as possible.
We also want to use the New-MoveRequest cmdlet to move mailboxes between the child domains, but when we do, we can’t see the mailboxes in one of the other domains. The command completes, but it doesn’t list the mailboxes. Also, we get an error when trying to move the mailboxes because we can’t see them from the Exchange Management Shell. Do you have any idea what’s going on?
A: When using the Exchange 2010 Management Shell, the default recipient scope is set to domain-level. This means only local mailboxes will be listed when running something like the Get-Mailbox cmdlet. In order to change the recipient scope to forest-wide, you must run the following command (see Figure 3): Set-ADServerSettings -ViewEntireForest:$true
.jpg)
Figure 3 Changing the Default Recipient Scope
_***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 forTimengoConsulting (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. _