Now that you have learned about the primary tools for troubleshooting SMS components, this lesson will explain which components are involved in running various SMS functions like software distribution and software metering. Armed with knowledge of the tools described in Lesson 1 and the functional view of SMS features provided here, you can effectively troubleshoot SMS.
TIP
The system flow diagrams contained in Appendix D of the SMS Administrator's Guide and in the Systems Management Server Administrator Help online book provide detailed information on how SMS services interact with a site. Use these diagrams to aid you in troubleshooting SMS. To troubleshoot SQL Server, refer to the SQL Server Books Online and the BackOffice resource kits.
If SMS setup fails to install the site server, the failure can usually be attributed to SQL Server, disk, or security problems. While SMS setup is running, it writes its progress to the Smssetup.log file. This file can be used to diagnose where SMS setup failed. The following table lists some common setup problems.
| Problem | Solution |
|---|---|
| Devices for SMS databases (site database and software metering database) are not available. | Use SQL Server Enterprise Manager to create or verify that the devices have available space to hold the SMS databases. If SMS setup creates the SQL Server devices, you will not see any SQL Server errors. |
| Not enough user connections for SQL Server. | Use SQL Server Enterprise Manager to increase the number of user connections to at least 55. |
| The SMS setup program fails to set up the site because the SMS Service account does not have enough rights. | Use User Manager for Domains to add the SMS
service account to the Domain Admins group, and then verify that
the 'Log on as a service' advanced user right is assigned to the
Administrators local group.
If the installation continues to fail, verify that the SMS Service account has permissions to access SQL Server over the network. In a Windows NT Server domain, verify that a trust relationship exists between the site server domain and the domain containing the SQL Server. That is, the SQL Server domain must trust the site server domain. If no trust relationship exists, add the SMS Service account to the domain containing the SQL Server. |
| SMS setup fails because a remote SQL Server does not have a device created before installing Systems Management Server. | For SQL Server version 6.5, create the devices for the SMS databases in SQL Server Enterprise Manager. For SQL Server version 7.0, create the databases that SMS setup will use. |
| SMS setup fails with a low disk space error | Verify that the NTFS partition that will contain SMS has enough disk space to complete the SMS installation. At minimum, 1 GB of disk space should be available for SMS. |
| SMS setup only allows for the installation of the SMS Administrator console. | There are no partitions formatted for NTFS or the
server was not restarted after the creation of an NTFS partition.
The computer is not running a compatible version of Windows NT/2000 to support a primary or secondary site server. An SMS site server cannot be installed on a computer running Windows NT Workstation or Windows 2000 Professional. |
| SMS setup stops, stating that a more recent service pack is required. | Windows NT version 4.0 running SP4a or later must be installed before a site server is installed on Windows NT Server version 4.0. Service Pack 4a is included on the SMS 2.0 installation CD-ROM. |
If a secondary site fails to install, the failure is usually one of a small set of problems. Reviewing the secondary site server installation progress log file (SMS_BOOTSTRAP.LOG), the Windows NT Event Viewer Application log file, and the log files for the services used on the primary site server to create a secondary site can help to isolate the problem.
Start by reviewing the SMS_BOOTSTRAP.LOG file on the root of the targeted secondary site server installation drive.
At the remote site server computer, check the Application log to see if the Bootstrap service has generated any errors. However, the information in the bootstrap log file is more verbose than what is written to the Windows NT Event Viewer Application log.
The services associated with secondary site installation will generate an event if they cannot complete their tasks successfully. If not enough information is in the SMS_BOOTSTRAP.LOG file to fix the problem, view the log files of the components involved at the primary site server (Hierarchy Manager, Site Component Manager, and the sender).
A secondary site server will fail if:
NOTE
If the site server runs out of disk space, services may not be able to create any error messages.
You may have supplied an incorrect site server computer name or the wrong SMS account name or password. You may have also supplied the wrong domain name. These errors will be obvious in the sender's log file. Enable Windows NT/2000 security auditing at the destination site server to see if the sender is encountering access problems.
It is recommended that you specify the domain name when configuring the service account to designate the domain in which the account is valid.
A secondary site server requires 223 MB of disk space to complete the installation. The Bootstrap service checks for this disk space minimum. If the minimum is not met, the Bootstrap service aborts the installation.
In the following sections, many of the client agent troubleshooting procedures are discussed in the context of the function they support. For all client agents, the following procedure quickly resolves many agent failures: Run the Control Panel's Systems Management application, choose the component that is failing, such as Remote Control, and then choose Repair Installation from the Components tab.
If running the installation repair procedure doesn't solve the client agent failure, it may be necessary to remove the core client component and the client agents. There are two ways to initiate a client agent removal:
The Systems Management Installation Wizard is located on logon points.
This batch file and the supporting files it calls remove all SMS client components. This tool is located below the RESKIT directory on the SMS 2.0 installation CD-ROM.
Another useful, client component troubleshooting tool on the SMS 2.0 installation CD-ROM is the Client Utilities Tool (CLIUTILS.EXE). This tool allows you to control, configure, and monitor the client components.
Hardware inventory components report events in log files and to the SMS status message system.
The Hardware Inventory client installation procedures report successful installation of the Hardware Inventory Client Agent, although this message is typically written 60 minutes after the installation of the client agent. The client agent then sends an 'inventory complete' message to the site server. The Hardware Inventory Client Agent reads SMS_DEF.MOF to determine what hardware inventory should be collected. SMS_DEF.MOF processing is reported to the site server. The Inventory Data Loader reports processing of client computer inventory for each client computer.
TIP
All site system log files and any client log files containing "32" in their prefix can be read and displayed by SMS Trace. All other client log files should be read with an ASCII text editor.
The following log files located on the client computer in the windir\MS\SMS\LOGS directory, provide insight into hardware inventory status and activity:
Client Component Installation Manager (CCIM) detects a hardware inventory offer.
Advertised Programs Manager schedules the Hardware Inventory Client Agent installation.
The Hardware Inventory Client Agent is installed. Upon successful installation, an 'Installation completed' message appears at the bottom of this log file.
Hardware Inventory Client Agent generates data as scheduled.
SMS Copy Queue copies data and status files to the CAP.
The following log files provide insight into hardware inventory status and activity:
Inbox Manager Assistant reports moving data files to the site server. This log file is located in the smsdir\LOGS directory on the CAP.
Inventory Processor reports individual client computer files being processed.
Inventory Data Loader reports individual client computer file processing delivered by the Inventory Processor.
NOTE
A common problem with server logs is lack of disk space. In the event that logging errors are reported and/or SMS services fail to start or stop running once started, disk space should be the first item checked.
Since a client computer can be a member of multiple SMS 2.0 sites, and because each site has unique configurations and schedules for inventory, the schedule of the principal site is used for inventory scheduling. The principal site is identified in the registry of the client computer. It is the first site in the sites list.
If inventory data (both hardware and software inventory) are not complete in the site database, run the Inventory Synchronizer Tool (INVSYNC.EXE) from the site server at the local site.
If you are creating custom inventory using MIF files, use the MIF Checker tool (MIFCHECK.EXE) to validate the syntax of a MIF file before submitting it to the site database. This avoids database problems resulting from an invalid MIF file. If custom inventory does not appear in the site database, analyze the messages generated by the Inventory Processor.
To update the master hardware inventory file (SMSDEF.MOF) use the MOF Manager Tool (MOFMAN.EXE) rather than editing the file using an ASCII text editor.
Software inventory components report events in log files and also send status messages to the status message system.
The Client Component Installation Manager (CCIM) reports successful installation of the Software Inventory Client Agent, which is delayed until after the CCIM verification cycle. Software Inventory Client Agent reports the completion of software inventory collection. The site server Software Inventory Processor reports processing of client computer software inventory for each client computer.
The following log files provide insight into software inventory status and activity:
Client Component Installation Manager detects a new component (the Software Inventory Client Agent) and submits the offer to the Advertised Program Manager.
Advertised Programs Manager installs the Software Inventory Client Agent.
Software Inventory Client Agent reports installation status. Upon successful installation, an 'Installation completed' message appears at the bottom of this log file.
Software Inventory Client Agent collects software inventory information and reports its activity.
SMS Copy Queue copies data and status files to the CAP.
The following log files provide insight into software inventory status and activity:
Inbox Manager Assistant reports the moving of data files to the site server. This log file is located in the smsdir\LOGS directory on the CAP.
Software Inventory Processor reports the processing of individual client computer data files.
If the Software Inventory Processor is not properly processing software inventory, the Software Inventory Viewer tool (SInvView.exe) can be used to view data generated by the SMS Software Inventory Processor during its inventory processing cycle.
You can take the following steps to make sure inventory is getting reported to the site server:
Hardware and software inventory are configured on different schedules. Therefore, check the schedules for both inventory methods.
Inbox Manager
Inbox Manager Assistant
Inventory Processor
Inventory Data Loader
Software Inventory Processor
Status messages for Software Metering are basic component start and stop messages. While each software metering component keeps a log file, the Software Metering Client Agent provides the most useful logging activity for resolving problems. The client agent writes the following activities to the LICCLI.LOG file:
Common software metering problems are:
Verify that the software metering server has been installed and that the Swmtr directory and the software metering account exist.
You can run a trend analysis for seven days, after which licenses are distributed to software metering servers. If a trend analysis is not performed, a client computer must receive a denial to trigger license balancing at each of the site's software metering servers.
This setting is specified on the Permissions tab for the program. This Permissions tab is contained in the properties of the program in the Software Metering tool.
Excluded programs are listed under the Tools menu's 'Excluded Programs' option in the Software Metering tool.
The default schedule for passing metering data is set in hours. Configuration change propagation is set in the Component Configuration node's Software Metering object. The Local tab controls license balancing within the site, and the Intersite tab controls license balancing between sites.
Software metering servers will appear in the client computer's registry.
The Software Metering Server service will appear in the Services application and in the SMS Service Manager.
The 'Time zone' setting is configured in the properties of the software metering site system.
Remote Tools operate in real time. Therefore, troubleshooting the Remote Tools function usually involves determining why the Remote Tools Client Agent did not install properly, why a connection could not be established, or why a remote support connection is not performing as expected.
The Remote Tools Client Agent installation information is written to the REMCTRL.LOG file in the windir\MS\SMS\LOGS\REMCTRL.LOG file. Review this file on the client computer if you suspect that the installation of the Remote Control Client Agent failed.
NOTE
The SMS 2.0 Release Notes contain a number of troubleshooting tips that should be read before implementing Remote Tools in a production network. For example, if the network is running a third-party remote control package, the Remote Tools Client Agent will not install. This tip and several workarounds are provided in the release notes. These release notes can be accessed from Systems Management Server Administrator Help online book.
To establish a connection between a viewer (the computer running the SMS Administrator console) and the host (the computer running the Remote Tools Client Agent), the two computers must have matching protocols. The client computer will accept a request for a remote support session using the default protocol, as specified in the properties of the Remote Tools Client Agent. The viewer computer will try its loaded protocols until a connection is established. If NetBIOS is part of or layered on top of the transport protocol, the remote session should be established with LANA0 on the client computer. If a remote session is not established with LANA0, change the client computer so that LANA0 is the same as the default protocol specified for the Remote Tools Client Agent. The NetBIOS-based remote session will be established over LANA0, the first attempted protocol, instead of the viewer computer trying additional protocols.
If the SMS Administrator console on the viewer is remote to the SQL Server, it must access the site database over a network so that a client computer (host) is selected to establish a remote support session.
The computer running the SMS Administrator console must be able to access the client computer through the physical medium (network or dial-up connection). For example, if RAS will be used to connect to a client computer, the RAS client (dial-out) software must be on the computer on which the remote session is initiated or a RAS Sender must be created to establish a connection with the remote network.
There are no status messages generated by Remote Tools components, nor are there any log files generated for status messages. Instead, Windows NT Security events are posted for sessions that are established between the viewing computer and a host computer running Windows NT/2000. Figure 14-19 shows a security event posted to the Windows NT Event Viewer's Security log. Auditing need not be enabled for these events to be posted to the Security log.
Figure 14-19. A Remote Tools security event code 5 appearing in the host computer's Windows NT Event Viewer's Security log.
The Windows NT Event Viewer Security log codes for Remote Tools are as follows:
1 = Remote reboot
2 = Chat session
3 = File transfer
4 = Remote execute
5 = Remote control session started (Figure 14-19)
6 = Remote control session ended
7 = Local user granted permission
If the viewer computer does not establish a remote session with the client computer on the first attempted protocol, use the Remote Control Settings Tool (RCCLIOPT.EXE) to change the default protocol on the client computer to the default protocol specified for the Remote Tools Client Agent. This tool can also be used to enable or disable multi-site Remote Tools security settings. If multi-site Remote Tools security is enabled, the most restrictive site settings apply.
If a client computer contains two or more NICs, the Remote Tools Client Agent attaches to the first NIC in the binding order. Use the Set NIC Tool (MULTINIC.EXE) to choose the NIC the Remote Tools Client Agent should bind to.
If a client computer is dynamically assigned an IP address when establishing a RAS connection, the Remote Tools Client Agent will load before the dial-up adapter IP address assignment is made. In order to connect to a client computer with a dynamically assigned RAS IP address, the Remote Tools Client Agent must be stopped and restarted. Use the Stop Remote Control (STOPRC.EXE) program to stop and restart the Remote Tools Client Agent after the client computer has made its RAS connection.
Software distribution is a complex task involving many SMS components and, potentially, many site systems and client computers. The most common causes of software distribution errors are discussed here.
The site server stores package instructions, advertisements, lookup files, package description files, and *.NAL files. These files do not require a great deal of disk capacity. However, the site server requires additional space if you choose to compress the package and store it on the site server and/or use the site server as a distribution point.
The distribution point requires enough space to store any uncompressed packages that are to be distributed.
The CAP requires space to store instructions, advertisements, lookup files, package description files, and *.NAL files. The amount of space required for storing these files is minimal compared to the space needed for package storage and distribution files.
Client computers to which the packages are targeted require enough disk capacity to run the package installation, but nothing additional.
Considerations
If a package is only distributed within a site, then there is no benefit to compressing the package files, except if you plan to store the package on the site server. Package compression is ideal for site-to-site package distribution.
If the site server has limited disk capacity, move the distribution point site system role to another computer or computers on the network.
If an advertisement does not appear on the client computer, or does not run properly, the following settings in the SMS Administrator console should be checked:
If this checkbox is selected, then the time given is for the GMT zone, not your local time zone.
The client computer must meet all of these requirements before a program installation will run.
Distribution Point and Client Computer Settings
Make sure a distribution point that the client computer can access is configured. For example, if you will be installing a package on a client computer running a native Novell redirector, make sure that a NetWare server accessible to the client computer is a distribution point for the package.
Verify that the client computer clock settings match the settings of the site database server. Client computers should regularly run a time synchronization procedure with the SQL Server.
Package distribution components report events in log files and to the status message system.
Status Messages
The System Status node in the SMS Administrator console contains a Package Status node. Read the specific package information to determine the summary status of a given package. Summary information includes: Targeted, Installed, Retrying, or Failed package status.
Access the Component Status node of the site to read messages reported by the Distribution Manager and the Offer Manager.
Server Log Files
The following log files provide insight into package distribution status and activity:
Distribution Manager prepares the package, creates the distribution shares, and copies packages files.
Offer Manager determines which client computers have not yet received this advertisement and adds these new client computers to existing *.LKP files. Offer Manager then creates instruction files.
Several files are created to support distribution of packages and advertisements. If an advertisement does not appear on a client computer, review the following files in the smsdir\INBOXES\OFFERINF.BOX directory on the site server:
The instruction file shows advertisements and collections.
The offer file includes advertisement, package number, program, collection, and site code.
This lookup file shows a globally unique identifier (GUID) of target client computers and an *.INS instruction file name. Review this lookup file if your advertisement is targeted at client computers.
This lookup file shows a target of users and an *.INS file name. Review this lookup file if your advertisement is targeted at user accounts.
This lookup file shows a target of groups and an *.INS file name. Review this lookup file if your advertisement is targeted at groups. Also, check to verify that the user is a member of the targeted group.
Review the following files in the smsdir\INBOXES\PKGINFO.BOX on the site server and CAP_sitecode\PKGINFO.BOX on the CAP:
Network abstraction layer file shows distribution point and share.
Package file shows package and program properties.
This is the icon that appears in APM.
CAP_ sitecode\OFFERINF.BOX on the CAP also stores a copy of:
The package itself is stored in SMSPKGx\packageID on the distribution point (x is the drive on which the package is stored).
Advertisement distribution components report events in log files and to the status message system.
Status Messages
The System Status node in the SMS Administrator console contains an Advertisement Status node. Read the specific advertisement information to determine the summary status of a given advertisement. Summary information includes: Received, Failures, Programs Started, Program Errors, and Program Success.
Available Programs Monitor Log Files
Information on program execution is stored in a variety of log files on the client computer. The following activity is tracked by these log files:
Schedules and executes an advertised program.
Locates NAL and PKG files on site systems.
Reads offer files for GUIDs (unique identifiers on client computers).
Reads lookup files for targeted users.
Reads lookup files for targeted user groups.
Tracks events related to scheduling the run time and connecting to the CAP during program execution.
If you suspect problems with a package (*.PKG) or offer file (*.OFR), use the Advertisement Information Tool (ADVINFO.EXE) to extract header information from these file types.
To determine what background tasks the Advertised Program Manager is completing on the client computer, run the APM Spy Tool (APMSPY.EXE) on the client computer. This tool runs only on Windows 32-bit client computers.
If you need to determine where packages are located, or if you want to verify that command line switches are being sent with a program, run the Test Application tool (TESTAPP.EXE). When TESTAPP runs, it displays the exact location from which it was run as well as the command line that invoked it. You can create a package and program containing TESTAPP and then distribute it with an advertisement. Then, from a client computer, run the advertised program to determine the distribution point and command line used to run Test Application.