Systems Management Server Deployment Guide for Windows 95 and Office 95

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Acknowledgments

Project Manager:

Tom Vukovic

Technical Advisors:

Denis Atam, Ralf Buchholz, Doyle Cronk, Tom Dodds, Michael Emanuel, Gary Ericson, Larry Gregory, Steven Guggenheimer, David Hamilton, Bryna Hebert, Phil Holden, Sharon Kay, Tom Prisk, Victor Raisys, Ron Rinard, Janet Sheperdigian, Stream International, Adam Taylor, David Van Balgooi, Jesse Vaught, and David White

Editing and Production:

WASSER, Inc.

Welcome

Welcome to the Systems Management Server Deployment Guide for Microsoft® Windows® 95 and Microsoft Office for Windows 95. This book is your guide to using Microsoft Systems Management Server (SMS) to deploy Windows 95 and Office for Windows 95 throughout your organization as efficiently as possible. Systems Management Server is like dedicated staff, helping you with all phases from predeployment inventory through final rollout. With Systems Management Server and this guide, you can reduce the costs of deployment, reduce the time it takes to plan and complete conversion, and reduce the disruption for your end users as you convert to the new system. You maintain control of the deployment process, even as you delegate some responsibilities to end users or secondary Systems Management Server sites. Using Systems Management Server, your organization can enjoy the benefits of Windows 95 and Office for Windows 95 more quickly and with less stress.

Once the new system is in place, Systems Management Server continues to serve you and your end users. Use Systems Management Server to reduce the time costs of every software upgrade and every equipment and software inventory. Use reports generated from Systems Management Server to make effective planning decisions. Also, when users have problems, your Help desk personnel can use Systems Management Server to provide quick and personalized support, without traveling from their own desks.

How to Use This Guide

This chapter lists the conventions used throughout this guide, and lists the product documentation that you should be familiar with in order to successfully deploy and administer Windows 95 and Office for Windows 95 throughout your organization. Parts 1 through 3 include the steps you need to take to deploy Windows 95 and Office 95 using Systems Management Server, as described below.

Part 1, Planning

This portion of the guide includes the first three steps necessary to use Systems Management Server effectively, including studying the products (Step 1); team formation and initial planning (Step 2); and defining the preferred client configuration (Step 3).

Part 2, Testing

This portion of the guide describes setting up the lab, and testing and refining the deployment plan (Steps 4 and 5).

Part 3, The Rollout

This portion of the guide describes the final general steps for deployment, from creating the pilot rollout plan to providing ongoing support to users (Steps 6 through 10).

Part 4, Office for Windows 95 Rollout

This portion of the guide describes rollout procedures specific to Office for Windows 95 using Systems Management Server.

Part 5, Appendixes

The appendixes include special additional information and instructions for specific situations, such as Systems Management Server use for sites using Novell® NetWare®.

Conventions

This document uses several conventions to help you identify information. The following table describes the typographical conventions used in the Systems Management Server Deployment Guide for Microsoft Windows 95 and Microsoft Office for Windows 95.

Convention	Used for
bold	MS-DOS®–style command and utility names such as copy and ping and switches such as /? and -h. Also used for Registry values.
italic	Parameters for which you can supply specific values. For example, the Windows NT™ root directory appears in a path name as systemroot\SYSTEM32, where systemroot can be C:\WINNT35 or some other value.
ALL CAPITALS	Directory names, filenames, and acronyms. For example, ITG stands for Microsoft's Information Technology Group; C:\AUTOEXEC.BAT is a file in the root directory of the C: drive.
Monospace	Sample text from batch and .INI files, Registry paths, and screen text in non-Windows–based applications.

Advantages of Using Systems Management Server to Deploy Windows 95 and Office for Windows 95

Deploying a major software component throughout your organization can be both time-consuming and costly. Microsoft Systems Management Server has features for every phase of the process, from the first inventory to final assessment, that will save you time and money and give you greater control. Whether you are deploying packaged or in-house developed software, Systems Management Server can be viewed as the default platform from which all software can be distributed.

Save Time and Money

