Upgrading to Systems Management Server 2.0

[Previous] [Next]

You are now ready to begin the upgrade process. Remember, a top-down upgrade is strongly recommended, as SMS 2.0 sites can report only to other SMS 2.0 sites and not to SMS 1.2 sites. In this section, we will begin with upgrading the primary site server and then explore upgrading secondary sites and SMS clients.

Object Migration

Let's begin by examining which elements of the SMS 1.2 site are migrated and which are not. Table 19-1 provides a list of these objects.

Many of these objects have been discussed earlier in this chapter, and some are listed on the premigration checklist. You might want to use Table 19-1 as a reference tool when planning your migration strategy.

Table 19-1. SMS 1.2 object migration status

Object	Migrated?	Relationship to SMS 2.0
Alerts	No	Status messages and status message filters are used to write messages to the Windows NT Event log.
Collected Files	No	Collected files are deleted. Files must either be collected again through the software inventory feature or copied to a folder outside the SMS directory structure.
Custom Architectures	Yes	Custom architectures created under SMS 1.2 for example, through custom IDMIF files are converted to SMS 2.0 objects.
Events	No	Status messages and status message filters are used to write messages to the Windows NT Event log.
Hardware Inventory	Yes	The Hardware Inventory Client Agent is used to collect more comprehensive data as well as physical disk data. Physical disk data should be documented prior to migration.
Software Inventory	No	The Software Inventory Client Agent is enabled through the SMS Administrator Console.
Jobs	No	Jobs, especially recurring jobs, are documented and then re-created as advertisements.
Machine Groups	Yes	Machine groups are converted to collections. (Names and membership should be documented prior to migration.)
MIF Files	No	MIF files on the site server are deleted; MIF files on the client are processed after the client upgrade. (MIF files should be saved in a folder outside the SMS directory structure if you intend to use them again.)
Packages	Yes	Packages are converted with the Compressed option enabled.
Programs	Yes	Package command lines are converted to programs; unattended command lines are converted as disabled.
Queries	No	Existing queries are documented and then re-created in the SMS Administrator Console.
Security Settings	No	Object security has been reengineered in SMS 2.0, SQL Server, and WMI. Object class and instance permissions are used to provide a more secure environment.
Site Groups	No	Site groups are not supported in SMS 2.0.
SMSID	Yes	SMS 2.0 preserves the unique identifier assigned to each client in the SMS 1.2 database.
SNA Sender	No	SMS 2.0 does not support the SMS 1.2 SNA Sender; instead, it supports an SNA RAS sender.
SQL Server Views	Yes	Views generated under SMS 1.2 are migrated; however, they are not required or used to access the data in the database. Any WBEM ODBC compliant application, such as Crystal Info, can access the data directly.

Primary Site Upgrades

The site upgrade process for a primary site is fairly straightforward, providing you have prepared the server appropriately. Most notably, be sure that the server itself can support the resources required by SMS 2.0 and that the server has been made fully Y2K-compliant. Be sure that the version of SQL Server you are running has been updated with SQL Server 6.5 Service Pack 4 or later.

You will need to log onto the site server using an account that has administrative permissions for the SMS database as well as for the server itself. The account needs to be a member of the local Administrator group. You will also need access to the SMS 2.0 source files. For the purposes of this discussion, we will assume that you have access to SMS 2.0 source files that have been updated with SMS 2.0 Service Pack 1.

Log onto the site server and locate the SMS 2.0 source files that you will be using to upgrade the server. Then follow these steps to upgrade the primary site:

1. Locate the Autorun.exe file, and double-click on it. Choose Set Up SMS 2.0 from the Autorun menu to display the Systems Management Server Setup Wizard welcome screen, shown in Figure 19-38. (Alternatively, you can navigate to the \SMSSetup\Bin\platform directory and run Setup.exe to launch the wizard.)



Figure 19-38. The Systems Management Server Setup Wizard welcome screen.

2. Click Next to display the System Configuration screen, shown in Figure 19-39, and verify that Setup has found the SMS 1.2 site. Read the screen text before you proceed with the upgrade.



Figure 19-39. The System Configuration screen.

3. Click Next to display the Setup Options screen, shown in Figure 19-40. The only option available on this screen is Upgrade An Existing SMS Installation.



Figure 19-40. The Setup Options screen.

4. Click Next to display the Systems Management Server License Agreement screen, shown in Figure 19-41. After reading the license agreement, select I Agree (assuming that you do).



Figure 19-41. The Systems Management Server License Agreement screen.

