Chapter 17 - Site Server Core Components 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.

Site server components are responsible for processing that occurs on the site systems in your site. The processing accomplished by these components is very specialized, with each component playing an important role in SMS processing. For example, Site Control Manager is responsible for updating the site control file under all of the various hierarchy structures you can create with SMS. At the same time, Site Control Manager relies on Hierarchy Manager to write new site control files to the SMS site database. Gaining an understanding of the flowcharts for these components will help you more fully understand the processes occurring in many of the process flowcharts in later chapters.

This chapter includes the following flowcharts:

  • Hierarchy Manager: Service Account Name or Password Change 

    Inbox Manager:

    • Copying, Moving, and Mirroring Files 

    • Client Access Point Processing 

  • Inbox Manager Assistant 

    Discovery Data Manager:

    • Normal Discovery Data Record Processing 

    • Parent Site Change 

    • Site Boundary Change 

    Collection Evaluator:

    • Collection Monitoring 

    • Normal Processing 

    • Site Assignment Change 

  • Replication Manager 

  • Scheduler and Sender 

  • Despooler 

To gain the most out of this chapter, make sure you are familiar with the basic concepts presented in the following chapters in the SMS 2.0 Administrator's Guide:

  • Chapter 1, "Introducing Systems Management Server 2.0" 

  • Chapter 4, "Creating Your SMS Security Strategy" 

  • Chapter 10, "Collecting Hardware and Software Inventory" 

  • Chapter 11, "Managing Collections and Queries" 

  • Chapter 12, "Distributing Software" 

Hierarchy Manager

Hierarchy Manager is a thread component that monitors the SMS site database for site control file change requests and updates the database with the new actual site control file after site control manager processes the changes. Change requests result from configuration changes that you make through the SMS Administrator console, or from custom applications that you can create using the SMS Toolkit.

The activity described in this flowchart take place on the primary site server. For more information about Hierarchy Manager's processing, see the Site Control File Process flowcharts in Chapter 18.

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 17.1 Status Message Components and Log Files for Hierarchy Manager: Service Account Name or Password Change 

Server components

Log files

Hierarchy Manager

SMS\Logs\Hman.log

Site Component Manager

SMS\Logs\Sitecomp.log

Troubleshooting Tips

If you change the service account name and password, and SMS does not successfully implement the changes: 

  • Verify that the old service account name and password were not deleted before the new ones were created. If you delete the old ones first, SMS does not have the required security access to make the change. 

  • Check the Site Component Manager status messages and the Sitecomp.log to verify that the SMS Executive service and the server components were reinstalled under the new service account name. 

Cc723594.smc1701(en-us,TechNet.10).gif

Inbox Manager

Inbox Manager is a thread component that monitors SMS inboxes and performs file copying, moving, and mirroring. When a component or service is ready to pass a file to another thread or service component, it drops the file into an inbox. Working on directory change notification, and in some cases a polling cycle, Inbox Manager picks up the file and carries out the proper procedure based on the rules for that file and inbox.

This chapter contains two Inbox Manager Flowcharts

  • Inbox Manager: Copying, Moving, and Mirroring Files 

  • Inbox Manager: Client Access Point Processing 

Inbox Manager: Copying, Moving, and Mirroring Files

Inbox Manager copies files for the local site and between sites. When Inbox Manager copies a file, it copies a file from a source inbox to a destination inbox. When Inbox Manager uses mirroring, it copies all of the files from the source inbox to the destination inbox and then deletes any files currently in the destination inbox that do not also exist in the source inbox.

The activity described in this flowchart takes place on primary 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 17.2 Status Message Component and Log File for Inbox Manager 

Server component

Log file

Inbox Manager

SMS\Logs\Inboxmgr.log

Troubleshooting Tips

If Inbox Manager does not appear to be moving, copying, or mirroring files correctly: 

  • Verify that Inbox Manager moves files to client access points (CAPs) when an SMS component (for example, software inventory changes) has either new files or file changes to send to clients. 

  • When an SMS component drops a file in an inbox at the site server (under SMS\Inboxes), it generates a directory change notification. Inbox Manager retrieves the inbox replication rules to determine what, how, and where to replicate the file. If files do not appear to be moving out of inboxes, check the status messages for the component whose inboxes are static. 

  • If Inbox Manager can establish a connection to the destination CAP server's appropriate inbox, it copies the files from the inbox on the site server to an inbox on the CAP. If copies are not being made, check the network connection between the site server and the CAP. 

  • If the site server fails in its attempts to connect to CAP servers or if Inbox Manager does not have the appropriate access to the destination inbox, then error status messages are recorded. Check the status messages for instructions on how to resolve this problem. 

  • If Inbox Manager fails in its attempts to send files from a site server to a CAP, it continues to retry connecting to the destination CAP server and records error status messages each time it fails. Review the Inbox Manager status messages for possible causes of this failure. 

  • To gain a better understanding of the process, you can also review successful Inbox Manager processing by reviewing the Inbox Manager status messages. 