Studies have revealed that the majority of costs associated with a software upgrade is manual labor. By automating both the inventory and the delivery process, Systems Management Server can reduce dramatically the time and cost involved in deploying software throughout your organization. Additionally, Systems Management Server has features that address post-installation issues, so support staff can troubleshoot problems and offer help to end users without leaving their own desks.

Cost Analysis

Microsoft's own internal Information Technology Group (ITG) calculated the cost of rolling out Windows 95 throughout its European Operations (targeting approximately 1,000 computers). These calculations provide an example of the savings achieved using Systems Management Server to migrate to Windows 95.

The following chart summarizes the findings from Microsoft's ITG, after using Systems Management Server to conduct the initial rollout of 1,000 computers. The calculations are based on figures derived from the actual rollout of Windows 95 desktops within Microsoft in Europe, covering six countries, as described below.

Microsoft ITG European Windows 95 Migration 1,000-User Rollout

Manual migration	Systems Management Server automated rollout	Time & cost savings
Upgrades	125 person-days • 1 upgrade/hour • 5 technicians • 8-hour day • 40 upgrades/day	20 person-days • 12 upgrades/hour • 2 technicians • 8 hour-day • 100 upgrades/day
Preparation	None	7 person-days (see the following table)
Totals	125 person-days	27 person-days

The following is the basis for the estimated preparation time.

build queries	0.5 person-day
run queries	0.5 person-day
create user groups	2 person-days
prepare INF files	1 person-day
test and adjust package(s)	2 person-days
create the package(s) on the server(s)	1 person-day

Manual Upgrade

Assumptions:

Technicians know Windows 95
Each upgrade takes 1 hour

With these assumptions, each technician can upgrade, on average, eight workstations per day (allowing time to travel between workstations and time for lunch and breaks). It would take 125 person-days to upgrade 1,000 workstations. So, for example, five technicians would take 25 days to upgrade 1,000 workstations, treating each as a special case.

If any of these workstations proved to have unexpected problems, such as insufficient free disk space or an installed application that could cause problems with Windows 95, the installation there would take longer. A few such workstations could throw off the entire schedule.

Upgrade Using Systems Management Server

Assumptions:

Technicians know Systems Management Server and Windows 95
Preparations for using Systems Management Server (preparing and running the queries, building the user groups, creating the package and supporting files, and testing and adjusting the jobs) take about eight person-days
Two technicians should be available to monitor the actual rollout and deal with any questions that arise

With these assumptions, it would take 27 person-days to upgrade 1,000 workstations. Two technicians would take 20 days for the actual installation, compared to the five technicians taking 25 days to upgrade 1,000 workstations manually. Because Systems Management Server is used to inventory all of the workstations shortly before the deployment begins, the chance that any of these workstations will have unexpected problems, such as insufficient free disk space or an installed application that could cause problems with Windows 95, is less likely when using Systems Management Server.

The time savings are more dramatic as the number of computers involved in the deployment increases, because most of the preparation work is the same whether you are deploying to ten workstations or ten thousand. Systems Management Server can easily handle deployments of more than 100 workstations per day, depending on the settings that the administrator chooses for the job. The resources needed to complete the deployment can be reduced accordingly.

When Microsoft ITG prepared for the rollout to its European subsidiaries, it estimated the days required for deployment with Systems Management Server as shown in the following table.

Person-days Required for Deployment: Systems Management Server Versus Manual Installation

Task	10 users	100 users	1,000 users	10,000 users
Prepare INF files	1	1	1	1
Create package	1	1	1	1
Test and adjust	2	2	2	2
Prepare query	0.5	0.5	0.5	0.5
Run query	0	0	0.5	0.5
Build groups	0	0	2	17
Rollout	0.5	2	20	200
Total person days using Systems Management Server	5	6.5	27	222
Total person days for manual installation	1.5	12.5	125	1,250

In summary, if you are deploying Windows 95 to as few as 100 computers, Systems Management Server can give you significant time savings over manual installation. The larger your organization, the greater the time savings. Even in large organizations, a modest increase in technicians to assist with the actual deployment is all that is needed to perform a full deployment in a reasonably short period of time.

