* Verify software compatibility. Some programs will run under the new
operating system but will cause an installation to fail if they run during the
upgrade. For example, many virus-checking terminate-and-stay-resident (TSR)
programs run after you install Win95, but you need to stop or remove them before
you upgrade. Some TSRs are incompatible with Win95, but Win95 Setup will remove
these TSRs from Autoexec.bat. Also, several applications are not compatible with
Win95. Determine software incompatibilities before you run the upgrade. You can
ask software manufacturers whether they have released an upgrade.
To help you verify incompatible applications and TSRs, check out the
programs.txt file included with Win95. Tip: When upgrading WFW to NT
Workstation, having 32-bit file access and disk access enabled will cause NT
Setup to hang. To disable 32-bit file access, edit the system.ini file and
comment out the following lines from the [386Enh] section:
device=vfat.386
device=vcache.386
To disable 32-bit disk access, edit the system.ini file and comment out the
following lines from the [386Enh] section:
device=*BLOCKDEV
device=*PAGEFILE
device=*int13
device=*wdctrl
STEP 3
Lab Testing
Ensure that you allocate adequate time, hardware, and people to testing.
Focus on these three areas: automation and unattended scripts, lab testing on
target hardware, and software testing for compatibility.
Scripts. Use the specifications you created in Step 1 to
identify the installation scripts you need to create and test. Ask yourself the
following questions: Do you need to configure an application after you install
it? Can you automate that configuration? Do you need to add or remove any
applications or desktop icons installed by default? Do you want to add your
company logo to the wallpaper? Tip: If you're creating a fully automated
installation script, you can modify the SMS Help Desk Options to enable remote
control by default. See the Microsoft Knowledge Base article Q122399, "Enabling
Help Desk Options for MS-DOS Clients," for details, http://www.microsoft.com/kb/articles/q122/3/99.htm.
You also can establish different
user profiles for different departments.
Target Hardware. Establish a test environment that
simulates your environment with typical target clients and operating systems. If
possible, back up several real clients and restore their images on your test
computers. You can use the clients' specifications to derive a testing goal.
Tip: Don't immediately attempt a fully automated installation. Start by
testing a simple upgrade without customization. Once you achieve basic
functionality, you can add customized scripts or changes.
When testing, you must use the same operating system distribution media
that you will use for the real upgrade. Differences exist between standard
retail versions of an operating system, OEM versions, and special versions that
come with Microsoft Developer Network or Microsoft BackOffice. The special
releases might have setup restrictions that can cause your upgrade to fail. As
testing progresses, write down the test scenarios (client hardware and software
configurations, the batch files or scripts used, etc.) and the results.
Software Compatibility. In the test environment, you need
to upgrade every variant of your clients' operating systems, including any
patched versions. After upgrading the test machines, test every local and
network application. Check for software conflicts, and ensure that the SMS
client components work correctly.
When a software conflict exists, try one of these three options:
* Remove computers with incompatible software from the machine group, and
upgrade them manually.
* Write and run a script that removes or stops the incompatible item before
the upgrade.
* Build separate target machine groups for users with specific needs. For
example, if outside contractors have security restrictions, they can receive a
different installation from full-time employees.
STEP 4
Pilot Testing
A pilot test is a check against lab testing. Even if you achieved successful
test results, you still need to conduct a pilot test. A pilot test establishes a
real production environment with a small set of computers and users.
This test is your first contact with users, and they will introduce a new
set of variables. Try to select technical users and flexible novice users.
Technical users might not cause errors like a non-technical user would, but
these users help identify network challenges, such as servers not responding or
installation scripts not running correctly. Novice users will help you identify
unclear parts of your process.
Choose a variety of hardware configurations, and select a diverse group of
users. For example, you might want to include client configurations you left out
of your test environment testing. You might also decide to have a technician on
site during an upgrade to help with problems.
Last but not least, communication is a vital factor in successful
deployment (e.g., management might need to know that you must install some
client computers manually). Inform users of the SMS logon script processing, and
define Package Command Manager for them. Teach users how to use it and how to
use the other SMS client utilities.
STEP 5
Production
After you have evaluated your pilot results and made any modifications to
your process, you are ready to introduce users to the new operating system and
train them. Limit deployment jobs to 25 clients at a time, rather than all 1000
or so at once. Stop at appropriate places to reassess your results and
streamline your process.
In his review of SMS 1.2 for Windows NT Magazine in May 1997, Tim
Daniels wrote: "You need to realize that SMS is a precision tool: You must
have the proper training and support to get the greatest benefit."
After a successful deployment using SMS, everyone in your organization will
agree. Your users, Help desk staff, and managers will appreciate your careful
planning and the smooth operation of a very complex task.