If you simply want to do an in-place upgrade of Exchange 2000 to Exchange 2003 using the same server, you’ve got

it made
– Microsoft has explained the process of upgrading and made it pretty simple. Even if you’re still using Exchange v5.5,
Microsoft has you covered with a wealth of documentation to peruse. But what if you’re an Exchange 2000 organization that
wants to bring in a new Exchange 2003 system alongside your existing machine, move all your content over to it, and
decommission the original box?  Then you’re left scratching your head. At the time of this writing, there is no guide I’ve been
able to find that explains the process with any detail.

This document will explain the process, combining information from numerous sources as well as my own experience. It’s
very easy to bring Exchange Server 2003 into your Exchange 2000 organization, with minimal disruption to your existing
server or your users. This document assumes you have an Exchange 2000 organization running in native mode.

Henceforth, the Exchange 2000 system will be referred to as the “old” server, and the Exchange 2003 system will be
referred to as the “new” server.

I. Prepare your Network for Windows Server 2003

Regardless of how you intend to get to Exchange 2003, there are some basic steps that must be done.

1. Begin by reviewing Microsoft’s 314649 – “Windows Server 2003 adprep /forestprep Command Causes Mangled
Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers” This article explains that if you have
Exchange 2000 installed in your organization, and you proceed with installing your first Windows Server 2003
system (and its accompanying schema modifications), you may end up with some mangled attributes in
AD. Preventing this from happening is simple enough: a script called Inetorgpersonfix.ldf will do the trick.

2. Run adprep /forestprep from Windows Server 2003 CD on your Windows 2000 server that holds the Schema
master FSMO role. (Of course you’ll need to be a member of Schema Admins).  Be sure to replicate the
changes throughout the forest before proceeding.

3. Run adprep /domainprep from Windows Server 2003 CD on your Windows 2000 server. I ran it on the system
holding the PDC Emulator FSMO role.

4. Before bringing a new Windows Server 2003 system online, it’s a good idea to review your third-party server
utilities and upgrade them to the latest versions to ensure compatibility. In my installation, this included the
latest versions of BackupExec, Symantec Antivirus Corp. Edition, and Diskeeper.

5. Run setup /forestprep from the Exchange Server 2003 CD on the Windows 2000 server that holds the
Schema master FSMO role.  Replicate the changes throughout the forest.

6. Run setup /domainprep from the Exchange Server 2003 CD on a Windows 2000 server. Again, I ran it on the
system holding the PDC Emulator role.

II. Install Windows Server 2003

1. Install Windows Server 2003 on the new server, join it to the domain, then apply all hotfixes to the server to
bring it up to date.

2. In AD, move the server object to the desired OU.

3. If you’re paranoid like me, you may be tempted to install antivirus (AV) software on your new server at the
earliest opportunity. Hold off on that for now.

4. Review Microsoft’s 815372 – “How to optimize memory usage in Exchange Server 2003” which explains a
number of settings required for Exchange Server 2003. Specifically, you may need to add
the /3GB and/userva=3030 switches to boot.ini, or you will have event 9665 in the event log.  I also had to
change theHeapDeCommitFreeBlockThreshold value in the registry at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ to 0x00040000 as directed in
the article.
 5. Review Microsoft’s 831464 – “FIX: IIS 6.0 compression corruption causes access violations”. I obtained the fix
from Microsoft, and you should do the same, as it fixes some nasties that may interfere with OWA.

III. Install Exchange Server 2003

1. If you have installed any AV software on the new server, stop all AV-related services now, or you may
experience a failed Exchange installation as I did.

2. Download the latest copy of the Exchange Server 2003 Deployment Tools, version 06.05.7226 as of this
writing.

3. To begin the Exchange Server 2003 install on your new server, run Exdeploy.hta after extracting the tools.

4. Choose “Deploy the First Exchange 2003 Server”

5. You’ll want to choose the item for your current environment, which in the context of this article is “You are
running Exchange 2000 in native mode and you want to upgrade a server or install the first new Exchange 2003
server.” Choose “Upgrade from Exchange 2000 Native Mode”.

6. Run through the entire checklist and perform all the steps and tests. When you get to Step 9 in Exdeploy, you’ll
need to specify the path to the Exchange Server 2003 CD since you’re running Exdeploy from a location other
than the CD.

7. Install all the Exchange components unless you have a compelling need to do otherwise.

8. When the install is completed, install Exchange Server 2003 Service Pack 1.

9. When SP1 is completed, run the Exchange System Manager from the Windows Server 2003 system, and you
will see your new server listed in the Exchange organization, as well as your old server.

10. The POP3 and IMAP4 services aren’t set to start automatically, so configure them for Automatic startup if
desired.

11. If you want to install or enable antivirus software, it’s now safe to do so.

IV. Get Familiar with Exchange Server 2003

At this point, you now have an Exchange 2003 system running in your existing Exchange organization.  Microsoft has done
a good job of allowing the two versions to coexist.

Before proceeding with your migration, there are a number of important tasks to consider at this stage. For openers,
communicate with your users about the migration if you haven’t already, brief them on the new OWA interface, and by all
means ask them to go through their mailboxes and delete old, unneeded items. You’ll appreciate this later!

This is a good opportunity to spend some time reviewing your new Exchange server. Even if you spent time learning the
new product in a lab environment (as you should have), exploring the system now before proceeding makes sense. Check
out the new ESM, move a test mailbox to the new server, and try OWA. Go through your old server and take note of any
settings you want to configure on the new system such as size limits on SMTP connectors or incoming/outgoing messages,
etc. You’ll find that Exchange Server 2003 is configured to block mail relaying by default.

This is a good time to uninstall the Exchange 2000 version of the ESM remote management tools (using the Exchange 2000
Server CD, run Setup, choose Remove) on any management workstations and install the new Exchange 2003 ESM, which
can be used to manage both versions of Exchange server.

As you test message routing, you will find that any email coming into your organization from the outside will be automatically
routed to the appropriate Exchange server where the mailbox resides. My test mailbox on the new server could send and
receive mail, no problem. I could also access the mailbox with Outlook or OWA from within the organization, no
problem. However, I was unable to access mailboxes on the new server from outside the organization.
In my configuration, an ISA Server 2000 system acts as the firewall, where web and server publishing rules exist to redirect
incoming traffic to the old mail server. There was no simple way I could find to allow simultaneous access to both the old and
the new servers. All incoming mail-related traffic was directed to the old server. This limitation affected the rest of the
migration as you will see.

