- Install Windows 2003 on a PC, and then connect the server to your network's primary domain. Make this server a domain controller. Once the new server has been established as a domain controller, let it sit for a couple of hours so that the replication process has time to complete.
- Once the domain controller has a full copy of Active Directory, shut it down and unplug it from your network.
- Connect the newly created domain controller to an isolated switch that's not connected to the rest of your network. Make sure that the switch is isolated. You can cause severe Active Directory problems if you attempt this in a domain controller that's not completely isolated from the rest of the network.
Because our goal is to create a lab to test deployment, we've created a domain controller that completely mimics our production domain controllers. Before we can gain the full benefit of having this domain controller replica, we'll have to seize operation master roles.
If you're unfamiliar with operation master
- roles, Windows 2000 and Windows 2003 use a domain model known as multi-master. This means that when changes are written to Active Directory, those changes can be written to any domain controller and propagated to the remaining domain controllers. In this type of environment, there are certain functions that must take place to preserve order.
- To seize operation master roles, open a Command Prompt window and enter the following commands:
connect to server servername (or server name is the name of the domain controller on the isolated network segment)
seize schema master
- When prompted, click Yes to indicate that you want to seize the schema master.
- Enter the following commands and click Yes after each command to confirm the operation:
Seize domain naming master
seize RID master
seize infrastructure master
- When the process completes, close the Command Prompt window.
- Reboot the domain controller.
Windows Server is designed so that the first domain controller brought online in the forest -- and the first domain controller brought online within each domain -- performs special housekeeping functions known as flexible operation master roles.
We've created a domain controller replica, removed it from the network and then placed it on its own network segment. Therefore, we've created a separate Active Directory environment. However, this Active Directory environment is incomplete because of the absence of flexible operation master roles. Windows allows you to seize operations master roles when a domain controller that was originally hosting the roles fails and cannot be recovered. This means telling Active Directory that the server that was previously hosting the roles doesn't exist anymore, and that you want a different domain controller to host the various roles. It's very important to ensure that your domain controller is on an isolated network segment beforehand.
When creating a domain controller for a lab environment, many people like to restore a back up, rather than install Windows. There is nothing wrong with this method, but I prefer the former method to avoid any complications related to machines that have different hardware from one another, as well as Windows activation issues.
Regardless of which method you use, you must make sure that the domain controller is performing the various flexible operation master roles on the lab network before you bring Exchange server into the equation. If you choose to restore a domain controller back up to the lab machine, you can accomplish this by restoring a back up of the domain controller that already holds the flexible operation master roles. You could also seize the roles using the above method.
Because your final goal is to migrate all Exchange Server 2003 mailboxes and public folders to an Exchange Server 2007environment, you will need one or more Exchange 2003 servers in your lab. Ideally, you'll want to create lab replicas of all of your production Exchange 2003 servers. Depending on the complexity of your Exchange 2003 organization though, this may be impractical.
If you're using identical hardware for your Exchange 2003 servers, then bringing Exchange 2003 into a lab environment should be simple. You can create a full-system state backup of each Exchange server, and then restore that backup to the duplicate hardware. Make sure that the Exchange server back up that you're restoring was made at about the same time as your lab's domain controller. Otherwise, Active Directory mismatches could occur, resulting in the existence of mailboxes for users whose accounts have been deleted, for example.
Even in an ideal situation, you still must have a plan in place. Depending on how complex your network is, you may have to add some networking hardware to recreate sites and simulate WAN links.
If your production Exchange organization contains multiple sites, then you must ensure that the networking hardware that bridges sites in your lab environment is configured similar to that of your production network. You don't need routers that are identical to those on your production network, but IP addresses must be identical.
Simulating multiple sites will also complicate your need for domain controllers. Each site on your lab network will require at least one domain controller; you also must configure bridgeheads and site links.
If Active Directory doesn't contain multiple sites, then this won't be an issue. However, if Active Directory does contain multiple sites, you can choose to simulate only the sites that contain Exchange servers, or test your migration procedure on a single site.
Having duplicate hardware available can simplify the act of adding Exchange 2003 servers to your lab network, but it's often difficult to obtain. Although you can configure a high-end PC to act as an Exchange server, this requires additional work because we're trying to make the lab environment as similar to the production network as possible.
To do this, your online domain controller contains an exact copy of your production Active Directory database. Exchange Server depends completely on Active Directory. The domain controller in your lab environment is aware of your production Exchange servers, because it wrote configuration information to Active Directory when it was deployed.
This means that your lab Active Directory contains computer accounts for your Exchange servers, so you can't install Exchange 2003 from the ground up. If you tried to do this, and assigned the same name as one of your production servers, it wouldn't work because the lab machine would have a different GUID than the production machine. Therefore, you must restore existing backups.
Remember, lab hardware is different from hardware used in a production environment. I recommend installing Windows manually, and then installing any necessary drivers that your lab system requires. You can name the lab machine the same as its production counterpart, but don't connect this machine to Active Directory since that has a computer account for the machine.
You should restore your backup to the lab machine, but you must be selective about the components that you restore. At the least you must restore the \EXCHSRVR directory and its subdirectories, as well as the system state. But before you restore the backup, you must patch the lab machine so that it runs the same patches and service packs as the production system. If you skip this step, Windows most likely won't work correctly after the restore.
A multi-tiered approach to hardware restoration
Because restoring Windows and Exchange to dissimilar hardware can be tricky, I recommend taking a multi-tiered approach. Your initial goals should be to get Windows functioning and to ensure that the new server is acknowledged as a domain member. After that, you can focus on restoring the information store.
If the disk configuration on the lab machine matches that of the duplicate server on the production network, you should be able to restore the information store. If they don't match, this process may be more complicated. What happens will vary since all Exchange organizations are different, but you can still try to restore the information store. If hardware differences prevent a successful information store restoration, I would recommend creating a recovery storage group and importing the mailbox data that way.
Your lab network must have a couple of workstations with Microsoft Outlook installed. I recommend installing the same version of Outlook that is used on your production network because Outlook 2007 is designed as self-configuring. When you move various mailboxes to the Exchange 2007 server, Outlook 2003 should intuitively know that mailboxes have been moved, but this may not always work. Outlook 2007 does well at determining mailbox moves automatically. If you plan to upgrade to Outlook 2007, you can test that in the lab as well.
I recommend using Outlook to test your lab's Exchange 2003 servers. You should make sure that users can log onto the network using the lab machines, and that they can open Exchange 2003 mailboxes using Microsoft Outlook. Exchange won't be able to send and receive email outside the Exchange organization at this point, but it should be able to send email internally.
Once you're confident that the system is working properly, you can upgrade your lab machines to Outlook 2007, if that's your plan. Outlook 2007 isn't required to run Exchange 2007. While there are a few new features that will only work if you're using Outlook 2007, you won't lose any functionality without it.
Outlook Web Access
You don't have to test Outlook Web Access (OWA) on your lab network prior to migrating to Exchange Server 2007. OWA is an IIS server acting as a front-end component of Exchange. Although Exchange 2007 supports OWA, the 64-bit requirement prevents you from doing a direct upgrade. Instead, the Exchange 2007 OWA server, or Client Access Server (CAS), will run completely different code on different hardware. Because there isn't anything for you to migrate with OWA, you can test it once you've deployed the updated version.
It's also important to use a lab environment to ensure that your new Exchange server can handle the anticipated workload. LoadSim is the tool-of-choice for testing Exchange's ability to handle a particular workload. You still can use LoadSim, but because it uses the Recipient Update Service (RUS), you must have a system running Exchange Server 2003 in your lab environment.
If you plan to keep an Exchange 2003 server online, then you might want to use the Microsoft Exchange Server Load Generator. This tool performs the same basic tasks as LoadSim, but it's designed specifically for use with Exchange Server 2007.
A lab network is basically a replica of your network as it will exist after migration is complete. Therefore, your lab network is perfect for training purposes. For example, you can bring in some extra workstations and offer users Outlook 2007 training. Because the lab domain controller is a replica of a production domain controller, you won't have to set up user accounts or mailboxes for the trainees. You can also use the lab to train administrative staff on day-to-day tasks.
Once you're comfortable with how the migration process will occur as well as using Exchange Server 2007, you can perform the actual migration. Some companies have purchased additional hardware so they can maintain the lab for long-term use. This lets companies test patches before deploying them to the production network and can serve as part of a disaster recovery contingency plan.
It's important to perform trial runs of your Exchange server in a lab environment to validate a deployment or migration techniques. But trial migration is only the beginning. There are still several things that you'll want to do in your lab environment after you've completed the migration.
Primary post-migration task involves testing Microsoft Outlook. You've migrated real data from copies of real mailboxes belonging to users; therefore, a few power users should be able to log onto your lab machines to access their mailboxes. You want to ensure that users can access their mailboxes and calendars, send messages to one another and schedule meetings. Because the lab environment is isolated, sending and receiving external SMTP email isn't possible.
Once you've verified that the migration was successful, it's time to test your backup strategy. Specifically, you need to know if your current backup software will work with Exchange Server 2007.
Even if your backup software is certified to work with Exchange 2007, there are two main reasons to test it anyway.
- You'll eventually have to back up data in a production environment, so is important to understand the process ahead of time. You should understand how your backup software works, how to verify that a back up was successful and how to restore a back up. Because the lab environment contains no production data, you should attempt to restore an Exchange database. If there are problems with your back up strategy, it's best to find out now.
- Even though your backup software is certified for Exchange Server 2007, Microsoft has recently made some changes to the way backups work in Exchange 2007. When Microsoft released Exchange Server 2007 SP1, it disabled remote streaming backup capabilities. You need to find out if this issue affects you. Incidentally, if you do discover that changes to remote streaming backups are a problem, there is a manual workaround that you can use to reinstate them.
Planning for an Exchange Server 2007 migration
Part 1: Exchange Server 2007 requirements
Part 2: Deploying Exchange 2007 server roles
Part 3: Test considerations for Exchange 2007 hardware and clustering
Part 4: How to set up and run an Exchange 2007 test lab environment
|ABOUT THE AUTHOR:|
Brien M. Posey, MCSE|
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
This was first published in March 2008