Chapter 20: Migration Issues

Reviewing the Current Site Structure

The first step in developing a migration strategy is to review your current SMS site structure. The current SMS site structure can play a more significant role in determining your migration strategy than you might realize. In general, the clearer your understanding of the current site structure, the easier it will be for you to manage upgrading the sites and maintaining a mixed site. This means documenting all aspects of your current structure, site by site.

Identify the location of your sites’ logon servers, distribution servers, site servers, and other site systems you’ve specified—an upgrade will affect all of these in one way or another. Identify your Microsoft Windows domain and forest structure and your Windows server platforms. As you’ve seen throughout this book, SMS 2003 has some specific setup and configuration requirements depending on the Windows server platform you’re using.

If your system currently supports SMS 2.0 secondary sites, consider whether you need to retain this support. Perhaps the needs of that site or your organization have changed since the secondary sites were implemented. Although an SMS 2003 primary site can support SMS 2.0 secondary sites, I really recommend that you take the time to review your site requirements. This is an excellent opportunity to rebuild your site structure to better meet your organization’s management needs, as well as to consolidate or upgrade hardware.

Determining Which Client Platforms Need to Be Supported

You already know that SMS 2003 supports only client systems running Windows 98 and higher. Prior to upgrading any existing site servers to SMS 2003 or implementing any new site servers using SMS 2003, you need to determine whether you have unsupported clients in your existing SMS sites and whether they still need to be managed by an SMS site. If not, you should remove the old SMS client components from those clients before upgrading the site server to which they belong.

If these clients still need to participate in an SMS site, they can be managed only by an SMS 2.0 site and you’ll need to implement a mixed site of SMS 2.0 and SMS 2003 servers. Although this isn’t an impossible situation, it’s also not without challenges. Mixed-site interoperability will be discussed in detail in the section entitled “Maintaining Mixed Sites Within the Same Site Structure” later in this chapter.

Reviewing Hardware and Software Currently in Use

Now is an excellent time for you to review the hardware and software currently in use on your Windows servers. Recall from Chapter 2, “Primary Site Installation,” that you must meet some minimum and recommended hardware and software requirements to successfully upgrade to or install SMS 2003. For example, you should have at least 256 MB of RAM and 2 GB of available disk space on an NTFS partition, and your server’s processor must be at least an Intel Pentium 550 MHz.

By now, you certainly understand that RAM, disk space, I/O, and processor speed are all important factors in maintaining acceptable performance for SMS 2003 site systems, particularly the site server and SMS database server. You must upgrade your servers accordingly before beginning an upgrade or installation process.

In terms of software, you must meet some simple, nonnegotiable terms in order to upgrade to or install SMS 2003. The proposed site server must be running Windows 2000 with Service Pack 3 or later or a server running Windows Server 2003 Standard or Enterprise Edition.

Also, although SMS 2.0 supports SQL Server 6.5 with Service Pack 4 or later applied, SMS 2003 requires SQL Server 7.0 SP3 or higher to support the SMS site database if you’re running SMS 2003 standard security and SQL Server 2000 SP3a or higher if you’re running SMS 2003 advanced security.

Exploring Site Considerations in a Mixed-Version Environment

If you need to maintain a mixed SMS 2.0 and SMS 2003 site structure, you need to consider several things as you reorganize the structure and roll out the upgrade. Although SMS 2.0 sites can report to SMS 2003 sites, the reverse isn’t supported—that is, SMS 2003 sites can report only to other SMS 2003 sites and not to SMS 2.0 sites. Be sure your proposed mixed-site structure reflects this reporting path. This limitation also almost guarantees the necessity of performing a top-down upgrade of SMS 2.0 sites. Begin your upgrade with the SMS 2.0 central site and work your way down to ensure that all SMS 2003 sites always report to another SMS 2003 site.

You can’t install or run SMS 2.0 components on an SMS 2003 site system. For example, you couldn’t define an SMS 2.0 logon point to be a site server for an SMS 2003 site server. Similarly, SMS 2.0 sites don’t recognize SMS 2003 management points, server locator points, or reporting points. However, SMS 2.0 and SMS 2003 sites can share distribution points because no SMS components are installed on those servers, although SMS 2.0 sites can’t take advantage of Background Intelligent Transfer Service (BITS) enabled distribution points

Perhaps the most important of these limitations is that SMS 2.0 and SMS 2003 can’t share the same SQL Server database, although both sites can maintain separate SMS databases on the same server running SQL. As always, however, it’s recommended that each SMS primary site have its own dedicated server running SQL.

Although you can’t use an SMS 2.0 Administrator Console to manage an SMS 2003 site, you can use an SMS 2003 Administrator Console to manage an SMS 2.0 site. In fact, this latter scenario is recommended in a mixed-site hierarchy. Of course, administration tasks specific to SMS 2.0 sites wouldn’t be available. For example, tasks related to software metering are unavailable, as are the Export Site Database or Export Site Transaction Logs maintenance tasks.

Reviewing and Cleaning Up the Database

Although the actual SMS 2003 upgrade process does a fairly good job of converting the SMS 2.0 database, performing whatever maintenance and cleanup tasks are necessary to make the database as error-free as possible before the upgrade is strongly recommended. Otherwise, you could run the risk of migrating “bad” data into the new site, and what’s the point of doing that?

Backing Up the Site and the Server

