Microsoft Systems Management Server 2003 : Migration Issues - Planning the Site Structure (part 1)

• Review the current SMS site structure

• Determine which client platforms need to be supported within your upgraded site structure

• Review server hardware and software currently in use

• Explore feature differences between SMS 2.0 servers and SMS 2003 servers

• Review and clean up the database to be converted

• Document current site settings that need to be re-created

• Back up the site and the server

Before you upgrade to SMS 2003, you must apply SMS 2.0 Service Pack 4 or later. You’ll no doubt add items specific and unique to your own SMS installation, but this checklist should serve as a good starting point as you prepare your SMS 2.0 migration strategy. We’ll look at each of these tasks in detail in the sections that follow.

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.

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.

Reviewing Hardware and Software Currently in Use

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?

Reviewing the Database

Before you upgrade, you should perform the usual recommended SQL Server database maintenance tasks. Microsoft recommends the following database maintenance commands for consistency checks:

• DBCC CHECKDB Verifies that index and data pages are correctly linked for each database table, indexes are in the proper sort order, pointers are consistent, and page information and offsets are reasonable

• DBCC CHECKALLOC Verifies that all data pages are appropriately allocated and used

• DBCC CHECKCATALOG Verifies consistency in and between system tables

• DBCC UPDATEUSAGE Reports on and corrects inaccuracies in the Sysindexes table that could result in incorrect space usage reports

For details about how to execute these commands. Also refer to your SQL Server documentation for complete information about these and other database maintenance commands. It’s recommended that you take the opportunity to clean up the database before upgrading. For example, check for any duplicate or old client records and remove them. In some cases you might determine that it would be better to start fresh rather than to upgrade and risk importing “dirty” information. As I’ve recommended in my SMS classes, it does you and your organization no good to preserve data that’s questionable; you only end up importing the same database “issues” into the new site. Then, of course, you’ll blame your problems on SMS 2003!

If you think that your SMS 2.0 site database might be problematic and you simply must retain that database information for historical purposes, one solution might be to maintain your “old” SMS 2.0 central site as a standalone site or as a child site of the “new” SMS 2003 central site so you still have access to the old site’s data when it’s needed.

Removing or Disabling Incompatible Features

SMS 2003 no longer supports several features of SMS 2.0. Before you upgrade an existing SMS 2.0 site, therefore, you must disable or remove those features. For example, SMS 2003 doesn’t use or recognize SMS 2.0 logon points or software metering server site systems, nor does it use the Event To Trap Translator client agent. You must disable the site systems and remove the client agent before you can proceed with the upgrade.

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.