Testing

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.

The testing portion of the Systems Management Server (SMS) deployment plan consists of setting up the lab and testing and refining that plan. The lab you create for testing Windows 95 and Office for Windows 95 deployment should be established as a permanent fixture to test future deployments. Based on the results of tests in your lab, you can make adjustments to your overall plan before you begin the automated rollout. After these steps, you can begin the pilot rollout.

On This Page

Step 4: Setting Up the Lab
Step 5: Testing and Refining the Deployment Plan

Step 4: Setting Up the Lab

The lab is set up to test the chosen configurations, and the deployment process itself, without disrupting the organization's production environment. When you finish setting up the lab, you should have an accurate simulation of the production environment, including all the types of hardware and software used in your organization's network.

The lab you establish for testing your Windows 95 and Office for Windows 95 deployment should be created as a permanent fixture, although its composition will change over time. After deployment, this lab will be useful for training and testing future deployments of major software upgrades or new software products.

Setting up the lab and defining the preferred client configuration are concurrent tasks; the process of setting up the lab will help clarify which features are most useful to your computing environment.

This portion of the guide discusses setting up a lab for deployment of Windows 95. If you will also be deploying Office for Windows 95, see Part 4, "Office for Windows 95 Rollout" for more information.

Defining Lab Requirements

A major factor in designing the testing lab is identifying the hardware and software components necessary to simulate your production environment. All components of the targeted environment should be represented so that ideal Windows 95 and Office for Windows 95 configurations, additional application software, Systems Management Server (SMS), and the files included with this guide can be tested for compatibility.

For the lab to reflect your production environment accurately, you need to be careful not to "sanitize" the lab setup. For instance, if your production environment includes nearly full disks, obsolete and possibly unused software, and an assortment of network adapter cards, your lab should have these features, too. Also, if sites are connected by routers or slow links, be sure to duplicate these in the lab. This ensures that any resulting problems can be identified and resolved in the lab rather than during the production rollout.

The testing lab should be set up as an independent LAN, separate from the rest of the organization. The LAN in the lab should be as similar as possible to the LAN or LANs in your production environment. This allows you to test new software and new methods, without concern that an error might affect the users in your organization.

Include the following in defining your testing lab.

File Servers

• The lab should include servers configured to represent the production network environment that will be encountered during deployment. For example, if you use multiple network operating systems (Windows NT, NetWare, LAN Server, etc.) or multiple protocols (TCP/IP, IPX/SPX, NetBEUI, etc.), be sure to test them all.

• If your production environment includes both Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs), set up one of your Windows NT Servers as a PDC, then set up another as a BDC. You must have one Windows NT Server configured as a PDC to run SMS.

• Server products, versions, and configurations should duplicate the production environment.

• If possible, include multiple servers in the lab configuration.

Clients (Workstations)

• Make sure that these computers meet your company's standards and represent the computers targeted for Windows 95 and Office for Windows 95 deployment.

• Attempt to include the full range of production workstations that might be encountered during full deployment. It is much better to find and deal with exceptions in the lab environment than during the actual rollout.

• Workstations should be configured with the full suite of standard desktop software, configured as they would be in the production environment. Consider legacy and line-of-business applications when setting up the workstations in the testing lab. Also, try to duplicate the real-life condition of the computers, including percentage of free disk space and the mix of network adapters, printers, and drivers used in your organization.

Note: Some applications are not supported on Windows 95. Check the complete listing included with the Windows 95 and Office for Windows 95 Migration Planning Kit.

The following diagram describes a suggested configuration. Note that it includes a Logon and Distribution server separate from the SMS Central Site server. If your company has multiple SMS sites, be sure that they are simulated in the lab, using the type and speed of communication links used in the production environment. You'll need a client for each hardware/software configuration used in your organization , including those that are only a small minority of your installed computers.

Once the individual computers and the LAN that connects them have been set up in the lab, you are ready to install your deployment software.

Setting Up the Lab

Windows NT Server and SQL Server must be properly configured before SMS is installed. If you have already installed Windows NT Server and SQL Server, read the following sections to verify that you have the correct configuration, making changes where needed. If you have not yet installed Windows NT Server and/or SQL Server, do so at this time, configuring the systems as described in the following sections. You might want to refer back to the System Requirements chart in the Part 1 of this guide to ensure your hardware meets these requirements.

Install and Test Windows NT Server

SMS 1.1 works with Windows NT Server versions 3.5 and later, and with SQL Server versions 4.21a and later. These installation instructions assume that you are running Windows NT Server 3.51 and SQL Server 6.0. If you are using either Windows NT Server 3.5 or SQL 4.21a, make sure that you are using the latest Service Pack. If you are using Windows NT Server 3.5 and SQL Server 4.21a, please refer to the Systems Management Server 1.1 Reviewers Guide (Part No. 098-58174) for guidelines.

The recommended minimum hardware configuration of the SMS Central Site Server is as follows:

• Pentium®-based

• 32 MB RAM (dependent upon function)

• At least 1 GB of disk space (depending on the number of clients and the number and size of packages)

For the purpose of deploying Windows 95 and Office for Windows 95, the following table shows the amount of disk space we recommend be allotted for the indicated component.

For this component	Allow this much disk space*
Windows NT Server	100 MB
SQL Server version 6.0	125 MB
SMS version 1.1	100 MB
SMS to deliver Windows 95 (up to five of the original source files to be distributed might be needed at any one time)	500 MB (100 MB each) for the "worst case" scenario
SMS Packages to deliver Office for Windows 95 (up to five of the original source files to be distributed might be needed at any one time)	600 MB (120 MB each) for the "worst case" scenario

* Please see Systems Management Server Administration Guide, Chapter 10, "Packages," for more detailed information.

The Windows NT Server Installation Guide, Chapter 1, provides detailed instructions for installing Windows NT. When installing Windows NT Server to be used with SMS, use Express Setup with the following options:

• Create at least one NTFS partition with at least 100 MB of free space. This will be used to install the SMS Site Server software. (You can convert to an NTFS partition at a later time, but it is easiest to convert during Setup.)