Cc723594.smc1702(en-us,TechNet.10).gif

Inbox Manager: Client Access Point Processing

Inbox Manager processing on CAPs is illustrated in this flowchart. When an SMS administrator assigns a new role to an existing site system (for example, a new CAP), the changes made to the site control file serve as notification for Inbox Manager to create additional inboxes at the destination CAP server. Inbox Manager reads the notification information, connects to the destination server, and creates the appropriate inboxes.

This flowchart documents the process that takes place on a site server when an SMS administrator creates a new CAP site system.

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 17.3 Status message Component and Log File for Inbox Manager: Client Access Point Processing 

Server component

Log file

Inbox Manager

SMS\Logs\Inboxmgr.log

Troubleshooting Tips

If inboxes are not created on a new CAP server defined in the SMS Administrator console: 

  • Check the Inbox Manager status messages for suggestions on how to correct this problem.

  • Study the Inboxmgr.log file to determine whether Inbox Manager is able to connect to the destination CAP server.

  • Verify that the SMS service account exists and has the appropriate access rights to the new CAP server. 

  • Verify that the site system connection account, specified in the SMS Administrator console, exists and that is has appropriate access rights to the CAP server. 

  • Determine whether the CAP server is active on the network. When Inbox Manager at the site server cannot establish a connection with the new CAP server, it continues to retry and then records error status messages each time it fails. 

Cc723594.smc1703(en-us,TechNet.10).gif

Inbox Manager Assistant

Inbox Manager Assistant is a thread component that moves files from inboxes at CAPs to inboxes at SMS site servers. Inbox Manager Assistant responds to directory change notification; however, if no change occurs within 30 minutes, Inbox Manager Assistant polls the inboxes.

The activity described in this flowchart takes place on CAPs.

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 17.4 Status Message Component and Log File for Inbox Manager Assistant 

Server component

Log file

Inbox Manager Assistant

SMS\Logs\Inboxast.log

Troubleshooting Tips

If client discovery data record (DDR) files are not arriving at the site server: 

  • If there is a backlog of DDRs in the CAP_<SiteCode>\Inboxes\Ddr.box on the CAP, and it appears they are not being copied to the \\<ServerName>\SMS_<SiteCode>\Inboxes\Ddm.box directory on the site server, determine whether Inbox Manager Assistant is able to establish a connection to the site server's Ddm.box directory.

  • Check the Inbox Manager Assistant status messages to see if errors were recorded and to determine possible causes for any errors. 

  • Check from the Inboxast.log, whether the connection between the CAP and the site server was established, and look for any other error messages that might have been recorded. 

If client inventory (either hardware or software or both) is not being reported to the site: 

  • Verify that Inbox Manager is able to connect to the site server's Hinv and Sinv inboxes. If it is unable to connect, it generates status messages and records log file entries. 

  • View the Inboxast.log to verify that the inventory (nhm, raw, mif, sic, and sid) files were successfully copied from the CAP to the site server's appropriate inbox. 

If client status messages are not being propagated to the appropriate inboxes: 

  • Verify that Inbox Manager Assistant successfully moved the client status messages to the \\<ServerName>\SMS_<SiteCode>\Inboxes\Statmgr.box directory at the site server.

  • If the SMS Administrator console at the site server is not reporting status messages when advertised programs have been completed on clients, determine whether the client wrote the status messages to the \\<ServerName>\CAP_<SiteCode>\Inboxes\Statmsgs.box on the CAP. If so, then determine whether Inbox Manager Assistant is able to connect to \\<ServerName>\SMS_<SiteCode>\Inboxes\Statmgr.box inbox to copy the status messages.

  • Check the Inbox Manager Assistant status messages to see if errors were recorded and to check for possible causes.

Cc723594.smc1704(en-us,TechNet.10).gif

Discovery Data Manager

Discovery Data Manager is a thread component that:

  • Processes discovery data records and loads the data into the SMS site database. 

  • Forwards all assigned data to secondary sites and propagates all data to each site's parent site.

  • Processes the information gathered through the discovery methods enabled for the site.

  • Processes site boundary changes. 

This chapter includes three flowcharts for the Discovery Data Manager thread component:

  • Normal Discovery Data Record Processing

  • Parent Site Change

  • Site Boundary Change

Normal DDR Processing

