A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 9)

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






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.




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


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



About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top