The Rollout

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.

After testing the Systems Management Server (SMS) deployment process in the lab, but before conducting a deployment throughout the company, you'll want to perform at least one pilot rollout. In the pilot rollout, a limited number of users — preferably those most eager to use the new software — are upgraded to Windows 95 and/or Office for Windows 95. The first pilot rollout sets the tone for the final rollout, so it is important to be completely prepared with all aspects of the rollout. You'll need to determine the time it will take for installation, the personnel and tools needed to facilitate the process, and the overall schedule.

Once you've tested the rollout plan in the lab and in one or more pilot rollouts, you are ready for the final deployment of Windows 95 and/or Office for Windows 95 throughout the organization. Your deliverable for this step is a swift and successful deployment with minimum interruption to your users. After the rollout plan has been fine-tuned, focusing on support materials, training, and orientation for the users, you can perform the final rollout. Finally, you will be responsible for providing ongoing support, including more installations and upgrades, Help desk support, and reporting. Depending on your organization and the resources available for deployment, you might prefer to rollout throughout the company either in a single pass or in stages.

On This Page

Step 6: Create the Pilot Rollout Plan
Step 7: Conduct Pilot Rollout
Step 8: Fine-Tune the Master Rollout Plan
Step 9: Perform the Final Rollout
Step 10: Provide Ongoing Support

Step 6: Create the Pilot Rollout Plan

This step involves creating the detailed pilot deployment plan, which will determine how and when the pilot rollout will occur. At the end of this step, you should have a detailed checklist that specifies what tasks are to be done, by whom, and at what time.

The general plan you made in Step 2 probably included a general plan for the pilot rollout. For Step 6, you need to fill in the details. Begin by reviewing the things you learned during the test deployment in the lab. These might dictate adding new steps or skipping steps in the pilot rollout that you had originally planned. This is also the time to check with the users who are slated for participation in the pilot rollout. Make sure that their work schedule would not be disrupted by a rollout at this time. Also, assess their understanding of the products to be deployed and the deployment process.

Your pilot rollout should involve at least two Systems Management Server (SMS) site servers, one being a child to the other. The SMS site for the pilot rollout should have a mix of hardware and software similar to that of the organization as a whole, but the site should not be too large.

Develop Pilot Strategy

The pilot deployment can be used not only to test and tune the deployment plan and tools but also to evaluate end-user support and training. It can also be the final deployment for early adopters.

In the pilot strategy, include steps to collect feedback on the effectiveness of the deployment plan. This can include an end-user survey, Help desk call statistics, and/or end-user meetings.

The deployment strategy includes project definition, technical perspective, training, and support. The basic components of a complete deployment strategy are described in the following table.

Deployment Strategy Decisions

Deployment strategy components	Decisions and issues
Functional strategy Affects planning for the remaining phases of the deployment.	Dependent on available time and resources. • How many pilots will be conducted? • How many computers will be in each pilot? • Will deployments be by file-server or by business function? • How many deployments and when? • How many simultaneous deployments? • Who will control the deployment priorities? • What order will user deployments be conducted? Be pragmatic and develop a deployment strategy that you can deliver.
Training strategy Affects the overall deployment strategy, plan, and schedule.	How will users be trained? • Classroom training? • Number of users trained per week? • What alternative training methods?
Support strategy Design and implementation of support strategy must coincide with the deployment.	How will the new environment be supported? Does the existing support model need to be modified for new environment? Does the support staff need training?

Select and Plan Pilots

When a strategy has been developed and approved, the groups to be included in the pilot tests must be selected. Critical selection criteria includes the following:

• Commitment of users and user management to participate in the test. Without user participation, the pilot cannot meet its objectives.

• Pilot groups should be representative of the organization's computing platforms and environments. Special attention should also be given to unique workstation environments. The pilot rollout is your chance to test in the real world the lessons you learned in the lab. If your lab accurately simulated your organization's computing environments, the first pilot rollout should be similar to your final lab rollout.

• It is a good idea to let your users get accustomed to SMS before using it for major work such as a rollout. Some users might be alarmed the first time they log on and see SMS perform tasks on their computers. To save disrupted jobs and calls to your Help desk, make sure that the users know what to expect. Then use SMS for relatively small jobs, such as synchronizing workstations with a time server, before using it for the rollout. That way, the users will be accustomed to seeing SMS at work when they log on, and they may begin to think of SMS as a program that makes things easier for them.

Develop Detailed Project Plans for Pilots

