Upgrading your corporate Windows 9x Desktops to Windows ...



[pic]

Operating System

Upgrading your corporate Windows 9x Desktops to Windows 2000 Professional

Scenario Guide

Abstract

This scenario guide outlines the factors you should take into consideration when planning to upgrade from your Microsoft® Windows® 95 or Windows 98 operating system desktop environment to the Windows 2000 Professional operating system. Specifically, it focuses on how to plan and deploy Windows 2000 Professional to managed and unmanaged clients without using Windows 2000 Server or the Active Directory™ service.

© 2000 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Active Directory, Windows, Windows NT and the Windows logo are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

0200

Contents

INTRODUCTION 1

Terminology 1

Scenario Requirements 2

Scenario Definition 2

Scenario Goal 2

Phases of Deployment 3

Data Gathering 3

Operating System Considerations 3

Hardware Considerations 4

Application Compatibility Considerations 4

LitWare’s Data Gathering Results 4

Planning and Design 5

Checking Compatibility 5

Windows 2000 Compatibility Lists 6

LitWare’s Design and Planning Decisions 7

Testing 8

Hardware Compatibility 8

Application Compatibility 9

Upgrade Testing 9

LitWare’s Testing 10

Piloting 10

LitWare’s Pilot 11

Production Deployment 11

Pre-Upgrade Check List 11

Upgrade Process Walktrhough and Flowcharts 13

Walkthrough 13

Windows 9x Portion 14

Windows 2000 Portion 15

Upgrade Process Migrations 16

User Account and Profile migration 16

Skipped Logon Process (using the ESC key) 16

Log on as clients of a Microsoft network 17

Log on as Workgroup clients or clients of a non-Microsoft network 17

Installation Directory 18

Machine Accounts 18

Application Migration 19

Migration Extension Interface 19

Overview of Migration DLL’s 20

Deployment Methods 21

Manual Upgrades 21

Automated Upgrades 21

Automated Deployment Methods 21

Automated Installation Scripts 21

Summary 25

Related Links 25

Windows 2000 Web Site Resources 25

Introduction

This deployment guide provides information that will guide you through preparing for a Microsoft® Windows® 2000 operating system upgrade in your network environment. This guide is designed for Information Systems professionals who are responsible for installing the Windows 2000 Professional operating system on many computers.

The upgrade is illustrated with the example of a small company upgrading its existing Windows 9x desktops to Windows 2000 Professional. The company is currently running a single domain network, based on Windows NT 4.0 Server and will be upgrading to Windows 2000 Advanced Server in the future.

In an upgrade, as many settings as possible are migrated to the new system. Due to significant differences between Windows 9x and Windows 2000 Professional, there is no guarantee that an upgraded machine will retain all features and customizations from the Windows 9x installation; all components, however, are upgraded successfully. Setup also supplies a mechanism for application vendors to provide migration dynamic-link libraries (DLLs) that allow their applications that were written for Windows 9x to run on Windows 2000 Professional.

Without a migration DLL, there is no guarantee that all previously installed applications will run after the upgrade. Testing your applications in your upgrade scenarios is the only way to ensure post-upgrade compatibility.

This guide does not discuss “clean” installations on new computers, on freshly formatted disks, or in a new directory on an existing installation. Information on hard-disk duplication, including cloning, can be found on the Windows 2000 Planning and Deployment site. The guide also does not discuss the upgrade of server infrastructures or upgrading to the Windows 2000 Active Directory™ service.

You should use this guide in conjunction with the Windows 2000 Deployment Planning Guide, in particular Part 6 - Windows 2000 Professional/Client Deployment.

Terminology

The terms upgrade and migration, as they are used in this guide, mean replacing the operating system in place using the upgrade features of Windows 2000. A clean install means formatting the disk and reinstalling the operating system and all applications. Windows 9x is used throughout this guide to collectively refer to Microsoft Windows 95 and Microsoft Windows 98.

Scenario Requirements

This guide assumes you are familiar with the features, functionality, and benefits of Windows 9x, Windows 2000 Professional, and Windows NT 4.0 Server.

Scenario Definition

In this scenario, we are using a fictional company named LitWare, Inc.

LitWare, Inc. currently has a single domain spanning two physical locations, Denver and Seattle, with a total of 500 desktops. The two locations are connected with a high-speed, reliable, leased line.

Scenario Goal

This guide discusses some of the deployment options that are available to LitWare, Inc. and why they chose those options. Some of the main areas covered in this guide are planning and upgrade considerations, phases of deployment, and setup tasks.

Phases of Deployment

Any deployment or upgrade of an operating system has several phases, including data gathering, planning and design, testing, piloting, and production deployment (rollout). These phases are described in the coming sections.

Data Gathering

Planning and testing of the Windows 2000-based desktop environment is greatly aided by a thorough assessment of your current network operating systems, infrastructure, desktop environment, and conventions. If you don’t know the exact state of the desktop and network environment, problems can arise. Make sure to document the following information:

