Introduction

In this multi-part article I want to walk you through the process that I used recently to transition an existing Exchange 2003
environment to Exchange 2007, including the methods I used to build the new Exchange 2007 environment. I won’t have
space within this article to detail every configuration option that was made, since some of these configuration changes are
made for a reason; background discussions had taken place before these decisions were reached. Neither will I cover every
single installation option but I will take some time to go over the installation and configuration of the new environment before
any migration information is supplied. My main goal is to give you an appreciation of the installation order, how the servers
were installed, some of the configuration changes that were made, and some of the issues that were faced along the way. If
you are facing a similar migration, hopefully this article will give you some key pointers that you can use in your planning.
You will want to supplement this with additional reading, of course.

Infrastructure

The existing Exchange 2003 environment was fairly typical in that it consisted of two Exchange 2003 back-end servers as
well as a single Exchange 2003 front-end server. Although the back-end servers were separate physical servers, the
decision had been made to move to a Clustered Continuous Replication (CCR) environment on Exchange 2007 as
messaging had become vital to the company’s business. An Edge Transport server was deployed to replace an aging
MailSweeper server. An existing ISA Server was used to publish mobility solutions such as Outlook Web Access (OWA) and
Exchange ActiveSync (EAS) externally, thereby allowing users to access their mailboxes when not connected directly to the
company’s internal network.

Since high availability had been designed for the Mailbox server role, it was also decided to deploy high availability for the
Hub Transport and Client Access Server roles. As you likely know, fault tolerance and redundancy are built into the Hub
Transport role by default and therefore the decision was made to deploy two Hub Transport servers. However, this same
default redundant configuration does not apply to the Client Access Server role which is typically made highly available via
the introduction of additional technologies such as hardware or software load balancing. As it turned out, only OWA and
EAS were used remotely by users and as both of these are based on the Hypertext Transfer Protocol (HTTP) it was possible
to use ISA Server to perform the Client Access Server load balancing. To reduce the overall server count, the Hub Transport
and Client Access Server roles were combined onto a single server and then two of these combined servers deployed for
fault tolerance and redundancy.

Also worth mentioning is the subject of virtualization. In this particular design, the combined Hub Transport and Client
Access Servers, as well as the Edge Transport server, were implemented on virtual servers. The two cluster nodes were
implemented using physical hardware. The various server names that will be referenced throughout this article are:

• NODE1 and NODE2. These are the names given to the actual cluster nodes.
• CLUSTER1. This is the name of the cluster itself.
• EX2007. Although the cluster nodes are called NODE1 and NODE2 and the cluster itself is called CLUSTER1, none of
these names are used by Outlook. The name that is used by Outlook is referred to as the Clustered Mailbox Server (CMS)
name which in this case is EX2007.
• HUBCAS1 and HUBCAS2. These are the names given to the combined Hub Transport and Client Access Servers.
• EDGE1. This is the single Edge Transport server.

I should also note that all servers were installed manually rather than via any scripted method. This is mainly because there
were a small enough number of servers to warrant this approach.

Server Preparation

All servers had been prepared by the customer with the Windows 2003 operating system and the relevant Service Packs
and other updates applied. I spent quite some time ensuring that all servers had correct configuration items such as server
names, domain membership and drive letter allocations. I am actually glad that I did this as during this time I discovered that
the Edge Transport server had incorrectly been made a member of the internal Active Directory domain so this server was
removed from the domain and placed back into a workgroup.

Other key settings that were applied to all servers were:

• Page file. The ‘rules’ from Microsoft are that if the server has less than 8GB of memory, set the page file size to be 1.5 x the
amount of memory. If the server has 8GB or more, set the page file size to be the amount of memory plus an additional
10MB. Each server was set according to these rules.
• Another key page file consideration is the scenario where you have a dedicated drive for the page file. In these cases, make
sure that the drive containing the operating system is configured with a 100MB page file so that a kernel dump can be
performed.
• I confirmed that the SMTP and NNTP services were not installed on these servers, as the presence of these services blocks
the installation of Exchange 2007.
• I addressed the Windows 2003 Scalable Networking pack issues as detailed on the Exchange team blog.
• Locales. I took the time to ensure that the operating system locales were set to the relevant setting, which in this case was
the UK.
• Application event log sizes. Before installing Exchange 2007, I made sure that all application event log sizes were at least
40MB, with the option to overwrite events as needed configured. The Exchange Best Practices Analyzer (ExBPA) will flag
this issue so it’s worth configuring the application event log sizes up front.

The first servers that were to be installed into the existing Exchange 2003 organization were the combined Hub Transport
and Client Access Servers so these servers were prepared with the installation of the following required components:

• .NET Framework
• Windows PowerShell
• IIS World Wide Web Publishing Service
• RPC over HTTP Proxy service. Since Outlook Anywhere was to be used this component is required on the Client Access
Server

When transitioning from Exchange 2003 to Exchange 2007, Microsoft recommends that you deploy your Exchange 2007
servers in the following order:

• Client Access Server

• Hub Transport server
• Mailbox server
• Unified Messaging Server

In this particular design, the Client Access Server and Hub Transport server roles were combined onto a single server and
therefore these combined servers were the first to be deployed. From the above list you will notice that the Edge Transport
server role is not listed. Since this server role exists in a perimeter network and is thus not part of your internal Active
Directory domain, it can be installed at any point, although in practice it is best deployed after the Hub Transport server role
so that the Edge Subscription process can be completed.

Schema Preparation

The decision was made to prepare the Active Directory schema as a separate process to the installation of the first
Exchange 2007 server. If you start the installation of the first Exchange 2007 server, the Active Directory schema will be
updated anyway but you have the choice of doing this important step as a separate task. I have detailed the Active Directory
preparation process in depth here on MSExchange.org so I will not be going into huge detail within this article but for the
purposes of this article what you need to know is that the setup.com program with
the /PrepareLegacyExchangePermissions, /PrepareSchema, /PrepareAD and /PrepareDomain switches was run at this
point. There are several additional things worth noting here:

• The schema was updated directly on the schema master which at the time was running a 32-bit version of Windows 2003.
Therefore, the 32-bit version of Exchange 2007 SP1 was used. Although Microsoft does not support the 32-bit version of
Exchange 2007 SP1 in production, it does support it for the purposes of extending the Active Directory schema.
• The setup.com /PrepareDomain command was also run in the child domain, since the root domain had already been
prepared during the setup.com /PrepareAD process.
• The Exchange 2007 SP1 software is available as a slipstreamed installation. In other words, the SP1 software was the only
version used to prepare the Active Directory schema and also to directly install the servers within this infrastructure; at no
point was the Release To Manufacturing (RTM) version used followed by an upgrade to SP1. This is one of the nice new
features of Exchange 2007.

Summary
That concludes part one of this article which has mainly dealt with setting the scene for the remainder of the parts of this
article as well as the overall server preparation process. In part two of this article, we will start to look at the installation
process as we cover the Hub Transport and Client Access Server role installation as well as the preparation of the CCR
environment.

Introduction

In part one of this article, I set the scene for the remaining parts of this article as well as detailed the general configuration
options that applied to all servers on this particular project. We left part one having prepared the Active Directory schema to
receive the first Exchange 2007 server. Here in part two we will continue the look at the order of events required to construct
the new Exchange 2007 infrastructure, starting with the installation of the Hub Transport and Client Access Server roles.