• When prompted to select the Windows NT Server Security Role, choose the Domain Controller (Primary or Backup) option. If you want your SMS Site Server to reside in an existing Windows NT 3.51 domain, choose Backup. If you want the SMS Site Server to be in its own new domain, choose Primary.

• When prompted for a server name, choose a name that fits with your organization's naming conventions. To migrate a PDC or BDC from one domain to another is to re-install Windows NT Server on the computer that acts as Domain Controller.

If you use Express Setup, TCP/IP is installed as the default protocol. Therefore, you will either need to enable DHCP or to install an IP address. If you want to use a different protocol, you can either change the protocol after the Express Setup is complete or use Custom Setup, specifying the protocol or protocols of your choice.

Prepare Windows NT Server for SMS

Once the Windows NT Server is installed, perform the following tasks:

• Install the Network Monitor Agent. (This can be done during installation, if you used Custom Setup.)

• Create the special service accounts.

• If your site includes Novell NetWare, install the Windows NT Gateway Service for NetWare, with all current patches applied. (This can be done during installation, if you used Custom Setup.) Then add the NT Gateway Group to all NetWare Servers. See Appendix A, "Special Instructions for Sites Using Novell NetWare," for more information.

Install the Network Monitor Agent

Included with SMS is the Network Monitor user interface, which enables network administrators to detect and troubleshoot problems on LANs or WANs. Network Monitor also works with the Microsoft Remote Access Service (RAS).

Using the Network Monitor user interface and Network Monitor Agent, you can:

• Capture frames (also called packets) directly from the network.

• Display and filter captured frames.

• Edit and transmit captured frames onto the network to test network resources or to reproduce network problems.

• Capture frames from a remote computer and then display the capture statistics on the local computer at intervals that you specify.

The Network Monitor Agents significantly enhance the scope of Network Monitor by enabling it to capture data across more than one network. In addition, when you install the Network Monitor Agent, counters are added to the Windows NT Performance Monitor. You can use the counters for limited monitoring of network performance. Network Monitor Agents can be password protected to prevent unauthorized access.

Note: To use Network Monitor Agents, you need a network adapter card that supports promiscuous mode, a state in which the network adapter card can be directed by a device driver to pass on to the operating system all the frames that pass over the network. To determine whether your card supports promiscuous mode, see the documentation that accompanies the card. An updated list of network cards that have been tested and have passed compatibility testing with Microsoft Network Monitor can be found in Library 1 of the WINNT forum (GO WINNT) or Library 17 of the MSWIN32 forum (GO MSWIN32) on CompuServeAE Information Services. We have not tested every computer or device in all possible configurations.

To install the Network Monitor Agent

1. In the Windows NT Program Manager, open the Main program group.

2. Choose the Control Panel icon.

3. Choose the Network icon.

   The Network Settings dialog box appears.

4. Click Add Software.

   The Add Network Software dialog box appears.

5. In the Network Software box, select Network Monitor Agent.

6. Choose Continue.

7. Choose OK.

   A message reminds you to restart your computer for the changes to take effect.

Create Service Accounts

Certain Windows NT services, including Directory Replicator, SQL Server, and SMS, use a special kind of user account called a service account. After Windows NT Server is installed, use User Manager for Domains (found in the Administrative Tools program group) to create the service accounts for these services.

The recommended account names and associated Groups are listed in the following table. The remainder of this guide assumes you are using these names; however, you may substitute other names if you prefer.

Account name	Description	Add to these Groups
REPLAdmin	Required for the Directory Replication Service, which is used to maintain logon scripts. (Required only if using a Backup Domain Controller in Windows NT and LAN Manager domains in SMS sites or if you have other domains [with logon servers] below the SMS primary site.)	Administrators Domain Administrators Replicator Backup Operators
SQLAdmin	Required with SQL 6.0 for the MS SQL Server Executive service, which is used to maintain the SMS database. Not required for SQL 4.21a.	Administrators Domain Administrators
SMSAdmin	Required for the SMS Services. Used for creating the database during the setup of the Primary Site Server and to log on as an SMS Administrator.	Administrators Domain Administrators

When using the Windows NT trusted domain model, create a single SMS service account in the trusted domain. The SMS service account must be a member of the Administrator's local group in ALL Windows NT domains in the SMS site and must have Log On as Service rights in all domains in the site.

For each account, choose New User, and fill in the account name, description, and password. For example, SMSAdmin for the account name, SMS Administrator for the account description, and the password of your choice. Each account should be given a password that is different from the account name, with the options that the user cannot change the password and that the password never expires. For example, the following illustration shows the details of the user account that is required by the Directory Replicator service.

This screen also shows the group memberships assigned to the account. The group memberships dialog box appears when you click on the Groups button in the User Properties dialog box.

Assign the User Right "Log on as a service" to each of these accounts. Make sure that the Advanced User Rights check box is selected. (See the following illustration.)

Add the appropriate accounts and/or groups to grant the "Log on as a service" right.

Configuring the Directory Replicator Service

SMS can automatically update users' logon scripts, allowing the administrator to gather all the details about each computer without having to visit that computer physically. In a Windows NT Server environment, this is achieved by enabling the Windows NT Directory Replicator Service. This account is not needed if your organization uses only NetWare for a network operating system or if you are not using a Backup Domain Controller.

Use Server Manager to configure the Replicator service to start automatically, using the REPLAdmin account. After you select the Replicator service from the Server Manager dialog box and choose Startup, the Service on Servername dialog box appears. Fill in this dialog box, using the following illustration as a guide.

Stay in the Server Manager and select Windows NT Server. Choose Properties from the Computer menu and click Replication. Click Export Directories and Import Directories, and then click OK. Now the Replicator Service starts, as shown in the following illustration.

This completes the process of setting up the Windows NT Replicator service.

Now you have a LAN with a Windows NT Server installed. For more information on special steps for NetWare environments, see Appendix A, "Special Instructions for Sites Using Novell NetWare."

Install SQL Server

Once you have installed Windows NT Server, you must install SQL Server, which handles the most of the information needed by SMS. After SQL Server is installed, you can install SMS.

