Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Viewing Detailed Process Activity

The “WMI in ConfigMgr,” “Components and Communications,” and “Inside the ConfigMgr Database” sections described the ConfigMgr technical architecture. This section presents some tools you can use to view the inner working of ConfigMgr in detail. The section includes a detailed example to illustrate the use of these tools.

System Center 2012 ConfigMgr provides two built-in mechanisms that allow you to view and analyze ConfigMgr operations in detail:

  • ConfigMgr components generate status messages to report milestone activity and problem occurrences. System administrators can view status messages and use them in queries and reports. You can also configure the status message system to invoke automated actions in response to specified status messages.
  • ConfigMgr components generate extensive logs that give additional detail about their activity.

Both the status message system and logging are highly configurable and provide valuable windows into the system.

Digging into ConfigMgr logs is one of the best ways to gain a deep understanding of ConfigMgr internals. Much of the material in this chapter is drawn from analyzing log files. Chapter 21 covers configuring the status message system. Appendix A discusses the various ConfigMgr logs in detail. This part of the chapter discusses the use of status messages and logs for looking at the inner working of ConfigMgr.

The ConfigMgr logs are text files, and you can view them in Windows Notepad or your favorite text editor. Most administrators prefer to use the ConfigMgr Trace Log Tool (CMTrace) rather than a text editor to display log files. The log viewer formats log entries, provides search and highlighting features, and provides error lookup. You can optionally turn on an auto-refresh feature to update the displayed log in near real time.

Process Monitor is a tool you can use to capture detailed process activity on Windows systems. It provides extensive filtering options that allow you to drill down on activity related to specific folders, view only the operation of selected threads, and so forth. More information on Process Monitor and a link to download this useful tool are available at http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

The SQL Server Profiler allows you to capture detailed activity on your SQL Server. The profiler provides extensive filtering options that allow you to record the specific SQL activity in which you are interested. You can use this tool though the SQL Server Profiler user interface or use the ConfigMgr stored procedures spDiagStartTrace and spDiagStopTrace to capture activity ConfigMgr SQL activity. SQL Server Profiler ships with Microsoft SQL Server; the SQL Online Books describe its use in detail.

The “Components and Communications” section presented an example of how ConfigMgr components work together to process a site change. This section takes a closer look at WMI and SQL activity associated with the same site change as captured in logs and other tools. In this example, an administrator uses the ConfigMgr console to modify a site component. This results in the following sequence of events:

  1. The console application invokes the SMS Provider WMI object for the modified site control item. The SMS Provider log file (smsprov.log) shows this activity.
  2. The provider implements code that applies the update to the database. You can use either the SQL Server Profiler tool or the ConfigMgr SQL logging option to capture the SQL statements the provider uses.
  3. The database contains special stored procedures, known as triggers, which automatically carry out additional processing when the update occurs. The triggers write records for auditing purposes and to provide notification to the Database Notification Monitor (SMSDBMON) component. You can use SQL Management Studio to locate and understand the triggers.
  4. SMSDBMON processes the data and notified additional components of the change. The Database Notification Monitor log (smsdbmon.log) shows SMSDBMON polling the database for changes. The Process Monitor tool shows file system activity by the Database Notification Monitor thread as it writes to other components’ inboxes.
  5. Additional threads carry out work to complete the site change. These threads record their activity in status messaged and logs.

Here is a detailed look at the activity just described.

Figure 3.38 shows a portion of the smsprov.log file as displayed in the log viewer.

Figure 3.38

Figure 3.38. Smsprov.log displayed in the Log Viewer (SMS Trace).

The smsprov.log file shows calls to the SMS Provider from management applications. The bottom pane of the log viewer displays the details of the highlighted log entry. The entry in Figure 3.35 shows that the user ODYSSEY\bholt modified an instance of class SMS_SCI_SiteDefinition. The SMS_SCI_SiteDefinition, displayed in Figure 3.39, provides an interface to binary data stored in the SiteControl table.

Figure 3.39

Figure 3.39. The SMS_SCI_SiteDefinition WMI class displayed in the WMI Object Browser.