Hub Transport and Client Access Server Installation

It was now time to install the first combined Client Access Server and Hub Transport server. Since these servers were being
installed manually the Graphical User Interface (GUI) version of setup was invoked and the option to install a Custom
Exchange Server Installation chosen. This was preferred over the Typical Exchange Server Installationoption since this
option installs the Mailbox server role as well as the Client Access Server and Hub Transport server roles. Selecting the
Custom Exchange Server Installation option allowed me to select just the Client Access Server and Hub Transport server
roles as you can see from Figure 1.

Figure 1: Installing the Hub Transport and Client Access Server Roles
When installing the Hub Transport server role onto an Exchange 2007 server that is to coexist in an Exchange 2003
infrastructure, you will be presented with a screen in the setup wizard that asks you to select a target Exchange 2003
bridgehead server that will be the connection point for a new Routing Group Connector that the Exchange 2007 setup
program creates for you. This screen is shown in Figure 2.

Figure 2: Bridgehead Server Selection

In my case the Exchange 2003 environment simply consisted of a single routing group that contained two back-end mailbox
servers so for this option I was able to select either of the Exchange 2003 servers for this purpose.

Once the setup routing had completed successfully, I checked the Exchange setup logs for signs of any errors that would be
a cause for concern. The setup logs are found in C:\ExchangeSetupLogs and checking these is something that I like to do
even if I receive a success message from the setup process. At the time of this particular installation the most recent update
rollup for Exchange 2007 SP1 was Update Rollup 3 so this was applied manually simply by executing the MSP file
downloaded from the Microsoft Downloads site. However, you should be aware of a handy tip for simplifying the process of
applying the update rollup patches, particularly if you are deploying a large number of servers. If you examine the file
structure of the Exchange source media, you should notice a folder called Updates that contains a single readme.txt file. If
you examine the contents of this text file you will see the following text:

“Updates added to this folder will be installed during setup.”

Therefore, to automatically deploy the relevant update rollup patch at the same time as installing Exchange 2007, simply
copy the update rollup patch to the Updates folder.
 Once Update Rollup 3 had been applied, the newly installed Exchange 2007 server was then fully activated by launching the
Exchange Management Console and entering the product key via the Enter Product Key menu option from the Action pane.
This entire process was then repeated on the second combined Client Access Server and Hub Transport server.

Cluster Nodes Preparation

Although the actual CCR cluster nodes had been prepared with the Windows 2003 operating system and associated update
patches, there was still quite a lot of configuration work to do regarding the network configuration. Obviously each cluster
node contained two network cards as is standard for cluster configuration, with the additional network card existing to
function as the intra-cluster communication channel or heartbeat network. Therefore, for easy identification purposes, I
renamed the network connections from their defaults of Local Area Connection and Local Area Connection
2 to Public and Private respectively. Additionally, since the network now named Private only existed for cluster heartbeat
purposes, there were several configuration changes that I had to make to this network connection. They were:

• Make sure that no DNS servers were defined on this network connection.
• Make sure that the check box titled Register this connection’s addresses in DNS was not selected. This option is shown in
Figure 3.
• Make sure that the WINS option titled Disable NetBIOS over TCP/IP is selected.

Figure 3: Private Network Configuration

This network connection should not be using DNS servers since these are configured on the Public network connection.
Additionally, this network connection will not be using NetBIOS over TCP/IP for similar reasons. Remember, this network
connection exists for the purpose of allowing the two cluster nodes to communicate with each other. However, one important
thing to remember here is that Microsoft generally recommends that you have the Client for Microsoft Networks and File and
Printer Sharing for Microsoft Networks options enabled for the Private network connection. It is recommended that multiple
networks (in this case the Private and Public networks) have this option enabled to provide fault tolerance for the Majority
Node Set quorum resource that will be created later, but of course this depends on factors such as your network
configuration. Finally I made sure that the network connection order was correct. This was achieved by going to the Network
Connections object in Control Panel and on the Advancedmenu option choosing Advanced Settings. This brings up
the Advanced Settings window as you can see in Figure 4. The correct order of priority is Public, Private and then Remote
Access connections.

Figure 4: Network Connection Order

The cluster nodes were then prepared with the pre-requisite software, namely .NET Framework 2.0 SP1, Windows
PowerShell 1.0, Network COM+ Access and the World Wide Web Publishing Service.

Cluster Creation

The next step was the actual formation of the cluster itself, prior to the deployment of Exchange 2007 onto each cluster
node. You can either do this via the Cluster Administrator program or via the command line using cluster.exe. Personally I
chose to use the Cluster Administrator program so that’s what I will detail here. Before running the cluster wizard, I created a
cluster service account in the domain which I’ll reference within this document asneilhobson\excluster.

I’ll briefly cover the screens presented within the cluster wizard:

1. First up was the opening Welcome screen of the New Server Cluster Wizard which I simply skipped past.

2. Next I was asked for the name of the domain into which the cluster was being installed, followed by the name of
the cluster. In this case, that was CLUSTER1.
 3. The next screen asked for the first node to be added to the cluster, for which I specified NODE1.

4. After this the wizard analyzed the configuration of NODE1 to ensure it was feasible to participate in a cluster.
This proved successful and I was able to continue.

5. Next up was the IP Address page where I configured the IP address of the cluster itself. Note that this is not the
IP address of the Clustered Mailbox Server (CMS) that Outlook users will connect to later.

6. The Cluster Service Account screen was then presented, whereby the service account that I created earlier was
entered.

7. Finally, the Proposed Cluster Configuration screen was presented that gave me a summary of my chosen
options. However, one important extra configuration item needed to be performed at this point and this was the
configuration of the quorum resource. In Figure 5, you can see the Quorum button which when selected
presented me with the Cluster Configuration Quorum window as you can see. I needed to make sure that the
quorum was set to the Majority Node Set option.

Figure 5: Configuring the Quorum

Summary

This concludes part two of this article in which we have covered the installation of the Hub Transport server and Client
Access Server roles as well as the initial cluster preparation steps. In part three of this article we will be taking a look at the
cluster and file share witness configuration as well as the installation of the Clustered Mailbox Server (CMS).

Introduction

This is the third part of an article series covering a project to transition from an existing Exchange 2003 environment to a
new Exchange 2007 environment. If you have read parts one and two already, you will know that so far I have covered the
installation of the first Exchange 2007 servers, combined Hub Transport and Client Access Servers, into the Exchange 2003
environment. I have also covered the initial preparation steps of the Clustered Continuous Replication (CCR) environment.
Here in part three, I will continue with the installation of this CCR environment.

Cluster Configuration

Now that the cluster had been created I was able to configure it for production use. The first element to configure was the
cluster network usage. To do this, I drilled down the Cluster Administrator hierarchy to the Networks object found under
the Cluster Configuration object. By bringing up the properties of the Private network, I ensured that this network was set
to Internal cluster communications only (private network) as you can see from Figure 6. The public network was
configured as All communications (mixed network).

Figure 6: Configuring the Private Network

Next it was important to ensure that the networks were in the correct order within Cluster Administrator. To do this I right-
clicked the cluster name, CLUSTER1, right at the top of the hierarchy in Cluster Administrator and choseProperties from the
context menu. This presented me with the cluster properties window and from there I navigated to the Network Priority tab
where I ensured that the private network was at the top of the list as you can see in Figure 7.
Figure 7: Configuring the Cluster Network Priority