The SQL Server that will hold the SMS site database can be located on the same computer as the SMS site server. Or, to reduce the load on a single computer, the SMS site server and the SQL server that holds the SMS database can be on different computers. In some cases, doing so will slow response time between the SMS site server and the SMS database, because they must communicate over the network.

A primary site's database contains system and inventory information for itself and the sites below it. The Central Site's database contains the system-wide configuration and inventory information for all sites in the SMS system.

SMS will use the character set and sort order set on the SQL Server. These settings affect how SMS queries and sorts data. For more information about how character sets and sort orders are used by SQL Server, see the Microsoft SQL Server documentation. SQL version 4.21a uses a binary sort order by default. SQL version 6.0 uses a case-insensitive sort order. You should be aware of this if you plan to upgrade from SQL 4.21a to SQL 6.0.

For complete instructions on installing SQL, refer to the SQL Server documentation. We recommend that you use the default setup, except as described in the following sections.

Auto Start Server and Executive

When the SQL Server Setup for Windows NT Installation Options dialog box appears, select Auto Start SQL Server at boot time and Auto Start SQL Executive at boot time, as shown in the following illustration.

Set SQLAdmin as Executive Log On Account

When the SQL Executive Log On Account dialog box appears, enter the account created earlier (SQLAdmin) and the password, as shown in the following screen.

(This step is optional, but recommended.)

If you run SQL Server and SMS on the same server, SMS gives you the opportunity to create the SQL devices and databases during Setup automatically. If you would prefer to run SQL Server on a separate Windows NT Server or would like to create the SQL devices manually, refer to Appendix C, "Creating Database Devices with SQL Server 6.0."

Working with Microsoft SQL Server

SMS works with several of the products that make up BackOffice™. In particular, SQL Server is an integral part of SMS. You don't need a lot of experience with SQL Server to use SMS. For example, SMS can create the appropriate devices and databases automatically when the system is first installed. However, sometimes you may want to use the SQL Server administration tools. This section discusses some of the primary features of SQL Server that you might need when working with SMS.

Setting the security options

From the SQL Server program group, choose SQL Setup. In the Options dialog box, select Set Security Options, as shown in the following screen, and then choose Continue.

Select Windows NT Standard, which is the default, as shown in the following screen, and then choose OK.

These changes will take effect when SQL Server is restarted. Use the SQL Service Manager to stop and restart SQL server, as shown in the following screen.

Note: SMS requires that the maximum user connection setting in SQL be no less than 20 connections. For SQL 4.21a, the default is 10 connections; for SQL 6.0 the default is 20 connections. If there are to be other remote administrator connections, this number should be 5 connections per administrator, to allow for worst-case scenarios. If the SQL Server is used for other databases, add 20 or more to the existing maximum user connections setting. See your SQL Readme Help for information on changing this setting.

We recommend that you allow at least 20K per computer in the SMS Database (SMSData) for data. Set the Database Log (SMSLog) size to be at least 20 percent of the Data size and allow at least 4K per computer (20 MB minimum) for the Temporary Database (TempDB). For example, if you have 50,000 computers in your SMS database, you should allocate at least 1 GB total for SMSData, at least 100 MB for SMSLog, and a further 200 MB for Tempdb.

The following table gives some recommendations for creating these devices and the space required for these files.

Examples:
Device	Default size
SMSData	45 MB
SMSLog	8 MB
TempDB	2 MB

In the testing lab, if you are using 2,200 or fewer computers, the default values are acceptable; remember, however, to increase your TempDB size to at least 20 MB. In your production environment, the recommendations in the preceding table should be used. See your SQL Server documentation for details.

This completes the process of setting up a remote database for SMS.

Install SMS on the Primary Site Server

If you have not already installed SMS, do so at this time. SMS requires at least one NTFS partition with at least 100 MB of free disk space for the initial installation of the SMS site server. We recommend that you allow at least 1 GB of additional disk space for the deployment of Windows 95 and Office for Windows 95. This additional space can be located on one or more partitions (formatted NTFS, FAT, or HPFS) on the SMS site server. If you did not choose to have Windows NT Setup convert a partition to NTFS, convert it before beginning the SMS Setup program.

The instructions that follow assume that you are installing the SMS primary site server on the computer that is running SQL Server. If the SMS primary site server is not installed on the same computer as is running SQL Server, you must manually create the database and log devices for the site database on the computer running SQL Server before you run the SMS Setup program. For information about creating databases and devices, see the Microsoft SQL Server documentation.

To install SMS

1. From the SMSETUP directory, run SETUP.BAT. This batch file examines your system to determine which platform to install: X86, Alpha, or MIPS.

2. From the Installation Options dialog box, choose Install Primary Site. This starts the primary site installation.

3. From the Setup Install Options dialog box, choose Continue to install the default SMS components. If you plan to use different computers, select the Custom dialog box and choose the computers that you plan to use. (Refer to the Release Notes for additional help or information.)

   If you are installing SMS on the same server as the SQL Server, the SQL Database Configuration dialog box appears with the SQL Server configuration information. Fill in the SQL Login (SMSAdmin) and the password you assigned to that account, as shown in the following illustration.

   

4. Enter the primary site configuration information for your installation, using the following illustration as a model. Note that the check box for Automatically detect all login servers has been selected; it is cleared by default.

   

   The fields in this dialog should be filled in as follows:

   • Code: Any unique combination of three alphanumeric characters (no special characters)

   • Name: A descriptive name

   • Server: Leave as default

   • Domain: Leave as default

   • Automatically Detect Logon Servers: Select

   • Username: The SMSAdmin account that you created. If trust relationships are used between domains, include the domain prefix with the user name.

   • Password: The SMSAdmin password (must be different from SMSAdmin account name)

   The Setup program copies files, completes the database configuration, automatically installs the Network Monitor Agent if it is not already installed, and starts the SMS Services.

Setting Properties

Now that SMS has been installed, use SMS Administrator to configure the SMS site. This is fully described in the Systems Management Server Administrator's Guide, Chapter 5, "Configuring Sites." To use SMS Administrator, you must first log on using the SMSAdmin account. Creation of this account was described earlier in this portion of the guide, under the heading "Create Service Accounts."