Once Systems Management Server is in place, these savings are repeated every time you need to inventory the hardware and software in use and every time you need to deploy software.

Using Systems Management Server for Inventories

One of the functions of Systems Management Server is to collect information from the computers on the network as they log on, storing the results in an SQL database. This inventory can be performed as often as every time a user logs on. Because manual inventories are so time-consuming, they can be out of date almost as fast as they are completed. As a result, the likelihood of attempting to deliver an upgrade to an unprepared computer is much greater with manual distribution than with automated distribution. The manual upgrade may either fail completely or encounters problems that result in a sharp increase in support calls and end-user dissatisfaction. With Systems Management Server, inventories can easily be kept up to date. By performing frequent inventories as the scheduled time for deployment approaches, you increase the likelihood that the computers you target for the upgrade can accept the upgrade.

Queries to the Systems Management Server database are used to identify which computers are candidates for receiving an upgrade. For example, you can query for minimum free disk space and installed memory. You can also query for installed software that might interfere with the software you want to install. You can query the Systems Management Server database just before you create the Systems Management Server job to perform the upgrade to minimize the risk of trying to install the software on a computer that is not capable of supporting it.

With Systems Management Server it is easy to deliver different configurations to different computers. Using the results of a query, an administrator can deliver the appropriate package based on the end user's requirements and the existing configuration of the user's computer.

A post-upgrade inventory and query can identify the computers that were not successfully upgraded, and these special cases can be dealt with proactively.

Minimize Staffing Requirements for Deployment

To upgrade hundreds of computers manually in a reasonable time frame, you will probably need to hire and train additional technicians to perform the predeployment inventory, as well as the deployment itself. With Systems Management Server, a small team can prepare the supporting files and initiate the Systems Management Server jobs.

Systems Management Server lets you perform the deployment either with the staff you already have or in conjunction with an experienced Microsoft Solutions Provider to help minimize the learning curve. Both during and after deployment, technicians and support personnel can use the Network Monitor and Help desk features of Systems Management Server to resolve most issues from their own desks, without physically visiting the target computer.

Minimize Disruption to End Users

A deployment using Systems Management Server is less disruptive to your users than a manual deployment. Users are not interrupted by a predeployment inventory, because this can be done by Systems Management Server when the users log on. Also, Systems Management Server performs the upgrade without the disruption of a visit by a technician. An entire group can be upgraded in a short period of time, so the individuals and the group as a whole are on-line and productive with minimal delay.

Some organizations try to minimize the cost of deployment staffing by having the users perform their own upgrades (also called a "pull" installation). The costs of upgrades performed by users are usually underestimated. If end users are asked to perform the upgrade, they might choose options or set variables during installation that you neither expected nor planned for. Or they might delay upgrading. The mixture of operating systems or software versions that results when upgrades are not performed on schedule can cause problems for workgroups that need to share data or program files.

Automated inventory and automated installation combine to maximize end-user productivity during rollout. Because the end users' time and attention are not diverted to performing or troubleshooting the rollout, their productivity does not suffer during the upgrade.

Maintain Control

With a manual installation, the quality of the upgrade can depend on the skill of the individual technicians. Systems Management Server lets you control the deployment from a central site, even if you choose to delegate some of the work to other sites. You can target exactly which computers are to receive a particular configuration, and in which particular time frame. The results of each job are logged automatically, so you have accurate records. You can also control the percentage of total network bandwidth that the job can consume in site-to-site communications.

Also, the lessons learned during each stage of deployment can be consolidated at a central site. The knowledge acquired during each stage of the deployment process can be incorporated into this record and into the queries and packages used for deployment. This means the information can easily be reapplied or kept for future reference, providing good leverage of resources. In contrast, when you use manual methods with local teams or groups of users, the teams often must reinvent solutions to common problems.

Additional Advantages over Manual Installations

