When migrating to Windows Server 2008, IT shops need to know how to move all of the content from the legacy network to the new parallel network. This excerpt from Chapter 12 of Microsoft Windows Server 2008: The Complete Reference by Danielle Ruest and Nelson Ruest examines the four major activities a Windows Server 2008 migration strategy must cover and outlines a migration order for virtual service offerings.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
When you're ready to move to the new network, you'll have to put together a migration strategy. This strategy must cover four major activities:
More on Windows Server 2008 migration Preparing for Windows Server 2008 migration
Windows Server 2008 migration: Return on investment calculation
IT managers eye new Windows Server 2008 features
- Security principal migration Migrating users and computers from the directory service in use in the legacy network to Active Directory Domain Services in the new network.
- Member server migrations Migrating all services found on member servers, including file, print, management, collaboration, and more. This also includes special products, such as Exchange, SQL Server, and other services that manage the back office.
TIP To find out more about Microsoft Exchange Server migration, look up MCITP Self-Paced Training Kit (Exam 70-238): Deploying Messaging Solutions with Microsoft® Exchange Server 2007, by Ruest and Ruest, published by MS Press.
- PC migrations Migrating PCs from obsolete operating systems to Windows Vista. This will also involve capturing and restoring user data and preferences or profiles. This portion of the migration may already be done.
- Custom application migrations This involves mostly conversions or redevelopment of both rich-client and Web-based in-house applications.
Each of the four stages is a mini-project of its own, and each will require its own resources. You should begin with the security principal migration. If you set up your environment the right way, you will be able to migrate user and computer accounts, as well as groups, at your own pace, giving yourself time to prepare the other aspects of the project. In addition, by using the parallel Virtual Service Offering network approach, you don't affect the current production environment so that users in either network will be able to share applications and services from both networks during the entire length of the migration project.
Next, you'll be able to move to member server migrations. Ideally, you will be able to migrate a service, stabilize the new virtual servers, and then proceed to the client migration. For client migration, you will ideally migrate their PCs to Windows Vista (if it isn't already done) in order to fully profit from the new services infrastructure. As you migrate PCs, you will need to move users to the new service and monitor service performance. It will usually take one to two months of operation before services are fully stabilized. Afterward, you will want to monitor services for growth potential. Meanwhile, you can have your development staff working on upgrades of your key applications, since these will take time and may not be ready until all other migration tasks have been performed.
TIP If you need to migrate PCs, we strongly recommend you pick up the free e-book The Definitive Guide to Vista Migration at http://www.realtime-nexus.com/dgvm.htm. It provides a wealth of information that may also assist you in the migration of your servers.
Keep the following considerations in mind as you prepare your migration:
- Identity servers You'll begin with the identity servers to perform the security principal migration. Domain controllers (DCs) and Active Directory Domain Services are absolutely essential for the new network to function. Prepare these servers first. Populate enough DCs in the virtual environment to provide a given level of service. If you are a small organization (SORG) with only one site, then you can begin the migration of other services once you have your base production forest infrastructure in place. In very small organizations (about 100 users or fewer), this will mean a single-domain forest and, therefore, two DCs for redundancy. In medium (MORG) to large organizations (LORG), which have at least two sites, you can usually begin the migration of some of your services once you have DCs located in at least two sites. Refer to the recommendations in Chapter 6 for the base requirements for the construction of these DCs.
- Network infrastructure Next, you can move to the migration of Dynamic Host Configuration Protocol (DHCP) and Windows Internet Naming Service (WINS)—if you haven't decided to use DNS GlobalNames Zones—because no special client is required for computers to use these services. They work with all versions of Windows. It may be easiest to use a new pool of addresses to do so, however, if you don't want to affect your production systems. Or another good way to perform this migration is to move up to IPv6 in the new network while the legacy network continues to offer IPv4 addresses. Make sure your applications are compatible with IPv6 before you decide to use this strategy. For example, verify network intrusion detection systems, antivirus systems, network analyzers, and so on. Next, create the Windows Deployment Services (WDS) servers because they are required to build PCs. Finally, create your systems management and operational servers so that your management infrastructure will be ready to manage new servers as they are added to the parallel network. The result should be a core network that is ready to deliver services both in a central office to meet the needs of SORGs, MORGs, and LORGs (see Figure 12-2) and remote offices to meet the needs of MORGs and LORGs (see Figure 12-3 ). And if you followed the advice in Chapter 11, you will already have your core business continuity strategy in place (see Figure 12-4 ).
Figure 12-2: The core network for a central office .
Figure 12-3: Using server-in-a-box for remote offices
Figure 12-4: Business continuity from site to site
TIP: Remember that because Virtual Service Offerings run on virtual machines, you don't really need a tool like WDS to provision them, since all you need to do is copy the files that make up source machines to create a new one. Also see the Application Virtualization: Ending DLL hell once and for all webcast at www.bitpipe.com/detail/RES/1193672482_325.html.
- Dedicated Web servers If you're using single-purpose Web servers, then the dedicated Web servers can be next, since IIS 7 provides backward compatibility for Web applications. Be sure to thoroughly test all applications before putting them into production. There are serious modifications in IIS 7 that may affect application operation. As with network infrastructure servers, no special client is required to operate with IIS.
- Application servers General-purpose IIS servers can also be migrated at the same time as the dedicated Web servers for the same reason. Database servers can also be migrated since, once again, they will operate with existing clients. Corporate application servers can also be migrated since they will also operate with existing clients. Remember to test each component before releasing it to end users.
- Terminal Services Windows Server 2008 Terminal Services (TS) servers can operate through Remote Desktop Web connections through TS Web Access. Clients need to be running the latest version of the Remote Desktop client (RDC). If you want to publish applications to take advantage of RemoteApps, and you want to make them available to existing PCs, then make sure you deploy the latest RDC to each PC.
TIP: You might not need to work with Terminal Services at all if you've decided to move to application virtualization. We strongly suggest you take a look at this operating model, since it is less expensive and more effective than running remote applications through Terminal Services. For more information, see Chapter 6 in The Definitive Guide to Vista Migration at www.realtime-nexus.com/dgvm.htm.
- File and print services File services require transfers of large quantities of data to migrate. As such, they should be kept toward the end of your migration or, at the very least, they should be coordinated with PC migrations (servers first, then PCs). Special attention should be paid to file ownership and access rights when files are migrated from the legacy network to the new network. Print services can be moved at the same time. This will decrease the number of printer drivers you need to make available on your systems, since you will only have to deal with updated PC systems.
CAUTION: Keep in mind that you can and should look to the replacement of file services with collaboration services based on Windows SharePoint Services (WSS). WSS provides a richer environment for collaboration than file servers can on their own.
- Collaboration services These services should be kept for last because they are at the basis of network service evolution. Windows Server 2008 collaboration services extend the capabilities of your network. As such, they require the full capabilities of the new network. You might consider using them, especially the WSS role, instead of working with file servers, replacing the user-oriented file servers altogether with WSS servers.
Remember to create your organizational unit (OU) structure first and pre-stage servers in the directory. Then create the server kernel and follow through with the server role staging process. Then, and only then, can you migrate data and users to the new network.
Excerpted from Microsoft Windows Server 2008: The Complete Reference by Danielle Ruest and Nelson Ruest (McGraw-Hill; 2008) with permission from the McGraw-Hill Companies.