Sites button

The necessary settings are made from the Site Properties dialog box, which you reach by choosing Sites from the SMS Administrator Window. From the SMS Administrator toolbar, click Sites.

The Sites Properties dialog box appears.

Setting the Client Properties

You will need to choose Clients from the Sites Properties dialog box and make the following adjustments:

• Click Proposed Properties radio button.

• Choose Automatically Configure Workstation Logon Scripts. When you enable this option for the site, SMS automatically modifies the logon scripts for all users in all Windows NT and LAN Manager domains in the site so that the SMSLS batch file is run every time a user logs on to one of the site's domains. For NetWare domains, the system login scripts for all the sites' NetWare file servers are modified to run the Client Setup and Inventory Agent programs.

• Choose Detect All Servers if your network includes Windows NT or LAN Manager domains.

• In most cases, choose Add to Bottom of Logon Script so that the modifications that SMS makes to the Login Script are added to the end of the script. This could depend on what else is done by the script.

Note: In the lab, you might want to reduce the Package Command Manager Polling Interval; the minimum permitted value is 5 minutes. During the actual deployment, you will probably need a higher value, such as 60 minutes.

The following screen shows a completed Clients dialog box.

These settings can be changed as needed. In the lab, you might prefer not to start the components automatically.

Setting the Domain and Server Properties

If your servers are all running Windows NT Server or LAN Manager, you probably will not need to make changes to the Domain and Server properties. If your network includes domains that use LAN Manager as the only network operating system, add these domains to the browser configuration on the PDC of the SMS site's domain.

If your site includes NetWare servers, follow the directions in "Setting the Domain and Server Properties" in Appendix A, "Special Instructions for Sites Using Novell NetWare," at this time.

Use SMS to Inventory the Lab

The simplest way to use SMS to perform hardware and software inventories is by enabling the Automatically Configure Workstation Logon Scripts option. That method is described in the section, "Setting the Client Properties," earlier in this portion of the guide. However, you can also add SMS installation and inventory commands manually to existing logon scripts if you prefer. For more information, see the Systems Management Server Administrator's Guide, "Setting Up Inventory Collection for Clients" in Chapter 3, "Installing Sites."

As each computer in the lab logs on to the lab network, SMS detects it, installs the appropriate SMS client software, and adds the computer to the inventory. Log on a few of the lab computers to populate the database.

Start SMS Administrator, logging on with the SMSAdmin login ID and the password you assigned to the SMSAdmin account when you set up that account. Open the Sites window to explore SMS Administrator and the lab inventory, following the directions in the Systems Management Server Administrator's Guide, Chapter 4, "SMS Administrator," and Chapter 6, "Inventory."

When you choose Expand All from the Tree menu, the computers in the inventory for the site appear in the right pane of the Sites window.

You can view the properties of any computer in the inventory by selecting it and then choosing Properties from the File menu.

Install and Test SMS Deployment Guide Files

To install and test SMS Deployment Guide files, first copy the files included in this guide to the appropriate SMS directories.

The Program Definition Files (PDFs) that will be used should be copied as follows:

root directory \ SMS\PRIMSITE.SRV\IMPORT.SRC\ENU\ directory.

Create a source directory for the Windows 95 operating system files. A source directory is the location of the software to be distributed. Copy the relevant Information (*.inf) files to this directory, (i.e., win95.inf, winofc95.inf, etc.), depending on your expected installation options. It is recommended that you copy all possible installation options, (i.e., .inf files), to a single source directory. This will increase flexibility and reduce disk resource requirements.

Note: The files that are supplied should be used as examples.

These files and this guide, Systems Management Server Deployment Guide for Windows 95 and Office for Windows 95, will be made available on the World Wide Web at the following locations:

https://www.microsoft.com/SMSMGMT

and also

ftp.microsoft.com/bussys/winnt/sms-docs

This guide will be made available free of charge. A hardcopy version is also available, please use part number: 098-61449, by ordering from 800-360-7561 (easy sales, TBC).

The WWW address will host all the latest information on Systems Management Server, please check regularly.

Install Windows 95 Prototype Platform

For hands-on testing and the development of ideal Windows 95 configurations, you need to install Windows 95 in the lab, on computers that closely reflect the existing mix of hardware and software in your organization. Begin with the ideal configuration you defined earlier, and then test and adjust that definition. Install Windows 95 as described in the Windows 95 Resource Kit, Chapter 3, "Introduction to Windows 95 Setup."

If you are also planning to deploy Office for Windows 95 at this time, install it as described in the Microsoft Office for Windows 95 Resource Kit, Part 2, "Installing Microsoft Office for Windows 95."

Finally, copy the Windows 95 files to your network source directory, following the directions under "Task 1: Copying Windows 95 Files to a Server" in the Windows 95 Resource Kit, Chapter 4, "Server-Based Setup for Windows 95." When setting the destination path and installation policy, as described in that section, specify User's Choice in the Source Path dialog box.

If you will be deploying Office 95, perform an administrative installation of Office 95 to the SMS server at this time as well.

The setup routines for Windows 95 and Office for Windows 95 can read information files to automate the setup process. These files (.INF for Windows 95, and .STF for Office for Windows 95) can be edited to describe the configuration you want to set up. To deploy Windows 95 using SMS, prepare the information files as described in the Windows 95 Resource Kit, Chapter 4, "Server-Based Setup for Windows 95," and include them in the Windows 95 source directory that you created earlier.

You might also choose to use files in the cabinet (.CAB) storage format to distribute Windows 95. These files take much less space (about 32 MB, as opposed to 90 MB for the expanded files), and are therefore an efficient way to send packages with installation information to SMS subsites. The files can then be extracted at the distribution server. The Extract program is described in the Microsoft Windows 95 Resource Kit, Appendix A, "Windows 95 System Files."

By placing the .INF, .CAB, and .STF files in the Windows 95 source directory, you insure that these files will be included when SMS copies the Windows 95 Setup files to the appropriate SMS distribution servers.