Note:
There is a way to have multiple Exchange servers, both 2000 and 2003, behind a firewall, whereby mail is automatically
directed to the appropriate server. This scenario involves installing Exchange Server 2003 on a server and configuring it as
a “front end” server, which allows it to act as a proxy. Unfortunately, the front end server cannot hold any mailboxes on its
own, so this isn’t an option in the migration scenario in this article.

Note: 
For a front end server to make any sense, a minimum of three servers would be needed: the front end server itself, and at
least two Exchange servers, to which the front end server would route messages, based on the mailboxes homed on
each. In our migration scenario, one could have a front end server routing mail to the old Exchange 2000 server and the new
Exchange 2003 server. As mailboxes are moved from the old to the new server, the front end server would route messages
to the correct place. This is a nice option for those with the hardware and the desire to do a gradual transition.

V. Configure Exchange Server 2003 to Host Public folders and Other Roles

As you begin moving folders and roles to the new server, one thing I learned the hard way is that you should use the ESM
running on the new server. I used the ESM on a Windows XP remote management workstation, and found that things
reported on the workstations’s ESM weren’t always the same as the Exchange server’s ESM.

1. Review Microsoft’s 307917 – “XADM: How to Remove the First Exchange 2000 Server Computer from the
Site”. This document contains most of what is needed to finish this migration, and explains in detail how to
setup replication of Public folders.

2. Using the instructions in 307917 as a guide, setup replication for all public folders that were created by your
organization on your old server. Do not setup replication for any folders you didn’t create, as several of these
will not be brought over to the new server. When the folders you replicated are in sync, remove the old server
from the replication tab. These folders now exist solely on the new server. They are accessible to those within
your WAN, but are inaccessible outside your firewall.

3. You should find that the Public folders called default and ExchangeV1 are already replicated to the new
server. Using Step 2 and 3 in 307917, setup replication to the new server for the folders Offline Address
 Book, OAB Version 2, and Schedule+ Free Busy Information. If you have a folder called Internet
Newsgroups, you should replicate that also. This folder is created by the Exchange system, though your
organization may not use it.

4. If you check the Properties, Replication tab on your administtrative group’s Folders node, you will see the
replication interval for the public folders. Unless you specifically changed the interval on any individual public
folders, they should follow this schedule. “Always run” means replication will run every 15 minutes. There is no
“replicate now” option.

5. Using Step 4 & 5 in 307917, rehome RUS and designate the new server as the routing group master.

5. Step 6 and 7 in 307917 didn’t apply in my configuration; proceed with those as needed.

5. Using Microsoft’s 265293 – “How to Configure the SMTP Connector in Exchange”, add the new server to the
SMTP connector, remove the old server, then cycle the MS Exchange Routing Engine service and the SMTP
service for these changes to take effect. Send a test message to verify the new server is sending the mail now.

5. There are a number of public folders on the Exchange 2000 server that do not need to be replicated and moved
to the new server, including several that are part of the Exchange 2000 version of OWA. On my system these
included:

1. Controls

2. Event Config_<old server name>

 3. Events Root

4. Exchweb

5. Img

6. Microsoft

7. Offline Address Book – First Administrative Group

8. Schema-root

9. Views

Just leave these folders on the old server.

At this point, with the exception that your public folders are no longer accessible outside your firewall, there shouldn’t be any
noticable difference to your users. You can accomplish all of the above during normal working hours without much
fuss. However, the next step isn’t as transparent.

VI. Move the Mailboxes to Exchange Server 2003

This is the moment we’ve all been waiting for, and it’s pretty straightforward. In order for this process to go as smoothly as
possible, you should make sure that no users inside your organization are accessing the email system. You should also
block all external access to your mail servers.

1. You can read a detailed description of moving mailboxes, see Henrik Walther’s “Moving Mailboxes with the
Exchange 2003 Move Mailbox Wizard”  article for specifics.

2. Prevent outside access to your mail servers. In my case, this involved disabling the web and server publishing
rules for IMAP4, POP3, and SMTP in my ISA Server 2000 system.

3. Make sure no internal users are accessing the mail server.

4. Turn off AV on both the old and the new server. Moving mailboxes is a time-consuming, resource-intensive
process. AV scanning will slow this process down, and in some cases can cause problems when large scale
data is being moved.

5. The Move Mailbox Wizard will allow you to select many mailboxes at a time, but it will only process four at a
time. I chose the “Create a failure report” option, which won’t move the mailbox if there are errors. I moved 75
mailboxes, 1.7GB of data, in 70 minutes, without a single error.

6. The key determining factor in the speed of the mailbox move process isn’t so much size as it is the number of
items in a mailbox. If your users deleted a lot of items per your request, the process will go a lot quicker now.

7. If you want to test your new system before moving all the mailboxes, you can move a handful of them, then turn
on outside access (I would turn on AV as well). Keep in mind, you’ll need to configure your firewall to point to
the new mail server. You should be able to access the new mailboxes with OWA and POP3 mail applications
like Outlook. You can also test access to Public folders in OWA if desired. Be sure to disable external access
and AV before proceeding.

8. Move all the mailboxes, except SystemMailbox, System Attendant, and SMTP-ServerName, as these should

already exist on the new server.

9. When the process is finished, configure your firewall to point to the new mail server, turn on AV, and enable
external access. You are now running an Exchange Server 2003 mail system.

VII. Final Cleanup

 1. Go through the public folders on the new server and remove the old server from the replication tab for any
public folders that are still replicating to it. On my system this included default and ExchangeV1.

2. Have your clients logon to their email clients. Outlook will attempt to connect to the old mail server, but as long
as the Exchange services are still running on it, it will automatically redirect Outlook to the new server.

3. Stop all the Exchange services on the old server. Stop IISAdmin, which should stop FTP, NNTP, SMTP, and
WWW.