Using the SQL Server Profiler lets you see SQL requests sent to the SQL Server database. (For information about the SQL Server Profiler, see http://msdn.microsoft.com/en-us/library/ms187929.aspx.)

The following SQL commands show the application SMS Provider inserting data into the vSMS_SC_SiteDefinition_Properties view:

IF NOT EXISTS (select 1 from vSMS_SC_SiteDefinition_Properties where ID = 0 and Name
= N'Comments'
)
insert into vSMS_SC_SiteDefinition_Properties (ID, Name, Value1, Value2, Value3)
values (0, N'Comments', N'Central Administration Site (CAS)', N'', 0)
 ELSE update vSMS_SC_SiteDefinition_Properties set ID = 0, Name = N'Comments',
Value1 
= N'Central Administration Site (CAS)', Value2 = N'', Value3 = 0  where ID = 0 and 
Name = N'Comments'

You can use SQL Server Management Studio to view the underlying tables for a view. Figure 3.40 shows that vSMS_SC_SiteDefinition_Properties is based on the SC_SiteDefinition_Property table.

Figure 3.40

Figure 3.40. The Site Definition Properties View depends on the SC_SiteDefinition_Property table.

Figure 3.41 shows the SC_SiteDefinition_Property table in the Object Explorer tree on the left with the text of the SMSDBAudit trigger in the right text pane. A trigger is a special type of SQL stored procedure that runs automatically when changes are made to table data. The SMSDB Audit trigger (SMSDBAuditTrigger_SC_SiteDefinition_Property_INS_UPD_DEL) inserts a row into the SCCM_Audit table when the data in the SC_SiteDefinition_Property table changes.

Figure 3.41

Figure 3.41. The SC_SiteDefinition_Property Table displaying a trigger definition.

The following query displays entries in the SCCM_Audit table associated with changes made by the SMS Provider:

SELECT [ID], [TransactionID], [TableName], [By_Machine], [By_User]
      ,[By_Component], [ChangeXML], [ChangeTime]
  FROM [CM_CAS].[dbo].[SCCM_Audit]
  WHERE By_Component = 'SMS Provider' and TableName = 'SC_SiteDefinition_
PropertyList'

The ChangeXML column from the site description change is as follows:

<Changes><Change OP="U"><NewValue><row ID="68" SiteNumber="0" Name="Comments"
Value1="Central (CAS) site" Value2="" Value3="0" /></NewValue>
<OLDValue><row ID="68" SiteNumber="0" Name="Comments" Value1="CAS site"
Value2="" Value3="0" /></OLDValue></Change></Changes>

Another trigger, SMSDBMON_SC_SiteDefinition_Property_SQLServerSSBPORT_UPD_HMAN_upd, inserts data into the TableChangeNotifications table as follows:

BEGIN
    INSERT INTO TableChangeNotifications(Component,TableName,ActionType,Key1,Key2,Key3)

        SELECT all 
N'SQLServerSSBPORT_UPD_HMAN',N'SC_SiteDefinition_Property',2,IsNULL(convert(nvarchar
(256),SiteNumber),N''),N'',N'' FROM inserted WHERE Name = 'SSBPort' AND 
UPDATE(Value3) AND (dbo.fnIsParentOrChildSite(SiteNumber) != 0 OR SiteNumber = 
dbo.fnGetSiteNumber())

    IF @@ERROR != 0 ROLLBACK TRAN
END

The SMSDBMON prefix indicates that this trigger is owned by the ConfigMgr Database Notification Monitor component. Many of the database tables have triggers that write to the TableChangeNotifications table when changes occur. The Database Notification Monitor log (smsdbmon.log) shows the activity of the maintenance thread, which maintains these triggers. The same thread also maintains the various site maintenance tasks in the database.

The Database Notification Monitor polling thread regularly executes the spGetChangeNotifications stored procedure shown in this SQL Server Profiler trace:

[SMS_DATABASE_NOTIFICATION_MONITOR] exec spGetChangeNotifications

The spGetChangeNotifications stored procedure reads the TableChangeNotifications table in batches of up to 1000 transactions. The Database Notification Monitor then processes any new entries it finds. The smsdbmon file shows the following activity from the polling thread:

RCV: UPDATE on SiteControl for SiteControl_AddUpd_HMAN [CAS  ][9811]
RCV: UPDATE on SiteControl for SiteControl_AddUpd_SiteCtrl [CAS  ][9812]
SND: Dropped F:\Program Files\Microsoft Configuration Manager\inboxeshman.box\CAS.SCU  [9811]
SND: Dropped F:\Program Files\Microsoft Configuration Manager\inboxessitectrl.box\CAS.CT0  [9812]
SQL>>>delete from TableChangeNotifications where RecordID in (9811,9812)

Notice the Database Notification Monitor receives notifications that site control data has been updated and drops files in the Hierarchy Manager and Site Control Manager inboxes. These are zero byte files; however, Windows generates a directory change notification when the file is created. ConfigMgr components subscribe to change notifications for their inboxes. The SQL command in the final log entry deletes the change notification entries after processing the changes. This is why you cannot directly view the output of the associated trigger in the TableChangeNotifications table as was possible with the SCCM_Audit table.

To see even more detail of the process activity that carries out the site modification, use Process Monitor to capture the file system activity of the SMSExec process during the site change. Here is a partial listing for some Process Monitor event details during the site change, with comments added:

***SMSDBMON file drops files in HMAN and SITECTRL inboxes***
Event Class:      File System
Operation:        CreateFile
Result:  SUCCESS
Path:    F:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\CAS.SCU
Event Class:      File System
Operation:        CreateFile
Result:  SUCCESS
Path:    F:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\CAS.CT0
*** SMSEXEC thread 5248 detects a Directory Change Notification***
*** Thread ID 5248 matches a thread ID in the Hierarchy Manager log***
Name:    smsexec.exe
Event Class:      File System
Operation:        NotifyChangeDirectory
Result:  SUCCESS
Path:    F:\Program Files\Microsoft Configuration Manager\inboxes\hman.box
TID:     5248
Duration:         27.4709051
Filter:  FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME

Several threads detect the file system changes. The Hierarchy Manager does much of the processing and will serve as an example of ConfigMgr process activity. The Hierarchy Manager Log (Hman.log) now shows:

Processing site control file: Site CAS

The actual processing is performed by executing SQL statements against the database. With SQL Tracing enabled, the log then shows a large number of SQL SELECT statements retrieving data from tables and views such as SC_SiteDefinition, vSMS_SC_SiteDefinition_Properties and vSMS_SC_Component_Properties. After retrieving data about the site, Hierarchy Manager logs the following entry:

Update the Sites table: Site=CAS Parent=

This is followed by a number of SQL statements, including updates to the SysReslist table and calls to the spUpdateSites stored procedure, which updates the Sites table. Hierarchy Manager then updates the SiteControlNotification table to create a site control notification for the site. Finally, the thread raises the following status message:

Hierarchy Manager successfully processed "F:\Program Files\Microsoft Configuration 
Manager\inboxes\hman.box\CAS.SCU", which represented the site control file for site 
"Odyssey Central Site" (CAS).

Process Monitor can display registry access as well as file access. You could use Process Monitor to see the details of Hierarchy Manager retrieving the registry values it uses to construct a connection string to the site database and accessing the SQL client libraries to initiate the database connection.

  • + Share This
  • 🔖 Save To Your Account