To deploy Office for Windows 95 using SMS, prepare the information files as described in the Microsoft Office for Windows 95 Resource Kit, Chapter 9, "Customizing Client Installations," and include them in the files on your SMS server.

Ready for Testing

In the process of setting up the lab, you might have adjusted your definition of the client configurations you want to use. You also have had a chance to become familiar with SMS, if it is new to your organization.

Once the lab has been set up, you are ready to test the deployment process in the lab. The tasks involved in testing are described in the following section, "Step 5: Testing and Refining the Deployment Plan."

Step 5: Testing and Refining the Deployment Plan

Already, you have defined your preferred client configurations, set up a LAN in the lab that simulates your production environment, installed Systems Management Server (SMS) and the files associated with this guide, and used SMS to take inventory of the servers and workstations in your lab. You are now ready to test your deployment plan using the mini-network in the lab. Based on the results of these tests, you might want to make adjustments to your overall plan. At the end of this step, you should have the files and procedures for an automated rollout. This portion of Part 2 discusses testing and refining the deployment of Windows 95. If you are also deploying Office for Windows 95, follow the additional steps in Part 4, "Office for Windows 95 Rollout."

The process described here can be used as described, or it may be refined to fit your particular organization. For additional information, see the Systems Management Server Administrator's Guide, or contact a Microsoft Authorized Technical Center (ATEC) for information on Systems Management Server training classes.

Test Windows 95 Deployment

Use SMS and the files included with this guide to perform a test deployment in the lab. This involves the following steps, which are discussed in greater detail in the remainder of this section:

1. Identify the target computers by running the queries associated with this guide.

2. Create Machine Groups containing these computers.

3. Send a job to run ScanDisk on these computers.

4. Review the log files for the ScanDisk job.

5. Create an SMS package to install Windows 95 on workstations.

6. Create an SMS job to execute the package.

7. Monitor the SMS job status.

8. Evaluate distribution results.

Creating the "Windows 95 Capable" Query

The goal of a "Windows 95 Capable" query is to help identify the computers that have the hardware requirements to run Windows 95. After you create and run the query, you can create a Machine Group with the results. This will be your target group for the jobs to run ScanDisk and to install Windows 95, and it provides a list of the computers targeted for a specific job.

If you wish to include Office for Windows 95 as part of the migration, refer to Part 4 of this guide, "Office for Windows 95 Rollout," and Systems Management Server Administrator's Guide, Chapter 7, "Queries" for more information.

Depending on your organization, you might want to use a modified version of this query. Instructions on how to do so are included later in this section. This particular query will include the following criteria: a PC running Windows for Workgroups, with 40MB of free disk space on drive C, using either a 486 or Pentium processor and with 8MB of physical memory.

The query will look like this:

(
MICROSOFT|DISK|1.0:Free Storage (MByte) is equal to '40'
AND
MICROSOFT|DISK|1.0:Disk Index is 'C'
)
AND
MICROSOFT|X86_PC_MEMORY|1.0:Total Physical Memory (KByte) is
Þ greater than or equal to '8000'
AND
(
MICROSOFT|PROCESSOR|1.0:Processor Name is like '486'
OR
MICROSOFT|PROCESSOR|1.0:Processor Name is like 'PENTIUM'
)
AND
MICROSOFT|OPERATING_SYSTEM|1.0:Operating System Name is
Þ 'MS Windows for Workgroups'

To create a query

1. Select New from the File Menu in SMS Administrator, as shown in the following screen.

   

2. In the Query Properties dialog box, enter the appropriate query name, such as "Windows 95 capable PC's."

3. Also in the Query Properties dialog box, enter the appropriate comment, such as "PC's capable of installing Windows 95," and the Architecture (e.g., Personal Computers), as shown in the following screen.

   

4. Click Add AND. The Query Expression Properties dialog box appears, as shown in the following screen.

   

5. Select the Operating System from the Query Expression Properties dialog box, in this case, "MS Windows for Workgroups".

6. Click OK to return to the Query Properties dialog box.

7. Click Add AND, and the Query Expression Properties dialog box appears.

8. Select a Processor group, in this case, "Processor Name."

9. Click OK to return to the Query Properties dialog box.

10. Click Add OR, as shown in the following screen. The Query Expression Properties dialog box appears.

    

11. Choose the processor name, in this case ,"486."

12. Click OK. The Query Expression dialog box reappears.

13. Click Add OR, again to choose an additional processor. The Query Expression Properties dialog box appears.

14. Choose the processor name, in this case ,"Pentium."

15. Click OK. The Query Properties dialog box reappears.

16. Click Add AND. The Query Expression Properties dialog box reappears.

17. Select the PC Memory, in this case Total Physical Memory, "in Kb",\024 where the value is greater than or equal to 8000, as shown in the following screen.

    

18. Click OK. The Query Properties dialog box reappears.

19. Click Add AND. The Query Expression Properties dialog box reappears.

20. Select a Disk Attribute, in this case, "Disk Index," where the value is C, as shown in the following screen.

    

21. Click OK. The Query Properties dialog box reappears.

22. Click Add AND. The Query Expression Properties dialog box reappears.

23. Select a Disk Attribute, in this case, "Free Storage," where the value is equal to 40, as shown in the following screen.

    

24. Click OK. The Query Properties dialog box reappears.

25. Group the Disk and Processor expressions by highlighting the expressions and clicking the "Group" button, as seen in the following diagrams. By making a set of expressions a group, you ensure that the group's expressions are treated as a single entity.

26. Click Add AND. The Query Expression Properties dialog box reappears.

27. Select the Personal Computer items, in this case "(Microsoft|Processor|1.0: Processor Name is like '486' or Microsoft|Processor|1.0: Processor Name is like 'Pentium')", as shown in the following screen.

    

28. Click Group, so the disk information will be moved to the top of the query, as shown in the following screen.

    

29. Click OK.

Once you have created the query to suit your needs, you can run it, as described in the next section. The query is run against the machine inventory records in the SMS database.

To run the query

