Windows Server 2008 R2 Unleashed (107 page)

6. On the target server, click Start, Administrative Tools, Windows Server Migration

Tools, right-click Windows Server Migration Tools, and click Run As Administrator.

7. Type import-smigserversetting –ipconfig ALL -sourcephysicaladdress

“”,”” -targetphysicalad-

dress “”,”” -path

path> -verbose.

8. When prompted, provide the password set during export.

NOTE

You must specify the physical mapping for each adapter indicated by

and . Use the physical

address for each adapter where indicated.

9. A restart is required for some of the settings to take effect.

ptg

Migrating Print Services

Migrating printer settings from an older environment can be accomplished by first export-

16

ing print queues, printer ports, and settings before importing them to Windows Server

2008 R2. The tools at your disposal for this job are the Printer Migration Wizard or the

printbrm.exe command-line utility.

NOTE

Migrating printer settings directly from Windows 2000 servers and older using the

Printer Migration Wizard or the printbrm.exe command-line tool is not supported. An

interim migration to Windows Server 2003 or 2008 is required before migrating to

Windows Server 2008 R2.

The Printer Migration Wizard gives you the graphical user interface that walks you

through the migration process. This is the easiest method of migrating printers. The steps

to migrate print servers are as follows:

1. Open Print Management (Start, Administrative Tools).

2. If not already there, add the remote print server using add/remove servers.

3. Right-click on the remote server and select Export Printers to a File to launch the

Printer Migration Wizard.

4. Review the list of items to be exported, and then click Next.

5. Browse to the location on the local server to save the export file, and click Next.

6. Click Finish when the export is complete.

522

CHAPTER 16

Migrating from Windows Server 2003/2008 to Windows Server

2008 R2

7. Still in Print Management, right-click on the target server, and click Import Printers

from a File to launch the Printer Migration Wizard.

8. Browse to the export file location on the local server, click Open, and click Next.

9. Review the list of items to be imported, and click Next.

10. Select Import mode, specifying if you want to overwrite or keep existing printers.

11. Select List in the Directory to specify your preferences for listing the imported print-

ers in the Active Directory.

12. Check Convert LPR Ports to Standard Port Monitors if you want to take advantage of

the faster Standard Port Monitor.

13. Click Next to start the import.

14. When the import has completed, click Finish.

NOTE

For in-place-upgrades, use the Printer Migration Wizard to export printer settings before

the upgrade and then import printer settings back to the same server after the upgrade

has completed.

ptg

An alternative method of migrating the printer servers is to use the command-line utility

printbrm.exe. This utility is not as “pretty” to use as the Printer Migration Wizard, but it

allows you to automate the migration process and reduces the number of steps. The steps

to migrate using the command line are as follows:

1. On the target server, click Start, All Programs, Accessories, then right-click Command

Prompt and select Run As Administrator.

2. Type CD %Windir%\system 32\spool\tools and then press Enter.

3. Type printbrm -s \\\ -b -f .printerexport and then

press Enter.

4. Type printbrm -s \\\ -r -f .printerexport and then

press Enter.

Summary

Although Windows Server 2003/2008 and Windows Server 2008 R2 are close cousins in

the operating system family tree, there are some compelling reasons to upgrade to

Windows Server 2008 R2 Active Directory Domain Services. The evolutionary nature of

Windows Server 2008 R2 makes performing this procedure more straightforward because

the upgrade does not require major changes to Active Directory architecture or the operat-

ing system design.

Best Practices

523

In addition, advanced tools such as ADMT v3.1 provide for a broad range of options to

bring organizations to Windows Server 2008 R2 functionality and closer to realizing the

benefits that can be obtained through a migration.

Best Practices

The following are best practices from this chapter:

. Ensure that one of the postupgrade tasks performed is an audit of all services so that

servers that need IIS have the service reenabled after migration.

. Because prototype phases of a project are essential to test the design assumptions for

a migration or implementation, create a production domain controller and then

isolate it in the lab for testing.

. Test the hardware compatibility of any server that will be directly upgraded to

Windows Server 2008 R2 against the published Hardware Compatibility List from

Microsoft.

. Keep in mind that Windows Server 2008 R2 is only available as 64-bit when develop-

ing migration plans. Older 32-bit hardware will need to be decommissioned or

ptg

repurposed.

16

. Because the decision to raise the forest or domain functional levels is irreversible,

ensure that there is no additional need to add Windows Server 2003/2008 domain

controllers anywhere in the forest and that there are no other compatibility issues

before performing this procedure.

. If the server or servers that hold the OM roles are not directly upgraded to Windows

Server 2008 R2 but will instead be retired, move these OM roles to another server.

. When using ADMT, migrate groups into a new domain first to keep users’ group

membership intact.

. Use the new Windows Server Migration Tools to migrate server roles to Windows

Server 2008 R2.

This page intentionally left blank

ptg

CHAPTER 17

IN THIS CHAPTER

Compatibility Testing
. The Importance of

Compatibility Testing

. Preparing for Compatibility

Testing

. Researching Products and

Applications

. Verifying Compatibility with

Vendors

At this point in the book, the new features of Windows