Normal discovery data record (DDR) Processing describes the actions that take place when a new DDR file is generated by a discovery process. The action described in this flowchart takes place on a site server after a discovery process has generated a new DDR file and written that DDR file to a logon point or CAP.

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 17.5 Status Message Components and Log Files for Discovery Data Manager: Normal DDR Processing 

Server components

Log files

Inbox Manager

SMS\Logs\Inboxmgr.log

Inbox Manager Assistant

SMS\Logs\Inboxast.log

NT Logon Discovery Manager

SMS\Logs\NTlgdscm.log

Replication Manager

SMS\Logs\Replmgr.log

Discovery Data Manager

SMS\Logs\Ddm.log

Replication Manager

SMS\Logs\Replmgr.log (if a *.ddr file is forwarded to the parent)

Troubleshooting Tips

If a site server is not discovering clients: 

  • Verify that the client belongs within the site boundaries by comparing the client's IP subnet or IPX network number to the site boundaries. To view the site boundaries in the SMS Administrator console, navigate to <site code - site name> in the console tree. 

    Systems Management Server
    

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

Right-click \<***site code - site name***\> and click **Properties**. Click the **Boundaries** tab to view or modify the site boundaries. 

If discovery information is not being generated (no DDRs): 

  • Verify that you have initiated discovery in the SMS Administrator console.

  • Verify that your discovery methods have been active long enough for discovery data to be generated. Some forms of discovery cannot occur more frequently than once per hour and might be set for daily, weekly, or even monthly updates. Other forms of discovery require clients to log on. 

  • Check the status messages for the discovery type you have initiated. For example, if you are running Network Discovery, check the Network Discovery Status Messages. Then, check the status messages for Discovery Data Manager.

  • Verify that your SMS Service Account has the permissions required to copy and move the files. 

If the Ddm.box on the site server is not receiving and processing DDRs: 

  • Check the logon point's NTlgdscm.log file to see if DDRs are being copied correctly. Also check the status messages for Inbox Manager and Inbox Manager Assistant to see if the files are being copied correctly. 

    Verify that Discovery Data Manager has access to the SQL Server computer:

    • Examine the Discovery Data Manager status messages or the Ddm.log file. This log file records any connectivity problems with the SQL Server computer. Also, determine from the log whether the DDR file was processed and whether information reported in the DDR file was compared to the site boundaries information in the SMS site database. 

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

If DDM.box is receiving DDR files, but they are accumulating: 

  • Examine the status messages or Ddm.log to see if Discovery Data Manager is in the middle of processing changes to site boundaries or changes to the parent site or if it is sending inventory to a new parent site. These changes take priority over normal DDR processing; until these changes are processed, normal DDR processing is suspended. For more information about the effect of these flows on normal DDR processing, see the "Discovery Data Manager: Site Boundary Change" and "Discovery Data Manager: Parent Site Change" flowcharts.

If DDRs are not being replicated to parent or grandparent sites: 

  • Make sure that Replication Manager is receiving the DDRs.

  • Verify that you have a properly configured sender and a properly configured address. 

If Discovery Data Manager indicates that it has added information to the SMS site database, but you cannot view the discovery data in the SMS Administrator console:

  • Verify that your logon account has the appropriate permissions in Windows Management Instrumentation (WMI; formerly called WBEM) and the appropriate class/instance rights for the SMS Provider. For more information about security rights, see Chapter 4, "Creating Your SMS Security Strategy," in the SMS 2.0 Administrator's Guide

  • If a DDR came from a secondary site, the primary site's Discovery Data Manager will forward the DDR back to the secondary site, using Replication Manager. The file will be processed by the secondary site's Discovery Data Manager, which writes the file to SMS\Inboxes\Ddm.box\Data.col\*.pdr. This process is logged in Ddm.log and Replmgr.log on the primary site server and in Ddm.log on the secondary site server. Study the status messages for Discovery Data Manager and Replication Manager to find possible errors. Or, examine the log files to verify that the DDR has been returned from the primary site to the secondary site. 

    Verify that Discovery Data Manager has access to the SQL Server computer:

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

    • Enable SQL tracing in the registry to add verbose SQL information to the component log files. 

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

Cc723594.smc1705(en-us,TechNet.10).gif

Parent Site Change

The Parent Site Change flowchart describes the actions that take place when an administrator attaches a site to a parent site. The effect of the described activity in the "Discovery Data Manager: Parent Site Change" flowchart is to pass all information in a primary site's database to its new parent site.

The described activity in this flowchart takes place on the primary site server after an administrator has used the SMS Administrator console to attach the primary site to a parent site. The flowchart is the same whether the site had a different parent site before the change or never had a parent site before.

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 17.6 Status Message Components and Log Files for Discovery Data Manager: Parent Site Change 

