Chapter 18 - Site Server Configuration and Change Control Flowcharts

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Configuration data is gathered from default settings installed with SMS, changes made by SMS administrators who make site configuration changes, and changes made by SMS service and thread components. When site configuration changes are made, SMS updates the site control file and the registry where configuration changes are stored. Since most SMS services function on a schedule, after an administrator or SMS turns on a service or thread component, the component checks the site control file for its configuration. This chapter contains the component flowcharts for the server components that are responsible for configuration and change.

This chapter includes the following flowcharts:

To gain the most out of this chapter, you should read the introductory material for the flowcharts in Chapter 16, "Introducing the SMS 2.0 Flowcharts." Also make sure you are familiar with the basic concepts presented in the following chapters in the SMS 2.0 Administrator's Guide:

  • Chapter 11, "Managing Collections and Queries" 

  • Chapter 18, "Maintaining SMS Systems" 

Site Component Manager

Site Component Manager is an SMS service component that installs and removes service and thread components at an SMS site and makes sure that all of the necessary service and thread components are installed. This section documents two Site Component Manager Flowcharts:

  • Site Configuration Change 

  • Polling Cycle 

Site Configuration Change

The Site Configuration Change flowchart illustrates the processing that occurs when an SMS administrator creates or changes a site system. When a site system gets created, Site Component Manager installs and starts the service and thread components that are necessary for that particular site system to perform its role. For more information about the server components that run on each type of site system, see Table 2.11, "Where SMS Service Components Are Installed" and Table 2.12 "Sites Where SMS Thread Components Run."

The activity described in this flowchart takes place on both primary and secondary site servers and on any site systems that each particular site server administers.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages for the server component listed in the table below. Or, you can enable the log file for this component. You can then study the log file and status messages associated with this component to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about viewing status messages and enabling logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 18.1 Status Message Component and Log File for Site Component Manager: Site Configuration Change 

Server component

Log file

Site Component Manager

SMS\Logs\Sitecomp.log

Troubleshooting Tips

If SMS service and thread components do not appear to be installed and started on a new CAP server: 

  • Review the status messages and log files for Site Component Manager. 

  • Verify that the SMS service account has Domain Admins privileges on the CAP server. Also verify that the SMSSvc_XXX_0000 account password or rights have not been changed. This is an account whose passwords and rights should never be changed. 

  • Verify connectivity between the site server and the newly assigned CAP. 

Cc723595.smc1801(en-us,TechNet.10).gif

Polling Cycle

The Polling Cycle flowchart documents the processing that takes place when Site Component Manager checks each service and thread component to verify that the appropriate components are running. Site Component Manager polls every server component every 60 minutes. If one of the components is not running, Site Component Manager tries to restart the component. If it fails, then it tries to reinstall the component.

The activity described in this flowchart takes place on primary and secondary site servers.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages for the server component listed in the table below. Or, you can enable the log file for this component. You can then study the log file and status messages associated with this component to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about viewing status messages and enabling logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 18.2 Status Message Component and Log File for Site Component Manager: Polling Cycle 

Server component

Log file

Site Component Manager

SMS\Logs\Sitecomp.log

Troubleshooting Tips

If Site Component Manager fails to restart a server component: 

  • Check the Site Component Manager status messages if you detect a problem with one of the server components. Possible problems include a service account password change, access rights problems, and corruption in the site server registry. 

Cc723595.smc1802(en-us,TechNet.10).gif

Site Control Manager

Site Control Manager is an SMS thread component that processes site configuration changes and writes new site control files. This section contains three flowcharts for Site Control Manager:

  • Configuration Changes Initiated at the Current Primary Site 

  • Configuration Changes Initiated at a Parent Site 

  • Configuration Changes Initiated at the Current Secondary Site 

Configuration Changes Initiated at the Current Primary Site

This flowchart describes how changes to site configuration are managed, whether the change is initiated by an administrator using the SMS Administrator console or by an SMS component.

The activity described in this flowchart takes place at primary site servers.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages for the server components listed in the table below. Or, you can enable the log files for these components. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about viewing status messages and enabling logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 18.3 Status Message Components and Log Files for Site Control Manager: Configuration Changes Initiated at the Current Primary Site 

Server components

Log files

SMS Administrator console (through the SMS Provider)

SMS\Logs\SMSprov.log

Hierarchy Manager

SMS\Logs\Hman.log

SMS Provider

SMS\Logs\SMSprov.log

Site Control Manager

SMS\Logs\Sitectrl.log

Troubleshooting Tips

