Hickam Air Force Base: Preparing for Migration to Windows 2000 and Exchange 2000
By Rod Gallagher and Wesley H. Peace (Issue 3 2001)
Earlier this year, Dell Technology Consulting helped prepare Hickam Air Force Base for its eventual migration to Windows 2000 and Exchange 2000 from Windows NT 4.0 and Exchange 5.5. This article discusses benefits of that preparation as well as basic principles that may be useful to organizations planning a migration.
Hickam Air Force Base (AFB) in Honolulu, Hawaii, is one of the Air Force's premier bases in the Pacific. Most of the decisions that impact the rest of the Pacific-particularly those related to network maintenance and operations-are made at this location. In the future, many administrative tasks may be centralized at this location as well.
Given the importance of Hickam AFB to its geographically diverse operations, Dell® Technology Consulting was brought in to assist with development of best practices. At Hickam AFB, several of the steps required for a successful migration, which are discussed in this article, had already been completed before the Dell project began. By working with the IT staff at the base, Dell implemented and documented many common best practices.
During the course of this project, many legacy systems were replaced with larger Dell PowerEdge® 8450s and PowerEdge 4400s to consolidate operations on fewer systems and to enhance manageability and reliability. The Dell consulting team focused on preparing the Exchange® 5.5 infrastructure and the Windows NT® 4.0 backbone. A successful migration does not necessarily require new hardware, but the consulting team thought it best to use new hardware in this particular case. Figure 1 illustrates the network prior to the migration.
Figure 1. Hickam AFB network configuration prior to migration
Preparation for migration
The first rule of any migration is to fix existing problems before considering the migration. Many people might be tempted to avoid making changes to an existing network since it will be upgraded. But a better practice is to make sure that everything is functional on the existing network before trying to make major changes by installing Windows® 2000 or Exchange 2000.
Check applications and system logs for errors. Watch for periodic problems that have been ignored. Consider the state of the current system—working with a distressed Windows NT 4.0 system will produce a distressed Windows 2000 foundation. Make sure these things are clean before moving forward. Migrating to Windows 2000 or Exchange 2000 will not always fix underlying problems, and may in fact make existing problems worse.
Migrating from Windows NT 4.0 to Windows 2000
After any problems have been detected, take inventory of current systems and identify what needs to be migrated. Should existing computers be upgraded? What about the disk configuration? Can they accommodate the requirements of Windows 2000? Is there enough "elbow room" on the system disk? These questions lead to the second rule of migration: Examine hardware requirements to be sure existing systems can handle a potentially greater load.
This is important because the requirements of some new features may not be immediately clear, such as the "self-healing" features of Windows 2000. Windows 2000 internally maintains a copy of many critical files and restores them if needed. This, of course, requires additional hard disk space. Copies of service packs are also maintained on disk, as are copies of other information that might not have been maintained in a Windows NT 4.0 configuration. A complete list of this information is beyond the scope of this article, but a quick scan of an operational Windows 2000 system will provide some insight. The disk requirements of Windows 2000 may be substantially greater than those of Windows NT 4.0, depending on the environment and needs.
The following sections describe other considerations when preparing an existing Windows NT 4.0 domain for migration.
Establish domain controllers
Most existing Windows NT 4.0 domains are configured with domain controllers that also serve other functions. While this can work in small Windows 2000 domain configurations, it is not recommended. A Windows 2000 domain controller should be dedicated as much as possible to responding to authentication requests.
In most cases, this requires reviewing the existing domain controllers, files, and services installed and developing a plan to move non-domain controller functions to other servers.This often means moving user files, printers, and applications. This exemplifies the third rule: Servers have roles; avoid sharing roles on a single system as much as possible. When planning a migration, the infrastructure should include dedicated domain controllers, application servers, and file and print servers.
This was a critical component of the Hickam AFB server consolidation project. By dedicating servers for specific functions, it was easy to consolidate the number of servers and domain controllers in the domain. Hickam AFB reduced the number of domain controllers supporting their users. They also improved the performance of their other servers by giving them dedicated roles.
Another rule used to design domain controller configuration is that every system needs at least two domain controllers. Windows NT 4.0 requires a primary domain controller (PDC) and, for reliability, a backup domain controller (BDC). While Windows 2000 is slightly different, these same considerations should be taken into account when configuring a Windows 2000 domain. In either case, the end goal is reliability.
Confirm proper WINS/DNS operation
Critical to any network operations is the IP addressing scheme. This is extremely important when designing a Windows 2000 architecture, as TCP/IP has truly become essential for proper operation. Take some time during the planning process to ensure that the IP addressing scheme makes sense and can easily be supported in the future. Also, look at the way IP addresses are assigned. Windows 2000 uses Dynamic Host Configuration Protocol (DHCP), which can simplify configuration.
The name resolution components are essential to the proper operation of a TCP/IP network. Hickam AFB had a very robust and reliable Domain Name System (DNS) structure, so little was done to change this. Other networks may not be as reliable. It is important to make an accurate assessment and prepare the Windows Internet Naming Service (WINS) or DNS infrastructure for the migration.
Watch for login scripts
Login scripts are critical to domain operations. At Hickam AFB, Kixstart, a popular scripting utility, was used to map connections throughout the base. The new servers required the login scripts to be examined and corrected where needed. Some login scripts run for many pages, and these scripts significantly influence the end-user's experience with the migration. Ignoring this will lead to support calls that could have been avoided.
Check service packs and hot fixes
Prior to the migration, create a list of all required service packs, hot fixes, firmware, and basic I/O system (BIOS) updates. Document each of the requirements and prepare a checklist for each server to ensure that each machine contains the correct version of the OS and has the same versions of software and service packs. Perform any updates needed and have a second person review the installation to validate each configuration.
Having a consistent and stable hardware and software configuration is essential to a good migration. Updating the applications and firmware can help avoid problems once the new system is up and running. Be sure to check compatibility lists for each piece of hardware and software to ensure support.
Migrating from Exchange 5.5 to Exchange 2000
When considering a migration to Exchange 2000, the first step is to simply understand what new capabilities are needed. Why do you want this version? What do you hope to gain? Which options will you utilize, and which ones are not valuable to your organization?
These are all questions that must be answered before moving forward. Details do not have to be finalized at this stage, but a broad understanding is critical. Some of the issues, such as using Outlook Web Access (OWA), the conference server, or the Web Store functionality, can have a huge impact on the preparations required. This is particularly true of consolidating Exchange servers and designing the future network.
Consolidate the Exchange servers
One of the best practices implemented at Hickam AFB was consolidating the Exchange users onto more robust hardware to enhance the manageability and reliability of the existing Exchange environment. Exchange 2000 can reliably handle a larger number of users per box, which was one goal of the migration. In the future, some capabilities (such as OWA and the conference server) will be placed onto smaller systems that work in conjunction with the consolidated systems.
The need for larger mailboxes for each user also drove the migration to more scalable hardware. Most Exchange systems are no longer used simply for text messages, but now contain documents, spreadsheets, and graphics that many users store in their mailboxes. To accommodate this trend, a larger mailbox limit was established and the Exchange Store was moved onto a storage area network (SAN). By using larger servers and a SAN, Hickam AFB simplified its Exchange environment while providing a higher level of service to the user community.
Confirm service packs and hot fixes
As with the Windows NT 4.0 configuration, it is critical that the appropriate service packs and hot fixes are assembled and applied. The same holds true for BIOS levels and firmware. Software and hardware compatibility is a critical issue with Exchange 2000, so it makes sense to perform these tasks before a migration is planned. Then, when the actual migration begins, time is not wasted fixing problems caused by unsupported hardware, software, or service packs.
Preparing the Exchange Store
The first step in preparing the Exchange Store is to perform basic maintenance. This includes identifying and fixing any errors, compressing the Store, and performing a defragmentation of the Store. This is critical to ensuring a smooth migration, but has the added benefits of providing a more stable Exchange operating environment and reducing the disk requirements of the current environment.
It is also critical to properly back up the Exchange environment. And as a best practice, these backups should then be tested to be sure they work properly. Each of these functions was performed at Hickam AFB. A significant amount of space was saved, which was helpful even before the migration to Exchange 2000. This also helped assure Hickam AFB that the disaster recovery procedures in place prepared the base for any problems.
Hickam AFB now ready to migrate
The preparations described in this article prepared Hickam AFB for migration to Windows 2000 and Exchange 2000. Figure 2 illustrates a portion of the network after the preparations for migration were completed.
Figure 2. System configuration after migration preparations
Hickam's environment is particularly complex, but the system is now operating more smoothly than before the preparations began. The system now provides greater reliability and better resource utilization due to the best practices implemented by the Hickam and Dell consulting teams. Once the basic preparations have taken place, a proper migration and implementation design can begin. This process will require substantial time and energy, and the phases of the migration will be discussed in future Power Solutions articles.
Rod Gallagher (rod_gallagher@dell.com) is a principal consultant for Dell Technology Consulting. He has extensive experience with Microsoft® and Novell® products, both in the lab and the field. He holds an MBA and is a Microsoft Certified Systems Engineer (MCSE) and a Master Certified Novell Engineer (MCNE). Rod has been involved in designing Windows 2000 and Exchange 2000 migrations for a variety of Dell customers.
Wesley H. Peace (wesley_peace@dell.com) is a principal consultant and team lead in the Microsoft Consultant Practice of Dell Technology Consulting. He specializes in Microsoft Exchange Server and Advanced Microsoft products and services including Windows 2000. Wesley has earned recognition from Microsoft for his work and was nominated by the Microsoft Product Support Services organization to be the second Microsoft Server MVP.