Systems Management Server provides other advantages over manual installations. For example, you can use modified network logon scripts to initiate the upgrade. With Systems Management Server, deployments via logon scripts can be timed to minimize disruption to the network. Upgrades can be timed either so that only a few are performed at one time or so that they occur after hours, when the network is relatively quiet. For example, delivery of an upgrade package can be set to minimize the impact on the network by scheduling the delivery after general business hours. In a manual installation triggered by logon scripts, you cannot ensure the timing of upgrades, other than as the users log on. The result can be an excessive load on network when the bulk of users log on.

Once an upgrade is performed manually, troubleshooting and support also must be done manually, usually involving a visit to the end user's computer. Systems Management Server includes features for remote diagnostics and Help desk support. With the user's permission, support staff using Systems Management Server can even take remote control of the client computer.

After you've used Systems Management Server once, you are prepared for future upgrades and deployments with features such as automated inventory and package distribution. This is true whether the upgrade is a packaged piece of software, such as Microsoft Office Professional, or an in-house product. If deployment is done manually, the entire process must be repeated every time an upgrade is required.

Features for Every Phase of Deployment

Whether you deploy an operating system or a major software package, you need to proceed in an orderly manner. Systems Management Server has features to help you with every stage of the process, from gathering information about your existing configuration, through planning and testing, to final deployment and post-deployment analysis.

Before Deployment

If you use logon scripts, Systems Management Server can automatically maintain an up-to-date inventory of your installed hardware and software in an SQL database. You can query this database to produce a list of the computers to receive each configuration or to produce a list of the computers that will need a hardware upgrade before the new software can be installed. The Systems Management Server database can also serve as a data source for reports generated using Microsoft Access, Microsoft Excel, or other ODBC-compliant front ends.

During Deployment

Once a Systems Management Server package has been created with the exact installation parameters you want to use, you can create a job to deliver the package from a central location in a timely and efficient manner. That job can perform the installation or upgrade you specify on hundreds or thousands of computers (you choose the target computers when you create the job). Because the package you create and test in the lab can be used in your actual deployment, the chances of introducing an error as you go from the lab to your production environment are minimized.

This guide comes with information files for Windows 95 and Office for Windows 95, and package definition files for use with Systems Management Server that you can use to get a head start on creating the package or packages you want to use in your own organization. The Job Status, Network Monitor, and Help desk tools allow a small team of technicians to monitor and troubleshoot the upgrade of a large number of computers.

After the test deployment in the lab, the pilot deployment, and the full rollout, you can study the log files and status information that Systems Management Server creates as it performs each job. They will give you accurate data to use in refining your deployment plan every step of the way. Your full rollout of Windows 95 and/or Office for Windows 95 can be much smoother than it would be without this information, and every software deployment in the future can be well ordered and controlled.

After Deployment and During Daily Operations