• Business organization and geographical requirements.

• Technology architecture.

• Interoperability.

• Network and application standards—current and future.

• User types (roaming, mobile, remote, task-based, knowledge-based, and so on).

• Support processes.

• Naming conventions.

• Hardware configurations and standards.

o Include brand and model; processor type and speed, amount of memory, hard drive free space, and BIOS revision number.

• Application configurations and standards.

o Include installed service packs and hot fixes, all third-party applications, and any registry-entry changes that have been made.

• User settings and user data.

Operating System Considerations

Computers that have more than one operating system installed (dual or multi-boot computers) cannot be upgraded to Windows 2000 Professional. If you want to install Windows 2000 Professional, you must reformat the hard drive partition and perform a clean installation. Any programs and user data on the partition will be lost unless they are properly backed up beforehand and then reinstalled.

Windows 9x systems that were upgraded from Windows 3.x may have many leftover files in the Windows directories that will not be cleaned out during an upgrade. It is recommended that you test the results in your network environment before deciding between an upgrade and a clean install.

Windows 9x systems that run from a shared server installation cannot be upgraded because they are not local installations. These systems require a clean install.

Hardware Considerations

You need to make sure that the hardware meets or exceeds the specifications required to run Windows 2000 Professional. To install Windows 2000 and have it perform as it is designed to do, you must have at least the following:

▪ Pentium class 133 MHz or faster computer

▪ 64 MB RAM

▪ 650 MB free space on your hard disk

▪ Uncompressed hard drive partition. If the hard disk on which you have Windows 9x is compressed, it must be uncompressed before it can be upgraded.

Also, check that the hardware peripherals are compatible with Windows 2000 Professional. It is recommended that the hardware BIOS supports Advanced Configuration and Power Interface (ACPI) and other advanced features of Windows 2000 Professional but this is not required.

Application Compatibility Considerations

Ensure that all applications you need will run on Windows 2000 Professional. Use the software compatibility list to verify whether an application has been successfully tested by Microsoft. Check with the software vendor to check if they have performed their own testing and established compatibility. The vendor may provide or recommend an update to some applications (the update is often referred to as a Migration DLL).

In-house applications must be tested to establish their compatibility. 16-bit applications run in a virtual-DOS machine (VDM) under Windows 2000 Professional, which precludes any direct hardware calls from the application or the use of Virtual Device Drivers (VxDs).

To prepare for a Windows 2000 active directory environment, find out whether the application will be able to get full use from the features and benefits of Windows 2000 and Microsoft Active Directory.

LitWare’s Data Gathering Results

After extensive discussions with their IT leads and an inventory of all hardware and applications, our example company LitWare knows that the Seattle site defined a standard configuration for desktop and mobile machines several years ago. The Seattle site has determined they have a total of 400 Windows 9x workstations with Service Pack 1 and the Year 2000 Update installed. Seattle replaces approximately one third of its machines each year. There is a range of video cards, monitors, Network Interface Cards (NICs), CD-ROM drives, and hard drives, although most of it is standard. This standardization will ensure that the Seattle site has a smooth migration path.

The Denver site has a total of 100 Windows 9x workstations with Service Pack 1 and the Year 2000 Update installed. The Denver site has only recently implemented a hardware policy similar to Seattle’s and begun to ensure that the hardware they purchase is on the HCL. Therefore, they own a large variety of differing hardware from many manufacturers, including some in-house built machines, and a mix of old and new hardware. This lack of standardization will result in a more problematic upgrade.

Both the Seattle and Denver sites have the same basic applications running on their workstations. The common applications consist of Microsoft Office 97 Service Release 2, Microsoft Internet Explorer 3.02, four third-party applications, and two custom in-house applications. Of the two custom applications, one uses VxDs. There are currently ten multi-boot desktops in the organization’s development department.

Planning and Design

The planning and design phase may require several iterations before complete. Before you start this phase, you must first understand the product’s capabilities and learn how to configure and use both the new and old features. Keep in mind that many things have changed in Windows 2000 Professional. To ensure that you are completely familiar with the new interface and processes, it is best to test all functions several times.

You also need to set goals for the deployment. Determine what your organization wants to gain by deploying Windows 2000 Professional, and what features in Windows 2000 Professional can assist your organization in reaching those goals.

Check for network diagrams and documentation. If you do not have these, create them and make sure they are accurate. They will be used during this phase to plan the deployment methodology. You need to understand the strengths and weakness of your network so that you can properly deploy Windows 2000 without disrupting network activity or bringing it to a standstill. This knowledge will help you determine your mix of over-the-network deployments and desktop installs.

Understand how changing the operating system on the desktop affects the network environment. With Windows 9x, there is no need to authorize a machine to join a domain. With Windows 2000 Professional, however, you need to ensure that the workstation has authorization (using machine accounts) to join the domain. This can be accomplished in several ways, which are discussed later in the guide.