Server components

Log files

SMS SQL Monitor

SMS\Logs\SMSdbmon.log

Discovery Data Manager

SMS\Logs\Ddm.log

Replication Manager

SMS\Logs\Replmgr.log (to forward to new parent site)

Discovery Data Manager

SMS\Logs\Ddm.log (at parent site)

Troubleshooting Tips

If DDRs and inventory from clients are not being reported to a new parent site: 

  • Verify that the parent site information and address are correct. To do so, 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**. 
  • Verify that the account (under Site Settings, Addresses in the SMS Administrator console) used to access the site has the appropriate permissions. 

  • Verify that the parent site has adequate disk space to store the data. 

  • Examine the status messages for Discovery Data Manager and Inventory Data Loader to verify that they have attempted to send the data to the parent site. 

    Examine the Ddm.log file on the client site to determine whether:

    • Discovery Data Manager started the evaluation process on all DDRs in the database, based on the new parent assignment. 

    • Discovery Data Manager created DDRs for each discovered resource in the database.

    • The DDRs created by Discovery Data Manager were passed to Replication Manager to send to the new parent site. 

  • Verify that Discovery Data Manager created notification files (*.sha) and placed them in the following directories: 

Table 17.7 Directories for Discovery Data Manager Notification Manager 

Directory

Purpose

SMS\Inboxes\DataLdr.box

Inbox for the Inventory Data Loader

SMS\Inboxes\Sinv.box

Inbox for the Software Inventory Processor

These notification files tell the respective processes that a new parent site has been assigned and that it should forward inventory data, after it is processed locally, to the new parent site.

  • Verify that the parent site is processing the DDRs properly. 

Cc723594.smc1706(en-us,TechNet.10).gif

Site Boundary Change

Site Boundary Change describes the actions that take place when an administrator changes the site boundary properties for a site. The described activity in this flowchart takes place on the primary site server when the site boundaries are changed for a site. If the boundaries are changed for a secondary site, the described actions take place on the parent site's site server, ending with the primary site's Discovery Data Manager writing a file to the secondary site's file-based database.

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 17.8 Status Message Components and Log Files for Discovery Data Manager: Site Boundary Change 

Server components

Log files

SMS SQL Monitor

SMS\Logs\SMSdbmon.log

Discovery Data Manager

SMS\Logs\Ddm.log

Replication Manager

SMS\Logs\Replmgr.log (to forward to secondary site)

Scheduler

SMS\Logs\Sched

Sender

SMS\Logs\Sender

Discovery Data Manager

SMS\Logs\Ddm.log (at secondary site)

Troubleshooting Tips

If changes to site assignment rules for a secondary site are not processing: 

  • Examine the SMS SQL Monitor status messages or the SMSdbmon.log file to verify that the SMS SQL Monitor service received notification of the site boundary changes you made using the SMS Administrator console. 

    Examine the Discovery Data Manager status messages or the Ddm.log file to verify that Discovery Data Manager did both of the following:

    • Started the evaluation process of all DDRs in the database, based on the new assignment rules.

    • Passed the changes to Replication Manager to send to the secondary site. 

    Examine the log files to verify that:

    • The sender in use is able to access the secondary site server. 

    • Replication Manager created a <site_code>.frf file and forwarded it to the secondary site using Scheduler and Sender. 

    • The account that the sender is using to access the secondary site has not changed and has the appropriate permissions. 

    Verify that Discovery Data Manager has access to the SQL Server computer:

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

    • Enable SQL tracing in the registry to add verbose SQL information to the component log files. 

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

  • Verify that the *.pdr file was created. Discovery Data Manager at the secondary site responds to the <site_code>.frf file that is generated when the secondary site boundaries are changed by writing the new assignment list to SMS\Inboxes\Ddm.box\Data.col\*.pdr. The Ddm.log file from the secondary site contains log entries about this event. 

Cc723594.smc1707(en-us,TechNet.10).gif

Collection Evaluator

Collection Evaluator is a thread component that manages collections, including refreshing collection data and propagating collection changes between sites. This chapter includes three flowcharts for the Collection Evaluator thread component:

  • Collection Monitoring

  • Normal Processing

  • Site Assignment Change 

Collection Monitoring

This flowchart illustrates the actions that occur to ensure that the memberships of dynamic collections are kept up-to-date. Each dynamic collection is re-evaluated according to a schedule set in the property dialog box for that collection. This flowchart describes the activity involved in these scheduled updates.

Collection monitoring activity takes place 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 17.9 Status Message Components and Log Files for Collection Evaluator: Collection Monitoring 