4. Your old server will still appear in the Exchange organization in the ESM, but that’s OK for now.  You may also
see an entry in the Queues node on the new server, destined for the old server. You can ignore this also.

5. Allow your new server for run for a few days if desired, keeping the old system in its present state for the time
being. You may even want to turn it off.

6. When you’re satisfied that the migration is a success and the old server is no longer needed, insert the
Exchange 2000 Server CD into the old server, run setup, and remove/uninstall Exchange 2000. Make sure the
server is still connected to the network when you do this, as this process will remove the old server from the
ESM.

Congratulations! Because you began with an Exchange 2000 organization in native mode, your Exchange Server 2003
system is in native mode. Your migration is finished.

So, if you run into any problems, you just should make sure that certain things are prepared and you can revert to
Exchange Server 2003. This article will discuss the various preparations you should make during the various stages
of the process and how to fix any problems that might occur.

General Preparation Tasks before the Transition

Before we start the Transition, you should review the event logs on all your Domain Controllers to make sure that no
errors or warnings are in there. If you find any, you should correct them first before you go on. Additionally, you
should make sure all Windows Updates are installed. DCDIAG.EXE from Windows Support Tools may help you
during this task.
 Afterwards you should back up the system state of all your Domain Controllers to make sure you are able to restore
Active Directory in the event of a failure during the setup process.

Domain and Forest Preparation for Exchange Server 2007

In order to prepare the Active Directory Environment you will have to import some new schema entries. This means
you will have to log on locally to your Domain Controller on which the schema role resides. Since this means a re-
indexing of your Active Directory Database, I recommend doing this during non-work hours and if possible when
running Active Directory Native Server 2003 forest mode. This would mean that we only have delta replications and
no full replications like running on Windows Server 2000 mode. So you will have less replication traffic on your WAN
links.

If you have trouble during the schema enhancement for Exchange Server 2007, your only chance to go back to
Exchange Server 2003 is to completely restore System State on your Schema Master Domain Controller and
hopefully it would not have replicated some entries during this phase, because this would mean restoring System
State on all your Domain Controllers in your network environment. But don’t be angry, a restore of Active Directory is
quite easy if you follow the following procedures:

 Start your Domain Controller in Active Directory Restore Mode.

 Log on with your Active Directory Restore Mode Logon Credentials.
 Restore System State from backup.
 Configure Authoritative Restore using NTDSUTIL.EXE.
 Restart your Domain Controller.
 Follow the steps above for all your Domain Controllers.

Troubleshooting the Implementation of Hub Transport Servers

The first Exchange Server 2007 box you might implement is the one on which the Hub Transport Role will reside.
This box is quite easy to implement, you should move forward after having a good system state backup ready in the
event of a failure. If something unplanned happens during the move of the general configuration settings to Exchange
Server 2007, your disaster recovery plan is to restore Active Directory from backup.

Troubleshooting the Implementation of Mailbox Servers

After having set up the mailbox or database role servers, which could be a single or multiple server deployment,
perhaps in addition with one of the high availability features of Exchange Server 2007 (Local Continuous Replication,
Standby Continuous Replication, Cluster Continuous Replication, or Single Copy Cluster), we have to move the
mailboxes from the old environment to the new one. This mailbox move is quite easy, too.

In general there should be no problems unless the user whose mailbox is currently being migrated is logged off. In
general no problems should occur on the client systems, too: they should discover that their mailbox has moved to
another server while they were offline. To insure this Exchange Server 2007 has a new functionality for automatic
creation of MAPI profiles, if you have Outlook 2007 deployed. So make sure to have Outlook 2007 deployed before
starting with the deployment of Exchange Server 2007 mailbox servers.

Troubleshooting the Implementation of Client Access Servers

The Client Access Server role provides functionalities like Outlook Web Access, Outlook Mobile Access (Exchange
Push), etc. When migrating from other Exchange Server releases this is the first box you should implement (in
general this will be your front end server machine), since this will allow Outlook Web Access to work on mailboxes
that reside on older versions of Exchange and on Exchange Server 2007.

If anything failed during the implementation of this server, you just have to reinstall this machine and try again.

Troubleshooting the Implementation of Unified Messaging Servers

When implementing the Unified Messaging role, your disaster recovery plan during your deployment of Exchange
Server 2007 is quite easy, because this is a new feature set that was not part of earlier releases of the product. In the
event of an unexpected error, you just have to take a second chance and reinstall the server again.

Troubleshooting the Implementation of Edge Servers

The Exchange Server 2007 Edge Server Role is a solution that is placed in your DMZ to relay your emails into your
Exchange Organization or outside it, so it is responsible for incoming and outgoing emails and is completely
independent from your Active Directory, because it works with ADAM (Active Directory in Application Mode). If you
run into problems during its implementation, you will have to start over again. If it is already running, you can run the
ExportEdgeConfig.ps1 Powershell script to save the configuration in a XML file and use this for import purposes on
the new server.

Conclusion

As you have seen in the sections above the transition from Exchange Server 2003 to Exchange Server 2007 is not a
big risk if you plan the project and each project phase should include a plan to revert if something unplanned happens
and there is no way to go on. These risk management procedures will insure that you minimize unavailability times in
case of an error and that your email environment will work properly and be available most of the time.

Exchange Server 2007 with Service Pack 1 is a very stable and reliable solution. In my opinion, it is the best release
Microsoft has come out with yet. So I think there is no reason for you to wait to migrate. Just create a project plan and
your email server environment will survive the transition to Exchange Server 2007.

If you still have any questions, please do not hesitate to contact me.
Microsoft will release Exchange Server 2010 later this year, but there are still plenty of enterprises on
Exchange 2000 and 2003 that are now migrating to Exchange 2007. Mike Crowley, an enterprise and
messaging administrator with Planet Technologies, Inc., a Germantown, Md.-based integrator, has some
advice for those moving to 64-bit Exchange Server 2007.

What is the most common problem IT administrators run into when upgrading from Exchange
Server 2003 to Exchange Server 2007?

