Exchange Queue & A: Focus on Exchange Server 2010 SP1

The first service pack for Exchange Server 2010 is scheduled for official release later this year, but it’s already generating lots of questions and comments.

Henrik Walther

Port Problems

Q: As we make plans to upgrade our Exchange 2010 production environment to Exchange 2010 SP1 when it’s released later this year, we’ve been testing the Exchange 2010 SP1 beta version in our sandbox. We have four Exchange 2010 Client Access Servers in a CAS array. We load balance Exchange client traffic across the CAS servers using a hardware load balancer from a third-party vendor. We’ve also assigned static RPC ports for the RPC Client Access service and Exchange Address Book service.

After we began using Exchange 2010 SP1, we’ve had a variety of issues connecting to a mailbox using Outlook. We have also had issues opening the Address book from Outlook. We don’t seem to have these issues when using OWA. Have you seen this or at least have an idea of what could cause this behavior?

A: With the Exchange 2010 RTM version, you would’ve assigned a static RPC port for the RPC Client Access service by adding a DWORD key named “TCP/IP Port” in the registry. This would be under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc\ParametersSystem. You would’ve also assigned a static RPC port for the Exchange Address Book service using the Microsoft.exchange.addressbook.service.exe.config file from in the “Bin” folder located in the Exchange 2010 installation folder. 

With Exchange 2010 SP1, things have changed a bit when it comes to assigning a static port to the Exchange Address Book service. To prevent Exchange setup from overwriting the custom values entered in the Microsoft.exchange.addressbook.service.exe.config file and make this configuration step more consistent with how you assign a static RPC port for the RPC Client Access service, the Exchange Product group decided to move this configuration option to the registry.

If you open the Microsoft.exchange.addressbook.service.exe.config file after upgrading a Client Access Server to Exchange 2010 SP1, you no longer see the

<add key="RpcTcpPort" value="static_port" />

as you can see in Figure 1.

Figure 1 With Exchange 2010 SP1, you no longer assign static port for the MSExchangeAB in a config file.

With Exchange 2010 SP1, you assign a static RPC port for the Exchange Address Book service by drilling down to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB. Here you need to create a new key named “Parameters” (not ParametersSystem). Under this key, you create a new REG_SZ string (not a DWORD) named “RpcTcpPort” and specify the RPC port number you want to assign to the service, as shown in Figure 2.

Figure 2 With Exchange 2010 SP1, you assign a static port for the MSExchangeAB in the registry.

It’s important to note that any current static RPC port you’ve assigned to the Exchange Address Book service using the Microsoft.exchange.addressbook.service.exe.config file won’t automatically be converted into a registry. You need to do this manually after upgrading to Exchange 2010 SP1. It sounds like this is what’s causing the issues you’re having when connecting to a mailbox with Outlook.

Importing and Exporting Mailboxes

Q: With Exchange 2007 SP1, we had the Import-Mailbox and Export-Mailbox cmdlets that we used to import or export data to or from PST files. Although these two cmdlets replaced the good old ExMerge tool, there were demanding requirements.

In order to use the cmdlets, you had to install the 32-bit version of Exchange 2007 SP1 Management tools, as well as Outlook 2003 SP2 or later, on a dedicated server or workstation. The MAPI provider included with Exchange 2003 and earlier had been removed from Exchange 2007.

Based on what I see, the Exchange 2010 RTM still uses the Import-Mailbox and Export-Mailbox cmdlets. Although the support for remote Windows PowerShell improves things a little by letting you run these cdmlets on a desktop or server without the Exchange 2010 Management tools installed, you still need to install Outlook 2010 64-bit on the Mailbox server itself. The cmdlets also seem somewhat error-prone in Exchange 2010.

Does Exchange 2010 SP1 make any improvements in regard to how you import and export mailbox data to and from PST files?

A: The short answer is yes. There’s a lot changing in this area. The long answer is also yes. With Exchange 2010 SP1, two brand-new cmdlets—MailboxImportRequest and MailboxExportRequest—have replaced the old Import-Mailbox and Export-Mailbox cmdlets.

Even better, the Exchange Product group also thought it was a good idea to get rid of the Outlook 2010 MAPI provider requirement. Exchange 2010 has its own MAPI provider, and those two new cmdlets take advantage of the Exchange Mailbox Replication Service (MRS). You can import or export data via an asynchronous process, just like when you move mailboxes using the New-MoveRequestcmdlet (see Figure 3).

So if I want to import a PST file to an Exchange 2010 SP1 mailbox, the command looks something like this:

New-MailboxImportRequest-Mailbox HEW -FilePath\\EX02\PSTFileShare\HEW.pst

Figure 3 Importing data from a PST file to an Exchange 2010 SP1 mailbox.

Notice that you now point to a UNC, not a local folder on the server upon which the cmdlet is run. This also has several benefits.

Archiving Answers

Q: With Exchange 2010 RTM, we couldn’t import a PST file directly to the online archive of an Exchange 2010 mailbox. Instead, we had to first import the data to the primary mailbox, and from there drag and drop the content (or use retention policies) to the online archive.