Evaluate how the new operating system and the use of its features will affect the network traffic. Features such as offline folders, and startup, logon, logoff, or shutdown scripts can affect network performance.

Understand how upgrading the operating system could affect the applications you run. Plan to test these applications thoroughly with Windows 2000 Professional during the Test phase.

Checking Compatibility

During the early stages of upgrade planning, it is vital that you conduct an audit of your software and hardware for compatibility with Windows 2000. The audit identifies applications and hardware that need to be upgraded, modified, or replaced. Systems management software, such as Microsoft Systems Management Server, is often able to do this. You can also check the Windows 2000 Product Compatibility site or run either Windows 2000 Setup in a report-only mode or the Readiness Analyzer.

Windows 2000 Compatibility Lists

The hardware and software you plan to use with Windows 2000 should be listed on the Windows 2000 Product Compatibility site. If you are using hardware or software that does not appear there, you should contact the vendor to determine the availability of Windows 2000-compatible versions or updates. You may also find that the hardware or software is compatible but has simply not been tested. Confirm this with your own testing and with the assistance of the vendor.

Ensure that any new hardware or software is compatible with Windows 2000.Consider making this one of the criteria that your purchasing department uses when making buying decisions.

The Readiness Analyzer

The Windows 2000 Readiness Analyzer tool analyzes your system and reports potentially incompatible hardware devices and software applications. The tool compares the devices and applications on your system against a list of known incompatibilities. This check occurs during Windows 2000 Setup, but you can download and run the tool before installing Windows 2000 n order to help ensure your installation will succeed. The Readiness Analyzer is a way to check all systems without having to have a copy of the Windows 2000 CD available, and it can run off two floppy drives if necessary. It can be downloaded from the Windows 2000 Readiness Analyzer site.

Note: The Readiness Analyzer is designed primarily for use on individual PC's. However, the tool can be used as part of an automated process to gather Analyzer results from multiple PC's in an enterprise, as described below.

Checking Windows 9x Systems

To determine compatibility, look up the components on the Microsoft Hardware Compatibility List (HCL). The HCL includes all the hardware that Microsoft currently supports. If your hardware is not on the list, contact the vendor to find out if there is a driver. If your components use 16-bit drivers, you need to obtain a 32-bit driver.

You can also use Windows 2000 Professional Setup to check for hardware compatibility. Run Setup in check-upgrade-only mode to obtain log files that indicate hardware and software incompatibilities and device drivers that need to be updated. The command line format for check-upgrade-only mode is as follows:

winnt32 /checkupgradeonly

When run under Windows 9x, Windows 2000 Setup can save the generated report to a central location. To do this, use the following command line:

Winnt32.exe /unattend:answer_file

where answer_file is the fully qualified file name of a minimal Windows 2000 Setup answer file. An example of a minimal unattended answer file is below. The output of the generated report is saved to the fully qualified name of the report_file.

[Unattended]

Win9xUpgrade=yes

[Win9xUpg]

ReportOnly=Yes

SaveReportTo=report_file

Report_file is the fully qualified file name of the report file to generate. Note that you can use %computername% anywhere in the path. Windows 2000 Setup expands this to the computer name of the system where the upgrade check is being performed. For example:

SaveReportTo=\\server\share\%computername%.txt

When Windows 2000 Setup is run on a system with the computer name “Caroline”, this generates a report file whose fully qualified filename is \\server\share\caroline.txt.

If the answer file is not provided, Windows 2000 Setup saves the compatibility report to a file called Upgrade.txt in the Windows directory of the local hard disk. Note that Setup can only check for known incompatibilities. You should test all of your programs to determine if they are compatible with Windows 2000, regardless of the specific output of the report. The check cannot verify the compatibility of all applications because it only knows about compatibility issues from the limited database the report is generated from. The report is a useful planning tool and an aid to identifying compatibility issues that have been identified from Microsoft's current Windows 2000 compatibility testing.

Note: When Windows 2000 Setup is started in a report-only mode, the user cannot continue with the upgrade or installation.

LitWare’s Design and Planning Decisions

After using a lab environment to test and learn the features of Windows 2000 Professional, our example company LitWare has developed its deployment goals, which are as follows:

• Increase user productivity by taking advantage of the better performance, improved usability, and advanced feature set of Windows 2000 Professional.

• Prepare the environment for Windows 2000 Active Directory services and ease of administration.

• Use the upgrade as a chance to standardize their desktops’ hardware and applications across both locations.

The Microsoft compatibility lists have been checked against the inventory of hardware and software. The winnt32.exe /unattend:answer_file option has been run on all systems, and reports were generated and stored centrally. Non-compatible hardware and software have been recorded. A plan for these systems has been created to bring them up to specification.

The ten multi-boot desktops in the development department will have the hard drive partition formatted, and Windows 2000 Professional will be installed clean. All the tested applications will be reinstalled.

Testing

