There are several SMS services that can use Windows NT® user accounts and passwords and can be managed through the Windows NT Control Panel. By default, the following services run on all SMS site servers:
Other SMS services include Bootstrap, SNA Receiver, SNMP Trap Receiver, and Inventory Agent for OS/2. Bootstrap runs temporarily on the secondary site servers during SMS installation. The Inventory Agent for OS/2 runs on LAN Manager for OS/2 logon servers.
The Hierarchy Manager monitors the site database for changes to the configuration for a site or any of its subsites. If the Hierarchy Manager detects a change in a site's proposed configuration, it creates a site control file that contains all proposed configurations for a site and sends it to the site. If you make site configuration changes using the SMS Administrator, the Hierarchy Manager must be running so it can create a site control file to make changes to that site. The Hierarchy Manager exists only in primary sites.
If changes are proposed at the primary site, its control file passes directly to the Site Configuration Manager for that site, to record the changes.
The Hierarchy Manager includes several commands for diagnosing and fixing sites. You can use PREINST.EXE, in the SMS\SITE.SRV\platform.BIN directory, to pass commands to the Hierarchy Manager while it is running. The syntax for PREINST.EXE is as follows:
preinst options
Where options are:
/DUMP
Writes site control images for all sites to the SMS\SITE.SRV\SITECFG.BOX directory.
/SYNCPARENT
Forces all site control images in the site database simultaneously up to the parent for the current site and all its subsites. Use this option when sites are out of synchronization due to time lags or job failures.
/DELSITE:{sitecode, parentsite}
Deletes incorrectly removed sites. Use this option if you removed a site before detaching it from its parent site. Note that the braces are required.
The sitecode parameter specifies the site to delete, and parentsite is the site code of the parent site for the site you are deleting. When you specify parentsite, it prevents unwanted deletion of a site previously relocated under a different parent site in another part of the site tree. For example, typing preinst /DELSITE:{CHL,PAR} deletes CHL only if it has a parent site of PAR. This transaction proceeds up the site hierarchy to all parent sites for the current site.
Note This instruction does not send a remove job to the target site. It merely removes the site and its SMS domains from the local site database and propagates the change up the site hierarchy.
/DEINSTALL:{sitecode}
Sends a job to remove a specific secondary site. The sitecode parameter specifies the site to remove from the site hierarchy. Note that the braces are required.
If you want to remove a secondary site from the hierarchy, you should first try to remove it using the SMS Administrator. If that fails for any reason, use this option.
/UPGRADE:{sitecode}
Selectively upgrades a specific secondary site. The sitecode parameter specifies the site to upgrade. If a global upgrade fails after specifying a system upgrade, use this option for the failed sites. Note that the curly braces are required.
The Site Configuration Manager monitors and controls the configuration of the site. The Site Configuration Manager uses the site configuration parameters in the site control files created by the Hierarchy Manager. If the site's configuration control file contains changes, the Site Configuration Manager implements the changes.
The Site Configuration Manager exists in both primary and secondary sites. It automatically restarts after the site server restarts, and it starts all other services.
When you add a Windows NT or LAN Manager domain to the site, the Site Configuration Manager:
If you make site configuration changes using the SMS Administrator, the Site Configuration Manager must be running to implement the changes to the site.
The Site Configuration Manager uses values set in the Windows NT registry to determine how frequently to monitor parts of the site. You can modify these values directly in the Windows NT registry using the Windows NT Registry Editor. These values are located in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_CONFIG_MANAGER registry key. You can set the following values:
Logon Script Configuration Interval
The frequency (in minutes) that the Site Configuration Manager checks the logon script configuration for all SMS domains in the site. By default, the interval is 1440 minutes (24 hours). This interval is checked only during the processing of a site control file or at the start of the next watchdog cycle.
Restart After Shutdown Delay
Determines the duration (in minutes) that the Site Configuration Manager waits before restarting SMS services at a site after the site server and the SMS system have been restarted. The startup delay is five minutes. This is the length of time that the Site Configuration Manager waits before activating the first cycle. Subsequent cycles work from the watchdog interval.
Site Configuration Reporting Interval
The frequency (in minutes) that the Site Configuration Manager writes a new site control file to report its current configuration. By default, the interval is 1440 minutes (24 hours). Note that this interval is checked only during the processing of a site control file or at the start of the next watchdog cycle.
User Group Reporting Interval
The frequency (in minutes) that the Site Configuration Manager retrieves the list of user groups from all SMS domains in the site and writes a management information format (MIF) file to report the user groups to the site database. By default, the interval is 1440 minutes (24 hours). This interval is checked only during the processing of a site control file or at the start of the next watchdog cycle.
Watchdogging Interval
The frequency (in minutes) that the Site Configuration Manager checks for new SMS logon servers, stopped services or components, or if any of the preceding reporting or configuration intervals are up. By default, the interval is 120 minutes (2 hours). This interval resets itself to be 24 times the service response polling interval whenever the service's response rate is changed. The response polling intervals are set by the Service Response rates for the Maintenance Manager, Site Configuration Manager, and Despooler. For more information, see SMS version 1.2 Installation and Configuration, Chapter 5.
You can trigger a specific task by sending a service control code to the Site Configuration Manager using the SMS utility program SENDCODE.EXE. The syntax for SENDCODE.EXE is as follows:
sendcode sms_site_config_manager svccode
The following table lists the values for svccode supported by the Site Configuration Manager.
Name | svccode | Description |
Memtrack_on | 128 | Starts memory allocation tracking. |
Memtrack_off | 129 | Stops memory allocation tracking. |
Memtrack_dump | 130 | Dumps the memory allocation data to ALERTER.MEM, APPMGR.MEM, HMAN.MEM, SCMANMEM.LOG, SCHED.MEM, and SMSEXEC.MEM in the root directory. |
"Net pause" toggle | 132 | Toggles the net pause support on and off for the Site Configuration Manager. |
Watchdog | 192 | Initiates a normal watchdog cycle (verifies current installation, checks for new SMS logon servers, restarts any stopped components, and so on). |
Status | 193 | Initiates a watchdog cycle then writes a status file (.CT2). |
Upgrade | 194 | Initiates a watchdog cycle but treats it as an upgrade. To be most effective, this should be preceded by shutdown. |
Usergroups | 195 | Initiates a watchdog cycle and writes a user group MIF file. |
Scripts | 196 | Initiates a watchdog cycle and modifies logon scripts only if the Automatically Configure Workstation Logon Scripts and the Use All Detected Servers options are enabled. |
Shutdown | 234 | Stops and removes services in the site (on the site server and all SMS logon and helper servers). |
Deinstall | 255 | Initiates a site removal (this removes all components, as well as files and shares, from the site server and all SMS logon and helper servers). |
The Inventory Agent runs on OS/2 and Windows NT-based servers. The Inventory Agent performs software and hardware inventory on the server, except NetWare servers (Maintenance Manager performs inventory on NetWare logon servers).
The Inventory Agent is started by the Site Configuration Manager during SMS installation on domain controllers for domains which SMS controls. The Inventory Agent wakes up at an interval specified by the Inventory Agent Service Interval in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_MAINTENANCE_MANAGER registry key. The default wake-up interval is 24 hours (1440 minutes). When it wakes up, the Inventory Agent checks software and hardware scan interval settings from the local DOMAIN.INI file. By default, scan interval settings for both hardware and software are 7 (days), indicating that inventory should once every seven days. To change the software and hardware scan interval settings, use the Site Properties dialog box in the SMS Administrator.
The Package Command Manager is installed on all Windows NT-based servers (site and SMS logon servers) in an SMS hierarchy. The Package Command Manager service (PCMSVC32.EXE) provides unattended package installation — a user does not have to be logged on to a server running Windows NT for package installation to occur. However, the package must be configured for automated installation in background mode.
If a package arrives at a server running Windows NT that is also running the Package Command Manager (PCMWIN32.EXE file), the package is handled by the Package Command Manager.
The Package Command Manager initially wakes up once every 60 seconds to check the package polling interval. You set the polling interval in the Site Properties dialog box (under Clients) in the SMS Administrator. The default is 60 minutes. If the polling interval has elapsed, the Package Command Manager checks the package instruction file to see if the time and date have changed. If the polling interval has changed, the Package Command Manager resets the polling interval counter to the new value, and waits until that many minutes have passed before polling again. The Package Command Manager Service is limited to package installations that do not require user input and do not display windows on the server. The polling interval is set in the SMS.INI file.
The Bootstrap sets up a Windows NT-based server as a secondary site. After the Hierarchy Manager at the primary site detects the request to add a secondary site, it initiates a job to the site to install the SMS installation directory on the secondary site server. It also tells the senders (LAN or RAS) to install and start the Bootstrap from that directory.
When the primary site sends a package containing site components to the secondary site, the Bootstrap:
After you add an SNA Sender to a site using the SMS Administrator, the SNA Receiver is activated by the Site Configuration Manager (the SNA Sender is started as part of the SMS Executive). The SNA Receiver processes information that has been sent from an SNA Sender at a remote site.
The Client Configuration Manager exists in both primary and secondary sites and is used by SMS Client Setup to install, upgrade, and remove SMS service components on computers running Windows NT. When SMS Client Setup needs to perform actions that may require special access on a computer running Windows NT, it posts a client configuration request to the Client Configuration Manager. The Client Configuration Manager then carries out the request. The Client Configuration Manager runs on all SMS logon servers running Windows NT Server.
The Client Configuration Manager configures the following components on Windows NT-based computers running as SMS clients:
Note
The Client Configuration Manager uses the SMS Service Account to install these components on computers running the Windows NT operating system. The service account must have administrative privileges on the computers or Client Configuration Manager will not be able to install the components. To grant administrative privileges on clients running Windows NT, do one of the following:
The following Client Configuration Manager parameters are maintained in the site server registry, in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_CLIENT_CONFIG_MANAGER registry key.
Deinstall All Client Services
When this value is set to Yes, it specifies that each client configuration request (CCR) be treated as a request to remove all of the SMS service-based client components. The default value is No.
Prompt for Restart
When this value is set to 0, the Client Monitor does not prompt the user at the client to restart the computer after installing software. The default value is 1, and it is not recommended that you change this value.
Ignore These Event IDs
Values specified in this parameter represent SMS event IDs that should not be reported to the Windows NT Event Manager. You can specify the following values:
402
Event that occurs when the Client Configuration Manager is unable to connect to a client. This event occurs when the SMS service account does not have administrative rights on the client, and when the client cannot be found (because it is turned off for more than seven consecutive days, it no longer exists, or its computer name has changed).
403
Event that occurs when the Client Configuration Manager succeeded in connecting to the client but encountered an error while attempting to install the client components.
When you encounter many of these events, increase the Error Reporting Delay and Retry Duration values in the site server registry (under the Retry queue) to allow the Client Configuration Manager to retry the client for longer than the default 24 hours before reporting the problem.
404
Event that appears when an excessive number of CCRs (as defined by the Machine Count Warning key in the Retry queue) appear in either the incoming or retry queues on each logon server. This event appears the first time the queue rises above the threshold number of events, and when the number of CCRs drops back below the threshold numbers.
These events indicate a backlog of clients to process. If you see an event for the incoming queue, the Client Configuration Managers running on the logon servers are not keeping up with the demand, and you need to consider performance and tuning issues for the site.
Only Report These Event IDs When Fatal
Values specified in this parameter represent SMS event IDs that should be reported to the Windows NT Event Manager only after they are "fatal," which means that the Client Configuration has stopped retrying to connect to the client and install or maintain client components. This value can be 402 or 403.
The SNMP Trap Receiver makes simple network management protocol (SNMP) trap information available to SMS. The SNMP Trap Receiver is disabled (no traps are received by or stored in the database) by default. You configure the SNMP Trap Receiver using the Site Properties dialog box (under SNMP Traps) in the SMS Administrator.
The SNMP Trap Receiver filters traps according to conditions you set. You can set trap filters based on the trap IP address, enterprise ID, Windows NT event source (for traps generated by the Event to Trap Translator), generic trap type, or specific trap ID. Filtered traps are either written to the database or discarded.
If a trap meets the filter conditions, SMS writes the trap data to the database. However, to minimize the impact on the database, SMS only writes the first 25 varbinds in the trap to the database. SMS also limits the size of each varbind. If any of the varbinds exceed the limit, SMS rejects the trap data. The data is not written to the database; a Windows NT event is created to log the failure instead.
The SNMP Trap Receiver can receive traps from any suitable SNMP source, including (but not limited to) the Event to Trap Translator. Traps generated by the Event to Trap Translator display the Windows NT event source name for the event that triggered the trap.
The SNMP Trap Receiver runs at all primary sites. It stores SNMP trap data in the database as a new architecture. This means that trap data can be viewed, queried against, and used to generate SMS alerts.
The SMS Executive serves as a master controller of several SMS components. The SMS Executive is started by the Site Configuration Manager, during SMS services startup and any other time that the SMS Executive is not running.
The SMS Executive reads the Windows NT registry to determine which components to start on SMS site, logon, and helper servers. By default, it starts the following components on the site server:
Each of these components is discussed in the following sections.
The Maintenance Manager installs and maintains the SMS client components on the SMS logon servers in a site. It replicates client components and configuration information to SMS logon servers within the site and retrieves inventory and status files. The Maintenance Manager is installed in every primary and secondary site server. The Site Configuration Manager sets up the registry information and necessary directory structures that the Maintenance Manager needs to run properly.
When a logon server is added to the SMS system, the Maintenance Manager replicates client files, such as the Inventory Agent, Program Group Control, and Package Command Manager programs, to the logon server. The Maintenance Manager also monitors the site server for any changes in configuration. If a change is detected, the Maintenance Manager replicates these changes to all of the SMS logon servers within the site. The Maintenance Manager also periodically scans all the logon servers and updates missing files.
In addition, the Maintenance Manager:
The Inventory Processor exists in both primary and secondary site servers. It creates the MIF files from the raw binary inventory information returned by the Inventory Agents for Windows NT and MS-DOS® and reads the MIF files returned by the Inventory Agents for OS/2 and Macintosh clients. The Inventory Processor creates a history file for the Windows NT, Apple Macintosh, and OS/2 platforms. MIF files also track history, unless they are created with an NHM extension. When a new MIF file is received, the Inventory Processor compares it with the history file and writes changes to an inventory file called a Binary MIF file. (If this is the first MIF file, the Inventory Processor writes a complete Binary MIF inventory file.)
The Inventory Processor also converts MIF files in the ISVMIF directory into Binary MIF files. ISVMIFs are files generated by independent software vendors (ISVs), which report objects such as computers that have custom architectures. The ISVMIF directory also contains MIF files from OS/2 and Macintosh clients.
The Site Reporter maintains a queue of MIF files containing inventory, job status, or event information. At child sites, the Site Reporter periodically creates a system job to send these files to the parent site. The queue length that triggers when the files are sent is determined by various registry settings. The Site Reporter keeps track of the different categories of MIF files that arrive for it and compares the category with a registry entry that indicates how long that type of MIF file should be allowed to wait. When any MIF file reaches its maximum wait time, all MIF files for that site are bundled and sent. The registry entries for the Site Reporter are under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_REPORTER key and are maintained by the Site Configuration Manager.
The Site Reporter also deletes MIF files that are not reported to parent sites, either because there is no parent site or because the MIF file is normally not reported to a parent site (such as a job detail MIF file).
The Site Reporter exists in both primary and secondary sites.
The Scheduler detects pending jobs and creates auxiliary files that enable jobs to be processed. This includes jobs that an administrator starts, such as a Run Command On Workstation job, as well as system jobs from system processes such as the Site Reporter.
When the Scheduler detects a job, it:
The Scheduler also manages send requests. It examines send requests for a specific sender's outbox and schedules them on a priority basis. For example, it might suspend a low priority job in progress and substitute a higher priority send request. After the higher priority job runs, it restarts the previous job.
The Scheduler runs on the site server, but you can use the Services button in the Site Properties dialog box in the SMS Administrator to move it to a helper server. The Scheduler exists in both primary and secondary sites.
The Despooler watches the SITE.SRV\DESPOOLR.BOX\RECEIVE directory for despooler instruction files and compressed packages created by the Scheduler. The instructions and packages can come from the local site or from another site. The Despooler reads the instruction file and uses the instructions to decompress the package files and determine how to process them. For example, it decompresses inventory files and moves them to the SMS\SITE.SRV \DATALOAD.BOX\DELTAMIF.COL directory so they can be processed by the Inventory Data Loader, which then updates the site database.
Note
Specify the drive that the Despooler will use for temporary files in the Preferred Drive For Temp Directory setting for the Despooler registry key. This value is blank by default, which directs SMS to use its drive. The SMS Drive Minimum Free Space in Mbytes option specifies that SMS look for a drive of the configured value (default value is 100 MB). If the free disk space on the SMS drive is less than 100 MB, the Despooler will start looking for other drives on which to place the package.
If there are two package shares, the Despooler will pick the drive (share) with the most free disk space until both of them have less than 100 MB of free space. Then it attempts to find a third drive with more free disk space. The Despooler will never place the same package on two shares even if they came in different jobs. To determine where packages are stored, look under the SMS\Components\SMS_Despooler\Transfer Package registry key.
For Run Command On Workstation jobs, the Despooler updates the Package Command Manager instruction files for all target computers in the site. After the package has been installed, the Despooler reports the job's status to the site where the job was created. It also logs an event to the site server's Windows NT event log if there is a failure.
The Despooler initially runs on the site server but can be moved to a helper server. The Despooler exists in both primary and secondary sites.
The Inventory Data Loader updates computer inventory, events, job location, and user group and job status information in the database. When an inventory MIF file arrives from a computer, the Inventory Data Loader attempts to locate the computer in the site database based on its SMS ID and key attributes in its identification group. If the MIF file contains instructions to update an object, such as a client's identification group that is missing from the database, the Inventory Data Loader initiates a resync command to update the database. The Inventory Data Loader processes job status, user group, event, and package location information, and then updates the database directly (no resync is necessary).
In SMS version 1.2, each of the main architectures creates MIF files with different extensions, as shown in the following table:
MIF file name extension | Contains |
.EMF | Event data |
.JMF | Job status data |
.UMF | User group data |
.PMF | Package location data |
All other MIF files are processed by the 'misc' processing thread, including MIF files from sites that are running earlier versions of SMS. The Inventory Data Loader processes the different MIF files in parallel.
The Inventory Data Loader:
Note
If the Inventory Data Loader is stopped before it has finished processing a MIF file, that file is renamed with an X at the beginning of the file name (for example, X0712.EMF). When the file has three X's at the beginning of the file name, it is considered a corrupt MIF file and is moved to the DELTAMIF.COL\BADMIFS directory.
If you stop and restart SMS Executive often, you might end up with many files in the DELTAMIF.COL\BADMIFS directory that would otherwise process normally.
The Inventory Data Loader is also responsible for:
The Inventory Data Loader initially runs on the site server but can be moved to a helper server. The Inventory Data Loader exists only in primary sites.
To enable each site to communicate with its parent sites and child sites, every site must have one or more senders. A sender is an SMS component used to transmit instructions and data from one site to another (such as reporting inventory information or installing software on clients in another site).
There are six types of SMS senders:
Each type of sender uses a specific type of communications link. The RAS Senders require a Remote Access Service (RAS) server, and the SNA Senders require the SNA Server communications service.
The sender monitors its outbox directory (the location for files waiting to be sent to another site) for a valid send request. When it detects a valid request, the sender connects to the target site and transfers the compressed files and its despooler instruction file to the destination site.
The LAN Sender runs on the site server but can be moved to a helper server. Use the SMS Administrator to add other senders. The sender exists in both primary and secondary sites.
The Applications Manager copies package and program group configuration information from the site database to other components in the site and to the sites beneath it in the site hierarchy.
When you create, modify, or delete packages or program groups using the SMS Administrator, the changes are added to the site database. When the Applications Manager detects a change to a package or program group, the new configuration information is updated in the Program Group Control database for the site. The Program Group Control database is a set of configuration files used by the Applications Control program for each SMS Windows®-based client.
The Applications Manager uses a system job to replicate package and program group data to child sites. Each child site then generates its own copy of the Program Group Control database. The Applications Manager also uses a system job to add data to the database from parent sites.
The Applications Manager exists in both primary and secondary sites.
The Alerter monitors the database for new alerts and any changes to existing alerts. It runs queries associated with alerts and compares query results with alert criteria.
If an alert's trigger condition becomes true, the Alerter performs any or all of the following actions:
Note
The Alerter cannot run a command that writes to a window.
The Alerter exists only in primary sites.