Microsoft also recommends that you configure various settings that control the tolerance towards missed cluster heartbeats.
To do this I used the cluster.exe command-line interface by running the following two commands:

cluster.exe CLUSTER1 /priv HeartBeatLostInterfaceTicks=10:DWORD

cluster.exe CLUSTER1 /priv HeartBeatLostNodeTicks=10:DWORD

After changing these settings, the cluster service was stopped and restarted on each node to ensure the changes took
effect. Of course, it was important to move the cluster resources between nodes before stopping the service to ensure that
the node being stopped and restarted was the passive node at the time.

File Share Witness Configuration

At this stage I was not finished with the configuration on the Hub Transport servers as these servers were to be the location
of the File Share Witness. The decision to use the Hub Transport servers as the location of the File Share Witness was in
line with Microsoft recommendations. Of course you are free to use any server that is capable of having a file share located
on it but as the Hub Transport servers obviously fall under the control of the Exchange administrators in most organizations
these make the best choice.

In normal circumstances there is only a single file share witness required and therefore I chose the server HUBCAS1for this
role. However, HUBCAS2 was also pre-provisioned with a file share witness to cater for the potential loss of HUBCAS1.
Here’s the process used to create the file share witness on HUBCAS1:

1. On the root of drive D: I created a folder called MNS_FSW_DIR_EX2007. This folder name followed the
Microsoft recommendation of using MNS_FSW_DIR_ followed by the CMS name. In this case MNS stands
forMajority Node Set, FSW stands for File Share Witness and the DIR shows you that this is a directory or
 folder name. You can create this folder anywhere you like but as I’ve indicated I chose the root of D: for this
particular installation. In the future, I think that I will be creating these folders somewhere under the main
Exchange installation folder instead, so that they are part of the Exchange installation structure.

2. Next the folder that was created in step 1 was shared using a shared name of MNS_FSW_EX2007. This share
name format is the Microsoft recommended format for the share name. Also, the cluster service account was
given full access to this newly created share. I did all this from a single command:

net share mns_fsw_ex2007 = d:\mns_fsw_dir_ex2007 /grant:neilhobson\excluster,full

3. Additional share permissions were then given to the built-in Administrators and cluster service account via the
following command:

cacls d:\mns_fsw_dir_ex2007 /g builtin\administrators:f neilhobson\excluster:f

4. Finally the cluster Majority Node Set resource was configured by running the cluster.exe command-line utility as
follows:

Cluster cluster1 res “Majority Node Set” /priv MNSFileShare=\\HUBCAS1\MNS_FSW_EX2007

In step 4, notice that the UNC path includes the HUBCAS1 server name. Some time ago Microsoft changed its
recommendations on recovery around loss of the server containing the file share witness. The old method involved the use
of DNS CNAME records whilst the newer method uses the cluster ‘forcequorum’ method. The reasoning behind this is
detailed on the Exchange team blog here and I recommend that you read this article.

CMS Installation

Now that the cluster was installed and configured correctly, along with the file share witness feature, the CMS itself was then
created by installing the Active Clustered Mailbox Role of Exchange 2007 SP1 onto the cluster node called NODE1. This
was achieved by running the Exchange 2007 setup.exe program as usual and following the various installation wizard
screens. It was important to ensure that a custom installation of Exchange 2007 was performed as the typical installation
does not allow for the installation of a CMS. At the Server Role screen of the installation wizard, the Active Clustered
Mailbox Role option was selected as you can see from Figure 8.
Figure 8: Installing The Active Clustered Mailbox Role

At the next screen, the Cluster Settings screen, the Cluster type option was set to Cluster Continuous Replication. The CMS
name was entered as EX2007 which, if you remember, is the name of the Exchange server that Outlook clients will connect
to. A suitable IP address was chosen for the CMS, not forgetting that this is a different IP address than the actual cluster IP
address that was chosen earlier.

CCR and Public Folders

I would like to point out here that during the installation of the CMS I did elect to create a public folder database on the CCR
environment. Although a CCR environment can host public folders, there are some caveats that you need to understand.
These caveats are documented in the article Planning for Cluster Continuous Replication under the section titled Cluster
Continuous Replication and Public Folder Databases and I recommend that you read this section carefully. The reason for
the approach taken within this design for public folder databases was simply because the requirement was for the public
folder data to be highly available in the same way as the mailbox data.

However, public folder databases have their own data replication mechanism and in some ways this replication model and
the replication model within CCR are incompatible. Since I had installed the CCR environment into an existing Exchange
2003 environment, there now existed two public folder databases which meant that public folder replication was enabled in
addition to the CCR replication model. Microsoft clearly states that in such a situation, if there is an unscheduled outage in
the CCR environment, the public folder database will not mount on the new active node until it can contact the original active
node. Note the reference to an unscheduled outage. In other words, during normal operations there are no problems.
With this in mind, deciding to implement a public folder database within a CCR environment that is coexisting with other
servers that contain a public folder database becomes a balancing act between the risk and convenience of such a
configuration. If you replicate and re-home your public folder data onto Exchange 2007 and remove the public folder
databases from Exchange 2003, the problematic configuration disappears anyway. It is an interesting design issue which
requires due thought. If the risk proves too great for you, implement a dedicated public folder server running Exchange
2007.

CMS Installation Completion

Once the CMS had been installed, the node was rebooted in accordance with the directive issued by the Exchange 2007
setup program. Once the active node had been rebooted and was fully started up, the installation of the passive node, in this
case NODE2, was commenced. This process is much easier than the installation of the active node since the only real
decision to be made is the choice of the Passive Clustered Mailbox Role which is the other option check box that you can
see immediately below the Active Clustered Mailbox Role in Figure 8. Once again, the setup program advised that this
server should be restarted before placing it into production so that’s what I did.

After NODE2 had fully restarted, I set about applying the same Update Rollup to both cluster nodes mainly because I had
neglected to install the update rollup at the time of the actual server installation! That’s not necessarily a bad thing as new
update rollups will be released in the future and therefore understanding how to apply them to a production environment is
going to be a requirement. The process for doing this is fairly simple and here’s what I did. I made sure that all resources
were moved to the cluster node that I was not updating, then, I applied the update to this node, the passive node. Once this
had completed, I moved the resources to the cluster node that I had just updated and then applied the update to the node
that was now passive. Do not forget to use the Move-ClusteredMailboxServer cmdlet to move the CMS between cluster
nodes. In my case a typical cmdlet that I used was:

Move-ClusteredMailboxServer EX2007 –TargetMachine NODE2 –MoveReason “Apply Update Rollup 3”

Summary

That’s it for part three of this article, in which we now have a working CCR environment alongside our combined Hub
Transport and Client Access Servers that are coexisting with Exchange 2003. It is important to spend time configuring the
cluster correctly before installation of the Exchange 2007 mailbox role onto the cluster nodes. In part four of this article we
are going to focus on the installation of the Edge Transport server role.

Introduction

The Exchange 2007 infrastructure has slowly been taking shape over the first three parts of this article. So far, I now have
two combined Hub Transport and Client Access Servers as well as a two-node Clustered Continuous Replication (CCR)
environment all coexisting with the existing Exchange 2003 servers. However, at this point I still had one more additional
Exchange 2007 role to install. Although I could have decided to start configuring the new Exchange 2007 servers at this
point, I decided to complete the installation of the new Exchange 2007 infrastructure first.

