Exchange Queue & A: Migrations and Transitions

There seem to be a lot of companies still using Exchange 2003, which can be quite cost-effective, but you may run into certain compatibility issues.

Henrik Walther

Shared Calendars

Q: We just migrated from Exchange 2003 to Exchange 2010 SP1. We have a mix of Outlook 2003 and Outlook 2007 clients throughout our organization. We’ve received some complaints from users opening numerous shared calendars from Outlook 2003 (opening more than 15 calendars at once is not unusual). They sometimes get an error when trying to open a calendar (see Figure 1).

Figure 1 The error message you’ll see when opening more than 15 shared calendars from Outlook 2003

Do you know if there’s some way to fix this issue without upgrading to Outlook 2007? We cannot upgrade these clients before second half of 2011.

A: This is usually caused by the new remote procedure call (RPC) throttling policies that are part of Exchange 2010—more specifically the “RCAMaxConcurrency” throttling policy parameter. If you have users needing to open more than 15 shared calendars or additional mailboxes using Outlook 2003, you can adjust the RPC-related throttling policy settings using the Set-ThrottlingPolicy cmdlet. Increase the value for RCAMaxConcurrency, which is set to 20 by default. The RCAMaxConcurrency parameter indicates how many concurrent connections an RPC Client Access user can have against a server running Exchange 2010 at one time.

To increase the value of the RCAMaxConcurrency setting in the default throttling policy from 20 to 30, open the Exchange Management Shell and run the following command to first create a variable for the policy:

$a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

Then pipe the variable to the Set-ThrottlingPolicy cmdlet:

$a | Set-ThrottlingPolicy -RCAMaxConcurrency 30

To apply these changes, restart the “Microsoft Exchange Throttling” service on each Client Access Server (CAS). You’ll now be able to open significantly more shared calendars or additional mailboxes than with the default setting (see Figure 2).

Figure 2 Opening 15 calendars using Outlook 2003 after changing the default setting for RCAMaxConcurrency

You can read more about Exchange 2010 SP1 throttling policies in the Exchange 2010 documentation on Microsoft TechNet.

Windows Phone Support

Q: Our company is considering offering Windows Phone 7 devices to our users. Before we do, we wanted to ask whether Windows Phone 7 devices support the same Exchange ActiveSync (EAS) policies as those supported by Windows Mobile 6.x devices?

A: Although Microsoft deveoped Windows Phone 7 primarily with consumers in mind, the Windows Phone team knew they needed to include enterprise features in the OS, with most people using the same phone for personal and work issues. The Windows Phone 7 OS supports a subset of the EAS policies provided with Exchange 2010 SP1, including the following policies:

• Password Required
• Minimum Password Length
• Idle Timeout Frequency Value
• Device Wipe Threshold
• Allow Simple Password
• Password Expiration
• Password History
• Disable Removable Storage
• Disable IrDA
• Disable Desktop Sync
• Block Remote Desktop
• Block Internet Sharing

If you want to use other EAS policies, you have the following options:

• Create a dedicated Windows Phone 7 EAS policy and associate it with mailbox users that use Windows Phone 7 devices
• Set the AllowNonProvisionableDevices property to true in the default EAS policy already configured
• Reconfigure the default EAS policy within the Exchange organization, so it only has the policies listed previously configured
• Deploy a third-party EAS client on the Windows Phone 7 devices

Coexisting with Exchange

Q: We’re a small organization currently planning a transition from Exchange 2003 to Exchange 2010 SP1. We only have one Exchange 2003 server. One of the tasks in the Upgrade from Exchange 2003 Client Access section of the Exchange 2010 TechNet library is to associate a legacy hostname (legacy.domain.com) with the Exchange 2003 infrastructure. Then we’ll have to configure an Exchange 2003 URL on the Exchange 2010 CAS that points to an Exchange 2003 front-end server with the following command:

Set-OWAVirtualDirectory <CAS2010>\OWA* -Exchange2003URL https://legacy.contoso.com/exchange

This will let our users access their mailboxes through a single sign-on during the coexistence period, which we need because we only have one Exchange 2003 server in our organization. The TechNet documentation specifically states you must point the Exchange 2003 URL to an Exchange 2003 front-end server. Does this mean we can’t use this coexistence feature unless we introduce an Exchange 2003 front-end server?

A: You don’t necessarily need a dedicated Exchange 2003 front-end server. When you only have one Exchange 2003 server, it’s absolutely fine to point the Exchange 2003 URL on the Exchange 2010 CAS directly at an Exchange 2003 back-end server. Just bear in mind that in order to get single sign-on, you’ll have to enable forms-based authentication on both the Exchange 2010 CAS and the Exchange 2003 back-end server (see Figure 3).

Figure 3 Enabling forms-based authentication in Exchange 2003

