Upgrading an Existing Installation of SMS 2.0

One of the first questions you considered during the preplanning phase of your SMS 2003 deployment was whether you have an existing SMS installation. If you do not have an existing SMS installation, then you are deploying SMS 2003 as a new installation. If you have an existing SMS 2.0 installation, you can choose to upgrade it to SMS 2003 or remove it altogether. In either case, it is important to remember that, before you proceed with the installation of SMS 2003, the same planning steps apply for an upgrade as for a new installation. See the “Planning to Deploy SMS 2003” section earlier in this book for the planning steps you must complete before you install SMS 2003.

If you choose to remove SMS and your SMS hierarchy consists of several SMS sites, you must remove SMS from every site. It is recommended that you begin with the lowest level sites in the hierarchy first, ending with the central site. At a minimum, you must have performed the following steps:

  • Remove the SMS site from the existing hierarchy.

  • Remove all clients that are assigned to the SMS site.

  • Remove all client software from client computers.

  • Remove all SMS site system roles from servers.

  • Remove SMS site server software by running SMS Setup.

  • Remove all SMS-specific registry keys from the SMS site server. For more information, see article 217044 in the Microsoft Knowledge Base at http://support.microsoft.com.

  • Remove all SMS-specific accounts from the local SMS site server and from the site’s Windows domain unless you want to reuse those accounts for the new SMS 2003 site.

One way that you can remove all clients that are assigned to a site, in addition to all client software from client computers, is to remove all site boundaries, and then wait one day (23 hours) for the clients to initiate the uninstall process.

Note

You must account for clients that are offline when you remove the site boundaries. These will not begin the uninstall process until they are online again.

If you have an existing SMS installation , and you plan to migrate SMS clients from the existing installation to SMS 2003, you must familiarize yourself with the relevant interoperability considerations that are related to SMS 2.0 and SMS 2003 sites and with planning issues relating to an upgrade from SMS 2.0 to SMS 2003. Here are some of the issues to consider:

  • SMS 2003 sites cannot use SMS 2.0 logon points.

  • Server locator points are not supported as site systems in SMS 2.0 sites. In a mixed-version hierarchy, where SMS 2.0 and SMS 2003 sites both reside in the same domain, SMS 2.0 sites cannot continue to use their logon points. However, SMS 2.0 sites can use server locator points that are set up in SMS 2003 sites to install their clients if you use Capinst.exe as part of a logon script or manual installation.

  • Queries that run against SMS 2.0 classes that do not exist in SMS 2003 return only the classes that exist in SMS 2003.

  • In a mixed-version hierarchy, it is recommended that all sites use a standardized SMS_def.mof file. Differences between the SMS_def.mof files at different sites in the hierarchy can result in having conflicting hardware inventory data.

  • The SMS 2003 Distribute Software Update Wizard does not operate correctly in SMS 2.0 sites. This is because SMS 2.0 site servers are missing specific folders and files that the wizard requires to create packages. This issue applies to SMS 2.0 sites regardless of whether the Software Update Services Feature Pack is installed or not.

  • SMS 2003 does not support the SMS 2.0 Software Metering feature. Software metering data that is collected at an SMS 2.0 site is not reported to an SMS 2003 parent site, and cannot be viewed by administrators at SMS 2003 sites.

For information about issues related to interoperability, see Chapter 6: “Understanding SMS Interoperability with SMS 2.0” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. For more information about general planning issues, see “Planning a Site Upgrade” in Appendix H.

Caution

During an upgrade, SMS Setup first deletes all SMS 2.0 files from the site server and then proceeds with installing SMS 2003. If the upgrade fails, you must manually restore your SMS 2.0 site. Additionally, clicking Cancel during a site upgrade does not undo the upgrade; all SMS 2.0 files are deleted. Cancel an upgrade only in extreme circumstances. Always back up an SMS site before you upgrade it. If the upgrade fails or is cancelled, you can restore the site from the backup. You can use the Backup SMS Site Server Site Maintenance task in the SMS Administrator Console to backup the SMS site.

One important question to consider is whether you are planning to upgrade your existing infrastructure. You must consider whether you intend to use the existing SMS site infrastructure or modify the number and assignment of site system roles. Site system roles include client access point (CAP), distribution point, management point, server locator point, reporting point, and site server.

You also must decide whether you want to use your existing server hardware to support SMS 2003 or whether you want to use new hardware. If you choose to use the existing hardware, you are performing an in-place upgrade.

If your existing SMS hierarchy consists of many SMS sites, consider whether you should consolidate those sites. It might be appropriate to develop a new design for your SMS hierarchy. You might also consider upgrading your existing hardware or using new hardware to support your SMS servers. If you plan to use new hardware, consolidate your existing site, or design a new site hierarchy as part of your upgrade strategy, you might be performing an in-place upgrade or a side-by side upgrade.

Any discussion of hardware or network considerations involves selecting the correct hardware to support your site design and determining the appropriate number of sites, site types, and site systems. This planning process is essentially the same whether you are deploying a new SMS 2003 installation or upgrading an existing SMS 2.0 installation and planning to use the same infrastructure or to upgrade that infrastructure. For information about how to plan your site design, see “Planning to Deploy SMS 2003” earlier in this book.

You must also consider which security mode to use when you upgrade your SMS 2.0 site. By default, the site will be upgraded to advanced security unless you specifically choose to use standard security. For more information about advanced security see the section Security Planning earlier in this document.

