A Practical Look at Migrating From Exchange 2003 to Exchange 2007

8/14/2019 A Practical Look at Migrating From Exchange 2003 to Exchange 2007

http://slidepdf.com/reader/full/a-practical-look-at-migrating-from-exchange-2003-to-exchange-2007 1/54

A Practical Look at Migrating From Exchange 2003 to

Exchange 2007

Part1

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 buildthe 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 additionalreading, 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 agingMailSweeper 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 todeploy 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 samedefault 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, wereimplemented 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 allservers 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 EdgeTransport 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.

http://msexchangeteam.com/archive/2007/07/18/446400.aspx




• 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 allapplication event log sizes were at least 40MB, with the option to overwrite events asneeded 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 thecombined 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 roleexists 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 Exchange2007 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 thisarticle but for the purposes of this article what you need to know is that the setup.com programwith 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

http://www.msexchange.org/articles_tutorials/exchange-server-2007/migration-deployment/closer-look-preparing-active-directory-exchange-2007-part1.html





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. Thisis 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 twoof 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.



Part2

Introduction

In part one of this article, I set the scene for the remaining parts of this article as well as detailedthe 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 ClientAccess 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 ClientAccess 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 inan 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. Thisscreen is shown in Figure 2.



Figure 2: Bridgehead Server Selection

In my case the Exchange 2003 environment simply consisted of a single routing group thatcontained 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 thenfully 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 thenrepeated 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 asthe 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 notselected. 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 NetBIOSover 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 Setquorum 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 youcan 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 WebPublishing 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 programso 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 Isimply 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 thatI 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 neededto 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 witnessconfiguration as well as the installation of the Clustered Mailbox Server (CMS).



Part3

Introduction

This is the third part of an article series covering a project to transition from an existingExchange 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 2003environment. 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 presentedme 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 restartedwas 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 chosethe 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 ShareWitness 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 Exchangeinstallation 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” /privMNSFileShare=\\HUBCAS1\MNS_FSW_EX2007

In step 4, notice that the UNC path includes the HUBCAS1 server name. Some time agoMicrosoft 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 theExchange 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 thetypical 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 IPaddress 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 waysthis 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 tothe 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 environmentthat 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 fullystarted 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 bea requirement. The process for doing this is fairly simple and here’s what I did. I made sure thatall 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 notforget to use the Move-ClusteredMailboxServer cmdlet to move the CMS between cluster nodes.

In my case a typical cmdlet that I used was:

http://technet.microsoft.com/en-us/library/bb123996.aspx

http://technet.microsoft.com/en-us/library/bb123996.aspx



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 environmentalongside 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 aregoing to focus on the installation of the Edge Transport server role.



Part4

Introduction

The Exchange 2007 infrastructure has slowly been taking shape over the first three parts of thisarticle. 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 2007role 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 existingserver 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 toalter 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 thecomputer 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 beenmade 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. ADAMwas 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 notmuch 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 Rollupapplied, 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 tosubscribe 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 ADAMdatabase 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 thatthere is a finite amount of time, 1440 minutes, allocated to complete the subscription

before the bootstrap account expires.

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

http://www.microsoft.com/downloads/details.aspx?FamilyID=9688f8b9-1034-4ef6-a3e5-2a2a57b5c8e4&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=9688f8b9-1034-4ef6-a3e5-2a2a57b5c8e4&DisplayLang=en



Figure 10: New-EdgeSubscription Process

2. Next I had to copy the contents of this XML file from EDGE1 to one of the HubTransport servers.

3. Once that had been done, the Edge subscription process could be completed either byusing 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 EdgeSubscription check box was selected. This screen is shown in Figure 11. Note that in thisexample 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 ensurethat 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. Youcan 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 necessarySend 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 bydefault, 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 andcost 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 MessageLabssystem 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 tothe 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 befound in the two subfolders located in the \Program Files\Microsoft\ExchangeServer\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 2007infrastructure 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’syour choice. In the next part we’ll start to look at the configuration of the Exchange 2007

