Q: What do I do before upgrading a site? What if the upgrade doesn't complete?
Be sure to back up the site, all subsites, and their related SQL databases before upgrading. For information about backup procedures, see Appendix K in the Systems Management Server Administrator's Guide for primary sites, and Microsoft Knowledge Base article Q138347 for secondary sites. You can access the Knowledge Base from the Microsoft Network (MSN), ftp.microsoft.com, Microsoft TechNet, and CompuServe.
Before you upgrade Systems Management Server (SMS) site server software, Microsoft recommends that you perform a Site Reset from the SMS Setup program. This reset ensures that all service components are properly responding to service control commands for stopping and starting.
If you are running Windows NT 3.5 with Service Pack 3 and attempt to install SMS 1.1, you may be unable to upgrade. On NT 3.5, SMS 1.1 setup checks only for Service Pack 2 and below. Contact Microsoft Product Support Services (PSS) for technical assistance.
During an install or upgrade of an SMS primary site, the appearance of the Primary Site Configuration dialog can mean that the system detected an installation error, a component failing to install, or a component failing to start correctly. If you change the Site Code when the second dialog appears, SMS Executive, Inventory Agent, and Package Command Manager services do not install successfully.
The smssetup.log file in the root of the SMS site server C drive is useful for finding installation and upgrade failure points. Do not, under any circumstances, change the SMS share name comments from those SMS creates.
Q: How do I add NetWare 4.X servers to my site?
For specific instructions on adding NetWare servers to your SMS site, see the SMS 1.1 Release Notes and the SMS 1.1 Frequently Asked Questions (FAQ) Help file. Setup creates an icon for this Help file in the SMS program group. The Help file provides detailed information about modifying the login script and configuring the server.
Q: Why am I having difficulty setting up my Windows for Workgroups (WFW) client?
You can choose among several ways to troubleshoot this problem, depending on the client's symptoms. Some problems relate to client memory configuration (e.g., not enough environment space available). If you can run smsls.bat (or runsms.bat) and you see Client Setup start, you can run through a few troubleshooting scenarios to identify your problems.
First, SMS Client Setup can incorrectly identify a Windows workstation as an MS-DOS client (i.e., the SMS section in the sms.ini file indicates OS=1 for an MS-DOS client instead of OS=2 for the Windows client) for three reasons:
- SMS Setup cannot find the win.com file in the path.
- Setup cannot find win.com in the path if the subdirectory for Windows is
too far down the path. For example, a system with the following path is detected
as an MS-DOS client:
path c:\;c:\dos;c:\util\path;
c:\apps\oracle;c:\apps\pctools;c:\wfw311 - The SMS batch process runs out of environment space.
Make sure that you correctly specify your Windows directory in the path, and
avoid using \Windows without specifying the full path name. To ensure proper
detection of the OS, move the Windows subdirectory closer to the beginning of
the path statement. One implementation of a correct path is the modified path
below:
path c:\;c:\dos;c:\wfw311;c:\
util\path;c:\apps\oracle;
c:\apps\pctools
To ensure that the SMS batch process does not run out of environment space, place the following setting in the Windows client's system.ini:
\[NonWindowsApp\]
CommandEnvSize=1024
If the client hangs when you run Inventory Agent, you need to check for a c:\smssafe.tmp file. This file lists each test you've run. The last test in the list is the test that hung the client. Inventory Agent deletes this file if it completes normally. If you are running SMS 1.1, the smssafe.tmp file is also in the ms\sms\data directory. You can set the SMSLS=1 environment variable. It turns on the smsls.bat file's verbose mode, which echoes all output to the screen, to help you determine where the Inventory Agent hung the client. Furthermore, you can modify the Inventory Agent command line directly to redirect its output to a file. You can closely examine the resulting text file to investigate the problem. An example of this procedure is
invdos /v > c:\invdos.txt
Once you determine where the Inventory Agent is hanging, remove or reconfigure the suspect component, and rerun the inventory. After you narrow the problem to a particular configuration, report the results to Microsoft PSS.
Finally, when you mistakenly configure two clients with the same SMS ID, the machine inventory appears to change and contain entries from another system. Check the machine name, logon name, or other unique identifier. If these change, you can track which machines have the same SMS ID.
To correct this problem, delete the sms.ini file from one system and run smsls.bat again on that system. This deletion assigns a new SMS ID to the affected system and creates a new entry in the SQL database. If this problem occurs on several systems, check all the \\<logon server>\sms_shr\smsid directories for the site, and confirm that the current .uid file contains a unique ID to assign to the next new SMS client that the system configures.
Q: What precautions do I need to ensure a successful first-time SMS site installation?
For step-by-step instructions, see the setup.hlp Help file under the smssetup subdirectory on the retail SMS 1.1 CD. Also, be sure you have configured your SMS service account correctly and granted it the proper rights (e.g., a member of the Administrators group has the "Log on as a service" right) and that you have met all SQL requirements. You can review the smssetup.log file in the root of the C drive if any problems arise.
Q: The workstation package I sent to my client never appeared in Package Command Manager. What went wrong?
Make sure the site server contains enough disk space so that the scheduler can create a compressed copy of the package. The Despooler needs enough disk space to decompress the package. Also, check for a lack of disk space on distribution servers; they need enough space to receive the uncompressed package. Then verify job details and make sure you have specified the distribution servers for the clients. Also, the client's system time must be synchronized with the distribution server.
Here are several prevalent SMS workstation package problems and how you can resolve them.
- The workstation package has been created and distributed with no errors,
but the item never shows in the pending folder of the destination system's
Package Command Manager.
First check the package workstation properties and confirm that the Supported Platforms pick list has the destination system's platform selected. Using SMS Administrator, check the PC Properties for the destination system, and confirm that SMS has the correct platform type for the target system.
Next, get the CurrentLogonServer location and the unique SMS ID from the hidden c:\sms.ini file. Check the \\<logonserver>\sms_shr\pcmins.box directory for a file with the name <Unique SMS ID>.ins.
If it doesn't exist, the instruction file for this system is missing from that logon server. The SMS Maintenance Manager is responsible for placing these files on the logon servers. Check the \sms\logs\maintman.log file for errors during this file's replication from the site server to the logon server. Check Appendix C of the SMS Administrator's Guide for details.
If the <SMS ID>.ins file exists on the logon server, use PCMDUMP to display its contents. (you can copy PCMDUMP from the \psstools directory on the SMS CD.) The Display Date and Expiration Date fields can tell you why the package has not been displayed on the destination system. - The mandatory package does not execute on time or does not execute at all.
Use PCMDUMP to check the Install By Date field's value. Compare this date/timestamp with the destination system's current date/time. Before PCM will run the package, the system time must be on or after the Install By Date.
If the package is supposed to run unattended on an NT system that has no user logged on locally, ensure that these conditions are met: First, confirm that the package doesn't use console I/O so nothing prints to the screen or requires keyboard or mouse input. The PCMSVC executes System Background installation tasks and has no access to the local console for I/O. Any console I/O in this type of package will fail. Second, confirm that both Automated Command Line and System (Background) Task are selected in the package's workstation properties. Third, confirm that the PCM service user account for the NT client has rights to execute the job on the system. On an NT system in a secure environment, you can keep the PCM service from accessing particular directories or other Windows NT system objects that can cause the installation to fail. - The package fails to execute properly or does not execute at all.
Ensure that you configured the package source directory and the package command line correctly. First, the command line must point to a valid executable. Second, all directory path references must be relative to the package source directory. For example, to execute setup.exe in a package's install directory, use a relative path in the command line (install\setup.exe). Do not use an absolute directory path reference (\\smssvr\d$\package1\install\setup.exe).
Next, use PCMDUMP to see what distribution servers contain the package. Connect to a listed server share and change to the directory listed for the package. Run the Packages Command Manager from this directory. Look for errors such as a reference to incorrect paths or missing files.
Then confirm that the package directory contains a mirror image of the original source directory specified when the package was created. Except for the top-level directory name, both directory trees will be identical. If not, check the despool.log file for errors during creation of the directory structure on the distribution server. If the distribution directory does not exist on the servers, check the \sms\logs\despool.log file on the SMS site server for errors referring to this directory's creation and file population. - The package instruction files never arrive or never get updated in the <logon
server>\sms_shr\pcmins.box directory.
Check the SMS site server \sms\site.srv\maincfg.box\pcmdom.box\<clients domain>\ directory. Confirm that an instruction file exists for the client and that it has been updated since the package was distributed. Use PCMDUMP if you are unsure of this file's status or contents.
If it exists and is updated, check the \sms\logs\maintman.log file for any errors logged when SMS attempted to transfer this file to the logon servers. The SMS Maintenance Manager will replicate these files at a regular watchdog interval. Use the log file to confirm that this watchdog cycle has occurred and that the logon server was one of its targets. If this file doesn't exist or has not been updated with the current package, check the despool.log file for errors in the creation or distribution of instruction files.
Q: What can I do if I can't install secondary sites successfully?
This problem happens for many reasons, including account problems, name resolution (WINS/DHCP, LM HOSTS), and corruption of the primary site. For this last problem, figure out where the account problems are, based on the primary site hierarchy. Then redo the setup with the proper account information. Make sure the SMS Service account has the correct Log On As Service for the target domain.
SMS Hierarchy Manager doesn't upgrade secondary sites until all those under the same parent have an active status. The administrator must resolve problems with secondary sites or let pending jobs finish before attempting the upgrades.
The SMS Senders don't check for free disk space before sending a package. So if the destination site doesn't have enough space for the package, the job fails. Furthermore, the Bootstrap service checks for enough free disk space (5MB) to install the site server components. If not enough disk space is free, the Bootstrap service reports the problem to the trace log and Windows NT event log and stops the installation.
After a failed attempt at installing a secondary site, an empty SMS directory remains on the target secondary site server. Delete this directory before repeating a secondary site installation; otherwise, the installation will fail again.