Client Migration

If you have an existing SMS 2.0 installation of, you can choose to upgrade that installation to SMS 2003 to take advantage of the new features and the more secure Advanced Client. This section helps you to plan for an SMS 2.0 upgrade, and it offers two upgrade scenarios: In-place Upgrade and Side by Side Upgrade.

Upgrading your SMS 2.0 site means upgrading the SMS clients that are assigned to the site. Because client support has changed significantly in SMS 2003, it is important that you understand how SMS 2003 supports clients and how that support affects your upgrade plan. This section categorizes SMS clients into three classes to distinguish how SMS supports them. Table 1.8 describes the type of client that is maintained in each class. Table 1.8 describes the Microsoft Windows® operating systems supported by clients in each class.

Table 1.8   SMS Client Classes

Class

Description

Class A

Supported by SMS 2003 sites. Clients in this class generally run SMS 2003 Advanced Client but can also run the SMS 2003 Legacy Client and the SMS 2.0 client.

Class B

Supported by SMS 2003 sites but the client operating systems do not run the SMS 2003 Advanced Client. Clients in this class generally run the SMS 2003 Legacy Client but can also run the SMS 2.0 client.

Class C

Supported only by SMS 2.0 sites. Clients in this class run the SMS 2.0 client.

Table 1.9   Windows Operating Systems Supported by Each SMS Client Class

Operating system

Class A

Class B

Class C

*SPVirtual PC 2004 or Virtual Server 2005 *SP

X

   

Windows Server 2003 family

X

   

Windows 2000 family

X

   

Microsoft Windows® XP Professional

X

   

Microsoft Windows® XP Home Edition

N/A

N/A

N/A

Windows NT 4.0 Service Pack 6 (with Internet Explorer 5 or later)

 

X

 

Windows NT 4.0 Service Pack 5 and earlier

   

X

Microsoft Windows® Millennium Edition

   

X

Windows 98 (with Internet Explorer 5 or later)

 

X

 

Windows 98

   

X

Microsoft Windows® 95

   

X

Note

Windows XP Embedded is only supported when you include the SMS Advanced Client as part of the operating system image. Installing the SMS client on an existing Windows XP Embedded machine is not supported.

Class C computers are not capable of supporting either the Legacy Client or the Advanced Client because of operating system incompatibility. If SMS 2.0 sites currently manage these clients, you must decide whether you need to continue supporting these clients. If so, then you need to manage them with an SMS 2.0 site until you can upgrade them to either the Legacy or Advanced Client, or no longer need to maintain them as SMS clients. This kind of SMS 2.0 site is known as a holding site.

Holding site

SMS installs client software for Class A and Class B clients according to the methods outlined in Appendix C: “Appendix C - Client Deployment Planning.” Because SMS 2003 sites do not support Class C computers, SMS 2003 does not install any SMS client software on Class C computers. If Class C computers previously were SMS 2.0 site clients, they effectively become orphaned clients in an SMS 2003 site.

A holding site is a designated SMS 2.0 site in the SMS 2003 site hierarchy that manages Class C computers. The holding site is a child site of an SMS 2003 site. The site boundaries of the holding site overlap with those of the SMS 2003 site or sites that have Class C computers.

For those computers that reside in the overlapping boundaries of SMS 2.0 and SMS 2003 sites, SMS determines which client type to install according to the Logon Script-initiated Client Installation command (Capinst.exe) and the computer’s operating system. In this case, Class C clients automatically become clients of the SMS 2.0 holding site rather than becoming orphaned.

Your decision to install the SMS 2003 Advanced Client or the SMS 2003 Legacy Client — supported by Class A and Class B computers — depends on more than the supported operating system. For an expanded discussion about these two client types, see Appendix C: "Appendix C - Client Deployment Planning."

For both in-place and side-by-side deployment scenarios, if you have clients that are in the Class C category described in the Client Support topic earlier, you must decide whether you want to continue managing these clients with SMS. If so, then you need to implement a holding site for those clients. If not, then remove the SMS client software from those clients so that they do not become orphaned. Clients that are in the Class A and Class B categories become members of the SMS 2003 site according to the client installation method you select for the site and according to the site boundaries and roaming boundaries you configure.

If you plan to consolidate your SMS site as part of a side-by-side migration, you add the boundaries of old SMS sites to the boundaries of the consolidated site. Use SMSMan.exe with the /F switch, or reference a script to assign computers to the consolidated site. When you finish assigning the computers to the consolidated site, remove SMS software from the old SMS sites.

Examples of these scenarios can be found in Appendix H: “Appendix H - Upgrading to SMS 2003.”

Considerations for Active Directory

As in a new deployment of SMS 2003, if you are upgrading to SMS 2003 in an Active Directory environment, you have the benefit of implementing advanced security, which is the preferred security mode. You must understand how SMS 2003 uses Active Directory and know the requirements for using advanced security. In particular, you should understand how to extend the Active Directory schema for SMS, how to use Active Directory site names for your SMS site boundaries and roaming boundaries, and how to manage SMS clients that roam from SMS site to SMS site. Extending the Active Directory schema is a forest-wide action. If you extend the schema for one SMS site in the forest, then the schema is extended for use by all SMS sites in the forest.

See “Active Directory Planning” for more information about how to develop a strategy for using Active Directory.