Appendix H - Upgrading to SMS 2003
This appendix identifies the tasks you must perform to upgrade your site hierarchy. Before you upgrade to Microsoft® Systems Management Server (SMS) 2003, ensure that you understand SMS 2003 architecture, and the concept and planning processes described throughout this document.
To upgrade from a previous version of SMS, you must be running SMS 2.0 Service Pack 4 or later. Also, SMS 2.0 sites that report to the upgraded site must be running SMS 2.0 SP4 or later before the parent site is upgraded to SMS 2003. To identify the upgrade issues that apply specifically to your SMS hierarchy and decide how to address them, see “Planning a Site Upgrade” later in this appendix.
This appendix assumes that you are familiar with SMS accounts-related security considerations. For more information about creating and configuring these accounts and about SMS 2003 security modes, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.
In This Appendix
Planning a Site Upgrade
Performing Site Upgrades
Performing Post-Upgrade Tasks
Planning a Site Upgrade
Before upgrading to SMS 2003 from SMS 2.0, you must create a plan that addresses the strategies you want to use to upgrade your SMS hierarchy, sites, and clients. You must also consider how to address features that are not supported in SMS 2003, and how to plan for new features that are in SMS 2003.
Before you can create an upgrade plan, you must determine what goals and results you want to achieve by upgrading to SMS 2003.
Determine whether you to upgrade all or some of your SMS 2.0 sites to SMS 2003.
If you have mission-critical applications that run on Microsoft Windows® 95 only, you cannot upgrade those clients to SMS 2003. However, you might want to migrate those clients to a holding site. For more information about holding sites, see the “Upgrade Strategies” section later in this appendix.
You might have secondary sites on Microsoft Windows NT® 4.0 backup domain controllers (BDCs). If any BDC is the first domain controller upgraded to Microsoft Windows 2000, to support upgrading to SMS 2003, then that BDC becomes a primary domain controller emulator.
Determine whether to deploy the Legacy Client, Advanced Client, or both to each SMS site.
You might decide that one of your sites must support the Advanced Client only, and that you want all your other sites to support the Legacy Client. Phasing your transition to the Advanced Client allows the opportunity for you to sufficiently test the Advanced Client and prepare your help desk staff to support it. Regardless of which client you deploy to a given site, each client has its own requirements for your organization. For example, the Advanced Client requires server infrastructure that the Legacy Client does not. See “Upgrading SMS Client Software” in Appendix I: "Appendix I - Installing and Configuring SMS Clients" for more information about upgrading clients.
Some other issues to consider include:
Operating system requirements
Training requirements
Management requirements
Support requirements
Network bandwidth constraints
Determine which SMS 2003 features you want to use.
SMS 2003 has many useful features. Some features have requirements that must be met before you can use those features. Keep your goals in mind as you determine which upgrade strategy helps you achieve the desired results, because feature requirements might conflict with your desired results.
Note
Due to changes in hardware inventory between SMS 2.0 and SMS 2003, clients in sites upgraded from SMS 2.0 to SMS 2003 will perform an inventory resynchronization, sending full hardware inventory reports instead of delta reports. If many clients perform resynchronization at the same time, these inventory resynchronizations might cause excessive load on the network and might cause the site systems in your SMS hierarchy to take a long time to process hardware inventory data. To reduce the load on your network and SMS site servers, consider performing a throttled site upgrade to prevent too many clients from resynchronizing at the same time.
Unsupported SMS Features and Platforms
The following features are not supported in SMS 2003. For more information, see Chapter 6: “Understanding Interoperability with SMS 2.0” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.
Novell NetWare
SMS site systems running on Novell NetWare must be removed manually. Novell NetWare clients are orphaned during upgrade. If you use IPX site boundaries at SMS 2.0 child sites of SMS 2003 parent sites, you cannot use server-locator-based client installation to install clients at the SMS 2.0 sites. You must continue using SMS 2.0 client installation methods at SMS 2.0 sites, such as Manual Client Installation.
IPX site boundaries
Clients that are x86-based computers, use IPX as their site boundary, and do not fall into any supported site boundary methods, will be uninstalled. Novell NetWare clients that use IPX as their site boundary and do not fall into any of the supported site boundary methods are orphaned during upgrade.
Alpha-based systems
Alpha-based clients are orphaned during upgrade. Remaining files used to support Alpha clients can be manually removed from the site server after upgrade.
Crystal Reports
Crystal Reports can be uninstalled prior to upgrading to SMS 2003. Use Add or Remove Programs in Control Panel to complete this task. See Appendix H: "Appendix H - Upgrading to SMS 2003," for more information.
Logon discovery
Windows Networking Logon Discovery is not included as a discovery method in SMS 2003.
Logon installation
In SMS 2003, computers can still be installed when users log on. This can be accomplished with Logon Script-initiated Client Installation. For more information about client installation, see Appendix I: "Appendix I - Installing and Configuring SMS Clients."
Logon points
SMS 2003 does not support logon points on the domain controller.
Legacy software metering
Software metering is now fully integrated with SMS 2003. Previous versions of software metering are not supported. For more information about removing legacy software metering, see Appendix H: "Appendix H - Upgrading to SMS 2003."
SNMP Event to Trap Translator
This feature is natively supported in Windows 2000 and later operating systems.
SMS 2003 Features
While you are planning your upgrade, you should consider the new features that SMS 2003 provides, and features that have changed since SMS 2.0. New features might require decisions that influence how you perform your upgrade. Changes to SMS 2.0 features in SMS 2003 might also require consideration.
Active Directory schema extension
During an SMS 2003 upgrade, you do not have the option to extend the Active Directory® schema. However, you must extend the Active Directory schema if you plan to implement automatic site assignment by using Active Directory or roaming boundaries for Advanced Clients. You must also extend the schema to use public key exchange available with SMS advanced security. You can extend the Active Directory schema after an upgrade by using the ExtADSch.exe tool, provided you have the proper rights.
Active Directory site boundaries
Active Directory site boundaries are configured after upgrading to SMS 2003. After upgrading, consider migrating to Active Directory site boundaries. Although you can use Active Directory site boundaries to define boundaries for your site, careful planning is required.
Advanced security
For SMS to use Advanced Security, Microsoft SQL Server™ 2000 must already be present on the site server to upgrade. To use Advanced Security, you must first complete your upgrade, be a part of an Active Directory forest on a computer running Windows 2000 SP2 or later, and then implement Advanced Security.
SMS Reporting
If you have previously used the SMS 2.0 Web Reporting tool, all custom reports that you have created are removed when you upgrade to SMS 2003. You must manually copy each query and save it and manually to recreate the report upon which it was based.
SMS 2.0 hardware inventory customization
SMS 2.0 hardware inventory customizations are not migrated when you upgrade to SMS 2003. You must manually include those customizations in the SMS_def.mof file that is created during the upgrade process. For example, in SMS 2.0, classes that were registered in the cimv2\sms namespace are registered in the cimv2 namespace in SMS 2003. You can avoid losing the data from your hardware inventory customizations by disabling the hardware inventory client agent before beginning the site upgrade. For more information about how SMS_def.mof is preserved during upgrades, see Chapter 2: “Collecting Hardware and Software Inventory,” in the Microsoft Systems Management Server 2003 Operations Guide.
If you plan to maintain a mixed-version hierarchy, consider using a standard SMS_def.mof throughout your hierarchy. Differences between the SMS_def.mof files at different sites in the hierarchy can lead to conflicting hardware inventory data. To prevent conflicts, ensure that each site in the hierarchy uses the same hardware inventory definitions. For more information about how to standardize the SMS_def.mof files in your hierarchy, see Chapter 6: “Understanding Interoperability with SMS 2.0” in the .
Note
If you implemented your SMS 2.0 hardware inventory extensions without changing the SMS_def.mof, adjust those extensions so that the reporting classes are included in the SMS_def.mof. You can still specify the data class definition and population in your customization.
Software inventory customization
When you upgrade a site, customized inventory names are migrated to SMS 2003 and default inventory collection names are installed. If you have previously removed any default inventory collection names, the collection names reappear in Software Inventory Client Agent Properties after the upgrade.
Preparing to Upgrade
To prepare for your migration, do the following:
Replace hardware and operating systems before upgrading to SMS 2003, if possible.
Resolve issues found by the Deployment Readiness Wizard.
Replace Hardware and Operating Systems Before Upgrading to SMS
Before you upgrade your SMS sites or clients, review the “Getting Started” chapter in the . It details system requirements and platforms supported by SMS 2003. This review helps you determine if you must plan for hardware or operating system upgrades and replacements. It is important to make these changes to your hardware and operating systems before upgrading to SMS 2003.
However, you might consider replacing hardware during a side-by-side upgrade if you want to establish new SMS sites on new hardware. For more information about side-by-side upgrades, see the “Side-by-Side Hierarchy Upgrades” section later in this appendix.
Resolve Issues Found by the Deployment Readiness Wizard
The Deployment Readiness Wizard (DRW) helps you determine what you have to do to prepare your existing SMS site hierarchy for an upgrade to SMS 2003 or to SMS 2003 Service Pack 1 (SP1). If you are upgrading from SMS 2.0 to SMS 2003, run the version of DRW that is included on the SMS 2003 CD. If you are upgrading from SMS 2.0 or SMS 2003 to SMS 2003 SP1, run the version of DRW that is included on the SMS 2003 SP1 CD.
The wizard normally runs during the upgrade process. If the wizard finds errors, you must correct them and then run the wizard again before the upgrade can continue. You can run the wizard manually from the SMSSETUP\BIN\I386 folder on your SMS product CD. After you correct all identified problems, upgrade proceeds.
Note
Depending on the complexity of your site hierarchy, it might take several hours to run the Deployment Readiness Wizard.
Note
If a primary site server is running the Advanced Client software, and you are using software distribution to run DRW.exe on that primary site server, the advertised program to run DRW.exe will not run successfully on the primary site server if DRW.exe needs to access another site server, such as a secondary site server. In addition, if the advertised program is run on a secondary site server, DRW.exe cannot run all tests successfully or update the registry of the secondary site server with test results, which will prevent upgrade.
If you plan to use software distribution to run DRW.exe on a primary site server that is an Advanced Client, you must manually grant the machine account of the primary site server the appropriate rights to the secondary site server.
Note
The Deployment Readiness Wizard is not compatible with Windows NT 4.0. When this tool is run (with or without the /q quiet switch) on a Windows NT 4.0 operating system with SP4 or SP5, a message box is displayed indicating that OLEACC.dll is missing.
When running the tool without the /q switch on a Windows NT 4.0 operating system with SP6a, a message box is displayed indicating that the tool cannot run on that operating system and that you must upgrade to Windows 2000.
To ensure that the tool runs successfully on a computer running Windows NT 4.0 operating system with SP6a, run it with the /q switch.
The wizard runs the following types of tests:
Platforms and operating system tests
SMS version tests
Database tests
SMS 2.0 features tests
The wizard returns the following types of test results:
Passed
Passed with warning
Error
When the wizard completes its tests, detailed results are displayed in the Deployment Readiness Tests Report in SMS\Logs\<sitecode>_Report.xml. Summary test result data is stored in %WinDir% in a log file named SMSDRW.log.
SMS 2003 does not support all the operating systems, network operating systems, or processor types that SMS 2.0 did. You must run the Deployment Readiness Wizard on SMS 2.0 SP4 or higher site servers. The following tables list tests run by the Deployment Readiness Wizard. Some tests are run only when you are upgrading from SMS 2.0 to SMS 2003. These are identified in the Test Name column of each table with the text SMS 2003 specific test. Some tests are run only when you are upgrading from SMS 2.0 or SMS 2003 to SMS 2003 SP1. These are identified in the Test Name column of each table with the text SMS 2003 SP1 specific test. For a complete list of Deployment Readiness Wizard tests that includes steps for resolving the warnings and errors generated, see SMS 2003 Deployment Readiness Wizard Procedures for Resolving Test Failures located at https://www.microsoft.com/technet/prodtechnol/sms/sms2003/drwfaq.mspx.
Table H.1 SMS 2003 Deployment Readiness Wizard Platforms and Operating System Tests
Table H.2 SMS 2003 Deployment Readiness Wizard SMS Version Tests
Table H.3 SMS 2003 Deployment Readiness Wizard Database Tests
Table H.4 SMS 2003 Deployment Readiness Wizard SMS 2.0 Features Tests
Test name |
Information |
Failure type |
|---|---|---|
Backlogged inboxes |
Verifies that the site server is processing critical inboxes in a timely fashion, and does not have any files older than one day. Review the tests results for more information. |
Warning |
Client GUID consistency |
Verifies that no clients have inconsistent GUIDs in the SMS site database. This scenario can occur, for example, if a client had its GUID set in the XRef table but not in the System_DISC table, a new DDR is received for the client, and Discovery Data Manager tries to update the GUID in the XRef table. The GUID cannot be updated, and a SQL error results. For this test to pass, all client GUIDs must be consistent. To correct this situation, run the following SQL Query: delete sys from System_DISC sys join MachineIdGroupXRef xref on sys.ItemKey=xref.MachineID where IsNULL(SMS_Unique_Identifier0,'') != IsNULL(GUID,'') |
Error |
DP has latest versions of packages |
Verifies that all distribution points in the site have the latest version of software distribution packages. Review the test results for more information. |
Warning |
Duplicate client IDs |
Verifies that the site does not have any duplicate client IDs in its database. The scope of this test is all clients assigned to the site or any site under it in the hierarchy. Duplicate client IDs can cause various problems including client inventories that are not valid and problems with software distribution. Review the test results for additional information. |
Warning |
Event to trap translator |
Verifies that the SNMP Event to Trap Translator agent is not enabled on the site. You must disable this agent for the test to succeed. Note that this feature is natively supported in Windows 2000 and later operating systems. |
Error |
Hardware Inventory Group Map |
Verifies that the inventory definitions for the SMS 2.0 site have not been extended in a way that conflicts with the updated inventory definitions for SMS 2003. Review the test results for more information. |
Warning |
Inactive Clients |
Verifies that all the clients assigned to the site recently communicated successfully with the site client access points (CAPs). If clients are not communicating with the site server, they might not upgrade successfully. |
Warning |
Logon Client Installation Disabled |
SMS 2003 does not support logon points. This is because SMS 2003 does not support Windows Networking Logon Discovery or Windows Networking Logon Installation. You must disable Logon Client Installation for the test to succeed. |
Error |
Logon Discovery Disabled |
Because SMS 2003 does not support logon points, logon discovery is not included as a discovery method in SMS 2003. You must disable Logon Discovery for the test to succeed. |
Error |
Logon points installed in Hierarchy |
Verifies that no logon points are currently installed in the hierarchy. For the test to succeed, you must disable all logon points. Ensure that your logon scripts no longer call SMSls.bat. Instead, invoke capinst.exe with optional command-line switches in your logon scripts. |
Error |
Multi-site assigned clients |
Multi-site assignment is unsupported in SMS 2003. During upgrade, a new Legacy Client removes all sites except the one that initiated client upgrade from its membership list if the client is within the boundaries of multiple sites. A Legacy Client automatically uninstalls if all site boundaries are removed, or if it moves out of the boundaries of its assigned site, unless travel mode is enabled. |
Warning |
Packages SQL constraint |
Verifies that there are no duplicate package IDs. |
Error |
SMSExec is running |
Verifies that SMSExec is running on site systems such as the SMS site server and CAPs. |
Error |
SMSExec Service crashes |
Verifies that no SMSExec service crashes have happened on the site server within the last 30 days. SMSExec service crashes are indicative of problems with site systems. Review the test results for more information. |
Warning |
Site control file processing backlog |
Verifies that site control file changes are being processed in a timely fashion. For the test to succeed, the site control file must not have more than four pending changes. Review the test results for additional information. |
Error |
Software Distribution: Uninstall registry key usage |
SMS 2.0 programs using the Remove software when it is no longer advertised option, which uses the Uninstall registry key, do not work on the Advanced Client. Review the test results for additional information. |
Warning |
Software metering site systems |
Previous versions of software metering are not supported. For the test to succeed, you must remove SMS 2.0 software metering. For more information about removing legacy software metering, see Appendix H: "Appendix H - Upgrading to SMS 2003." |
Error |
Upgrade Strategies
The upgrade strategies you choose directly affect how long an upgrade takes to complete, the effect on your network, and the fundamental structure of your SMS site hierarchy.
Upgrade strategies are divided into two major categories described in this appendix:
In-place hierarchy upgrades
Side-by-side hierarchy upgrades
Because of the complex nature of SMS, most administrators plan to employ a mixture of upgrade strategies and other upgrade scenarios that best fit their needs. For example, some upgrade strategies are better suited for use when you do not want to modify any computer hardware used in your SMS sites. Other strategies are better suited to accommodate computer hardware changes during the upgrade process. As a part of your upgrade plan, reconsider your SMS objectives and determine the effect of the upgrade.
You are not limited to use a single upgrade strategy. Depending on the complexity of your SMS site hierarchy, you can decide to use elements of both in-place and side-by-side upgrade strategies. As the SMS administrator, you are in the best position to determine which upgrade strategy or combinations of strategies are best for your organization. After reading this appendix you will understand the requirements, options, advantages, and disadvantages for each upgrade strategy.
Reconsider SMS Objectives During Upgrade Planning
Carefully examine whether there were significant business changes affecting SMS since your last deployment. For example, the geographical profile of your organization might have changed. Perhaps changes to your site boundaries are required. When planning for your upgrade, determine if other changes to your SMS hierarchy are required. For more information about planning for business objectives, see “Preplanning Phase” earlier in this book, and Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."
Determine the Effect of the Upgrade
Is your existing SMS site hierarchy too large to upgrade overnight? One way to determine if your site is too large to upgrade directly to SMS 2003 is to recall how well the SMS 2.0 SP4 upgrade was achieved. If you had insufficient network bandwidth for upgrade, or if you had numerous difficulties, then use a phased-site upgrade strategy. A phased-site upgrade pertains to a single site only and it prevents all clients in the site from upgrading at the same time. Other sites within the SMS hierarchy are not affected by the phased-site upgrade.
Alternatively, if there were few or no problems with your network when you upgraded your clients to SMS 2.0 SP4, or if network performance degradation was within acceptable limits, then you can perform an overnight upgrade.
You must consider whether computers are shut down at night. If all the computers in your organization are shut down, the computers begin upgrading when they start up. A large number of clients upgrading simultaneously might overload your network. Performing a phased-site upgrade over a weekend prevents users from being negatively affected by the upgrade.
Consider the amount of time needed to upgrade. For example, upgrading a site might take a long time if you have a large SMS site database. To help ensure your upgrade is completed as quickly as possible, fully plan the upgrade and consider the amount of time required for the upgrade to complete as a factor to weigh.
In a test lab, you can use Network Monitor to help determine your expected available network bandwidth. The amount of available network bandwidth is an important factor used to help determine how many clients you can upgrade over a given period of time.
You should test the SMS site database upgrade on a copy of the SMS site database with the /testdbupgrade Setup switch. For example:
Setup.exe /testdbupgrade SMS_<sitecode>
When you successfully run the database upgrade test, then you are assured the database portion of the upgrade process will be successful. You can review the results of the test in SMSsetup.log, which is in the root of the system drive.
Caution
Because the /testdbupgrade Setup switch destroys data, ensure that you use this setup option only on a copy of your SMS site database.
In-Place Hierarchy Upgrades
Most of the upgrade strategies described in this section use a holding site. A holding site is an SMS 2.0 site that holds clients that are not supported by SMS 2003. Clients running Windows 95, that are from other sites in your hierarchy, migrate to the holding site. A holding site is only effective when it manages clients in one geographical location. To establish a holding site, you can continue using an existing SMS 2.0 site, or you can create a new SMS 2.0 site server. The alternative to establishing a holding site is to not manage unsupported clients.
If computers running unsupported operating systems, such as Windows 95, make up the fewest number of client computers, it might be best to conduct an in-place upgrade. An in-place upgrade refers to a site being upgraded with relatively little change to existing hardware.
If you have a deep SMS hierarchy, you can create an SMS 2.0 holding site and migrate the clients running Windows 95 to the holding site. Then upgrade your other sites to SMS 2003 and their clients to your preferred client type. For additional information about deep hierarchies, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."
Overnight Upgrade
This in-place hierarchy upgrade strategy helps you upgrade your entire SMS hierarchy overnight.
By performing an overnight upgrade, your organization can quickly benefit from SMS 2003. With this strategy, you upgrade all of your existing SMS 2.0 clients to the Legacy Client. This requires that you have ample available network bandwidth for the upgrade to complete in 23 hours. To start the overnight upgrade, choose a site to upgrade in the hierarchy to SMS 2003. Within 23 hours, your entire SMS 2.0 site is upgraded.
Alternatively, you might choose to upgrade your site over a weekend if client computers are left on and are connected to the network. In this case you can schedule the site upgrades for a Friday evening. This can prevent heavy network usage from affecting your users and allow ample time for each Client Configuration Installation Manager (CCIM) cycle to fully complete. After all of your clients have upgraded to the Legacy Client, you can determine which clients should be replaced with the Advanced Client.
When an Advanced Client replaces an SMS 2.0 client, the first site the SMS 2.0 client was assigned to is used as the Advanced Client’s assigned site, unless the site code is specified during client installation. When an Advanced Client replaces a Legacy Client, the Legacy Client’s assigned site is used as the Advanced Client’s assigned site, unless the site code is specified during client installation. See “Upgrading SMS Client Software” in Appendix I: "Appendix I - Installing and Configuring SMS Clients" for more information about upgrading clients.
Note
If you have SMS 2.0 clients that cannot upgrade to the SMS 2003 client, you must establish a holding site. Otherwise, you are not able to manage the clients that cannot upgrade.
Performing an overnight upgrade has the following benefits:
An overnight upgrade is the fastest and easiest way to upgrade to SMS 2003.
This strategy simplifies the upgrade process because you can address replacing Legacy Clients with the Advanced Client after the overnight upgrade is completed.
Your organization can start using SMS 2003 without having to first establish Advanced Client infrastructure, such as management points.
You do not have to spend a lot of time performing exhaustive planning before you take action.
This strategy is attractive to you if you have not decided which SMS 2003 client to install on a given computer type.
Phased-Site Upgrade
A phased-site upgrade is an in-place site upgrade strategy that uses the Client Upgrade Control tool to temporarily stop all clients within a site from being upgraded. During this process, batches of clients are upgraded in a controlled manner. As described in other examples, other upgrade mechanisms can be used in conjunction with a phased-site upgrade.
Deciding to conduct a phased-site upgrade should be based on results you find in your lab test or a pilot project. If you are certain that your site infrastructure cannot adequately process all client requests to upgrade in a 23-hour period, then you can perform a phased-site upgrade. This allows you to upgrade your clients in smaller, isolated groups.
Each client upgrade requires approximately 12 MB of network bandwidth. After your site server is upgraded to SMS 2003, the site’s clients start upgrading. Client upgrade is triggered by either a Client Configuration Manager (CCM) cycle, which occurs every 23 hours on each client, or when a client computer logs on to a domain. If your site is small enough, and you estimate that a 12 MB download for each client cannot not overload the site CAPs, then an overnight upgrade might be the best upgrade strategy for you. Otherwise, a phased-site upgrade might be appropriate.
This section provides general information about how to perform a phased-site upgrade. More detailed information about site and client upgrades is provided later in this appendix, and in Chapter 4: “Understanding SMS Clients” in the .
You can perform a phased-site upgrade using one of the following methods:
Use the Client Upgrade Control tool with the /Enable switch.
Use Client Push Installation with collections on clients running Windows 2000 or later to deploy the Advanced Client.
Use software distribution to deploy the Advanced Client.
Using the Client Upgrade Control tool
The Client Upgrade Control tool (Cliupgrade.exe) is used to conduct a phased-site upgrade of SMS 2.0 sites. The Client Upgrade Control tool is included on the SMS 2003 product CD and is found in \SMSSETUP\BIN\I386. Using the Client Upgrade Control tool with this strategy slows the upgrade process, which ensures that you have sufficient time to upgrade your clients.
You can use the Client Upgrade Control tool to help upgrade some or all of your SMS 2.0 clients to the SMS 2003 Advanced Client. If you have a smaller site, you might send the tool through software distribution to disable only the clients that can support the Advanced Client. In this case, you can send the Client Upgrade Control tool with the /Disable switch to client computers running Windows 2000 and later, and then upgrade the SMS site server. If you take no further action, only computers running Windows 98 and Windows NT 4.0 upgrade automatically to the SMS 2003 Legacy Client. Later, by using either software distribution or Client Push Installation, you target computers running Windows 2000 and later to install the Advanced Client.
Note
Using the Client Upgrade Control tool might not be suitable for use with SMS 2.0 dial-up clients in support of suppressing automatic client upgrade, because many dial-up clients might not run the advertisement before your planned upgrade begins. If you use the Client Upgrade Control tool to prevent clients from automatically upgrading, ensure that you allow ample time for all dial-up clients to receive and run the advertisement.
The Client Upgrade Control tool prevents many normal client functions, so timing their upgrade is critical. The tool stops the CCIM cycle from occurring. After you upgrade a site server, you should upgrade its clients as soon as possible. After you run the tool, you cannot upgrade the SMS 2.0 clients to a newer version of SMS 2.0, such as a service pack or a security patch. You cannot change client settings, or change the hardware inventory schedule. Clients affected by the Client Upgrade Control tool that report to an SMS 2003 site do not run software inventory or retrieve collected files. For example, if you realize that a critical security patch must be applied to your SMS 2.0 clients, you cannot deploy the patch until the SMS 2.0 clients receive the /Enable switch.
SMS 2.0 clients that are prevented from upgrading with the tool do not automatically upgrade to the SMS 2003 Legacy Client. To minimize this disadvantage, plan your upgrade strategy thoroughly before you distribute the Client Upgrade Control tool.
Use the following basic procedure as a guideline only. It demonstrates the hierarchy-upgrade process using a phased-site upgrade strategy in the context of a single site. Upgrade your site hierarchy in a top-down manner. You upgrade a site only after its parent site has already been upgraded, starting with the central site.
To upgrade a site, you must use an account that is a member of the local Administrators group on the site server. By default, members of the Domain Admins group are members of the local Administrators group.
To perform a phased-site upgrade
Upgrade the central site server to SMS 2003.
It is unlikely that the central site has enough clients, if any, to warrant a phased-site upgrade. Your site might differ.
Note
The Deployment Readiness tool runs during the upgrade. Logon points must be removed from all the sites in your hierarchy before the upgrade proceeds. For more information, see “Preparing a Site for Upgrade” later in this appendix.
Send the Client Upgrade Control tool to every client in each site to be upgraded using SMS 2.0 software distribution with the /Disable command-line switch to disable clients from upgrading.
Upgrade the first site server to SMS 2003.
Determine the collection that you want to target clients to upgrade. Choosing the collection to advertise to determines how large the set of clients to upgrade is.
Send your chosen collection the Client Upgrade Control tool with the /Enable switch through software distribution. This allows clients to upgrade.
After members of the collection receive the tool with the /Enable switch, they upgrade to the SMS 2003 Legacy Client during their new CCM cycle, or when a user logs on, whichever occurs first.
Verify that an acceptable number of clients have been upgraded, and then send the enabling switch to the next collection. Repeat this step until all the clients in the site have been upgraded.
Repeat this process to upgrade each site in your hierarchy.
Overlapping site boundaries
Overlapping your site boundaries is necessary to ensure that clients running Windows 95 migrate from their original site to a holding site. However, if you overlap the boundaries of too many sites to your holding site, the holding site might not support all the clients. This results in serious site performance degradation.
Note
The process of overlapping site boundaries is used to facilitate client migration only. After all the SMS 2.0 clients finish migrating, you should remove any overlapping site boundaries.
Additionally, if a management point determines that an Advanced Client falls into the boundaries of multiple sites, the management point returns the distribution points of the multiple sites, and the Advanced Client selects one randomly. This might cause the Advanced Client to use a remote distribution point even though a local distribution point is available.
Example Scenario 1
Before beginning a phased-site upgrade, the SMS administrator should determine approximately how many clients the holding site might contain. In this example scenario, there are a variety of client operating systems, including Windows 95, in the SMS site hierarchy. The administrator has decided to upgrade as many sites as he can to SMS 2003. This scenario only works well in a deep hierarchy where all sites are in the same geographical location and they are not connected by wide area networks (WANs).
After reviewing his current hierarchy, the administrator has decided to create a new site, D, to act as the SMS 2.0 holding site. The administrator’s goal is for all clients, running Windows 95 and Windows NT 4.0, to move to the holding site, and then upgrade sites B and C to SMS 2003.
Figure H.1 First example of a phased-site upgrade
.gif "Cc179616.CPIG_010_001c(en-us,TechNet.10).gif")
The administrator wants to upgrade sites B and C while all client computers remain managed. A fast, reliable network connects all sites. One client is running Windows 95 and is a member of site B. The other client runs Windows 2000 and is a member of site C.
To upgrade the computers supported by SMS 2003 and move the others to a holding site, the administrator:
Upgrades central site A to SMS 2003.
Creates the SMS 2.0 holding site D.
Adds the site boundaries for sites B and C to site D. This overlaps the site boundaries and ensures that SMS 2.0 clients that are unsupported by SMS 2003 remain managed during the upgrade process.
Upgrades site servers B and C to SMS 2003. Clients temporarily remain members of their original sites and become members of site D.
The upgrade begins when a client, that is running Windows 95, runs its CCIM cycle, or when a client, that is running Windows 95, runs Logon Script-initiated Client Installation (capinst.exe) from site B during logon. The upgrade process detects that the client operating system is not supported by SMS 2003. The client removes the SMS 2003 site codes from its site code list. The SMS 2.0 holding site’s site code remains in the client site code list. The client is now a member of site D only.
The upgrade begins when the Windows 2000 client runs its CCIM cycle, or when the client runs Logon Script-initiated Client Installation during logon from site C. SMS notifies the client that a newer version of SMS is available and client upgrade begins. Because site C initiated the client upgrade, the client becomes a member of site C. However, the client is a member of more than one site and SMS 2003 supports membership to one site only. Site D is removed from the client’s site membership list automatically. Both clients are now members of only one site each. The administrator waits until all clients have either upgraded or changed site membership before proceeding.
Repeats steps 3 and 4 to upgrade clients for each site in the hierarchy, until all sites have been upgraded.
Maintain the overlapping boundaries until there are no more clients running Windows 95, or until you no longer need to support clients running Windows 95.
Example Scenario 2
The hierarchy is in one geographic location. A fast, reliable network connects all sites. After reviewing his current hierarchy, the administrator has determined that:
One-quarter of his client computers are running Windows 95. These clients reside in various sites within the hierarchy.
The remaining client computers are running Windows NT 4.0 SP6a and Windows 2000. The administrator wants to continue using his existing SMS hardware to manage these clients. He wants to upgrade these clients to the Legacy Client. They reside in various sites within the hierarchy.
Site B is an SMS 2.0 site. The administrator does not plan to upgrade this site, because it will become a holding site.
Site C will be upgraded in-place to SMS 2003.
Figure H.2 Second example of a phased- site upgrade
[This is AltText: Second example of a phased-site upgrade.]
.gif "Cc179616.cpig_10_02c(en-us,TechNet.10).gif")
The administrator:
Upgrades central site A in-place to SMS 2003.
Creates a server locator point at central site A.
Creates site D, a new SMS 2003 transition site.
Creates a management point at site D.
Adds the site boundaries for site C to site B. Site B is not upgraded—it is the SMS 2.0 holding site. This overlaps the site boundaries and ensures that SMS 2.0 clients that are not supported by SMS 2003 remain managed during the upgrade process.
Upgrades site server C to SMS 2003. Clients temporarily remain members of their original site C, and become members of site B.
The upgrade begins when a client, that is running Windows 95, runs its CCIM cycle, or when a client, that is running Windows 95, runs Logon Script-initiated Client Installation from site A during logon. The upgrade process detects that the client operating system is not supported by SMS 2003. The client removes the SMS 2003 site code from its site code list. The upgrade process ends without the client being upgraded. The SMS 2.0 holding site’s site code remains in the client site code list. The client is now a member of site B only.
The upgrade begins when any client, that is running Windows NT 4.0 SP6a or Windows 2000, runs its CCIM cycle, or when the client runs Logon Script-initiated Client Installation from site A during logon. SMS notifies the client to communicate with the CAP at site C. The CAP at site C notifies the client that a newer version of SMS is available. SMS 2.0 clients upgrade to the Legacy Client. Because site C initiated the client upgrade, the client becomes a member of site C. However, the client is a member of more than one site and SMS 2003 supports membership to only one site. Site B is removed from the client’s site membership list automatically.
At each site, use a collection to target and send the Advanced Client Windows Installer package to computers running Windows 2000. SMS 2.0 client software is replaced by the Advanced Client on computers running Windows 2000 and become members of site D.
Removes the site boundaries of sites C from site B when there are no more clients running Windows 95 to manage.
Interoperability during upgrade
You might plan to upgrade only some of your SMS 2.0 sites, to continue to support clients that SMS 2003 does not support. For example, to continue to support clients running Windows 95, you must maintain SMS 2.0 sites within your SMS 2003 site hierarchy until those clients are upgraded.
You must follow these guidelines when planning the upgraded hierarchy:
A parent site must be either the same version as, or one version later than, the child site. For example, an SMS 2003 site can be a parent site of another SMS 2003 site, or of an SMS 2.0 site. You must organize the site hierarchy so that SMS 2003 sites report to other SMS 2003 sites only. SMS 2.0 sites can report to other SMS 2.0 sites or to SMS 2003 sites.
Before starting any site upgrade, apply SP4 or later to SMS 2.0 sites that will share a hierarchy, even temporarily, with SMS 2003 sites.
The order of the upgrade is the same whether you plan to upgrade all the sites or not. To maintain the reporting structure during a phased deployment of SMS 2003, you must upgrade the central site first. Then, upgrade the central site’s immediate child sites. Continue down the hierarchy until you reach the SMS 2.0 sites that you do not want to upgrade.
Side by Side Hierarchy Upgrades
A side-by-side migration occurs when new hardware is used, or when you reconfigure existing computer hardware in conjunction with changes to your SMS site hierarchy or the upgrade process. A side-by-side migration typically requires much more planning to ensure that all clients remain managed during the migration than an in-place upgrade does. Ensure that you and your organization are fully prepared before beginning the migration.
A side-by-side migration offers significant benefits that other upgrade strategies cannot. For example, with a side-by-side migration, you can:
Use new hardware and revise your existing hierarchy.
Continue using existing hardware, if desired.
Limit the number of client types in your sites.
Rearrange sites and clients within the SMS site hierarchy.
Note
Clients do not have to remain members of their original SMS 2.0 sites after they upgrade. For example, if you have two SMS 2.0 sites, one of which is not being fully used, you can migrate its clients to another site then remove the unused site.
Using a Transition Site
If you are considering a side-by-side migration, determine what the client composition of your hierarchy is. If your most demanding SMS users are those who have the most up-to-date computers, but they only consist of 20 percent of your hierarchy, then you probably do not want upgrade your entire hierarchy to SMS 2003 to accommodate only those computers. In this case, you might want to establish a transition site in your existing hierarchy, and then migrate the client computers to the transition site. A transition site is an SMS 2003 site that manages clients that cannot be members of SMS 2.0 sites. In other words, a transition site is an SMS 2003 site that holds only SMS 2003 clients.
To establish a transition site, you can upgrade an existing SMS 2.0 site to SMS 2003, or you can create a new SMS 2003 site server. Using a transition site might ensure that your most demanding users receive the benefits of SMS 2003 quickly. For example, you can deploy Advanced Clients and still keep old SMS 2.0 sites and clients. Because the Advanced Client is more scalable than the Legacy Client, you can have many more Advanced Clients at a single site than Legacy Clients, and you can use multiple management points instead of multiple CAPs to handle the clients. Later, you can use other strategies to upgrade other sites and upgrade or migrate their clients.
Restricting Client Installation
Any site upgrade within an SMS hierarchy might temporarily result in having three different clients:
The SMS 2.0 client
The SMS 2003 Legacy Client
The SMS 2003 Advanced Client
Based on the business needs of your organization, you might decide that you do not want to manage three different client types. In this case, you might purposely avoid migrating your SMS 2.0 clients to one of the SMS 2003 client types.
For example, you might decide that all clients running Windows 2000 or later must run the SMS 2003 Advanced Client. All other client computers must continue to use the SMS 2.0 client. In this case, you avoid upgrading any clients to the Legacy Client and you keep your holding site at SMS 2.0 indefinitely. This scenario is acceptable if it meets your organization’s business goals.
In this example, you continue managing your SMS 2.0 hierarchy and upgrade the central site and one primary site, which becomes a transition site. All other sites remain SMS 2.0 holding sites, temporarily. Then you identify clients from the hierarchy that can run the Advanced Client. You migrate those clients to the SMS 2003 transition site. When the transition site reaches its capacity in terms of adequately supporting all assigned clients, you can create or upgrade another holding site. This allows you to continue migrating more clients, which slowly offloads work from your SMS 2.0 sites while the SMS 2003 sites grow. This strategy ensures that all clients are managed during the upgrade. You can also use the new features of SMS 2003 during your site migration, until the process is complete. When your SMS 2.0 sites are no longer required, you can remove them from your hierarchy.
Deciding When to Upgrade a Flat Hierarchy
If you have a relatively flat SMS hierarchy that contains clients that cannot run SMS 2003, such as computers running Windows 95, you should accelerate plans to upgrade those computers to newer hardware and operating systems that SMS 2003 supports. Because the SMS clients are separated from the primary site by WAN links, you cannot centrally manage the clients using a holding site. After you upgrade or replace the client computer operating systems at a secondary site, you can upgrade the secondary site server to SMS 2003.
Note
A flat hierarchy contains fewer tiers than deep hierarchies and makes the hierarchy easier to configure, administer, and support. SMS needs less time to deploy software to lower level sites and report status back to the top of the hierarchy.
This might or might not be acceptable in your organization. Consider the following:
Proportion of the overall client base to the non-supported clients
Functions within your enterprise of the non-supported clients
Length of time before retiring the non-supported clients
The alternative to upgrading clients to operating systems supported by SMS 2003 is to create a new holding site at every separate geographical location. This avoids having sites with clients on the other side of WAN links. For additional information about flat hierarchies, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."
However, if you are required to maintain some client computers running Windows 95 indefinitely, you cannot upgrade those clients right away. Instead, you should wait to upgrade your SMS client software until you have upgraded your operating system to one supported by SMS 2003. A phased-site upgrade is not practical. Additionally, creating a holding site at each secondary site location can be very expensive. You should to wait to upgrade your hierarchy until you have planned for and received new computers that can run SMS 2003. The limiting factor is that WAN links are typically slow or unreliable, and you cannot schedule network traffic to distribution points with senders.
Upgrading Secondary Sites
When you upgrade a primary site that has secondary sites, the primary site’s roaming boundaries are populated with the site boundaries of its secondary sites. This is because Advanced Clients cannot be members of secondary sites. Later, if you replace the SMS 2.0 client with the Advanced Client at secondary sites, the clients do not become orphaned. Although Advanced Clients cannot be members of secondary sites, they can use proxy management points at secondary sites for most purposes. For more information about roaming boundaries, see Chapter 2: “Understanding SMS Sites” in the . See “Upgrading SMS Client Software” in Appendix I: "Appendix I - Installing and Configuring SMS Clients" for more information about upgrading clients.
Replacing Secondary Sites with Protected Distribution Points
If you have an SMS site hierarchy with few primary and secondary sites, you might consider migrating the hierarchy to a few large primary sites, and eliminating secondary sites. You can do this by replacing secondary sites with protected distribution points.
By removing secondary sites, you lose the ability to control network traffic across a WAN connection between the parent site and secondary sites. If the primary purpose of establishing secondary sites was to control network traffic across a WAN, then you should not remove your secondary sites.
Conversely, your original purpose of establishing secondary sites might be to comply with service level agreements (SLAs) requiring different site settings for SMS components. If you are confident that you can adequately meet SLAs and other SMS objectives without secondary sites to share the workload of the parent primary site, then consider replacing the clients at a secondary site with Advanced Clients assigned to the parent site.
Establishing protected distribution points minimizes network traffic from clients outside of the boundaries configured for the protected distribution points. Advanced Clients within the boundaries configured for a protected distribution point use it to receive software distribution packages.
By removing secondary sites, you remove the burden of managing them, and your primary sites become larger and more complex. For more information about protected distribution points, see Chapter 2: “Understanding SMS Sites” in the .
Note
If a protected distribution point becomes unavailable, Advanced Clients retrieve software distribution packages from other distribution points in the site.
Before removing a secondary site, determine whether it is small enough to warrant removal. You should conduct a network traffic comparison of how much network traffic it generates as a secondary site vs. how much network traffic proposed Advanced Clients might generate. Client network traffic is primarily generated by:
The number and size of software distribution packages.
The frequency of Advanced Client policy updates.
How much inventory is reported.
How much software metering information is sent by the clients.
For more information about capacity planning, see “Site System Planning” earlier in this book, and Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."
In this case you plan to:
Upgrade the parent primary site to SMS 2003.
Replace the SMS 2.0 client with the Advanced Client through software distribution, or with the Client Push Installation Wizard. Through this process, you migrate the secondary site SMS 2.0 clients to the primary site.
Remove the SMS 2.0 secondary sites after all clients have migrated to the parent site.
Establish protected distribution points where the secondary sites used to be.
Replacing Multisite Clients
SMS 2003 clients cannot be assigned to multiple sites. Plan to install the Advanced Client on computers that roam to other SMS sites and when roaming clients require SMS services while visiting sites away from their assigned site. You can use a number of migration strategies detailed later in this appendix to help migrate your SMS 2.0 multisite clients to the Advanced Client.
The Advanced Client uses efficient methods to communicate with the site it is assigned to. The client can also use locally available distribution points to access packages. When distribution points are not local, the Advanced Client’s use of Background Intelligent Transfer Service ensures that package downloads do not adversely affect the user’s use of the computer’s network link.
The SMS 2003 clients’ lack of multisite assignment is beneficial in the following ways:
Consistency with the operating system’s assignment of computers to a single Active Directory site.
Simplified client configuration troubleshooting.
Individual client data is not stored in multiple branches of your SMS hierarchy.
Clients contacting multiple sites do not consume network capacity.
Note
If a multisite SMS 2.0 client upgrades to the SMS 2003 Legacy Client, the client automatically removes all sites from its assigned sites list except for the site that initiates the client upgrade.
If you use multisite assignment for your SMS 2.0 clients, reconsider your procedures in the following circumstances:
Site coexistence
Two sites cannot exist at one location and manage the same clients. You must merge the two sites into one. You can use collection-level security to separate responsibilities, or the SMS administrators at one of the sites must stop managing clients.
Loss of redundancy
If you have clients assigned to multiple sites to ensure that the clients remain managed when one site is not available, you must consider alternative approaches. For example, you can use a parent site to manage clients at a child site. Or, you can refine your backup and recovery procedures to help ensure that if a site fails, it is recovered quickly.
User support from multiple help desks
Personnel at the help desks must revise their procedures when clients are assigned to multiple sites to allow the help desks to use the SMS site database of their local site to find clients and remotely control them or to view client inventory details. The help desks must also revise their procedures when each local site distributes advertisements to the clients. Some alternatives include:
Have each help desk use a remote SMS Administrator console to connect to home site of the users, or to the central site to administer a client.
Change the client site assignment whenever the clients change sites.
Upgrading Clients by Attrition
If you have a small number of client computers running Windows 95, you can replace these clients through a process of attrition. Attrition does not directly upgrade clients. It purposely orphans them. If you consider this approach, you should determine whether the percentage of unsupported clients in your organization is small enough to leave unmanaged by SMS. This strategy is appropriate if the cost of maintaining a mixed-version hierarchy is too great for the small number of unsupported clients.
You should consider this strategy if you decide to replace or upgrade the computers running Windows 95 in a short period of time. The benefit of this approach is that you can upgrade your site and its clients directly to SMS 2003, without maintaining an SMS 2.0 site to manage the clients that are not supported by SMS 2003. When problems occur one of these older computers, you should then replace the computer. This plan also works well if you have already procured replacement client computers. Over time, you replace all your legacy computers with computers that run an SMS 2003 client.
Finalizing Your Upgrade Plan
After you determine which upgrade strategies to employ, you should finalize your upgrade plan. Many of the activities you must consider are similar to those described in “Planning to Deploy SMS 2003.” At a minimum, you should:
Document your upgrade plan.
Create and schedule a backup and recovery plan.
Schedule your upgrade resources.
Schedule the upgrade to occur after hours.
Prepare your users for the upgrade.
Performing Site Upgrades
This section provides task lists to help you organize your upgrade. The task lists are followed by complete step-by-step instructions that guide you through the upgrade process. Specifically, this section describes the following upgrade tasks:
Preparing a site for upgrade
Upgrading primary site servers
Installing SMS components
Upgrading secondary site servers
Note
You can copy the SMS 2003 installation files from the SMS 2003 product CD to a network drive so that you can install SMS from the network.
Preparing a Site for Upgrade
Before you upgrade to SMS 2003, you must perform some preliminary tasks to ensure that the upgrade progresses smoothly. Use the task lists in this section to organize your pre-upgrade efforts.
SMS 2003 Deployment Readiness Wizard
The SMS 2003 Deployment Readiness Wizard is a tool that you must use before you upgrade to SMS 2003. You run the SMS 2003 Deployment Readiness Wizard on any primary site to help ensure that an SMS 2003 upgrade will be successful. The SMS 2003 Deployment Readiness Wizard identifies potential problems at the primary site and its child sites.
Important
You must run the SMS 2003 Deployment Readiness Wizard to proceed with an upgrade. In addition to this requirement, the SMS 2003 Deployment Readiness Wizard must complete without errors.
There are a number of pre-installation checks that you must perform before upgrading an existing SMS 2.0 site to SMS 2003. This tool helps you identify potential problems. For example, the SMS 2003 Deployment Readiness Wizard can check your site for unsupported platforms.
Errors prevent the upgrade from continuing until all the errors are corrected. For more information about the list of the tests that are performed and how to correct the errors, see “Planning a Site Upgrade” earlier in this appendix.
You can run the DRW.exe file from the following folder on the SMS 2003 product CD: SMSSETUP\BIN\I386\. Also, the tool will run automatically when you start SMS 2003 Setup.
To run the SMS 2003 Deployment Readiness Wizard by using DRW.exe
On the Welcome page, click Next.
On the Tests page, select the tests that you want to run, and then click Next.
On the Completing the Systems Management Server 2003 Deployment Readiness Wizard page, click Finish.
The SMS 2003 Deployment Readiness Wizard runs the selected tests. After completion, you can view the detailed test results by selecting the site and clicking Details.
You can also use the setup command-line options to run the SMS 2003 Deployment Readiness Wizard and for software distribution scenarios. The following table represents examples of entries that you might type at the command line.
Table H.5 SMS 2003 Deployment Readiness Wizard Command-Line Options
Entry |
Option |
Description |
|---|---|---|
/?/h |
Help mode |
Defines the supported command-line options. No tests will be performed. Any additional specified command-line options are ignored. |
/q |
Quiet mode |
Runs the tool without displaying the progress and results summary. If you do not specify any other command-line option, the tool runs the primary site option. |
/p |
Primary site |
Runs the tool on the primary site. You cannot run the tool on any secondary sites when you select this option. |
/s |
All secondary sites |
Runs the Deployment Readiness Wizard on all the secondary sites. |
/s:### |
Specific secondary sites |
Runs the Deployment Readiness Wizard on the specified secondary sites. The ### characters represent the three-letter site code of the secondary site. You can specify multiple secondary sites by using a space as a separator between the secondary site codes. |
/r:<path>\logs |
Copy report to specified drive location |
Copies the report file to the specified drive location. Path represents the drive and folder where the reports are saved. The drive folder must exist, and the Deployment Readiness Wizard must have permission to copy files to it. |
/r:\\<computer name>\<share>\logs |
Copy report to specified network location |
Copies the report file to the specified network location. The network folder must exist and the Deployment Readiness Wizard must have permission to copy files to it. In addition, the directory must already be shared. |
/t:<number of hours> |
SQL query timeout set to specific value |
Extends the timeout for SQL query tests. The default timeout is three hours. Even if a test times out, the Deployment Readiness Wizard continues running the rest of the selected tests. When all tests are complete, you can increase the timeout value and then rerun any tests that timed out. A value of 0 sets the SQL query to never time out. |
All Sites Task List
These site preparation tasks apply to all of your SMS 2.0 sites:
Plan your upgrade.
The concept and planning processes described in this book focus on gathering information and making choices. “Planning a Site Upgrade,” focuses on gathering information and making choices for upgrading to SMS 2003. You use the results of your documentation and decision-making efforts (clearly defined high-level goals, hardware and software requirements, the site hierarchy structure, and site system roles) to supply the answers to questions that arise during upgrade.
Ensure that your existing site is running SMS 2.0 SP4 or later.
If the site that is being upgraded is running SMS 2.0 SP3 or earlier, the upgrade will not complete successfully. Also, all SMS 2.0 sites that report directly to the upgraded site must be running SMS 2.0 SP4 or later before the parent site is upgraded to SMS 2003, even if you intend to upgrade the child and secondary sites.
Ensure that your existing site server supports SMS 2003.
Before you upgrade to SMS 2003, ensure that your site server meets the minimum system requirements for the primary or secondary site that you plan to install. If the site server does not meet the system requirements, the upgrade might fail. For more information about system requirements and supported platforms, see the “Getting Started” chapter in the .
Adjust the number of SMS licenses on the site server.
To add additional SMS 2003 licenses when they are required, on the site server, navigate to:
Start └Program menu └Administrative Tools └Licensing
Primary Sites Task List
Use this task list to prepare your primary sites for the upgrade:
- Ensure that your installation of SQL Server supports SMS 2003.
Check the version number of the installation of SQL Server you are using for the SMS site database. SMS 2003 supports SQL Server 7.0 SP3 or later. If you have an earlier version of SQL Server, you must upgrade SQL Server before you upgrade to SMS 2003. Otherwise, the upgrade will fail. For more information about system requirements and supported platforms, see the “Getting Started” chapter in the . SMS 2003 does not support clustered SQL servers.
Test the SMS 2.0 site database.
It is recommended that you use setup /testdbupgrade on a copy of your database to verify that the database portion of the upgrade will be successful. This procedure should be performed only on a copy of your SMS 2.0 database.
To test the SMS 2.0 site database by using /testdbupgrade
Back up your SMS site database.
Obtain a copy of the SMS site database backup created by a recent SMS backup task.
An alternative method is to stop all SMS services on the SMS site server and SQL Server, then use SQL Server Enterprise Manager to make a backup of the SMS site database.
Note
Setup /testdbupgrade fails on SMS site databases that are restored from an SMS 2003 site database with SQL Server database replication enabled.
When SQL Server database replication is enabled for the SMS 2003 site database, the computer running SQL Server modifies the SQL tables that are included in the publication. When the database is restored to another database, the setup /testdbupgrade fails on that restored SMS site database.
To work around this situation, disable publishing on the SMS site database before you back up the SMS site database.
Note
You do not need to install an SMS site on this server.
On the restored SQL Server database, type the following at the command prompt: setup.exe /testdbupgrade < database name >.
If you successfully run the database upgrade test, the database portion of the upgrade process on your actual SMS site database will also be successful. Any problems encountered by the test upgrade must be corrected before upgrading your production site. You can review the results of the test in SMSsetup.log, which is in the root of the system drive.
Caution
Because the /testdbupgrade setup option destroys data, ensure that you use this setup option only on a copy of your SMS site database.
Set the required SMS site database free disk space.
If you do not have enough free disk space on the SMS site database, then the upgrade might fail. This free space is used temporarily during the upgrade process. For more information about calculating the required SMS site database free disk space, see “Planning a Site Upgrade.”
If the unused space in the SMS site database log is larger than the Software Inventory table, then you have sufficient space to ensure a smooth database upgrade. After the upgrade, you can compact the SMS site database and adjust the SMS site database log to their former sizes.
If the Software Inventory table is larger than the unused space in the SMS site database log, you should increase the log size.
To specify how the file should grow, see the SQL Server Help. You can access the SQL Server Help within the SQL Server Enterprise Manager console. You can select from the following options:
To allow the currently selected file to grow as more data space is needed, select Automatically grow file.
To specify that the file should grow by fixed increments, select In megabytes and specify a value.
To specify that the file should grow by a percentage of the current file size, select By percent and specify a value.
Note
The maximum database size is determined by the amount of disk space available and the licensing limits determined by the version of SQL Server you are using.
Perform routine maintenance on your SMS site database.
Before and after any major database operations, such as upgrading your database to SMS 2003, it is important to perform database consistency checks and other database management tasks. These tasks should include backing up the SMS site databases. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.
Uninstall logon points.
Logon points are not supported in SMS 2003. Before upgrading to SMS 2003, you must turn off logon discovery and logon installation and remove logon points from all domain controllers. This process takes time and involves replication between all domain controllers in the domains managed by SMS. Do not immediately proceed with the upgrade process after you turn off logon installation. If you do, clients that are not supported by SMS 2003 might get failed installations of SMS 2003.
Note
All logon points must be removed from all domain controllers. Shared logon points must be removed and the folders must be deleted. To ensure that you are ready to proceed, check the logon scripts and ensure that Smsls.bat is not present. Ensure that the logon points are uninstalled by manually checking each domain controller in the SMS 2.0 site uses to see that the Smslogon directory is removed (or the SMS 2.0 site code under smslogon\sites if the logon points are shared by more than one site).
Remove Crystal Reports.
When you upgrade a primary site server from SMS 2.0 to SMS 2003, the following conditions apply:
You cannot use Report Viewer to view reports that were created with Crystal Reports included in SMS 2.0.
You cannot use Report Viewer to access an SMS 2.0 site database.
SMS 2003 does not upgrade or remove Crystal Reports.
When you upgrade a primary site from SMS 2.0 to SMS 2003, you should continue to use Crystal Reports for SMS 2.0 if:
You want to continue using the stand-alone version of Crystal Reports to view the reports that you created using Crystal Reports for SMS 2.0.
You want to access Crystal Reports on SMS 2.0 sites in your hierarchy.
For more information about SMS 2003 reporting, see Chapter 11, “Creating Reports,” in the Microsoft Systems Management Server 2003 Operations Guide.
To remove Crystal Reports for SMS 2.0
In Control Panel on the primary site server, open Add or Remove Programs.
In the Currently installed programs list, click Seagate Crystal Info for SMS, and then click Change or Remove Programs.
On the primary site server, navigate to the following path:
\SMS\CInfo\
Delete all folders and files under this directory.
To remove other SMS 2.0 software metering settings
Delete the SWMAccount user account if there are no other sites using it.
Open ODBC Data Source Administrator, click the System DSN tab, select the LicAdmin and License Server Local DSN entries, if present, and then click Remove.
Delete the \SWMtr and \SMS\Licmtr directories from your site server, if present.
Remove the license metering database from SQL Server.
Disable the Software Metering Client Agent on all sites.
Note
You cannot restore an SMS 2.0 backup snapshot to an SMS 2003 site. Use the SMS 2.0 backup snapshot only if the upgrade failed.
Customized files are overwritten during an upgrade. However, you can export your SMS_def.mof files for use in SMS 2003.
Table H.6 Custom Files to Back Up in Preparation for a Primary Site Upgrade
File |
Folder |
|---|---|
Backup control file |
\<SMS Folder>\inboxes\smsbkup.box\smsbkup.ctl |
Site control file |
\<SMSFolder>\inboxes\Sitectrl.box\sitectrl.ct0 |
SMS.def.mof |
\<SMS Folder>\inboxes\clifiles.src\hinv |
For more information about backup and recovery in SMS 2.0, see Chapter 18, “Maintaining SMS Systems,” in the Microsoft Systems Management Server 2.0 Administrator’s Guide.
Upgrading Primary Site Servers
After you complete the tasks in the primary site task list, upgrade your primary site.
To upgrade a primary site
Log on to the primary site server that you are upgrading. Use an account that is a member of the local Administrators group on that computer. By default, members of the Domain Administrators group are members of the local Administrators group.
Insert the SMS 2003 product CD into the drive, or connect to a copy of the installation files on a network drive.
On the Welcome page of the SMS Setup Wizard, click Next.
Setup detects your SMS 2.0 installation and offers to upgrade it. Click Next.
On the Setup Options page, select Upgrade an existing SMS installation, and then click Next.
The Licensing window appears. After reading the license and accepting its terms, select I Agree, and then click Next.
If you are using a computer other than the site server for your SMS site database, the SMS Provider Information page appears. If your SMS site database is on a different computer from the site server, you can install the SMS Provider on either computer.
If only a few SMS Administrator consoles access the SMS site database, and you have a computer running SQL Server that shares the SMS site database, then install the SMS Provider on the site server.
If a large number of SMS Administrator consoles access the SMS site database, then install the SMS Provider on the computer running SQL Server.
Select the location where you want to install SMS Provider, and then click Next.
On the Completing the Systems Management Server Setup Wizard page, click Finish.
Caution
If the site you are upgrading has parent sites that have not been upgraded to SMS 2003, and you want the site to continue reporting to those parent sites, cancel the upgrade before clicking Finish and upgrade the parent sites.
Choosing Cancel during a site upgrade does not undo the upgrade. The SMS 2.0 site you are upgrading will not be left intact if you choose to cancel during the site upgrade.
- When a message appears indicating that SMS is upgraded, click OK.
After the upgrade is complete, SMS 2003 uses the upgraded data to configure your upgraded site. This process, which can take 30 minutes or more, is indicated by increased activity in the SMS Executive service. You can monitor this activity with the Windows Task Manager.
The upgrade process converts only the components that were installed in the SMS 2.0 site. You must modify the site to install components that are new to SMS 2003 or that were not installed on the SMS 2.0 site you upgraded.
Note
SMS 2003 software metering is installed, but not enabled, regardless of whether it was installed in SMS 2.0 prior to the upgrade. It is not considered an additional component.
You might want to view the upgraded data before you install new SMS 2003 components or any other components that were not installed on your SMS 2.0 site. To do this, you must wait until the initial configuration activity is complete.
Installing SMS Components
The upgrade process converts only the components already installed in the SMS 2.0 site. With the exception of software metering, components that were not installed on the original site are not installed during the upgrade.
To install components on your upgraded site that were not installed before the upgrade, run SMS Setup again from the product CD and select the options you want to modify in the existing installation.
To modify a newly upgraded primary site
Log on to the primary site server that you are upgrading. Use an account that belongs to the local Administrators group.
Insert the product CD into the drive, or connect to a copy of the installation files on a network drive.
On the Welcome screen, click Next.
Setup detects your SMS 2003 installation. To view your setup options, click Next.
On the Setup Options page, select Modify or reset the current installation, and then click Next.
On the Setup Installation Options page, select the components that you want to install, and then click Next.
On the next three pages, you can make changes to your SQL Server database. The default settings are the settings used for your SMS 2.0 site before the upgrade. On each of the following pages, accept the defaults, and then click Next:
SMS Service Account Information
SQL Server Database or Name Modification
Windows Authentication previously known as Integrated Security for SMS Database
On the confirmation page, click Finish.
After SMS Setup installs the components on your site, a message appears indicating that the setup was successful.
Note Setup writes the settings to the SMSsetup.log file, which is located at the root of your system drive. You can view this log file at any time.
Upgrading Secondary Site Servers
When a parent site is upgraded, its secondary sites are not automatically upgraded. This makes it easy for you to maintain SMS 2.0 secondary sites in your hierarchy to support clients running operating systems that are not supported by SMS 2003.
In some ways, upgrading a secondary site is easier than upgrading a primary site because a secondary site has no SMS site database.
Note
Status information from the secondary site that you upgrade does not include information about the progress of the upgrade. After the upgrade is complete, the parent site receives a site control file from the secondary site. This updates the version information of the secondary site in the primary SMS site database and SMS Administrator console.
Secondary Site Upgrade Methods
You can use one of the procedures described in this section to upgrade your secondary site. There are three secondary site upgrade methods:
Download the upgrade from the parent site
Use this method when the secondary site does not have an administrator who can perform the upgrade and when the effect on intersite network bandwidth is not a concern. You can upgrade up to five secondary sites at one time.
To download the upgrade from a parent site, see the “Upgrading a Secondary Site from the Parent Site” section later in this appendix.
Initiate the upgrade from the parent site using source files located at the secondary site
Use this method when you want to control the upgrade from the primary site, but want to minimize the effect on intersite network bandwidth. To start the upgrade from the parent site, see the “Upgrading a Secondary Site from the Parent Site” section later in this appendix.
Upgrade locally at the secondary site server by using the SMS 2003 product CD
Use this method when the secondary site has an administrator who can perform the upgrade or when the effect on intersite network bandwidth is a concern. To perform the upgrade locally at the secondary site server, see the “Upgrading a Secondary Site Locally” section later in this appendix.
Note
After you run the Secondary Site Upgrade Wizard at the primary site, the secondary site’s properties appear in the details pane when its parent site is selected in the console tree. However, the secondary site’s properties do not appear under the parent site in the console tree until the primary site receives the site control file from the upgraded secondary site. This can take up to 24 hours.
Upgrading a Secondary Site from the Parent Site
This section describes how to use the Upgrade Secondary Site Wizard to initiate an upgrade from the parent SMS 2003 site.
To upgrade a secondary site from the parent site
- At the parent site, open the SMS Administrator console and navigate to the parent site:
Systems Management Server └Site Database <site code - site name> └Site Hierarchy └<site code - site name>
Right-click the site name in the console tree, click Task, and then click Upgrade Secondary Sites.
On the Welcome page, click Next.
On the Select Sites page, select the secondary sites that you want to upgrade, and then click Next. You can upgrade up to five secondary sites at a time.
On the Installation Source Files page, specify either that installation files are to be downloaded from the primary site server or that the files are already on the secondary site server. Click Next.
If you specify that the files are located on the secondary site server, the product CD must be inserted into the drive on the site server. Alternatively, you can use an image of the SMS 2003 product CD on the local disk or removable media or on a mapped network connection at the secondary site server.
On the Complete the Upgrade Secondary Site Wizard page, click Finish.
If an upgrade stops responding, ensure that the system requirements are met at the secondary site and that the installation source files are accessible. Then, initiate the upgrade again.
Upgrading a Secondary Site Locally
This section describes how to use the Setup program on the SMS 2003 product CD to upgrade a secondary site at the secondary site server.
To upgrade a secondary site server from the SMS 2003 product CD
Log on to the secondary site server that you are upgrading by using an account that is a member of the local Administrators group on that computer. By default, members of the Domain Administrators group are members of the local Administrators group on computers in the domain.
Insert the product CD into the drive. Or, you can connect to an image of the SMS 2003 product CD on a mapped network drive, a hard disk drive, or a removable drive of the secondary site.
On the Welcome page, click Next.
On the System Configuration page, click Next.
On the Setup Options page, select Upgrade an existing SMS installation, and then click Next.
On the Completing the Systems Management Server Setup Wizard page, click Finish. Setup removes SMS 2.0 components from all site systems and installs SMS 2003 on the site server.
When the message appears that SMS is installed, click OK.
Because the upgrade process only converts components that you were using in your SMS 2.0 site, you must modify the site to install components that are new in SMS 2003. The procedure is essentially the same as the procedure for modifying a newly converted primary site. For more information, see the “Installing SMS Components” section earlier in this appendix.
Performing Post-Upgrade Tasks
After you upgrade a site, you must perform several additional tasks. You perform most of them from the SMS Administrator console. These tasks include:
Upgrade Legacy Client to Advanced Client on computers running Windows 2000 or later operating systems
When you upgrade the SMS 2.0 site to SMS 2003, the Legacy Client is installed on existing SMS 2.0 clients running Windows 2000 or later primarily to assist with your migration of these clients to the Advanced Client rather than as a long-term enterprise solution. It is strongly recommended that you install the Advanced Client as soon as possible after the upgrade is complete so as to take advantage of the enhanced security and other benefits provided by the Advanced Client on these platforms.
If you have installed the Legacy Client on a computer running the Windows 98 or Windows NT 4.0 operating system, and you upgrade those computers to the Windows 2000 or later operating system, the Legacy Client agent is removed from the client as part of the upgrade process. It is recommended that you install the Advanced Client on that computer after you upgrade the operatings system to Windows 2000 or later.
Status filter rules after upgrading the site server to Windows Server 2003
If you have configured status filter rules to send a network message when an event occurs, and you upgrade the site server to Windows Server 2003, the status filter rules will no longer run. By default, the messenger service in Windows Server 2003 is disabled. To allow these status filter rules to run, enable and start the Messenger service.
Database maintenance and consistency checks
It is a good idea to back up your upgraded site and to perform database consistency checks. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.
This is a good time to schedule the backup task. For more information about backup and recovery, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.
Differences between the SMS_def.mof files at different sites running the same version of SMS in the hierarchy can lead to conflicting hardware inventory data. To prevent conflicts, you should make sure that each site running the same version of SMS in the hierarchy uses the same hardware inventory definitions.
For more information about how to standardize the SMS_def.mof files in your hierarchy, see Chapter 6: “Understanding Interoperability with SMS 2.0” in the .
For more information about how to restore your customized SMS_def.mof files after you upgrade, see Chapter 2: “Collecting Hardware and Software Inventory,” in the Microsoft Systems Management Server 2003 Operations Guide.
Site configuration
You must configure the site settings for all new SMS 2003 sites. This applies to newly installed SMS 2003 sites and to sites upgraded to SMS 2003 from SMS 2.0. Configuration settings from SMS 2.0 are preserved during an upgrade. For example, you must configure the site boundaries and enable client installation methods to upgrade clients and populate the SMS site database.
In general, perform post-upgrade tasks in the following order:
Configure all site settings.
Assign new site system roles.
Specify the IP subnets or Active Directory sites that define your site boundaries.
Enable resource discovery methods.
For more information about configuring your SMS 2003 sites, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy," and Appendix G: "Appendix G - Deploying and Configuring SMS Sites."
- Enable client installation methods. For more information about client installation methods, see Appendix I: “Discovering Resources and Deploying Clients.”
Enable logging and increase log file size
By default, SMS component logging is enabled and the log file size is set to 2.5 MB on new installations of SMS 2003. However, when you upgrade from SMS 2.0, the upgrade retains whatever log settings you might have enabled. If you did not enable SMS component logging for your SMS 2.0 site, logging will not be enabled after the upgrade completes. Use the SMS Service Manager tool in the SMS Administrator console to enable logging for SMS components, and to increase the log file sizes to 2.5 MB to be consistent with new installations of SMS 2003.
Set the Exclude Encrypted/Compressed option to True
The Exclude Encrypted/Compressed option in SMS 2003 can be used to avoid CPU-intensive software inventory scans of compressed and encrypted files/folders on client computers. By default, this value is set to TRUE for a new installation of SMS 2003.
When SMS 2.0 sites are being upgraded, the existing software inventory rules are migrated to SMS 2003 and to maintain parity with SMS 2.0 software inventory data, the Exclude Encrypted/Compressed option is set to FALSE for each rule. When this option is set to FALSE, compressed and encrypted files are inventoried. This increases the size of software inventory report files, which are generated on the upgraded clients and causes software inventory processing backlogs on the site server.
After the site is upgraded from SMS 2.0 to SMS 2003, if you are not interested in inventory of encrypted/compressed files, you must manually set the Exclude Encrypted/Compressed option to TRUE for each software inventory rule/query as follows:
Open the SMS Administrator console.
Navigate to Site Settings, Client Agents, and then double-click Software Inventory Client Agent.
Navigate to the Inventory Collection tab and double-click each of the software inventory rules/queries.
For each rule/query, enable the Exclude encrypted and compressed files option.
Save the new setting.
This prevents the compressed/encrypted files from being inventoried and helps reduce the size of the software inventory report significantly.
Process audit status messages
After upgrading an SMS 2.0 site, which has a remote SMS site database server and a remote SMS Provider, to SMS 2003, audit status messages might not be processed. The unprocessed messages are held in the %Windir%\system32\smsmsgs\winmgmt\<sitecode> folder.
If you determine that there is a build up of status messages in that folder, you can process those status messages by stopping and restarting the WMI service on the SMS site database server.
Software Update Management
SMS 2003 includes a software update management feature. Some components of this feature are automatically installed with SMS 2003. Other components require a Web download and separate installation on the site server. See Table H.7 for component installation information.
Earlier versions of the software update management components were released as value-added features in the SMS 2.0 Software Update Services Feature Pack. For information about upgrading SMS 2.0 sites that have the software update management tools previously installed, see the “Upgrading SMS 2.0 Software Update Management Features to SMS 2003” section later in this appendix.
For system requirements, see the “Getting Started” chapter in the .
For information about interoperability issues in a mixed-site hierarchy, see Chapter 6, “Understanding Interoperability with SMS 2.0” in the .
Installation
Table H.7 shows the components and installation details of the SMS 2003 software update management feature.
Table H.7 Software Update Tool Installation Details
Feature |
Installation Details |
|---|---|
Distribute Software Updates Wizard |
Installed by default on the SMS 2003 site server and SMS 2003 Administrator console. |
Software updates installation agent |
Installed by default on the SMS 2003 site server. Distributed to SMS client computers automatically when you run the Distribute Software Updates Wizard to create and advertise software update packages. |
Software update reports |
Installed by default on SMS 2003 reporting points and the SMS 2003 Administrator console. |
Security Update Inventory tool |
Download from the Web at https://www.microsoft.com/smserver/downloads. Separate installation on an SMS site server. |
Microsoft Office Inventory tool for updates |
Download from the Web at https://www.microsoft.com/smserver/downloads. Separate installation on an SMS site server. |
Upgrading SMS 2.0 Software Update Management Features to SMS 2003
Table H.8 lists the actions that are required for upgrading an SMS 2.0 site to SMS 2003 when the SMS 2.0 versions of the SUS Feature Pack tools are already installed.
Table H.8 Software Update Tool Upgrade Requirements
Use the following procedure to upgrade the SMS 2.0 version of the Security Update Inventory tool to the SMS 2003 version.
Important
The following procedure upgrades the Security Update Inventory tool and its associated collections, packages, programs, and advertisements to SMS 2003 versions. Although it does not remove these objects from the SMS site database, the upgrade process replaces any custom properties you set on these objects with the default values. If you have made such changes and want to preserve them, make a note of the configuration settings for these objects before you perform this upgrade.
To upgrade the SMS 2.0 Security Update Inventory tool to the SMS 2003 version
On an SMS 2003 site server, download the installation program for the tool from https://www.microsoft.com/smserver/downloads.
Run the installation program (SecurityPatch_xxx.exe, where xxx is the locale code of the package; for example, SecurityPath_ENU.exe for the English language version).
When prompted to remove the previous version, click OK.
When prompted to remove packages, collections, and advertisements, click No.
When prompted to replace the existing package, collections, and advertisements during the installation of the new version, click OK.
Following setup, review the configuration settings for the collections, packages, programs, and advertisements for the tool. If necessary, replace the default settings with the custom settings appropriate for your site.
This procedure describes the process of upgrading the Security Update Inventory tool. To upgrade the Microsoft Office Inventory tool for updates, follow the same steps, but substitute the file name OfficePatch_xxx.exe for SecurityPatch_xxx.exe.
Other Issues Affecting an Upgrade
The following are other points to consider when performing an upgrade of the SMS 2.0 version of the software update management tools:
SMS 2.0 software update packages created by the Distribute Software Updates Wizard are only upgraded to SMS 2003 packages when they are opened and saved in the SMS 2003 version of the Distribute Software Updates Wizard. For more information, see the “Software Update Management” section in Chapter 6: “Understanding Interoperability with SMS 2.0” in the
The SMS 2.0 Administration Feature Pack tools are not compatible with SMS 2003. You should remove these tools prior to an upgrade of the SMS 2.0 Administrator console to SMS 2003. Compatible versions of these tools will be available for SMS 2003, but are not included in this release.