Although it’s not entirely necessary, especially if you like to live on the wild side, it’s a good idea to back up your SMS 2.0 site, including not only the site database but also the SMS directory structure and registry keys. This backup can assist you mightily if you encounter problems with the upgrade and need to restore your site—as will all the other documentation procedures we’ve discussed.

In addition, consider creating or updating the emergency repair disk or backing up the system state for the Windows server on which your SMS 2.0 site is installed. This disk will assist you in restoring registry keys and SMS services should you need to do so.

Along these same lines, I strongly recommend that you thoroughly document your SMS 2.0 site settings, configuration settings, packages, advertisements, and especially any custom information you might have created, such as a custom Managed Object Format (MOF) file. Having this information available can greatly simplify recovering the old site in the event that something goes wrong with the upgrade, as well as fine-tuning the new site after the upgrade is complete.

Preserving Custom MOF Settings

In a mixed-version hierarchy, it’s recommended that you use a standard SMS_def.mof file to avoid conflicts in the type of hardware inventory that’s collected and propagated up the hierarchy to the central site. In a mixed- version hierarchy, different versions of Windows Management Instrumentation (WMI), the source that the .MOF file uses to collect hardware inventory, are used in SMS 2.0 and in SMS 2003. Having conflicting hardware inventory data in the SMS site database results in having multiple tables for the same class, and reports based on inventory can display incorrect information.

Some organizations customize their .MOF files to collect additional information that the original file doesn’t collect. When you upgrade from SMS 2.0, the setup program replaces the old version of the SMS_def.mof file with the SMS 2003 version, and any customizations that you made will be lost. It’s important, therefore, that you document any customizations you made to the SMS_def.mof file. You might consider making a copy of it in a directory separate from the SMS installation directory.

In many cases the SMS 2003 version of the .MOF file can now include the extensions that the SMS 2.0 version did not. Compare the .MOF files that you’re using with SMS 2.0 against those used for SMS 2003. As you did for SMS 2.0, determine which .MOF extensions you want to use and which you don’t need. Also, determine whether existing SMS 2003 extensions can collect the information that you customized the SMS 2.0 version to collect and use the SMS 2003 extensions. After the upgrade you can use your documentation to add any extensions that the SMS 2003 version of the file doesn’t already include.

Running the Deployment Readiness Wizard

There’s quite a bit to consider before attempting to upgrade your SMS 2.0 site to SMS 2003. I’ve pointed out only a few of the concerns you must think about. However, Microsoft created a tool to help you determine whether your SMS 2.0 site is ready for an upgrade. You must run the Deployment Readiness Wizard (DRW) on the SMS 2.0 site server before you can run the upgrade.

As you can see in Table 20.1, this wizard runs a rather comprehensive series of tests on your SMS 2.0 site server. When it’s finished, it generates a list of the tests and whether they passed. As each test runs, it can either pass with flying colors or generate an error or warning message. A warning message doesn’t prevent the upgrade from occurring, but it does identify a potential issue that you might consider resolving before upgrading. An error message, on the other hand, does prevent the upgrade from occurring. You must resolve the issues that caused the error message before you can proceed with the upgrade.

To run the DRW, complete the following steps:

1. On the SMS 2.0 site server, navigate to the SMSSetup\Bin\I386 folder on the SMS 2003 product CD and run DRW.exe. The Welcome page is displayed, as shown in Figure 20.1.

   
   Figure 20.1: DRW Welcome page.

2. Click Next to display the Site Selection page, shown in Figure 20.2.

   
   Figure 20.2: DRW Site Selection page.

3. Select Analyze This Primary Site if you’re running the DRW on the SMS 2.0 primary site you’re upgrading or select Analyze One Or More Direct Child Secondary Sites if you want to run DRW against an SMS 2.0 secondary site associated with this primary site. If you select the latter option and click Next, the Secondary Sites page is displayed, as shown in Figure 20.3. Select the site or sites that you want to analyze and then click Next.

   
   Figure 20.3: DRW Secondary Sites page.

4. Click Next to display the Tests page, shown in Figure 20.4. Select the tests that you want to run and then click Next. Unless you’re truly confident about the state of your SMS 2.0 site, I recommend running all the tests.

   
   Figure 20.4: DRW Tests page.

5. On the Completing the Systems Management Server 2003 Deployment Readiness Wizard page, shown in Figure 20.5, click Finish.

   
   Figure 20.5: Completing the Systems Management Server 2003 Deployment Readiness Wizard page.

6. When the wizard has completed running the tests, click Details on the Progress And Results Summary page shown in Figure 20.6 to see the results of each test.

   
   Figure 20.6: DRW Progress And Results Summary page.

   When you click Details, the Test Results page is displayed, as shown in Figure 20.7. In this page, click View Report to display a report that lists and describes each test that ran or select a test from the list and click Details to display information specific to that test. Click Close when you’re finished.

   
   Figure 20.7: DRW Test Results page.

Notice the More Information button on the Progress And Results Summary page. Clicking this button takes you to the SMS 2003 Deployment Readiness Wizard Procedures for Resolving Test Failures Web page, shown in Figure 20.8, hosted on TechNet. This document outlines each test in more detail and includes steps you can take to resolve the warnings and errors that might be generated. You can download a printable version of this document either from TechNet or from the SMS Web site.

Figure 20.8: SMS 2003 Deployment Readiness Wizard Procedures for Resolving Test Failures Web page.