Like the planning and design phase, the testing phase may require many iterations. You will need a scaled-down version of the production environment. The test phase is the first opportunity for administrators to evaluate changes and additions to Windows 2000 Professional.

First you will need to develop a testing strategy. The testing strategy/plan can make or break a deployment. The goal is to mirror the production environment as closely as possible. This will allow you to test extended server functionality as well. Design the client computer lab so that you can test the functions and features you use in your production environment. Include the same mix of client computers, servers, printers, peripherals, applications, and network configurations in your testing environment.

If you plan to have a phased client rollout, include the same mix that will occur during rollout. For example, have client computers with Windows 95 and client computers with Windows 2000 Professional.

This section covers some considerations for designing a lab to test Windows 2000 Professional. The issues presented here might not apply to every Windows 2000 Professional implementation.

Hardware Compatibility

Include at least one client computer for each vendor and model that is to run Windows 2000 in your production environment. If your organization uses laptops, docking stations, or port replicators, be sure to include those vendors and models as well. Include a representative sample of the types of peripherals used in your production environment. For example, include the same types of printers and scanners, along with their associated drivers

You will need to determine if your existing hardware base will present any problems. Ensure that all the computers meet the minimum requirements for running Windows 2000 Professional. There may be incompatibilities with some older hardware. For example, some hardware requires an update BIOS for the system to run properly or to take advantage of new features in Windows 2000 Professional. You will want to be aware of these issues and either contact the hardware vendor or manufacturer for the correct drivers or replace some hardware before performing the upgrades.

It is recommended that you develop a standard hardware configuration for Windows 2000 Professional as part of your deployment project. Your lab testing can help you define and refine a standard configuration. As you define hardware configurations, verify that the components are compatible with Windows 2000. For example, you might need to verify compatibility for the following components:

• Universal serial bus (USB) devices and peripherals

• Compact disc (CD) and digital video disc (DVD) drives

• Sound adapters

• Network adapters

• Video adapters

• Mass storage controllers (SCSI, RAID)

• Removable storage devices

• Input devices (mice, trackballs, tablets, and so on)

Application Compatibility

This may include commercial and custom applications.

The goal of your application testing is to verify that everything that works on your current platform also works on Windows 2000. If an application was written for a previous version of Windows, it may not utilize new Windows 2000 features, but it should still function as designed.

You should always test applications in your environment even if they have already been tested by the manufacturer and said to be compatible. Focus your testing on the way your organization uses the applications and test configurations that your organization uses, features that are frequently used, and combinations of applications that are used together.

For more specific Information please see the Application Migration sections later in this guide.

Upgrade Testing

After you determine and resolve the hardware and application compatibility issues, you can then move on to testing the upgrade of the operating system. Several areas need to be evaluated and documented during this phase.

The first is the feasibility of automated upgrades relative to manual upgrades. If your hardware is standardized, it will be much easier to create an automated installation. If the hardware is very mixed, such as with LitWare, Inc.’s Denver site, manual installs may be more feasible due to complexity of testing and the many variables involved with creating unattended installs for mixed hardware.

You should have 2 phases of component testing. One with installing all of the components of the operating system, even ones you don’t plan on implementing. Use this to test the load signature to ensure that the workstations can handle the functions of the operating system that you may decide to implement in the future. Baseline the client disk space footprint and performance for all components for the operating system. This allows you to understand what you will need to do in case you implement additional features in the future.

The second, installing only the components of the operating system you plan on implementing. Use this to test the load signature to ensure that the workstations can handle the functions of the operating system that you currently plan on deploying. Baseline the client disk space footprint and performance for these components. This allows you to understand what you will need right during the deployment.

For more specific testing information please see Part 6 of the Deployment Planning Guide.

LitWare’s Testing

LitWare has chosen to test all four standard desktops from the Seattle site as well as three of the most common desktops from the Denver site. All standard hardware and software applications will be tested. Testing of custom applications will be conducted with the participation of the application developers and the technical and business leads for the applications. This will ensure that the application functions properly before the upgrades are deployed.

All installations will rely on user education, corporate help desk, and local computer technicians. The users will be educated about the entire process during roundtable discussions and by e-mail explaining the process, support procedures, and timeframes.

Automated upgrades using an unattend.txt file will be conducted at the Seattle site because the desktops there are all standardized. Due to the complexity of trying to create an unattended installation for the mix of diverse hardware at the Denver site, Windows 2000 will be installed manually at the Denver site. All installations will be using distribution servers that limit access to a predefined number of users depending on the network bandwidth saturation.

Testing has determined that all the standard 32-bit applications work properly as installed. If not, vendor-supplied migration DLLs resolved any issues. The custom application that was using VxDs will be replaced with a newer 32-bit version after the upgrades.

Piloting

The pilot phase is the “proof of design” time in your deployment This is when you take your designed Windows 2000 Professional deployment and put it through a scaled-down, real-world testing.

