Systems Management Server 1.2

SMS performs 4 main functions:
  • Collecting hardware and software inventory information
  • Distributing and Installing Software
  • Sharing network applications
  • Troubleshooting hardware and software problems

SMS Heirarchy
Primary site This site has a SQL Server and owns the database for all the computers in the site and any sites below in the hierarchy. The primary site located at the top is called central site. Unlimited number of subsites can exist below a primary site. Also called a Parent site (if it has sites below it).
Secondary site A site without an SQL Server; reports to the primary site direct above it in the hierarchy. Must be created, configured and administrated by one of the primary sites above in the hierarchy. Cannot have subsites below it. Also called a child site.
Site server
  • Runs SMS server services
  • The primary owns the database (secondary's reports to the primary site server).
  • Inventory collection point.
  • Runs on WinNT server 3.5 service pack 3 or 4.0 as a domain controller.
  • Maintains copies of packages and configuration information.
    		•
    Logon server
  • Any server capable of validating a user account.
  • Is the installation source for SMS client installation.
  • Clients place here collected inventory info and status of software distribution.
  • Clients read from here configuration information including inventory collection rules, information about available software and network configurations.
    		•
    Distribution server
  • Supplies available software to clients.
  • Distribution servers can be added by SMS Administrator utility.
    		•
    Helper server
  • Runs some of the SMS server services to off-load the site server.
  • Runs on WinNT server 3.5 service pack 3 or 4.0 as a domain controller.
    		•

    Sites communicate with each other by using senders. These senders transmits instructions and data from one site to another.

    There are 3 types of senders:

    • LAN sender - Over a normal LAN using the WinNT server redirector an a LAN protocol.
    • RAS sender - Over ISDN, X25 or modems using WinNT server Remote Access Service (RAS).
    • SNS sender - Over existing SNA network using APPC LU 6.2 sessions.

    Senders are designed to handle interruptions and data transfer errors.

    Multiple senders can be configured for fault tolerance.

    Before a site can communicate it needs an address and an outbox in which to place outgoing files. There are six outboxes to define: 1 for LAN, 2 for SNA, 3 for RAS. Outboxes can be scheduled when to send the data or to receive specific jobs (example High priority).

    Implementing a RAS sender requires RAS services to be installed on each site.

    Site Control Files:

    • SITECTRL.CT0 - Master site control file; contains backup of most recent configuration.
    • SITECTRL.CT1 - Generated by HM using input from either Setup program or SMS Administrator.
    • SITECTRL.CT2 - Generated by SCM after processing an xxxxxx.ct1 file and reflect actual, or current configuration.

    Setting up a primary site
    Before setting up a primary site there must be a SQL server available. When the SQL server is configured for Standard security mode, you must have a SQL login ID to create and access a database.

    After logging into a new SQL Server, create an account with the following permissions:

    • Create Database
    • Dump Database
    • Dump Transaction

    The permissions must be applied on the master database. This account is used by SMS to access the database.

    If the SQL server is configured for Integrated or Mixed security mode, NT user accounts can be used to login to the SMS database.

    A SQL Server device is pre-allocated hard disk space. SMS needs two devices: one for the site database and one for the transaction log.

    If SMS and SQL are on the same computer then SMS setup can create the database and log devices. On seperate computers the SQL administrator must create them by using SQL Enterprise Manager.

    SMS requires a minimum of 20 user connections (default=5) during installation. Allow 20-35 Kb/computer in the SMS database for data and set the transaction log device to be at least 10% of the data size.

  • TIMESERV.EXE - Used to synchronize time between SMS and SQL servers.

    • The SMS service account created on the site server must have Administrator priveleges and the Log on as a service advanced user right. Account must be valid on all servers (incl. SQL) with which SMS interact. Create this account before installing SMS.

    On Novell servers the SMS account must have supervisor equivalent rights and must have the same name and password as those of the SMS service account on the site server.

    Configure SMS database:

    SQL server name     Name of the server SQL is installed
    SQL login SQL admin account name (default=sa)
    Database name Name assigned to SMS database
    Database device Name of the device to store the SMS database (default=SMSdata)
    Log device Name of the device to store the SMS transaction log (default=SMSlog)
    When SMS is on the same computer as SQL, use the Device Creation button to specify the physical path and device size.

    Configure Primary Site Server:

    Site Code Three-character code to identify this site (must be unique in the entire SMS hierarchy).
    Site Name A descriptive label which appears in Administrator Sites window (recommended : site code)
    Site Server Must be the current computer.
    Site Domain Domain name of the site server : must be the current domain.
    Automatically detect    
    all logon servers    		 Will enumerate and configure all logon servers in the domain. Must be selected to configure logon scripts automatically for clients in the domain.

    It contains the following utilities:

    • SMS Administrator - To configure SMS and view database

    • SMS Network Monitor - Provide network tracing features

    • SMS Service Manager - Allows administrator to stop, start and trace SMS sevices

    • SMS MIF form generator - Allows administrator to create custem data forms for the database

    • SMS Setup - Provide modification for the current SMS installation including removing the site server

    • SMS Books Online - Contains SMS documentation

    • SMS Release Notes - Last-minute info for SMS

    • SMS Database Manager - Allows administrator to delete special items from SMS database, such as collected files

    • SMS Sender Manager - Allows administrator to configure limits on senders such as % of bandwith a sender can use

    • SMS SQL View Generator - Allows administrator to generate views of the SMS database that can be accessed by ODBC apps

    The Installation process also changes two locations in the registry Hkey_Local_Machine and creates three shared directories:

    • SMS_SHR - On the logon servers (points to Sms\logon.srv); main interface between client and SMS server.
    • SMS_SHRd - Points to SMS installation (d= SMS installation drive); used by SMS to communicate with each other.
    • SMS_SITE - Points to \ SMS\Site.srv\Despoolr.box\Receive. A remote site connects here when transmitting data.

    System Managment Server Services
  • SMS_HIERARCHY_MANAGER - Monitors SMS database for configuration change requests and update it after configuration is complete.

  • SMS_SITE_CONFIG_MANAGER - Configures the site according to information received from SMS_HIERARCHY_MANAGER.

  • SMS_EXECUTIVE - This is the main SMS service and includes the following threads:
    • Scheduler - Schedules jobs for processing and compresses software for distribution
    • Despooler - Decompress packages and instruction files at each side
    • Senders - Manage communication between sides
    • Maintenance Manager - Passes client config information to logon servers and collects inventory from logon servers
    • Inventory Data Loader - Adds inventory data to the database
    • Inventory Processor - Maintains inventory history
    • Alerter - Provides alert service for SMS
    • Application Manager - Monitors database for software packages
    • Site Reporter - Prepares inventory data to be passed to the parent site
    • Trap Filter - Filters SNMP traps

  • SMS_INVENTORY_AGENT_NT - Creates and collects inventory at computers running Windows NT.

  • SMS_PACKAGE_COMMAND_MAN - Receives packages at computers running Windows NT Server with appropriate configuration settings.

  • SMS_CLIENT_CONFIG_MANAGER - Installs service-based components on Windows NT based computers.

  • SMS Remote Control Agent - Windows NT Remote Control Agent for remote troubleshooting.

    The Hierarchy Manager, Site Configuration Manager and the WinNT Remote Control Agent are started automatically. The Site Configuration Manager starts the remaining SMS services. They all appear in the Services icon in the Control Panel.

    • SMS Client
  • Package Command Manager - Runs a command from a package from a distribution server.

  • Program Group Control - Runs shared applications from a distribution server.

  • Remote Troubleshooting - Allows remote control and diagnostics.

  • MIF Entry Program - Allows you to add customized information to the SMS inventory

    • By selecting the Automatically Configure Workstation Logon Scripts check box administrators can enable automatic inventory collection at client computers. Modifies only logon scripts for users that have no existing logon script or have logon scripts with an extension (.bat, .scr).

    SMSLS.BAT - is a batch file that starts the collection.

    Directory Replication distributes the logon scripts to NETLOGON directory and to other logon servers.

    To install SMS on a client system, either:
      1. Copy logon files to NETLOGON share
      2. Add Smsls.bat to logon script of specific users
         -OR-
      1. Connect a user to the SMS_SHR directory
      2. Run Runsms.bat

    SMSLS is used for automatic installation via login script, and RUNSMS is used for manual installations.

  • PKG_16.CFG - Software scanning rule files

  • SMS.INI - Hidden file in the root directory of the first local drive containing configuration information the for Inventory Agent and other SMS client applications.

  • DOMAIN.INI - Template for SMS.INI, resides on all logon servers and is used by all clients.

  • SMS unique ID - Unique number to identify the client. Identification only occurs during initial installation and inventory collection of the client.

  • DEINSTALL.BAT - Used to uninstall SMS Client software.

    • SMS Events
    SMS is designed to report events to the WindowsNT Applications Event Log and the SMS database.

    Events in the SMS database can be viewed by Event Viewre and the SMS Administrator Events window.

    Child sites update their own database and then forward the MIF files to their parents.

    SQL errors can be viewed the messages in the SQL Server Messages window of the SMS administrator.

    SMS server logs shows process operations. These logs are ASCII files which can be viewed with SMSTRACE in realmode or with TRACER.EXE.

    Help Desk
    Client must enable help desk functions prior to use.

    Remote agent files:

    • DOS - USERTSR.EXE/USERIPX.EXE
    • Windows - WUSER.EXE
    • Windows NT - WUSER2.EXE

    Requirements for using Helpdesk utilities are:

    • Client must exist in Site Inventory
    • Remote Agent must be started on the client
    • Client must allow access to viewer
    • Server and client must use common protocol

    The help desk file transfer utility is used as the quickest way to transfer files to a client.

    Inventory
    Inventory is collected by the Inventory Agent:
    • MS-DOS, Win3.x, Win95 - INVDOS.EXE
    • WinNT - INVWIN32.EXE
    • OS/2 - INVOS2.EXE
    • Macintosh System 7 - INVMAC

    For all clients, except Macintosh, a connection is made to a logon server and the appropriate Agent is run.

    Inventory files have a .RAW extension, excluding Macintosh and OS/2. Macintosh and OS/2 produces standard .MIF files and place them in the Logon\Isvmif.box directory on the Logon server.

    Software auditing can be implemented by compiling AUDIT.RUL with RUL2CFG.BAT. This creates AUDIT.CFG, which can be used through the Package Manager.

    During detection hardware failures are copied to the SMS.INI file under the [WorkstationStatus] section.

    The inventory files (.RAW) from the client are placed in the Logon.srv\Inventory.box directory on the logon server.

    The Maintenance Manager running at the site server collects the inventory data from the \Logon.srv and copies these files to the equivalent \Site.srv directories.

    INVDOS /F can be used to force an inventory.

    Passing inventory to siteserver:

      1. Inventory agent collects and copies results to logon server.
      2. Maintenance Manager moves data and status files from logon servers to site server.
      3. Inventory Processor preprocesses the inventory data, compares it against history files for each computer and produces a file (Delta.mif) which contains only the changes for the Inventory Data Loader.
      4. Dataloader compares new inventory list with computers in database to flag sync errors such as duplicate computers, updates the SMS database and produces an output file for the Site Reporter Service if inventory must be forwarded to a parent site.
      5. Site Reporter receives file from Inventory Data Loader and creates a job that passes the inventory to the parent site (using the Scheduler, a sender, and the Despooler).

    Backup and Restoration
    Backup and restore the SMS database by creating a backup device with the SQL Enterprise manager. After creation select the SMS database and proceed with the backup.

    The SMS registry key and the master site control file (Sitectrl.ct0) need to be restored to return the SMS site to a known configuration.

    SMS Jobs
  • System Jobs - Tasks for installing a secondary site or passing inventory to a parent site.

  • Administrator-Initiated Jobs:
    • Run Command on Workstation - Distributes software packages to, or runs commands on, clients.
    • Share Package on Server - Distributes shared applications to distribution servers and creates program groups for participating users.
    • Remove Package from Server - Used to remove workstations or sharing packages from servers.

  • SMS Job Processes:
    • Scheduler - Monitors SMS database for jobs, schedules jobs, and chooses and monitors senders.
    • Senders - Transfers packages and instruction files.
    • Despooler - Receives and decompresses packages and instruction files. Carries out commands in the instruction files at the destination site.

    Once a job is configured the Scheduler and the Despooler carry out the job.

    The following steps occur:

      1. Job is stored in SMS database.
      2. Scheduler monitors the SMS database for jobs that need to be activated. Once a job is activated, Scheduler compresses the package for delivery and places it in a sender's outbox.
      3. Senders pass the package to the target site servers.
      4. Despooler at each target site decompresses and stores a master copy of the package.
      5. The decompressed package files are placed on the specified distribution servers.
      6. Target computers receive either the new command (for Run command on Workstation) or displays the new Program Manager group (for Share Package on Server Jobs).

    Job status is read from the SMS database, and is not real-time.

    SMS finds the drive with the most free space and places the packages in that drive's \SMS_pkgx directory (x=drive letter).

    Scheduler
    The Scheduler manages the process of sending the job's data to the job's destination sites.

    The Scheduler selects a sender, prepares the package, creates the instruction file, and places the data in the \Site.src\Sender.box\Tosend directory.

  • Send Request file (*.SRQ) - Contains instructions for the sender to connect to the destination site for data transfer.

    If a job failed to send for seven days the job is cancelled and the .SRQ files are deleted. The job status is set to Failed.

    After the job successfully completes, the .SRQ and instruction files are deleted.

    The package will stay in the \Sender.box\Tosend dir until deleted from the Packages window in the SMS Administrator.

    • Despooler
    The Despooler receives, decompresses and distributes the packages.

    The compressed package is copied to the \Despoolr.box\Store directory.

    The Despooler keeps a list of package locations in the WinNT registry. It does not use the SMS database.

    For system jobs, the Despooler decompresses the instruction file (i.00), carries out the instructions and decompresses the package in the appropriate location (such as \Sms\Site.srv\Dataload.box\Deltamif.col) for inventory from a child site.

    Updating a job's status is handled by a DELT.MIF file created by the Despooler.

    Package Command Manager
    PCM runs Workstation Job Commands that administrators have sent to the client.

    PCM runs any command that the user selects and mandatory commands.

    Packet Command Manager can be set to poll every 5 to 1440 minutes.

    Package command manager starts automatically on Win3.x, Win95, WinNt (Pcmwin16.exe and Pcmwin32.exe); it is placed in the SMS group and runs as a background process. Appears when a new command is available.

    On MS-DOS machines PCMDOS.EXE must be started manually. PCMDOS.EXE takes 420k conventional memory to execute.

    On Mac PCMMAC starts after the inventory agent is started.

    When running the PCM with commands that will restart Windows, use the SynchronousSystemExitRequired setting in the .PDF file to cause the PCM to mark a job as complete before the client restarts.

    To run PCM in debug mode, remove PCM from the \MS\SMS\DATA\SMSRUN16.INI file under [Startup] section, restart Windows and start PCM using the /DEBUG switch.

    Shared Applications
    Shared applications support Win3.x, Win95, WinNT

    Applications are assigned to network operating system user groups. Groups are added to SMS database by Site Configuration Manager.

    Valid groups are WinNT Server global (not local) groups, LAN Manager 2.x user groups and Netware user groups.

    Site Configuration Manager monitors all logon servers within the site. It verifies directories, updates logon scripts, and reads the groups from each server at periodic intervals.

    After the interval has elapsed, Site Configuration Manager will:

    • Enumerate the supported groups for supported OS in each domain. For each domain, the domain that it trusts will be enumerated for global user groups.
    • Create a DELT.MIF file to report the groups that are enumerated.
    • Copy this file to the Data Loader directory for processing.

  • Network Application Database (*.NAD) - Stores shared applications for users. References .HGF and .HAF files for desktop customization.

    Program Groups should be configured after the shared package has been distributed.

    Program Group Control configuration information is stored in SMS.INI.

  • APPCTL - Builds the network application and program groups, based on information from the .NAD file. Occurs when Program Group Control starts.

  • APPSTART - Starts network application from information in the .NAD file. Uses DDE to send application to the Program Control Group. Uses PCM to run the application.

    • Setting Up Multiple Sites

    To establish a relationship with a parent side you must know:

    • The destination site code
    • The type of sender to use

    A properly configured site includes an account that can access the site server being addressed. It is recommended to use an account different from the SMS service account because this account has rights throughout the site.

    SMS adds the proposed properties to the site database. When the Hierarchy Manager detects the changes it creates the files nessesary to make the actual changes to the site's configuration. When configuration is completed at the parent site the at the parent side will see a new child in the Sites window. After the childs site's inventory has been reported he will be able to view the inventory of any computer in the child site, as well as to administer the child site server.

    The site configuration file (.ct2) is sent to the parent site.

    A secondary site server is created and configured from its parent site and is used when:

    • No local administrator exists at a remote site
    • Insufficient resourses are available for a SQL Server database
    • The remote side will never requires subsites below it

    Removing SMS Servers
    Primary server:
    • 1. Remove any secondary site from this parent.
    • 2. Once the parent has detached, remove the site from the hierarchy.
    • 3. Attach child sites to the new parent site.

    Removing the site can be performed by the SMS setup program: click Deinstall in the Installation Options menu. During this process, you can request SQL Server to drop the SMS database and log devices.

    If clients in the site are completely removed from the SMS hierarchy, you should remove these computers from the site databases of all parent sites above the removed site. Use the Delete Special command to remove inventory for these clients from each site database.

    Secondary Site:

    • 1. In the Sites window, click the secondary site to be removed.
    • 2. Press DEL or on the Edit menu click Delete.

    SMS automatically creates a bootstrap job to send to the remote site to remove SMS from the site. This removes only the server files on the site/logon/distribution servers. It does not remove the client files or packages installed on the clients.

    SNMP
    SNMP uses a distributed achitecture consisting of management systems and agents. The SNMP Servise sends information to one or more hosts when the host requests it or when a significant event occurs.

    A mangement system can initiate the get, get-next, and set operations.

    • Get - Request for a specific value
    • Get-next - Request for the "next" value
    • Set - Changes a value

    The only operation initiated by a agent is a trap (alerting management systems to an extraordinary event).

  • Management Information Base (MIB) - A set of manageable objects representing device data.

    Define communities to prevent an Agent accepting a request from a management system ouside is configured community.

    An SNMP Agent can be a member of multiple communities, thus allowing communications with SNMP managers from various communities.

    How it works:

      1. A SNMP management sytem send a req to an agent using the agent's host name (or IP address).
      2. SNMP packet is formed containing following information:
      • A get, get-next, or set request for one or more obects
      • A community name and other validating informations
      3. SNMP agent receives information in his buffer
      • Community name is verified
      • If valid it verifies the source name or IP address and the request is passed to the apropriate DLL
      • Object identifier is mapped to the apropriate API function, and the API call is made
      4. SNMP packet is send back to the SNMP manager with the requested information

    If SNMP Service is installed after SMS you must run the Client Configuration Manager to reset the SNMP Event to Trap Translator for newly installed SNMP Service. (Can be forced by running RUNSMS.BAT from the SMS_SHR share on the logon servers).

    Trap filters are stored in the WinNT registry.

    • Troubleshooting
    Hints for troubleshooting:
    • Check the WinNT Event Log for errors
    • Check the SMS database (Event MIF files are stored in the database)
    • Check SNMP traps (Events are reported as SNMP trap messages)
    • Check for network errors
    • Check disk errors (disk space; file system etc)
    • Check database errors ( is database available, full or corrupted)
    • Check if the SMS service account has the required permissions
    • Check if the account the sender uses is well configured
    • Check if time on the servers is synchronized
    • Check if the different requires Managers are running and not paused
    • Check the different directories if the expected file for a specific task arrives

    Diagnostics Tools to use:

      Network Monitor To diagnose network problems between computers or general problems.
      Dumpsend Used for diagnosing problems with sending data between two sites.(Shows the status of the send request).
      ViewNAD Used to view the shared applications that are located on servers an are avvailble to be used by clients.
      Tracer & SMSTrace       SMSTrace is graphical (dynamically updated) application that can load multiple log files at one time. Tracer is useful for displaying a log file dynamically. Whenever it is updated, Tracer places the information in its application window. This allows a process to be traced as it is working. Multiple instances of Tracer can be run to trace more than one process simultaneously.
      MIFCheck Verifies that a MIF file is valid.

    Special Thanks to Wim Steenberg for writing the original Cram Session for this exam!