Using Microsoft Systems Management Server 2.0 to Deploy Microsoft Windows XP and Microsoft Windows Server 2003

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.

Using Microsoft Systems Management Server 2.0 to Deploy Microsoft Windows XP and Microsoft Windows Server 2003

Scalable Management for Microsoft Windows-based Systems

Technical Paper

Abstract

This technical paper explains a systematic approach to deploying the Microsoft Windows XP and Windows Server 2003 operating systems by using Microsoft Systems Management Server, including package preparation, package distribution, advertising, and monitoring.

Introduction

Microsoft Systems Management Server (SMS) provides a variety of tools to help you deploy the Microsoft Windows .NET Server and Windows XP Professional operating systems in an enterprise environment. SMS is not intended to be used to distribute Windows XP Home Edition. Project leaders and analysts, Windows XP technical analysts, and SMS administrators involved in this process should become familiar with the recommended configurations and procedures described in this technical paper. Although these recommendations also work for smaller organizations, the focus is on organizations with at least 2,500 personal computers.

You do not need to be familiar with SMS version 2.0 to understand the information in this technical paper. However, you do need someone with SMS expertise to perform your Windows XP or Windows Server 2003 deployment. It is presumed that your SMS infrastructure is in place or that you will put an SMS infrastructure in place prior to deploying Windows XP or Windows Server 2003.

Because Windows XP and Windows Server 2003 deployment is similar to Windows 2000 deployment there are several references in this technical paper to existing Windows 2000 documentation. These references should help you understand the principals and requirements for deploying Windows XP or Windows Server 2003.

Windows XP and Windows Server 2003 are very similar when it comes to distributing them with SMS this technical paper mainly focuses on deploying Windows XP, you can use the same methods and processes to deploy Windows Server 2003 except where explicitly noted otherwise, such as package and program setup.

Note When this technical paper was written Windows Server 2003 had not been released. The information provided in this technical paper in reference to Windows Server 2003 was accurate when this technical paper was written but is subject to change with future versions of the Windows Server 2003 operating system. This technical paper also presumes that Service Pack 3 or higher has been applied to SMS 2.0.

Using SMS to Distribute Software

Deploying Windows XP on a large scale is much simpler when you use automated installation. However, there are still many tasks involved when you apply automated procedures to multiple servers and client computers throughout your organization. These tasks include:

Selecting computers that are equipped for Windows XP and that you are ready to support.
Distributing Windows XP source files to all sites, including remote sites and sites without technical support staff.
Monitoring the distribution to all sites.
Securely providing enough operating system rights to do the upgrade.
Automatically initiating the installation of the software package with the possibility of allowing the user to control the timing.
Resolving problems related to the distributions or installations.
Reporting on the rate and success of deployment.

SMS can help you with all these tasks. The primary tasks involved in deploying Windows XP with SMS are illustrated in Figure 1.

Figure 1 Deploying Windows XP with SMS

SMS provides tools for upgrading your current computers but not for installing new computers that do not have an operating system already installed. To use SMS software distribution, you must install SMS client components on the destination computers. These SMS components require that the computer has a properly configured operating system.

Note The phrase "SMS client" refers to all destination computers regardless of their function. They might be servers or clients running the Windows operating system. Note You can also use SMS to help you with other Windows 2000 and Windows XP deployment activities. For more information about using SMS in your Windows 2000 deployment, see "Using Systems Management Server to Analyze Your Network Infrastructure" in the Windows 2000 Deployment Planning Guide at https://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp.

Software Distribution with SMS 2.0

SMS software distribution is based on multiple components and tasks, which allow you to completely control the process.

SMS Packages

SMS software distribution starts with an SMS package. The package, the basic unit of software distribution, contains the source files for the program and the details that direct the software distribution process.

Each package contains at least one SMS program*,* which is a command line that runs on each targeted computer to control the execution of the package. Programs can direct the installation of software or contain any other command line to be run at each targeted computer. Most packages also contain package source files, such as software installation files, that are used by the program when it runs.

Some software applications provide extensive installation options. Other packages and tools do not. If the program you want to distribute does not provide appropriate setup options, such as unattended operation, you can use SMS Installer to prepare your program for software distribution. SMS Installer can generate attended and unattended installation scripts that you can customize. This kind of scripting is not appropriate for the Windows XP upgrade. However, it might be useful for packages that are sent prior to the Windows XP upgrade to prepare the computer, or for packages that are sent after the upgrade to finalize the configuration. For more information about SMS Installer, see "Creating Self-Extracting Files with SMS Installer 2.0" in the Systems Management Server Administrators Guide.

You can create a package by using Packages in the SMS Administrator console, or you can create or obtain a package definition file and use the Create Package from Definition Wizard. A package definition file is an alternative, non-interactive way to create a package. It is a formatted file that contains all of the information that is necessary to create the package. A package definition file for Windows XP Professional and Windows Server 2003 is available on the Microsoft Windows Web site. You can use SMS tools and wizards to create packages from package definition files with minimal user interaction. When a package has been created, use the SMS Manage Distribution Points Wizard to choose the distribution points.

Distribution

Packages also contain information about software distribution, such as the directory for the package source files. Distribution Points are shares on SMS site systems where the package source files are copied for access by client computers. Packages also include information about how and when to update distribution points. For ease of administration, you can group distribution points into Distribution Point Groups.

When package files need to be propagated to other sites, SMS compresses these files for sending between sites. You can also create and use a compressed copy of the package source files within the originating site.

You can control the distribution of a package by using Distribution Points, which is under the package definition (in the SMS Administrator console, under Packages).

Advertising

After you create the Windows XP package, you advertise one or more of the packages programs to your users by creating an advertisement. An advertisement specifies what program is available to client computers, which computers will receive the advertisement, and when the program will be scheduled for installation. Figure 2 shows the software distribution process.

When an advertisement is received at an SMS client, the user can still have some control over the scheduling of the SMS program. You can run the advertisement in a special privileged mode so that you need not give administrative privileges to users. You can also run the advertisement so that it operates without any user intervention.

You create an advertisement by using Advertisements in the SMS Administrator console.

Figure 2 SMS 2.0 Software Distribution Process

For more information about SMS software distribution, see the Systems Management Server Administrators Guide.

SMS Software Distribution Best Practices

With large software distributions, such as Windows XP, it is important to note the two phases of SMS 2.0 software distribution: distribution and advertising. Distribution gets the software close to the computers that you want to upgrade. Advertising lets the clients know that the upgrade is available. With a package as large as Windows XP, the distribution phase consumes a great deal of resources, and problems could arise due to lack of disk space. Therefore, make sure to plan and monitor the distribution phase carefully. After you have successfully completed the distribution phase, begin the advertising phase.

Test your distribution by first distributing Windows XP to only one site. Also, you should send the initial advertisement of the package only to a few clients at that site. This allows you to test your SMS infrastructure and procedures on a limited scale. As your confidence increases and as capacity allows, you can distribute the package to more sites and increase the scope of the advertisement to include more clients and sites until you eventually include your entire organization.

Additional best practices are included in the following discussions of the software distribution process.

Note: For other best practices for working with SMS see the technical paper SMS Site Design Best Practices at https://www.microsoft.com/smserver/techinfo/deployment/20/deploysms/bstprac.asp

How SMS Can Help with Windows XP Deployment

The following sections explain how SMS can be particularly helpful for deploying Windows XP.

Sending Windows XP Source Files Out to All Sites

SMS has senders that can send files over a wide variety of network protocols and over virtually any kind of network link. Senders provide several benefits over traditional file transfer methods. They can:

Use only a fraction of the network bandwidth, allowing other business functions to continue at the same time.
Forward packages only during specified hours, such as when most users are not using the network.
Check the files as they are transferred so that if the network link fails, the transfer resumes at the latest checkpoint rather than at the beginning of the transfer.
Choose an alternate route to the destination.
Use the SMS hierarchy to get the packages to the sites, rather than sending the packages to all sites directly from the originating site.