For each planned pilot test, develop a detailed project plan and schedule. Follow the same planning and scheduling guidelines used for the overall project plan, as described under "Develop Initial Project Plan and Schedule" in Part 1 of this guide, "Team Formation and Initial Planning." When developing resource and staffing plans, remember to be realistic. Allow for a learning curve in both the technical staff and the end users.

The following tactics can make the pilot rollout more successful:

• An after-hours rollout can reduce impact to the end users.

• Users should be notified that the rollout is beginning.

• Support staff should be on call to handle user problems and/or questions as soon as possible.

• Procedures to reverse installation and to recover from setbacks should be included in the plan.

During the pilot deployment, keep detailed records of staff and resource usage. This information can be used later to refine the overall project and resource planning for the final rollout.

Staffing

Estimate the number of technicians you will want available to monitor the deployment and provide assistance if necessary. In a complicated deployment, or if you have been rushed in the testing phase, you might want as many as one technician per one hundred workstations.

Using Microsoft Office to Plan Deployment

Because SMS data is kept in an SQL database, you can include the data in reports you generate using Microsoft Access or Microsoft Excel. These reports can be used in scheduling the tasks for different phases of the deployment. Microsoft used this technique when it deployed Windows 95 to its European offices. This section tells you how to do the same in your organization.

By using the SMSVIEW utility included with SMS, you can modify the SMS database on a given SMS primary server so that Microsoft Access can retrieve the information. The steps to modify the database need to be done only once for each SMS primary server. The "hooks" into the database are then built via the ODBC drivers available from Microsoft.

SMSVIEW is installed automatically on the computer used as an SMS primary site server. To start the utility, enter smsview at the command line. The Create Views window appears, as shown in the following screen.

Enter the server name and database name in the boxes provided. Use sa as the login name, and supply the password you have assigned to that account. Leave the Drop Only check box clear, unless you want to drop existing views on the site database.

The first time you run SMSVIEW, it creates views for all groups in the Personal Computer database. If you add new groups later, run SMSVIEW again to create views for those groups. For more information on SMSVIEW, see the Systems Management Server Administrator's Guide, Appendix I, "Using Computer Inventory Information in Other Applications."

ODBC Administrator

To build the "hooks" into the SMS database, run the ODBC Administrator. This will build the links used by Microsoft Access to gain entry to the SMS database tables.

In the illustration that follows, this link, or data source (used by Microsoft Access) is called sms data.

In the following example, the link "sms data" is set up to point to the server SMSEUROPE.

With the links set up, you are ready to build queries in Microsoft Access 2.0 to extract the data. These will be specific to your organization. The discussion that follows describes the process used in Microsoft's ITG Europe.

Using MS Access 2.0 - ITG Europe Example

To build queries in Microsoft Access for the ITG Europe deployment, first a list of "eligible" users at each site was created from a master database. This gave each SMS site administrator a starting point from which to select the users who would receive the upgrade.

The extraction of the data from the data source SMSEUROPE had to be done in three stages. Because of the complex nature of the queries, ITG Europe found it easier to build two "static" tables. These two tables were built within Microsoft Access and contained all user information that met the client selection criteria they had established.

Once these two tables were built, a third stage was used to extract the data that was wholly compliant with the selection criteria. The resulting lists of user names, machine names, and SMS Uid's was then exported to Microsoft Excel spreadsheets for presentation purposes.

The completed Microsoft Excel spreadsheets were then distributed to the SMS primary site administrators for use in the rollouts to their respective sites. The list proved useful in giving the site administrators a starting point from which to build their machine groups. The lists were sent out once a week, to allow the site administrators time to prepare for the next week's likely candidates.

The following illustration shows tables "Imported" from the SMS Database. Please note the tables "Output Part 1" and "Output Part 2."

The following illustration shows the three queries needed to produce the lists. They are discussed in the following section.

The Queries

The query "Target User List 1" was built as a "Make Table Query." It creates the table "Output Part 1" from elements in the following tables.

• dbo_vIdentifaction

• dbo_vOperating_System

• dbo_vDisk

• db0_vProcessor

The fields used, the tables from which they were taken, and the selection criteria were as shown in the following table.