5. If your installation of SQL Server is on a server other than the SMS site server, clicking Next will display the SMS Provider Information screen, shown in Figure 19-42. Select either the SMS Site Server or the SQL Server Computer option. The accompanying notes on this screen will help you decide where to place the SMS Provider. In general, for large sites with a large number of SMS administrators and because the SMS Provider's primary task is to access object data in the SMS database, you should place the SMS Provider where the database resides—on the SQL Server computer.
6. Click Next to display the Completing The Systems Management Server Setup Wizard screen, shown in Figure 19-43. Click Finish to begin the primary site upgrade process.
7. At this point, if this site has any child sites the setup process will remind you to upgrade these sites using a top-down approach, as discussed earlier. Keeping this in mind, if this site reports to an SMS 1.2 site, click Cancel to stop the migration process. Remember that SMS 2.0 sites cannot report to SMS 1.2 sites. Click Finish to continue.



Figure 19-42. The SMS Provider Information screen.



Figure 19-43. The Completing The Systems Management Server Setup Wizard screen.

8. One final wizard screen will be displayed, as shown in Figure 19-44. Click Start Database Conversion to launch the database conversion process. This is your last chance to back out of the upgrade—to do so, click Cancel.



Figure 19-44. Starting the database conversion process.

9. A message box will appear, outlining the progress of the database conversion process, as shown in Figure 19-45. This same information can be found in the log file C:\Conv20.log.



Figure 19-45. A message box reporting on the progress of the database conversion.

10. Finally, the old site is upgraded to SMS 2.0. Old elements are removed or upgraded, and new components and services are installed.
11. When the upgrade is complete, a message to that effect will be displayed on your screen. Click OK.

Since only a limited number of SMS 1.2 elements are upgraded to SMS 2.0, you will need to add the SMS 2.0 options and features you want to include in your new primary site. For example, you may want to add software metering or product compliance. You can add additional components to your site server the same way you would add components to a newly created SMS 2.0 site server (see Chapter 2). The basic procedure is outlined here:

1. From the SMS 2.0 source file location, launch the Systems Management Server Setup Wizard.
2. Click Next until you get to the Setup Options screen, shown in Figure 19-46. Select the Modify Or Reset The Current Installation option.



Figure 19-46. The Setup Options screen of the Systems Management Server Setup Wizard.

3. Click Next, and unless you need to install other platform support, click Next again to display the Setup Installation Options screen, shown in Figure 19-47. In the Options list, check the SMS 2.0 components you want to include in your SMS 2.0 site server.
4. Continue clicking Next, and if you do not need to make any changes to your SQL Server database information, such as switching to integrated security, simply accept the default values that appear on the remaining screens.

If you need to make changes, or if you chose to install the Software Metering tool, identify the SQL Server database names and account information as those screens are displayed to you.

5. Review your changes on the Completing The Systems Management Server Setup Wizard screen, shown in Figure 19-43, and then click Finish.



Figure 19-47. The Setup Installations Options screen of the Systems Management Server Setup Wizard.

Each new SMS 2.0 component is discussed in detail in a previous chapter of this book; refer to these earlier chapters for detailed information about specific SMS 2.0 features.

Site System Upgrades

SMS 2.0 introduces several new site system roles. As a matter of fact, the only SMS 1.2 site system that is not materially affected by the upgrade is the distribution server, because no SMS components or services are installed there either by SMS 1.2 or by SMS 2.0.

After a site has been upgraded to SMS 2.0, the Windows NT logon discovery and Windows NT logon installation methods are left disabled by default. When you choose to enable these methods, SMS will convert all domain controllers identified to the site to SMS 2.0 logon points. This means that any SMS 1.2 logon servers still identified as such will be overwritten. To review how to maintain both versions of the logon scripts in a mixed SMS 1.2 and SMS 2.0 environment, refer to the section "Logon Contention" earlier in this chapter. To add any other site systems to your new site, you would use the SMS Administrator Console. Refer to Chapter 3 to review this procedure.

Secondary Site Upgrades

Recall that once an SMS 1.2 secondary site's parent has been upgraded to SMS 2.0, its properties can no longer be modified. You must either make any needed changes prior to upgrading the parent or not upgrade the parent in the first place.

If you need to upgrade the secondary site, you can do so using one of the following techniques:

• Initiate the upgrade process wholly from the parent site. This procedure will take up some network bandwidth and is similar to creating a secondary site as outlined in Chapter 4—that is, you right-click on your primary site entry in the SMS Administrator Console, choose All Tasks from the context menu, and then choose Upgrade Secondary Sites to launch the Upgrade Secondary Site Wizard. This wizard is fairly self-explanatory; refer to the Systems Management Server Administrator's Guide for details.
• Initiate the upgrade process from the parent site, but place the source files locally at the secondary site to minimize network concerns.
• Upgrade locally at the secondary site server, using the SMS 2.0 source files and setup process. Again, this procedure is similar to that outlined in Chapter 4 for creating a new SMS 2.0 secondary site. It is almost identical to the primary site upgrade procedure discussed in the preceding section. In this case, however, there will be no database to convert, so the process should take less time.