Server components

Log files

Collection Evaluator

SMS\Logs\Colleval.log

SMS Provider

SMS\Logs\SMSprov.log

Troubleshooting Tips

If collections are not being refreshed at regular intervals: 

  • Read the status messages recorded by Collection Evaluator to pinpoint why a collection update was not successful. 

  • Verify that a collection update schedule is set for each collection. To do so, open the property dialog box for the collection, select the Membership Rules tab, and click Schedule. If Recurrence Pattern is set to None, this collection is not periodically refreshed. 

  • Determine from the Colleval.log file whether the Collection Evaluator was able to run a query against the SMS site database to obtain the latest information about a specific collection. This log file contains a record of SQL Server connectivity problems. The log file also records SQL Server environment issues related to running the query, such as the Tempdb database's running out of space or SQL Server's running out of memory. To determine or adjust SQL Server settings, use the SQL Enterprise Manager. 

  • Verify that changes to update schedules in the SMS Administrator console are written to the SMS site database through the SMS Provider by checking the SMS Provider status messages or enabling and examining the SMSprov.log file. 

Cc723594.smc1708(en-us,TechNet.10).gif

Normal Processing

Normal Processing traces the actions that occur when a collection is added, modified, or deleted.

The Collection Evaluator: Normal Processing flowchart describes activity that takes place on the site server of the site containing the collection. If the site has child sites, additional activity takes place on the site server of each child site.

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 17.10 Status Message Components and Log Files for Collection Evaluator: Normal Processing 

Server components

Log files

Collection Evaluator

SMS\Logs\Colleval.log

Replication Manager

SMS\Logs\Replmgr.log

Troubleshooting Tips

If new collections created at the parent site do not appear at the child site:

  • Examine the Collection Evaluator status messages or the Colleval.log file to verify that the new collection (or updates to an existing collection, or removal of an existing collection) are written to the parent's SMS site database.

  • Examine Collections in the SMS Administrator console at the parent site to verify that the collections are appearing. 

  • Examine the Replmgr.log file to verify that the collection changes (in the form of a *.psd file) are written to the parent's \\<ServerName>\SMS_<SiteCode>\Inboxes\Colleval.box directory. The Replmgr.log file reports any connectivity problems that occur between sites during the file transfer process. 

  • If the child site is a primary site, examine the Colleval.log file to determine whether Collection Evaluator was able to read the *.psd file and write the changes to the child's SMS site database. 

  • If the child site is a secondary site, examine the Colleval.log file to verify that Collection Evaluator was able to read the *.psd file and write the changes to the *.clf file in the SMS\Inboxes\Colleval.box directory. 

If you suspect that problems are occurring with your SMS site database: 

  • Verify that this computer can reach the SMS site database server (SQL Server computer). 

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

  • Enable SQL tracing in the site server's registry (HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Tracing \SQLEnabled). Set the value to 1 to turn on SQL tracing, and set it to 0 to turn it off. Then, stop and restart the SMS Executive service using Control Panel. Enable logging for Collection Evaluator using the SMS Service Manager. This will enable tracing for SQL commands being passed between Collection Evaluator and the SQL Server. The trace messages will appear in Colleval.log. 

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

Note Enable SQL Tracing for temporary troubleshooting purposes only.

Cc723594.smc1709(en-us,TechNet.10).gif

Site Assignment Change

Site Assignment Change traces the actions that occur when a primary site is assigned to a different parent or when a child site is added to a parent site.

This flowchart addresses the following two cases:

A site assigned to a different parent site. 

When a site is given a new parent site, collections created by the previous parent site are removed. Later, collections from the new parent are processed as described in the flowchart, "Collection Evaluator: Normal Processing."

A child site added to a parent site. 

A new child site must be sent collection rules (if the child is a primary site) or a collection list file (if the child site is a secondary site).

The activity described in this flowchart takes place on the child 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 17.11 Status Message Components and Log Files for Collection Evaluator: Site Assignment Change 

Server components

Log files

Collection Evaluator

SMS\Logs\Colleval.log

Replication Manager

SMS\Logs\Replmgr.log

Troubleshooting Tips

If the change in parent site information makes this primary site a central site, Collection Evaluator generates the necessary default collections for the new central site. If these default collections fail to appear: 

  • Verify that the parent site information is correct. To do so, open the SMS Administrator console and navigate to <site code - site name>. 

    Systems Management Server
    

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

Right-click \<***site code - site name***\> and then click **Properties**. View the parent site information and verify that it indicates "None." 
  • Ensure that you have refreshed the screen of the SMS Administrator console after the change. To refresh the SMS Administrator console, navigate to <site code - site name>. 

    Systems Management Server
    

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

