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
Estimated lesson time: 40 minutes
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
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.
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.|
|Software vendor/contact information|
|Number of departments using the software|
|Number of users in each department using the software|
|Default installation locations|
|Proprietary hardware 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.
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.
If the SMS infrastructure has already been sufficiently established, it can aid with the deployment of Windows 2000.
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:
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.
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:
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.
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 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.
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.
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.
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
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.
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.
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.
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.