Using SMS and its senders can be beneficial for distributing large software packages when your sites are remote, particularly if they have no technical support staff. In such cases, you can reliably distribute Windows XP software to all sites without interfering with other business functions.

Monitoring the Distribution to All Sites

SMS automatically sends a status message as each step is completed, and you can easily monitor these messages by using the SMS status subsystem.

Selecting Computers

Because deploying Windows XP upgrades is a large, complex, high-profile process, you need to deploy it in phases. This spreads out both the network activity and required support. Also, all your computers might not be ready to receive the package at the same time; for example, some computers might not have enough memory or disk space. SMS collects inventory details about your computers and allows you to create queries that select appropriate computers. You can increase the size of the selections as your confidence in the process increases.

Collections of inventory details automatically can include any additional computers that now meet the selection criteria. For example, consider a collection that is defined to include computers with 64 megabytes (MB) of memory or more. If you added 32 MB to an SMS client computer that had 32 MB, it would then qualify to receive the Windows XP Professional upgrade and will be included in the collection automatically.

Securely Providing Enough Operating System Rights

Operating system upgrades affect all aspects of a computer and, therefore, require that end users have broad access rights. You might be hesitant to give such broad permissions to users who do not have an in-depth knowledge of computers or of important company policies and procedures. SMS does have special privileges and can run the upgrade in a high rights user context.

Automatically Initiating the Installation

Upgrades can be either initiated automatically or initiated by users. You can set up the process so that even when users are involved, they do not have to choose between complex options. You can give users the option to control the timing so that the upgrade can occur when their computers are not in use.

Resolving Problems

If the upgrade to Windows XP causes problems on a particular computer, SMS features help provide a solution. The status and inventory information that SMS provides can supply many details about the computer from a central, convenient source — the SMS Administrator console. You can also use SMS remote tools to remotely control the computer, transfer files, or manipulate the computer in other ways (as long as the SMS client is functional). If the user has an incompatible application or an application that might benefit from being reinstalled, you can use SMS software distribution to automatically update or remove it.

Reporting Status

SMS status messages are generated not only for the distribution of the package but also for the advertisements and the installation on computers. You can use these status messages to report on the rate and success of deployment.

The steps required to take advantage of these SMS features are described in the procedures following the following sections. The details for enabling the relevant SMS subsystems and using them effectively are included the SMS documentation.

Packaging Windows XP and Window .NET Server for SMS

When you use SMS to deploy Windows XP or Windows Server 2003, you must put the Windows XP or Windows Server 2003 files into an SMS package. You need to create separate packages for Windows Server 2003 and Windows XP Professional. These can be used as the starting point to create your Windows XP and Windows Server 2003 packages.

For each SMS program, SMS obtains the files from a distribution folder. You must include all the auxiliary files required to complete the upgrade, such as the Plug and Play device drivers and answer files. You can even include standard applications, language packs, and service packs. For typical Windows XP and Windows Server 2003 deployments, the details provided in this technical paper should be sufficient, but "Allowing User Input During the Upgrade" later in this technical paper, will be useful if you have special requirements.

Warning: Windows XP and Windows Server 2003 require the folder structure and name i386. Do not attempt to modify or change the name of the i386 folder or your software distribution will fail.

Each Windows XP and Windows Server 2003 SMS package definition also contains SMS programs. Each program is a different combination of options that you create for installing the Windows XP or Windows Server 2003 package. For example, your default program might be to install Windows XP with no user intervention. If you want to allow power users to choose options, they need a different program. All these SMS programs must be compatible with the set of files for the package available at the distribution folder.

Preparing the Windows .NET Standard Server Upgrade Package

The following procedure describes how to set up a typical upgrade package for Windows Server 2003. The first step is to set up the location of the package source files for distributing Windows Server 2003.

To set up a location for the Windows Server 2003 SMS package source files:

On a disk with at least 600 MB of available disk space, create a directory.
If the directory in step 1 was not created on the SMS site server then make the directory available as a share.
Copy the entire i386 directory tree structure of the Windows Server 2003 CD-ROM to the directory created in step 1.

Be sure to preserve the directory hierarchy.
Create an unattended setup answer file in the directory created in step 1.

To create a Windows Server 2003 SMS package:

Set up a location for the SMS package source files, as per the previous procedure.
In the SMS Administrator console, click Packages, on the Action menu, point to New, and then click Package From Definition as shown in Figure 3.

Figure 3: Initiating the Create Package from Definition Wizard
Create a WinNET.SMS file, as discussed in the "The Windows Server .NET and Windows XP Package Definition Files" section. Then, in the Welcome dialog box, in the Package definition list, click Next, click Browse, and then choose the .sms file for Windows .Net Standard Server.
In the package definition list, click Windows .NET Standard Server.
On the Source Files tab, click Create a compressed version of the source, and then click Next.
In the Source directory box, enter the path to the package source files (see step 1), click Next, and then click Finish.

If the site server is extremely low on disk space, on the Source Files tab, you can choose Always obtains files from a source directory. In addition to saving disk space, this also ensures that there are source files in an alternate location for disaster recovery should the SMS site server be lost for some reason. However, this slows future distributions of the software, and you must ensure that the source directory is always available.
When the wizard finishes, under your new package, click Programs.
In the results pane (the right side of the console), double-click Automated upgrade from Windows 2000 Server, NTW 4 and verify that the predefined Command line is the correct setup command for your needs.

Repeat this step for the other programs that you use.
To verify that the predefined Command line meets your needs, see "Examining the Windows Server 2003 Package Definition" later in this technical paper.

Consider specifying an answer file in the program command line, which can allow you to specify a large number of configuration options. For more information about answer files, see "Automating Server Installation and Upgrade" in the Windows 2000 Deployment Planning Guide.

In the Comment box, enter a comment for each of the programs that you will use.

The end user can see your comments, so be sure they are descriptive. Give your users contact information, such as the name, phone number, or e-mail address of someone to contact for more information or report problems to.
On the Requirements tab for each program, adjust (if necessary) the Estimated disk space and Estimated run time to values that are appropriate for the upgrade you are doing.

These values are information for your users.
On the Environment tab for each program, verify that Program can run is set to Whether or not a user is logged on.

This setting ensures that the program is run with administrative rights, which is necessary for Microsoft Windows NT Server and Windows 2000 Server upgrades.
Click OK to close the Program Properties dialog box.
If you want to ensure that users do not upgrade their computers before you are ready to deploy Windows Server 2003, under your new package, click Access Accounts, and then in the results pane, delete the Guests and Users access accounts.

Note SMS hides the software distribution shares and that users would require administrative rights on the computers where those shares are located (or the computers would have to be running Microsoft Windows 98 or Microsoft Windows Me) for them to take advantage of the Window XP setup files.

You will have to give access to users who are authorized to upgrade to Windows NET Server at a later time.

Also, do not add or change any distribution points or create an advertisement at this time.

Caution If you want to use security to control who can adjust or deploy the package, see the chapter "Distributing Software" in the Systems Management Server 2.0 Administrators Guide.

If you require multiple Windows Server 2003 upgrade answer files to accommodate variations in your upgrades, you must create additional programs for the package in the SMS Administrator console. Each program will specify a different answer file for the winnt32 /unattend option. You can use separate answer files to upgrade different groups of computers in different ways while still using just a single package.

SMS 2.0 includes a variety of sophisticated options for packages and their programs. For example, you can specify that the Windows XP files be made available with a specific share name at your distribution points. This way they can easily be used by people performing manual upgrades as well as by SMS. The Systems Management Server Administrators Guide includes more details on these options.

The Windows Server .NET and Windows XP Package Definition Files

The following two sets of text can be used as package definition files when following the procedure give in the "Preparing the Windows .NET Standard Server Upgrade Package" section. These files should also be available for download from https://www.microsoft.com/smserver/default.asp.