Table	Field	Total	Sort	Show	Criteria
(1)	dwMachineID	Group By	none	Yes	none
(1)	Name0	First	Ascending	Yes	none
(1)	Site0	First	none	Yes	none
(1)	SMSID0	Group By	Ascending	Yes	none
(1)	LogOn_Name0	First	none	Yes	none
(2)	Opertating_System	First	none	Yes	<>""
(2)	Version0	Group By	none	Yes	none
(3)	Free_Storage_MByte_0	Max	none	Yes	Is Not Null
(4)	Processor_Name0	First	none	Yes	<>""
(2)	Operating_System_Name0	Where	none	No	"MS Windows for Workgroups" Or "MS Windows 95"
(3)	Free_Storage_MByte_0	Where	none	No	>=40
(4)	Processor_Name0	Where	none	No	Like "*486*" Or Like "*PENTIUM*"

The query "Target User List 2" was also built as a "Make Table Query." It creates the table "Output Part 2" from elements in the following tables.

• dbo_vIdentifaction

• dbo_vPC_Memory

• dbo_vNetcard

• db0_vNetwork

The fields used, the tables from which they were taken, and the selection criteria were as shown in the following table:

Table	Field	Total	Sort	Show	Criteria
(1)	dwMachineID	Group By	none	Yes	none
(1)	Name0	First	Ascending	Yes	none
(1)	Site0	First	none	Yes	none
(1)	SMSID0	Group By	Ascending	Yes	none
(1)	LogOn_Name0	First	none	Yes	none
(2)	Total_Physical_Memory_KB0	Max	none	Yes	Is Not Null
(3)	Manufacturer	Max	none	Yes	<>""
(4)	WorkGroup0	First	none	Yes	none
(2)	Total_Physical_Memory_KB0	Where	none	No	>=8192
(3)	Manufacturer	Where	none	No	Not Like "*XIRCOM*"
(4)	WorkGroup	Where	none	No	<>""

Once the two tables resulting from these queries (Output Part 1 and Output Part 2) were created, the query "Target Userlist" was run against them.

The fields used, the tables from which they were taken, and the selection criteria were as shown in the following table.

Table	Field	Total	Sort	Show	Criteria
(1)	dwMachineID	Group By	none	Yes	none
(1)	FirstOfSite0	First	Ascending	Yes	none
(1)	FirstOfName0	First	Ascending	Yes	none
(1)	SMSID0	Group By	none	Yes	none
(1)	FirstOfLogOn_Name0	First	none	Yes	none
(1)	FirstOfOperatingSystem0	First	none	Yes	none
(1)	Version	Group By	none	Yes	none
(1)	MaxOfFreeStorage0	Max	none	Yes	none
(1)	FirstOfProcessor_Name0	First	none	Yes	none
(2)	MaxOfTotal_Physical_Memory_KB0	Max	none	Yes	none
(2)	MaxOfManufacturer0	Max	none	Yes	none
(2)	FirstOfWorkGroup0	First	none	Yes	none

The Reports

The result of the last query, the Target User List table, was used as a source for a report generated by Microsoft Access. The following illustration shows a report using the fields Machine Name, SMS ID, and Logon Name.

The export feature in Microsoft Access was then used to transfer the data taken by this report to a Microsoft Excel spreadsheet. This spreadsheet was then sent to the respective SMS administrators. The following illustration shows one of these spreadsheets.

Step 7: Conduct Pilot Rollout

Once every detail of the pilot rollout has been planned and documented, you are ready for the actual deployment. At the end of the pilot rollout, the information you learned from the pilot can be documented and used to refine your final rollout plan. In addition to feedback from technicians and users, you can study Systems Management Server (SMS) job status and job logs in your analysis of the pilot rollout. If adjustments are indicated, test them in the lab before proceeding.

Install SMS in Pilot Site Production Environment

The first step in conducting the pilot rollout is to install SMS on servers supporting the pilot group or groups. The procedure is similar to that described in Part 2, "Testing," under Step 4, "Setting Up the Lab."

The SMS server in the lab should remain an isolated server for lab use only. The SMS server used for the pilot group should be a production server, one that will remain in use for the final rollout and be used for management and inventories after the deployment is complete. This server should follow all the design and configuration guidelines specified in the SMS documentation.

Once SMS has been installed, install your modified versions of the files shipped with this guide, and verify that SMS is functioning properly. Use it to inventory all pilot site workstations and use the SMS User Interface to query the resulting SMS databases. This also gives the users a chance to get used to SMS.

Set the production server report the information it gathers to the lab's central site server. This provides information about the actual production environment to your lab and will give you a better idea of your organization's requirements.

Prepare the installation files for Windows 95 and Office for Windows 95, as you did in the lab. After completing Step 8, you can begin the pilot deployment.