environment prior to migration of mailboxes.



Part5

Introduction

So far in parts one to four of this article series we have constructed the new Exchange 2007environment 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 thefocus 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 theExchange 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 productdocumentation 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 byseparating 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\ExchangeServers\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\ExchangeServer\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 withinthe 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\ExchangeServer\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 Transportservice 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 twoof 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 acouple of Exchange Management Shell cmdlets.

In my case, one of the configuration steps that I performed was to update the Routing GroupConnectors 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 Exchangeservers 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 connectorswith 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 thefollowing 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 2003environment, 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,000KBand 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\ExchangeServer\ClientAccess\owa folder and the parameter of interest is maxRequestLength as you cansee 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

SummaryThat concludes part five of this article series covering a project to transition from Exchange 2003to 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 messagesize limits are addressed. In the next part of this article series, we’ll continue our look at the

configuration of the Exchange 2007 environment.



Part6

Introduction

If you have been following this article series you will know that we ended part five havingstarted 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 butmisspelled 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 theSend Again button on the DSN, correct the address and send the message on its way. Figure 21shows 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 than10MB, 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 headersare 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 Exchange2003 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 HubTransport servers as well as the Edge Transport server. The cmdlets that I used were:

Set-TransportServer –Identity {server name} –InternalDsnMaxMessageAttachSize 0Set-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’ intheir 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 Pickupfolder. 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 berepeating 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 toset 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.

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/exchange-pickup-folder.html

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/exchange-pickup-folder.html



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 transportdumpster 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 HubTransport server in the same Active Directory site as the CCR environment to re-deliver emailmessages. 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 transportdumpster 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 specificHub 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 defaultvalue 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 ConfigurationTo 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 InformationStore 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 thefailed 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 transactionlogs.

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 highavailability 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 Configurationarea 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 wayto 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.



Part7

Introduction

In part six of this article series we looked at various items that I needed to configure within theExchange 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 haschanged 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 HubTransport 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, theself-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 methodrather 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 certificaterequires 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 theserver’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 accepteddomains 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 differentto 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 typethe same address into their browsers when working on the internal network. If using NLB, youcould 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 –SubjectNamecn=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 styleof 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 aswhen 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. dis 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. Tocreate 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 Figure28.



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





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.



Part8

Introduction

We left part seven of this article series having created the certificates for the Client AccessServers. 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 doat 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 tasksindividually 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, Iwas 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 canuse 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 StandaloneSnap-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 youshould 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 thecertificate 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 toensure 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 andhubcas2.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 ClientAccess 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 theExchange 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 useautodiscover.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 Anywhererequires 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 containsthe 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 toensure 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 certificatescreated 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.

http://blog.msfirewall.org.uk/2008_07_01_archive.html

http://blog.msfirewall.org.uk/2008_07_01_archive.html



Part9

Introduction

This is the 9th and final part of this article series looking at a project to transition from Exchange2003 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 stateearlier 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 theconfiguration 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 thatis 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 anydata 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 functioningcorrectly, 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.





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 Iam outlining in this article, Outlook 2003 was widely in use although some users were usingOutlook 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 databasewithin 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, Iused 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 installedExchange 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’svery 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 controlwhen 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 newExchange 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 cannot perform an in-place upgrade of an Exchange 2003 server to Exchange 2007 so the onlyavailable 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 Databaseheld in a storage group called First Storage Group on a server called E2K7.

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/moving-mailboxes-exchange-2007-part1.html

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/moving-mailboxes-exchange-2007-part1.html



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 obviouslyneed 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 additionalsteps 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 2003to 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.

http://www.msexchange.org/articles_tutorials/exchange-server-2007/migration-deployment/removing-last-exchange-2003-server-exchange-2007-part1.html

http://www.msexchange.org/articles_tutorials/exchange-server-2007/migration-deployment/removing-last-exchange-2003-server-exchange-2007-part1.html

Documents

A Practical Look at Migrating From Exchange 2003 to Exchange 2007