A Practical Look At Migrating From Exchange 2003 To Exchange 2007

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

Part2

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

Hub Transport and Client Access Server Installation It was now time to install the first combined Client Access Server and Hub Transport server. Since these servers were being installed manually the Graphical User Interface (GUI) version of setup was invoked and the option to install a Custom Exchange Server Installation chosen. This was preferred over the Typical Exchange Server 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).

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

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

Figure 6: Configuring the Private Network

Next it was important to ensure that the networks were in the correct order within Cluster Administrator. To do this I right-clicked the cluster name, CLUSTER1, right at the top of the hierarchy in Cluster Administrator and 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.

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

Edge Server Installation The last server role to deploy was the Edge Transport server that was to replace an existing server running MailSweeper software. The MailSweeper server was configured to send and receive Internet email through the MessageLabs service, so this configuration had to remain. This actually made the configuration somewhat easier to manage, as this meant I did not have to alter things such as the company Mail Exchanger (MX) records. The server designated as the new Edge Transport server was prepared with the same applications as per the other server roles deployed, such as the .NET Framework, Powershell and so on. Also, this server’s DNS suffix was changed from the default option such that the server had a complete Fully Qualified Domain Name (FQDN). Admittedly this is one area that I can often forget when installing the Edge Transport server role but it’s important that I completed this task otherwise the setup process would have not been able to continue. To alter the DNS suffix, I brought up the properties of the computer object and went to the Computer Name tab. From there I selected the Change button which brought up 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.

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

Part6 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 GetMailboxServer 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.

Part7 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 selfsigned 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. 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. 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.

Part8 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 ImportExchangeCertificate 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.

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