Exchange Queue & A: Migration Management

Managing the migration process is always an issue. There are several ways to better streamline and control the process.

Henrik Walther

Upgrade Scheme

Q. We’re using Microsoft Exchange Server 2010 SP1 as our messaging infrastructure. We’re planning to upgrade to Exchange Server 2010 SP2. We want to do so as soon as possible, because we want to use the new Address Book Policies (ABPs).

As we prepare to upgrade to Exchange 2010 SP2, we aren’t sure if we need to prepare the Active Directory using “Setup /PrepareAD.” Is it enough to extend the schema using “Setup /PrepareSchema?” We saw “Exchange Schema Versions – Common Questions & Answers” on the TechNet wiki, but that doesn’t say anything about the requirement to prepare Active Directory, only the schema.

In our lab environment, we only ran “Setup /PrepareSchema” and were able to upgrade the Exchange 2010 servers to SP2 without any issues. Could you shed some light on this?

A. Before you upgrade the Exchange 2010 servers to SP2, you must extend the schema using “Setup /PrepareSchema.” You must also prepare Active Directory using “Setup /PrepareAD.” For small deployments, you could have the setup wizard automatically prepare your group for the upgrade. It can do this if the logged-on account holds the required permissions.

In large enterprise environments, it’s a good idea to prepare the schema and Active Directory in separate steps. Most large enterprise customers require this approach, as they usually have a dedicated Active Directory to perform these preparation steps.

It sounds like you were able to upgrade your Exchange 2010 servers in the lab without running “Setup /PrepareAD” because you were logged on with an account with the appropriate permissions.

Migration Control

Q. We’re a large Exchange hosting provider, and we plan to migrate to Exchange 2010 running in non-hosted mode, using a third-party control panel for the provisioning logic and multitenancy.

Because we’ll be using a third-party control panel, we wish to disable access to the “Manage My Organization” setting for Exchange Administrators accessing the Exchange Control Panel (ECP). We don’t want to disable access to the ECP in general, only the “Manage My Organization” feature (see Figure 1). Do you know if this is possible?

Figure 1 You can disable access to certain functions.

A. You couldn’t do this prior to Exchange 2010 SP2, unless you were running Exchange 2010 in hosted mode. That’s not to say you should’ve deployed Exchange 2010 in hosted mode. We actually recommend against doing this, and instead prefer to let a third-party control panel solution do all the provisioning and multitenancy, as you did.

So with Exchange 2010 SP1 running in hosted mode, one of our recommendations was to disable access to the “Manage My Organization” option within the ECP. You can do this using a registry key as explained in the Exchange 2010 Hosting documentation. You create a DWORD key named “OMECPDisabled” under “HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\ExchangeServer\v14.” Note that you don’t need to set a value for this key (see Figure 2).

Figure 2 It’s relatively straightforward to enable or disable access with registry keys.

After creating that key, you’d see what is shown in Figure 3 when accessing the ECP. There’s no longer a “Manage Myself” dropdown menu and you have no access to perform any administration on the organization level using the ECP—mission accomplished.

Figure 3 After making this modification, you’re locked out of administrative functions.

Notice this answer began with “Prior to Exchange 2010 SP2”? The registry key isn’t supported with Exchange 2010 in non-hosted mode when running Exchange 2010 SP1 or earlier. Here’s the good news, though: with Exchange 2010 SP2, you can use the same key to accomplish the same goal in Exchange 2010 non-hosted mode environments.

Any Port in a Migration

Q. We’re currently deploying and configuring the Exchange 2010 environment to which we’ll migrate from Exchange 2003 later this year. E-mail is mission-critical within our organization, so we will of course employ a Client Access array and Database Availability Groups (DAGs). To load balance incoming client traffic across the Client Access servers in the Client Access Service (CAS) array, we’ll use a hardware load balancer. We’ve heard it’s a good idea to configure static remote procedure call (RPC) ports on the CAS servers in such a scenario. What’s your opinion?

A. The short answer is yes: You should strongly consider configuring static RPC ports. There are several reasons for this.

First, it’s always a good idea to keep your network/security/firewall guys happy. Don’t ask them to keep IP ranges open. Instead, ask them to open up a few single ports. If you have one or more firewalls in place between the client subnet(s) and the load balancer/Exchange 2010 servers, you don’t configure static RPC ports on your CAS servers. You would need to ask them to open a huge RPC port range (more specifically, TCP port 135 and the dynamic port range 6005-59530).

By configuring static RPC ports, you only need to ask for three ports: TCP/135 (TCP endpoint mapper), the port assigned to the RPC CAS and the port assigned to the Exchange Address Book service.

Second, when you’re using a hardware load balancer and you don’t configure static RPC ports, you’ll often see a larger memory footprint than if you configured static RPC ports. Also, some load balancers don’t play well with dynamic port ranges in general. Finally, it’s easier to configure a monitoring solution to monitor three ports instead of a dynamic port range.

To learn how to configure static RPC ports, take a look at the TechNet wiki page, “Configure Static RPC Ports on an Exchange 2010 Client Access Server.”

Henrik Walther* is a Microsoft Certified Master: Exchange and Exchange MVP with more than 16 years of experience in the IT business. He works as a technology architect for a Microsoft partner in Denmark and as a technical writer for Biblioso Corp., a U.S.-based company specializing in managed documentation and localization services.Walther is also a contracted vendor working for miscellaneous product teams, including the Exchange and Lync teams, at Microsoft. E-mail him at v-henwal@microsoft.com.*

Related Content

• Exchange Queue & A: Exchange Is Always Changing
• Exchange Queue & A: Migrations and Updates
• Exchange Queue & A : Configuration Conundrums