Service Pack 2 Installation Release Notes
Updated : August 4, 2000
These release notes contain information about Microsoft Systems Management Server (SMS) version 2.0 Service Pack 2 (SP2) that you need to have to successfully install SP2. This information is not available in the product documentation. Please read these release notes thoroughly before installing the SMS software. Additional release notes, documenting issues that do not affect SP2 installation, are available on the SMS 2.0 SP2 compact disc, in the file Readme_Operations.htm.
To search these Release Notes, press CTRL+F.
The compact disc that includes this readme file contains SMS 2.0 with all of the Service Pack 2 fixes incorporated. Throughout this document it will be referred to as the "SMS 2.0 SP2 compact disc."
Before you install or upgrade, be sure to check whether you need to apply the updates described in the Required Updates section of this document.
.gif "note-icon")
Warning: You might need to apply these updates to all your sites sharing site systems before installing or upgrading to SMS 2.0 SP2. If you do not apply these updates, SMS clients might not function properly because different versions of client components won't be able to communicate with each other. In addition, clients will not be able to complete the SMS 2.0 SP2 upgrade process, and they will be in an unmanageable state. If that happens, you will have to visit each SMS client desktop to correct this condition.
Warning: If you plan to upgrade from SMS 1.2 to SMS 2.0 and also upgrade from Microsoft SQL Server™ 6.5 to SQL Server 7.0, read DO NOT Upgrade to SQL Server 7.0… later in these release notes.
If you have comments or suggestions about SMS 2.0, please send them to smswish@microsoft.com. We value your feedback.
On This Page
Problems Addressed by This Service Pack
Required Updates
System Requirements
Upgrading
Upgrading Secondary Sites
Installation: Server
Installation: SMS Client
SQL Server
Interoperability with SMS 1.2
Site Configuration and Maintenance
Security
Site Backup and Recovery
Using SMS With Windows 2000
Internationalization
Printed and Online Documentation
HealthMon
Problems Addressed by This Service Pack
For the most recent information about the problems addressed by SMS 2.0 SP2, see the Microsoft Knowledge Base article Q258682, "SMS: List of Bugs Fixed in Systems Management Server 2.0 Service Pack 2."
The following sections provide information on known issues with this service pack.
Required Updates
The updates described in this section are available on the SMS 2.0 SP2 compact disc, in the \SMSQFE directory.
Apply Updates Before Upgrading to SMS 2.0 SP2
This release note applies if, even briefly, your hierarchy will include both SMS 2.0 SP2 sites and sites running previous versions of SMS 2.0. In this case you must apply certain updates to all your existing SMS 2.0 sites (with or without SP1) before you add any SMS 2.0 SP2 sites to your site hierarchy. The updates you need to apply depend on whether the site requiring the update is running SMS 2.0 or SMS 2.0 with SP1.
SMS 2.0 without Service Pack 1 (Build 1239)
If the existing site is running SMS 2.0 without SP1 (Build 1239), apply the updates described in the following Microsoft Knowledge Base articles:
Q251070, SMS: Copylog.tcf Does Not Reflect Site Which Site Last Updated the Logon Point
Q252718, SMS: CCM Avoids Installation Attempts on SP2 Clients
SMS 2.0 with Service Pack 1 (Build 1380)
If the existing site is running SMS 2.0 with SP1 (Build 1380), apply the updates described in the following Microsoft Knowledge Base articles:
Q249077, SMS: SP1: Copylog.tcf Does Not Reflect Which Site Last Updated the Logon Point
Q252717, SMS: SP1: CCM Avoids Installation Attempts on SP2 Clients
Note: The installation files for the updates described in the articles are located in the \SMSQFE directory on the SMS 2.0 SP2 compact disc.
System Requirements
Calculating Required SMS Site Database Free Space
The free space in the SMS site database might need to be increased to avoid an upgrade failure. This free space is used temporarily during the upgrade process. After the upgrade finishes, there should be approximately as much free space available as before the upgrade started. However, if there is not enough free space on the SMS site database, the upgrade will fail.
An SMS site database index might become corrupted if the upgrade fails because of insufficient SMS site database free space.
If the upgrade has failed due to insufficient free space, the error "Can't allocate space for object '<object name>'" appears in \MSSQL\LOG\ERRORLOG and the error "FAILED Sql Script: Creating indexes on <object name>" appears in SMSsetup.log.
WORKAROUND: The query you use and the terminology vary slightly according to the version of SQL Server that you are using. (Note that expanding the transaction log does not provide additional space for data.)
If you are using SQL Server 7.0:
Select the SMS site database.
Run the following query to calculate the amount of space required in the SMS site database primary file:
select 8.0*max(reserved)/1024.0 from sysindexes where indid in (0,1)The query result is in MB of required free space. Add 5 MB to the resulting number and use SQL Server Enterprise Manager to expand the SMS site database primary file to ensure it has at least this much space.
If you are using SQL Server 6.5:
Select the SMS site database.
Run the following query to calculate the amount of space required in the SMS site database data device:
select 2.0*max(reserved)/1024.0 from sysindexes where indid in (0,1)The query result is in MB of required free space. Add 5 MB to the resulting number and use SQL Server Enterprise Manager to expand the SMS site database data device to ensure it has at least this much space.
If the upgrade has failed because of insufficient SMS site database free space:
Expand the database as described earlier for the version of SQL Server that you are using.
Run upgrade again.
SMS Setup will fix any index corruption that occurred when a previous upgrade failed.
Note: If upgrade fails while upgrading the database, the upgrade will probably need to be run a third time. See Site Services not Running after Successful SMS 2.0 SP2 Upgrade for additional information.
Upgrading
DO NOT Upgrade to SQL Server 7.0 Before You Upgrade to SMS 2.0: Printed Documentation Error
Chapter 5, "Upgrading from SMS 1.2 to SMS 2.0" and Chapter 6, "Installing SMS 2.0 Sites" in the SMS 2.0 Administrator's Guide both advise you to upgrade to SQL Server 7.0 before you upgrade to SMS 2.0. This is incorrect.
WORKAROUND: To successfully upgrade SMS 1.2 to SMS 2.0 and SQL Server 6.5 to SQL Server 7.0, do the following:
See the Microsoft Knowledge Base Article Q196824 for the most recent information about upgrading SMS.
As a safety precaution, configure and enable the automated "backup SMS site server" task from the SMS Administrator console. Then start the SMS_SITE_BACKUP service.
Apply Microsoft Windows NT®4.0 SP4 (or later).
Apply SMS SP4 to SMS 1.2 if you have not done so already.
Apply SQL SP4 (or later) to SQL Server version 6.5 if you have not done so already.
Upgrade SMS 1.2 SP4 to SMS 2.0.
Upgrade SQL Server 6.5 to SQL Server 7.0.
Finally, run the SQL Server Upgrade Wizard included with SQL Server 7.0 Setup to upgrade your SMS site database to SQL Server 7.0.
You can now use SMS 2.0 with your converted database.
SMS Hierarchy Upgrade Order
SMS upgrades must be performed in the correct order to avoid compatibility problems.
WORKAROUND: To upgrade your SMS hierarchy, do the following:
Upgrade the hierarchy, from the central site down to the bottom tier.
If logon points are shared between sites, it is recommended that you upgrade the senior site before upgrading the other sites that are sharing the logon points. (To identify the senior site see Knowledge Base article Q235726 from Microsoft Product Support Services.)
If the SMS Provider is shared among sites, when the first of those sites is upgraded, select the option to also upgrade the SMS Provider. When additional SMS sites are upgraded with the same version of SMS, do not upgrade the SMS Provider. For more information, see Upgrading Shared SMS Providers
Upgrade the SMS site before upgrading the SMS Administrator console on computers other than the site server.
Supporting SMS 1.2 and SMS 2.0 Using the Same Logon Servers
Upgrading SMS overwrites an existing NT_Logon.pcf file on your SMS site server. Support for SMS 1.2 and SMS 2.0 scripts on the same logon server is lost.
WORKAROUND: To restore support for SMS 1.2 and SMS 2.0 scripts on the same logon server after upgrade, see the Help topic, "SMS 1.2 and SMS 2.0 Using the Same Logon Servers," in the on-line version of the System Management Server Administrator's Guide.
Backup Custom Hardware Inventory Information Settings Before Upgrading SMS
Upgrading SMS overwrites any custom SMS_Def.mof you might have created to collect custom inventory items.
WORKAROUND: Before you upgrade your site, backup the SMS_Def.mof file from your site under SMS\Inboxes\Clifiles.src\Hinv, then replace it after performing the upgrade.
Upgrading Shared SMS Providers
If the SMS Provider on the computer running SQL Server is used by more than one site, then when you upgrade the site server to SMS 2.0 SP2 a dialog box appears giving you the option to upgrade the SMS Provider to SMS 2.0 SP2.
WORKAROUND: If no other site has upgraded the shared SMS Provider, upgrade it when you upgrade the site.
To determine whether SMS Provider has been upgraded, use Windows NT Explorer on the computer where the SMS site database resides to search for the file SMSprov.dll. Right-click the file and choose Properties. On the Version tab, the file version ends in 1444.2000 or greater if the SMS Provider has been upgraded.
Note: Upgrading the SMS Provider disconnects all current SMS Administrator console sessions on all sites that use that SMS Provider, as well as other applications using Windows Management Instrumentation (WMI) from the SMS Provider. Therefore, the SMS Provider should be upgraded only once.
SMS 1.2 Secondary Site Properties Unavailable After Primary Site Upgrade
After you upgrade an SMS 1.2 primary site to SMS 2.0, the SMS Administrator console does not display a version or build number for an existing SMS 1.2 secondary site. If you right-click <Site Code - Site Name> for the secondary site in the SMS Administrator console, the Properties menu item will not appear, and the Upgrade Site menu item is disabled. Additionally, the Upgrade Secondary Site Wizard will not show the secondary site as being available to upgrade, because the primary site needs updated configuration information from the secondary site to update its database. The secondary site will automatically send updated configuration information when its site configuration manager completes its next regular verification of the installation. Refreshing the SMS Administrator console's Site Hierarchy item after that time will cause all of the secondary site's data to appear and its menu items to appear or be enabled. The Secondary Site Upgrade Wizard will then list it as available for upgrade.
WORKAROUND: You can make the secondary site send updated configuration information immediately by opening a command prompt on the secondary site server and typing sendcode sms_site_config_manager 193. Sendcode.exe is on the SMS 1.2 compact disc and the SMS 1.2 Resource Kit compact disc.
New Clients Might Be in a Suspended State Until Site Upgrades Have Been Completed
If an SMS (no service pack) or SMS SP1 site is upgraded to SP2, and its CAPs have been upgraded to SP2, but the logon points have not yet been upgraded, new clients logging on will not complete the upgrade process and will remain in a suspended state. Clients will retry every hour to install Available Programs Manager (APM) and optional components from the CAP but will continually fail. (The relevant log line in the Ccim32.log is "ERROR: Unable to establish a connection with APM - the filename, directory name, or volume label syntax is incorrect.") When the logon point has finally upgraded and the client logs on again, the upgrade of base and optional components will be complete.
WORKAROUND: After the logon points have been upgraded, log the client back on to the domain. Alternatively, do not deploy new clients until logon point upgrades have been completed.
Always Back Up Before and After Upgrading
For more information, see Always Backup Before and After Upgrading in the Site Back Up and Recovery section of this document.
WORKAROUND: None.
Non-SMS Files and Folders Are Deleted When SMS Is Upgraded or Removed
If any non-SMS files or directories reside in the SMS directory structure, they are deleted when SMS is upgraded or removed.
WORKAROUND: To avoid removing non-SMS data when SMS is upgraded or removed, install SMS in a directory that does not contain other application or data files. In addition, do not install other applications in SMS directories.
Note: Copies of all files in the SMS site server directory tree are included in your SMS backup, if you have previously used the automated Backup SMS Site Server database maintenance task.
SMS 1.2 to SMS 2.0 Site Database Upgrade and Unique SMS ID
In environments where it is possible or likely that the site to be upgraded has SMS clients with duplicate SMS IDs, ensure that the duplicate clients have the SMS 1.2 client software removed before upgrade. For information about how to determine whether your site has duplicate IDs, see the Microsoft Knowledge Base Article Q192859 .
When you upgrade an SMS 1.2 site to SMS 2.0, remember that it takes some time to complete the SMS site database upgrade. The more history and aged machine records that exist in the SMS site database, the longer the upgrade process will take.
Note: The SMS 2.0 conversion program (Conv20.exe) automatically deletes history records older than 180 days.
WORKAROUND: To reduce the amount of data to be converted during an SMS 1.2 to SMS 2.0 site upgrade and to reduce the conversion time, do the following:
Verify that there are no duplicate SMS client IDs. (If there are, remove the SMS client software from the affected clients.)
Delete machine history records that are older than 60 days.
Delete machine history records with a last activity older than 30 days.
Use the SMS Database Manager (DBClean) to remove orphaned inventory data that was left when machine history records were deleted. This program appears in the program group for SMS 1.2 administrative tools.
Use Datdupck.exe (in \Support\Support.exe on the SMS 2.0 SP2 compact disc) to check for duplicate data keys in the SMS 1.2 site database. If Datdupck.exe reports that one or more SMS tables have duplicate data keys, do the following:
Back up the SMS site database before you continue.
Run Datdupcl.exe (in \Support\Support.exe on the SMS 2.0 compact disc) to clear the duplicate data keys.
Run SQL Server DBCC consistency checks, such as DBCC CheckDB and DBCC NewAlloc, against the SMS site database.
Back up the SMS site database before you upgrade to SMS 2.0.
You might want to perform a test upgrade by restoring your existing SMS site database on a computer running SQL Server in a test lab (no SMS site needs to exist on the test computer); installing the SMS 1.2 Administrator and related tools; and running the interface with the test database. In a test environment, you can manually run the database upgrade process (by running Conv20.exe in the SMSsetup\Bin\<Platform> directory on the SMS 2.0 compact disc). A test upgrade that uses the methods described in this section will help you determine whether the SMS site database upgrade will be successful and how long it will take.
Multiple Site Databases on Site Server Not Supported
Several SMS 1.2 sites can share a single instance of SQL Server running on a site server; however, SMS 2.0 does not support this configuration. SMS 2.0 Setup terminates if you attempt to install a second SMS site database on an instance of SQL Server that is running on an SMS site server. If you have multiple SMS 1.2 site databases on an SMS site server, then the site databases for the other sites must to be moved to a different computer before any of the sites can be upgraded to SMS 2.0.
An SMS 1.2 site's database can be moved to an instance of SQL Server on the site server from an instance of SQL Server on a different computer. After the site is upgraded to 2.0, this is no longer an option. For more information, see Moving the SMS Site Database in this readme file.
WORKAROUND: To move SMS site databases to separate installations of SQL Server:
Use SQL Enterprise Manager to dump the databases to be moved.
Restore each database to an instance of SQL Server that is not on the SMS site server for a different site. You can also install an instance of SQL Server on the SMS site server that uses one of the other databases. Then, restore that site's database to this new instance of SQL Server. The only database that can remain on the site server is the one used by that site.
Run SMS Setup.exe locally on each site (for each database to be moved) to point the site to the new database location.
After each database used by remote sites is moved from the computer running the SMS 1.2 site, upgrade that SMS site to SMS 2.0.
Identifying SMS 2.0 SP2 Sites
If you are not sure whether a site server, an SMS Administrator console, or a client has been upgraded to SMS 2.0 SP2, there are several ways to find out.
If the SMS 2.0 version number is 1493 (or slightly higher), you are running SP2. Use any of the following methods to determine the version number:
In the SMS Administrator console, navigate to Site Hierarchy. The build number for each site is listed in the Details pane.
In the registry of the site server, examine the Version values in the HKLM\Software\Microsoft\SMS\Setup key.
At the client, open Control Panel and click Systems Management. On the Components tab, look at the version number.
SMS Services Not Running After Successful SMS 2.0 SP2 Upgrade
After re-running upgrade you might receive a message stating that SMS has been successfully upgraded on your system. However, the site is shut down and SMS services are not started.
Note: This problem might occur after upgrade has failed and is re-run an additional time.
WORKAROUND: Verify that the site is shut down by checking the last three lines of SITECOMP.LOG:
Shutdown complete. Site shutdown complete. Transaction processing complete.
If these lines appear in the file, then the site is in a shut-down state. If so, you must re-run upgrade. However, if these lines are not present, then the site is not in a shut-down state, and additional troubleshooting might be required. If necessary, contact Microsoft Product Support Services.
For support phone numbers and information about support costs, see the Microsoft Product Support Services site.
Do Not Change Connection Accounts During SMS Site Upgrade
If the SMS Server Connection account is changed or recreated while upgrading an SMS site, access to the SMS directory tree and registry tree can be disrupted, and other problems might occur. Account management is a complex process that must not be performed in conjunction with a site upgrade.
WORKAROUND: Do not perform account management tasks during site upgrades. In particular, do not change or recreate the SMS Server Connection account during a site upgrade.
If the SMS Server Connection account name has been changed or recreated during SMS site upgrade, use the ACL Reset tool (Aclreset.exe) to restore access permissions. To download this tool, see the Maintenance & Recovery site.
If other account-related problems occur, see the troubleshooting section of SMS Security Essentials.
Also, always use the SMS Administrator console to change the SMS Client Connection account. For detailed instructions about specifying connection accounts, see Specifying Connection Accounts During Setup in this readme file.
Note: Use the ACL Reset tool every time the server connection account is changed or recreated.
Upgrading Secondary Sites
Secondary Site Disk Space Requirements for SMS 1.2 to SMS 2.0 Upgrade
If there is not enough disk space on a secondary site server to allow for file decompression and SMS 2.0 installation, that secondary site cannot be upgraded successfully. More disk space is required for upgrades that are sent from the parent site than for upgrades performed locally at the secondary site server.
WORKAROUND: If you upgrade over the network, ensure that the secondary site has at least 330 MB of free disk space, to allow for file decompression and SMS 2.0 installation.
If you upgrade from the SMS Setup compact disc, ensure that the secondary site has at least 100 MB free disk space for SMS 2.0 installation.
In each case, the figures do not include any space for the operation of SMS on the site server; 100 MB of additional free space should be considered minimum, but this can be exceeded if a large package is sent from the primary site.
If the secondary site server runs out of disk space during the upgrade, you need not cancel Setup; instead, create some free space, and then click Retry.
Apply SMS 1.2 SP4 to SMS 1.2 Sites
When you upgrade a site hierarchy from SMS 1.2 to SMS 2.0, clients at SMS 1.2 sites that have not yet been upgraded to SMS 2.0 might report errors.
WORKAROUND: If you plan to maintain one or more SMS 1.2 site servers in your hierarchy, update them to SMS 1.2 SP4 before you proceed with the SMS 2.0 installation. This service pack helps the clients remain silent during the upgrade. For more information, see Chapter 5, "Upgrading from SMS 1.2 to SMS 2.0," in the SMS 2.0 Administrator's Guide.
Installation: Server
Deploying This Service Pack
You should be prepared for this service pack to affect shared logon points, shared servers with SMS Provider, your network infrastructure, customizations, and mobile or multi-site clients.
Due to the highly distributed nature of SMS, you should deploy SMS service packs carefully. Considerable planning and preparation might be necessary.
WORKAROUND: For detailed information, see Deploying SMS Service Packs. This document is also located in the \Docs directory on the SMS 2.0 SP2 compact disc, with the file name SMS_SP.pdf.
Specifying Connection Accounts During Setup
By default, connection accounts and their passwords are randomly generated during SMS Setup. You might want to specify connection accounts for any of the following reasons:
To reduce the number of SMS accounts.
To force a custom account name to match organizational naming standards.
To force a known password to replace the randomly generated password.
WORKAROUND: During SMS Setup, specify existing accounts to use as connection accounts. The accounts can be specified as parameters to the Setup command, or you can list them in an SMSAccountSetup.ini file in the %Windir%\system32 directory of the targeted site server. In either case you must create the account before you run Setup. The SMSAccountSetup.INI file must be an ASCII text file, and can be created with Notepad.exe.
To use command-line parameters to specify an account:
Modify the Setup command with one or both of the following sets of parameters:
/ServerAccount domain\account /ServerPassword password/ClientAccount domain\account /ClientPassword passwordThen continue with Setup.
To use an SMSAccountSetup.ini file to specify an account:
Create an SMSAccountSetup.ini file in the %Windir%\system32 directory and populate it with the following entries:
[ServerAccount] Name=server_account_name Password=server_account_password
[ClientAccount] Name=client_account_name Password=client_account_password
To use command-line parameters to change an account password:
Modify the Setup command with the following parameters:
/ServerAccount domain\account /ServerPassword passwordThen continue through Setup, making no changes, and reset the site. See instructions for resetting the site in SMS Security Essentials.
Supported Configurations for Shared SQL Servers and SMS Providers
Any site server with a remote SQL Server must have a fast and reliable LAN connection between the two servers, and should be rated at 10 Megabits per second, or faster. The connection must have sufficiently free bandwidth available to support network traffic between the two servers.
Supported Configurations with no sharing of a SQL Server or SMS Provider
A site, SMS provider, SMS site database all on the same computer
A site and SMS Provider on the same computer, with the SMS site database on a remote server running SQL Sever
A site with the SMS site database and SMS Provider on the same remote server running SQL Server
Supported Configurations with SQL Server or SMS Provider Shared
Sites can share SQL Server on a remote server by setting up their separate SMS site databases on the remote Server that is running SQL Server
Each site setting up an SMS site database on a shared SQL Server has the option of choosing to share SMS Provider on the remote server where its SMS site database is, or of installing SMS Provider on the site server computer
Configurations Not Supported
Sharing SQL Server on the same computer on which an SMS site is installed
Sharing the SMS Provider on the same computer on which an SMS site is installed
A site connected to its remote SQL Server though a WAN
Required Update Q238762 Might Cause Excessive Software Inventory Table Size and Upgrade Failure
If you have applied update Q238762, you might have an excessively large software inventory table from multiple entries, which in turn might cause your SP2 upgrade to fail.
Because upgrading to SMS 2.0 SP2 causes clients to resynchronize their software inventory, additional entries are created in the SoftwareFile table that are eventually orphaned and deleted by the Delete Aged Collected Files database task. If the excessive size of the software inventory table causes Setup to fail, or if you need the inventory table cleaned up immediately, you must manually clean up the software inventory tables.
You are affected by this problem if your SoftwareFile table is approximately the same size as your software inventory table.
WORKAROUND: If it is acceptable for software inventory data to be temporarily unavailable:
Remove all software inventory by truncating the software inventory tables. This will result in a faster upgrade, but software inventory data is unavailable until software inventory is rerun on each upgraded client. As soon as a client is upgraded, a full inventory is run by the client.
Run the following commands in ISQL/W:
truncate table SoftwareInventoryStatustruncate table SoftwareInventorytruncate table SoftwareFile
Proceed with the upgrade.
If it is not acceptable for software inventory data to be temporarily unavailable:
Run the following commands from ISQL/W to determine how much space your software inventory tables are taking up:
exec sp_spaceused SoftwareFile, trueexec sp_spaceused SoftwareInventory, true
Ensure there is at least as much free space in the database as is reported under the data column. This is more of a concern when using SQL Server 6.5 because the database cannot automatically grow. If you are using SQL Server 7.0, ensure the database can grow enough to support this much free space.
Proceed with the upgrade. After the upgrade, set the Delete Aged Collected Files task to run daily. The cleanup task for orphaned entries in the SoftwareFile table is embedded in this task. After each client upgrades and runs software inventory, the duplicate files for that client are removed from the SoftwareInventory table, and the matching records in the SoftwareFile table are orphaned. These orphaned records are later cleaned up by the Delete Aged Collected Files task.
Crystal Info Installation Hangs
An MMC.exe process can be running even though no instance of MMC appears on the taskbar. You cannot complete the installation of Crystal Info while an MMC.exe process is running.
WORKAROUND: If the installation of Crystal Info appears to hang, open Task Manager. On the Processes tab, select the process MMC.exe, and then click End Process.
Prerequisites
Before installing an SMS primary or secondary site server on a computer running Windows NT 4.0, you must install Internet Explorer 4.01 SP1 or later and MDAC 2.0 SP1 or later. This software can be installed from the Windows NT 4.0 SP4 compact disc, or from the SMS 2.0 SP2 compact disc.
WORKAROUND: To install the software from the Windows 4.0 SP4 compact disc to a computer running Windows NT 4.0 SP4 or Windows NT 4.0 SP5, do the following:
Insert the Windows NT 4.0 SP4 compact disc.
Run Y2ksetup.exe from the <platform>\Update\ directory.
Install Internet Explorer 4.01 SP1 and MDAC 2.0 SP1 or higher. You might be given Custom or Complete Setup options during the MDAC installation. If you select Custom MDAC Installation, be sure to choose both ODBC Driver for Microsoft SQL Server and ODBC Driver for Microsoft Access.
If you do not have a Windows NT 4.0 SP4 compact disc, you can install the software from the SMS 2.0 SP2 compact disc. To install the software, do the following:
Insert the SMS 2.0 SP2 compact disc.
Run NT4SP4.exe from the NTQFE\NT4SP4 directory.
Run Y2ksetup.exe from the <platform>\Update\ directory on the computer running Windows NT.
Install Internet Explorer 4.01 SP1 and MDAC 2.0 SP1 or later. You might be given Custom or Complete Setup options during the MDAC installation. If you select Custom MDAC Installation, be sure to choose both ODBC Driver for Microsoft SQL Server and ODBC Driver for Microsoft Access.
Password Security
On computers running Windows NT or Windows 2000, non-administrative users can, by default, read files in the System32 directory. This would allow anyone with access to that server to read the password located in the SMSAccountSetup.ini file. By default, non-administrative users cannot log onto servers running Windows NT or Windows 2000, so the file is secure in that way. However, if you let non-administrative users log onto SMS servers, additional steps are required to protect the SMSAccountSetup.ini file.
WORKAROUND: On servers running Windows NT, adjust the security on the SMSAccountSetup.ini file by removing the Everyone permissions on it. On servers running Windows 2000, remove the Users and Power Users permissions on the SMSAccountSetup.ini file.
Moving the SMS Site Database
During original site setup you can choose either a local or a remote SQL Server on which to create the SMS site database. After setup, the SMS site database can be moved from the site server to another (remote) computer running SQL Server, or from one remote computer running SQL Server to another. However, the SMS site database cannot be moved from a remote computer running SQL Server to the site server.
WORKAROUND: None. Decide before running Setup whether to put the SMS site database on the site server computer. For example, you might choose to keep the SMS site database on the site server so that only one computer needs to be maintained for these two roles.
Installing SMS 2.0 Support Tools
To conserve space on the SMS 2.0 SP2 compact disc, SMS 2.0 SP2 support tools are bundled into an executable file.
WORKAROUND: To install the support tools, run the setup program, \Support\Support.exe, from the compact disc. The setup program prompts you to specify a location to install tools.
For information about using these tools, see the Tools.htm file, which is installed by the Support.exe setup package.
Express Setup
When choosing between Express and Custom Setup, be aware of the following:
Express Setup does not install NetWare or NDS support.
Express Setup, when run on a domain controller:
Enables all installation methods.
Enables all discovery methods except network discovery.
Express Setup, when run on a server that is not a domain controller:
Enables all installation methods, but logon installation is not configured with any domains.
Enables all discovery methods except network discovery, but logon discovery is not configured to enumerate any domains.
Enables and configures only the user account and user group installation and discovery methods.
WORKAROUND: If you need NetWare bindery, NetWare bindery emulation, or NetWare NDS Support, either use the Custom Setup option or run Setup from the SMS 2.0 SP2 compact disc again later to add these features. You can enable or disable installation and discovery methods at any time, as a part of regular site configuration.
Installation: SMS Client
Site System's Client Might Fail SP2 Upgrade When Not in Own Site's Boundaries
An SMS site system is also an SMS client if, and only if, it is in the supported boundaries of the site. An SMS site will attempt to install the SMS client on all of its site systems regardless of whether they are in the supported boundaries list. Normally such an attempt bows out gracefully if the site system is not supported, but some SMS client files nonetheless remain on that system. This situation causes conflict if the site system is an SMS client of a different SMS site that has a previous version of SMS.
If the site system is not in the boundaries of the sitefor which is ita site system, and the site system is a client of another site that has a previous version of SMS, the client software might fail to fully upgrade to SP2.
This failure might occur after the site server has been upgraded to SP2 and the site server tries to upgrade the clients of its site systems. The SMS client will be partially upgraded, although client functions will be suspended. The site system functionality will remain intact. This affects all site systems, including logon points, CAPs, distribution points, and software metering servers.
WORKAROUND: Include the site system's IP or IPX subnet in the boundaries of the site for which it is a site system, or upgrade the site to which the site system's SMS client is assigned.
SQL Server
SQL Server Upgrades Not Supported by SMS Setup
SMS Setup installs SQL Server, but it does not upgrade existing instances of SQL Server. These instructions assume only one SMS site is using the SQL Server software that is being upgraded.
WORKAROUND: If you plan to upgrade your instance of SQL Server:
If you are using SQL Server version 6.5 SP4 or later, you should upgrade SMS before upgrading SQL Server.
If you are using SMS 2.0 and SQL Server version 6.5 SP3 or earlier, you should upgrade SQL Server before upgrading SMS.
If you are using SMS 1.2, see DO NOT Upgrade to SQL Server 7.0 Before Upgrading to SMS 2.0: Printed Documentation Error
To use the recommended method for upgrading SQL Server:
Stop all non-Windows NT processes and services.
Stop the following SMS services to prevent them from accessing SQL Server:
Info Agent
Info APS
Info Sentinel
SMS_EXECUTIVE (Stop this service only on the SMS site server.)
SMS_SITE_COMPONENT_MANAGER
SMS_SQL_MONITOR (Running locally on the site server, if the site database is on the site server.)
SMS_SQL_MONITOR_<Site Server Name> (Running on the site database server, if the site database is not on the site server.)
SMS_LICENSE_SERVER (If software metering is enabled, and it is running on the SQL Server, then stop this service on the SQL Server.)
Note: This prevents the service from accessing ODBC components that need to be upgraded during the SQL Server upgrade cycle.
Stop and disable the Windows Management Service on the site server and the remote server running SQL Server (if the site is using one) to prevent an application from automatically starting Windows Management Service after it was stopped.
Upgrade SQL Server. The upgrade process sets SQL Server to single-user mode. It is crucial that no SQL Server client other than the upgrade process accesses this single connection.
If the upgrade stalls, it might be because another SQL Server client can access the connection. To ensure that this does not happen, isolate the computer from the network, and run the upgrade locally. If the SQL Server service is configured to log on using an account that requires authentication from a different computer, you must configure the SQL Server service to log on using a local account before you isolate the computer from the network. After the upgrade is completed, restore the computer to the network, and then configure the SQL Server service to log on using the account it used previously.
Enable the Windows Management Service and configure it to start automatically.
Important: Reboot the server to ensure a typical startup sequence for all applications and services.
Note: Using Preinst.exe /STOPSITE in conjunction with Setup could cause unexpected upgrade behavior and upgrade problems, so it is not recommended. Preinst.exe doesn't completely stop the site or stop access to SQL Server.
Refer to the SQL Server installation notes regarding SQL Server installation.
ODBC Error Message Appears While Upgrading to SQL Server 7.0
When you upgrade SQL Server 6.5 to SQL Server 7.0, you might see a SQL Server Setup dialog box that says "ODBC components on your system need to be updated, but one or more files are in use or are marked as read-only. Close all applications and click retry. Note that a reboot might be required to free the files". However, rebooting does not free the files if processes are automatically started by a service, registry keys, or the startup group at logon.
If automatically started Crystal Info services are keeping the files locked open after they are stopped or ended, you must configure them not to start at system startup logon. Afterwards, reboot the computer, then upgrade to SQL Server 7.0.
WORKAROUND: Stop all three Crystal Info services before you upgrade SQL Server 6.5 to SQL Server 7.0:
Info Agent
Info APS
Info Sentinel
SQL Server 6.5 Is Not Supported for SMS Express Setup on Windows NT Enterprise Edition
SMS Express Setup will fail if both of the following conditions are true and will succeed if only one is true:
Your site server is running under Windows NT 4.0 Enterprise Edition
Your site database is running an installation of SQL Server 6.5
WORKAROUND: Use Custom Setup if both conditions are true.
Interoperability with SMS 1.2
SMS Sites Cannot Share Databases
If you install an SMS site using an SMS site database that belongs to different site, neither site will function correctly. An SMS site cannot share its SMS site database with another SMS site, regardless of version. However, two sites can use the same computer running SQL Server if they have separate SMS site databases.
WORKAROUND: During SMS Setup, specify an SMS site database that is not being used by another SMS site.
Client Platform Restrictions
Computers running MS-DOS 6.22 or OS/2 can be discovered as resources, but they are not supported as SMS 2.0 clients. Also, Macintosh computers are not directly supported in SMS 2.0.
WORKAROUND: To support clients running MS-DOS 6.22, Macintosh, or OS/2, you must maintain an SMS 1.2 site within your site hierarchy. Or, upgrade the clients running MS-DOS 6.22 in the SMS 1.2 site to an operating system supported by SMS 2.0, and then upgrade the entire site.
For more information, see Chapter 5, "Upgrading from SMS 1.2 to SMS 2.0," in the SMS 2.0 Administrator's Guide.
Upgrading Clients of SMS 1.2 Child Sites Causes Advertisements to Re-Run
SMS 2.0 sites can send advertisements to clients of SMS 1.2 child sites, where they are run by Package Command Manager. If you then upgrade the SMS 1.2 child site and its clients to SMS 2.0, there is currently no mechanism on the client for informing the newly running Available Programs Manager (APM) that the advertisements have already been run under SMS 1.2. APM will run advertised programs that have previously come from the parent site as if it were the first time the client had seen them. This is true for all advertisements and for all client operating systems.
WORKAROUND: To prevent APM from re-running advertisements:
Delete advertisements that have previously been run by the SMS 1.2 clients on the site server.
Upgrade the child site server.
Upgrade the SMS 1.2 clients.
Optionally, create new advertisements.
Site Configuration and Maintenance
Setting a Parent Site
Attaching a child site to a parent site initiates a wide range of activity at both sites, and at sites further up and down the hierarchy. Some of this activity can affect performance or functionality, and it should be taken into account before you set the new parent for the site. This release note highlights some of these issues.
Performance Issues
Inventory data is bundled at the attaching child site, sent to the new parent, and then expanded and written to the SMS database at the parent. This data propagates up the hierarchy to the central site. If a large amount of inventory data is involved it can affect performance at the child and the parent sites, and create a load on the network when it is transferred. Consider this when deciding the best time to assign a new parent to a child site.
Overwriting Modifications to Software Distribution Objects
Objects created at a parent site can not be altered at a child site. If the child site is later detached from that parent, it gains control of these objects and administrators of that site can modify these objects. However, if the site is later attached to the same parent, or to a child or grandchild of that parent, the parent's version of these objects overwrites the version on the attaching site. The modifications made by administrators at the attaching site are then lost. This affects objects such as packages and advertisements that were originally created at the parent site and then propagated to the child site.
If you need the modified version of an object that was originally created at a parent site, create a new object with the same properties before re-attaching the child site to that parent site. Object definitions of software distribution objects created at the child site are unaffected by object definitions created at a parent site.
Re-use of Software Distribution ID Numbers
SMS 2.0 uses sequential ID numbers to manage software distribution and other objects throughout the hierarchy. If objects are created between the time a site is backed up and the time it fails, these ID numbers are in use at child sites when the site fails, but they are not included in the backup used to restore the site. For this reason, site recovery involves gathering data about existing objects from child sites, and also resetting the starting ID number for new objects. If this is not done, a new object can be created at the parent site that uses an old ID number - one that is already in use at child sites. This can cause a variety of problems.
This problem is magnified when a site is reinstalled without restoring a backup after failure.
For example, suppose that a package of Microsoft Office is created at the parent and was assigned the ID number 2345. At a child site, an advertisement is created to distribute Microsoft Office to the Artists user group. Internally, the advertisement refers to the package by the ID number 2345. A few days later, but before the package definition is included in any backup, the parent site fails, and is recovered. (Recovery includes restoring data from the database and several other steps, including resynchronizing the failed site with other sites in the hierarchy.) During recovery, the ID numbers are not explicitly reset at the parent. As a result, the next ID number to be used at the parent site is lower than 2345. Shortly after the site is restored, a new package is created to distribute financial analysis software, and this new package is assigned the number 2345. The new package is propagated to child sites. At the child site that advertised package 2345 to Artists, members of the Artists group attempt to install Microsoft Office, but instead get the financial analysis software.
The same issues apply to sites above and below these two sites in the hierarchy.
WORKAROUND: Carefully consider the impact of assigning a parent to a site, especially if the attaching site has been part of the hierarchy previously.
See Knowledge Base article Q258924 for more information on setting a parent site.
For more information about incrementing serial numbers in a site reinstall during a site recovery, see the SMS Maintanance & Recovery site.
Security
Default Permissions for CAPs Not Automatically Updated During Upgrade from SMS 2.0 to SMS 2.0 SP2
To enhance security in SMS 2.0 SP2, new default permissions are set on client access points (CAPs). However, these settings are not applied automatically when you upgrade SMS 2.0 to the SMS 2.0 SP2 release.
WORKAROUND: To use the new default permissions, after you upgrade to the SP2 release of SMS 2.0, do one of the following:
If you have more than one CAP, remove the client access point role from a site system, and after SMS removes the share and directories, assign the CAP back to the site system. The new CAP will have the new default permissions. Repeat until all the CAPs have the new permissions. You must always have at least one CAP in the site.
Or, if you have only one CAP:
Use Windows NT Explorer to stop sharing the CAP share and subdirectories. If messages appear informing you of open connections to the share, choose to close the open connections.
If the CAP is on the site server, set Site Component Manager, SMS Executive, and Logon Discovery Agent to start manually on the site server. This prevents them from accessing the CAP directories after the reboot. If the CAP is not on the site server, stop Site Component Manager and SMS Executive on the SMS site server. Set SMS Executive and Logon Discovery Agent to start manually on the computer on which the CAP resides.
Reboot the computer on which the CAP resides.
Delete all of the directories (including subdirectories) and files in the CAP share.
Set Site Component Manager, SMS Executive, and Logon Discovery Agent to start automatically.
Start Site Component Manager. (Allow Site Component Manager to start SMS Executive and Logon Discovery Agent on the SMS site server, and remote CAP.)
The CAP will be rebuilt and shared with the new access permissions.
Or, set permissions on the existing CAP share and subdirectories manually, according to the following table.
Permissions (Windows NT)
Share or Directory Name |
Administrators |
Guests |
Users |
Everyone |
|---|---|---|---|---|
CAP_<sitecode> (share) |
N/A |
N/A |
N/A |
Full |
CAP_<sitecode> |
Full |
RX |
RX |
N/A |
CCR.box |
Full |
RWX |
RWX |
N/A |
Clicomp.box |
Full |
RX |
RX |
N/A |
Clidata.box |
Full |
RX |
RX |
N/A |
Clifiles.box |
Full |
RX |
RX |
N/A |
DDR.box |
Full |
RWX |
RWX |
N/A |
Inventory.box |
Full |
RWX |
RWX |
N/A |
Offerinf.box |
Full |
RX |
RX |
N/A |
Pkginfo.box |
Full |
RX |
RX |
N/A |
Sinv.box |
Full |
RWX |
RWX |
N/A |
Statmsgs.box |
Full |
RWX |
RWX |
N/A |
Key: R=Read, W=Write, X=Execute, F=File Scan, C=Create, M=Modify, N/A=not applicable
Permissions (NetWare)
Share or Directory Name |
Bindery Everyone |
NDS OU |
|---|---|---|
CAP_<sitecode> (share) |
N/A |
N/A |
CAP_<sitecode> |
RF |
RF |
CCR.box |
RWFCM |
RWFCM |
Clicomp.box |
RF |
RF |
Clidata.box |
RF |
RF |
Clifiles.box |
RF |
RF |
DDR.box |
RWFCM |
RWFCM |
Inventory.box |
RWFCM |
RWFCM |
Offerinf.box |
RF |
RF |
Pkginfo.box |
RF |
RF |
Sinv.box |
RWFCM |
RWFCM |
Statmsgs.box |
RWFCM |
RWFCM |
Key: R=Read, W=Write, X=Execute, F=File Scan, C=Create, M=Modify, N/A=not applicable
Note: Directories that formerly had Change permission, but now have Write permission, no longer have Delete access.
For a table of default permissions in the initial release of SMS 2.0, see "Using Windows NT File and Directory Security" in Chapter 4, "Creating Your SMS Security Strategy" of the SMS 2.0 Administrator's Guide.
Site Backup and Recovery
Recommended Tasks to Perform Before Site Backup
Run the following database consistency check tasks before a site backup to reduce the risk of a corrupted backup:
dbcc checkdb
dbcc checkcatalog
dbcc newalloc (SQL Server 6.5 only)
dbcc textalloc (SQL Server 6.5 only)
See the topic, Backing Up a Site, in the SMS 2.0 Administrator's Guide, or see the SMS 2.0 Help for additional information on these tasks.
WORKAROUND: None.
Always Back Up Before and After Upgrading
You cannot restore an SMS site database unless you have a recent backup. A site's functionality can be recovered without restoring a backup. However, all inventory and status information will be lost, and most or all data will be lost.
WORKAROUND: Configure and enable the automated "backup SMS site server" task from the SMS Administrator console. Then start the SMS_SITE_BACKUP service.
Upgrade Overwrites Backup Control File
There are significant differences between the backup control file (Smsbkup.ctl) for SMS 2.0 SP1 and SMS 2.0 SP2. The backup control file used for SP1 cannot be used for SP2, and is overwritten during the upgrade process. If you have customized the backup control file, you must reproduce the customizations in the new version of the file.
The SP1 version of the backup control file was based on the features installed by Express Setup and generated spurious errors if the site had been installed using Custom Setup with fewer features installed.
The SP2 version of the backup control file is based on a minimal installation of SMS. The backup tasks for the optional components are listed but are commented out. If optional components are installed on your site, you must uncomment the tasks for those components to include them in the backup.
WORKAROUND: If you are using a customized backup control file, save a copy of it before upgrade. The copy in the directory SMS\inboxes\smsbkup.box\smsbkup.ctl will be overwritten. After upgrading your site, use the old backup control file as a guide to update the new file.
If you are using the default backup control, and any of the following components are in use, edit the new Smsbkup.ctl file to remove the comments from the lines that refer to them.
Crystal Info
Network Monitor
SNMP Events
Software Metering
Using SMS With Windows 2000
Using Crystal Info After Upgrading from Windows NT 4.0 to Windows 2000 Removes WMI ODBC Driver
During the upgrade from Windows NT 4.0 to Windows 2000, the WMI ODBC driver is removed. This prevents Crystal Info from working. The WMI ODBC driver should be restored from the SMS 2.0 SP2 compact disc rather than from the Windows 2000 compact disc because SMS 2.0 SP2 includes a newer version.
WORKAROUND: Install the WMI ODBC driver using Wbemsdk.exe. Wbemsdk.exe is in the \SMS\bin\i386 directory on the site server and in the \SMSSetup\bin\i386 directory on the SMS 2.0 SP2 compact disc. From the command line type:
wbemsdk /s /server
Note: The /s option must precede the /server option. This option configures the program to run silently.
Additional Information About Using SMS with Windows 2000
Detailed information about using SMS with Windows 2000 is available on the Systems Management Server Web site. This information is not available on the SMS 2.0 SP2 compact disc.
WORKAROUND: Refer to SMS – Windows 2000 Compatibility.
Internationalization
International Client Packs Cannot Be Uninstalled
You cannot uninstall International Client Packs.
WORKAROUND: Back up your site before installing the ICP. That way, you have the option of recovering the site if you encounter problems with the ICP in your site environment.
Versions Must Match for Site and International Client Pack
If the version of the site and the version of the ICP applied to the site do not match, client language support is lost. Also, a site configuration with one version for the core binaries and English user interface, and a different version for the ICP, is not supported.
WORKAROUND: Immediately after upgrading the site server that has an ICP installed to a new version of SMS, upgrade the ICP to the new SMS version.
For example, if you want to upgrade an SMS 2.0 SP1 ICP4 site to SMS 2.0 SP2 ICP4, you would install SMS 2.0 SP2 and then immediately install SMS 2.0 SP2 ICP4. Leaving just SMS 2.0 SP2 installed or installing SMS 2.0 SP2 ICP1 (an earlier version of ICP) are not supported configurations. Additionally, installing SMS 2.0 SP1 ICP4 after installing SMS 2.0 SP2 is not supported.
No Separate Readme for Localized Version
Earlier releases of localized versions of SMS provided a separate readme file for issues specific to that localized version. Beginning with SMS 2.0 SP2, all issues specific to all localized versions of SMS are documented in the Internationalization sections of the Installation readme file and the Operations readme file. There is no longer a language-specific readme file.
Issues specific to International Client Packs (ICPs) are documented in the readme_ICP.htm file, which is included with each ICP. All three readme files (readme.htm, readme_operations.htm, and readme_ICP.htm) contain the most up-to-date information as of the releate date.
For issues specific to a localized version of SMS 2.0, SP2 or later, read the Internationalization section of the readme files.
Windows 2000 MultiLanguage Version Not Supported by SMS 2.0 SP2
For information about Windows 2000 MultiLanguage version support in SMS 2.0 SP2, see the Microsoft Knowledge Base article Q259447, SMS: Windows 2000 MultiLanguage Version Support in SMS 2.0 SP2.
WORKAROUND: None.
Setting the AutomaticAnsiToOEM Option for SQL Server
The default installations of SQL Server version 6.5 and SQL Server version 7.0 enable the AutomaticAnsiToOEM option. However, if your computer running SQL Server will process data from non-US code pages, you should disable the AutomaticAnsiToOEM option.
WORKAROUND: To disable the AutomaticAnsiToOEM option, use the appropriate procedure:
For SQL Server version 6.5, do the following:
In the SQL Server Client Configuration Utility, click the DBLibrary tab.
Clear the Automatic ANSI to OEM check box.
Click Done.
For SQL Server version 7.0, do the following:
In the SQL Server Client Network Utility, click the DB Library Options tab.
Clear the Automatic ANSI to OEM conversion check box.
Click OK.
Site Hierarchies Using Multiple Character Sets
If your site hierarchy uses more than one character set, you must specify code page ANSI 1252 or ISO 8859-1 Latin 1 when you install SQL Server for your site databases.
WORKAROUND: None.
Printed and Online Documentation
Online Version of SMS 2.0 Administrator's Guide Is Most Current
Updates and corrections have been made to the online version of the SMS 2.0 Administrator's Guide (SMSAdmin.chm). This online version is more up-to-date than the printed version.
WORKAROUND: For a summary of changes and corrections made to the online SMS 2.0 Administrator's Guide, please see the Readme_Operations.htm file on the SMS 2.0 SP2 compact disc, or the Operations Readme book in the readme.chm file.
See also DO NOT Upgrade to SQL Server 7.0…
HealthMon
Installing the HealthMon 2.0 Agent on Windows 2000 or on Windows NT 4.0 Using WMI Version 1.5
If you attempt to install the HealthMon Agent on a computer running either Windows 2000 or Windows NT 4.0 with Windows Management Instrumentation (WMI) version 1.5 by running Setup.exe directly from a read-only location (such as the SMS 2.0 SP2 compact disc), the HealthMon MOF file will fail to be compiled and the agent will not be configured correctly. During Setup, you will receive an error message stating, "The installation was unable to compile the MOF file." After this error message appears, however, the Setup Installation Completed page will state, "The installation of the HealthMon Agent has been successfully completed." This is incorrect because the agent configuration was not completed. If you install the HealthMon console after this error occurs and then attempt to add a system to the console, you will see the following event message in the events pane:
Could not connect to <computername>. The HealthMon Agent may not be installed or is incorrectly configured on <computername>.
The agent installation fails when you attempt to run the HealthMon Agent Setup.exe file from the SMS SP2 2.0 compact disc or any other read-only location because WMI requires Read\Write access to the location where this Setup executable file will run.
WORKAROUND: To install the HealthMon Agent successfully, do the following:
From the HealthMon\Platform\Lang ID\Agent directory on the SMS 2.0 SP2 compact disc, copy the Setup.exe file to the computer where you want to install the HealthMon Agent. WMI must have read\write access to this location.
Run Setup.exe from this location.
- or -
If the HealthMon Agent software is already installed, do the following on the computer where you installed the software:
At the command prompt, switch to the following installation directory:
\Program Files\Microsoft SMS HealthMon\AgentTo compile the HealthMon MOF file, type the following:
%SystemRoot%\system32\wbem\mofcomp healthmon.mof
Note: This problem only occurs when you attempt to install the HealthMon Agent by running Setup directly from a read-only location, such as the SMS 2.0 SP2 compact disc. You can run the HealthMon console Setup.exe file directly from the SMS 2.0 SP2 compact disc to install the HealthMon console.