Note Windows XP without a service pack and pre-release operating systems in the Windows Server 2003 family produce a status MIF with the MIFVersion property set to 5.0. This is the same value that Windows 2000 used. If you are deploying both Windows 2000 and Windows XP at the same time, advertisement status reporting could be inaccurate for this reason. When deploying Windows XP with SP1 (or later) incorporated (slipstreamed), or when deploying the final release of operating systems in the Windows Server 2003, the MIFVersion should be set to 5.1. Confirm this is the correct value in your testing.

Server

Copy the following text into a text file named WinNET.SMS:

[PDF]
Version=2.0
[Package Definition]
Language=English
Publisher=Microsoft
Name=Windows .NET Standard Server
Programs=unattendedx86, manualx86
MIFPublisher=Microsoft
MIFName=Windows NT
MIFVersion=5.0
[unattendedx86]
Name=Automated upgrade from Windows 2000 Server, NT 4.0 Server (x86 SP6)
CommandLine=i386\winnt32.exe /UNATTEND30 /BATCH /NOREBOOT
EstimatedDiskSpace=1700MB
EstimatedRunTime=90
AfterRunning=SMSRestart
CanRunWhen=AnyUserStatus
SupportedClients=Win NT (i386)
Win NT (i386) MinVersion1=4.0.1381.0
Win NT (i386) MaxVersion1=4.00.9999.9999
Win NT (i386) MinVersion2=5.00.0000.0
Win NT (i386) MaxVersion2=5.00.9999.9999
[manualx86]
Name=Manual upgrade from Windows 2000 Server, NT 4.0 Server (x86 SP6)
CommandLine=i386\winnt32.exe /NOREBOOT
EstimatedDiskSpace=1700MB
EstimatedRunTime=90
AfterRunning=SMSRestart
CanRunWhen=UserLoggedOn
UserInputRequired=True
AdminRightsRequired=True
SupportedClients=Win NT (i386)
Win NT (i386) MinVersion1=4.0.1381.0
Win NT (i386) MaxVersion1=4.00.9999.9999
Win NT (i386) MinVersion2=5.00.0000.0
Win NT (i386) MaxVersion2=5.00.9999.9999

Professional

Copy the following text into a text file named WinXP.SMS. This file should be used instead of the WinNET.SMS file when preparing the Windows XP Professional package.

[PDF]
Version=2.0
[Package Definition]
Language=English
Publisher=Microsoft
Name=Windows XP Professional
Programs=unattended32bitx86, manual32bitx86
MIFPublisher=Microsoft
MIFName=Windows NT
MIFVersion=5.0
[unattended32bitx86]
Name=Automated upgrade from Win98/98SE/ME, Windows 2000 Pro, NTW 4.0 (x86 SP6)
CommandLine=i386\winnt32.exe /UNATTEND30 /BATCH /NOREBOOT
EstimatedDiskSpace=1500MB
EstimatedRunTime=60
AfterRunning=SMSRestart
CanRunWhen=AnyUserStatus
SupportedClients=Win 9x, Win NT (i386)
Win 9x MinVersion1=4.10.1998
Win 9x MaxVersion1=4.10.9999.9999
Win NT (i386) MinVersion1=4.0.1381.0
Win NT (i386) MaxVersion1=4.00.9999.9999
Win NT (i386) MinVersion2=5.00.0000.0
Win NT (i386) MaxVersion2=5.00.9999.9999
[manual32bitx86]
Name=Manual upgrade from Win98/98SE/ME, Windows 2000 Pro, NTW 4.0 (x86 SP6)
CommandLine=i386\winnt32.exe /NOREBOOT
EstimatedDiskSpace=1500MB
EstimatedRunTime=60
AfterRunning=SMSRestart
CanRunWhen=UserLoggedOn
UserInputRequired=True
AdminRightsRequired=True
SupportedClients=Win 9x, Win NT (i386)
Win 9x MinVersion1=4.10.1998
Win 9x MaxVersion1=4.10.9999.9999
Win NT (i386) MinVersion1=4.0.1381.0
Win NT (i386) MaxVersion1=4.00.9999.9999
Win NT (i386) MinVersion2=5.00.0000.0
Win NT (i386) MaxVersion2=5.00.9999.9999

Allowing User Input During the Upgrade

Many SMS administrators consider it good practice to not allow user input during package installations. When users install software by themselves, the Setup program generally prompts for responses, such as on which disk to install the software or what options to install. Every user interaction introduces the opportunity for error that can later cause problems. Users might not understand the implications of the answers they provide. If even a small percentage of users make mistakes, the number of help desk calls can be overwhelming at a time when you are upgrading thousands of computers.

Another reason to prevent user input during an upgrade is to allow the installation to occur while no one is present at the computer so that you minimize the inconvenience to users.

Finally, providing all the answers in an answer file ensures that you maintain configuration standards. When you follow those standards, you simplify future computer maintenance and support by reducing the number of variables that could be relevant to a problem.

Providing an answer file with all the details required for the upgrade prevents the Windows Server 2003 Setup program from asking for user input. If some details are not provided (and the UnattendMode line in the answer file allows it) or if the /unattend command-line option is not specified, the program prompts the user for the details. This may be necessary for the Product Key unless your Microsoft licensing agreement allows you to re-use a single product key and does not require individual clients to get an activation code (for more information, see Windows XP Product Activation later in this technical paper). An answer file for a server upgrade might look like the following (you must change the ProductKey value):

; Microsoft Windows Codename Whistler Personal, Professional, Server, Advanced Server and Datacenter
; (c) 1994 - 2000 Microsoft Corporation. All rights reserved.
;
; Sample Unattended Setup Answer File
;
; This file contains information about how to automate the installation
; or upgrade of Windows Codename Whistler so the
; Setup program runs without requiring user input.
;
[Unattended]
Unattendmode = FullUnattended
OemPreinstall = NO
TargetPath = *
Filesystem = LeaveAlone
[UserData]
FullName = "Your User Name"
OrgName = "Your Organization Name"
ComputerName = *
ProductKey= "<Valid Product key>"

Note You must specify the answer file by using the command winnt32 /unattend:<answer.file>. The command winnt32 /unattend performs an unattended upgrade, but it gets the information it needs from the current configuration. It will prompt the user for a product ID. You can also include /batch on the command line if you like.

For more information on the settings and sections of unattended answer files see Ref.chm which is located in \Support\Tools\Deploy.cab on your Windows XP CD-ROM.

Examining the Windows .NET Server Package Definition

The Windows Server 2003 package definition that is available from the Microsoft Web site includes predefined programs. Review these programs to understand how the upgrades are performed.

The Windows Server 2003 upgrade from Windows NT Server includes the options /unattend30 and /batch. The first option, /unattend30, means that you are going to do an unattended upgrade and that all the required information is to be taken from the current installation. The computer will restart 30 seconds after the Setup program completes its first phase, which is when the files are copied to your computer. An answer file is not used.

The /batch option specifies that Setup not display any error messages. This is appropriate when you are sending the package to users whom you do not want involved in the setup or if you are running the upgrade when no one is at the computer. However, if there are problems with the upgrade, such as a lack of disk space or an incorrect Start in directory, this will not be readily apparent, because no error messages will appear. However, you can find error information in the SMS status messages generated as a result of the operation, and also in the log files in the Windows or Winnt directory on the client. If you encounter problems in your testing and the status messages are insufficient, remove the /batch option to allow errors to be displayed during package testing. Also, with the /batch option, if the user clicks Cancel during the first phase of the Windows XP Setup, the user will not be asked to confirm that they want to stop the setup.

The estimated disk space and run time values included in the SMS 2.0 package are estimates that might not be realistic for your environment. You might want to increase them. These values are informational only and for the benefit of the user.

If you include an answer file in the command line of the package program, you can specify many of the options for your upgrade. For example, you can specify on which disk Windows XP is to be installed, or whether an upgrade or new installation needs to be done.

Note: On the Environment tab the program is set up to run with administrative rights securely provided by SMS. This is an important benefit when you are upgrading clients that run Microsoft Windows NT Workstation 4.0 or Windows 2000 to Windows XP Professional. This feature means that you do not have to give administrative privileges to users. It can also be important when servers are owned by business units and when central administrators have rights on the servers only through SMS.