In daily operations, use Systems Management Server features such as Network Monitor to identify and resolve network traffic problems. Use Help desk features to let your support personnel view the screen of a user with a problem from their own desks and even (with the user's permission) take over the screen remotely to adjust a configuration or perform a quick tutorial. Use the Systems Management Server inventory and query features to maintain an accurate inventory of the hardware and software in use in your organization. You can compare this against your list of licensed software as often as needed and also use it to identify obsolete equipment. Maintain the health of your computing environment by using Systems Management Server jobs to run regular virus checks on all of the computers that log on to your network.

As you become familiar with Systems Management Server, you will find other ways that it can reduce difficult tasks in your computing environment to routine chores.

Summary

As we have seen, Systems Management Server can drastically reduce the cost of software deployment in a wide variety of organizations. By reducing the manual labor involved in deployment, Systems Management Server targets the area that can lead to substantial cost benefits. Additionally, after the deployment has been completed, Systems Management Server can be used to significantly reduce the effort required to support computer networks.

Manual upgrades can be expensive not only in terms of direct dollar costs but also in terms of end-user dissatisfaction and lost productivity. The features built into Systems Management Server let you minimize the direct and indirect costs that are inevitable in manual deployments.

Overview of the Deployment Process

Updating an operating system or critical application suite throughout an organization must be done in a controlled and well-managed manner, regardless of the tools used to do the job. It involves careful planning, testing, and scheduling.

This chapter outlines the steps in this process. The remainder of this guide provides details for executing each step.

Ten Steps for Deployment

These steps are guidelines, not inflexible rules. Be sure to identify and respond to the particular needs of your organization.

Study the products involved in the rollout. At the end of this step, you should have a high-level appreciation of the products and processes involved in the rollout.
Form the team and draft a high-level project plan. This step involves gathering the resources, including equipment, software, and staff, to properly plan for testing and evaluating Windows 95 and Office for Windows 95. Members of the support team should receive training during this step.
Define the preferred client configurations. Completing this step should give you a good idea of what features of the new software you want to use in the organization as a whole or in specific departments. You should have an understanding of what features you want to implement and which hardware and software will be required to support the software you want to install. This is also the time to decide whether to install Windows 95 and Office for Windows 95 at the same time or to install Office for Windows 95 separately, after you have completed deployment of Windows 95. For example, if you want the features of Office for Windows 95, you must also install Windows 95, either before or during your deployment of Office for Windows 95.
Set up a lab to test the rollout. This step involves setting up a simulated environment that reflects the makeup of your present network environment. Always include your weakest or slowest network link in the test. For example, if your enterprise network contains two sites communicating over a 56K link, make sure to test for deployment over a 56K link. The process of setting up the lab will allow you to train your technical staff in the products and procedure used for the deployment. The technical staff can become aware of the special considerations of your organization's computing environment, without the pressures of the production environment.
Test the rollout in the lab. Use this step to identify any special considerations presented by the configurations of the target computers in your organization and to fine-tune your deployment to accommodate them in the final rollout. Based on what you learn during the test rollout, you might make adjustments to your high-level plan or the preferred client configurations. This step should produce the files and procedures necessary for an automated rollout.
Plan the pilot rollout. In this step, you create a detailed plan for the pilot rollout, based on what you learned in the test rollout in the lab. This step should produce the dates and targets for the pilot rollout, including prerollout training and postrollout evaluation. It's a good idea to involve a central site and a single primary site below the central site.
Conduct the pilot rollout. At the end of this step, the users in your pilot rollout should be enjoying the benefits of the new software, and the deployment team should know which, if any, adjustments need to be made to the plan for the full rollout. In addition to feedback from technicians and users, you can study SMS job status and job logs in your analysis of the pilot rollout. If adjustments are indicated, test them in the lab before proceeding.
Fine-tune the final rollout plan. The final rollout plan is an extension of the pilot planning process, with the added steps of documenting, budgeting for, and carrying out the final logistics. As you perform these steps, you should also update the policies and practices guidelines governing network and computer use in your company. This step should produce the final detailed rollout plan.
Conduct the full rollout. Because of your efforts in the previous steps, this should go more easily than ever before and should conclude with users throughout your organization enjoying the benefits of the upgrade.
Provide ongoing support. SMS is at least as useful in daily operations as in a major software deployment. The Inventory and Query features automate tedious and expensive tasks, and they ensure that you have current information on which to base your decisions. The Network Monitor feature can be used to identify and to resolve network traffic problems. Help desk features, including remote monitoring and remote control, let your support personnel provide "on the spot" support without leaving their own desk. Any commercial or custom application that can be deployed to large groups of computers can be automated, just as you automated the deployment of Windows 95 and Office for Windows 95.

This process is not strictly linear. For example, the information you get by testing the rollout in Step 5 might suggest a change in the high-level plan that was drafted in Step 2. Or the pilot rollout in Step 7 might uncover special situations or erroneous assumptions that are best sorted out by going back to Steps 4 and 5 to test in a lab setup that better reflects your actual organization. A flowchart of the process would look something like the following:

Most of these steps are required no matter how you effect the rollout. For example, you must always have a thorough knowledge of a new application or operating system before you install it throughout your organization. Similarly, to understand how the new software can interact with the software you already have (and how to configure the new software), you need to set up a lab to test your chosen configuration with the existing software. By including SMS in your test environment, you can prepare for a much easier final rollout. Once SMS is in place in your organization, all future upgrades and new software rollouts will be easier. In addition, routine inventories can be continual and automatic. And your Help desk personnel will be able to give better, faster help to more people — without leaving their own desks.