For this phase, you should target a small number of users in a controlled environment. Use at least one site and try to target 30-60 clients, depending on your real environment. Perform normal operational tasks and implement procedures in the same way that they will be used in the production environment.

Use the same policies for all problem resolution and management tasks in the pilot as you use in the production environment. Evaluate procedures constantly and adjust as needed. Involve all relevant groups in the pilot, including change control, escalation management, and so on.

Finally, create a team environment. Pick sympathetic users for the pilot and keep them involved because you will need their feedback and cooperation. Give thank you gifts (such as shirts) as a “feel good” measure. Most important, be honest with the users—warn them that things may not go perfectly.

LitWare’s Pilot

The pilot LitWare has created consists of 10 carefully chosen desktops at the Denver site and 40 desktops at the Seattle site. The desktops were chosen as a representative sample to try to cover the majority of possible desktops in the environment. There is a support team at each location to educate and support pilot users throughout the upgrade.

Production Deployment

This is the time to take all your knowledge from the pilot and adjust your design to reflect what you learned. It is very important to ensure that everything goes as smoothly as possible. During this phase, e-mail should be sent out to all parties involved in the rollout to keep them apprised of timelines and possible disruptions. Likely parties include user support, network management, systems management development, and server maintenance and design staff, among others.

The steps for final deployment are very similar to those for pilot deployment. To ensure a smooth upgrades of all your desktops during full-scale deployment, you must set up the distribution servers, if used. You must also notify the users of the upcoming installation, train them on Windows 2000 Professional, and customize the user installation scripts. If needed, upgrade the hardware on the client computers, and remove any software that doesn't comply with company policy. Always back up critical data and configuration files on the client computers. Furthermore, you must make sure that the client computers are fully operational and the network is running, and conduct virus scan, disk scan, and hard-disk defragmentation as required.

Pre-Upgrade Check List

Carry out these steps prior to upgrading to Windows 2000 Professional.

1. Scan your current system for viruses

You should be running a virus scan on a regular basis already. Run your virus checker again before upgrading to be certain that there are no infected files on the computers. Be sure the virus checker has the latest updates, and set it to check all files on the computer.

2. Back up all files

As a safety precaution, you should back up all files on your hard disk before you install a new operating system.

3. Close all applications and disable any virus scanning software

It is always safest to ensure all applications are closed down before the upgrade process begins.

Upgrade Process Walktrhough and Flowcharts

Walkthrough

The Windows 9x upgrade process can be run in either attended or unattended modes on a working Windows 9x installation. When deploying Windows 2000 Professional across a company-wide network, you should consider using the automated installation methods that are supported by Windows 2000 Professional.

An upgrade of any operating system involves moving user and system settings from the current installation to the new operating system. Since Windows 9x and Windows 2000 are very different operating systems, the upgrade process must determine what is installed on Windows 9x and then attempt to upgrade known pieces of the system and move directories or registry information to their proper locations on a Windows 2000 system. As a result of this, the upgrade process will have two main phases: a Report phase and a Setup phase.

In the Report phase, setup gives the user a chance to provide third-party migration DLLs and files that fix installed applications and devices that would otherwise not work with Windows 2000. It then scans the Windows 9x system for all installed applications and devices, noting incompatibilities with Windows 2000, and scans the current installation for all user accounts on the machine, including the default user account. Next, it presents a report on device and application incompatibilities to the user. If the user has any more migration DLLs, he or she will have to re-start WINNT32.EXE in order for the DLLs to be processed. Then, setup creates an answer file that is used during the setup phase of the upgrade process, installs the Windows 2000 boot loader and copies Windows 2000 installation files to the local hard disk.

The machine reboots after this initial information and report phase is completed. The second phase, Setup, then commences. It has two parts—Text mode and GUI mode.

In the Text mode phase, Setup installs a base Windows 2000 installation to the same directory as the previous Windows 9x installation. This is usually the C:\Windows directory. The target directory cannot be changed during an upgrade. Then the Windows 9x registry files and profiles are moved to a temp directory (%windir%\setup\temp).

The system then reboots into the GUI mode phase. Here, Setup migrates the settings that were saved from the Windows 9x system to the Windows 2000 registry. Next, it executes application migration using migration DLLs provided in the Windows 9x phase of the process and migrates all user accounts from the Windows 9x to Windows 2000.

The upgrade process is now complete.

Windows 9x Portion

[pic]

Windows 2000 Portion

[pic]

Upgrade Process Migrations

There are many facets to the upgrade process. The two that you should be most familiar with are application migration and the way that the Windows 2000 upgrade process deals with user accounts and profiles. Having a full understanding of these will better prepare you for testing for your network environment.

This section will assist you in understanding the migration process for different situations and also give you a baseline for checking against your own testing.

User Account and Profile migration

All user accounts and non-roaming profiles on the Windows 9x installation will be migrated to Windows 2000. This will involve moving each user’s registry and profile information to the Windows 2000 system according to rules described below.