Do you know if this will change with Exchange 2010 SP1?

A: As explained in the previous answer, a lot of stuff is changing when it comes to importing and exporting mailbox data to and from PST files. The same is true of importing and exporting data to and from an online archive.

Using the same cmdlets (MailboxImportRequest and MailboxExportRequest), you can now move data in and out of an online archive (as in Figure 4). Instead of the command I provided in the last answer, you use something like the following to import data directly to the online archive:

New-MailboxImportRequest -Mailbox HEW –IsArchive-FilePath\\EX02\PSTFileShare\HEW.pst

Figure 4 Importing data from a PST file to an Exchange 2010 online archive.

Avoiding Forced Restarts

Q: With Exchange 2010 RTM, a user can work in his mailbox while it’s being moved between two Exchange 2010 mailbox databases or between an Exchange 2007 SP2 and an Exchange 2010 RTM mailbox database. As you can see in Figure 5, though, at the end of the move, the user was told to quit and restart Outlook in order to apply the recent changes.

Figure 5 Outlook restart triggered by Exchange 2010

Do you know if Microsoft has done any further work in this area in regard to Exchange 2010 SP1? The dialog box in Figure 5 is a minor annoyance for an end user, so it would be awesome if they could remove this step.

A: That’s a good question, and yes, there actually has been some work in this area. With Exchange 2010 SP1, if you move a mailbox between two Exchange 2010 SP1 databases, the user usually won’t receive an “Outlook must be restarted” dialog box unless:

• The RpcClientAccessServer property is different between the two involved mailbox databases. (This is usually the case when you don’t use a CAS array.)
• If you move a mailbox between a source mailbox database in Active Directory site 1 (with one CAS array configured) to a target mailbox database in Active Directory site 2 (with another CAS array configured).
• If the named properties for the mailbox is reset using the DoNotPreserveMappingSignature parameter when running the New-MoveRequestcmdlet.

If you move a mailbox between Exchange 2003/2007 and Exchange 2010 SP1, you’ll still have to restart Outlook.

Staying in Control

Q: We’ve just upgraded from Exchange 2003 to Exchange 2010 RTM. So far, we really like the features of this version—especially the new Exchange Control Panel (ECP). However, we’re facing a problem with the ECP. Besides their normal mailbox-enabled user accounts, our IT personnel have another admin account. Our IT policy dictates that mailbox-enabled admin accounts aren’t allowed within the organization. Our testing shows that in order to access the ECP, you must log in with a mailbox-enabled account.

We were wondering if you know of any workarounds in regard to this limitation? We really would like to use the ECP for many Exchange 2010-related administrative tasks.

A: Early on in the development stages of Exchange 2010, the development team decided an account accessing the ECP needed an Exchange 2010 mailbox. The primary reason for this decision was the engineering effort required to support a scenario where both non-mailbox-enabled accounts and mailbox-enabled accounts would have access to the ECP. Allowing that access would result in different code paths, which again would mean increased complexity/test costs. So the Exchange Product group decided to set this limitation and concentrate on providing actual features in the GUI. So yes, the Exchange 2010 RTM version requires any user/admin accounts that access the ECP be mailbox-enabled.

As most of you know, the Exchange Product group takes all feedback from the community and its customers very serious. In fact, many feature changes were made based on that feedback. Since the release of Exchange 2010 RTM, the Exchange group has learned many organizations have IT policies in place similar to yours. So it’s great to be able to tell you that when Exchange 2010 SP1 is released later this calendar year, that requirement will be gone.

With Exchange 2010 SP1, you will be able to log on directly to the ECP (https://mailcontoso.com/ecp) with a non-mail and non-mailbox-enabled AD user account (Figure 6).

Figure 6 Opening ECP using a non-mail or non-mailbox-enabled AD user account

The Rhyme and Reason of Repair

Q: Our organization has upgraded from Exchange 2007 to Exchange 2010. Occasionally, we need to perform offline repairs on mailbox databases. We wanted to ask if you still need to run ISInteg after having repaired a mailbox database, as in previous versions of Exchange Server?

What should those of us who occasionally need to detect and repair mailboxes in an Exchange 2010 Mailbox database do? With Exchange 2010 the Exchange Product group is moving away from ISInteg. In Exchange 2010 SP1, we’ll have a brand-new cmdlet called New-MailboxRepairRequest. This replaces the ISInteg tool. You can run this cmdlet against one or more mailboxes asynchronously while the mailbox database in which they’re located is mounted. Bear in mind, though, that the mailboxes being repaired using this cmdlet will be disrupted.

To detect and repair folder views, we would use something like the following:

New-MailboxRepairRequest -Mailbox HEW -CorruptionTypeFolderView

Figure 7 Running the new Mailbox Repair cmdlet against a mailbox

You can also run the cmdlet against a mailbox database, but your access to all mailboxes in that database will then be disrupted until you’ve finished the repair process.

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

• Installing Exchange 2003/2007 in an Exchange 2010 Environment
• A Second Look at Exchange 2010 Features and Improvements