Preparing the Windows XP Professional Upgrade Package

To upgrade computers to run Windows XP Professional by using SMS, you must first create a Windows XP Professional package. You prepare and use this package in much the same way as the Windows Server 2003 package. Begin by following the procedure to create a Windows Server 2003 package, but be sure to specify that this is a Windows XP Professional package, and use the WinXP.SMS file. Because there are special issues for Windows 98 and Windows Me upgrades to Windows XP, you must create a new package, as outlined in the following section.

Note Additionally, be sure to create a separate package when you use SMS to distribute Windows .NET Enterprise Server or other Windows Server 2003 versions. Although many files and setup details in this program are the same as those in Windows Server 2003, there are enough differences to require each version to have its own package. You can use the basic Windows Server 2003 package definition as a starting point when creating packages to distribute other Windows Server 2003 versions.

Windows XP Product Activation

A new requirement for Windows XP and Windows NET Server is the product activation process. If a computer running Windows XP or Windows Server 2003 is not activated within 30 days after installation it will become unusable. This requirement is in addition to the product key. To enable automatic product activation, you can add the following line to the answer file in the Unattended section:

AutoActivate=Yes

In addition, it might be necessary to add ActivateProxy to your answer file if it will be necessary to go through a proxy server to reach the Internet for product activation. For more information on the AutoActivate and ActivateProxy options, see Ref.chm, which is located in \Support\Tools\Deploy.cab on your Windows XP CD-ROM.

Windows 98 and Windows Me Upgrades

In addition to the differences in the source files, a significant difference between the Windows Server 2003 and Windows XP Professional upgrades is in the answer file. When upgrading computers that are running Windows 98 or Windows Me to Windows XP Professional you must account for the lack of prior domain participation. Computers running Windows 98 or Windows Me have not been members of a domain (even if the users using them have been logging on to a domain), and have not had local accounts (although they have had local profiles and password list files). Also, the SMS client must be upgraded from the version run on Windows 98 or Windows Me before it can run successfully on Windows XP. Therefore, relevant details must be specified in the answer file, such as the following (you must change the JoinDomain, DomainAdmin, DomainAdminPassword, and ProductKey values):

; Microsoft Windows Codename Whistler Personal, Professional, Server, Advanced Server and Datacenter
; (c) 1994 - 2000 Microsoft Corporation. All rights reserved.
;
; Sample Unattended Setup Answer File
;
; This file contains information about how to automate the installation
; or upgrade of Windows Codename Whistler so the
; Setup program runs without requiring user input.
;
[Unattended]
Unattendmode = FullUnattended
;the following line is needed to get UpdateSMSClient.bat copied to the client
OemPreinstall = Yes
Filesystem = ConvertNTFS
Win9xUpgrade=Yes
AutoActivate = Yes
[GuiUnattended]
; Sets the Admin Password
AdminPassword = temporary
;the following two lines are needed because we used OemPreinstall
OemSkipWelcome=1
OemSkipRegional=1
[GuiRunOnce]
; List the programs that you want to launch when the machine is logged into for the first time.
; This batch file will use the logon point that the user logged on to run SMSLS.BAT. This will
; ensure the SMS client becomes functional again as soon as possible.
; You could also create and run another program (written in C or another language) to set the local
; administrator password to a value that is hidden in the executable.
C:\UpdateSMSClient.BAT
[Identification]
JoinDomain=RED1DOM
; minimize the privileges of the following account
DomainAdmin=JoinComputers
DomainAdminPassword=secret
[UserData]
ProductKey="<Valid Product key>"

For more information on the settings and sections of unattended answer files see Ref.chm which is located in \Support\Tools\Deploy.cab on your Windows XP CD-ROM.

To set up a location for the Windows XP Professional SMS package source files needed for upgrade from Windows 98 or Windows Me:

On a disk with at least 550 MB of available disk space, create a directory.
If the directory in step 1 was not created on the SMS site server, make the directory available as a share.
Copy the entire i386 directory tree structure of the Windows XP Professional CD-ROM to the directory created in step 1.

Be sure to preserve the directory hierarchy.
Create an unattended setup answer file in the directory created in step 1.

Alternately, edit the sample Unattend.txt file in that directory. Additional details about the answer file are provided later in this technical paper.
Create a $OEM$ directory under the directory created in step 1, and then create a C (the letter C, only) directory inside the $OEM$ directory.
Create a batch file called UpdateSMSClient.bat under the $OEM$\C directory.

The batch file must include the line "%LOGONSERVER%\NETLOGON\SMSLS.BAT".

Note SMSLS.BAT will not exist in this location unless you have set up your SMS Logon points. For more information, see Using Logon Scripts and Logon Points in the Systems Management Server Administrators Guide.

The options available for setting up a Windows 2000 source are described in greater detail in the chapter "Automating Server Installation and Upgrade" in the Windows 2000 Deployment Planning Guide at https://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp

In the preceding procedure, steps 4 through 6 are optional. These steps ensure that the client reruns the SMS client setup procedures as soon as possible, so that files that are Windows 98 and Windows Me-specific SMS client components are replaced with Windows XP SMS client components. However, if you normally have SMS logon scripts enabled, or if you intend to manually run the SMS client setup procedures after the computer is upgraded, this solution is not required. If you don't use steps 4 through 6, you also will not need the GuiRunOnce section in the answer file, nor the OemPreinstall, OemSkipWelcome, and OemSkipRegional lines.

After you have set up the location for the Windows XP Professional SMS package source, you can follow the same procedures for creating a package like those used in the Windows Server 2003 upgrade package section earlier in this technical paper. However, in step 3 of the procedure to create a Windows Server 2003 SMS package, import the Windows XP Professional package definition, rather than the Windows NET Server package definition. Also, in step 5 create a new program, modeled on the predefined program, rather than modifying the current program. You cannot change the name of SMS programs, but you will want a program name that clearly indicates that this is an automated upgrade from Windows 98 or Windows Me ("Win9x") only. (Upgrading from Windows NT Workstation 4.0 or Windows 2000 is described in the next section.)

A computer that is upgraded from Windows 98 or Windows Me to Windows XP Professional is given a local Administrator account. This account requires a password; you can specify that password in the GUIUnattended section of the answer file or let the user be prompted for it at the end of the upgrade. This password can be read from the answer file by anyone that can access the SMS package share, which is commonly most users. This is not an immediate security risk because computers running Windows 98 and Windows Me were not secure before the upgrade, due to the non-secure nature of those operating systems.

You might want to set the administrator account password to a secure value and begin enforcing limited user privileges. You can do this after the upgrade by running a program that changes the password from the temporary value specified in the answer file (and which could be seen by unauthorized people) to a value shared only with authorized staff. The password is compiled within the program and is not available to unauthorized staff. You can easily create such programs by using common programming languages or scripting tools, such as SMS Installer. You can distribute the program with SMS, or you can invoke the program at the end of the Windows XP upgrade by specifying appropriate values in the answer file. Another alternative is to use the Cusrmgr.exe utility from the Windows 2000 Resource Kit to change the password to a random (and unknown) value. In that case you must be sure to first add Domain Admins or a similar group to the local Administrator group so that someone can still manage that computer.

A better alternative is to encrypt the password for the administrative account in the answer file. You must use the Setupmgr.exe tool provided on the Windows XP Professional CD-ROM to create an unattended installation answer file. Setupmgr.exe is located on the CD-ROM in Support\Tools\Deploy.cab. In the Administrator Password dialog box, select the Encrypt administrator password in answer file check box. Setupmgr.exe will create an answer file with the following lines in the GuiUnattended section:

AdminPassword=<encrypted password string>
EncryptedAdminPassword=Yes

Use these lines in the GUIUnattended section of the package answer file to assign a local Administrator password. Users who see the file will not be able to determine the password, as it will be encrypted.

Although computers that run Windows 98 and Windows Me are not members of domains, computers that run Windows XP Professional must be. Therefore, you need to include the JoinDomain line in the answer file to indicate which domain the computer needs to join, along with an administrative account and password with the right to join computers to that domain.