If site configuration changes are not being written to the site control file: 

  • If you are using standard SQL Server security, determine (from the Hman.log file or by contacting your SQL Server administrator) whether the SQL Server sa password has been changed recently.

    If the password has changed, ensure that the change is propagated to SMS. You can explicitly inform SMS of a change in the sa password on the Accounts tab of the Properties dialog box for the site. To open the site Properties dialog box, navigate to <site code - site name> in the SMS Administrator console: 

    Systems Management Server
    

· Site Database (site code - site name) · Site Hierarchy · site code - site name

Right click \<***site code - site name***\> in the console tree and click **Properties**. 
  • If a component initiated the configuration change, determine, from the appropriate component log file whether the *.ct1 file was created and placed in the SMS\Inboxes\SiteCtrl.box\Incoming directory. 

    Examine the Sitectrl.log file to determine whether Site Control Manager can do all of the following:

    • Read the *.ct1 file. 

    • Copy the *.ct0 file to the SMS\Inboxes\SiteCtrl.box\History directory as a *.ct0 site control file. 

    • Create a new Sitectrl.ct0 file by merging the current version with the incoming *.ct1 file. 

    • Create a *.ct2 file for Hierarchy Manager to update the SMS site database. 

  • Hierarchy Manager reads SMS site database information from the site control table and uses it to create a *.ct1 file in the SMS\Inboxes\Sitectrl.box\Incoming directory. Using the Hierarchy Manager status messages or Hman.log, verify that Hierarchy Manager is able to read the SMS site database and create a *.ct1 file. Enable SQL tracing and then examine SMSprov.log and Hman.log to see a report of the SQL commands and responses from SQL Server. 

  • Hierarchy Manager takes a *.ct2 file from SMS\Inboxes\Hman.box and writes it to the SMS site database. Verify this last step in the update process by examining the Hman.log file. 

  • Use Windiff to compare site control files in the SMS\Inboxes\Sitectrl.box\History directory to see which configuration changes were made during each cycle. 

  • When the site control file process spans more than one SMS site, such as a child site reporting to a parent, verify that you have created addresses between the two sites. 

Cc723595.smc1803(en-us,TechNet.10).gif

Configuration Changes Initiated at a Parent Site

This flowchart illustrates the process Site Control Manager uses to update site control files on a child site. Because the site control file update process is very similar in all three Site Control Manager flowcharts, the troubleshooting tips and tracing information listed for Site Control Manager: Configuration Changes Initiated at the Current Primary Site apply to this flowchart as well.

The activity described in this flowchart occurs on a parent site and a child site.

Cc723595.smc1804(en-us,TechNet.10).gif

Configuration Changes at the Current Secondary Site

This flowchart illustrates the process Site Control Manager uses to update site control files at a secondary site. Since the site control file update process is very similar in all three Site Control Manager flowcharts, the troubleshooting tips and tracing information listed for Site Control Manager: Configuration Changes Initiated at a Parent Site apply to this flowchart as well.

The activity described in this flowchart occurs on a secondary site and its parent.

Cc723595.smc1805(en-us,TechNet.10).gif

SMS SQL Monitor

SMS SQL Monitor is an SMS service component that runs on the SMS site database server (the SQL Server computer). SMS SQL Monitor reads the site control file for the site and also reads certain registry entries on the SMS site database server. Based on the instructions it finds in these directories and on the list of enabled database maintenance tasks, SMS SQL Monitor detects changes in the SMS site database and writes files to inboxes for other SMS components, as appropriate. This chapter documents the following SMS SQL Monitor flowcharts:

  • SMS SQL Monitor Tasks 

  • Trigger Manager

SMS SQL Monitor Tasks

The Task Manager thread of the SMS SQL Monitor service component is responsible for monitoring the site control data and executing the scheduled tasks when they become due. This service component creates the following default tasks if they do not already exist:

Table 18.4 Default SMS SQL Monitor Tasks 

Task

Notes

Backups:
Export SMS Site Database
Export SMS Site Database Transaction Log
Export Software Metering Database
Export Software Metering Transaction Log

These tasks are disabled by default. To activate exports, you must create a dump device and specify the period. When enabled, their default schedule is to run every Sunday between 12:00 midnight and 5:00 A.M.

Backup SMS Site Server

Backs up SMS site and software metering databases, the SMS and NAL registry keys, and the SMS directory structure to a network path. When enabled, the default schedule for this task is to run every Sunday between 12:00 midnight and 5:00 A.M.

Delete Aged Inventory History

This task deletes historical data from the Inventory tables, given an "older than" parameter, in days. By default, it is scheduled to run every Saturday between 12:00 midnight and 5:00 A.M. and deletes data that is more than 90 days old.

Delete Aged Status Messages