Also remember that you’ll have to install an SSL certificate that includes the legacy hostname (legacy.domain.com) on the Exchange 2003 server. It doesn’t need to be the common name on the certificate. If you use a UC/SAN certificate on your Exchange 2010 server, you could add the legacy hostname to the SAN list and use this certificate on the Exchange 2003 server as well.

Specifying Multiple Gateways

Q: We’re currently deploying Exchange 2010 SP1. We have two datacenters and plan to use database availability groups (DAGs) stretched between each datacenter. We’ll have two DAG members in one datacenter and two in the other. Each DAG member server will have two network interfaces (one for MAPI access and one for replication) and different subnets for each datacenter.

We’ve specified a default gateway for the MAPI network on each server and DAG members in one datacenter. They can reach the DAG members in the other datacenter and vice versa via the configured MAPI network IP address. However, the servers can’t reach each other via the replication network, which is an issue. We’re quite sure this is because we also need to specify a default gateway on the replication networks. When we do so via the TCP/IPv4 property page on the replication interface, we see the warning message shown in Figure 4.

Figure 4 Warning message when configuring multiple default gateways

Before continuing with the configuration of the replication interface, we wanted to ask what the proper method is in regard to specifying multiple gateways on a DAG member server?

A: I’m glad you asked before you decided to configure multiple gateways using the GUI. This is an unsupported path that would have created routing issues between the datacenters. You’ll have to specify a default gateway for the replication network interface.

Back in the Exchange 2007 days, you used the “Route Add” command to configure default gateways when deploying multi-site Cluster Continuous Replication (CCR) clusters or Single Copy Cluster (SCC) clusters with nodes on different subnets. With Windows Server 2008 and Windows Server 2008 R2, the guidance was changed a little. Instead of using “Route Add,” Microsoft recommended customers to use “Netsh” to configure the default gateway.

With Exchange 2010 DAG member servers located on separate subnets, you should still use Netsh. You’ll need to create a static route for the replication subnet in the other datacenter with Netsh. To create a static persistent route from subnet 10.10.10.0/24 to 10.10.11.0/24 using “Route add,” use the following command:

Route add 10.10.11.0 mask 255.255.255.0 10.10.10.203 –p

This will send all traffic destined for 10.10.11.0/24 to the gateway 10.10.10.203. This will then route it to the respective servers on the 10.10.11.0/24 subnet. To create the same static route using Netsh, use the following command:

Netsh interface ipv4 add route 10.10.11.0/24 "REPLICATION" 10.10.10.203

The name of the replication network interface is “REPLICATION” and the default gateway is 10.10.10.203. Note that with Netsh, “Route add” will be created as a persistent route.

Parallel Mailbox Moves

Q: We’ve just upgraded our Exchange 2010 servers to Exchange 2010 SP1. One observation we’ve made is that it only moved two mailboxes in parallel per target database. With Exchange 2010 RTM, we saw five mailboxes being moved in parallel.

Two questions come to mind: Why was the number of parallel mailbox moves changed with Exchange 2010 SP1, and can we change this value?

A: You’re right that the maximum active moves per target mailbox database was changed from five to two with Exchange 2010 SP1. The maximum active moves per target server is still set to five. This means that if you move users to multiple target mailbox databases, you’ll still be able to move up to five mailboxes in parallel per target mailbox server.

Internal testing in the Exchange product group showed that letting you make up to five parallel moves per target mailbox database resulted in too much load on high availability. This is especially true when moving large mailboxes to a target mailbox server that is also a member of a DAG.

You can tweak the value of this setting based on your needs and your specific environment. You should keep it at five if you’re moving large mailboxes and utilize a DAG. However, if you have small mailboxes or use standalone Exchange 2010 mailbox servers, you can usually up the value to 10 per target mailbox database and 40 per target mailbox server.

To change the value, log on to the Exchange 2010 CAS and open the MSExchangeMailboxReplication.exe.config file in notepad (see Figure 5).

Figure 5 Opening the MSExchangeMailboxReplication.exe.config file in Notepad

With the file open, change MaxActiveMovesPerTargetMDB and MacActiveMovesPerTargetServer values (see Figure 6).

Figure 6 Default MaxActiveMovesPerTargetMDB and MaxActiveMovesPerTargetServer values in Exchange 2010 SP1

When you’ve changed the values, restart the Microsoft Exchange Mailbox Replication service in order for them to apply. If you have multiple Exchange 2010 CAS servers in the organization, you must of course perform the above steps on all of them.

_***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. _

Related Content

• Exchange Queue & A: Gone to the DAGs
• Exchange Queue & A: Migrating Mailboxes
• Exchange Queue & A: Installing Exchange 2003/2007 in an Exchange 2010 Environment