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.