Right-click \<***site code - site name***\> and then click **Refresh**. 

If you have refreshed the screen, but collections from the previous parent still appear, then exit and re-open the SMS Administrator console. Opening the SMS Administrator console initiates a fresh query of the SMS site database; this should cause the new information to appear in Collections. 
  • Examine the Collection Evaluator status messages or the Colleval.log file to determine whether Collection Evaluator attempted to retrieve all collections that were created by the previous parent site from the site database.

    The Colleval.log file also records whether Collection Evaluator failed to delete these collections, and if it failed, the reasons for the failure. 

  • Verify that the SMS Service Accounts on both sites have the appropriate permissions if the child site resides in a separate domain from the new central site. 

If collections still exist at the old parent site: 

  • Look for the *.sca file in the SMS\Inboxes\Colleval.box directory. If the file still exists, enable logging for Collection Evaluator and examine the log file. 

When an SMS Administrator adds a secondary site to a primary site, Collection Evaluator retrieves all collections from the primary site database and forwards them to the secondary site. If the secondary site collections do not appear to be updated in the parent site's SMS Administrator console: 

If you suspect that problems are occurring with your SMS site database: 

  • Verify that this computer can reach the SMS site database server (SQL Server computer). 

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

  • Enable SQL tracing in the site server's registry (HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Tracing \SQLEnabled). Set the value to 1 to turn on SQL tracking and set it to 0 to turn it off. Then, stop and restart the SMS Executive service using Control Panel. Enable logging for Collection Evaluator using the SMS Service Manager. This will enable tracing for SQL commands being passed between Collection Evaluator and the SQL Server. The trace messages will appear in Colleval.log. 

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

Note Enable SQL Tracing for temporary troubleshooting purposes only.

Cc723594.smc1710(en-us,TechNet.10).gif

Replication Manager

Replication Manager is a thread component that handles both incoming and outgoing intersite replication. Replication Manager packages the objects into replication files and hands them off to Scheduler as mini-jobs to be sent to the appropriate locations by a sender. Replication Manager also analyzes incoming files, and if appropriate, replicates the objects to appropriate directories on the server.

The activity described in this flowchart takes place on 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 17.12 Log Files for Replication Manager

Server components

Log files

Replication Manager

SMS\Logs\Replmgr.log

Scheduler

SMS\Logs\Sched.log

Sender

SMS\Logs\Sender.log

Despooler

SMS\Logs\Despool.log

Troubleshooting Tips

If collections are not getting updated on child sites: 

  • Confirm that there are no errors by checking the Replication Manager status messages or the Replmgr.log file. 

If only high priority requests are being successfully replicated: 

  • Check to see if some of the requests have been prioritized incorrectly.

  • Reduce the number of high priority requests. 

  • Check to see if you have a large number of high or medium priority requests 

  • Verify that your network has enough bandwidth to handle the requests. 

If Replication Manager does not successfully create RPT files for Scheduler to send: 

  • Check the Replication Manager status messages or the Sched.log file for any errors related to connectivity or packages not being properly received. 

If Replication Manager does not successfully decompress package files: 

  • Verify that Replication Manager is able to decompress the *.rpl package files. After they are decompressed, verify that Replication Manager is processing them properly. 

Cc723594.smc1711(en-us,TechNet.10).gif

Scheduler and Sender

Scheduler and Sender are both thread components. Scheduler manages data transfer between sites, based on user-defined addresses and sending schedules. There are several types of senders, depending on your network connectivity options. For example, the Standard Sender uses the existing connectivity system to communicate with other sites. Standard Sender manages the connection, ensures the integrity of transferred data, recovers from errors, and closes connections to another site when they are no longer needed. This chapter includes one flowchart that combines both the Scheduler and Sender thread components.

The activity described in this flowchart takes place 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 17.13 Status Message Components and Log Files for Scheduler and Sender 

Server components

Log files

Scheduler

SMS\Logs\Sched.log

Sender

SMS\Logs\Sender.log

Troubleshooting Tips