CASE 1

If the default user account on Windows 9x has never been accessed or used, the upgrade process will NOT move the Windows 9x default user settings to Windows 2000 default user settings.

CASE 2

If the user who installed Windows 9x hit the ESC key at the first logon prompt, users on the machine are not presented with the log-on prompt on subsequent startups of the machine.

This implies that all users on that machine share the same registry and profile information based on the Windows 9x default user configuration. This default configuration (including registry and profile settings) will be migrated to the Windows 2000 Administrator account and default user settings to ensure desktop and system consistency after the upgrade.

CASE 3

If the user who installed Windows 9x did not hit the ESC key at the first logon prompt, the log-on prompt will be presented on subsequent boot-ups of the machine.

Skipped Logon Process (using the ESC key)

If the user accesses the Windows 9x system by skipping the log-on process, the user’s registry settings are stored in the default user configuration on Windows 9x.

When you upgrade, the default Windows 9x user profile is retained as the default Windows 2000 profile. If you do not want to use the default Windows 9x user profile as the default Windows 2000 profile, you can use an Unattend.txt file to disable this behavior. If you do this, Windows 2000 builds its own default user profile (as if you had not upgraded from Windows 9x).

To use the Unattend.txt file, use the following syntax in the file:

[Win9xUpg]

MigrateDefaultUser=no

For more information, see the MS Windows 2000 Unattended Setup Parameters Guide.

Log on as clients of a Microsoft network

If users log on as clients of a Microsoft network (with name, password, and domain), they may have the same preferences and desktop settings or different preferences and desktop settings.

For users with the same preferences and desktop settings, the upgrade moves common registry settings to the default registry for Microsoft network client accounts on Windows 2000:

• The %windir%\Start Menu profile is moved from Windows 9x to %windir%\Profiles\All Users\Start Menu on Windows 2000.

• The %windir%\Desktop profile is moved from Windows 9x to %windir%\Profiles\All Users\Desktop on Windows 2000.

For users having different preferences and desktop settings, the following will be left alone:

• %windir%\Profiles\\Start Menu.

• %windir%\Profiles\\Desktop.

The Microsoft network client account registries will be moved to their Windows 2000 equivalents.

The Machine account (in the domain) will need to be created during setup or created prior to upgrading. If the machine account is not available during setup and the machine is joined to a Workgroup rather than to a Domain the previous Domain user settings are lost.

Log on as Workgroup clients or clients of a non-Microsoft network

If the users log on Workgroup clients or clients of a non-Microsoft network (with name, password), they may have the same preferences and desktop settings or different preferences and desktop settings.

For users with the same preferences and desktop settings, upgrade will migrate common registry settings to the equivalent local accounts registries on Windows 2000.

• The %windir%\Start Menu profile is migrated from Windows 9x to %windir%\Profiles\All Users\Start Menu on Windows 2000.

• The %windir%\Desktop profile is migrated from Windows 9x to %windir%\Profiles\All Users\Desktop on Windows 2000.

If users have different preferences and desktop settings the following will be left alone:

• %windir%\Profiles\\Start Menu.

• %windir%\Profiles\\Desktop.

Installation Directory

During an upgrade, there is no option to specify the installation directory. Windows 2000 will be installed in the same directory where Windows 9x was installed. For example, if Windows 95 is installed in c:\windows and this installation is upgraded to Windows 2000, Windows 2000 will also be installed in c:\windows. The TargetPath key in the [Unattended] section of the answer file is ignored.

Machine Accounts

Unlike Windows 9x, Windows 2000 computers that are to participate in a Microsoft network domain require a machine account on that domain.

There are three ways to create machine accounts for Windows 9x computers being upgraded to Windows 2000. The preferred method is to create the machine account on the domain before the upgrade is performed. Other options are to create the machine account during the winnt32 phase of Setup and create the machine account after the upgrade has been performed. Each of these three methods can be done manually or automatically.

Creating Machine Accounts Before Performing the Upgrade

Domain administrators can create machine accounts manually through the Server Manager administration tool on a Windows NT or Windows 2000 domain server. Since this could be an extremely time consuming process for anything more than a few computers, it is usually preferable to automate this process.

Using the Active Directory Services Interface (ADSI), a script or utility program can be written to extract the computer names and domain names from the database and automatically create the machine accounts.

For more information on how to automate the process using ADSI, see the ASDI FAQ.

Creating Machine Accounts During the Upgrade

A machine account can be created during the upgrade either by specifying the domain to join in the unattended answer file, allowing the user to provide the necessary information, or using the Netdom Resource Kit utility in a run-once command line.

The disadvantage of all three of these methods is that a user name and password for an account that has permissions to create machine accounts is required. In the case of using the answer file or automating the Netdom utility, these names and passwords could be stored centrally. In any case, you should consider the security implications of storing these details in a file or allowing users to create their own machine accounts.