Edge Server Installation

The last server role to deploy was the Edge Transport server that was to replace an existing server running MailSweeper
software. The MailSweeper server was configured to send and receive Internet email through the MessageLabs service, so
this configuration had to remain. This actually made the configuration somewhat easier to manage, as this meant I did not
have to alter things such as the company Mail Exchanger (MX) records. The server designated as the new Edge Transport
server was prepared with the same applications as per the other server roles deployed, such as the .NET Framework,
Powershell and so on. Also, this server’s DNS suffix was changed from the default option such that the server had a
complete Fully Qualified Domain Name (FQDN). Admittedly this is one area that I can often forget when installing the Edge
Transport server role but it’s important that I completed this task otherwise the setup process would have not been able to
continue. To alter the DNS suffix, I brought up the properties of the computer object and went to the Computer Name tab.
From there I selected the Change button which brought up theComputer Name Changes window. On this window I was able
to click the More… button which brought up a further window called DNS Suffix and NetBIOS Computer Name. In this
window it’s possible to enter primary DNS suffix as you can see in Figure 9.
Figure 9: Entering The Primary DNS Suffix

I also needed to ensure that the Edge Transport and Hub Transport servers were capable of resolving each other’s names,
which can either be via DNS or traditional hosts files. Also, you may remember back in part one of this article that the Edge
Transport server had actually been made a member of the internal Active Directory domain, so I had already removed it
from the domain and moved it back into a workgroup configuration.

One additional key component installed onto the Edge Transport server was Active Directory Application Mode (ADAM),
which is available from the Microsoft downloads site here. ADAM was used because the Edge Transport server was running
on Windows 2003; had it been running on Windows 2008, I would have needed to install the Active Directory Lightweight
Directory Services role which has replaced ADAM on the Windows 2008 platform. There’s really not much to say about the
ADAM installation process as there aren’t any installation options to speak of; I simply followed the default installation
screens.

Once the relevant DNS changes had been made and ADAM had been installed I was able to then go ahead and install the
Edge Transport server role using the same techniques that you have already seen within the other parts of this article. Once
installed and the relevant Update Rollup applied, the server’s product key was entered as normal. At this stage I had a
functional Edge Transport server but it wasn’t actually configured to do anything at that time. I next needed to subscribe the
Edge server to the Active Directory site that contained the Hub Transport server roles.

Edge Subscription Process

The Edge subscription process is one of the great new features of the Edge Transport server role. Essentially it allows you
to subscribe one or more Edge Transport servers to the Active Directory site that contains the Hub Transport servers, the
result of which is a periodic one-way replication of configuration data as well as recipient information from Active Directory
into the ADAM database running on the Edge Transport servers. The main administrative benefit in doing this is that it
allows you to make any required configuration changes on the Hub Transport servers and have those changes replicated to
the Edge Transport servers, thereby reducing your overall effort. Also, Outlook safe sender information is aggregated onto
the Edge Transport servers.

Here’s the process I used to subscribe the Edge Transport server, EDGE1, to the Active Directory site that contained both
Hub Transport servers.

1. First I ran the Exchange Management Shell on EDGE1 and executed the cmdlet listed below. This created the
subscription information in a file called EdgeSubscription.xml on the root of drive C: on EDGE1. Note from the
information presented in Figure 10 that there is a finite amount of time, 1440 minutes, allocated to complete the
subscription before the bootstrap account expires.

New-EdgeSubscription –FileName “c:\EdgeSubscription.xml”

 Figure 10: New-EdgeSubscription Process

1. Next I had to copy the contents of this XML file from EDGE1 to one of the Hub Transport servers.

1. Once that had been done, the Edge subscription process could be completed either by using the Exchange
Management Console or Exchange Management Shell on the Hub Transport server. I chose to use the
Exchange Management Console and therefore the next thing to do was to navigate to the Organization
Configuration container, choose the Hub Transport container and then select New Edge Subscription… from
the context menu.

1. In the resulting New Edge Subscription wizard, I ensured that the Active Directory site: field was set to the
correct Active Directory site and then proceeded to import the EdgeSubscription.xml file that I had previously
copied by selecting the Browse… button. I also ensured that the option to Automatically create a Send
connector for this Edge Subscription check box was selected. This screen is shown in Figure 11. Note that in
this example the Active Directory site name is HeadOffice.
 Figure 11: New-EdgeSubscription Wizard

1. Once the wizard had run, I was presented with a warning that stated that I must ensure that there is name resolution
between the Edge Transport and Hub Transport servers and that the Hub Transport servers can connect to the Edge
Transport servers on port 50636. This is why it’s important to ensure that the name resolution process works and that your
firewall has been configured accordingly.

1. Finally, I forced the Edge synchronization process to run immediately by running the Start-
EdgeSynchronization cmdlet and checking for a successful synchronization. You can see an example of this
process in Figure 12.
Figure 12: Successful Edge Synchronization Process

Internet Email

The thing to remember is that the Edge Subscription process automatically creates the necessary Send connector that is
required to send Internet email outside of your organization. However, this Send connector has an address space of *,
meaning that it will be able to process messages destined for any Internet domain name. Fortunately it is also configured
with a cost of 100 by default, which means that any existing SMTP Connector that is configured in Exchange 2003 will likely
have a smaller cost and therefore will still be preferred as the connector to send Internet email. In other words, Internet email
should still flow via the existing routes rather than via the new route configured on the Edge Transport server. You can see
this address space and cost configuration in Figure 13 where the basic properties of the Send connector were obtained
using the Exchange Management Shell.

Figure 13: Send Connector Default Address Space and Cost

Of course, there came a time when I needed to test that the Edge Transport server was capable of sending and receiving
Internet email. Before I did this I had to ensure that the MessageLabs system was aware of this new server, of course. To
test email connectivity, I raised the cost of the Exchange 2003 SMTP Connector and lowered the cost of the Exchange 2007
Send connector so that the Send connector was the preferred route. I also changed the protocol logging level to Verbose on
the Send connector, an example of which can be seen in Figure 14. Don’t forget that configuration changes such as this
were performed on the Hub Transport server and replicated to the Edge Transport server via the Edge Subscription process.
Figure 14: Send Connector Protocol Logging

Doing this allowed me to examine the contents of the Send connector protocol logs on both the Hub Transport and Edge
Transport servers to confirm that these servers were indeed processing the messages rather than the legacy Exchange
2003 servers. By default these log files can be found in the two subfolders located in the \Program Files\Microsoft\Exchange
Server\TransportRoles\Logs\ProtocolLog folder, an example of which you can see in Figure 15.
Figure 15: SMTP Protocol Log

Summary

That concludes part four of this article, which now sees a fully installed Exchange 2007 infrastructure coexisting with
Exchange 2003. With regards to the Internet email connectivity, you could, of course, leave this until after you have migrated
everyone to Exchange 2007; it’s your choice. In the next part we’ll start to look at the configuration of the Exchange 2007
environment prior to migration of mailboxes.

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 QueueDatabasePathparameter 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.
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.

Introduction
If you have been following this article series you will know that we ended part five having started the configuration of the
Exchange 2007 environment prior to any users being migrated to it. I will save article space by refraining from any in-depth
introduction text – let us get straight back into the configuration performed on the system.