Caution Answer files can be read by unauthorized staff so you need to consider security issues when you create them. However, it is unlikely that people would gain access to the files from an SMS distribution point because the distribution points are hidden and they must know where to look for these details. An appropriate precaution, however, is to use an administrative account whose only right is Add workstations to domain. Another precaution is to add the computers upgraded in this manner to a dedicated resource domain. In that case the administrative account only needs to have rights in that domain, and therefore cannot cause problems in other domains in which you might have account domain controllers or other sensitive computers.

The answer file must also specify that you want to upgrade the computers that are running Windows 98 or Windows Me. Do this by including the following line in the answer file:

Win9xUpgrade=Yes

Without this line, you do a clean installation of Windows XP rather than an upgrade.

During the Windows 98 or Windows Me upgrade to Windows XP, the Windows XP Setup program eliminates programs that it suspects might be incompatible with Windows XP. This occurs for some of the SMS 2.0 client components. This is why you must run SMSLS.bat or SMSMan.exe on each client after upgrading it.

Windows NT Workstation 4.0 and Windows 2000 Upgrade

Upgrading from Windows NT Workstation 4.0 or Windows 2000 to Windows XP is quite simple compared to upgrading from Windows 98 or Windows Me. This is because Windows NT Workstation 4.0 and Windows 2000 have much more in common with Windows XP Professional. For this reason, you can upgrade with a minimal answer file. In fact, you can use a copy of the answer file used for the Windows Server 2003 upgrade (except that the product ID must be changed to a valid Windows XP Professional product ID).

It is important to set the Environment properties of the SMS program so that it runs with administrative rights, unless users will be logged on and have administrative rights when the package is initiated at client computers.

The package and package source location set up for the Windows 98 or Windows Me upgrade to Windows XP Professional can be used for the Windows NT Workstation 4.0 or Windows 2000 upgrade as well. The $OEM$ file and directories are not required, but they will be ignored, since the answer file does not reference them. Using the same package (as opposed to a new one) is preferable to avoid duplicating the disk space and network usage of distributing another package. The answer files for Windows 98 (and Windows Me), and Windows NT Workstation (and Windows 2000) can be included in the same package. Their file names should clearly identify which is which.

You must create a new SMS program in the Windows XP Professional package for the Windows NT Workstation or Windows 2000 upgrade. This is set up much the same as the Windows Server 2003 or Windows 98 (or Windows Me) upgrade programs. By creating a new program you can give it a new name that clearly identifies this as a program for upgrading computers running Windows NT Workstation or Windows 2000 (only). The program must use the appropriate answer file.

Distributing the Windows XP and Windows .NET Server Packages

You need to distribute the SMS package files for Windows XP to all sites where you anticipate upgrading computers. Distribution is involved even if you have just one site. Distribution consists of sending the package files to the site, and then getting the files to the SMS distribution points within the site.

Preparing to Distribute the Packages

Before you distribute the Windows XP packages, there are several tasks you must perform to ensure that your SMS hierarchy is ready to receive them. Each of these tasks are described in the following sections.

Check the Status of Site Servers and Distribution Points

Windows XP is a large operating system that requires considerable disk space. Not only are copies of Windows XP required for computers to be upgraded, but SMS also needs copies as it moves the package between servers. Therefore, you must review your site servers and distribution points to ensure that they have enough disk space. The easiest way to do this is to go to System Status in the SMS Administrator console, click Site Status, and then for each site, click Site System Status as shown in Figure 4. The results pane displays the distribution points and their free disk space. Depending on your SMS configuration you may need to have enough space for two to three times the package size available on your SMS Site server.

Figure 4: Site Status with Distribution Points and Their Free Space

Ensure Each Site Has an Adequate Number of Distribution Points

You might want to limit the number of Windows XP upgrades that you perform concurrently at each site. Upgrades can impose a heavy load on the local network and the distribution points. Before you upgrade, you need to experiment in a lab or run a pilot. When you test, use servers that are typical of your distribution points and a typical network. This will allow you to judge how many clients you can comfortably upgrade at one time.

If you find that your network is not a bottleneck for the upgrades but that your distribution points are, consider adding more distribution points at the site. For more information about how to add distribution points, see "Distributing Software" in the Systems Management Server Administrators Guide.

Use Distribution Point Groups

Because the Windows XP package is quite large and you will use it extensively, you may want to dedicate distribution points for this package. You can refer to these distribution points as a group. You can create a distribution point group for your Windows XP distribution points to reduce the number of administrative tasks.

You can create distribution point groups (and add or remove distribution points from the groups) when you are creating or adjusting distribution points. Then, during distribution, you can specify the distribution point groups at the same places that you specify distribution points. For more information about distribution point groups, see Managing Distribution Point Groups in the Systems Management Server Administrators Guide.

Ensure Sender Controls Are in Place

If the Windows XP package is sent to any site that does not have adequate sender controls in place, it can overload the network link at a time when it may interfere with other business functions. Therefore, check the sender controls to be sure they are properly set.

The SMS Administrator console includes SMS address definitions for each site that it directly communicates with. SMS addresses include the SMS site server name, security details for accessing that site, and network transport details (if required). The addresses also include a schedule to specify when high, medium, and low priority transfers can be executed, and how much of the network link can be used at any time of the day.

Ensure Fan-out Distribution Will Work

SMS 2.0 has a feature called fan-out distribution, which allows child sites to distribute software to lower sites. This reduces the workload on the site that you use to initiate the software distribution because the software does not need be distributed from the initiating site to all sites. This also reduces the workload on the network link between the initiating site and the rest of the sites, which is often the most significant issue. When you are distributing a package to many sites, copying Windows XP over the network many times from any site can cause an unacceptably heavy load. Figure 5 illustrates the difference between software distribution with fan-out and without fan-out distribution.

Figure 5 Two Types of Software Distribution

Fan-out distribution occurs automatically if the initiating site does not have an SMS address for the destination site. Therefore, you must use the SMS Administrator console to review the SMS addresses for each site and make sure that the site only has addresses for direct parent and direct child sites.

Select a Test Site

To ensure that your plan is complete, distribute the Windows XP package to a test site or a small number of sites before sending it to your entire organization. This will enable you to quickly correct problems and to minimize their impact.

The test site or sites should be as typical as possible, but at least one site should also represent a high-risk scenario. Examples of such a scenario include deploying with a site server or distribution points that have very little disk space to spare, or having a network link that is particularly slow or unreliable.

A best practice for this level of testing is to start with small sites that do not have complex requirements. An ideal test site has a support staff ready to assist you if needed and users who are willing to run your test software distribution. At such sites, you can identify solutions for any problems that you might not have built into your contingency plans during deployment planning. As your confidence in your procedures increases, expand your testing to sites that are larger, more complex, or more difficult to support.

During the distribution phase, your Windows XP deployment needs to be transparent to your users because you have not yet run the upgrades on their computers. Caution is appropriate now but is more critical later in the deployment process.

For more information about the tasks presented in this section, see the Systems Management Server Administrators Guide.

Distributing the Packages to Sites and Distribution Points

The basic procedure for distributing packages is presented as follows. When you perform this task, note that all distribution points for all sites are listed, so you can select all the intended distribution points at one time. However, make sure that you first distribute the package to a small number of sites so that you can test your SMS infrastructure and procedures. As your confidence increases and capacity allows, you can include additional distribution points at other sites. For more information about this procedure, see "Distributing Software" in the Systems Management Server Administrators Guide.

To distribute a Windows XP SMS Package:

In the SMS Administrator console, click Packages, click the Windows XP package, and then click Distribution Points.
From the Action menu, point to New, and then click Distribution Points.

The New Distribution Points Wizard appears.
Click Next to continue past the Welcome dialog box, and then select the distribution points you want to use.

If this is a test distribution, select the distribution points that you decided on. Also, if you are using distribution point groups, select them now. Note that all distribution points for all sites are listed, so you can select all the intended distribution points now. However, you might do a limited number of distribution points at one time to better manage network traffic.
Click Finish to start the distribution.