This task allows you to enable and schedule how long status messages are stored in the SMS site database before they are deleted. Use Status Filter Rules under Site Settings in the SMS Administrator console to configure which messages will be deleted. By default, this task runs daily between 12:00 midnight and 5:00 A.M.

Delete Aged Discovery Data

This task deletes discovery data that was discovered no earlier than an "older than" parameter, in days. By default, it is scheduled to run every Saturday between 12:00 midnight and 5:00 A.M. and deletes discovery data that was not discovered within the last 90 days.

Delete Aged Collected Files

This task is similar to deleting history, although it only deletes files from the collected files group that are greater than 90 days old. The files are deleted from the Collected Files inbox. This task is scheduled to run every Saturday morning between 12:00 midnight and 5:00 A.M.

Monitor Keys and Recreate Views

This task verifies the integrity of the SMS site database keys and updates any SQL views that require updating.

Update Statistics

This task is run against every table in the SMS site database and recalculates the table size to allow the SQL optimizer to most efficiently run a query. The default execution value is every two days between 12:00 midnight and 5 A.M. on every day but Sunday.

Rebuild Indexes

This task rebuilds SQL indexes for faster data retrieval. By default, this task is scheduled to run every Sunday morning between 12:00 midnight and 5 A.M.

You can schedule additional SQL Server commands; the results are written to a designated log file.

This flowchart documents the actions involved in these scheduled tasks. All of the actions take place on an SMS site database server.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages for the server component listed in the table below. Or, you can enable the log file for this component. You can then study the log file and status messages associated with this server component to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about viewing status messages and enabling logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 18.5 Status Message Component and Log File for Site Component Manager: Site Configuration Change 

Server component

Log file

SMS SQL Monitor

SMS\Logs\SMSdbmon.log

Troubleshooting Tips

If scheduled tasks are not being executed: 

  • Verify that SMS SQL Monitor is running. 

    Verify that SQL Server is running. Also, examine the SMSdbmon.log file to verify that SMS SQL Monitor can access the SMS site database server to run the tasks.

    • Verify that the SMS site database server services are running. 

    • Verify that SMS can access the SMS site database. 

    • Verify that the SMS site database, transaction log, and tempdb are not full. 

    • Verify that there are at least 50 SQL Server user connections, plus five for each SMS Administrator console. 

    • If the problem persists, check the SMS site database server error logs. 

  • Verify that the task is scheduled to occur now. If the task is not yet due to be run, SMS SQL Monitor sleeps for 60 minutes or until the task is due, whichever is shorter. 

  • Examine the SMS SQL Monitor status messages or the SMSdbmon.log file to determine whether SMS SQL Monitor was unable to execute the task, and if so, why it failed. SMS SQL Monitor reports errors that occur when it tries to execute a scheduled task and when a tasks starts. Upon failure, SMS SQL Monitor retries within a scheduled interval. 

Cc723595.smc1806(en-us,TechNet.10).gif

Trigger Manager

The Trigger Manager thread of the SMS SQL Monitor service component is responsible for notifying other SMS components of database changes. This service allows an almost instantaneous response to the creation, update, deletion, or request for numerous SMS processes such as collection updates. To inform the Trigger Manager of specific database events, SMS Executive thread components add keys to a specific location in the site server's registry. Each trigger responds to an insert, update, or delete on a specific database table.

The actions illustrated in this flowchart take place on the SQL Server computer, although the registry entry that SMS SQL Monitor reads at the beginning of the flowchart is on the site server.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages for the server components listed in the table below. Or, you can enable the log files for these components. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about viewing status messages and enabling logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 18.6 Status Message Components and Log Files for SMS SQL Monitor: Trigger Manager 

Server components

Log files

SMS SQL Monitor

SMS\Logs\SMSdbmon.log

SMS Provider

SMS\Logs\SMSprov.log

Troubleshooting Tips

If triggers are not generated in the inboxes where they are expected: 

  • If the site server and SQL Server are on different computers, verify network connectivity between the two. Also, examine the SMS SQL Monitor status messages or the SMSdbmon.log file to verify that SMS SQL Monitor read the triggers from the registry and installed them to the appropriate tables in the SMS site database. 

    Examine the SMSdbmon.log file to verify that:

    • SMS SQL Monitor has access to the specified inboxes at the site server where it must write the key file for the trigger.

    • The key file (for example *.adc or *.udc) was written to SMS\Inboxes\component.box (for example, SMS\Inboxes\Colleval.box). 

  • If the trigger file was written, verify from the appropriate component log file that the component read the key file and took the required action. 

Cc723595.smc1807(en-us,TechNet.10).gif

Cc723595.spacer(en-us,TechNet.10).gif