Delivery Status Notification Message Sizes

Historically, Exchange has had a useful user feature whereby if a user received a Delivery Status Notification (DSN), the
entire original message was sent back to the user. For example, if a user sent a 20MB PowerPoint presentation file to
someone external to their organization but misspelled the external email address, Exchange would include the 20MB
PowerPoint attachment with the DSN. The idea behind this feature is that the user could then simply use the Send
Again button on the DSN, correct the address and send the message on its way. Figure 21 shows this feature.

Figure 21: Send Again Feature in Outlook

This is a nice feature for a user but at the same time it can quickly become an irritation both for the user and the system
administrator. If you think about it, the user has a 20MB message in their Sent Items folder already and they now have a
20MB message sat in their Inbox which is affecting their mailbox quota. Additionally, if an archiving system is in use then this
20MB DSN may also be archived. Earlier versions of Exchange sent back the entire message contents along with the DSN
but changes were made with Exchange 2003 to limit this to attachments less than 10MB, which is a configuration setting
that has been maintained in Exchange 2007. In other words, if the original message that the user sends exceeds 10MB then
only the message headers are sent back to the user in the DSN. Additionally, Exchange 2007 allows you to control this size
restriction on both internal and external DSNs. This can be effective in controlling overall mailbox sizes and system
resources and is something that I regularly configured on Exchange 2003 systems. In fact, it was not uncommon for
organizations to set this limit to something small such as 100KB or even to disable the feature entirely.

As I have said Exchange 2007 has this limit set to 10MB by default for both internal and external DSNs. For the project that I
was working on, the requirement was to disable the feature altogether. To do this, I had to use the Set-
TransportServer cmdlet with the two key parameters
being ExternalDsnMaxMessageAttachSize andInternalDsnMaxMessageAttachSize. These parameters can be a numerical
value but in my case they were set to 0 which means that only the original message headers were sent back with the DSN. I
configured the settings on both Hub Transport servers as well as the Edge Transport server. The cmdlets that I used were:

Set-TransportServer –Identity {server name} –InternalDsnMaxMessageAttachSize 0

Set-TransportServer –Identity {server name} –ExternalDsnMaxMessageAttachSize 0

Running this cmdlet successfully simply returned me back to the command prompt, so I decided to check the configuration
by running the Get-TransportServer cmdlet:

Get-TransportServer –Identity {server name} | fl *attach*

This retrieved all parameters from the Get-TransportServer cmdlet that have the string ‘attach’ in their names. For example,
consider Figure 22 below which shows the results of this cmdlet run against the local Hub Transport server.
Figure 22: Results of Get-TransportServer cmdlet

SMTP Pickup Folder

Also found on the Hub Transport and Edge Transport server roles is the SMTP Pickup folder. This is often used in Exchange
environments to test mail flow by copying formatted text files into this folder which are then processed by Exchange as a
normal email message. I have already covered the SMTP Pickup folder in detail here on msexchange.org so I will not be
repeating that level of information in this article. What I do want to mention here is mainly a reminder that, in some cases,
this functionality can be disabled which was the chosen configuration option for this project. To achieve this, the Set-
TransportServer cmdlet was run to set the PickupDirectoryPath attribute to $null. The cmdlet that was run was therefore:

Set-TransportServer –Identity {server name} –PickupDirectoryPath $null

However, one word of caution before you go ahead and disable this feature. Do check whether any applications in use
within your environment are using the SMTP Pickup folder since disabling it could have an adverse affect on those
applications.

Transport Dumpster Configuration

Since an Exchange 2007 CCR environment had been installed, additional configuration was required to support this. One
important component of a CCR environment is the transport dumpster feature, which helps to combat data loss that can
occur during a lossy failover event in the CCR environment. If a lossy failover occurs, the transport dumpster feature allows
each Hub Transport server in the same Active Directory site as the CCR environment to re-deliver email messages. By
default, the transport dumpster on each Hub Transport server is set to 18MB in size and the recommendation from Microsoft
is to set this to 1.5 times the size of the maximum message size permitted within the organization.

Since I had set the maximum message size to 10MB, it followed that I needed to set the transport dumpster size on both
Hub Transport servers to 15MB. To do this, I ran the Set-TransportConfig cmdlet, specifying the –
MaxDumpsterSizePerStorageGroup parameter. Note that the cmdlet is focused on the overall transport configuration and
not the configuration of any single specific Hub Transport server. In other words, making changes via the Set-
TransportConfig cmdlet means that the changes apply to the entire Exchange 2007 organization. The cmdlet used was:

Set-TransportConfig –MaxDumpsterSizePerStorageGroup 15MB

It was also important at this time to ensure that the MaxDumpsterTime parameter was configured with the Microsoft
recommended value of 7 days, which happens to be the default value. This parameter controls when messages are
removed from the dumpster based on the assumption that the value specified by the MaxDumpsterSizePerStorageGroup
has not been reached. The idea here is that 7 days should help protect you from a lengthy outage. As I said earlier, the
default value is 7 days anyway but I do like to check that this setting is correct. To do this I ran the following cmdlet:

Get-TransportConfig | fl

The results of this cmdlet can be seen in Figure 23.

 Figure 23: Checking the MaxDumpsterTime Parameter

CCR Availability Configuration

To finish off this part of the article series, I want to cover a configuration option that can sometimes be overlooked in a CCR
environment. Each CCR environment is equipped with a parameter know as the AutoDatabaseMountDial which, as its name
suggests, is responsible for determining whether the databases can be automatically mounted by the Exchange Information
Store service after a lossy failover scenario. Whether to automatically mount the databases is determined by the
administrator who acknowledges how many transaction logs can be lost. There are three settings for
AutoDatabaseMountDial:

• Lossless. This setting means that no logs at all should be lost. What this essentially means is that, after the failure of the
active node, the newly active node will require that the failed node comes back online with all required transaction logs
available for copying. Once this has happened, the databases will automatically mount, ensuring no data loss.
• Good Availability. With this setting, up to three transaction logs can be lost in which case the databases will still mount
automatically.
• Best Availability. This is the default setting and allows for the loss of up to six transaction logs.

It is important when designing any CCR environment to think about the AutoDatabaseMountDialSettings and how this
affects your overall service, in particular your Service Level Agreements (SLAs) for Exchange. In my case, the decision was
to leave this configuration option at the default setting of Best Availability, since it was deemed that high availability was
important to the business. I then checked the configuration via the Get-MailboxServer cmdlet. For example, look at Figure
24 where you can see that this cmdlet has been run against the local mailbox server and filtered to only show attributes
containing the string auto. You can see that in this example the setting has been changed to Lossless.

Figure 24: Checking The AutoDatabaseMountDial Parameter – Exchange Management Shell

Of course, since Exchange 2007 Service Pack 1 came out, this configuration option is also available in the Exchange
Management Console. To find it, navigate to the Server Configuration area and select the Mailbox object. Locate your CCR
Clustered Mailbox Server (CMS) object, right-click it and choose Properties from the context menu. On theClustered Mailbox
Server tab, select the relevant option from the Auto database mount dial drop-down list. You can see this in Figure 25.
Figure 25: Checking The AutoDatabaseMountDial Parameter – Exchange Management Console

Summary