If you supply a domain account and password in the unattended answer file, Setup will automatically remove these from the local copies of the answer file left on the computer after the upgrade. It may therefore be acceptable to create a special account for your upgrades and remove this account once the upgrades are completed.

Creating the Machine Account after Setup has Completed

If a machine account is not created before or during the upgrade, the computer will not be able to join a domain. Instead, it will join a workgroup. This process can be controlled using the unattended answer file. A domain does not authenticate users logging onto a Windows 2000 computer in a workgroup. Rather, they are authenticated by the computer’s local or workstation domain using a user account local to the computer. To gain access to domain resources, users will have to explicitly authenticate themselves to the domain using their domain account. One of the great advantages of the domain model is that a single logon can be used to authenticate users to the local computer, the logon domain (the one containing the users domain account) and any domains that trust the logon domain. In this way, users can be granted seamless access to multiple resources across several domains.

Application Migration

Application migration is a key factor in determining the success of the Windows 9x to Windows 2000 upgrade project. The upgrade process provides mechanisms for 16-bit and 32-bit applications to be successfully migrated.

Usually, no extra work is required to migrate 16-bit applications that do not make Windows 9x specific function calls while running. In the case where a 16-bit application uses VxDs or makes direct hardware calls, the application will not run properly under Windows 2000. These applications will need to be replaced with Windows 2000-compliant applications.

Some 32-bit applications will require some work in order to run on the upgraded systems. This is because these applications often write to different registry locations on Windows 9x and Windows 2000 (registry values may also be different). Also, they install different files (DLLs, EXEs, and so on) on the two operating systems, install different versions of files that are common to both Windows 9x and Windows 2000, and make operating-system-specific calls on Windows 9x that are not available on Windows 2000.

For applications that exhibit any of the above listed behaviors, a Migration Extension Interface is provided so vendors can write migration DLLs that correct any of the above listed behavior.

NOTE: Applications that rely on incompatible components (for example real mode components) are NOT supported, since these components are not available on Windows 2000.

Migration Extension Interface

The Migration Extension Interface is an extension to the Setup API that enables you to ensure that custom application will operate correctly after Windows 2000 is installed over Windows 9x. To make use of the Migration Extension Interface, you must write a migration DLL (Migrate.dll) that the Setup program can use to make the necessary changes. Vendors should provide these DLL third-party applications. Some migration DLLs are also included with Windows 2000.

Overview of Migration DLL’s

Migration DLLs provide a mechanism for Windows 9x installations to be upgraded to Windows 2000. These DLLs migrate users and application settings over to Windows 2000 as part of the upgrade process.

In theory, this upgrade process should be simple and straightforward: the user accounts are created, application registry systems are migrated to the Windows 2000 registry, and all 32-bit executables are moved to the \system32 directory from \system. In reality, there are a number of applications that perform functions specific to Windows 9x and of applications that install differently under Windows 9x or Windows 2000.

You might have to create migration DLLs for custom in-house applications. You can find more information about creating and testing migration DLLs by searching the MSDN Library using the keywords "migration DLL."

Deployment Methods

Manual Upgrades

In many cases, a manual upgrade is necessary; for example, on an isolated, computer that is not connected to a network or because of the complexity of testing scenarios due to a diverse mix of hardware or applications

In such cases, an organization can use the Setup Manager Wizard to create a partially automated install with manual intervention; send a technician to each desktop and run the installation from a CD-ROM drive or network share; or educate the users on how to install the software from CD-ROM or a network share.

The type of installation can affect the way the desktop runs. In addition, the computer may need to be reconfigured, which may take extra time. It is recommended that you use the Setup Manager wizard and answer files to automate as many items as possible. This is discussed in more detail in the next section.

Automated Upgrades

Automated Deployment Methods

Windows 2000 Professional supports automated installation scripts, disk-imaging (duplication), remote installation, and electronic distribution using the Systems Management Server (SMS). Below we will briefly discuss automated installation scripts.

Automated Installation Scripts

Any well-designed automated upgrade saves time and resources by removing the need to visit each desktop, and eliminating the users’ need to answer questions during installation. The easiest way to create an automated installation script is to use the Windows 2000 Professional Setup Manager. This is a comprehensive, wizard-based tool that guides administrators through the process of creating custom setup scripts. Administrators can use Setup Manager to set many of the answer file parameters that fully automate the setup process. Automated installation scripts consist of an Unattend.txt file and, if needed, a Uniqueness Database File (UDF) file and cmdlines.txt file. These files are used to answer the normal setup questions you would see during a manual upgrade and to customize settings for your network environment and each specific computer. They are also used to run commands that the GUI mode executes when installing optional components, such as applications that must be installed immediately after the upgrade.

Some of the features that are automated using the Setup Manager wizard include:

• Setting the level of user interaction.

• Creating answer files that can be used to automate the installation of Windows 2000 on multiple computers.

• Extracting the configuration information from a pre-configured system into an answer file. This can then be used to replicate that configuration on other computers.

