Using Systems Management Server (SMS) to automate an enterprisewide upgrade to Windows NT or Windows 95 will save you time, resources, and money. And the time gained with automation gives you more time to look after exceptional cases. But the success of your upgrade clearly depends on one key step: planning. Too many times, system administrators cite lack of time and resources as reasons for skipping this step. But the complexity of SMS makes planning mandatory. For a successful deployment, you must have a clear picture of the end result and the steps to get there.
Successful deployment depends on knowing how SMS works, in addition to becoming familiar with the Win95 and NT operating system setup programs. SMS provides the delivery mechanism, and it drives the standard operating system installation routines. To automate an upgrade, you must supply the appropriate setup answer files. For Win95, those files are msbatch.inf, netdet.ini, apps.inf, wrkgrp.ini, automate.inf, custom.inf, and setuplog.txt. For NT, the file is nt4.txt.
Before you begin, you need to know which operating systems SMS lets you upgrade: MS-DOS 5.0 or later, Windows 3.1x, and Windows for Workgroups (WFW) 3.1x to either Win95 or NT. SMS does not allow an automatic upgrade from OS/2, and you cannot upgrade Win95 to NT 4.0. In these cases, you must perform a manual installation.
Networked Windows installations also require special handling. If you have a networked Windows version and want to use SMS to upgrade, consider rolling back to MS-DOS before you upgrade.
If your environment has any dual-boot computers, you must choose the operating system under which you want to install the SMS client, and make that OS your primary one. SMS client functionality will not be available under the secondary operating system.
To ensure successful automation of your new OS rollout, you must plan it carefully. The following five steps are crucial in any SMS upgrade plan. (For more information on planning an upgrade using SMS, see, " References for Planning an Upgrade.")
Identify Client Configurations
Both Win95 and NT allow for multiple configurations. To begin planning an upgrade, you must identify the configurations in your existing environment and identify your clients' optimal configurations. You will use this information for testing and for automating or customizing the setup. Here is a checklist of items to consider:
Setup. Decide the extent to which you let users set up and configure their environments during initial installation. For example, do you want users setting up the Microsoft Exchange mailbox using the Exchange wizard, or do you want to fully automate the setup?
Networking Options. Determine the default protocol (e.g., TCP/IP, IPX). Determine what redirector you will install (e.g., Microsoft Client for Windows Networks, Microsoft Client for NetWare Clients, Novell Client 32). Decide which Services you need to install (e.g., Simple Network Management Protocol--SNMP--Agent, Remote Access Service--RAS, NetWare Client Services).
Security. Note which users have access to their hard disk. (Locked-down workstations will require special consideration, and you may need to upgrade them manually.)
Policies. Integrate current and future policies into your test plan.
Profiles. Establish any user or hardware profiles. (For information on user profiles, see Drew Heywood, "Windows NT User Profiles," September 1997. For information on hardware profiles, see Mike Reilly, "Configuring Hardware Profiles," September 1997.)
Applications. Identify which applications are local and which are remote. What applications run locally on all desktops? What applications run from the server? Do you have applications that require open database connectivity (ODBC)?
After you have considered all these points, use them to create a specification for each operating system and configuration. The specifications need to match your current environment or become a plan for your ideal environment.
Identify Target Computers and Software
An accurate and complete list of target computers (those you want to upgrade) in the SMS database is essential for a successful upgrade. Take the following steps to compile an accurate list of target computers:
* Verify the integrity of the SMS database. Before you query the SMS database for target computers, make sure you have an up-to-date computer inventory. Increase hardware inventory collection frequency to once daily. Use logon scripts to collect inventory at logon or when the user runs runsms.bat. Drop outdated computers from the database. Tip: If the database contains questionable information, you need to delete the site history files (*.hms). You can find these files in sms\site.srv\inventry.box\history. When you delete site history files, you do not compromise the database's integrity; instead, you ensure that complete Management Information Format (MIF) files are passed to the database. (For details about MIF files, see Mark Eddins, "Customizing Systems Management Server," January 1997.)
* Verify hardware compatibility. You can use the SMS query function to list computers that meet the new operating system's minimum hardware requirements and those that do not. At a minimum, your query must identify processor name, amount of RAM, available hard disk, display type, and network card. Also check for client computers that are not on Microsoft's Hardware Compatibility List (HCL). You may want to exclude these computers to avoid potential problems.
* 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:
To disable 32-bit disk access, edit the system.ini file and comment out the following lines from the \[386Enh\] section:
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.
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.
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.