Data Gathering and Analysis

Immediately before a pilot deployment, update the SMS inventory for the workstations included in the pilot so that the most recent data is available. When the hardware and software inventory has been verified, execute your modified versions of the "Windows 95 Capable" and "Not Windows 95 Capable" queries supplied with this guide to assess the installed workstation base and determine which workstations will support Windows 95 and/or Office for Windows 95. Be sure to review the versions you created in the lab and alter them as necessary to reflect your pilot group.

Modify Deployment Approach and Tools to Reflect Pilot Environment

After completing the inventory of the target user environment, modify the plan and/or deployment tools, as necessary, to reflect target workstation characteristics and the distinct needs of different target groups. This might involve further customizing the SMS targeting scripts and packages, and Windows 95 and Office for Windows 95 configuration files.

Deploy Windows 95

Use the plan and tools developed in earlier tasks to install Windows 95 (and Office for Windows 95, if you are deploying them together) on computers in the pilot group. This should be analogous to the test deployment described in Part 2, "Testing," under Step 5, "Testing and Refining the Deployment Plan." Begin, as you did then, by creating machine groups to be targeted for different configurations and by using an SMS job to run ScanDisk on the target workstations.

Assess Automated Deployment

Once the SMS jobs have been submitted and completed, assess the results of the automated deployment, using the same techniques that you used in the lab. These are described in Step 6, in the section "Evaluate Distribution Results." In addition, ask your users what did and did not work for them.

Troubleshoot Exceptions

Some individual workstations might not successfully complete the upgrade to Windows 95. This can happen for many reasons, including modifications made to the workstation after the last SMS Inventory was completed or a hardware incompatibility of some type, such as insufficient disk space. If a user adds files to the hard disk between the last inventory and the automated deployment of Windows 95, resulting in insufficient disk space for the installation, the deployment can fail. The following table indicates some of the items that should be checked during the troubleshooting process.

Troubleshooting Checklist

Exception causes	Actions/Determining factors
1: Determine whether a workstation was successfully upgraded to Windows 95 from its original operating environment.	Execute the Assessment queries. • Successful workstations show Windows 95 as the current operating system and the original operating system (e.g., DOS) as the past record. The DOS version for successful workstations will be 7.0. • Unsuccessful workstations show only the original operating system.
2: Determine whether any individual workstations, which may have failed during the Windows 95 upgrade process, are no longer operational. The Windows 95 installation process protects against this to the extent possible, but there might be exceptions.	• Workstations that are no longer operational are not updated in the SMS Inventory. You might choose to perform the inventory at more frequent intervals in the weeks before the rollout to make sure that only currently operational computers are targeted. • In some cases, you might want to develop an SMS query to identify workstations that have not had their inventory updated. These can be checked through other means.
3: Determine whether a faulty hardware component caused a failure of the Windows 95 upgrade process.	Add this to the "Windows 95 Capable" SMS query, or create a separate query. Exclude affected workstations from the automated Windows 95 deployment process. Handle these cases as exceptions.

When the exceptions have been identified and the problems resolved, use SMS again to deploy Windows 95 to the exception workstations. You might need to modify the installation files to meet the requirements of these workstations.

Evaluate Pilot Test Results

When the pilot rollout is completed, perform a detailed analysis of the pilot deployment results, including any modifications to the plan and tools used. Include feedback from the users as well as the technicians and Help desk personnel who participated in the pilot rollout. What worked well? What didn't? Was the level of effort accurately estimated? Did training adequately prepare the users and support personnel for Windows 95 and/or Office for Windows 95? What would the users and support personnel change about the process?

If necessary, modify the final rollout plan and/or deployment tools based on feedback from the pilot tests. If substantial changes are indicated, you might want to conduct additional pilot tests to test these changes and collect data on the effectiveness of the revised plan.

When you are satisfied with the pilot rollout process and have made final adjustments to your procedures, you are ready to deploy Windows 95 and/or Office for Windows 95 throughout your organization.

Step 8: Fine-Tune the Master Rollout Plan

Identify what did and did not work well in your pilot deployment or deployments, and modify the rollout plan and schedule accordingly. Components to modify and update might include the following:

• Estimated time and budget necessary to complete the rollout

• Policies and Practices Guidelines

• Staffing plans and resource assignments

Prepare Implementation Support Materials