1. From the File menu of the SMS Administrator window, click Execute Query. The Queries window appears.

2. Open the Sites window, and tile the Queries and Sites windows so that they look something like the following screen.

   

3. Drag the query you want to run into the Sites window, and drop it on one of the primary or secondary sites. The query will run on the site and on all of its subsites.

   If you want to limit the query to just the target site's inventory, run the query by clicking Execute from the File menu and filling in the resulting dialog box.

When you run the query, you should get a result something like that shown on the following screen.

The unaltered "Windows 95 Capable" query searches all computers in the SMS database that have Microsoft Windows for Workgroups version 3.11 installed. SMS records the MS-DOS versions of all computers running MS-DOS, Windows, Windows for Workgroups, or Windows 95. This means that all workstations that meet the criteria of the query will be targeted for the installation, including existing Windows 95 computers.

Because the PDF has multiple command lines (for installing Windows 95 for MS-DOS, Windows, and Windows 95 computers), you will need multiple queries to define the target workstations for the different platforms. This information will be used in defining the job details when you send the job to install Windows 95.

Note: In the inventory, the MS-DOS version for Windows 95 is recorded as version 7.0. SMS does not report a MS-DOS version for Windows NT Workstation or Windows NT Server platforms.

If you want to, you can modify the properties of the "Windows 95 Capable" SMS query used to target distribution of Windows 95 and save it with a unique name. For example, if you have both 486 and Pentium computers that are "Windows 95 Capable" but only want to target the 486 computers, you can edit the query to specify this restriction. You can find detailed information on queries in the Systems Management Server Administrator's Guide, Chapter 7, "Queries." The following is a brief description of the steps for editing a query.

To edit a query

1. Open the Query window in SMS Administrator.

2. Select the query (in this case, the Windows 95 Capable query), and click Edit. The Query Properties dialog appears, as shown in the following screen.

   

3. Select a line you want to edit, and click Properties. The Query Expression Properties dialog box appears. The choice of operators and values you have in this dialog box depends on the line you chose to edit.

   If you choose the line describing the disk storage, the following dialog box appears.

   

   If you choose the line describing the total physical memory, the following dialog box appears.

   

4. Choose the operator and value you want to select from the drop-down boxes at the bottom of the dialog box, and click OK.

5. Repeat steps 3 and 4 until the query is as you want it.

6. Click OK to close the Query Properties dialog box.

Once you have altered the query to suit your needs, you can run it, as described earlier. The query is run against the machine inventory records in the SMS database.

You can create a group of all the computers that you want to upgrade to Windows 95 by running the modified version of the query and dragging and dropping the query results into a Machine Group in the Machine Group window. This group can then be used in subsequent steps. The following screen shows a group created from the results of the query.

You might want to create several different Machine Groups to deploy different configurations. Use variations of the query to create different groups.

All the queries should be tested before proceeding further to ensure that you are selecting the computers you want to target.

See the Systems Management Server Administrator's Guide, Chapter 7, "Queries," for more information on creating and executing queries, and Chapter 14, "Machine Groups and Site Groups," for more information on Machine Groups.

Execute ScanDisk on Target Computers

ScanDisk should be run on each computer before Windows 95 is installed. It checks for lost chains and clusters on the hard drives of the target computers. The Windows 95 Setup program runs ScanDisk and will fail if it detects a problem, so you should identify and correct such problems before attempting to install Windows 95.

If the target computer is running Windows for Workgroups version 3.11, use the version of ScanDisk created for MS-DOS version 6.22 rather than the one shipped on the Windows 95 CD-ROM.

When you run ScanDisk, choose either of the following options:

• Run ScanDisk to correct all errors detected automatically.

• Have ScanDisk create log files that can be manually reviewed later. Corrective action can then be taken on a case-by-case basis.

For information on parameters to the ScanDisk command, including switches for use on drives compressed with DoubleSpace or DriveSpace, see the Microsoft Windows 95 Resource Kit, Appendix A, "Command-Line Commands Summary."

Create a ScanDisk Package

SMS makes it easy to run ScanDisk on all the targeted computers. Create an SMS package containing ScanDisk, and then drag the package to the site (the same way you dragged queries to a site) to create a job with that package. This guide includes a .PDF file for ScanDisk.

To create a package containing ScanDisk

1. If you have not already done so, create a source directory for the SCANDISK.EXE file, and share the directory so that SMS can access it.

2. In the Packages window, choose New from the File menu. The Package Properties dialog box appears.

3. Choose Import, and then select the file \\servername\sharename\import.src\ENU\scandisk.pdf, where servername is the name of the server to which you copied the files included with this guide. The following screen shows this file being selected.

   

   After you select the file, you are returned to the Package Properties dialog box.

4. Click Workstation. The Setup Package for Workstation dialog box appears, as shown in the following screen.

   

   Enter the full UNC name of the source directory (in this case, the directory with the ScanDisk source file) in the Source Directory text box. If you choose to browse through the list of files, edit the resulting path so that it shows the UNC name (which would begin with \\servername\sharename) rather than the relative name (which would begin with the drive letter you have assigned to the server during the current session). The screen should look something like the following screen.

   

5. You can examine the command line for the package by clicking Properties in the Setup Package for Workstations dialog box. If you do so, the Command Line Properties dialog box appears, as shown in the following screen.

   

   You might also choose to view the inventory properties for the package by clicking Inventory in the Package Properties dialog box. If you do so, the Setup Package for Inventory dialog box appears, as shown in the following screen.

   

6. When you are satisfied with the package, click OK until the Package Properties dialog box is closed.

For more information on creating packages, see the Systems Management Server Administrator's Guide, Chapter 10, "Packages."

Run a ScanDisk Job

You can now create jobs using the ScanDisk 6.22 package. Use the Windows 95 queries and/or the Machine Groups you created earlier to define the target computers for these jobs.

To create a ScanDisk job

1. Open both the Sites window and the Packages window in SMS Administrator, as shown in the following screen.

   

2. Drag the ScanDisk package you created to the site on which you want it to run. The Job Details dialog box appears, as shown in the following screen.

   