Caution: As soon as you click Finish, the distribution process begins. You might notice a short delay, due to system processing, package priorities, or sender schedules; however, be prepared for immediate SMS activity.

For more information about the flow of a package after you initiate distribution, see "Software Distribution Flowcharts" in the *Systems Management Server 2.0 Resource Guide (*part of the Microsoft BackOffice 4.5 Resource Kit available at https://www.microsoft.com/mspress/). The Windows XP files are compressed into a single file that is then sent to child sites with distribution points that you selected. At each site, the package might then be sent to other child sites, if they have distribution points for this package.

Testing the Distribution

As the Windows XP packages are distributed, verify that they are arriving properly at the distribution points. "Monitoring the Distribution," later in this technical paper, describes how you can verify that the packages have arrived at all distribution points and how you can quickly identify any problems. However, you also need to test the distributions to ensure that they are complete and that the directory trees are properly laid out. You do not need to test all distribution points at this level, but make sure to spot-check a few distribution points to confirm that the production distribution is working as you intended.

Expanding the Distribution

When the first distribution of the package has been completed successfully, you can distribute the package to additional sites and distribution points. The procedure is exactly the same, except that you might want to send to more distribution points at a greater frequency and with less monitoring. You should make sure the package has reached the new sites before advertising the package to clients at those sites. SMS does not make the advertisement available to the clients until a distribution point is available.

Distributing by Means of the Courier Sender

Network links to some of your sites might be slow or unreliable, or they might already be fully utilized by other traffic. Therefore, sending a large package like Windows XP over the network links might not be acceptable. SMS 2.0 includes an alternate sender, called the Courier Sender, which you can use to provide all the benefits of SMS software distribution but without the network overhead normally involved in getting packages to sites.

With the Courier Sender, the SMS package is copied to CD-ROM or similar media, and then sent through mail or by courier to your sites. At the sites, someone puts the CD-ROM into the site server and runs a simple program. From this point on, the software distribution carries on as it normally would. The advertisements, status information, and other information will flow over the network at the times you specify; however, this traffic is small relative to the traffic that the package itself would have required if you had sent the package over the network

For more information about Courier Sender see the Systems Management Server Administrators Guide.

Monitoring the Distribution

Distributing Windows XP in an organization with many SMS sites takes some time to complete. Some sites will take longer than others due to the speed of the wide area network (WAN) links, the reliability of those links, sender scheduling, and other possible variables. There is also the possibility that, despite good preparations, some sites or distribution points might have inadequate disk space by the time the package arrives. For these reasons, it is important to give the Windows XP distribution adequate time to complete. Monitor it closely to determine if there are any issues to resolve and make sure that the distribution of the package is complete at all sites.

System Status Subsystem

SMS 2.0 includes a powerful System Status subsystem for monitoring the distribution. The SMS Administrator console includes a System Status node where you can obtain summary and detailed results from the System Status subsystem. You can also obtain the status of the package distribution from the Package Status subnode.

Note When you create a package, the definition of that package is immediately distributed to all child sites; however, the actual files for that package, if any, are not distributed at that time. The same package definition is re-sent when the package definition is updated. Status information for the package definition distribution is then available. Therefore, when reviewing package status, make certain you distinguish between the distribution of the package definition and the package files.

Software distribution status is summarized at several levels, as described in the following sections.

Package Status for All Packages

When you select Package Status (under System Status), you can see, as shown in Figure 6, how many distribution points have been targeted for each package and how many have been installed, are retrying, or have failed. This level is useful to identify how many distribution points, if any, might need intervention. Note the size difference between the original package and the compressed package. The package identification number might also be useful for other purposes, such as troubleshooting. At this level there are no status messages to query.

Figure 6 The Status of All Packages

Package Status for a Specific Package

Below the package status for all packages, you can select each package. At this level you can see, as shown in Figure 7, which sites should or should not have the package, and which ones might need intervention. You can also verify that all sites have the same package version, as indicated by the Source Version column.

Figure 7: The Status of the Windows XP Package at All Sites

At this level you can click the Action menu, and then click Show Messages, All to see all the status messages for the package from all sites and distribution points. This can be a lot of messages; and therefore, it is better to review the messages at each site individually.

Package Status at the Sites

Below the package status for a specific package you can select each site. This level of status checking allows you to see, as shown in Figure 8, which specific distribution points within a site might be having problems with the distribution.

Figure 8: The Status of the Windows XP Package at a Specific Site

At this level, you can click the Action menu, and then click Show Messages, All to see all the status messages for the package from this site and all its distribution points. The following sequence of messages is typical (the distribution point--specific messages are listed in the next section):

30000 or 300001 — package created or modified
30003 — program created
2300, 2310, and 2311 — Distribution Manager preparing the package
2339 — Distribution Manager initiating schedule and sender to send the package information (not the package files)
30009 — distribution point assigned
2333 — preparing to send compressed image of package
2335 — Distribution Manager initiated scheduler and sender to send the package files to the sites
2315 — Distribution Manager deleted the compressed image of the package

When reviewing status messages, notice that each sequence of Distribution Manager activities ends with the message 2301, which indicates that the sequence was successful. This message appears whenever Distribution Manager completes any activities. Distribution Manager is the SMS component that distributes packages from the site server to the SMS distribution points and that initiates the sending of the package to other sites.

Package Status at a Distribution Point

At the package status at each site, you can select each distribution point. At this level, you can click the Action menu, and then click Show Messages, All to see all the status messages for the package at this distribution point. The following sequence of messages is typical:

2317 — Distribution Manager is refreshing the package on distribution point (not seen the first time the package is sent to the distribution point)
2342 — Distribution Manager is starting to distribute the package to the distribution point
2322 — Distribution Manager decompressed the package to the temporary directory (if applicable)
2329 — Distribution Manager copied the package from the temporary directory or package source to the distribution point
2330 — Distribution Manager successfully distributed the package to the distribution point

Note For a list of all status messages and their complete message text, see Chapter 26, Status Messages in the Systems Management Server Resource Guide.

Reporting Package Distribution Status

You might want to produce a report of the package distribution status, either for easy reference or to address your own specific requirements. You can perform queries of the package distribution status classes and incorporate the responses in the reporting tool of your choice as is done with other SMS reporting tools. Table 1 lists the relevant classes and the category of status information that you can find in each. Creating reports can be a complex operation and is beyond the scope of this technical paper. For more information, see the Advanced Systems Management Server 2.0 Reporting technical paper at https://www.microsoft.com/smserver/techinfo/administration/20/using/advreport.asp.

Table 1 WMI Package Distribution Status Classes

Class	Status Information
SMS_PackageStatus	Overall summary information about the status of packages on the distribution points.
SMS_PackageStatus RootSummarizer	Information about the status of a given package. Maps to Package Status in the SMS Administrator console.
SMS_PackageStatus DetailsSummarizer	Detailed information about the status of a given package by site code. Maps to the package console tree under Package Status (in the SMS Administrator console).
SMS_PackageStatus DistPointsSummarizer	Detailed information about the status of a given package at a given site. Maps to the site code under the package console tree (under Package Status in the SMS Administrator console).

Troubleshooting the Distributions

Monitoring the software distributions can indicate whether a software distribution has encountered problems at some point. Typically, this is due to lack of disk space, network link difficulties, or server problems. The status message text indicates such problems.

Isolating the problem is the first step in solving any technical problem. When you know which component failed, you can concentrate your efforts on the appropriate issues. Using the monitoring techniques described earlier will help you to isolate the problem. Also, the chapter on "Software Distribution Flowcharts" in the Systems Management Server Resource Guide includes graphics that show the typical flow of the software distribution process. If you find indications that your software distribution did not make it to a certain point in the flow, there is a good chance that the failure occurred at the previous point in the flowchart.

After you have isolated the particular component, understanding how it works can provide clues why it failed. The flowcharts can also help gain an understanding of the process. In addition, the related log files can show what is happening with the component at a very low level; and therefore, what might not be working. The logs are enabled by using the SMS Service Manager.

For troubleshooting tips for software distribution, see the chapter "Software Distribution Flowcharts" in the Systems Management Server 2.0 Resource Guide.

Advertising the Windows XP Packages

Computers can be upgraded to Windows XP when they receive the appropriate advertisement. The advertisements give descriptive information about the package to end users, and they include the details necessary for SMS to run the programs. The advertisements can even be assigned to run at specific times so that the user cannot block the upgrade or so that the upgrade can occur while the user is away from the computer.

Selecting Computers to Upgrade

An advertisement tells SMS to make available to an SMS collection a specific program within a package. A collection is a very flexible definition of computers, users, or user groups. In the case of a Windows XP software distribution, you would initially use collections that are a small number of computers used for testing purposes. Later, you would use collections that are all computers that are ready for Windows XP. You might subdivide the collection by site or information collected from SMS Inventory.

Query-based Collections have the additional benefit of being dynamic; as time goes on, you can add computers to a collection, and the advertisements that are available to that collection automatically become available to those additional computers. If the collection is based on the memory capacity of computers, for example, computers are added to the collection as their hardware is upgraded for Windows XP. If you install additional memory in a computer, the SMS hardware inventory detects this and records it within SMS. This computer is automatically included in the collection; therefore, the Windows XP upgrade is made available to the computer. Other than physically adding the memory to the computer, this is all automatic.

For more information about determining which computers in your organization are ready to upgrade, see "Using Systems Management Server to Analyze Your Network Infrastructure" in the Windows 2000 Deployment Planning Guide. This includes defining queries to select the computers from the inventory that SMS maintains. You can use these example queries to create collections, as described in the following procedure.

To create a collection of computers ready for Windows XP:

Create a query containing the systems that are ready to have receive the Windows XP installation.
In the SMS Administrator console, click Collections.
On the Action menu, point to New, and then click Collection.
In the Collection Properties dialog box, enter a name for the collection.
On the Membership Rules tab, click the New Query Rule button.
In the Query Rule Properties box, click the Browse button, and then select the appropriate query.

For example, use a query that you have made to report on the computers that are available to be upgraded to Windows XP. (For help developing such a query, see the chapter "Using Systems Management Server to Analyze Your Network Infrastructure" in the Windows 2000 Deployment Planning Guide.) You might have other queries that you prefer to use, such as All Windows 98 Systems or queries that you have defined to include all computers at specific sites.
Add query rules or direct membership rules as necessary.

Alternatively, at step 5 you might prefer to click the New Direct Rule button, and then use the Create Direct Membership Rule Wizard to specify the computers that you want to upgrade. This choice might be your best option during testing, especially if you have a small number of arbitrarily chosen computers that you want to run the package on.

An issue to consider is that SMS 2.0 allows collections to include computers, users, or user groups. Including domain users or user groups might not be appropriate, because users can often log on to different computers. Therefore, each computer that a user logs on to could be upgraded, especially if the advertisement is assigned and runs whether or not the user chooses it. However, the computers that they log on to might not be ready for the upgrade, or the users that usually use the computer might not be trained to use Windows XP.

Preparing Clients to Receive the Advertisements

The computers to which you are going to advertise need to be ready for the advertisement. During the Windows XP upgrade, the computer needs to restart several times. If this can occur automatically, the entire upgrade can be accomplished without input from users.

Some users put a boot password on their computer. This password is required by the computer itself; and therefore, cannot be circumvented by software. Until this password is entered, the computer will not restart, and the Windows XP upgrade cannot continue. Therefore, make sure to advise users to temporarily disable their boot passwords. If this is not possible, someone must be present during the upgrade. The same issue holds true if the computer stops for confirmation during restart because of hardware configuration changes or other issues.

It is recommended to give users advance notice of the upgrade so that they can be sure to close all documents. If users know that the upgrade is imminent, they will also be more inclined to get any training they require, perform backups, and prepare any programs they are responsible for.

If you are advertising the package with an assignment to run overnight or over a weekend, any client computers running Windows 98 or Windows Me need a user logged on in order for the advertisement to start automatically. These users might want to use a secure screen saver to prevent others from using their computer while they are away. Client computers running Windows NT do not require a user to be logged on for the advertisements to start.

Advertising the Packages to Computers

You now have a Windows XP or Windows Server 2003 package ready to distribute, you have the right computers selected, and you have the computers ready for the upgrade. The next step is to initiate the process. Do this by creating an advertisement as shown in the following procedure.

To create an advertisement for Windows XP:

In the SMS Administrator console, click Advertisements.
On the Action menu, point to New, and then click Advertisement.
In the Name box, give your advertisement a name that helps you to identify it.
In the Package list, click Microsoft Windows XP Professional English.
In the Program list, click Automated upgrade from Win98/98SE/ME, Windows 2000
Click Browse, and then select the collection that you are advertising the program to.
If you want to set the advertisement to run at a specific time, click the Schedule tab, and then to add assignment schedules, click the New (*) button.

Caution Assigned advertisements run only once for each client they are advertised to. If the advertisement fails at the client computer, the client does not attempt to automatically run it again. This ensures that computers are not caught in an infinite loop of trying to run an assigned advertisement, failing, restarting, and then trying again. Therefore, in step 7, you might also want to select Allow users to run the program independently of assignments. This allows users to run the program ahead of schedule or to run it afterwards if the program fails the first time. Alternatively, you can create a new advertisement at a later time for the computers that failed to upgrade.

As with the previous phases of Windows XP software distribution, start the advertising on a limited scale and expand as it proves successful. This is especially true now, because end users are definitely affected by the software distribution. You can expand the advertising by creating additional advertisements, each aimed at different collections, or by adjusting the collection that the advertisement is based on so that it includes more and more computers. Separate advertisements might be necessary to advertise different programs to appropriate collections. For example, the Windows 98 upgrade program should be advertised only to the computers in the Windows 98 collection.

Expanding Security on Distribution Points

If you restricted access to the package on the distribution points when you created the package, you must now open that access. Do this by using the following procedure. If you are using SMS to run the program with administrative privileges, add the client network connection accounts used in the SMS site as your package access accounts.

To open security for the Windows XP package:

In the SMS Administrator console, click Packages.
Click the Windows XP package, and then click Access Accounts.
On the Action menu, point to New, and then click Windows NT Access Account.
In the Access Account Properties dialog box, click Set.
In the Windows NT Account dialog box, enter the domain and user or group, specify the Account Type, and then click OK to close the dialog box.
In the Access Account Properties dialog box, verify that the Permissions are Read.

Repeat this procedure as necessary to add additional users or groups.

Upgrading Computers

When you have Windows XP on a distribution point in the same site as the computers to be upgraded, and the advertisement is available at the computers, you can do the following:

Schedule the upgrade for a time that is convenient for the user.
Report the status of the upgrade.

Executing the Advertisement at Each Computer

Distribution to all users can be done with SMS at a time that you believe is convenient. However, you can give users the option to adjust the date and time, as shown in Figure 9, to coincide with a time when they are not using their computers. You can also make the upgrade mandatory at a certain date and time so that users cannot postpone the upgrade indefinitely.

Figure 9: Users Can Schedule the Upgrade for a Convenient Time

The distribution that you initiate to users also includes appropriate command-line options to indicate which auto-answer file to use and other options, so that the setup is done according to the standards that you have determined.

Many organizations do not give their end users full privileges on client computers. This helps to minimize problems that are caused by users making uninformed or unintentional computer changes. However, this lack of privileges would normally stop users from initiating a Windows XP upgrade for their computers. SMS avoids this problem by doing the Windows XP upgrade in the context of a special SMS security account when the Windows XP Setup program is set to run with administrative rights.

Note If you are not using an answer file the user will be prompted to enter a product key during installation. To avoid this prompt see Allowing User Input During the Upgrade earlier in this technical paper.

Status of the Upgrade at Each Computer

When the first and final phases of the Windows XP upgrade are completed at the computer, SMS produces status files that are propagated up the SMS hierarchy. You can use this information to report on the overall progress of the upgrade project or to investigate the status of an individual computer, as discussed in the next section.

You can produce customized status files to indicate specific details relating to the status of the upgrade, if desired. The programs that create these status files are invoked as part of the package execution; and therefore, must be included in its definition. For example, you might want to include such status files if you have the Windows XP Setup program initiate post-upgrade tasks.

Monitoring the Advertisements

The SMS status message that reports the progress of the upgrade at each computer can also be used to report the progress of the Windows XP deployment as a whole. The number of computers ready to be upgraded, those successfully upgraded, and the locations of failures can all be reported. You can then intervene where any problems have occurred.

The System Status Subsystem

SMS 2.0 includes a powerful System Status subsystem that allows you to readily monitor the distribution. The SMS Administrator console includes a System Status node where you can obtain summary and detailed results from the System Status subsystem. There is an Advertisement Status subnode that allows you to obtain the status of the advertisements.

Status for All Advertisements

When you select Advertisement Status under System Status in the SMS Administrator console, you can view the following:

How many systems have received the advertisement
How many systems have experienced general failures processing the advertisement
How many times the advertised program has been started
How many times the program has run to completion or failed
Various advertisement details

An example of this information is shown in Figure 10. At this level there are no status messages to be queried.

Figure 10: The Status of All Advertisements

Status for a Specific Advertisement

Below the advertisement status for all advertisements you can select each advertisement. At this level, you can view the following:

Which sites have clients that have received the advertisement
Which sites contain clients that experienced a general failure while processing the advertisement
How many times the advertised program has run at each site
How many times it ran to completion or failed

Figure 11 shows this type of status. At this level, there are no status messages to be queried.

Figure 11 The Status of the Windows XP Advertisement

Status at a Site

At the advertisement status level, you can select each site. On the Action menu, point to Show Messages, and then click All to see the status messages for the advertisement at this site. The following sequence of messages is typical:

30006 — advertisement created
3900 — advertisement processed within a site (distributed to client access points)
10002 — advertisement received at a client
10005 — program started
10007 — program failed

The message indicates why this has occurred. Common reasons are that the user canceled the program or otherwise forced it to stop, or the client computer did not have enough disk space.
10008---program completed successfully
10009 — program completed successfully and a status Management Information Format (MIF) file was generated

At this point the SMS part of the upgrade is done. This corresponds with the end of the first phase of the Windows XP Setup (the file upgrade phase)..

Reporting Advertisement Status

You might want to produce a report of the advertisement status, either for easy reference or to address your own specific requirements. You can perform queries of the SMS advertisement status subsystem and incorporate the responses in the reporting tool of your choice, as is done with other SMS reporting functions. Table 2 lists the relevant class and the category of status information that can be found in the class.

Table 2 WMI Advertisement Status Class

Class	Status Information
SMS_AdvertisementStatusSummarizer	Displays detailed advertisement status information grouped by site code. You can locate maps to the advertisement items under Advertisement Status (in the SMS Administrator console).

For more information about writing reports based on the data that SMS collects, see the SMS Web site at https://www.microsoft.com/smserver/default.asp.

For the Windows XP advertisement status reporting, you will want reports such as the types described in the following sections.

Computers that Have Been Advertised to But Have Not Received the Advertisement

This report is a comparison of computers that are currently in the relevant collection but do not have a 10002 status message. If the program was advertised before the report, this report will indicate the computers that have not been used lately or that are not properly connected to the network or the SMS infrastructure.

Computers that Have Received the Advertisement But Have Not Started the Program

This report is a comparison of computers that have a 10002 status message but do not have a 10005 status message. If the program was assigned to run before the report, this report will indicate the computers that have not been used since the advertisement was first advertised or that have become disconnected from the network or the SMS infrastructure. If the program was not assigned, this report will also include computers where the users have chosen not to upgrade yet.

Computers Where the Program Started But Did Not Complete Successfully

This report is a comparison of computers that have 10005 status messages but not 10009 status messages. These are likely to be computers where the user has canceled the upgrade or the computers did not have enough disk space. Parsing the 10007 message description gives more details. If either problem is common, a report of those specific computers might be appropriate.

There is a remote possibility that some computers could fail in such a way that neither 10007 nor 10009 status messages are received. To take that possibility into account, you can have a report of computers with 10005 messages but not 10008 or 10009 messages. For users who have canceled the upgrade, an e-mail message reminding them of the importance of the upgrade might be sufficient to resolve the problem. Or, the program can be assigned so that it must happen at a specific time. For other problems, manual intervention might be required (using the SMS remote tools might be sufficient).

Troubleshooting Advertisements

You can use the advertisement monitoring process to isolate problems, hopefully before the users report problems. Typical problems include lack of disk space, user interference, or package definition errors. The text of the status messages will indicate such problems. Also make sure to verify that the package is available on at least one distribution point at the site.

Isolating the problem is the first step in solving any technical problem. If you know which component failed, you can concentrate your efforts on the appropriate issues. Using the monitoring techniques listed previously will help you to isolate the problem. For graphics that show the typical flow of the software distribution process on the server side, see the chapter "Software Distribution Flowcharts" in the Systems Management Server Resource Guide. For graphics that show the flow on the client side, see the chapter "Client Features Flowcharts" in the Systems Management Server Resource Guide. If you find indications that your software distribution did not make it to a certain point in the flow, there is a good chance that the failure occurred at the previous point in the flowchart.

After you have isolated the component, understanding how it works can provide clues as to why it failed. The flowcharts can help you gain an understanding of the process. In addition, the related log files can show what is happening with the component at a very low level, which can help you see what might not be working. You enable server logs by using the SMS Service Manager, and client logs are always enabled.

SMS has several features that can help you resolve problems on client computers. You can:

Remotely control the client computer.
Transfer files to the computer to replace files that need updating.
Restart the computer.
Obtain computer details, either based on the routine inventory or on real-time remote control tools.

Note The routine inventory is available even when the client is offline.
Upgrade incompatible application software.

There will be situations where manual intervention is needed, such as when an upgrade makes it impossible to restart the computer or to connect a computer to the network, or when the SMS client components become inoperative.

Using SMS to Ease Domain Consolidation and Migration

In the past, larger organizations have often had multiple domains running Windows NT 4.0. With Windows 2000, the reasons for those domains will most likely disappear, and therefore, consolidating them will simplify computer administration. Migrating to native Windows 2000 domains allows your organization to take full advantage of Windows 2000 features.

For details about the issues of domain consolidation and migration, see the chapter "Determining Domain Migration Strategies" in the Windows 2000 Deployment Planning Guide. That chapter also details strategies and techniques that will ease the process of consolidation and migration. SMS can help with this process, and thus Windows 2000 deployment with SMS should be considered in conjunction with domain consolidation and migration. For example, you can use SMS to deliver scripted executions of the DCPromo portion of the upgrade process for domain controllers.

The most significant benefit of using SMS for domain consolidation and migration occurs during deployment of the upgrade to Windows XP. By adjusting the JoinDomain value in the answer file, the computers can be put in the new, consolidated domain.

For More Information

For more information about SMS, check out the SMS Web site at https://www.microsoft.com/smserver/default.asp

Microsoft TechNet

https://technet.microsoft.com/sms/bb676797.aspx

Windows 2000 Resource Kit https://www.microsoft.com/windows2000/techinfo/reskit/default.asp

Windows 2000 Deployment Planning Guide

https://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp

Microsoft BackOffice 4.5 Resource Kit https://www.microsoft.com/mspress/

Deploying Windows XP Part I: Planning

https://www.microsoft.com/windowsxp/pro/techinfo/deployment/planning/default.asp

Deploying Windows XP Part II: Implementing

https://www.microsoft.com/windowsxp/pro/techinfo/deployment/implementing/default.asp

Other Windows XP deployment resources

https://technet.microsoft.com/library/bb457058.aspx