Server 2008 R2 have been presented and discussed in depth,

. Microsoft Assessment and

as have the essential design considerations and migration

Planning (MAP) Toolkit

processes. The goal of this chapter is to examine the process

. Lab-Testing Existing

of testing the actual applications that rely on the Windows

Applications

Server 2008 R2 infrastructure.

. Documenting the Results of the

This chapter provides insight into the steps necessary to

Compatibility Testing

gather information before the testing process begins, how to

ptg

. Determining Whether a

actually test the applications and document the results, and

Prototype Phase Is Required

how to determine whether a more extensive prototype

testing process is needed. Going through this process is vital

to ensure the success of the project and to avoid a displeased

end-user community. The application testing process is

intended as a quick way to validate the compatibility and

functionality of the proposed end state for the upgrade.

Currently, many companies are seeking to “right-size” their

network environment, and might be using the upgrade to

Windows Server 2008 R2 as a chance to actually reduce the

number of servers within the network infrastructure. At the

end of the process, fewer servers will handle the same tasks

as before, and new functionality might have been added,

making the configurations of the individual servers that

much more complex, and making it even more important

to thoroughly test the mission-critical networking applica-

tions on the server. For example, Windows Server 2008 R2

introduces a tremendous amount of new technologies that

enhance failover clustering, web applications, virtualization,

security, Remote Desktop Services, improved branch office

deployments, and much more, prompting some organiza-

tions to replace existing Windows systems with Windows

Server 2008 R2. Thus, it’s even more important to test this

526

CHAPTER 17

Compatibility Testing

configuration to ensure that the hardware and software are compatible, the performance

meets user expectations, and the everyday features used by the employees to share knowl-

edge and collaborate are in place.

The results of the application compatibility testing process will validate the goals of the

project or reveal goals that need to be modified because of application incompatibility or

instability. If one key application simply won’t work reliably on Windows Server 2008 R2,

the legacy Windows system might need to be kept as part of the networking environment,

which changes the overall design. As discussed in Part II of this book, “Windows Server

2008 R2 Active Directory,” a variety of different combinations of Windows Server system

configurations can be combined in the end configuration, so the chances that there will

be a way to keep the troublesome applications working in the new environment are good.

NOTE

Many legacy systems running old applications and operating systems cannot be

upgraded to Windows Server 2008 R2. This is because the application is not compati-

ble with Windows Server 2008 R2, a direct upgrade from the legacy operating system

is not supported, and/or the hardware is not compatible with Windows Server 2008

R2. When these circumstances exist, it is common for organizations to utilize virtualiza-

tion technologies such as Hyper-V Server or VMware to emulate and maintain these

ptg

legacy applications and operating systems.

The Importance of Compatibility Testing

The process presented in this chapter is an essential step to take in validating the design

for the end state of the migration or upgrade. The size of the organization and the breadth

and scope of the upgrade are important factors to consider in determining the level of

testing needed, and whether a full prototype should be conducted.

The differences between a prototype phase and an application testing phase can be

dramatic or negligible based on the nature of the upgrade. A prototype phase replicates

the end state as completely as possible, often using the same hardware in the test lab that

will be used in the production rollout.

CAUTION

Application testing can be performed on different hardware with different configurations

than the end state, but be aware that the more differences there are between the test-

ing environment and the actual upgraded environment, the greater the risk for unex-

pected results. Essentially, you can do an application testing phase without a complete

prototype phase, but you shouldn’t do a prototype phase without a thorough application

testing process. This recommendation also applies when planning to use virtual tech-

nologies such as Hyper-V.

Preparing for Compatibility Testing

527

Most network users don’t know or care which server or how many servers perform which

task or house which application, but they will be unhappy if an application no longer

works after a migration to Windows Server 2008 R2. If the organization already has Active

Directory in place and is running Windows Server 2003 systems, the risk of application

incompatibility is likely to be less than if the organization is migrating from an older oper-

ating system, such as NT 4.0 Server, Windows 2000, or a competing operating system,

such as Novell NetWare. It is possible to conduct an in-place upgrade from Windows

Server 2003 or Windows Server 2008 to Windows Server 2008 R2. However, a direct

upgrade from Windows NT 4.0 or Windows 2000 is not supported.

NOTE

If there is a need to preserve settings by upgrading a legacy operating system such as

Windows NT 4.0 or Windows 2000, the system should first be upgraded to Windows

Server 2003 and then again to Windows Server 2008 R2. Typically, this is not the rec-

ommended approach because the hardware is typically outdated; however, the multiple

upgrade approach is doable.

Preparing for Compatibility Testing

ptg

Although the amount of preparation needed will vary based on a number of factors,

certain steps should be followed in any organization—the scope of the testing should be

identified (what’s in and what’s out), the goals of the testing process should be clarified,

and the process should be mapped out.

A significant advantage of following a phased design methodology, as presented in

17

Chapter 2, “Planning, Prototyping, Migrating, and Deploying Windows Server 2008 R2

Best Practices,” is in the planning discussions that take place and in the resulting state-

ments of work, design, and migration documents that are created as deliverables. Often,