Previous Section
 < Day Day Up > 
Next Section


The Site Configuration Process Flow

Different SMS 2003 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 requested by you and posted to the SMS database, the change is carried out by the appropriate SMS site server component processes, and 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.14. The file is quite complete and detailed. It’s the single most significant file for the site, apart from the database itself, because it contains every site setting parameter.

Click To expand
Figure 3.14: An example of some of the site properties contained in the site control file, showing the site code and site name (S00 and Contoso Corp), the site server platform (X86), the installation directory (V:\SMS), and the site server name and domain (SQL1 and Contoso).

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.15 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 2003 components responsible for maintaining and updating the site control file.

Click To expand
Figure 3.15: 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 through the SMS Administrator Console, the SMS Provider directs that request to the SMS database through Windows Management Instrumentation (WMI). It matches the change against the current database settings, called the site control image, and then creates a delta site control image that contains the changes to be made.

  2. A SQL stored procedure (one of over 200) is triggered, which wakes up the SMS SQL Monitor Service.

  3. The 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 component on the site server monitors Hman.box for any new files. When the wake-up file is written to that folder, 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. The Site Control Manager component on the site server monitors Sitectrl.box\Incoming for any new files. When the .CT1 file is written, the Site Control Manager thread wakes up, reads the .CT1 file, and performs three actions:

    • It copies the current Sitectrl.ct0 file to the SMS\Sitectrl.box\History folder. SMS retains the last 100 site control files. As you’ll discover, these files can multiply quickly.

    • It merges the changes into the current site control file and creates a .CT2 file in Hierarchy Manager’s inbox, SMS\Inboxes\Hman.box.

    • 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.

This is not the whole story, of course. When you initiate a change, you might 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, or the SQL Monitor Service might write a wake-up file directly to the appropriate component’s inbox. When Site Control Manager generates the new site control file or SQL Monitor writes a wake-up file to an inbox, these other components wake up, read the file(s) for changes that pertain to that component, and then carry out the change. These same components might themselves create .CT1 files to update the site control file with changes that have been carried out.

As you can see, the Site Control Manager process is very much event driven, meaning that services and threads wake up when a change is detected rather than waiting a predetermined period of time before waking up and checking for any activity that needs to take place. This process was introduced with SMS 2.0 and further enhances the performance of SMS 2003, as many of these processes have been streamlined.

More Info 

Throughout this book, we’ll explore process flows relating to specific processes such as package distribution and client installation. We’ll look at the highlights of these process flows—those elements that most facilitate troubleshooting. However, many of these process flows are far more complex. For a thorough treatment of various SMS process flows, refer to the Microsoft Systems Management Server 2003 Troubleshooting Guide, available through the SMS Web site (www.microsoft.com/smserver) and through Microsoft TechNet.



Previous Section
 < Day Day Up > 
Next Section