3. Select the appropriate command from the drop-down list under Run Workstation Command as shown in the following screen.

   

4. Click OK. The Job Properties dialog box appears.

5. In the Job Properties dialog box, fill in a Job ID and a comment. Or, click Schedule to set the earliest time for the job to start. The job priority should be Low, which is the default setting. The priority affects when the job is sent to distribution servers, not the priority the job is given at the client workstation.

6. Click OK until the Job Properties dialog box is closed. The job is sent.

For more information on jobs, see the Systems Management Server Administrator's Guide, Chapter 11, "Jobs."

Monitor the SMS Job Status

Monitor the status of the job by selecting that job in the Job Properties dialog box, clicking Status, and viewing the Sending and Working columns in the Job Status dialog box. The following screen shows the Job Status dialog box.

After the job has had a chance to propagate, you can check on details of the job. In the small network you have set up in the lab, this could take as little as 30 minutes. In your production network, you'll need to allow more time. To view the details of the job, click Details from the Job Status dialog box. The Job Status Details dialog box appears, as shown in the following screen.

When the Status column changes to Complete, the job has been distributed. The total duration of the job depends on many factors, including parameters set for the job and the behavior of your users (who must log on to accept the SMS Package).

Create a Package to Install Windows 95 on Workstations

To install Windows 95 on the target computers, the setup command that installs Windows 95 must be run on each workstation. An SMS Distribution Package can be used to run this command locally on each targeted workstation.

This package, which we will call the "Windows 95" package, is created in the same manner as the package used to run ScanDisk. Make sure this package points to the proper disk location for the Windows 95 source code, including the appropriate .INF files, whether the standard MSBATCH.INF or other versions of this file is used.

Each package is completely self-contained: it has all the command lines and files needed for the task or tasks it is designed to do. Also, a single package can contain several different helper files, .EXEs, and .INFs to allow for multiple configuration options. You choose the command line you want when you create a job using the package definition. The same package definition can be used again when defining different Windows 95 installation jobs.

Creating a package to deploy Windows 95 and/or Office for Windows 95 is much like creating a package to run ScanDisk on the target computers.

To create a package to deploy Windows 95 and/or Office for Windows 95

1. If you have not already done so, create a source directory for the required installation files and share the directory so that SMS can access it.

2. In the Packages window, click New from the File menu. The Package Properties dialog box appears.

3. Click Import, and select the file \\servername\sharename\import.src\ENU\winofc95.pdf, where servername is the name of the server to which you copied the files included with this guide. Or, select the file WIN95.PDF in the same directory. After you select the file, you are returned to the Package Properties dialog box.

4. Click Workstation. The Setup Package for Workstation dialog box appears, as shown in the following screen.

   

   Enter the full UNC name of the source directory (in this case, the directory with the Windows 95 and/or Office for Windows 95 source files) in the Source Directory text box. If you choose to browse through the list of files, edit the resulting path so that it shows the UNC name (which would begin with \\servername\sharename) rather than the relative name (which would begin with the drive letter you have assigned to the server during the current session). Also, choose the Automated Setup command line, as shown in the following screen.

   

   As with the ScanDisk package, you can choose to have SMS inventory this package. If you select this checkbox, as shown in the following screen, SMS will copy the installation log file from the target workstations to the SMS site server, where it can be examined by an SMS administrator.

   

5. When you are satisfied with the package, click OK until the Package Properties dialog box is closed.

   When the package has been created and appears in the Packages window, you can include it in a job, as shown in the following screen.

   

For more information on creating packages, see the Systems Management Server Administrator's Guide, Chapter 10, "Packages."

Create a Job to Execute the Package

For the command in the setup package to be run on the target computers, it must be made available in a Run Command on Workstation job. The job is created in the same way as the ScanDisk job was created, by dragging the package to the Machine Group on the site and filling in the Job Details dialog box that appears as a result. Use the following screen as a model for the job details.

You will probably want to set the value in the Expires After list box to something less than the default of 6 months. Once a job is distributed, the associated instructions are kept in the instruction file on each affected logon server until the job expires or is canceled, even after the job has completed on all target computers. This consumes about 3K per job per logon server. Specify an expiration date that is realistic for your organization and for the job.

You might also choose to take advantage of the job scheduling and configuration options, as shown in the following screen. If so, remember to set the priority to Low.

After you have set up the job, it should appear in the Jobs window as a pending job, as shown in the following screen.

For more information on jobs, see the Systems Management Server Administrator's Guide, Chapter 11, "Jobs."

Evaluate Distribution Results

You can monitor the job status as you did for the ScanDisk job.

A "complete" job status does not necessarily indicate successful deployment of Windows 95. You must perform additional analysis to determine results.

First, make sure that the SMS Workstation Inventory update has been performed for all computers in the target group of workstations. Then use the "Successful Windows 95" and "Unsuccessful Windows 95" SMS queries provided with this guide, run against the same targeted group of workstations, to determine results. (The machine groups you made from query results earlier can be used to define your targets now.)

You will probably want to examine the computers that were not successfully upgraded on a case-by-case basis. If you marked the Inventory this package check box in the Setup Package for Inventory dialog box, a copy of the setup log file created on each target computer is available to the SMS administrator. This file should be studied to determine the cause of any problems. For example, there might have been changes in available disk space or in the availability of some other resource between the time the computer was added to the target group and the time the upgrade was performed.

The computers that were successfully upgraded should be tested to make sure that the configuration you specified works as expected on these computers.

Job Events

You can check details of job events to troubleshoot problems. This is described in the Systems Management Server Administrator's Guide, Chapter 11, "Jobs," under "Viewing Job Events and Status."

For example, if a job has failed, the .INF file was not available where it was expected; this would be reported in the job events, as shown in the following screen.

To view the job events

1. From the SMS Administrator window, click Jobs. The Jobs window appears.

2. Select the job.

3. From the File menu, click Properties. The Job Properties dialog box appears.

4. Click Status. The Job Status dialog box appears.

5. Click Details.

Service and Component Trace Logs