When package distribution to a child site fails during the send phase:

  • Verify that SMS components can successfully send information in the form of files and requests to other sites in the hierarchy by using the Scheduler and Sender. Examples include collection updates, inventory MIFs from child site to parent site, discovery records, and package distribution. 

  • When a package is created and distributed from the parent site to the child site, verify that Distribution Manager successfully created a send request for Scheduler in the SMS\Inboxes\Schedule.box\Requests directory.

  • Check to see if Scheduler creates an instruction file for the Sender based on the send request. Also check to see if a despooler instruction file was created for the destination site Despooler and a compressed package file was created with the actual data to be transferred. 

  • Study the Scheduler status messages to see if Scheduler successfully completed the operation or if it encountered problems. Sched.log also records the same information. 

  • Verify that Sender received a send request from Scheduler. Sender monitors its outbox for send requests from Scheduler. When Sender finds a send request, it renames it to an in-process send file and connects to the destination site to transfer the data. 

  • Verify from the SMS\Inboxes\Schedule.Box\Outboxes\Lan (in case of the Standard Sender) that the Sender is working on the send request and that a *.srs file exists. Sender renames the send request file, *.srq, to an in-process send file, *.srs, first, and then it attempts to connect to the destination server. 

  • Verify whether Sender is able to connect to the \\<ServerName>\SMS_<SiteCode> share of the destination server. When Sender cannot connect, it records an error status message and places the send request in the Retry queue to work on it later. The same information is also recorded in the Sender.log file. 

  • Verify that Despooler is able to copy the despooler instruction files and the compressed package files from the \\<ServerName>\SMS_<SiteCode> share. When the copying is successful, Despooler records a success status message and closes the sending thread. 

If Sender is unable to connect to the destination site: 

  • Verify that the both the sending site and the receiving site are set to the same time.

  • Check the Sender priority settings. If Sender is restricted from connecting to the destination site during the day or only certain priority send requests are allowed to go, then other send requests will be queued up to go during a time when Sender is not restricted from connecting to the destination site. 

    You can check these properties in the Sender Address Properties dialog box on the Schedule and Rate Limits tabs. 

  • Check for network connectivity problems to and from the site server. Connectivity problems may cause the Sender's request processing to be backed up. When the network connectivity is restored, it might take some time to recover from the resulting backlog. Sender records status messages and log file entries in such a case. 

When package distribution to a child site fails at the destination site: 

  • Verify that Sender from the sending site can connect to the destination site and copy files and instructions to the destination site's \\<ServerName>\SMS_<SiteCode>\Inboxes\Despoolr.box. 

    Verify that Despooler successfully renames any incoming package to a *.pck file and any incoming despooler instruction file to an *.ins file before processing.

    • Verify, from the destination server's \\<ServerName>\SMS_<SiteCode>\Inboxes\Despoolr.Box\Receive directory that the incoming *.p* file is renamed to a *.pck file indicating that Despooler has received the package and has started processing it. 

    • Verify, from the same directory, whether there are any *.tmp files left. If so, then Sender from the sending site has probably either not completed sending the despooler instruction file, or it has failed during the process. Once the Despooler receives the complete file, it renames the *.tmp file to an *.ins file (instruction file). 

  • Verify whether Despooler processes the package based on the *.ins file and records status messages to indicate progress. 

  • Verify, from the Despooler status messages that Despooler was successful or that it failed during this operation. The same information is also recorded in the Despool.log file. 

  • Verify that Replication Manager received the *.pck file from Despooler. 

  • Verify that Distribution Manager received the package from Replication Manager and successfully processed it. 

Cc723594.smc1712(en-us,TechNet.10).gif

Despooler

Despooler is a thread component that watches for despooler instruction files and compressed packages that are created by Scheduler or Distribution Manager. The instructions and packages can come from the local site or from another site. Despooler decompresses the instruction file and writes the compressed package.

The activity described in this flowchart takes place on 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 files and status messages associated with this thread 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 17.14 Status Message Component and Log File for Despooler 

Server component

Log file

Despooler

SMS\Logs\Despool.log

Troubleshooting Tips

The Despooler flowchart branches out into five separate operations from the point where Despooler reads the instruction file. Tips for each operation are included below.

When a distributed package does not appear on a Distribution Point: 

  • Verify that Sender from the site server placed a package replication *.ins file in the \\<ServerName>\SMS_<SiteCode>\Despoolr\Receive directory on a distribution point. When it receives a directory change notification, Despooler processes the instruction file. 

  • Verify that Despooler opened the *.ins file and determined that this is a package instruction file. You can do this by checking to see if Despooler decompressed and copied the package to the local site server. Despooler also saves the package information in the \\<ServerName>\SMS_<SiteCode>\Inboxes\Distmgr.box\Incoming directory. 

  • Verify that SMS SQL Monitor successfully wrote a *.pkn file to the Distribution Manager inbox. Despooler writes the package definition to the SMS site database and generates a SQL trigger. SMS SQL Monitor then writes a *.pkn file to the Distribution Manager inbox, which signals Distribution Manager to begin distributing the package within the site. Despooler generates status messages that indicate when the above operation fails.

  • Verify that the package instruction file is written to the \\<ServerName>\SMS_<SiteCode>\Despoolr.box\Receive directory by the Sender (by using status messages and Sender.log entries). 

  • Verify that Despooler was successfully able to read the instruction file, decompress the package, and copy it to the site server. Use the status messages for the Despooler and the Despool.log file. 

  • Verify the package processing by studying the Distmgr.log file. 

