If you would like to read the other parts in this article series please go to:
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 1)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 2)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 3)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 5)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 6)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 7)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 8)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 9)
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.
- 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
- Next I had to copy the contents of this XML file from EDGE1 to one of the Hub Transport servers.
- 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.
- 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
- 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.
- Finally, I forced the Edge synchronization process to run immediately by running the Start-EdgeSynchronization cmdlet and checking for a successful synchronization. You can see an example of this process in Figure 12.
Figure 12: Successful Edge Synchronization Process
Internet Email
The thing to remember is that the Edge Subscription process automatically creates the necessary Send connector that is required to send Internet email outside of your organization. However, this Send connector has an address space of *, meaning that it will be able to process messages destined for any Internet domain name. Fortunately it is also configured with a cost of 100 by default, which means that any existing SMTP Connector that is configured in Exchange 2003 will likely have a smaller cost and therefore will still be preferred as the connector to send Internet email. In other words, Internet email should still flow via the existing routes rather than via the new route configured on the Edge Transport server. You can see this address space and cost configuration in Figure 13 where the basic properties of the Send connector were obtained using the Exchange Management Shell.
Figure 13: Send Connector Default Address Space and Cost
Of course, there came a time when I needed to test that the Edge Transport server was capable of sending and receiving Internet email. Before I did this I had to ensure that the MessageLabs system was aware of this new server, of course. To test email connectivity, I raised the cost of the Exchange 2003 SMTP Connector and lowered the cost of the Exchange 2007 Send connector so that the Send connector was the preferred route. I also changed the protocol logging level to Verbose on the Send connector, an example of which can be seen in Figure 14. Don’t forget that configuration changes such as this were performed on the Hub Transport server and replicated to the Edge Transport server via the Edge Subscription process.
Figure 14: Send Connector Protocol Logging
Doing this allowed me to examine the contents of the Send connector protocol logs on both the Hub Transport and Edge Transport servers to confirm that these servers were indeed processing the messages rather than the legacy Exchange 2003 servers. By default these log files can be found in the two subfolders located in the \Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog folder, an example of which you can see in Figure 15.
Figure 15: SMTP Protocol Log
Summary
That concludes part four of this article, which now sees a fully installed Exchange 2007 infrastructure coexisting with Exchange 2003. With regards to the Internet email connectivity, you could, of course, leave this until after you have migrated everyone to Exchange 2007; it’s your choice. In the next part we’ll start to look at the configuration of the Exchange 2007 environment prior to migration of mailboxes.
If you would like to read the other parts in this article series please go to:
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 1)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 2)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 3)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 5)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 6)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 7)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 8)
- A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 9)