Usually, the job event details provide you with all the information you need to resolve any problems with failed jobs. If you need more information, you can use the SMSTRACE utility to examine trace logs for the services and components in the SMS Executive service. The SMS Executive and its components are described in the Systems Management Server Administrator's Guide, Appendix A, "SMS System Reference."

SMS maintains a log for each component of the SMS Executive. These log files can be examined if the job failed or produced unexpected results to help you pinpoint the source of the problem.

To determine which log file to examine, first use the flow charts in the Systems Management Server Administrator's Guide, Appendix C, "SMS System Flow," to determine which component was active when the failure occurred. These flow charts, and the accompanying text, describe the actions of each component and the files involved. Using File Manager, you can check for the existence of files created by the various components. You know the process failed at the point where an expected file is not found.

For example, the flow of Run Command On Workstation jobs includes a step in which the Sender transfers the instruction file to the target SMS site as a .TMP file and then renames it as a valid instruction file (*.INS). If the .TMP file appears on the target computer but is not renamed to *.INS, then the error affected the Sender component. To learn the nature of the error, examine the log file for the Sender component.

SMSTRACE.EXE, which you copied to your SMS server while setting up the lab, is used to view these log files. When you start this program, the SMS Tracer window appears. You can open a log file by clicking Open from the File menu to view the contents of the log file. The following screen shows three log files.

For more information on trace logs, see the Systems Management Server Administrator's Guide, Appendix J, "Tracing SMS Services."

Post-Deployment Queries

The queries "Successful Windows 95" and "Not Successful Windows 95" are used to evaluate the results after SMS has been used to deploy Windows 95.

Note: SMS queries are directed at the SMS database, not the target computers themselves. For the results to be meaningful, allow time after the job is run for the database to be updated before you query for successful deployment. The time intervals for hardware inventory frequency and software inventory frequency are set for each SMS site in the Site Properties window. By default, the inventories are performed each time the user logs on.

Execute these queries to determine which workstations have Windows 95 successfully installed and which do not. Modification of these two queries is probably unnecessary, unless you wish to add additional criteria to the definitions of a "successful" Windows 95 installation. For example, you might want to add the criteria Free Disk Space greater than 10 MB. Any of the query options can be altered through the Queries Properties in the SMS Administrator.

The "Successful Windows 95" query is as follows:

Microsoft|Operating_System|1.0:Operating System Name is
Þ 'MS Windows 95'

The "Not Successful Windows 95" query is as follows:

Microsoft|Operating_System|1.0:Operating System Name is 'MS DOS'
   AND
Microsoft|Operating_System|1.0:Version is not '7.00'

If you want to deploy Windows 95 and Office for Windows 95 in one pass, you'll also need to run the queries provided to help you select target computers for both Windows 95 and Office for Windows 95.

Additional Help

If you need to contact Microsoft Product Support for help with the deployment, be sure that you have copies of the following for the time the problem occurred:

• Registry dump of the SMS key

  Trace logs:

  • Drive:\SMS\LOGS\*.LOG

  • Drive:\SCMAN.LOG

  • *.LO_ files

• The .PDF file or files used in your deployment of Windows 95 and/or Office for Windows 95

• The .INF file or files used in your deployment of Windows 95

• The .STF file or files used in your deployment of Office for Windows 95

• The SETUPLOG.TXT files for the computers on which installation failed

Also, have ready a description of the job details.

Test the Installation

When all has gone well with the job, test the computers in your lab network to make sure that the configuration you have installed will serve your organization as expected. The following suggestions are taken from the Windows 95 Resource Kit, Chapter 2, "Deployment Strategy and Details":

• Connect to and browse through the network.

• Set up a printer and test printing to local and network printers.

• Open, run, and close applications on both the client computer and the server.

• Shut down completely.

Test all mission-critical applications for proper function. If you encounter problems, try removing related features from the proposed configuration as a solution. Document any changes made to the original configuration.

If the preferred client configuration works as expected, you may want to conduct additional testing of the optional software features and components in Windows 95. This can help you determine whether you are running Windows 95 optimally. For this kind of testing, conduct side-by-side evaluations on two computers, changing individual features on each one, to determine the following:

• Performance in terms of responsiveness and throughput

• Ease of use

• Stability

• Compatibility

• Functionality

To evaluate network client software for Novell NetWare, run your network performance tests in the following configurations:

• Windows 95 installed with an existing 16-bit, Novell-supplied workstation client (NETX), using ODI drivers

• Windows 95 added to an existing installation of Windows 3.x and NetWare, using Client for NetWare Networks and protected-mode networking support components (NDIS adapter drivers)

• Windows 95 as a new installation using all protected-mode components, including both Client for NetWare Networks and Client for Microsoft Networks, plus peer resource sharing support

Perform several common tasks, such as connecting to the network and administering a remote NetWare server, to test for ease of use. Similarly, you'll want to run any business-specific NetWare applications under Microsoft Client for NetWare Networks to make sure that they run compatibly. Any stability issues should become apparent during this testing.

When you have identified a configuration that performs well during testing, test the same configuration by using other hardware from your company.

Review Results and Adjust Plan

When all the lab tests have been completed, the deployment team needs to review the results. What adjustments had to be made? How could the process be streamlined? Are your plans for preparing the users adequate, or should additional information be provided to them before deployment?

By using the results of the lab tests, you might choose to alter your high-level plan. Test the changes in the lab to ensure that they don't need further adjustment. In some cases, this can mean reconfiguring the lab so that it again simulates your organization's predeployment environment and repeating the test deployment. It is more time effective to repeat the tests in the lab than to disrupt part of your production environment with a pilot deployment you are not quite ready for. When all is complete and you have created an installation checklist, continue to the next step, which is planning and implementing the pilot rollout.

Create an Installation Checklist

For use in the pilot and final rollouts, it is a good idea to create a simple checklist of all the steps you performed in the lab. If you need to bring in additional team members (perhaps at remote locations) to help with the rollout, they can use the checklist to ensure that no steps are left out. Even when the rollout is performed entirely by those who became familiar with the process in the lab, a checklist allows attention to be focused on special cases rather than on reconstructing the sequence of steps in the process.