IN THIS CHAPTER
The previous chapter (Chapter 8, “Installing Configuration Manager 2007”) discussed installing a new Configuration Manager (ConfigMgr) 2007 hierarchy. If you already have an existing Microsoft Systems Management Server (SMS) deployment, you will almost certainly want to preserve much of the work put into that SMS implementation when you upgrade to ConfigMgr 2007. This chapter presents the options that are available when migrating an existing SMS environment to Configuration Manager. It then explains in detail how to carry out the migration and deal with interoperability issues with a mixed SMS and ConfigMgr environment. The chapter also discusses some specific issues you may encounter during or after migration, and how you might deal with them.
When planning a migration to Configuration Manager, you should first assess your current environment. Here are the key questions you need to consider when looking at your SMS 2003 environment:
• Is your environment working well today? You should consider the services you are currently delivering with SMS and the success rate you are achieving.
• Is your server hardware adequate to support the ConfigMgr deployment you envision, or does the hardware need replacing?
• Does your hierarchy fit your current network environment?
You should also determine what new features you will support and how they will affect your requirements. Chapter 2, “Configuration Manager 2007 Overview,” presents the new capabilities of Configuration Manager 2007.
There are two basic strategies for migrating from an SMS 2003 environment to Configuration Manager 2007:
• Perform an in-place upgrade on sites running SMS 2003 Service Pack 2 (SP 2) or higher to upgrade directly to Configuration Manager.
• Carry out a side-by-side migration to replace your existing SMS sites with ConfigMgr sites.
Although an in-place upgrade is simpler than a side-by-side migration, there are circumstances under which you may want to consider the side-by-side approach:
• Restructuring— You want to restructure your hierarchy during migration. This is the most compelling reason to choose a side-by-side migration.
• Mixed environment— You plan to maintain a mixed environment for an extended period. One reason you may need to do this is to maintain compatibility with older clients not supported under ConfigMgr 2007, such as Windows 98 or Windows NT systems.
• Hardware upgrades— You plan to upgrade site server hardware. Although a side-by-side migration is not necessary for hardware upgrades, the extra work of replacing hardware and upgrading to ConfigMgr makes the advantages of an in-place upgrade less compelling.
Choosing your migration strategies is not an all-or-nothing decision. You may find that it makes sense to upgrade some of your sites in place, while replacing other sites in a side-by-side fashion.
About Supported Upgrade Paths
You cannot upgrade directly to Configuration Manager 2007 from any version of SMS earlier than SMS 2003 SP 2. If you are running an earlier product version, you must upgrade to SMS 2003 SP 2 or SP 3 before upgrading to ConfigMgr.
You may recall from the hierarchy planning discussion in Chapter 6, “Architecture Design Planning,” that a Configuration Manager site cannot report to an SMS 2003 parent site. This restriction means that you must always begin your upgrade with the central site and progress down the hierarchy. If you want to introduce ConfigMgr at a child site before upgrading the central site, you must detach the site from your hierarchy and perform an upgrade or side-by-side migration to create a standalone ConfigMgr site. You can later integrate that site into your hierarchy.
Before determining a migration strategy, review your current hierarchy to determine whether you will make any changes to it as you move to a Configuration Manager environment. There are two major reasons you may decide to modify your hierarchy during migration:
• Business requirements— You may find that your current SMS hierarchy is no longer optimal to meet the needs of your organization and match the requirements of your environment. It is likely that there have been changes to your business, your network, or your administrative model since you first deployed SMS to your organization. Your migration to Configuration Manager 2007 presents a good opportunity to review and improve upon your current hierarchy design.
• Product capabilities— The new features of Configuration Manager provide options and requirements not present in SMS 2003 and earlier versions. As an example, the new branch distribution point server role can replace a secondary site in many scenarios. Similarly, if one of your goals is to support Internet-only clients (a new feature of ConfigMgr 2007), you may decide to add a dedicated site for Internet-based client management (IBCM).
You might start by reviewing the material on hierarchy design in the planning chapters of this book (Chapters 4–6) as well as in the product documentation, asking yourself how you would plan a new implementation from the ground up to meet your goals and fit your environment. You can then compare the hierarchy you would envision to your current model and decide what changes to make.
You can upgrade an SMS 2003 SP 2 or SP 3 primary site to Configuration Manager 2007 by running the Setup program from the ConfigMgr 2007 installation media. Use the slipstreamed SP 1 version of ConfigMgr for upgrades wherever possible. Using a slipstreamed version saves the extra effort of applying the service pack after the upgrade; in addition, SP 1 has an enhanced prerequisite checker. The prerequisite checker is described in the next section of this chapter, “Running the Prerequisite Checker.”
In some cases, you may not be able to upgrade to SP 1 directly. In such a case, upgrade from a supported service pack level of SMS 2003 to the Release-to-Manufacturing (RTM) version of ConfigMgr 2007 and then upgrade again to SP 1.
As with any software upgrade, verify that you have a complete backup of your site server before upgrading the site server, site database server, or site database. You should also confirm you have all required installation media and supporting documentation available in the event you need to recover your site. For a complete list of requirements for recovering an SMS 2003 site, install and run the Recovery Expert from the SMS 2003 installation media.
You should also note that the upgrade removes any custom files you have added to the SMS folder structure. If you wish to retain these files, you should copy them to another location and restore them to their original location after the upgrade.
Microsoft released several feature packs for SMS 2003 that add functionality not included in the original product. If you installed any of the SMS 2003 feature packs, uninstall them before upgrading each site. The only exception to this is the Inventory Tool for Microsoft Updates (ITMU), used for patch deployment to SMS clients. (See Chapter 15, “Patch Management,” for a discussion of patch management for ConfigMgr 2007.) You should keep ITMU installed and upgrade it as part of your upgrade to Configuration Manager.
If you are using the Operating System Deployment (OSD) Feature Pack, your existing OS images will display under the OSD FP Packages node in the ConfigMgr console. You will need to deploy each of those images to a reference machine prior to the upgrade and capture them as part of your Configuration Manager OSD if you want to continue to use the images in Configuration Manager 2007 OSD. Chapter 19, “Operating System Deployment,” discusses Configuration Manager OSD.
The prerequisites for upgrading to Configuration Manager 2007 include the following requirements:
• All SMS 2003 sites being upgraded must be at SMS 2003 SP 2 or above.
• All site server systems must be running Windows Server 2003 SP 2 or above with .NET Framework 2.0 installed.
• All primary sites must be running SQL Server 2005 SP 2 or above.
• All sites you will be upgrading need to be in advanced security mode.
• Microsoft Management Console (MMC) 3.0 is required for the ConfigMgr console.
• SMS 2003 supported two types of clients: legacy clients and advanced clients. ConfigMgr sites support SMS 2003 advanced clients, but legacy clients do not work in ConfigMgr 2007 sites and are not supported by Microsoft. You should install the advanced client on SMS 2003 client systems running Windows 2000 Service Pack 4. ConfigMgr 2007 sites do not support clients running earlier versions of Windows.
The Configuration Manager installation media includes a prerequisite checker that looks for these and many other requirements. The next section of this chapter describes how to use this tool. Some additional considerations for site upgrades include the following:
• Running the prerequisite checker on the site server only verifies the readiness of the site server itself. You can run the prerequisite checker separately on management point servers to verify that your management point meets the requirements for Configuration Manager. You should also verify that any site system roles you have distributed to other systems meet the minimum requirement for those system roles. Chapter 6 discusses the requirements for site systems.
• If you modified the membership rules for any of the default SMS collections, the upgrade preserves those modifications. If you removed any of these collections, they are re-created unless you run Setup with the /NODEFAULTCOLL
switch.
Before running the actual site setup, run the prerequisite checker from the Configuration Manager installation media; then download the required files and resolve any issues reported. To run the prerequisite checker, launch splash.hta from the root folder of the ConfigMgr installation media. The splash screen, shown in Figure 9.1, offers several options.
Choosing Run the prerequisite checker brings up the Microsoft System Center Configuration Manager 2007 Installation Prerequisite Check Options screen, displayed in Figure 9.2.
Notice that the options for installing a new site are grayed out and the only available option in Figure 9.2 is Upgrade. There is also a check box allowing you to check the readiness of all secondary sites. You will want to select this option if you are running the prerequisite checker on a site server of a primary site with immediate child secondary sites. After verifying the appropriate options are selected, click OK to run the prerequisite checks. The checks may take a few minutes, after which you will see a screen displaying the results of the prerequisite check. Figure 9.3 shows an example of the prerequisite check results.
The output may show two types of results:
• A red circle with an X indicates a critical error, which is likely to cause Setup to fail. You must correct any critical issues before continuing.
• A yellow warning symbol with an exclamation mark indicates a possible problem that will not prevent you from upgrading your site but should be fixed prior to the upgrade.
Notice the text in the lower pane, which tells you that you can double-click any item to display details about how to resolve the problem or view the ConfigMgrPrereq.log file to help identify problems. Ensure you understand each issue presented by the prerequisite checker before continuing. The results screen also includes a link to view the latest prerequisite information. Use this link to access a complete list of prerequisite check rules with the severity level of each rule (warning or failure), a description of the prerequisite the rule is checking, and detailed information about the check. Figure 9.4 shows an example of the details displayed in the Results pane by double-clicking the “WSUS SDK on site server” result.
Chapter 15 discusses the prerequisites for ConfigMgr Software Updates. For this particular rule, the information displayed by the wizard is essentially the same as what you will find in the ConfigMgrPrereq.log file. In some cases, you will find additional information on the Setup Prerequisite Checks web page (located at http://technet.microsoft.com/en-us/library/bb680951.aspx) and in the log file.
As an example, if you double-click the “Client GUID consistency” error displayed in Figure 9.4, the text displayed in the user interface simply states “Inconsistent client GUIDs can lead to SQL Server errors and should be resolved before continuing the upgrade process.” The Setup Prerequisite Checks web page provides a somewhat more detailed description of the rule “Verifies that the Configuration Manager 2007 site database to be upgraded does not contain inconsistent client GUIDs.” The most useful information for resolving this problem is in the ConfigMgrPrereq.log, located in the root of the C drive:
You can copy the SQL query shown in the log and run it against your site database to find out which client GUIDs (Globally Unique Identifiers) are causing the problem. The exact steps for running the query will vary depending on the version of SQL Server you are running. If you are running SQL Server 2005, you can execute the query as follows:
The results show the system SMS-000005 has an inconsistent SMS GUID. In this case, the problem can be corrected by deleting this system from the database, removing the SMS client software on the system, or by deleting the smscfg.ini file from the Windows folder and reinstalling the client.
The detail of the unsupported client operating system version rule included in the ConfigMgrPrereq.log contains the following SQL query:
This query illustrates the fact that you may need to make some minor adjustments to the SQL syntax. In this example, the site name appears in the log enclosed in double quotes (“HOU”). You will need to replace this with the site name in single quotes (‘HOU’) before executing the query. The additional details of this rule indicate the following:
Configuration Manager clients are only supported on Windows 2000 SP4 or
later operating systems.
After running the SQL query to identify those clients running unsupported operating system versions, you will need to either upgrade these clients to a newer operating system or exclude them from the Configuration Manager migration.
The prerequisite checker shown in Figures 9.2 through 9.4 is from the Configuration Manager 2007 RTM version. Microsoft has enhanced the prerequisite checker shipped with Configuration Manager Service Pack 1 with a number of additional checks. Figure 9.6 shows the results when using the SP 1 prerequisite checker on the same SMS 2003 site server. Notice the scroll bars, which indicate you can see additional results by scrolling down on the results list.
The Details pane shows that the particular rule selected in Figure 9.6 applies only to Out of Band service points (a new feature in SP 1). However, some of the added checks also apply to the RTM version. It is therefore advantageous to run the SP 1 prerequisite checker, even if you are upgrading only to Configuration Manager 2007 RTM.
SMS 2003 SP 2 and above versions provide support for both SQL Server 2000 SP 4 and SQL Server 2005. If your site database server is running SQL Server 2000, you will need to upgrade to SQL Server 2005 and apply Service Pack 2 before you can upgrade your SMS primary site. The next sections of this chapter step through a sample SQL Server upgrade. For additional information about upgrading SQL Server, you can refer to the SQL Server documentation and the release notes on the product installation media.
Before upgrading SQL Server, download and run the latest SQL Server 2005 Upgrade Advisor from http://www.microsoft.com/downloads/details.aspx?familyid=1470e86b-7e05-4322-a677-95ab44f12d75&displaylang=en (at www.microsoft.com/downloads, search for SQL Server 2005 Upgrade Advisor). After the download is complete, execute the SQLUASetup.msi Installer package to install the Upgrade Advisor. Once it is installed, you can launch the Upgrade Advisor from Start -> Programs -> Microsoft SQL Server 2005. The welcome screen shown in Figure 9.7 includes the option Launch Upgrade Advisor Analysis Wizard.
The Analysis Wizard allows you to select the components and databases to analyze, and it generates a report. You can view the report from the launch report button when the wizard completes, or you can use the Launch Upgrade Advisor Report Viewer link on the Upgrade Advisor welcome screen. Be sure to investigate any potential problems indicated in the Upgrade Advisor report.
The report shown in Figure 9.8 identified an issue with one of the extended stored procedures registered by SMS. The links in the report indicated that the affected object was the extended stored procedure xp_SMS_notification. Following the instructions on the “Tell me more about this issue and how to resolve it” link, the issue was corrected by executing the following SQL queries to re-register the procedure with the full path:
After preparing your database server for the SQL Server upgrade, you can launch the Setup from SQL Server installation media splash screen. Perform the following steps:
Before upgrading an SMS 2003 primary site to Configuration Manager 2007, test the database upgrade to ensure there are no incompatibilities. To test the database upgrade, perform the following steps:
You can copy the database using SQL Server Management Studio by right-clicking the site database and choosing Tasks -> Copy Database, as shown in Figure 9.10. This launches the Copy Database Wizard. The wizard is straightforward, and you can generally accept the default options. Note that the SQL Server Agent service must be running for the database copy to succeed. When the copy completes, you should record the size of the newly copied database files. You will need this information to estimate the space requirements for the database upgrade.
setup /testdbupgrade <databasename>
Run this from the smssetupin<processor architecture> folder of the ConfigMgr installation media, where <databasename> is the name of your copied database and <processor architecture> is generally i386.
You should also compare the size of the upgraded database files with the initial database size you recorded in step 1. This provides an estimate of the additional space required when you upgrade the database.
Before upgrading your database, export any custom objects you created outside of SMS. Any custom tables created in the SMS database, for example, are removed by the upgrade, although the upgrade preserves custom views based on the default SMS tables. You should also be prepared to re-create any customizations made to default SMS reports, because the upgrade process overwrites changes made to the default reports.
Any custom objects you have created within SMS, such as custom collections or cloned reports, are preserved through the upgrade.
After completing the prerequisites outlined in the previous sections, you are ready to upgrade your primary site.
You should also verify client push installation is disabled on your site prior to the upgrade. This will allow you more control over the client upgrade process. The “Upgrading SMS 2003 Clients” section of this chapter discusses upgrading clients.
Perform the following steps to upgrade your primary site:
If you choose to upgrade ITMU at this point, the ITMU upgrade process prompts you to download the latest security updates catalog from the Web or supply an alternate location for the catalog, as shown in Figure 9.18.
Once you complete this dialog box and click Next, Setup finishes the ITMU upgrade and displays the Setup Complete dialog box, shown in Figure 9.19.
The upgraded ITMU can deliver patches to SMS 2003 clients in your ConfigMgr site. As the message in the dialog box in Figure 9.19 indicates, you will need to ensure that your clients have Microsoft Installer (MSI) 3.1 or later if you use ITMU to deliver updates for Microsoft Office or other Windows Installer–based updates to those clients. To provide continuity of service, you should plan to deploy the appropriate MSI version to your clients before upgrading your site.
For Configuration Manager clients, you will need to install WSUS and complete the additional steps required for ConfigMgr software updates. Chapter 15 discusses software updates and patch management. The “Migrating WSUS to Configuration Manager” section of this chapter discusses migrating from standalone WSUS to ConfigMgr WSUS. Chapter 15 also discusses using ITMU to support SMS 2003 clients in your ConfigMgr environment.
You can upgrade a secondary site after you upgrade its parent primary site. Before upgrading your secondary sites, run the prerequisite checker on the parent primary site server again—this time check the All Secondary Sites box on the Installation Prerequisite Check Options page, previously displayed in Figure 9.2, to verify the sites meet all prerequisites for the Configuration Manager upgrade. The prerequisite checker displays any errors or warnings in the results screen and generates the log file c:ConfigMgrPrereq.log on the secondary site server.
To upgrade a secondary site, perform the following steps:
The upgrade will take several minutes to complete—longer if you are copying files across a wide area network (WAN) link with limited available bandwidth. You can view the site properties in the ConfigMgr console to verify that the version is now 4.00.5931.000 (ConfigMgr 2007 RTM) or higher. You can also use the console to view the site status for any errors that may have occurred.
Unless you have client push installation enabled, your SMS 2003 clients will not automatically upgrade to the Configuration Manager client during your site upgrade. Here are some points to keep in mind:
• You can use any of the supported discovery and client deployment methods to deploy the client agent. Chapter 12, “Client Management,” describes discovery and client deployment.
• You can use software distribution to selectively deploy the upgrade to selected collections of clients. To use software distribution to deploy the client upgrade, you will first need to create the Microsoft Configuration Manager Client Upgrade 4.0 ALL package, using the Package Definition option in the Create Package from Definition Wizard, as shown in Figure 9.25.
To complete the wizard, you will need to choose This package contains source files option and then specify the package source location as the client folder under your ConfigMgr installation folder. For more information about software distribution, see Chapter 14, “Distributing Packages.”
Once your site upgrades successfully, you will need to configure any new site systems and make any changes required for site maintenance tasks, updated boundaries, discovery methods, client agent settings, and client installation methods. Chapter 8 discusses these configuration tasks. Other post-upgrade considerations include the console, site boundaries, and the SMS SQL Monitor, which are discussed in the next sections.
During the upgrade, the existing SMS Administrator console on the site server is upgraded to the ConfigMgr console. You cannot use the ConfigMgr console to manage SMS 2003 primary sites, or the SMS 2003 Administrator console to administer ConfigMgr sites. When you initially launch the console after upgrading to Configuration Manager 2007, you may need to connect to the site database using the Connect to Site Database Wizard. Chapter 10, “The Configuration Manager Console,” describes this wizard.
You will need to separately upgrade the console on administrative workstations. Running Setup on a remote console installation installs the Configuration Manager console alongside the SMS 2003 Administrator console. If you prefer to upgrade the console to the ConfigMgr version only, run Setup with the /UPGRADE
switch. Once the ConfigMgr console is installed on a machine, you will not be able to install the SMS 2003 console or apply a service pack to an existing SMS console installation. Although the two console versions can coexist on a machine, you cannot uninstall one without also removing the other.
Most site properties and settings will be preserved in your Configuration Manager site, although any site boundaries defined in SMS 2003 will be migrated as read-only. You will not be able to edit these boundaries, and will need to delete and re-create the boundaries to make any changes.
SMS 2003 implemented the SMS SQL Monitor as a separate service. This component runs as an SMS Executive thread in Configuration Manager 2007. Although Setup should remove the SQL Monitor service, in some cases this service is not cleanly removed and still shows up as an installed service set to start automatically (although it will fail to start). If the SMS SQL Monitor service is still installed after your upgrade, you should disable the service.
If you are currently using standalone WSUS for patch deployment rather than deploying patches with SMS 2003, you will need to disable any Active Directory (AD) group policies you have configured for managing WSUS clients. Configuration Manager clients receive policies from their assigned ConfigMgr site rather than from AD. If you need to keep the AD group policies in place to manage other WSUS clients in your environment, you can accomplish this in several ways, although each method can involve a substantial amount of work:
• Move your ConfigMgr clients and your WSUS clients to separate Organizational Units (OUs) in Active Directory, and apply the WSUS policies only to the WSUS clients.
• Use security groups to filter the application of GPOs so the WSUS policies will not apply to ConfigMgr clients. To accomplish this, you will need to be able to add the ConfigMgr clients to a security group that has the apply group policy right on the GPO set to denied. For information on using security group membership to filter GPO applications, see http://technet.microsoft.com/en-us/library/cc779291.aspx.
• Use WMI to filter the application of GPOs so that the WSUS policies will not apply to ConfigMgr clients. For information on WMI filtering, see http://technet.microsoft.com/en-us/library/cc781936.aspx.
Here’s a WMI filter to exclude Configuration Manager clients:
RootCCM;Select * from SMS_Client where ClientVersion not like '4.%'
A WMI filter to exclude all clients assigned to the HOU site would look like this:
RootCCM;Select * from SMS_Client where SMS_Authority not like 'SMS:HOU'
If you decide to adopt any of these methods, you should carefully test them during your proof of concept and pilot phases before deploying them to your live environment. Chapter 7, “Testing and Stabilizing,” discusses the proof of concept and pilot phases.
You will need to install WSUS on each system you plan to use as a software update point (SUP), and install the WSUS administration components on your site servers. Exit the WSUS setup without configuring synchronization settings or update classifications, categories, and languages, because you will configure these settings in the ConfigMgr console.
You can use an existing WSUS server as an SUP; however, you should delete the software updates metadata from the database prior to configuring the system as an SUP. Failure to do so can cause a number of problems, including clients scanning for and reporting on update classifications, categories, and languages not configured for your site.
Chapter 15 discusses installing and configuring software update points.
Whereas an in-place upgrade provides the advantage of preserving your SMS 2003 sites and settings, a side-by-side migration may be more appropriate if you plan major changes to your SMS environment. Carrying out a side-by-side migration includes the following tasks:
• Standing up new Configuration Manager 2007 sites with new site codes alongside your existing SMS 2003 sites.
• Migrating site boundaries, clients, and database objects from your existing SMS hierarchy to the new ConfigMgr sites.
• Removing any entries published by the old sites from Active Directory and WINS. If you will continue to use your old site systems for other purposes, you should review their Active Directory group memberships and remove them from any groups that are no longer required.
Microsoft provides a very useful flowchart describing the major activities for a side-by-side migration, available at http://technet.microsoft.com/en-us/library/bb681052.aspx.
As part of a side-by-side migration, you will need to assign site boundaries manually to your ConfigMgr sites and remove the corresponding boundaries from your SMS sites. The important point is that site boundaries should never overlap, because overlapping boundaries will cause serious problems for both SMS and ConfigMgr clients. Clients use site boundaries to determine their site assignment and to receive policy and content from the appropriate sites. Overlapping boundaries can cause unpredictable results for operations that depend on clients correctly determining what site they are located in, such as software distribution.
You should first remove site boundaries from the SMS sites you plan to decommission, and allow time for replication before adding the boundaries to your new ConfigMgr sites. Chapter 8 describes the procedure for adding boundaries to a Configuration Manager site. Before adding boundaries to one of your ConfigMgr sites, remove any boundaries from your SMS sites that would contain any part of the IP address space or AD sites that will comprise the ConfigMgr site boundaries. To delete a site boundary in SMS 2003, perform the following steps:
Figure 9.26 shows the SMS 2003 Site Boundaries dialog box.
Several methods are available to migrate your existing SMS 2003 clients to your new ConfigMgr sites. Here are the major options:
• Use any of the client deployment methods that allow you to specify a site code to assign the clients to the new site at the same time they are upgraded. For example, you might run the command CCMSETUP.EXE /noservice SMSSITECODE=
xyz
, where xyz
is the client’s new site code. You can also use client push installation to upgrade clients and assign them to their new site code. Chapter 12 describes client push installation.
• Use SMS 2003 software deployment to advertise a package for reassigning the clients. One way to create a package for site assignment is to use a Visual Basic script (VBScript) similar to the following:
Your program command line will then be cscript.exe <
path to vb script><script name>.vbs
. The <
path
>
is not required if your package includes source files and the script is in the root of the package source directory.
Because you have probably already removed the boundaries from your SMS site, your clients will treat your distribution points as remote. You will therefore need to select the option in your advertisement settings to either download or run from a remote distribution point when the package is not available on a local distribution point.
• If the SMS console (“Right Click”) tools are installed, you can right-click a collection or individual SMS client and use the tools to reassign all clients in the collection. The console tools will attempt to connect to each system in the collection and initiate the site change; therefore, any clients that are offline or otherwise inaccessible will not receive the site change.
• Log on to an individual client machine and change the site code on the Advanced tab of the Control Panel Systems Management applet.
You will generally want to use one of the first two methods listed here to migrate most of your client systems. The last two methods are useful for picking up any clients missed by your primary migration method.
The most common way to preserve the objects you have created in SMS database, such as packages and collections, is to temporarily join your new ConfigMgr central site to the existing SMS hierarchy. Because a ConfigMgr site cannot be a child of an SMS 2003 site, this means you will need to do one of the following:
• Upgrade your existing SMS 2003 central site to ConfigMgr before joining the new site to it. Although this should not affect the rest of your SMS hierarchy, it does require that the existing central site meet all the ConfigMgr system requirements.
• Install your new ConfigMgr central site as an SMS 2003 SP 2 or higher site, join it to the existing SMS 2003 hierarchy, allow the objects to replicate, and then detach the site. You can then upgrade the site to Configuration Manager 2007.
Alternatively, you can use a temporary site to transfer the objects. You can build an SMS 2003 site, perhaps as a virtual machine (VM), join it to your production SMS hierarchy, allow replication to complete, and then detach it from the SMS hierarchy. You will then upgrade the temporary site to ConfigMgr, remove any objects you no longer need, and make your new ConfigMgr production site a child of the temporary site. After the objects replicate to your permanent ConfigMgr site, detach your permanent ConfigMgr central site from the temporary site and decommission the temporary site. This method is a bit more work but allows you to have a clean ConfigMgr installation for your permanent site rather than upgrading, and it does not require you to upgrade your production SMS central site.
Queries and reports do not replicate down the hierarchy. You must export these objects from the SMS sites where they are defined and import them into your ConfigMgr site, as described in Chapter 7. Microsoft also has tools available for migrating SMS objects to ConfigMgr. These tools are not publicly available; contact your Microsoft support representative if you are interested in using these tools.
SMS and Configuration Manager use Managed Object Format (MOF) files for hardware inventory. These files are substantially different in Configuration Manager from those in SMS 2003. As discussed in Chapter 3, “Looking Inside Configuration Manager,” the data classes defined by ConfigMgr 2007 are now defined in the configuration.mof file, whereas the reporting classes are specified in the SMS_Def.mof file. This means that you will need to separate out any custom classes defined in your SMS 2003 SMS_Def.mof or mini-MOF files and then add the appropriate MOF language to each of the ConfigMgr .mof files.
Before the upgrade, copy your SMS_Def.mof file and any mini-MOF files you are using to a separate location to avoid them being overwritten. After the upgrade completes, use a text editor to open and edit the .mof files.
If you have custom classes defined in your SMS 2003 SMS_Def.mof file or in mini-MOF files, you can use the #pragma namespace
compiler directives in the file to locate the data and reporting classes for these definitions. The SMS 2003 SMS_Def.mof file uses a #pragma
namespace
compiler directive to instruct the compiler to use a particular namespace. Most custom data classes extract data from the rootCINV2 WMI (Windows Management Instrumentation) namespace.
In general, you can locate data classes in the SMS_Def.mof or mini-MOF by searching for the #pragma namespace rootCINV2
directive. You should append the block of text following this directive to the end of the configuration.mof file (without the #pragma namespace
directive itself). You will find the corresponding reporting class definitions under the #pragma namespace rootCINV2sms
. These should be copied to the SMS_Def.mof file.
Although you can upgrade SMS 2003 SP 2 sites directly to ConfigMgr 2007, you should upgrade them to SP 3 if you plan to maintain SMS 2003 sites for a significant period. ConfigMgr clients running Windows Vista will not function correctly if they roam to SMS 2003 SP 2 sites. In addition, SMS 2003 SP 2 clients cannot roam to ConfigMgr sites in native mode.
SMS 2003 SP 2 is no longer supported based on the Microsoft support life cycle. You should therefore upgrade any SP 2 sites and clients to SP 3 or ConfigMgr 2007 as soon as possible to continue to receive support and software updates.
In a mixed environment, you will use the SMS 2003 Administrator console to administer SMS 2003 primary sites and the ConfigMgr console to administer ConfigMgr primary sites. If you have secondary sites running SMS 2003, you will be able to administer them through the parent primary site; however, you will not be able to change the accounts or passwords used by these secondary sites. You will also not be able to create or configure Remote Access Service (RAS) senders or configure Active Directory Security Group Discovery on SMS 2003 secondary sites with ConfigMgr parent sites.
If you encounter any failures during the setup process, you should check the setup log at c:ConfigMgrSetup.log for any error messages. Some common upgrade issues include the following:
• You receive the following error message: Cannot insert the default site control image to the database. ConfigMgrSetup.log contains the entry “error xp_SMS_notification not found.”
This generally occurs when you have reinstalled SQL Server on the site database server and the xp_SMS_notification extended stored procedure was removed during setup. To correct this problem, use the procedure described in http://support.microsoft.com/kb/556084 to re-create the extended stored procedure.
• Setup fails while attempting to install the SMS Provider. ConfigMgrSetup.log contains the entry “CompileMOFFile: Failed to compile MOF.”
This generally results from an incorrect AD Service Principal Name (SPN) registration. See Chapter 5, “Network Design,” for a discussion of Service Principal Name issues.
• Upgrading a secondary site may fail when using local source files if the bootstrap process is unable to locate the installation files in the correct path or if there is a version mismatch.
SMS_Bootstrap.log will show errors locating the install.map file or an incorrect build number in install.map.
• Setup fails to correctly detect the type of site you have installed.
This may be the result of previous failed upgrade attempts or incorrect information in the site server registry.
• The SMS SQL Monitor service is no longer required in Configuration Manager 2007 SP 1. You should disable or delete this service after the upgrade to avoid misleading error messages at logon, in the system event log, and in the ConfigMgr status message system.
One way to delete the service is to use the SC.EXE Windows Resource Kit tool with command line SC delete SMS_SQL_Monitor
. For information about SC.EXE, see http://technet.microsoft.com/en-us/library/bb490995.aspx. After you delete the service, you can manually remove the following Registry keys:
• HKEY_LOCAL_MACHINESoftwareMicrosoftSMSCOMPONENTSSMS_SITE_COMPONENT_MANAGERComponent Servers<servername> ComponentsSMS_SQL_MONITOR
• HKEY_LOCAL_MACHINESoftwareMicrosoftSMSTracingSMS_SQL_MONITOR
If Setup completes successfully, you should review the site status to make sure all systems and components have an OK status, or investigate any errors or warnings that have occurred. Chapter 21 discusses the status system.