Here in part six of this article series we have continued our look at the configuration of the Exchange 2007 environment,
covering some lesser-known configuration issues such as the way to handle attachments that are sent with delivery status
notifications. Setting such options can help streamline an Exchange installation and so they’re worth examining to see how
the features plan out in your environment. In the next part we will continue to look at the configuration, focusing on areas
such as the Client Access Server certificates.

Introduction

In part six of this article series we looked at various items that I needed to configure within the Exchange 2007 environment.
An example of which would be the transport dumpster and CCR availability configuration parameters. In part seven we are
going to start looking at one of the new key areas of Exchange 2007, namely certificates. Let us begin by taking a look at
what has changed regarding certificates on the Exchange 2007 Client Access Servers by going over the certificate creation
process.

Client Access Server Certificates

By default, Exchange 2007 installs self-signed certificates that are acceptable for use on the Hub Transport and Edge
Transport server roles in most situations. There are however one or two exceptions, such as using Edge Transport server
features, namely domain security. However, the self-signed certificates are not suitable for Client Access Server features
 such as Outlook Anywhere and long-term use of Outlook Web Access. As a result, the self-signed certificates installed on
Client Access Servers should be replaced. In my project scenario, the Client Access Server role and the Hub Transport
server role coexisted on the same servers, so in effect, I also replaced the Hub Transport server certificate too.

Within the customer’s Active Directory environment there was an internal Windows-based Certificate Authority (CA) that was
capable of issuing the required certificates. This was good to see, since there are many Microsoft products other than
Exchange 2007 that require the use of certificates, such as Office Communications Server 2007 for example. Once the
Windows CA had been set up, it was obviously free in monetary terms to create certificates using this method rather than
purchasing them from a public CA. Of course, certificates issued by a public CA are required on the ISA Server since it was
accepting public requests for services such as Outlook Web Access, Outlook Anywhere and so on.

To create new certificates for the Client Access Servers, the first thing that needs to be done is to generate a new certificate
request using the New-ExchangeCertificate cmdlet. It is very important to understand the various names that this certificate
will require. Since the certificate requires multiple names, the Subject Alternate Name attribute is used. On my certificates I
ensured that the following names were present:

• The FQDN of the server, such as hubcas1.neilhobson.com or hubcas2.neilhobson.com.

• The NetBIOS name of the server, such as hubcas1 or hubcas2. This is not strictly required, but I always add it anyway as
quite often I like to test and use Outlook Web Access simply by entering https://servername/owa. Adding the server’s
NetBIOS name to the certificate makes sure that you do not get a certificate warning prompt when using the server’s
NetBIOS name.
• The accepted domain name for the organization (such as neilhobson.com) which in my example, only a single accepted
domain name is in use. However, in cases where additional accepted domain names are present you need to cater for them.
An easy way to do this in Exchange 2007 Service Pack 1 is to use the –IncludeAcceptedDomains parameter of the New-
ExchangeCertificate cmdlet which ensures that all accepted domains that you have defined are included in the certificate
request.
• The autodiscover domain name, such as autodiscover.neilhobson.com. In fact, I used the new –
IncludeAutodiscover parameter of the New-ExchangeCertificate cmdlet for this purpose. Like the –IncludeAcceptedDomains
parameter, this ensures that the autodiscover name for any additional accepted domain names is included in the certificate
request. You do not have to use this parameter. If you do get into the habit of using it you will not forget any additional
domain names that might be required.
• The name that users will use to access email remotely, such as email.neilhobson.com.

Had I been using a certain technology such as Windows Network Load Balancing (NLB), it would have been a requirement
to include the NLB name in the certificate too if it was different to the remote access name, but this was not the case in my
project. Just to elaborate on this a bit further, imagine that users externally typedemail.neilhobson.com to access Outlook
Web Access when working remotely. It makes sense, from a training perspective, to allow the users to type the same
address into their browsers when working on the internal network. If using NLB, you could therefore make sure that the NLB
name was set to email.neilhobson.com, to give users a consistent naming experience when accessing Outlook Web Access.
However, if you had decided to implement a different name for Outlook Web Access via NLB internally, such
as nlb.neilhobson.com, you would need to make sure that the name nlb.neilhobson.com was also included in the certificate
names.

Creating The Certificates

To create the certificate request, I ran the New-ExchangeCertificate cmdlet with quite a few different parameters. The full
cmdlet I used was similar to this:

New-ExchangeCertificate –GenerateRequest –Path c:\hubcas1.txt –SubjectName cn=hubcas1.neilhobson.com –

DomainName email.neilhobson.com, hubcas1, hubcas1.neilhobson.com –IncludeAcceptedDomains –IncludeAutodiscover –
PrivateKeyExportable $true

Let us now go through each parameter and discuss what it allowed me to do.

• GenerateRequest: This allowed me to create a certificate request file rather than a self-signed certificate.
• Path: Here I specified the file that was to contain the certificate request generated, namely c:\hubcas1.txt.
• SubjectName: This parameter links the certificate with a server name and is in the style of an X.500 distinguished name. In
my case, the certificate was issued to hubcas1.neilhobson.com.
• DomainName: You will note that I ensured that the DomainName field contained the external access name, the NetBIOS
name and the Fully Qualified Domain Name (FQDN). This means that all these names were present on the certificate.
• IncludeAcceptedDomains: As I discussed earlier, I usually add this parameter to ensure that any additional domains
defined as accepted domains within the Exchange 2007 configuration are added to the certificate.
• IncludeAutodiscover: Like the accepted domains, I usually add this parameter to ensure that additional autodiscover
domain names are added appropriately.
• PrivateKeyExportable: This is useful tool to allow you to export the certificate, such as when you copy the certificate to an
ISA Server.

Once I ran this command it completed and informed me of the certificate thumbprint and subject name. An example of this
can be seen in Figure 26.

Figure 26: New-ExchangeCertificate Cmdlet

Running this cmdlet also created the file c:\hubcas1.txt on the Client Access Server. This is the familiar certificate request
file, the contents of which will look similar to that shown in Figure 27.
Figure 27: Contents of a Certificate Request File

As I mentioned earlier, in my project, an internal Windows CA was present and was able to be used to create the certificates
for the combined Hub Transport and Client Access Servers. To create the certificates I used the following process:

1. I first navigated to the web interface of the CA by bringing up a browser and going to http://server/certsrv. Here,
‘server’ should be replaced with the name of the server running the Windows CA. This brought up the welcome
screen that you can see in Figure 28.
 Figure 28: Windows CA Welcome Screen

1. From the welcome screen I chose the option to Request a certificate. This action brought up the Request a
Certificate screen that you can see in Figure 29.

Figure 29: Windows CA Request a Certificate Screen

1. From the Request a Certificate screen, I chose the option to submit an advanced certificate request. This action brought
up the Advanced Certificate Request screen that you can see in Figure 30.

Figure 30: Windows CA Advanced Certificate Request Screen

1. From the Advanced Certificate Request screen, I chose the option that starts with Submit a certificate request by using a
base-64-encoded CMC or PKCS #10 file. This action then brought up the Submit a Certificate Request or Renewal
Request screen that you can see in Figure 31.

Figure 31: Windows CA Submit a Certificate Request Screen

1. In the Saved Request field, I pasted the contents of the certificate request file hubcas1.txt. I then made sure that
the Certificate Template field was set to Web Server. The completed screen can be seen in Figure 32.
 Figure 32: Windows CA Completed Submit a Certificate Request Screen

