Site Configuration Process Flow

[Previous] [Next]

Different SMS 2.0 services and processes carry out different tasks depending on the site property or site setting you enable or configure. However, there is still one basic process flow that takes place when any site setting changes: the change is made, the change is carried out, the database is updated with the change. Let's explore this process more closely.

Site settings are stored in the site control file. This file is named Sitectrl.ct0 and is maintained in the SMS\Inboxes\Sitectrl.box directory on the site server. This file is a text file that you can view using any text editor. The beginning of a representative site control file is displayed in Figure 3-10. The file is quite complete and detailed. It is the single most significant file for the site apart from the database itself because it contains every site setting parameter.

Figure 3-10. An example of some of the site properties contained in the site control file, showing the site code and site name (A01 and Primary Site 1), the site server platform (X86), the installation directory (G:\SMS), and the site control file serial number (17).

The site control file can be modified either through a change initiated by the SMS administrator or through a change initiated by an SMS component. Figure 3-11 outlines the process flow for initiating and carrying out a change to the site control file. The SMS SQL Monitor service and the Hierarchy Manager and Site Control Manager threads are the three SMS 2.0 components responsible for maintaining and updating the site control file.

Figure 3-11. The process flow for carrying out changes to the site control file in an SMS site.

This process is broken down into the following steps:

1. When the SMS administrator makes a change to a site setting, the SMS Provider updates the SMS database through Windows Management Instrumentation (WMI). The SMS Provider matches the change against the current database settings, called the site control image, and then creates a delta site control image, which contains the changes to be made.
2. A SQL stored procedure is triggered, which wakes up SMS SQL Monitor.
3. SMS SQL Monitor, in turn, writes a wake-up file to Hierarchy Manager's inbox, SMS\Inboxes\Hman.box. This filename is in the form sitecode.ssu or sitecode.scu, where sitecode is the three-character code you assigned to the site during setup.
4. The Hierarchy Manager thread accesses the database and looks for any proposed changes to the site settings. If a delta image exists in the database, Hierarchy Manager creates a delta site control file with the extension .CT1 and writes this file to Site Control Manager's inbox, SMS\Inboxes\Sitectrl.box\Incoming.
5. When this file is written, the Site Control Manager thread wakes up, reads the .CT1 file, and performs three actions:

1. It copies the current Sitectrl.ct0 file to the SMS\Sitectrl.box\History directory. SMS retains the last 100 site control files. As you'll discover, these files can multiply quickly.
2. It merges the changes into the current site control file and creates a .CT2 file in Hierarchy Manager's inbox, SMS\Inboxes\Hman.box.
3. It creates a new Sitectrl.ct0 file in the SMS\Sitectrl.box directory.

6. Hierarchy Manager wakes up when the .CT2 file is written to its inbox and updates the SMS database with the new site control data.

NOTE

---

Hierarchy Manager and Site Control Manager wake up whenever a file is written to their respective inboxes on the site server. However, they also have wake-up cycles. Hierarchy Manager will wake up every 60 minutes by default, and Site Control Manager will wake up once a day at midnight by default to generate a heartbeat site control file for Hierarchy Manager.

Site Control Filenames

As you monitor the Hierarchy Manager and Site Control Manager inboxes, you will see the .CT1 and .CT2 files created. You will also notice the rather strange filenames that are assigned to these files. When the files are created, they are assigned randomly generated filenames. This is done both to ensure uniqueness and to provide security. By scanning the status messages that are generated, or the log files, for Hierarchy Manager and Site Control Manager, you will be able to follow the creation of these files as they move from inbox to inbox.

The history copy of the site control file that Site Control Manager writes to the SMS\Inboxes\Sitectrl.box\History folder, however, has a very definite naming convention. Here each site control history file is named *.ct0, where * represents the site control file serial number in hexadecimal format. Thus site control file 9 would be saved with the filename 00000009.ct0, and site control file 10 would be saved with the filename 0000000A.ct0.

The serial number of the site control file is simply its sequential order in relation to other site control files. The site control file created during setup is serial number 0. The next one representing a change in site settings would be serial number 1, and so on. The serial number is recorded in the sixth line of the site control file, which can be read using any text editor.

This is not the whole story, of course. When you initiate a change, you may be asking SMS to enable a component, schedule a task, or initiate discovery or installation. Other SMS components also monitor the Sitectrl.ct0 file for changes. When Site Control Manager writes the new site control file, these other components wake up, read the file for changes that pertain to that component, and then carry out the change. These same components may themselves create .CT1 files to update the site control file with changes that have been carried out.

Those of you familiar with earlier versions of SMS will recognize this process flow, since it is similar to that carried out by the old Hierarchy Manager and Site Configuration Manager services. The main difference is that this process was largely cycle-driven in earlier versions of SMS. That is, after the SMS administrator proposed a change to the site control file, you had to wait for Hierarchy Manager to wake up from its sleep cycle before the change would be processed. In SMS 2.0, the Site Control Manager process is event driven, meaning that services and threads wake up when a change is detected. This greatly enhances the performance of SMS 2.0.