Mike Crowley: The number one gotcha is the fact you cannot "upgrade" Exchange 2003. You must
migrate services and mailbox content to another server. This is primarily because of the change in CPU
requirements. Exchange 2003 can only be on x86 systems and Exchange 2007 can only be x64 systems,
as well as Exchange Server 2010. For small businesses that plan to reuse the same hardware (assuming
it's x64 capable), this means they have to move everything out and then move it all back. For large bu... 

Introduction to Microsoft Exchange Server 2003 Migration Strategy

The golden rule for a successful migration is - set a clear goal.  For example,
'Our goal is to install Exchange 2003 and migrate all mailboxes from
Exchange 5.5 in 6 months.

Of all Microsoft upgrades, Exchange is by far the most complex.  The

reasons that make an Exchange 2003 migration so difficult are, the sheer
number of different components, coupled with need to keep the email
flowing during the migration.  It may surprise you when I say the key role
for a successful Exchange 2003 migration is not a technical expert but
experienced project manager.

Topics for Microsoft Exchange 2003 Migration

 Migration to Exchange Server 2007
  Role of Active Directory in Exchange Migration
 Importance of naming
 Phase one - Move user accounts from NT 4.0 and Dir.edb to Active
Directory
 Exchange Migration Tactics - ADC or ADMT
 Phase two - Move the accounts from Exchange 5.5 to Exchange
2003
 Tactics - In place upgrade or migrate mailboxes
 ExDeploy - From the Exchange Server CD
 Summary Exchange Migration

  ♠

Role of Active Directory in Exchange Migration

An important point to always keep in mind is that Exchange 2003 absolutely
relies on Active Directory.  This means that Exchange Server gets
information about users either from Windows Server 2003 (best), or from
Windows 2000.  What Active Directory provides is integrated user
authentication and mailbox security. 

Another way of looking at Active Directory is as a replacement for Exchange

5.5's Dir.edb.  As well as integrating with logon security, Active Directory is
designed around the object / property / attribute model.  In practical terms,
this means that each user object has Exchange properties such as mailbox. 
You probably realise that Active Directory holds user's password, logon id
and group membership; also remember that when you install Exchange
2003, email address and mailbox are also properties of the user and not
stored separately as they were in Exchange 5.5.

In addition to creating users with their mailboxes, Active Directory is also

your vehicle for building distribution groups and contacts.  It is also Active
Directory that provides the search mechanism so that users can locate
recipients in the address book.

When you install Exchange Server 2003 you need to be aware of the
schema.  We have seen that Active Directory holds definitions for the
properties of the user object, for example, password, group membership and
department.  Now when you install Exchange the user's schema is extended
to hold properties like mailbox, email address and mail server.  Exchange
2003 can prepare Active Directory through the commands setup /forestprep
and setup /domainprep.  These setup switches add over 100 Exchange
attributes to the schema. (See more on Exchange 2003 Installation)
 Guy Recommends: The SolarWinds Exchange Monitor
Here is a free tool to monitor your Exchange Server.  Download and
install the utility, then inspect your mail queues, monitor the Exchange
server's memory, confirm there is enough disk space and check the CPU
utilization. This is the real deal - there is no catch.  SolarWinds provides this
fully-functioning product for free, as part of their commitment to supporting
the network management community.

Free Download of SolarWinds Exchange Monitor

Importance of naming
The first point on your migration checklist should be naming.  What will be
the name of your Microsoft Exchange 2003 organization?  Is this the same
name as the existing Exchange 5.5, or are you restructuring and creating a
new organization?  How does the Window Server 2003 domain name
compare with the NT 4.0 domain name?  Perhaps the most difficult naming
system to master is DNS, nevertheless DNS is essential for locating Active
Directory logon services, sites, and Global Catalog servers.  The extra DNS
factor with exchange is creating MX records so that SMTP can route mail to
the correct server.

 Phase one - Move user accounts from NT 4.0 and

Dir.edb to Active Directory
The Exchange 2003 migration project will
become easier when you divide the project
into two distinct phases.  The first phase is to
get the directory information from Exchange
5.5 into Active Directory - preferably Windows
Server 2003.  Only when you have migrated
that user account information should you consider moving the actual
mailboxes with email to your new Exchange 2003 server.

Exchange Migration Tactics - ADC or ADMT

The ADC (Active Directory Connector) is a service that allows you to create
'agreements'.  These agreements will dictate how the user information is
transferred to Active Directory.  Alternatively, use the ADMT (Active
Directory Migration Tool) wizard to copy user information and 'paste' it into
Windows Server 2003 Active Directory.

The benefit of ADC is that you also migrate public folder information. 
However, ADMT gives better rollback because users will still be able to logon
to NT 4.0.

Guy Recommends:  A Free Trial of the Orion Network Configuration Monitor (NCM) v6

Config management of routers, switches and firewalls is fun with NCM

(Network Configuration Manager.  Furthermore, it can help to achieve
your compliance policy, for example, pinpoint devices not backed up and
discover access infringements or even weak passwords.  This Solarwinds
NCM suite can not only detect violations, but also upload scripts to correct
the problem.

Most computer problems arise from configuration changes.  Thus it makes

sense to get a proper monitoring system so that you can double-check that
that all the settings confirm to your security policy.

Download your free trial of Orion's Network Configuration Monitor.

Phase two - Move the accounts from Exchange 5.5 to Exchange 2003.
Now that the mailbox owner and security information has been added to
Active Directory, you can turn your attention to moving the email stores
from Exchange 5.5 to Exchange 2003.  Unlike an Exchange 2000 migration,
when you upgrade Exchange 5.5 you have to use the move mailbox
strategy, an in-place upgrade is not an option.

ExDeploy - from the Exchange 2003 Server CD

This wonderful wizard leads you through the
nine steps needed for a  successful upgrade
from Exchange 5.5 to Exchange 2003.  If you
have not created the Active Directory Connection agreements (ADC), the
wizard will even do that for you.

It is also possible to use the same wizard to guide you through an upgrade
from Exchange 2000 to Exchange 2003. (See Diagram)

Note:  ExDeploy is new in Exchange 2003 (not available for Exchange 2000).
Check out the Exchange 2003 Server CD for ExDeploy

Guy Recommends: SolarWinds Engineer's Toolset v10

The Engineer's Toolset v10 provides a comprehensive console of utilities for
troubleshooting computer problems.  Guy says it helps me monitor what's
occurring on the network, and the tools teach me more about how the
system itself operates.

There are so many good gadgets, it's like having free rein of a sweetshop.
Thankfully the utilities are displayed logically: monitoring, discovery,
diagnostic, and Cisco tools.  Download your copy of the Engineer's
Toolset v 10

Summary of Exchange Migration Strategies

Break down your Exchange migration into stages.  Stage one, transfer all
the directory services information from NT 4.0 to Active Directory.  Stage
two, move the mailbox data from Dir.edb in Exchange 5.5, to Active
Directory.  Microsoft supply a wonderful tool called ExDeploy.  Give this
wizard a chance, you may be pleasantly surprised how ExDeploy guides you
through each stage.

My final advice is pay special attention to the names of your: Exchange

organization, dns, and Active Directory domain.

What makes describing your transition to Exchange Server 2007 difficult

is the sheer number of upgrade paths.  Let me start by clarifying the
terminology:
Transition - Is the latest buzzword to describe moving mailboxes from
Exchange 2000 /3, to a brand new Exchange 2007 server in the same
Exchange Organization.

Migration - Microsoft have decided to apply a stricter logic to the word

'Migration'.  It describes the bigger step of moving mailboxes from
another email system to Exchange Server 2007.  For example, you
could migrate users from Lotus Notes, a UNIX email system, or even
from an Exchange Organization in a different company, to a brand new
Organization running Exchange Server 2007.

Topics for Transition to Exchange Server 2007

 General Advice - What to Expect from Microsoft Exchange Server
2007  
 Exchange 2007 Transition Checklist
 Planning Advice - Preparing to Migrate to Exchange 2007 Server
 Detailed Steps for Your Transition to Exchange 2007

  ♠
General Advice - What to Expect from Microsoft Exchange Server 2007
Is Exchange Server 2007 really easier than Exchange 2003?

Can it be true that Exchange Server 2007 is easier than Exchange

2003?  Guy says it depends what you mean by easier!  Exchange 2007
is more straightforward to get started, but it has more individual
components to consider than Exchange 2003.  Yes there are new exiting
features, but each item needs time to evaluate.  It's true that the
wizards are cleverer, and they guide you surely through the necessary
configuration, but there are more of them to get to know. 

The addition of Exchange 2007 to the server family inevitably results in

more compatibility squabbles with Exchange 2003, Exchange 2000 and
Exchange 5.5.  I admit that the relationship between Exchange 2007
and Exchange 5.5 is tenuous because you have decommission or
upgrade the Exchange 5.5 before you can install Server 2007.

A benefit of transitioning to Exchange 2007 is that each component is

bigger, faster and clever than its counterpart in Exchange 2003.  Yet
this does not mean the whole Exchange Organization is easier to
manage because more components means greater complexity.  Another
factor you soon discover is that a favorite Exchange 2000 /3 feature has
been decommissioned, renaming or de-emphasising.  Such changes
cannot make Exchange 2007 easier than Exchange 2003, but
fortunately each change makes sense and you soon get used to the new
names and features.
In summary, each individual Exchange 2007 feature is easier to
configure, but you need more planning to decide which components suit
your organization.  One constant theme is that Exchange Server 2007
looks simple but efficient on the surface, but when you investigate any
given component, it seems both powerful and complex.

Guy Recommends: SolarWinds Engineer's Toolset v10

The Engineer's Toolset v10 provides a comprehensive console of utilities
for troubleshooting computer problems.  Guy says it helps me monitor
what's occurring on the network, and the tools teach me more about
how the system itself operates.

There are so many good gadgets, it's like having free rein of a
sweetshop. Thankfully the utilities are displayed logically: monitoring,
discovery, diagnostic, and Cisco tools. Download your copy of the
Engineer's Toolset v 10

My Mission
My mission is to outline general transition strategies, and then highlight
trusty tactics that work which ever path you take to reach Exchange
Server 2007.  Good news, Microsoft have always been good at
migrations, after all it's in their best interests to make the latest and
most expensive systems easily accessible.  Moreover, they want to pick
up business from Lotus Notes, UNIX, mainframes as well as Microsoft's
older systems like Exchange 5.5.  As for practical help, what will make
your transition easy is to seek guidance from Microsoft's installation
wizards.

The best migration advice that I can give you is begin by identifying
your correct track.  If you are upgrading (transitioning) from Exchange
2000 to Exchange Server 2007, then don't try the Exchange 2003
transition methods; instead, seek instructions dedicated to replacing
Exchange 2000.

The task of planning a Microsoft Exchange organization is divided into

two distinct subtasks: designing the overall Exchange organization,
followed by placing individual Exchange servers in sites to optimize
message transfer. This approach results in a logical placement of
resources while focusing on literally delivering the users' email.
Beginning at the organizational level.  Establish organization-wide
naming conventions, determine the number of routing groups you need,
their fix their boundaries and provide multiple links.  At the server level,
you should determine the function(s) each server performs, and then
plan the server configuration to accommodate those roles.

Exchange 2007 Transition Checklist

 Before you buy Exchange Server 2007 decide which combination you
need: RTM or SP1. Standard or Enterprise. 64-bit (32-bit is only for
testing).
 Upon which operating system will you install Exchange Server 2007? 
(Windows Server 2003, or Server 2008)
 Which version of Active Directory will you use? (Windows Server 2003 or
2008)
 Where is the DNS server which resolves your Exchange 2007 servers and
services?
 Check the Function Level, is it Windows 2000 Native or later?
 What about the Forest Function Level?  Is it already Window Server 2003?
 Check the Exchange Organization name, and also the default email
address.
 Raise the Exchange Operation mode to: Native Mode (no pre-Exchange
2000 servers).
 For multiple sites check the Global Catalog requirements.
 Will there be an extended period with heterogeneous Exchange
Servers?  How long will it last, what will be the replacement sequence for
Exchange 2000, Exchange 2003.
 A good question is: 'How can we use the Exchange 2007 transition to
become more efficient?'  For example, take the opportunity to consolidate
with fewer Exchange 2007 servers than Exchange 2000/3 servers.
 Supplementary question: 'What other email improvements can we
implement at the same time?'  For example, embrace Unified Messaging,
take more advantage of OWA.  Also investigating Journaling so that we
conform to legal requirements to keep company email.
 Plan for co-existence with different versions of Exchange Server. 
Remember that there is no in-place upgrade even from Exchange 2003,
thus there will be phase of co-existence where communication between all
Exchange servers is vital.
  Repercussions when you decommission the Exchange 2000 / 3 servers. 
For example, move the Offline Address Book and the Recipient Update
Service to Exchange Server 2007.  Check, and if necessary, remove
legacy routing groups and also legacy connectors.
 (Do any of the later checklist items affect your original choice of Exchange
Server 2007 DVD?)

Exchange Server 2007 is a complex topic, do you

need practical hands on training?  As an MCT trainer,
I can thoroughly recommend TrainSignal.  In
particular, I like the way that TrainSignal cover all
learning methods, instructor lead, video and of
course text material.  You can either take one module, for example
Exchange 2007 or go for a combination of modules.  Learn more about
Microsoft Exchange Server 2007 here

Easy Transition Stuff

64-bit hardware is an absolute requirement for Exchange Server 2007. 
Maybe this constraint is an opportunity to get new kit!

Exchange 2007 introduces the server 'Role' concept; Microsoft provide

top-notch wizards to help you add these 5 roles: Mailbox, CAS (Client
Access Server), Bridgehead, Unified Messaging or Gateway.

Decide on your tactics.  Would it be best to have few servers with

multiple roles, or alternatively a different server for almost every role. 

Talking of tactics, embrace the simple but effective concept of building a

new Exchange Server 2007 from scratch.  Then calling for the Move
Mailbox wizard to swing all the users mailboxes from the old server(s) to
the new Exchange 2007 server with the Mailbox role.

Forget about an in-place upgrade from Exchange 2003 or even 2000;

thankfully, this transition method is not allowed for Exchange Server
2007.  Do begin with a clean install of the underlying operating system
(Windows Server 2008 [best], or Windows Server 2003).

Forget about Exchange 5.5 servers.  Because of changes to the Function

Level, pre-2000 Exchange servers are not allowed to co-exists with
Exchange Server 2007.
Medium Migration Difficulty
We can divide the task of planning a Microsoft Exchange organization
into two distinct subtasks:  firstly, designing the overall Exchange
organization. Secondly, placing individual Exchange servers in sites to
optimize the messaging system. This approach provides you with a
logical placement of resources developed with users' needs in mind.

Check, and if necessary, adjust the Domain and the Forest Function
Levels.  Also check that the existing Exchange's operation mode is
native.

Make sure DNS is working properly, and the Exchange 2007 servers are
registered along with any MX records.

Investigate PowerShell cmdlets.  Trust me, one day you will configure
most of your Exchange Server 2007 settings from the command line.  If
you believe me, little-by-little you will build a formidable repertoire of
PowerShell commands.

Monitor Your Network with the Real-time Traffic Analyzer

The main reason to monitor your network is to check at a glance which
of your servers are available.  If there is a network problem you want an
interface to show the scope of the problem immediately.

Even when all servers and routers are available, sooner or later you will
be curious to know who, or what, is hogging the precious network's
bandwidth.  A GUI showing the top 10 users makes interesting reading.

Another reason to monitor network traffic is to learn more about your

server's response times and the consumption of resources.  To take the
pain out of capturing frames and analysing the raw data, Guy
recommends that you download a copy of the SolarWinds free Real-
time NetFlow Analyzer.
Hardish Stuff
Write down a clear vision of what you want to achieve with your email
system.  Give the vision time to crystallize, parts may be fuzzy at first,
but gradually their focus sharpens.

Once you have a master plan, breakdown each task into items, and then
investigate each component thoroughly.  In Guy's opinion, nothing beats
a test network where you can get all the mistakes out of your system
without the prying eyes of the users, or your boss.

For example, once your Exchange client has been decided, or imposed,
check how that client accesses your Exchange 2007 Server.  OWA 2007,
Outlook 2003, Outlook 2007 all have slightly different requirements and
features.  Oh yes, start by adding the CAS (Client Access Server) role to
at least one of your Exchange 2007 servers.

Guy Recommends:  A Free Trial of the Orion Network Configuration Monitor (NCM) v6

Config management of routers, switches and firewalls is fun with NCM

(Network Configuration Manager.  Furthermore, it can help to
achieve your compliance policy, for example, pinpoint devices not
backed up and discover access infringements or even weak passwords. 
This Solarwinds NCM suite can not only detect violations, but also
upload scripts to correct the problem.

Most computer problems arise from configuration changes.  Thus it

makes sense to get a proper monitoring system so that you can double-
check that that all the settings confirm to your security policy.

Download your free trial of Orion's Network Configuration

Monitor.

What's in a Name?
In practical terms, when you migrate to Exchange 2007 keep your eye
on the Exchange Organization name.  This name is crucial and cannot be
changed easily.  Therefore during installation, watch carefully to see
which Organization Name the wizard is suggesting.
20% of Exchange techies are in for a surprise when the check these four
Exchange related names.  Now, these names don't have to match, but
you do need to know what they are.

 Exchange Organization Name - Maybe it's plain YourExOrganization, and

not YourExOrganization.com
 Email domain addresses, for example: admin@YourExOrganization.com.
 Active Directory Domain - Is it a root domain?  For example
YourDom.com, or is child domain Worcester.YourDom.com
 DNS Name - Fascinating to know if the DNS name is identical to the Active
Directory Domain name.

It does not matter if these names have completely different stems, what
does matter is that you configure the correct information, it is vital that
you and your server are on the same page. 

One more point, Exchange Server 2007 member servers don't take
kindly to being renamed.  Unlike other member servers, changing the
name on an Exchange server causes all matter of immediate and pent
up problems, thus make a naming plan and stick to your names.

Plan for Exchange Server Co-existence - understand the limitations

You can manage only Exchange 2007 servers with the Exchange 2007
Management Console, and Exchange 2003 servers.  The reciprocal is
also true, you cannot configure Exchange 2007 objects from Exchange
Server 2003.  In order to complete decommissioning, there is an
exception, it is possible to delete Exchange 2003 objects such as
connectors.

Exchange Server 2007, Exchange 2003 and Exchange 2000 servers can
all exist and function within your Exchange organization, however there
are restrictions.  When in doubt use the native console to manage
Exchange 2007 or Exchange 2003 objects.

Features Removed from Exchange Server 2007

 Network News Transfer Protocol (NNTP)
 Instant Messaging service
 Exchange Chat Service
 Exchange 2000 Conferencing Server
 Microsoft Mobile Information Server
 Key Management Service
 Novell GroupWise connector
 cc:Mail connector
 MS Mail connector
Planning Advice - Preparing to Migrate to Exchange 2007 Server
Shoot for the stars.  Start by asking for the moon.  Think of your ideal
outcome then work towards that vision.  In the case of an email system,
my suggestion would be to match Exchange 2007 with Windows Server
2008, and on the client side, Outlook 2007 or OWA 2007.  The further
you move away from these matched components, the more complex
your transition will be.  Common sense dictates that the more disparate
the system that you are managing, the more problems that you will
have both now and in the future. 

Beware of spending time and money fire-fighting old systems.  Think of

the advantages of spending that same time and money achieving your
vision of a modern client server email system.  Decisions are often made
on the basis of : 'How much is our time worth?'.  A better approach
would be - work smart.  Rather than spending time on work-arounds to
retain Exchange 5.5 servers in the branch offices, develop negotiating
skills to persuade the financial director to free the purse strings and
invest in a native Exchange 2007 system.

Making the transition to Exchange 2007 is easier than upgrading from

Exchange 5.5 to Exchange 2000.   Much of the initial work is sifting
through a long list of possible factors, to find the handful tasks that
apply to your situation.  What makes my advisory task so complex is
that everyone has a different list of tasks for their particular transition. 
My mission is to help you eliminate factors that don't apply to your
situation, while a focus on those elements that are vital for the success
of your Exchange 2007 upgrade.

How to transition to Exchange 2007 - Practical Tasks

Summary: Transition to Exchange Server 2007

Let us begin with vision of the best outcome. Then by spending time
deciding on the sequence of transition events, If you choose to
transition to the very latest client / server system, with luck and skill,
many niggling peripheral tasks may suddenly become redundant.

Guy cannot help wondering if the assertion 'System A is easier than

system B', is unhelpful marketing speak. It would be better to say that
system B will be better, and furthermore, the migration / transition /
upgrade will have its own personality.

See more Microsoft Exchange Server 2007 topics:

• Exchange 2007 Home   • SP1   • Migration   • Compatibility  
• ExBPA   • Free Syslog Analyser
 • Install   • Server Roles   • CAS Role   • Hub Transport  • SMTP
Connector   • NDRs  • Exchange CCR

• Mailbox Role   • Create Mailbox   • Mailbox Stores  

• Recipients   • OWA   • GAL   • Eseutil   • Edge

Please write in if you see errors of any kind.  Please report any factual
mistakes, grammatical errors or broken links, I will be happy to not only
to correct the fault, but also to give you credit.

Takeaway: Exchange 2007 represents a bigger change to Exchange

administrators than the move from Exchange 5.5 to Exchange 2003. You
just can't put a CD in the drive and click Setup. Here's what you'll need to
know to make the move from Exchange 2003 to Exchange 2007.

This article is also available as a TechRepublic download.

One of Microsoft's newest introductions for 2007 is Exchange Server 2007. If you currently have
Exchange Server 2003 running on your network, you might be in for some surprises when you
upgrade to the latest version. In this article, I will explain what's involved in making the move
from Exchange Server 2003 to Exchange Server 2007.

Plan on buying new hardware

If you're making the move to Exchange Server 2007, plan on purchasing new server hardware.
Exchange Server 2007 does not support in-place upgrades. You can't just insert an Exchange
2007 installation CD into an Exchange 2003 server and expect it to install. Instead, you will have
to install Exchange Server 2007 on a brand new server, and then migrate mailboxes and public
folders to it.

You can’t perform an in-place upgrade because Exchange Server 2007 will only run on a server
that has a 64-bit processor and a 64-bit operating system. Exchange Server 2003 will run on 64-
bit hardware, but only if it is running a 32-bit operating system. This difference in required
operating systems makes an in-place upgrade impossible.

In case you are wondering, Microsoft's decision to require a 64-bit operating system for
Exchange Server 2007 has to do with memory. Over the last few years, the average size of an
Exchange database has grown exponentially. In fact, Exchange Server 2003 standard edition
used to have a maximum database size of 16 GB; but Microsoft increased the size limit to 75
GB in one of the service packs because of the way that database sizes were growing.
This rapid database growth has been fueled by several factors. One factor is e-mail retention
legislation. Many companies are now required to keep e-mail messages that would previously
have been deleted. Another factor is the widespread availability of high-speed Internet
connections. Suddenly, it isn’t a big deal to send an e-mail message containing a 10 MB
attachment. Of course spam also contributes to Exchange Server database growth.

Whatever the reason, there’s no arguing that on average, Exchange databases have been
growing exponentially. The problem is that the larger an Exchange database, the more memory
required to keep the database performing well. 32-bit operating systems are limited to a
maximum address space size of 4 GB. The Windows operating system claims 2 GB of address
space, leaving 2 GB for user mode processes (in this case, Exchange Server).

Many large companies have been struggling with the 4-GB address space limit for some time.
You can use the /3GB switch in the Boot.ini file to allocate more memory to user mode
processes; but doing so decreases the number of available Page Table Entries, and that can
cause problems of its own. Making the move to a 64-bit environment makes perfect sense for
Exchange Server, because 64-bit operating systems are not subject to the 4-GB address space
limit.

Hardware requirements
 

Rolling migrations
As you ponder a migration to Exchange Server 2007, keep in mind that you may not have to
replace all of your server hardware. Most new servers include 64-bit processors that are
capable of running 32-bit code. If you have these types of servers running Exchange Server
2003, then you can perform a rolling migration.

Imagine you had three servers running Exchange Server 2003, and each of those servers met
the recommended hardware requirements for Exchange Server 2007. Rather than buying three
new servers, you could get away with buying one new server. You would install Exchange
Server 2007 onto the new server and then migrate the contents of one of your Exchange 2003
servers to it. When the migration is complete, you can reformat the Exchange 2003 server that
has been migrated. You would then install a 64-bit Windows Server operating system and
Exchange Server 2007 onto that server, and migrate the contents of your next Exchange 2003
server. When you finish migrating all three servers, you will be left with one remaining server
that you can use for whatever you want.

Earlier I mentioned that 64-bit operating systems have a much larger memory address space
than their 32-bit counterparts, and that this larger address space facilitates the creation of larger
Exchange databases. Exchange Server 2003 Enterprise Edition did not impose a database size
limit, but there was a practical limit to the size to which a database could grow that was based
on hardware constraints. These constraints have all but vanished from Exchange in Exchange
Server 2007, allowing you the freedom to create some truly massive databases.

Assuming that you have the disk infrastructure and backup hardware to support such a
database, then one option is to consolidate all of your Exchange 2003 servers onto one or two
Exchange 2007 servers. You will still have to purchase a new server, but consolidating all of
your Exchange 2003 servers could save you a small fortune in Windows and Exchange license
fees. Before you attempt a server consolidation, I would recommend that you use Microsoft’s
System Center Capacity Planner to test the impact that the planned consolidation would have
on performance.

Preparing for a migration

I cannot possibly do any justice to the topic of planning an Exchange Server 2007 deployment in
this article. I’ll cover most of that in a completely separate article on the subject. What I will tell
you is that before you install Exchange Server 2007, I recommend planning how the new server
will fit into your existing Exchange infrastructure. You also need to have a rollback strategy in
place in case something goes wrong during the deployment.

The biggest thing to keep in mind is that Exchange Server 2007 modifies the Active Directory
schema during installation. Therefore, I recommend making a full system backup of your
domain controllers prior to installing Exchange. Then you have something to fall back on if the
schema update should crash and corrupt your Active Directory.

Migrating mailboxes
Now that the preparation work is complete, it's time to begin migrating user mailboxes from the
Exchange 2003 server to your new Exchange 2007 server. Migrating mailboxes is simple: go to
your Exchange 2007 server and open the Exchange Management Console. When the console
opens, navigate through the console tree to Recipient Configuration | Mailbox. When you do,
the console's detail pane will display a list of every mailbox in the entire Exchange Server
organization.

In larger organizations with multiple mailbox servers, you probably don’t want to see a unified
view of all of the mailboxes across all of the servers. You can create a filtered view that will
display only the mailboxes residing on the server you want to migrate.

Select Create Filter from the top of the screen. A series of drop-down lists will appear at the top
of the console; these lists allow you to enter a condition for which you want the list of recipients
to be sorted. Since our goal is to migrate all of the mailboxes from a specific server, let’s filter
the recipient list so that only recipients with mailboxes on that server are shown. Select the
Server option from the first drop-down list and leave the second drop-down list set to Equals.
Select Browse; you should see a list of all of your organization’s Exchange servers. Choose the
server that you want to migrate and press OK. Select Apply Filter and the list will be filtered to
display only recipients with mailboxes on the selected server.

Now that the list has been filtered, it’s time to move the mailboxes. You can move all of the
mailboxes at once, but I recommend moving a couple of mailboxes individually first so you can
make sure that the migration process is working correctly. If you are concerned about the
integrity of your user’s mailboxes, you could always create a few sample mailboxes and fill them
up with junk mail as a way of testing the migration process before you attempt to migrate live
data.

To migrate a mailbox, right-click on the mailbox and select the Move Mailbox command from the
resulting shortcut menu. Exchange will launch the Move Mailbox wizard; its initial screen
prompts you to select a server, storage group, and database as the destination that you want to
move the mailbox to.

Select Next and you will see a screen asking you what you want to do if corrupt messages are
found within the mailbox. You have the option of either skipping the mailbox or skipping the
corrupt messages. If you choose to skip the corrupt messages, then you have the option of
specifying the maximum number of messages to skip before the migration is aborted.

Select Next and you will see a screen asking you when you would like for the mailbox to be
moved. The default option is to move the mailbox immediately, but you can schedule the move
for another time. Scheduling the migration is useful if you are afraid of disrupting user
productivity or disrupting the nightly backup.

In regards to scheduling, it may be impractical to try to move all of the mailboxes at once. For
example, if you try to migrate all of the messages at once, the migration process might take too
long and would be disruptive to the users. If you are worried about the amount of time that the
migration will take to complete, you can schedule the migration so only a few mailboxes are
migrated at a time. You don’t have to set the schedule individually for each mailbox; select
multiple mailboxes by pressing [Ctrl] and clicking on the mailboxes you want to move. When you
right-click on the selected mailboxes, you will have the option of moving the selected mailboxes
collectively as a group.

After setting the migration schedule, click Next and you will see a summary of the migration
options that you have chosen. As you look over the summary, pay particular attention to the
number of mailboxes to be moved. Otherwise you could be in for a nasty surprise if you
accidentally selected the wrong mailboxes.

If the summary looks good, select Move to move the mailboxes. When the move completes,
select Finish to close the wizard.

Linking users to their mailboxes

If you have ever installed Microsoft Outlook for your users, then you know the initial setup
process requires you to tell Outlook the user is connecting to an Exchange mailbox. After doing
so, you must enter the user’s name and the name of the Exchange server containing the user’s
mailbox.

The problem with this is that after you move a user’s mailbox to a different server, Outlook will
be pointed to an incorrect mailbox location. To get around this problem, I recommend deploying
Outlook 2007 to all of your users prior to deploying Exchange Server 2007. My primary reason
for making this recommendation is that Outlook 2007 is self-configuring when installed in an
Exchange Server environment. Rather than requiring you to manually enter the user’s name
and the name of the Exchange Server containing the user’s mailbox, Outlook 2007
automatically extracts the necessary information from Active Directory. If you deploy Outlook
2007 in advance, mailbox migrations should be semi-transparent to your users.

Slightly complicated
As you can see, deploying Exchange Server 2007 in an Exchange Server 2003 environment
requires more than just inserting an installation CD and running Setup. Before deploying
Exchange 2007 in your environment, I recommend thoroughly planning the deployment and
having a rollback strategy in place in case something goes wrong.