Lesson 2: Application Assessment | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

Strategic applications and general office applications will need to be functioning throughout the migration period and in the new Windows 2000 infrastructure. This lesson covers methods for taking inventory of the applications that are running in your business to test for Windows 2000 compatibility. You'll also examine Microsoft's Windows 2000 Readiness Analyzer tool for verification of both hardware and applications.

After this lesson, you will be able to

Begin the development of an application inventory and test plan.

Estimated lesson time: 40 minutes

Application Inventory and Compatibility

If a strategic application can't work in the new environment, this might become a potential showstopper. You might have to adopt workarounds that could mean operating in a mixed Windows NT and Windows 2000 mode until you find alternatives. Hence, a compilation of all server and client applications including administrative ones such as antivirus programs is required. Once you have a complete listing of all programs, you'll need to verify whether

Your commercial applications will work with Windows 2000.
Applications will require software updates to work with Windows 2000.
In-house applications will need modifications to work with Windows 2000.

A useful Web site for help with application compatibility is www.microsoft.com/windows2000/upgrade/default.asp; however, you should still put all the applications your company uses through the test lab.

Taking Inventory of Applications Manually

Having teams of people examining the applications on users' systems can be even more time-consuming than taking a manual hardware inventory. However, Table 3.2 lists some aspects that should be part of the inventory.

Table 3.2 Template for Gathering Information About Applications

Type of Information Needed	App1	App2	App3	Etc.
Version/service pack/hotfix
Software vendor/contact information
Number of departments using the software
Number of users in each department using the software
Installation requirements
Default installation locations
Proprietary hardware required
Business priority
Shortcuts required
Scheduled date for testing

Manual collection of this information is labor-intensive and time-consuming. If you don't have an automated system established, an alternative to reducing the burden on staff is to ask for the business manager of each division to complete a template similar to this one. You can send it as an electronic form via e-mail or you can make it available via an intranet.

Automating the Inventory of Applications

Management software such as SMS has the added benefit that it can also take inventory of installed applications. This is helpful if you need to know which business-critical desktop applications and server-based applications are being used and which servers they are being housed on. SMS will also help you locate idiosyncrasies on the desktop, such as specialized departmental applications that IT support (and sometimes managers) might not be aware of. You might be able to use the Windows 2000 migration as a means to consolidate the number of applications being used if you find that very few or no users are accessing old or outdated legacy programs.

TIP
If the SMS infrastructure has already been sufficiently established, it can aid with the deployment of Windows 2000.

Application Testing

Once you've obtained and prioritized the business applications and the number of affected users, try to develop some test criteria such as the following:

Does the application work with Windows 2000 at all?
Do the basic functions of the application work—opening files, saving files, printing files, and so on?
Does the application publish information to Active Directory?
If the application doesn't work, what can you do to make it work (for example, change a registry setting or obtain an updated .dll file, a patch, or a hotfix)?
If the application requires some changes, how easily can these be deployed?
If the application works but requires specialized hardware, does that hardware meet Windows 2000 compliancy standards?
Does the application rely on Windows NT services or special roles? For example, some software might work only on a Windows NT PDC or BDC. This will have major implications on the initial design of your Windows 2000 infrastructure (for example, you might be forced into a mixed-mode strategy).
Does the application require NetBIOS? If so, you'll need to plan for this. NetBIOS has a number of security loopholes and you should plan to remove it as soon as possible. For example, you might elect not to publish a network share in Active Directory, but it can still be viewed by browsing the main network.

As you can see, the answers to these questions could potentially affect your Windows 2000 migration plan, and it's important that you get some bearing on these issues prior to a migration. Microsoft maintains a list of applications that have been tested to work with Windows 2000. You can find these on the Internet at www.microsoft.com/windows2000/upgrade/compat/certified.asp; however, you should always endeavor to do your own testing.

Mission-Critical Applications and Business Applications

One major problem you might encounter with your migration is in determining how to keep your server-based applications such as e-mail services, inventory processing, or line-of-business applications available during the migration period. In some circumstances, the only way forward might be to schedule downtime such as a weekend period while the servers are migrated; however, this too could have implications should your international business units require these servers to be operational.

