A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 5)

If you would like to read the other parts in this article series please go to:

Introduction

So far in parts one to four of this article series we have constructed the new Exchange 2007 environment that is happily coexisting with the original Exchange 2003 environment. At this point of the implementation process, the actual Exchange 2007 server software had been installed but other applicable software such as antivirus and backup software had not. Since the focus of this article is on the Exchange configuration, I shall not be detailing the installation and configuration of areas such as antivirus and backup software; such subjects may well be the focus of future articles here on msexchange.org.

Over the next few parts of this article I will be covering the overall configuration of the Exchange 2007 environment prior to the migration of any user mailboxes. What I would not be covering is basic configuration information such as creating new mailbox databases and setting mailbox size limits, as this information is readily available elsewhere in the product documentation and in other articles. Rather, what I want to now cover are some of the key overall configuration changes that were made to the system after the various server roles had been installed and activated. In this particular article, the focus will be mainly on configuration areas that affect the Hub Transport servers.

Moving the Hub Transport Database

Although the Hub Transport servers had been installed and updated successfully, there still remained the need to move the Hub Transport database file from its default location. Since the Hub Transport server role now uses an Extensible Storage Engine (ESE) database, the design of this system followed the standard design practice of ensuring good system performance by separating the Hub Transport server ESE database onto a separate disk array. By default, both the Hub Transport database and associated transaction log files had been installed onto the D: drive of the server and it was required that just the databases were moved to the E: drive instead. In Figure 16, you can see an example of the default folder location for both the database and the transaction logs. This default location is \Program Files\Microsoft\Exchange Servers\TransportRoles\data\Queue. In Figure 16, you can see the database file, mail.que, along with the transaction log files such as trn.log, trn00000001.log and so on.


Figure 16: Location of Hub Transport Database

To change the location of the Hub Transport database, the EdgeTransport.exe.config file needed to be modified accordingly. This file was found in the \Program Files\Microsoft\Exchange Server\bin folder which is its default location. I should also point out here that this modification applied to the Edge Transport server as well as the Hub Transport servers. The parameter within the EdgeTransport.exe.config file to amend was the QueueDatabasePath parameter as you can see from Figure 17. Here, the value was set to E:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue, which was obviously a simple change from the default D: drive to the E: drive.

Note:
The parameter below (QueueDatabaseLoggingPath) controls the associated transaction log files. These were left on drive D: in order to ensure that they remained separate from the database.


Figure 17: Modifying the EdgeTransport.exe.config File

Once the change had been made and the file saved, I restarted the Microsoft Exchange Transport service which automatically created the new folder structure on drive E: and obviously also created a new mail.que file. One interesting thing to note is that this process did not clean up drive D: so the old database file was not removed; this needed to be done manually.

Routing Group Configuration

Since the Exchange 2007 environment was coexisting with the Exchange 2003 environment, this meant that the installation of the first Hub Transport server role had automatically created a Routing Group Connector between Exchange 2007 and Exchange 2003. As you saw in part two of this article, the installation of the first Hub Transport server requires that you identify the target Exchange 2003 bridgehead server that becomes the connection point for the Routing Group Connector. If your infrastructure consists of multiple Exchange 2003 bridgehead servers and/or multiple Exchange 2007 Hub Transport servers, you can consider adding additional source and target transport servers to the Routing Group Connector configuration by running a couple of Exchange Management Shell cmdlets.

In my case, one of the configuration steps that I performed was to update the Routing Group Connectors with the name of the second Hub Transport server that was installed as well as the other Exchange 2003 server. This meant that the Routing Group Connectors had an element of fault tolerance since you may remember that in this project the combined Hub Transport and Client Access Servers were not configured with any load balancing methods since this was being handled by ISA Server 2006. There were two Routing Group Connectors to update, since each connector is half of the two-way path between the Exchange 2003 and Exchange 2007 environments. The names of these connectors are derived from the names of the Exchange servers they connect to, which in my example case are HUBCAS1 and E2K3SRV1. Therefore, the identity of the Routing Group Connector from Exchange 2003 to Exchange 2007 was “E2K3SRV1-HUBCAS1”, whilst the identity of the Routing Group Connector going the other way was “HUBCAS1-E2K3SRV1”. The connectors themselves must be updated using the Exchange Management Shell on an Exchange 2007 server and not via the Exchange System Manager connected to an Exchange 2003 server. Taking the example of updating the connectors with the name of the second Hub Transport server, the first cmdlet run was:

Set-RoutingGroupConnector –Identity “E2K3SRV1-HUBCAS1” –TargetTransportServers HUBCAS1,HUBCAS2

As you can see, this sets the target Exchange 2007 transport servers parameter with the names of both Hub Transport servers. This was followed by the second cmdlet:

Set-RoutingGroupConnector –Identity “HUBCAS1-E2K3SRV1” –SourceTransportServers HUBCAS1,HUBCAS2

It should be obvious that this sets the source Exchange 2007 transport servers parameter with the same Hub Transport servers. I then confirmed that the settings were correct by running the following cmdlet:

Get-RoutingGroupConnector | fl Name,SourceTransportServers,TargetTransportServers

An example of what the output of this cmdlet should look like is shown in Figure 18. This is taken from a lab environment consisting of two servers called DCE2K3, running Exchange 2003, and MSE2K7 running Exchange 2007.


Figure 18: Result of Get-RoutingGroupConnector cmdlet

Maximum Message Sizes

The customer on this particular project required that the maximum global message size was set to 10MB which was already present within the Exchange 2003 environment. When Exchange 2003 and Exchange 2007 Service Pack 1 coexist, the global limits that apply to both versions of Exchange are automatically copied to the organizational limits that apply to just Exchange 2007. As it happens, the default organizational limits are 10MB for Exchange 2007 anyway, as you can see from the results of the Get-TranpsportConfig cmdlet shown in Figure 19. The two parameters of interest are MaxSendSize and MaxReceiveSize. Also of interest is the MaxRecipientEnvelopeLimit which was set to 1000 when examined. This parameter controls the maximum number of messages that are permitted in a message. In the Exchange 2003 environment, the Maximum number of recipients setting had already been set to 1000, so the corresponding Exchange 2007 parameter, MaxRecipientEnvelopeLimit, was also set to 1000.

Image
Figure 19: Result of Get-TranpsportConfig cmdlet

Also of interest at this point was the maximum message size permitted in Outlook Web Access. By default, the largest message that you can send via Outlook Web Access is 30,000KB and so in order to keep all settings consistent it was decided to modify this to match the overall global message size limits. To make this change, the web.config file was modified on each Client Access Server. This file is found in the \Program Files\Microsoft\Exchange Server\ClientAccess\owa folder and the parameter of interest is maxRequestLength as you can see from Figure 20. Here you can see that this parameter had been changed to a value of 10240, down from the default value of 30000. This value obviously reflects 10MB. An IISReset command was performed after the change had been made.


Figure 20: Editing the web.config File

Summary

That concludes part five of this article series covering a project to transition from Exchange 2003 to Exchange 2007. This part of the article has focused on the configuration of settings that are mainly relevant to the Hub Transport server role. It’s important in any transition project to ensure that key settings such as the location of the Hub Transport database and the maximum message size limits are addressed. In the next part of this article series, we’ll continue our look at the configuration of the Exchange 2007 environment.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top