1. Once completed, I clicked the Submit button which resulted in the Certificate Issued screen that you can see in Figure 33.
From here, I ensured that the DER encoded option was selected and then chose the Download certificate link that you
can see on the same screen. I then saved the resulting certificate file, certnew.cer, locally onto the Client Access Server.

Figure 33: Windows CA Certificate Issued Screen

Summary

This completes part seven of this article series, where we have seen the initial steps of the process in replacing the self-
signed certificate that is installed as part of the overall Client Access Server installation routine. This certificate generation
process simply involves running an Exchange Management Shell cmdlet and creating the certificate via the Certificate
Authority website. In the next part of this series we will import and enable the certificate.

Introduction
We left part seven of this article series having created the certificates for the Client Access Servers. This was done by
creating the certificate request file and processing this request file via the Windows Certificate Authority website. At the end
of part seven we were left with a file called certnew.cer which contained our newly created certificate. All that remained for
me to do at this point was to import the certificate into the Client Access Server and then enable it. This part of the article
series will show you how I did this and then move on to cover a new topic, enabling of Outlook Anywhere.

Importing and Enabling the Certificates

The certificate creation process detailed in part seven of this article series completed the certificate issuing process but of
course it still has not been imported into Exchange at this point. Neither had the certificate been enabled after importing. You
can perform these two tasks individually if you like, or pipe the results of one into the other. For example, I ran the Import-
ExchangeCertificate cmdlet and piped the results into the Enable-ExchangeCertificate, electing to enable the certificate for
the IIS and SMTP services. You can see the result of this cmdlet in Figure 34. As I was overwriting the default self-signed
SSL certificate for the SMTP service, I was prompted to confirm this overwriting process as you can also see in the figure.
Do not forget to include the POP, IMAP or UM services if you are enabling your certificate for those services.

Figure 34: Importing and Enabling The Certificate

Once imported and enabled, I checked the properties of the certificate for correctness. You can use Internet Information
Services Manager to do this, or perhaps the Certificates snap-in. I suspect that most administrators know how to use the
Internet Information Services Manager snap-in, so here is the process to check the certificate using the Certificates snap-in.

1. Click Start, then Run, type mmc into the run window and choose OK.

2. In the resulting window, which should be called Console1, click File and then choose the Add/Remove Snap-
in option.

3. From the resulting window, click the Add button which will bring up the Add Standalone Snap-in window.
Choose the Certificates snap-in and then click the Add button.

4. You will now be presented with the Certificates snap-in window, from which you should choose theComputer
account option. Once chosen, click Next.

5. In the Select Computer window, choose Local computer and then click Finish.

6. You will now be back at the Add Standalone Snap-in window. Since you do not require any more snap-ins, click
the Close button.

7. Now back at the Add/Remove Snap-in window, click OK.

8. The main Console1 window is shown again, but this time with the Certificates snap-in loaded. Expand
theCertificates object and then expand the Personal certificate store located underneath it. Once you have
done this, select the Certificates object and you should now see the certificates listed like in the example
shown in Figure 35.
Figure 35: Certificate Store

1. Double-click the certificate that you have just created and examine its properties to make sure that they are
correct and valid. For example, on the Details tab scroll down until you find the Subject Alternative Namefield
and you should see the various names that the certificate is configured with. An example is shown below in
Figure 36.

Figure 36: Certificate Subject Alternate Names

Since I had implemented two separate servers running the Hub Transport and Client Access Server roles, I had to perform
this entire procedure again on the other server. Of course, I had to ensure that parameters of the New-ExchangeCertificate
cmdlet, such as the DomainName parameter, had the correct names relevant to this other server. For example, this
parameter would need to include the NetBIOS and FQDN names of this server, such as hubcas2 and
hubcas2.neilhobson.com.

Enabling Outlook Anywhere

If you have been reading all of this article series you may remember that way back in the first part I mentioned the fact that
the RPC over HTTP proxy service was installed onto the Client Access Servers since Outlook Anywhere was to be used.
Installing this component was a vital part to the successful working of Outlook Anywhere. Another key part was the enabling
of the Outlook Anywhere service on the Client Access Servers. To do this, I personally used the Exchange Management
Console although of course the Exchange Management Shell can be used too. Here is the steps I took to enable Outlook
Anywhere using the Exchange Management Console:

1. I first navigated to the Server Configuration area in the left-hand pane and under this selected Client Access.

2. I then right-clicked the relevant Client Access Server and chose Enable Outlook Anywhere from the context
menu.

3. The Enable Outlook Anywhere wizard was then displayed as you can see from Figure 37. All I then did was
type in the external Outlook Anywhere host name. I chose to use autodiscover.neilhobson.com to reduce the
number of certificates used externally, although of course, you can set this as you see fit. Some organizations
choose to use different external DNS names that reflect the service they provide, such
asoutlook.neilhobson.com for example. Since I was using ISA Server 2006 I was also able to offer NTLM
authentication but note that there are requirements in this area, such as the use of Kerberos Constrained
Delegation (KCD).
Figure 37: Enabling Outlook Anywhere

Now, this article series is already getting quite long and I need to ensure the focus stays on Exchange. However, I’m well
aware that publishing technologies such as Outlook Anywhere requires additional skill areas in products like ISA Server
2006. You can find more information on this area in a blog called Me, Myself and ISA which is written by a work colleague of
mine Jason Jones. Jason is a ForeFront MVP and explains much more information on publishing Exchange 2007 in his blog
post here.

Setting ExternalURLs

I am going to finish part eight of this article series by covering the setting of the parameter known as
the ExternalUrlparameter on various components. The Outlook Anywhere client needs to connect to various services such
as Exchange Web Services, Offline Address Book and also Unified Messaging. The Exchange Web Services provide
functionality such as the Out of Office message. To connect to these services, the Outlook Anywhere client first locates the
autodiscover service which, in my example, was available via the URL
https://autodiscover.neilhobson.com/autodiscover/autodiscover.xml. This XML file then contains the URLs to the
aforementioned services. To set these URLs involves running several Exchange Management Shell cmdlets. The cmdlets I
ran were:

Set-WebServicesVirtualDirectory –Identity ‘HUBCAS1\EWS (Default Web Site)’ –ExternalUrl

https://autodiscover.neilhobson.com/ews/exchange.asmx
 This cmdlet sets the Web Services virtual directory to be externally accessible via the URL that you can see in the cmdlet.
Of course, this had to be run against both CAS servers, remembering to change the –Identity parameter to match the
relevant CAS server.

Set-OabVirtualDirectory –Identity ‘HUBCAS1\EWS (Default Web Site)’ –ExternalUrl

https://autodiscover.neilhobson.com/oab

This cmdlet is very similar to the previous cmdlet but of course it now references a different service in the Offline Address
Book. In this particular project I was not using the Unified Messaging service so I did not have to run the final cmdlet shown
below, but, I did it anyway to ensure that the configuration was present should the Unified Messaging server role be
installed. The final cmdlet ran was:

Set-UmVirtualDirectory –Identity ‘HUBCAS1\EWS (Default Web Site)’ –ExternalUrl

https://autodiscover.neilhobson.com/unifiedmessaging/service.asmx

Summary