The first part in the migration process will be to classify applications into the following categories, from a client-processing perspective:

Mission-critical. These applications are generally ones that will cause the most damage to a corporation or a business if they're not online. Examples include e-commerce Web sites and applications critical for revenue collection.
Business-critical. These applications are generally ones that are required to run the business. Examples of these could include line-of-business, payroll, purchasing, and human-resource applications.
Crucial. These applications include ones that are required for the smooth running of the business, but the impact or cost of failure is low. Examples of these could include word-processing applications.

If your mission-critical applications and business applications will migrate to Windows 2000, you might then need to consider scheduling downtime or running a parallel system and migrating the data across. The latter is the safer method. However, you'll need to perform proof of concept testing to guarantee that Windows 2000 will work with your applications. Although an upgrade is easier, if it fails, the impact on your production environment can be much greater—so you should always backup prior to migration.

NOTE
For further information, read Chapter 21 of the Microsoft Windows 2000 Server Deployment Planning Guide volume of the Microsoft Windows 2000 Server Resource Kit.

Microsoft Readiness Analyzer

Microsoft offers a special program called the Windows 2000 Readiness Analyzer tool that evaluates whether the applications on your system and your system hardware are potentially incompatible with Windows 2000. You can run the program directly from the Internet (for machines connected to the Internet), or you can download it from the Microsoft Web site to use it on offline machines. The Readiness Analyzer is constantly being updated as more applications and hardware are tested and added to its database, so you're advised to download the latest version from www.microsoft.com/windows2000/downloads/deployment/radiskimg/default.asp.

Practice: Analyzing Application Compatibility

In this practice, two exercises cover alternative ways to help you assess your system for compatibility with Windows 2000. In the first exercise you will use the Microsoft Readiness Analyzer tool to check your existing applications and hardware for Windows 2000 compatibility. In the second exercise, you will use a simple method for collecting lists of the programs on your computer.

Exercise 1: Using the Microsoft Readiness Analyzer

In this exercise you will use the Microsoft Readiness Analyzer to test the readiness of your Windows NT system for an upgrade to Windows 2000.

Log on to MIGKIT1 as Administrator, using the password secret.
Open a command prompt and switch to the C:\Tools folder.
Type chkupgrd.exe and press Enter.
Click Yes to accept the license agreement.
The Readiness Analyzer will now proceed to validate whether your applications and hardware will be compatible with Windows 2000. This process can take a long time depending on the number of applications and devices you have installed. Once completed, you might see a screen similar to the one shown in Figure 3.2.

Figure 3.2 Readiness Analyzer upgrade report
Possible problem areas will be listed. If more information is available, a Details button will appear. You can save or print the report.
After reviewing the contents of the report, click the Finish button.
From the Tools folder, use Notepad to open the sample document called Benport.txt, an upgrade report created from running the Readiness Analyzer on a Microsoft Windows 98 system.
Use the document to answer the following questions:
1. Which hardware needs further investigation?
2. Which software might not be supported?
3. Which software will need to be reinstalled after an upgrade?

Answers

Exercise 2: Taking Inventory of Applications

As an alternative to using the Readiness Analyzer, you might simply want to create a list of applications residing in specific locations on workstations and servers.

Open a command prompt.
To find the applications residing on drive C:, type the following:
```
C: cd\ dir c:\*.exe /s > %computername%.txt
```
This last command searches for all executable files on the C: drive and creates a file that has the same name as the computer on which it's run. For example, if you type this command on MIGKIT1, the document will be called Migkit1.txt.
Open the file and observe that it has located all the executables on the hard disk.

You can also use this technique in a logon script to search for .cmd, .dll, .com, or other files, and then bring the text file into a corporate database that validates whether each file is Windows 2000–compliant.

Lesson Summary

In this lesson, you learned several methods for collecting information about current hardware and software applications. You learned to use the Microsoft Windows 2000 Readiness Analyzer and examined how to automate the collection of lists of applications for later testing.