• Creating a distribution share point for network installations. In addition to the Windows 2000 installation files, this network installation share can contain additional applications, drivers, and additional commands to run at the end of setup, and other custom components, as specified by the system administrator.

Answer files can contain many settings, for example, default user information and desktop look-and-feel, network adapter, video adapter, and Internet Explorer 5 settings.

For a detailed explanation of unattend.txt settings please see the Deployment Planning Guide.

When you set up a large-scale unattended upgrade, adding a unique ID for every user is difficult because unattended.txt refers to one user. However, you can use a (UDF) to merge into or replace sections of the answer file for the GUI section of a software installation. UDFs are ASCII files that you can easily modify using a simple text editor such as Edit, which you run at a command prompt. You can break down a UDF into a UniqueIDs section and a section for each UniqueID parameter that the file specifies. The UniqueIDs section identifies each unique ID you want the answer file to include and the sections of the answer file that the UDF will merge into or replace. The UniqueID parameters sections define the specific data that the UDF will place in the answer file.

Listing 1 is an example of a UDF.txt. UDF.txt is a UDF with two unique IDs: Bob1 and Bob2, each of which has three sections: Userdata, GuiUnattended, and Network, that will merge into or replace the corresponding sections in Unattended.txt. First, UDF.txt defines the unique IDs and unattended.txt sections that it will provide replacement data for. Next, UDF.txt provides the replacement data. Each UDF.txt section begins with the unique ID, followed by a colon and the unattended.txt section name that the UDF.txt section's data refers to. The UDF merges these parameters into Unattended.txt, rather than replacing unattended.txt data, because these parameters aren't in the unattended.txt file. If the parameters already existed in the unattended.txt file, which Listing 2 shows, the UDF parameters would replace the Unattended.Txt's existing parameters.

Listing 1: UDF.txt

[UniqueIDs]

Bob1 = Userdata,GuiUnattended,Network

Bob2 = Userdata,GuiUnattended,Network

[Bob1:UserData]

FullName = "Bob Smith"

ComputerName = "Clyde1"

[Bob1:GuiUnattended]

TimeZone = " (GMT-06:00) Central Time (US & Canada)"

[Bob1:Network]

JoinDomain = "BobsDomain1"

[Bob2:UserData]

FullName = "Ian Smith"

ComputerName = "Clyde2"

[Bob2:GuiUnattended]

TimeZone = "(GMT-04:00) Pacific Time (US & Canada)"

[Bob2:Network]

JoinDomain = "BobsDomain2"

Listing 2: Standard unattended.txt Parameters

[Unattended]

OemPreinstall = yes

OEMSkipEULA = Yes

Method = "express"

NoWaitAfterTextMode = 1

NoWaitAfterGUIMode = 1

FileSystem = ConvertNTFS

ExtendOEMPartition = 1

ConfirmHardware = no

NtUpgrade = no

TargetPath = * ;defaults to C:\winnt

OverwriteOemFilesOnUpgrade = no

KeyboardLayout = "US-International"

[GuiUnattended]

OemBlankAdminPassword = 1

[UserData]

OrgName = "Smith Consultants"

ProductID = "111-111111"

[Network]

DetectAdapters = DetectAdaptersSection

InstallProtocols = ProtocolsSection

Merging this UDF file and the unattended.txt file requires command-line switches. The following switches work with winnt.exe or winnt32.exe:

• /u specifies the name of the answer file

• /s defines the NT source

• /udf determines the UniqueID and the local name of the UDF

The following example shows how to start an unattended NT installation using a UDF and the unattended.txt file:

winnt32 /u:unattend.txt /s:h:\ /udf:Bob1,h:\udf.txt

As you can see, a UDF file contains all the parameters that are unique to an individual, and the unattended.txt file contains statements common to every user. If no UDF file is specified, Setup prompts you to insert a disk that contains the $Unique$.udB file.

For more advanced Windows 2000 setup information, see Chapter 6 of the MS Windows 2000 Preview Guide.

For more information regarding automated deployment, please see the unattend.doc and the deptool.chm files on the Windows 2000 Professional CD under the support\tools directory in the deploy.cab file. This file will provide you with all the upgrade parameters and options needed for creating an unattended upgrade of the operating system.

Summary

Windows 2000 Professional is the most advanced Windows operating system ever. It is an outstanding operating system designed for the business user who is concerned with speed, reliability, and security. It is built on the Windows NT code base providing the best desktop and mobile operating system for businesses of all sizes.

After upgrading from Windows 9x to Windows 2000 Professional in the business environment, you should benefit from increased reliability and stability, improved manageability and ease of use, and enhanced support for mobile users and new devices.

Related Links

For the latest information on Windows 2000 Server, check out our Web site at



and the Windows 2000/NT Forum at

Windows 2000 Web Site Resources

Exploring Communications & Networking Services

Windows 2000 Planning and Deployment Guide



................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download