Client Upgrades

SMS 1.2 clients will not be upgraded until you have enabled one of the following three client upgrade methods available through SMS 2.0:

• Windows Networking Logon Client Installation method
• Manual upgrade of the client by running the SMS Installation Wizard
• Windows NT Remote Client Installation method

The Windows Networking Logon Client Installation method is the most common method to enable. As discussed in Chapters 3 and 8, this method will enable the configuration of all domain controllers as SMS logon points for the site. If these domain controllers were previously SMS 1.2 logon servers, they will now be written with SMS 2.0 support files. Logon scripts will be upgraded automatically as well, and the next time the user logs on the upgraded script will also cause the SMS client to be upgraded.

NOTE

---

Remember that MS-DOS, Macintosh, and OS/2 clients are not supported under SMS 2.0.

If you choose not to enable Windows Networking Logon Client Installation, you could instead run the SMS Installation Wizard to manually upgrade each client or selected clients. This technique might be useful if you have a large mix of supported and nonsupported clients and want to be sure that only appropriate clients are upgraded. You will still have to configure a logon point for your site, but you would not have to enable SMS to update logon scripts. Connect to the SMSLogon share on a logon point, navigate to the X86.bin\00000409 folder, and run SMSMan.exe (or SMSMan16.exe for 16-bit Windows clients) to begin the upgrade process.

The Windows NT Remote Client Installation method can be used to push the SMS client out to computers running Windows NT. Chapter 8 outlines the client requirements and procedure for enabling this method. You specify whether to install the client on Windows NT workstations, servers, or domain controllers, and SMS essentially finds all those types of computers that reside within the site boundaries and begins the upgrade process.

CAUTION

---

This is an all-or-nothing option. The Windows NT Remote Client Installation method will find all the Windows NT computers of the type you selected within the site boundaries. As a result, you might find and install some computers running Windows NT that you did not intend to install at this time.

After the upgrade is complete, it is advisable to have the user restart the computer to ensure that all SMS components are upgraded and all agents are started. Some client agents, such as the Software Metering Client Agent and the Remote Tools Client Agent, will require a restart to fully enable their functionality. If for some reason a client component does not install correctly—for example, if when you are viewing the component status through the Systems Management applet in Control Panel, the component displays a status of "Installation Pending" or "Failed" and a restart does not correct the problem—you should manually reinstall the client as described earlier in this section.

During the upgrade process, the old SMSID is preserved and used as the new SMSID for the new site. A new MS\SMS directory structure is created below the operating system directory, and the old MS\SMS directory structure is removed, along with all SMS 1.2 client programs and the old SMS.ini file. The exceptions are the IDMifs and NOIDMifs folders, which are moved to the new MS\SMS directory tree.

TIP

---

Since by default no client agents are enabled when you upgrade the SMS 1.2 site, you must enable and configure the SMS client agents through the SMS Administrator Console to install these components on the SMS clients during the upgrade. It is recommended that you do so prior to upgrading the clients so that as the clients are upgraded, they will not lose functionality.

Figures 19-48 and 19-49 demonstrate the extent to which an SMS 1.2 client's inventory is converted, as compared to inventory collected from an SMS 2.0 client. As you can see, the SMS 1.2 inventory is not as complete or as detailed as the SMS 2.0 inventory. Notice that physical disk information collected during the SMS 1.2 hardware inventory process is converted to logical disk information.

Figure 19-48. Sample hardware inventory collected through SMS 1.2.

Figure 19-49. Sample hardware inventory collected using SMS 2.0's Hardware Inventory Client Agent.

By opening the collection containing the client, right-clicking on the client in the Details pane, and choosing Properties from the context menu, you can examine the properties of the upgraded client in the client's Properties window. Figures 19-50 and 19-51 show the Discovery Data list on the General tab of the client's Properties window. These properties will reflect the fact that the client was upgraded, the date and time of the conversion, and the client's IP information. As you can see in Figure 19-51, the client's initial domain membership and SMSID were retained.

NOTE

---

If you are using PGC and have not prepared for the migration of this functionality before upgrading your clients, the old PGC icons and groups will not be removed from the clients and will have to be removed manually. See the section "Program Group Control" earlier in this chapter for details.

Figure 19-50. The General tab of the Client Properties window, showing the first half of the Discovery Data list.

Figure 19-51. The General tab of the Client Properties window, showing the second half of the Discovery Data list.