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

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

n 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 Installation option 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 Advanced
menu 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 as neilhobson\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).
If you would like to read the other parts in this article series please go to:

his 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 chose Properties 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 HUBCAS1 for 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 for Majority 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.

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

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 the Computer 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

2. Next I had to copy the contents of this XML file from EDGE1 to one of the Hub
Transport servers.
3. 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.
4. 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

5. 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.
6. 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.

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.

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

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 and InternalDsnMaxMessageAttachSize. 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 the Clustered 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.

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

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 typed email.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

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

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

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

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

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

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

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 the Computer 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 the Certificates 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

 9. 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 Name field 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 as
outlook.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 ExternalUrl parameter 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.

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

Introduction
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, called Exchange2007Edge.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.

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