That concludes part eight of this article series, where we have finished the process of replacing the self-signed certificates
on the CAS servers by importing and enabling the new certificates created via the internal Windows Certificate Authority. We
have also covered the enabling of Outlook Anywhere and the setting of the various external URLs that Outlook uses for
features such as the Out of Office assistant and the Offline Address Book. I will be wrapping up this article series in part
nine.

ntroduction

This is the 9th and final part of this article series looking at a project to transition from Exchange 2003 to Exchange 2007. In
parts one to eight, we have looked at many different areas such as system prerequisites, installing the new server roles,
configuring many different aspects of system operation and complex areas such as certificate generation and installation. I
did state earlier in this article series that I would not focus on some of the more obvious configuration areas of Exchange
2007 as this information can be found in abundance in various articles out there on the Internet. The type of information I’m
referring to includes areas such as:

• Creating the storage groups and mailbox databases

• Configuring mailbox quota limits and when the storage warnings are sent
• Configuring settings such as global Out of Office and automatic replies/forwards
• Configuring deleted item retention and deleted mailbox retention

Of course no installation of Exchange 2007 can be considered complete without the configuration of such items as those
listed above so do take time to make sure that your environment is configured accordingly.

Here in the last part of this article series I will cover a few final configuration areas, starting with the Security Configuration
Wizard.

Security Configuration Wizard

The Security Configuration Wizard (SCW) is a tool used to disable some of the functionality that is not used by the various
Exchange 2007 server roles, thereby minimizing the attack surface on those server roles. Once I had installed the various
Exchange 2007 server roles, and before any data was migrated, I installed the SCW on each Exchange 2007 server and
configured it accordingly. It is important that you install and test your Exchange 2007 servers without the SCW to ensure that
they are functioning correctly. Once you are happy that they are functioning correctly, you can install and configure the SCW
and test again. It’s much easier this way to spot any functionality that the SCW may break.

Installing the SCW is really easy. To do this, all I had to do was to go to the Control Panel and choose the Add/Remove
Programs applet. The SCW is a Windows component as you can see from Figure 38.
Figure 38: Installing the Security Configuration Wizard

Once installed, I was able to find the SCW in the Administrative Tools folder on my desktop. However, before running the
SCW it is a requirement to register the SCW extensions for the Exchange 2007 server roles. This is required because, by
default, SCW knows nothing about the specifics required for an Exchange 2007 installation. The extensions for Exchange
2007 allow SCW to have this knowledge. I found the extensions in the Scripts folder of my Exchange 2007 installation. In my
case this was C:\Program Files\Microsoft\Exchange Server\Scripts.

The extensions come in the form of an XML file, of which there are two. One XML file, called Exchange2007.xml, is for the
Mailbox, Hub Transport, Client Access Server and Unified Messaging server roles, whilst the other,
calledExchange2007Edge.xml, is for the Edge Transport server role. To register these XML files, I used the following two
commands:

scwcmd register /kbname:Ex2007KB /kbfile:”c:\program files\microsoft\exchange server\scripts\exchange2007xml”

scwcmd register /kbname:Ex2007EdgeKB /kbfile:”c:\program files\microsoft\exchange

server\scripts\exchange2007edgexml”

Once the SCW extensions had been registered I was able to then run the SCW and create a new security policy to apply to
the Exchange 2007 servers. Now, there are far too many screens on the SCW to detail here so I advise you to read detailed
SCW configuration information that you can find here.

Public Folder Migration

As I am sure you all know by now, public folders are de-emphasized in Exchange 2007 but are still readily available and, in
fact, are a required feature if the version of Outlook in use is earlier than Outlook 2007. This is because these earlier
versions of Outlook use the public folder system for functionality such as the storing and retrieval of free/busy information.
On the project that I am outlining in this article, Outlook 2003 was widely in use although some users were using Outlook
2007. Therefore, it was important that the system public folder information was migrated to Exchange 2007. Additionally,
normal user public folders were in use anyway, so these also had to be migrated.
As I explained in part three of this article series, I had already created a public folder database within the CCR environment
and accepted the potential issue that could occur if the CCR environment experienced a lossy failover. I therefore needed to
replicate and re-home the public folders from the Exchange 2003 environment to the Exchange 2007 environment. To do
this, I used the MoveAllReplicas.ps1 script provided with Exchange 2007. You will find this script in the \Program
Files\Microsoft\Exchange Server\Scripts folder on the drive where you installed Exchange 2007. From one of the Exchange
2007 servers, I loaded the Exchange Management Shell and ran the following cmdlet:

MoveAllReplicas.ps1 –Server E2K3SRV1 –NewServer EX2007

It should be fairly obvious from the parameters above that this cmdlet moves all public folders from the Exchange 2003
server called E2K3SRV1 to the Exchange 2007 server called EX2007. In my case, the Exchange 2007 server name is
actually the Clustered Mailbox Server (CMS). It’s very important to note that this replication and re-home process can take
some time to complete, depending on how many public folders there are, how many items are in these public folders and
also the size of the items within the public folders. On your project, you may need to control when the replication occurs, to
make sure that you don’t add too much network traffic during the working day. To do this, you can modify the replication
schedule accordingly. The end result that I was waiting for was zero entries shown in the Public Folder Instances tab on the
Exchange 2003 servers. An example screen shot of what I needed to wait for is shown in Figure 39.

Figure 39: Empty Public Folder Instances

Moving Mailboxes

Of course, I eventually had to move the user mailboxes from the Exchange 2003 servers to the Exchange 2007 servers.
Over the years I’ve always favored the approach of building new Exchange servers and moving the mailboxes across, as
opposed to performing in-place upgrades of the existing Exchange servers. This approach always presents the least risk to
the business and also has the least amount of downtime for the users. Fortunately with Exchange 2007 you can not perform
an in-place upgrade of an Exchange 2003 server to Exchange 2007 so the only available option is to move the mailboxes
across from one server to another.

I’ve detailed the process of moving mailboxes in a two-part article here on msexchange.org, so I won’t be repeating this
information within this article here. One thing I want to add, though, is that a few weeks ago I was asked how you move a
specific list of users at the same time rather than an entire mailbox database for example. To do this you can use an array
within an Exchange Management Shell script. Here’s an example:
$UsersToMigrate = "ann", "bob", "carol"
ForEach ($SingleUser in $UsersToMigrate) {Move-Mailbox -Identity $SingleUser -TargetDatabase "E2K7\First Storage
Group\Mailbox Database" -Confirm:$false}

In this script, the three users with aliases of Ann, Bob and Carol respectively are moved from wherever their current mailbox
database is to a target mailbox database called Mailbox Database held in a storage group called First Storage Group on a
server called E2K7.

Decommission Exchange 2003

There will eventually come the time when you need to decommission your Exchange 2003 servers. Decommissioning these
servers is a fairly straightforward process in that you obviously need to ensure that all mailbox and public folder data is
moved off of these servers. In addition, you need to ensure that any connectors are moved to other servers. However, some
additional steps need to be taken to remove the last Exchange 2003 server from an organization that is being transitioned to
Exchange 2007. I have detailed the steps you need to take in an article series here on msexchange.org so I won’t be
repeating those steps in this article.

Summary

That completes this article series on the overall steps required to transition from Exchange 2003 to Exchange 2007. I have
covered a fair bit of ground during this series and I hope that it has given you some pointers on the various steps that can be
performed during a transition. As always, it’s best to try these methods out in a lab environment before attempting them on
your production servers.