After completing the pilot rollout, prepare the checklists and update your procedures for project monitoring before the final rollout so that the plan you've developed can be replicated by multiple implementation teams working simultaneously. Step-by-step procedural checklists covering preparation, execution, and follow-up for the Windows 95 migration ensure consistency as well as thoroughness. You also need to determine the method and frequency of project activities, potential problems, and overall progress to be tracked, and who will be responsible for these tasks.

Training and Orientation for Deployment Teams

To ensure consistency in the overall deployment, implementation team members should receive training that covers the following:

• Deployment Plan

  All participants should be familiar with the overall deployment plan and the tools that will be used.

• Systems Management Server (SMS) Product

  Windows 95 deployment staff should receive sufficient training in SMS to allow them to use this guide and the associated software to deploy Windows 95. Primary emphasis should be on the user interface of SMS.

• Windows 95

  All team members should have training and hands-on experience with Windows 95.

• Office for Windows 95

  If you are deploying Office for Windows 95 at this time, the team members should be familiar with it as well.

Step 9: Perform the Final Rollout

The tools and plan you've developed throughout the process outlined in this guide have been tested and refined, and you are now ready for the smooth deployment of Windows 95 and Office for Windows 95 throughout your organization. Most likely, multiple implementation teams will work in parallel on this deployment.

Even during this final deployment, it's best to remain flexible. Take advantage of every opportunity to improve the process, and be ready to deal with the unexpected. As experience and additional expertise are gained, you can refine and tune the deployment processes to make each successive deployment effort more efficient.

To this end, the following ongoing tasks are recommended:

• Monitor project timeline and milestones.

  Regularly monitor project progress against the project schedule, especially critical project milestones and dates.

• Monitor Help desk call activity.

  Help desk call activity levels and subject matter are good indicators of the success of the deployment. High call volumes may indicate possible deficiencies, and they should be researched and corrected.

• Maintain the testing lab.

  The testing lab should be maintained indefinitely. As problems arise that must be researched, new application products are introduced into the solution, or upgrades to Windows 95 are released, use the lab to evaluate the potential impacts and proactively adjust the migration approach.

• Use Systems Management Server (SMS) inventory data to track progress.

  As the deployment progresses, the central site SMS database collects information on the installed workstation base. Use information available from custom SMS queries to monitor deployment rates and other critical progress indicators. Have the SMS distribution servers report to the testing lab's central site server so that this information will be available for future tests and deployments.

Final Assessment

When the final deployment is complete, you will probably want to assess the process. Now that SMS is in place, you can to use it in future deployments of upgrades and new software. To accomplish this consider the following:

• What advantages did you enjoy in this deployment that you want to be sure to maintain in the future?

• What would you like to improve on?

• How can predeployment training of the users be improved?

• How completely did the support staff take advantage of the Help desk features of SMS?

• What other SMS features will you want to implement in the future?

Also, ask the users for feedback on the configurations you set up for them. If the configurations need adjustments, you now have the tools to deploy an adjusted configuration to a target group with minimal impact to the users.

Step 10: Provide Ongoing Support

After the rollout is complete, you can enjoy the ongoing advantages of Systems Management Server (SMS). Here are a few of the features that will make life easier for users and support personnel alike:

• Easier installation of new software and upgrades

• Faster, more efficient Help desk support

The following sections discuss some of the specific ways you can take advantage of these features in your organization.

Easier Installation and Upgrades

With SMS in place, you are ready to upgrade any of the software used throughout your organization, using the tools and procedures you developed to deploy Windows 95 and Office for Windows 95, including future updates to Windows 95 and Office for Windows 95. Also, any new software can be deployed, using these same tools and procedures. When you next deploy a new product or upgrade, begin at the planning stage, with a full inventory of the hardware and software in use throughout your organization. Compare it to the configurations you used while deploying Windows 95. Then fine-tune the deployment plan for your new software or upgrade by making the necessary changes. This is why it is so important to document your deployment plan, including all changes and special cases. The plan you used to install Windows 95 throughout your organization will save considerable time — and therefore money — in the years to come.

Help Desk Support

The Inventory, Diagnostic, Remote-Control, and Network Monitoring functions of SMS, and the Network Protocol Analysis tool, are integrated to provide optimal user support from your Help desk. Support personnel can use the SMS User Interface for full access to the caller's current configuration and for access to the historical changes to that configuration. If the remote-control option is installed, support staff can also remotely diagnose the caller's workstation to facilitate troubleshooting. If necessary, with the user's permission, support staff can also take over the caller's workstation from the Help desk computer and perform the actions necessary to correct a problem rather than traveling to the user's office to do so.