SMS 2.0 or SMS 1.2 child sites send client inventory MIF files to parent sites by using Replication Manager and by using Sender. Despooler receives the Replication Instruction file and parses it to see if it came from an SMS 1.2 child site or an SMS 2.0 child site. When child site client inventory does not appear in the parent site's database: 

  • If the files came from an SMS 2.0 child site, verify that Despooler copied the files to the \\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box directory, if the files came from an SMS 2.0 child site. A directory change notification is also generated to inform the Inventory Data Loader that new files are available for processing. Use the Despooler-generated status messages and Despool.log entries to verify that this operation was successful. 

  • If the files are from an SMS 1.2 child site, verify whether Despooler discarded the files. Despooler determines whether the files are package status files or inventory MIF files. If neither, Despooler discards them and records status messages. 

  • If the files are inventory MIF files from the SMS 1.2 child site, verify that Despooler handed them off to Inventory Data Loader in the same fashion as it does the MIF files from the SMS 2.0 child site. 

  • If the files are package status files from an SMS 1.2 child site, verify that Despooler converted them to SMS 2.0 package status files and copied them to the \\<ServerName>\SMS_<SiteCode>\Inboxes\Distmgr.box directory for Distribution Manager to process. 

  • Verify from the Despool.log and/or the Despooler Status messages whether the above steps were successful or failed. Despooler records status messages for each step. 

SMS 2.0 central sites use fan-out distribution for packages. If a grandchild site is targeted for the package, the central site can send the package instruction file to its immediate child, who is the parent of the grandchild site. If a package distribution from a central site to a grandchild site fails at the middle parent site: 

  • Verify that Sender from the central site copied the package-routing instruction file to the mid-level parent site in the \\<ServerName>\SMS_<SiteCode> \Inboxes\Despoolr.box\Receive directory. 

  • Check the Despooler status messages (or Despool.log file) at the mid-level parent site to see if Despooler successfully determined, from the routing instruction file, which child site the package was to go to and created a request for the Scheduler to send the package to the grandchild site. 

  • Check the Despooler status messages (or Despool.log) from the mid-level parent site to see if Sender from the central site successfully transferred the package routing instruction file to the mid-level parent. 

  • Determine, from the mid-level parent site's Despooler status messages (or Despool.log), whether Sender was successfully able to hand off the package to Scheduler to send to the grandchild site. 

If the SMS 1.2 child site's site control file updates do not get written to the parent site's SMS site database: 

  • Verify that Depooler received the site control file updates. Updates from the SMS 1.2 child site are handled by Despooler when they first arrive at the SMS 2.0 parent site. 

  • Verify that Despooler parsed the files and that Sender at the SMS 1.2 child site wrote the files in the \\<ServerName>\SMS_<SiteCode>\SMS\Inboxes\Despoolr.box\Receive directory. Despooler then determines whether the file is a site control file update and hands it off to Hierarchy Manager to write to the SMS site database. 

  • Verify that Hierarchy Manager at the SMS 2.0 parent site wrote the site control file update information to the SMS site database. 

  • Determine whether Despooler recorded success in handing off the SMS 1.2 site's Site Control File updates to Hierarchy Manager, then determine from the status messages generated by Hierarchy Manager whether Despooler was successful in connecting to the SMS site database and writing the site control file updates. 

If inventory resync requests are not successfully sent from the parent to the child site: 

  • Verify that the inventory resync request was received at the \\<ServerName>\SMS_<SiteCode>\Inboxes\Despoolr.box\Receive directory at the child site. When an inventory resync is requested from the parent site for the child site's clients, Sender sends the request to the child site and copies it to the Despoolr.box\Receive directory of the child site. 

  • Verify that Despooler parsed the instruction file and added the resync request to the *.cfg file in the \\<ServerName>\SMS_<SiteCode>\Clidata.src directory. 

  • Check to see whether Despooler recorded the generation of the resync request at the local site in the form of status messages and Despool.log file entries. 

  • Determine from the .cfg file updates in the \\<ServerName>\SMS_<SiteCode>\Clidata.src directory whether Despooler successfully processed resync requests from the parent site. Clients that belong to the child site will not receive the resync request unless the above processing takes place and Inbox Manager copies the .cfg files to the CAPs. 

Cc723594.smc1713(en-us,TechNet.10).gif

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