Understanding and Troubleshooting Content Distribution in Microsoft Configuration Manager

What does this guide do?

This guide helps administrators understand the content distribution process and serves to build a foundation for diagnosing and resolving general content distribution related problems in the following products:
  • Microsoft System Center 2012 Configuration Manager (ConfigMgr 2012)
  • Microsoft System Center 2012 R2 Configuration Manager (ConfigMgr 2012 R2)
  • Microsoft System Center Configuration Manager current branch (1502, 1602, etc.)
Who is it for?
This guide is for administrators charged with managing content distribution in a Microsoft Configuration Manager environment and troubleshooting related issues.

How does it work?
This guide explains the content distribution process, including Distribution Point (DP) installation and upgrade, the content library, package creation and distribution, as well as the various threads and components involved. Troubleshooting tips and useful SQL queries are also provided.

Estimated time of completion:
30-60 minutes.
Getting Started
This guide is divided up into six core sections:
  • Installing and Managing Distribution Points
  • Understanding the Content Library
  • Understanding Package Creation and Deployment
  • Understanding Components and Threads
  • Troubleshooting
  • Useful SQL Queries

In order to fully understand and successfully troubleshoot content distribution problems, it is recommended that you start at the beginning with Installing and Managing Distribution Points and work through the entire guide. However, if you’d rather focus on a particular section you can select it below.

Getting Started
This guide is divided up into six core sections:
  • Installing and Managing Distribution Points
  • Understanding the Content Library
  • Understanding Package Creation and Deployment
  • Understanding Components and Threads
  • Troubleshooting
  • Useful SQL Queries

In order to fully understand and successfully troubleshoot content distribution problems, it is recommended that you start at the beginning with Installing and Managing Distribution Points and work through the entire guide. However, if you’d rather focus on a particular section you can select it below.

Installing and Managing Distribution Points
The Distribution Point (DP) installation process involves the steps listed below. These steps cover a typical DP installation initiated from the Configuration Manager console after the administrator has finished the DP installation wizard. Each step is described, followed by an example of how the step can be monitored by examination of the associated log file. If you have a problem with DP installation, the log files should show you exactly where in the process the problem is occurring and provide vital clues to why the process is failing.

Step 1: The console creates an instance of the SMS_SCI_SysResUse WMI class
Step 2: The boundary group is configured
Step 3: SMSDBMON notifies HMAN to process the site control file for changes
Step 4: HMAN distributes the default client packages and updates the certificate
Step 5: HMAN finishes processing the site control file and raises a status message
Step 6: SMSDBMON instructs DistMgr to begin the DP installation
Step 7: Threads are created for DP installation
Step 8: The DP and optional roles are installed
Step 9(optional): PXE is install if enabled
Step 10: Status message raised noting that the installation is complete
Step 11 (for pull DPs only): DP upgrade worker thread run pulldp.msi to perform the pull DP installation
Understanding the Content Library
The content library is a new concept that was introduced in System Center 2012 Configuration Manager.  In a nut-shell, the content library stores all of the Configuration Manager content efficiently on the disk. The content library optimizes disk storage to avoid redistributing a file that already exists on the distribution points. For example, if two different packages each contain a particular file that is identical, even if the file names are different, only one copy of this file will be stored by the content library. This minimizes the disk space consumption.

The way it works is that when distributing a package, Configuration Manager analyzes all of the files in that package. If a file is already present on the distribution point as part of another package, or as part of a previous version of the same package, that file is not copied to the distribution point.  Instead, a mapping reference is added between that file and the new package. This helps reduce the network traffic by not copying files that already exist. Additionally, it allows for more rapid provisioning of packages on the distribution point.

Location of the Content Library

A copy of the content library (containing all packages) is housed on the site server as the source for distribution points. Moreover, each distribution point will have a copy (as the source for clients) containing the packages distributed to the distribution point. The content library is designed to optimize both network and disk usage in the distribution process which helps keep costs low and maximize efficiency. The content library is typically stored on the root of a drive in a folder called SCCMContentLib. This folder is shared and has restricted permissions to prevent accidental damage. Within this are the Package Library (the PkgLib folder), the Data Library (the DataLib folder) and the File Library (the FileLib folder). The Package Library contains information about what packages are present on the distribution point. The Data Library contains information about the original structure of the packages. The File Library contains the original files in the package; this is typically where the bulk of the storage is used.

For example, in the screenshot below, the content library is located on the root of the C: drive in C:\SCCMContentLib and is shared as SCCMContentLib$.  Regardless of which drive the content library is located on, the primary share location will always be SCCMContentLib$.
4000401_P3_IMG1
 

Here’s a diagram showing these relationships:
4000401_P3_IMG2
 

Exploring the Content Library

The starting point for exploring the content library is the Package Library folder PkgLib.  Within this folder will be several files: One for each package distributed to the distribution point.  The name will be the package ID (e.g. ABC00001.INI) and in this file is a list of content IDs (under the “[Packages]” section) that are part of the package, as well as other information such as the version. Using these content IDs, we can continue exploring the contents of the content library. 

So let’s assume that ABC00001 is a legacy-style package at version 1, thus the content ID in this file will be ABC00001.1. In the Data Library folder (DataLib) there will be one file and one folder for each of the content in each package. In our example, this file and folder will be named ABC00001.1.INI and ABC00001.1, respectively.  The INI file contains information for validation. Inside the folder, the folder structure from the original package is recreated, however the files in the Data Library are replaced by INI files that have the name of the original file in the package (e.g. MyFile.exe.INI). These files contain information about the original file such as the size, time modified and the hash.  The first four characters of the hash will help us find where the original file is in the File Library.  For example, suppose that the hash in MyFile.exe.INI is DEF98765.  Thus, the first four characters are DEF9.

The last step is to locate the file in the File Library (FileLib).  Note that if the content library spans multiple drives, the files could be in the File Library on any of these drives. Using the first four characters from the hash found in the Data Library, we can locate the file. Inside the File Library folder will be many folders, each with a four-character name, so find the folder that matches the first four characters from the hash.  Remember that the folder may be in the File Library on a different drive. Once this folder is found, it will contain one or more sets of three files. These three files will share the same name, but one will have the extension INI, one will have the extension SIG, and one will not have any extension at all. The file with no extension is the original file. Using the example above, we would look for folder DEF9 which will contain DEF98765.INI, DEF98765.SIG and DEF98765.  Here, DEF98765 is MyFile.exe.  Additionally, in the INI file, there will be a list of “users” which are actually content IDs that share the file.  The file will never be removed unless all of these contents are also removed.

The Difference Between Distribute, Update and Redistribute Actions

The first major action pertaining to content distribution is the Distribute action.  This refers to the initial distribution of a package to a distribution point. This is triggered with Distribute Content in the Configuration Manager console. This will transfer all files in a package to the target distribution points, excluding those which are already present as part of another package—these will become shared.
The second major action is the Update action.  This is typically used when a package has been changed and all distribution points to which it is distributed need the updated content. This is triggered with Update Distribution Points in the console.  This will transfer the changed files to all distribution points. Unchanged files will not be transferred. If a file is removed from the package in the updated version, it will be deleted from the package on the distribution point as long as no other packages are sharing it.
The third major action is the Redistribute action, triggered with Redistribute in the Configuration Manager console. This will transfer the entire contents to a specific distribution point. Files will be transferred and overwritten even if they are already present on the distribution point. The chief purpose of the Redistribute action is to correct any inconsistencies that may exist in the content library.

The Content Library Explorer Tool

There is a new tool available in the System Center 2012 R2 Configuration Manager toolkit called Content Library Explorer. This tool facilitates user-friendly exploration of the contents of the content library.  This tool cannot be used to modify the contents, however it can provide insight into what is present as well as allowing validation and redistribution.  Please refer to the toolkit documentation for more information. This documentation is installed with the toolkit and there is typically a shortcut for it in the Start menu called System Center 2012 R2 Configuration Manager Toolkit Help. You can find more about the Configuration Manager Toolkit here.

Drive Spanning

The content library can be spanned across multiple drives. These drives can be manually chosen by the administrator at the time the distribution point is created, or they can be chosen automatically by Configuration Manager (this is the default setting).
If the drives are chosen manually by the administrator, a primary and secondary drive can be specified. On the primary drive, all metadata will be stored, and only the File Library will be spanned across to the secondary drive. On secondary drives, the folder’s share name includes the drive letter.  For example, if D: and E: are secondary drives for the content library, the share names would be SCCMContentLibD$ and SCCMContentLibE$, respectively.
If Automatic is chosen, Configuration Manager selects the drive with the most available free space as its primary drive. All of the metadata will be stored on this drive with only the File Library spanned across to secondary drives.  The administrator selects a reserve space amount and Configuration Manager attempts to use a secondary disk once the best available disk has only this amount of reserve space left free. Each time a new drive is selected for use, the drive with the most available free space is selected.
Currently it is not possible to specify that a distribution point should use all drives except for a specific set from the console. However, a drive can be excluded by creating an empty file on the root of the drive called NO_SMS_ON_DRIVE.SMS.  This file must be present before the drive is selected for use by Configuration Manager. If Configuration Manager detects this file on the root of the drive, it will not use the drive for the content library.  Additionally, there is a command-line tool in the toolkit for permanently moving the content library to a different drive called ContentLibraryTransfer.exe.

Modifying the Content Library

It is not recommended to alter, add or remove any files or folders in the content library, as doing so could corrupt packages, contents or the content library as a whole.  If missing, corrupt or otherwise invalid data is suspected, the validation feature in the Configuration Manager console should be used to detect this, and the redistribution feature used to correct it.

Troubleshooting the Content Library

Here are a few tips for troubleshooting issues with the content library:
  • Check the logs on both the site server (distmgr.log and PkgXferMgr.log) as well as on the distribution point (smsdpprov.log) for any pointers to the failures.
  •  Use the Content Library Explorer tool to gain additional insights.
  •  Check if there are any file locks by other processes (e.g. antivirus) or other software.  It is a good practice to exempt the content library on all drives from automatic antivirus scans, as well as the temporary staging directory (SMS_DP$) on each drive. 
  • If you still have issues you can try validating the package from the Configuration Manager console and see if there are any hash mismatches.
  • As a last option, you can redistribute the content, which should resolve the issue.
Understanding Package Creation and Deployment
Before taking a look at package creation and deployment, let’s take a minute to review again the differences between Distribute, Update and Redistribute actions.
The first major action pertaining to content distribution is the Distribute action.  This refers to the initial distribution of a package to a distribution point. This is triggered with Distribute Content in the Configuration Manager console. This will transfer all files in a package to the target distribution points, excluding those which are already present as part of another package—these will become shared.
The second major action is the Update action.  This is typically used when a package has been changed and all distribution points to which it is distributed need the updated content. This is triggered with Update Distribution Points in the console.  This will transfer the changed files to all distribution points. Unchanged files will not be transferred. If a file is removed from the package in the updated version, it will be deleted from the package on the distribution point as long as no other packages are sharing it.
The third major action is the Redistribute action, triggered with Redistribute in the Configuration Manager console. This will transfer the entire contents to a specific distribution point. Files will be transferred and overwritten even if they are already present on the distribution point. The chief purpose of the Redistribute action is to correct any inconsistencies that may exist in the content library.

Package Creation

The following steps explain the flow of events when you create a new package from the administrator console:
  1. Admin Console creates an instance of the SMS_Package WMI class. 
  2. SMSDBMON detects a change and notifies DistMgr to process the package by creating a <PackageID>.PKN file. 
  3. DistMgr processes the package on the package source site.
    1. The main DistMgr thread creates a package processing thread.
    2. The package processing thread creates a package snapshot and writes content in the content library.
    3. The package processing thread replicates the package to other sites.
    4. The package processing thread exits. 
  4. (If applicable) DRS replicates the package to other sites. 
  5. (If applicable) SMSDBMON on the receiving site notifies DistMgr by creating a  <PackageID>.PKN file. 
  6. (If applicable) DistMgr on the receiving site processes the package.
    a.The main DistMgr thread creates a package processing thread.
    b.The package processing thread processes the package.
Now let’s take a look at each of these and follow along via the log files.

 
Step 1: The console creates an instance of the SMS_Package WMI class
Step 2: DistMgr is notified to process the package
Step 3: DistMgr processes the package after detecting the PKN file in DistMgr.box
Step 4(if applicable): Package metadata information is replicated
Step 5(if applicable): DistMgr is notified to processes the package on the receiving site
Step 6(if applicable): DistMgr on the receiving site processes the package
Distributing a package that exists in the Content Library
The following steps outline the flow of events when a package is distributed to a DP in the primary site and the primary site server in question already has a copy of the package in the content library.
  1. The administrator distributes the package to the DP. The administrator can do so from the administrator console connected directly to the primary site in question or CAS, or a different primary site.
  2. If the administrator distributes the package from a different primary site or CAS, the Database Replication Service (DRS) replicates changes to the site in question.
  3. SMSDBMON notifies DistMgr to process the package.
  4. DistMgr wakes up to process the package. 
    1. The main DistMgr thread starts a package processing thread. 
    2. The package processing thread creates DP threads to process package actions, then waits for them to exit.
    3. The DP threads create a Package Transfer Manager (PkgXferMgr) job to transfer content to the DPs and then exits.
    4. The package processing thread exits after all DP threads exit.
  5. SMSDBMON notifies PkgXferMgr to process the job.
    1. The main PkgXferMgr thread creates a sending thread.
    2. The sending thread copies content to the DP.
    3. The sending thread sends a status message to DistMgr.
  6. PkgXferMgr wakes up to process the job.
  7. SMS DP Provider adds the content to the content library.
  8. DistMgr processes the status messages sent by PkgXferMgr.
  9. Package status changes are replicated to other sites via DRS.
Now let’s take a look at each of these and follow along via the log files.
 
Step 1: The console adds the specified DP to the package
Step 2: DRS replicates the changes
Step 3: DistMgr is notified to process the package
Step 4: DistMgr processes the package and creates a PkgXferMgr job
Step 5: PkgXferMgr is notified to process the job
Step 6: PkgXferMgr wakes up to process the package.
Step 7: The content is added to the content library
Step 8: The package status is updated in the database
Step 9: Status is replicated to the other sites

Distributing a package that does not exist in the Content Library
The following steps outline the flow of events when a package is distributed to a DP in the primary site but the primary site server in question does not contain a copy of this package in the content library. This package was created on the CAS site and as a result, CAS is the package source site:

On the Package Source Site:

  1. The admin console adds the DP to the package by calling the AddDistributionPoints method on the SMS_Package WMI class.
  2. SMSDBMON detects the package change and notifies DistMgr by dropping a <PackageID>.PKN file in DistMgr.box.
  3. DistMgr wakes up to process the package.
    1. The main DistMgr thread creates the package processing thread.
    2. The package processing thread processes the package actions.
    3. The package processing thread creates a mini-job to send the compressed copy of the package to the destination site.
    4. The package processing thread exits.
  4. The scheduler component processes the mini-job created by the package processing thread and creates a send request.
  5. The sender component starts working on the send request.
    1. The main sender thread starts a sending thread.
    2. The sending thread copies the compressed package file (PCK file) to the destination site along with the package instruction file (SNI file).
  6. The scheduler component marks the job as completed and deletes the send request.

On the Destination Site:

  1. Despooler processes the PCK and SNI files.
    1. The main despooler thread creates a despooling thread.
    2. The despooling thread processes the instruction and writes content to the content library.
    3. The despooling thread updates Type 1 row for the receiving site in PkgStatus.
  2. SMSDBMON notifies DistMgr to process the package.
  3. DistMgr wakes up to process the package.
    1. The main DistMgr thread creates a package processing thread.
    2. The package processing thread creates DP threads to process package actions and waits for them to exit.
    3. The DP threads create a PkgXferMgr job to transfer content to the DPs and then exits.
    4. The package process thread exits after all DP threads exit.
  4. SMSDBMON notifies PkgXferMgr to process the job created in Step 9c.
  5. PkgXferMgr wakes up to process the job.
    1. The main PkgXferMgr thread creates a sending thread.
    2. The sending thread copies the content to the DP.
    3. The sending thread sends a status message to DistMgr.
  6. SMS DP Provider adds the content copied in Step 11b to the content library.
  7. DistMgr processes the status message sent in Step 11c.
  8. Package status changes are replicated to other sites via database replication.
Now let’s take a look at each of these and follow along via the log files.

Detailed flow with log snippets (sending site)


Step 1: The console adds the specified DP to the package
Step 2: DistMgr is notified to process the package
Step 3: DistMgr processes the package and creates a PkgXferMgr job
Step 4: The scheduler component creates a send request to send the package to the destination site
Step 5: The sender component processes the send request and sends the compressed copy of the package to the destination site
Step 6: The scheduler component marks the job as complete
Step 7: Despooler on the receiving site begins processing the files
Step 8: DistMgr is notified to process the package
Step 9: DistMgr processes the package and creates a PkgXferMgr job
Step 10: PkgXferMgr is notified to process the job
Step 11: PkgXferMgr wakes up to process the package.
Step 12: The content is added to the content library
Step 13: The package status is updated in the database
Step 14: Status is replicated to the other sites
Updating a Package
When you update a package, the package content is resent to all of the distribution points that the package was distributed to. This is done by incrementing Package Source Version, and only the content changes are sent to the DPs instead of sending all of the content again.

The following steps outline the flow of events that occur when a package is updated. In this example, we will look at the package update operation for a package that was created at a primary site and focus on process changes specific to the package update operation. 

  1. The admin console executes the RefreshPkgSource method against the SMS_Package WMI class in the SMS Provider namespace. 
  2. SMSDBMON notifies DistMgr to process the package. 
  3. DistMgr wakes up to process the package. 
    1. The main DistMgr thread starts a package processing thread.
    2. The package processing thread creates a package snapshot, writes content to the content library and increments the package version.
    3. The package processing thread processes starts DP threads to process package actions then waits for them to exit.
    4. The DP threads start and create PkgXferMgr jobs to transfer content to the DPs, then exit.
    5. (if applicable) The package processing thread creates a mini-job to send the compressed copy of the package to other sites.
    6. The package processing thread exits.
  4. SMSDBMON notifies PkgXferMgr to process the job. 
  5. PkgXferMgr wakes up to process the job. 
    1. The main PkgXferMgr thread creates a sending thread for each job. 
    2. The sending thread copies content to the DP. 
    3. The sending thread sends a status message to DistMgr. 
  6. SMS DP Provider adds content to the content library. 
  7. DistMgr processes the status messages sent by PkgXferMgr. 
  8. The package status changes are replicated to other sites via DRS. 
Now let’s take a look at each of these and follow along via the log files.
 
Step 1: The console notifies SMS Provider that a package has been updated
Step 2: DistMgr is notified to process the package
Step 3: DistMgr processes the package and creates a PkgXferMgr job
Step 4: 
Step 5: PkgXferMgr wakes up to process the package.
Step 6: The content is added to the content library
Step 7: The package status is updated in the database
Step 8: Status is replicated to the other sites
Redistributing a Package
When you redistribute a package to a DP, all of the package content files are re-copied to the DP even if the content already exists in the content library on the DP.

The following steps outline the flow of events that occur when a package is redistributed to a DP. In this example, the primary site server already has a compressed copy of the package. This process is identical to the process outlined in Distributing a package that exists in the Content Library above so here we only look at detailed log snippets for PkgXferMgr.
  1. Administrator distributes the package to the DP.
  2. SMSDBMON notifies DistMgr to process the package.
  3. DistMgr wakes up to process the package.
    1. The main DistMgr thread starts a package processing thread.
    2. The package processing thread creates DP threads to process package actions and waits for them to exit.
    3. The DP threads create a PkgXferMgr job to add the package to the DPs and then exits. 
    4. The package processing thread exits after all DP threads exit.
  4. SMSDBMON notifies PkgXferMgr to process the job.
  5. PkgXferMgr wakes up to process the job.
    1. The main PkgXferMgr thread creates a sending thread.
    2. The sending thread copies content to the DP.
    3. The sending thread sends a status message to DistMgr.
  6. SMS DP Provider adds the content to the content library.
  7. DistMgr processes the status messages sent by PkgXferMgr.
  8. Package status changes are replicated to other sites via DRS.

Details of Step 3
Details of Step 5

Understanding Components and Threads

In this section we’ll take a look at the following:

  • The components used for content distribution
  • The Distribution Manager (DistMgr) threads
  • Distribution Manager thread configuration
  • Server thread configuration
  • Bandwidth control and threads

The components used for content distribution

Here’s a quick list of the primary components used for content distribution:
 Name  Component Name  Friendly Name  Description
 Distribution Manager  SMS_DISTRIBUTION_MANAGER  DistMgr Manages content and creates jobs for PkgXferMgr
 Package Transfer Manager  SMS_PACKAGE_TRANSFER_MANAGER  PkgXferMgr  Transfers packages to distribution points
Hierarchy Manager  SMS_HIERARCHY_MANAGER  Hman  Processes and replicates changes to the site hierarchy
 Sender  SMS_SENDER  Sender Initiates inter-site communications across TCP/IP networks
 Despooler  SMS_DESPOOLER  DespoolerProcesses incoming replication files from parent or child sites
 Scheduler  SMS_SCHEDULER  Scheduler Creates sender jobs
Database Notification Monitor  SMS_DATABASE_NOTIFICATION_MONITOR  SmsDbMon Watches the database for changes to certain tables and creates files in the inboxes of components responsible for processing those changes
 SMS Provider  SMS Provider  SMSProv Windows Management Instrumentation (WMI) Provider that assigns read and write access to the Configuration Manager database at a site
 SMS DP Provider  SMS DP Provider  SMSDPProv  Windows Management Instrumentation (WMI) Provider that manages Content Library operations on the DP

The Distribution Manager threads

Distribution Manager (DistMgr) performs a variety of operations to distribute content to the distribution points (DPs). These operations are handled by the different types of threads, and the diagram below explains the DistMgr thread hierarchy for the default thread configuration:

4000401_P9_IMG3
 

The Main DistMgr Thread

Log entry for identification: SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER as thread ID 3648 (0xE40)
This thread is started by SMS_Executive on service startup. The main DistMgr thread starts Replication Processing, DP Manager, Content Cleanup and Upgrade Processing threads when it starts. It also starts package processing threads on-demand when a package change occurs.
In addition to managing these threads, this thread also handles changes to the Site Control File and updates DP settings (Configure DP/PXE, update registry settings, create monitoring/usage tasks on the DP, etc.).

Replication Processing Thread

Log entry for identification: Starting thread for processing replication, thread ID = 0x1A14 (6676)
This thread is started by the main DistMgr thread and processes the following files in the DistMgr.box\incoming directory: 

 STA  Updates package status in the PkgStatus table in the database.
 FWDForwards the specified package to the specified destination site by creating a mini-job to send the package.
 DMDDistributes on demand requests. Targets the specified package to the specified DP.
 PUL  Updates the pull DP package response in the PullDPResponse table in the DB.

DP Manager Thread

Log entry for identification: Starting the DP Manager thread, thread ID = 0x5D8 (1496)
This thread is started by the main DistMgr thread and processes update/removal of distribution points when detecting a Site Control File change. When an appropriate Site Control File change occurs, SMSDBMON drops a DPN (DP Notification) file or a DPU (DP Update) file in DistMgr.box. These files are processed by this thread.
DPN files notify of a DP change, which involves DP removal (detected by Action = 3 in the DistributionPoints table).DPU files are used to notify that a DP Update needs to be performed for migrated DPs.

Content Cleanup Thread

Log entry for identification: Starting the content cleanup thread, thread ID = 0x1604 (5636)
This thread is started by the main DistMgr thread and runs content cleanup. It determines if content cleanup is required by detecting orphaned content from the database.

Upgrade Processing Thread

Log entry for identification: Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)
This thread is started by the main DistMgr thread and handles DP installations and upgrades for standard and pull distribution points. This thread reads the DPUpgradeThreadLimit Site Control File (SCF) property for the SMS_DISTRIBUTION_MANAGER component to determine the number of threads it can start for performing DP installations/upgrades simultaneously. The default value of the DPUpgradeThreadLimit SCF property is 50, however if this SCF property does not exist for some reason, a smaller default value of 5 is used for DPUpgradeThreadLimit.

Package Processing Thread

Log entry for identification: Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)
These threads are started by the main DistMgr thread. The number of package processing threads is determined by the Maximum number of packages thread setting in the Software Distribution Component Configuration properties. Each package processing thread performs the hashing of the package content and creates a compressed copy of the content.
NOTE: Although all package processing threads run simultaneously, they are responsible for hashing and compressing package source. There is a Critical Section around the compression, meaning only one thread can be compressing content at a time. If a bunch of new, large packages are created and distributed, the per-package threads can block in a chain, each waiting for their turn to get the compression lock.
Depending on the package actions (add/update/delete), each package processing thread also creates:
  • DP threads to create a Package Transfer Manager job for adding/updating content on a distribution point.
  • DP threads to instruct a remote distribution point to remove content from the content library.
The number of DP threads each package processing thread can create is determined by the Maximum threads per package setting in the Software Distribution Component Configuration properties.

Distribution Manager Thread Configuration
All Configuration Manager sites (including the CAS) allow configuring the number of threads that can be used for distributing content to the distribution points (DPs). This configuration is specific to each site and can be accessed by right-clicking the site under the Sites node and selecting Configure Site Components -> Software Distribution. Here’s a look at the default configuration:
Asset not found 
In most cases, you would only be concerned with the Maximum number of packages and Maximum threads per package settings.
  • Maximum number of packages: Specifies the maximum number of packages that ConfigMgr can send to the DPs simultaneously. The specified value should be between 1 and 50.
  • Maximum threads per package: Specifies the maximum number of threads allocated to each package during distribution. Specified value should be between 1 and 999.
The default configuration of Maximum number of packages=3 and Maximum threads per package=5 can also be referred to 3x5. This is how the thread configuration will be often be denoted.

What does this really mean?

Effect on Distribution Manager (DistMgr): With the default thread configuration of 3x5, DistMgr can simultaneously process 3 packages and use up to 5 threads for each package, allowing it to use up to a total of 15 threads to perform work. Here's how this breaks down assuming we have more than 3 packages that need to get distributed to more than 5 DPs:
Asset not found 
To process each individual package, a package processing thread is spawned by the main DistMgr thread. This package processing thread uses one out of 3 package processing slots from the Maximum number of packages setting. Note that there is a unique package processing thread per package - DistMgr does not spin up multiple package processing threads for the same package. This means that 3 unique packages will utilize 3 unique package processing threads. Each of these package processing threads can spawn up to 5 DP threads to distribute the package to 5 DP's simultaneously.

Effect on Package Transfer Manager (PkgXferMgr)

For each PkgXferMgr job created by DistMgr, PkgXferMgr uses 1 thread. Thread configuration of 3x5 means that the sending capacity for PkgXferMgr is set to 15, which means that PkgXferMgr cannot work on more than 15 jobs simultaneously, limiting it to a maximum of 15 threads.

How long does a thread run? Is this even important?

DistMgr threads:
The purpose of a DP thread is to create a job for Package Transfer Manager, which then does the actual content copy to the DP. DP threads finish after creating the PkgXferMgr job, and as a result, the lifetime of a DP thread is usually very short. Due to this nature, most of the time there is no need to set up aggressive thread configuration to speed up content distribution. Instead of setting aggressive values, look towards finding a balance (more on this below).
PkgXferMgr threads:
For standard DPs, since PkgXferMgr threads perform the real work of sending the content, the lifetime of these threads depends on the size of the packages. For larger packages, these threads can take a long time depending on the package size, network speed, etc. While these threads can take a long time to complete, the lifetime of DistMgr threads is much shorter which means that DistMgr can queue a large number of jobs for PkgXferMgr, creating a backlog of jobs in the queue.
For pull DPs, PkgXferMgr threads simply notify the pull DP, asking the pull DP to download the content. As a result, the lifetime of PkgXferMgr threads for pull DPs is usually very short. PkgXferMgr does start another thread to perform pull DP polling (based on the configured polling interval) to check on the progress of the job, however this is also a quick operation and these threads do have a short lifetime as well.

Choosing the right values

To determine the appropriate values for these settings, you first need to understand the Configuration Manager hierarchy. Let's consider the following hypothetical Configuration Manager environment:
  • Central Administration Site: CS1
  • Primary Site: PS1
  • Number of regular Distribution Points reporting to PS1: 200
  • Total number of packages: 1000

In this environment, the default thread configuration (3x5) will mean that if a new package needs to get distributed to all 200 DP's, we will only process 5 DP's at a time. Once a DP thread exits, another DP thread will then spawn and the process will continue until all the DP's are processed. This process will take some time to loop through all 200 DPs.
To optimize this, we first need to ask a couple of questions:
  1. How many packages do you foresee getting added/updated/distributed simultaneously on an average?
  2. How many DPs do you have in the site? How is the network configuration between the site server and these DPs?
Assuming the answer to the first question is 5, and the answer to the second question is 200 with good network connectivity, you could theoretically set Maximum number of packages to 5 and Maximum threads per package to 200, allowing Configuration Manager to send up to 5 packages to all 200 DPs simultaneously. However, this means that when there is more than the average load we can create up to 1000 threads, which is a lot of threads. More threads are usually good, but not always since the work being performed also relies on hardware and network configurations. Too many threads can sometimes cause bottlenecks and slow things down instead of improving them.
The most important thing to remember when configuring these settings is to find a balance. For the example above, a reasonable option would be to set the thread configuration to 5x100 (or even 5x50 depending on hardware/network) which still allows Configuration Manager to process up to 100 DP's simultaneously for 5 different packages. With these settings, the maximum number of threads that can spawn during high load will not exceed 500.
In the same hierarchy, you may run into a situation where you are bringing a new DP in the environment and you need to distribute all 1000 packages to the DP. In this case, thread configuration of 5x100 is not going to be very effective since we can only process 5 packages at a time, and processing a 1000 packages will take a considerable amount of time. In this scenario, you could choose to either:
  1. Temporarily set the thread configuration to something like 50x10 which is more suitable for the current requirement, but is not a good option in the long run considering we have 200 DPs.
  2. Permanently set the thread configuration to something like 20x25 which provides a far better balance and will offer similar performance in a scenario where more packages need to go to handful of DPs as well as a scenario where a handful of packages need to go to a lot of DPs.

The Bottom Line

There isn't a set recommendation on values for thread configuration; it varies for each environment and should be set after understanding your specific environment and requirements. Always remember to find a balance!
Sender Thread Configuration
Each Configuration Manager site (including the CAS and secondary sites) has one Sender. The sender manages the network connection from one site to a destination site, and can establish connections to multiple sites at the same time. To connect to a site, the sender uses the file replication route to the site to identify the account to use to establish the network connection. The sender also uses this account to write data to the destination site’s SMS_SITE share.
By default, Sender writes data to a destination site by using multiple concurrent threads. Each concurrent thread can transfer a different file-based object to the destination site. By default, when the Sender begins to send an object, it continues to write blocks of data for that object until the entire object is sent. 
All Configuration Manager sites allow you to configure the number of threads that can be used by the Sender component to send data concurrently to other sites. This configuration is specific to each site, and can be accessed from the Site Properties under the Sites node by selecting the Sender tab. Here’s a look at the default configuration:
Asset not found 
All Sites: The maximum number of simultaneous communications allowed for this sender. The default value is 5. These communications can be destined for different sites or all for the same site, except as restricted by the maximum value specified in Per Site.
Per Site: The maximum number of simultaneous communications allowed to any single destination site. The default value is 3.
NOTE: When configuring the total number of concurrent sending threads to be used when communicating with other sites, the total number of sending threads should be configured as a greater number than the threads configured for the per site setting. If the total number of sending threads is equal to the number configured to be used per site and a receiving site is unavailable, it could cause all sending threads to become used when attempting to communicate with the unavailable site and prevent site-to-site communication to other sites.

What does this mean?

The value specified under All Sites defines the total number of threads that Sender can use for sending data concurrently to other sites. Out of the total number of threads for All Sites, you can allot a maximum number of threads under Per Site that can be used for sending data to any one destination site. By default, each site is configured to use five concurrent threads, with three available for use when sending data to any one destination site. When you increase this number, you can increase the throughput of data between sites by enabling Configuration Manager to transfer more files at the same time. Increasing this number also increases the demand for network bandwidth between sites.

Choosing the right values

To determine appropriate values for these settings, you first need to understand the Configuration Manager hierarchy. Let's consider the following hypothetical Configuration Manager environment:
  • Central Administration Site: CS1
  • Primary Site: PS1
  • Primary Site: PS2
  • Primary Site: PS3
  • Primary Site: PS4
In this environment, the default Sender thread configuration will allow using a total of 5 threads, and out of those 5 threads, 3 can be used for any one of the 4 destination primary sites. If an administrator sends 3 to all of these sites, it is possible that Sender will end up using 3 threads for one of these sites (let's say PS1), leaving only 2 threads for the remaining sites. Out of the remaining 2 threads, Sender may use 1 for PS2 and the other for PS3 utilizing all 5 allowed threads leaving no room for sending data concurrently to PS4. At this point, Sender will have to wait for one of the existing 5 threads to finish before it can send more data. Once an existing thread finishes, Sender will then be able to use another thread for sending more data to the PS2/PS3/PS4 sites.
It is generally recommended to set aside 10 threads for each site that Sender will communicate with. In this case, the CS1 site can communicate with 4 other sites, which means that a Per Site value of 10 for 4 sites will require setting the All Sites value to 40.
Note that this is a general recommendation and these values may require further tweaking depending on the number of packages a site needs to send concurrently to other sites.
Bandwidth Control and Threads
In Configuration Manager, you can configure a schedule and set specific throttling settings for remote distribution points as well as for File Replication Routes for sites. The controls for scheduling and throttling to the remote distribution point are similar to the settings for a standard sender address, but in this case, the settings are used by a component called Package Transfer Manager.
For the Package Transfer Manager component (for Site Server -> DP), the throttling settings are configured in the Properties for a Standard Distribution Point that is not on a site server.
For the Sender component (for Site Server <-> Site Server), the throttling settings are configured in the properties of the File Replication Route under Hierarchy Configuration -> File Replication.

Schedule Options

To restrict data, select the time period and then select one of the following settings for Availability
  • Open for all priorities: Specifies that Configuration Manager sends data to the distribution point with no restrictions. 
  • Allow medium and high priority: Specifies that Configuration Manager sends only medium and high priority data to the distribution point. 
  • Allow high priority only: Specifies that Configuration Manager sends only high priority data to the distribution point. 
  • Closed: Specifies that Configuration Manager does not send any data to the distribution point.
    You can restrict data by priority or close the connection for selected time periods.
  • Rate Limit Options

  • This is used to configure rate limits to control the network bandwidth that is in use when transferring content to the distribution point. You can choose from the following options:
  • Unlimited when sending to this destination: Specifies that Configuration Manager sends content to the distribution point with no rate limit restrictions.
  • Pulse mode: Specifies the size of the data blocks that are sent to the distribution point. You can also specify a time delay between sending each data block. Use this option when you must send data across a very low bandwidth network connection to the distribution point. For example, you might have constraints to send 1 KB of data every five seconds, regardless of the speed of the link or its usage at a given time.
  • Limited to specified maximum transfer rates by hour: Specify this setting to have a site send data to a distribution point by using only the percentage of time that you configure. When you use this option, Configuration Manager does not identify the networks available bandwidth, but instead divides the time it can send data into slices of time. Then data is sent for a short block of time, which is followed by blocks of time when data is not sent. For example, if the maximum rate is set to 50%, Configuration Manager transmits data for a period of time followed by an equal period of time when no data is sent. The actual size amount of data, or size of the data block, is not managed. Instead, only the amount of time during which data is sent is managed.
  • For more information on these settings, please see Configuring Content Management in Configuration Manager in the Microsoft TechNet Documentation Library.
  • How this affects Sender and PkgXferMgr threads

  • When bandwidth control is enabled for a site, the sender component will ignore the sender thread configuration for the site and will only use one thread for that site. Similarly, when bandwidth control is enabled for a DP, PkgXferMgr will ignore the thread configuration and will only use one thread for the DP.
When bandwidth control is in effect, PkgXferMgr.log will log one of these lines:
Scheduling:
~Address to DPNAME.CONTOSO.COM is currently under bandwidth control, therefore only one connection is allowed, returning send request to the pool. 
Pulse Mode:
~Addres to DPNAME.CONTOSO.COM is currently in pulse mode, therefore only one connection is allowed. ~Abandoning send request because only one connection is allowed in pulse mode. 
Sender.log will show similar entries when bandwidth throttling is configured. 
Troubleshooting
Each section in this guide has troubleshooting tips specific to that part of the content distribution process, so if you haven’t read the section relating to your problem then you should start there first. What we’ll discuss here is a general example of how to troubleshoot a content distribution problem, then we’ll take a look at some of the more common problems you might run into.

Sample Problem

For this example, let’s say that you distributed a package to a distribution point but the package is in either a Failed or In Progress state for the DP.
  1. First, review DistMgr.log on the site (primary/secondary) where the DP resides.
    1. Look for "~Processing package" entries in the log and identify the package processing thread for the package ID in question. Filter DistMgr.log for the thread ID you identified.
    2. Review the filtered log and check if a DP thread was created for the DP in question. Filter DistMgr.log for the thread ID to make this easier.
    3. Review the filtered log and check whether a PkgXferMgr job was created.
  2. Review PkgXferMgr.log on the site (primary/secondary) where the DP resides.
    1. Look for "Found send request with ID" entries in the log and identify the sending thread for the affected DP/package combination. Filter PkgXferMgr.log for the thread ID identified.
    2. Review the filtered log to see if the content was successfully transferred to the DP or if there was an error.
  3. After PkgXferMgr copies the content files to the DP, it instructs the DP WMI provider to add the file to the content library by calling WMI methods. Review SMSDPProv.log on the DP to ensure that content was added to the content library.
  4. PkgXferMgr next sends a status message to DistMgr. Review DistMgr.log to verify if the status message was processed successfully.
  5. If multiple sites are involved, ensure that Database Replication is working and the database links between relevant sites are active.

Common DistMgr Issues

  1. DistMgr.log shows the following entry for the package ID in question:
    05-16-2016 12:23:23.455    SMS_DISTRIBUTION_MANAGER    2732 (0xaac)    ~The contents for the package CS100026 hasn't arrived from site CS1 yet, will retry later. 
    This usually happens temporarily while the content is in transit from one site to another. Review the Sender/Despooler logs to ensure that there are no issues with site communications. If you see errors during site to site communication (Scheduler -> Sender -> Despooler), focus on resolving those errors before troubleshooting the above message in DistMgr.log. If there are no errors, it may be necessary to force the parent site to re-send the package to the affected site.
  2. DistMgr.log may show that it's busy processing other packages and is using all the available threads for package processing.
    05-17-2016 14:32:59.644    SMS_DISTRIBUTION_MANAGER    4824 (0x12d8)    ~Currently using 3 out of 3 allowed package processing threads. 
    If you see this, review the current package processing threads in DistMgr.log to see if they are stuck. You can also review the Package Processing Queue and Packages Being Processed registry values under the following registry key to see how many packages are currently in the Processing Queue.
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_DISTRIBUTION_MANAGER
    If there are a lot of packages in the queue but the queue is moving, it may be necessary to review and change the thread configuration.
  3. DistMgr.log does not process the incoming PKN files, and as a result packages are not being processed. This is resulting in a backlog of PKN files in the DistMgr inbox. 
    The PKN files are processed by the main DistMgr thread so in these cases it's helpful to identify the main DistMgr thread ID by looking for the "SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER" log entry, then filter the DistMgr.log for the thread ID identified. 
    In most cases, this issue occurs when the main DistMgr thread is making a WMI call to a remote DP but WMI on the DP is not responding, causing DistMgr to wait for it indefinitely. Filtering the DistMgr.log for the main DistMgr thread can provide clues about the DP it's trying to communicate with. Once identified, check if the DP is responding and WMI is functional on the DP. If necessary, reboot the DP to see if that helps.

Common PkgXferMgr Issues

  1. PkgXferMgr.log shows an error while adding files to the content library on the DP:
    12-04-2014 05:44:27.364    SMS_PACKAGE_TRANSFER_MANAGER    5744 (0x1670)    ~Sending completed [D:\SCCMContentLib\FileLib\B53B\B53B6F96ECC3FB2AF59D02C84A2D31434904BACF2F9C90D80107B6602860BCFD] 12-04-2014 05:44:27.411    SMS_PACKAGE_TRANSFER_MANAGER    5744 (0x1670)    ~ExecStaticMethod failed (80041001) SMS_DistributionPoint, AddFile 12-04-2014 05:44:27.411    SMS_PACKAGE_TRANSFER_MANAGER    5744 (0x1670)    CSendFileAction::AddFile failed; 0x80041001 12-04-2014 05:44:27.427    SMS_PACKAGE_TRANSFER_MANAGER    5744 (0x1670)    ~Deleting remote file \\DPNAME.CONTOSO.COM\SMS_DP$\Content_b034813c-bc60-4a16-b471-7a0dc3d9662b.1-B53B6F96ECC3FB2AF59D02C84A2D31434904BACF2F9C90D80107B6602860BCFD 12-04-2014 05:44:27.427    SMS_PACKAGE_TRANSFER_MANAGER    5744 (0x1670)    ~ Sending failed. Failure count = 1, Restart time = 12/4/2014 6:14:27 AM Eastern Standard Time 
    After PkgXferMgr copies the content file to the DP, it executes WMI methods to instruct the remote DP to add the file to the content library. If the remote DP fails to add the file to the content library, you will see a generic WMI error (0x80041001 = WBEM_E_FAILED) in PkgXferMgr.log. When this happens, it is necessary to review SMSDPProv.log on the DP to identify the reason that the DP failed to add the file to the content library.
     

  2. PkgXferMgr.log shows that only one connection is allowed to the DP: 
    03-29-2016 20:48:04.694    SMS_PACKAGE_TRANSFER_MANAGER    21216 (0x52e0)    ~Address to DPNAME.CONTOSO.COM is currently under bandwidth control, therefore only one connection is allowed, returning send request to the pool.
    --- or ---
    03-29-2016 20:50:19.286    SMS_PACKAGE_TRANSFER_MANAGER    21216 (0x52e0)    ~Addres to DPNAME.CONTOSO.COM is currently in pulse mode, therefore only one connection is allowed. 
    If PkgXferMgr.log shows that "only one connection is allowed" to the DP, it means that the DP is configured for bandwidth throttling. If this is the case, PkgXferMgr can only use one thread for the DP, and as a result only send one package to the DP at a time.
  3. PkgXferMgr.log shows the address is closed:
    3/15/2016 8:00:06 AM SMS_PACKAGE_TRANSFER_MANAGER 7156 (0x1BF4) Address is closed for priority 2 jobs, stop sending [E:\SCCMContentLib\FileLib\2F08\2F0819F959E788CF843F42E9CA7B44E258B8B4BA37BB63902DB39ACF747BE7DA]  3/15/2016 8:00:06 AM SMS_PACKAGE_TRANSFER_MANAGER 7156 (0x1BF4) Deleting remote file \\DPNAME.CONTOSO.COM\SMS_DP$\P0100003.6-2F0819F959E788CF843F42E9CA7B44E258B8B4BA37BB63902DB39ACF747BE7DA 3/15/2016 8:00:08 AM SMS_PACKAGE_TRANSFER_MANAGER 7156 (0x1BF4) CSendFileAction::SendFiles failed; 0x80004005  3/15/2016 8:00:08 AM SMS_PACKAGE_TRANSFER_MANAGER 7156 (0x1BF4)  Sending failed. Failure count = 1, Restart time = 3/15/2016 8:30:08 AM Mountain Daylight Time  
    If you see this in the log, it means that the DP is under bandwidth control and the address to the DP closed while content transfer was in progress. In the example above, the DP schedule was configured for Allow high priority only during 8:00AM to 10:00AM and as a result, PkgXferMgr stopped sending content at 8:00AM and marked the package/DP in a failed state.
  4. PkgXferMgr.log shows multiple threads starting at the same time for the same job: 
    02-25-2015 10:04:20.296    SMS_PACKAGE_TRANSFER_MANAGER    8360 (0x20a8)    Sending thread starting for Job: 12771, package: P0100055, Version: 8, Priority: 2, server: DPNAME.CONTOSO.COM, DPPriority: 200 02-25-2015 10:04:43.134    SMS_PACKAGE_TRANSFER_MANAGER    10752 (0x2a00)    Sending thread starting for Job: 12771, package: P0100055, Version: 8, Priority: 2, server: DPNAME.CONTOSO.COM, DPPriority: 200 02-25-2015 10:04:45.817    SMS_PACKAGE_TRANSFER_MANAGER    12208 (0x2fb0)    Sending thread starting for Job: 12771, package: P0100055, Version: 8, Priority: 2, server: DPNAME.CONTOSO.COM, DPPriority: 200 02-25-2015 10:04:47.467    SMS_PACKAGE_TRANSFER_MANAGER    4244 (0x1094)    Sending thread starting for Job: 12771, package: P0100055, Version: 8, Priority: 2, server: DPNAME.CONTOSO.COM, DPPriority: 200 02-25-2015 10:04:47.804    SMS_PACKAGE_TRANSFER_MANAGER    8348 (0x209c)    Sending thread starting for Job: 12771, package: P0100055, Version: 8, Priority: 2, server: DPNAME.CONTOSO.COM, DPPriority: 200 
    Typically, PkgXferMgr uses one thread for a job, but if it uses multiple threads for the same job, the content transfer may start failing because of error 0x80070020 (ERROR_SHARING_VIOLATION). This happens if the site server and the site database servers are in different time zones. The solution here is to ensure that the site server and site database servers have the same time zone set.

Generic Issues

  1. The DistMgr or PkgXferMgr log shows a file/path not found error:
    02-02-2016 17:41:36.003    SMS_PACKAGE_TRANSFER_MANAGER    3776 (0xec0)    CContentDefinition::TotalFileSizes failed; 0x80070003 02-02-2016 17:41:36.003    SMS_PACKAGE_TRANSFER_MANAGER    3776 (0xec0)    Sending content 000f8a0a-825c-457b-a15b-57ade145a09b for package P0100059 02-02-2016 17:41:36.018    SMS_PACKAGE_TRANSFER_MANAGER    3776 (0xec0)    CSendFileAction::SendFiles failed; 0x80070003 02-02-2016 17:41:36.018    SMS_PACKAGE_TRANSFER_MANAGER    3776 (0xec0)    CSendFileAction::SendContent failed; 0x80070003 02-02-2016 17:41:37.096    SMS_PACKAGE_TRANSFER_MANAGER    648 (0x288)    Sent status to the distribution manager for pkg P0100059, version 14, status 4 and distribution point ["Display=\\DPNAME.CONTOSO.COM\"]MSWNET:["SMS_SITE=S01"]\\DPNAME.CONTOSO.COM\~ 
    --- or ---
    03-08-2016 08:21:09.920    SMS_PACKAGE_TRANSFER_MANAGER    11228 (0x2bdc)    Sending legacy content P0100053.2 for package P0100053 03-08-2016 08:21:10.010    SMS_PACKAGE_TRANSFER_MANAGER    11228 (0x2bdc)    CContentDefinition::TotalFileSizes failed; 0x80070003 03-08-2016 08:21:10.020    SMS_PACKAGE_TRANSFER_MANAGER    11228 (0x2bdc)    CSendFileAction::SendFiles failed; 0x80070003 
    Common Error Codes: 0x80070002, 0x80070003.
    For file/path not found errors, the problem is likely due to the fact that the content library on the site server is missing content files for the package. As a result, PkgXferMgr is not be able to send the files to the DP.
    In these cases, you can identify the content ID from the log and track the content from PkgLib to FileLib to ensure that the files exist. You can also use Content Library Explorer from the System Center 2012 R2 Configuration Manager toolkit to check if the package content files are available in the content library, however Content Library Explorer can take some time to load and it may be easier to manually track the content from PkgLib to FileLib.
    If the site that is missing content in the content library is the Package Source site, it is necessary to Update the package to increment the Package Source version so that DistMgr takes a snapshot of the content from the Package Source Directory again and re-populates the missing content.
    If the site missing the content in the content library is different from the Package Source site, you can force the Package Source site to resend the compressed copy of the package to the affected site. 
  2. DistMgr/PkgXferMgr log shows a network error:
    05-26-2016 11:39:58.319    SMS_DISTRIBUTION_MANAGER    5112 (0x13f8)    Failed to make a network connection to \\DPNAME.CONTOSO.COM\ADMIN$ (0x35).~ 05-26-2016 11:39:58.319    SMS_DISTRIBUTION_MANAGER    5112 (0x13f8)    ~Cannot establish connection to ["Display=\\DPNAME.CONTOSO.COM\"]MSWNET:["SMS_SITE=PS1"]\\DPNAME.CONTOSO.COM\. Error = 53 05-26-2016 11:39:58.337    SMS_DISTRIBUTION_MANAGER    5112 (0x13f8)    Error occurred. Performing error cleanup prior to returning. 
    Common Error Codes: 2, 3, 53, 64.
    For network related errors, review the log and identify the server you’re trying to communicate with when you get the error. Once identified, test the following:

    1. Can you ping the affected SERVERNAME using the FQDN/NetBIOS/IP address?
    2. Can you access \\SERVERNAME\admin$ share using the FQDN/NetBIOS/IP address using the SYSTEM account from the site server?
    3. Can you access \\SERVERNAME\admin$ share using the FQDN/NetBIOS/IP address using the logged in user's account from the site server?
    4. Is there a firewall between the site server and the affected server? Are relevant ports (RPC/SMB) open?
  3. DistMgr/PkgXferMgr log shows an access denied error:
    05-26-2016 12:18:24.412    SMS_DISTRIBUTION_MANAGER    7076 (0x1ba4)    Taking package snapshot for package PS10003A from source \\PS1SITE\PKGSOURCE\DummyPackage 05-26-2016 12:18:24.414    SMS_DISTRIBUTION_MANAGER    7076 (0x1ba4)    ~The source directory \\PS1SITE\PKGSOURCE\DummyPackage doesn't exist or the SMS service cannot access it, Win32 last error = 5 05-26-2016 12:18:24.424    SMS_DISTRIBUTION_MANAGER    7076 (0x1ba4)    ~Failed to take snapshot of package PS10003A 
    Common Error Codes: 5, 0x80070005.
    For permissions related errors, review the log and identify the path you're trying to access when you get the error. Once identified, test the following:
    1. Can you ping the affected SERVERNAME if the path is a UNC path?
    2. Does the site server computer account have permissions to access the path?
    3. Can you access the affected path using the FQDN/NetBIOS/IP address when using the SYSTEM account from the site server?
    4. Can you access the affected path using the FQDN/NetBIOS/IP address when using the logged in user's account from the site server?
    5. Is there a firewall between the site server and the affected server? Are relevant ports (RPC/SMB) open? 

Useful SQL Queries
This section is mainly just for reference purposes, but below are some SQL queries that may prove to be helpful when troubleshooting various content distribution related issues.

Package/DP Status Queries

-- All Failed Packages/DPs
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.MessageState, DPSD.LastStatusTime, DPSD.SiteCode FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE MessageState = 4 
-- All In Progress Packages/DPs
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.MessageState, DPSD.LastStatusTime, DPSD.SiteCode FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE MessageState = 2 
-- All Success Packages/DPs
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.MessageState, DPSD.LastStatusTime, DPSD.SiteCode FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE MessageState = 1 
-- All Package/DPs in InProgress state for more than 3 days 
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.MessageState, DPSD.LastStatusTime, DPSD.SiteCode FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE DPSD.LastStatusTime > DATEAdd(dd,-3,GETDate())  AND MessageState = 2 
-- All Package/DPs in Failed state for more than 3 days 
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.MessageState, DPSD.LastStatusTime, DPSD.SiteCode FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE DPSD.LastStatusTime > DATEAdd(dd,-3,GETDate())  AND MessageState = 4 
-- Count of All States 
SELECT MessageState, COUNT(MessageState) AS [Count] FROM vSMS_DPStatusDetails WHERE PackageID <> '' GROUP BY MessageState 
-- Counts of Package States Per DP 
SELECT DPName, CASE         WHEN MessageState = 1 THEN 'Success'        WHEN MessageState = 2 THEN 'InProgress'          WHEN MessageState = 4 THEN 'Failed'        END AS [State],  COUNT(MessageState) AS [Count] FROM vSMS_DPStatusDetails WHERE PackageID <> '' AND DPName = 'PS1DP1.CONTOSO.COM' GROUP BY DPName, MessageState ORDER BY DPName 
-- State of all DPs for a given Package
SELECT DPName, CASE        WHEN MessageState = 1 THEN 'Success'       WHEN MessageState = 2 THEN 'InProgress'        WHEN MessageState = 4 THEN 'Failed'        END AS [State] FROM vSMS_DPStatusDetails WHERE PackageID = 'CS100002' GROUP BY DPName, MessageState ORDER BY State 
-- Count of DP States per Package
SELECT  CASE        WHEN MessageState = 1 THEN 'Success'       WHEN MessageState = 2 THEN 'InProgress'        WHEN MessageState = 4 THEN 'Failed'        END AS [State], COUNT(MessageState) AS [Count] FROM vSMS_DPStatusDetails WHERE PackageID = 'CS100002' GROUP BY MessageState  
-- Package/DP Current State
SELECT distinct DPSD.DPName, DPSD.PackageID, SP.Name, DPSD.LastStatusTime, DPSD.SiteCode, DPSD.MessageState, CASE        WHEN MessageState = 1 THEN 'Success'       WHEN MessageState = 2 THEN 'InProgress'         WHEN MessageState = 4 THEN 'Failed'        END AS [State] FROM vSMS_DPStatusDetails DPSD JOIN SMSPackages_All SP ON DPSD.PackageID = SP.PkgID WHERE DPName = 'PS1DP1.CONTOSO.COM' AND DPSD.PackageID = 'CS100002'

Finding Orphaned DP References

The query below can be used to identify if there are any orphaned rows left in the database for a DP that is no longer in the environment. There could be orphaned rows if the DP was not removed properly.
DECLARE @DPName NVARCHAR(100) SET @DPName = 'PS1DP.CONTOSO.COM'   SELECT * FROM ContentDPMap WHERE ServerName = @DPName SELECT * FROM DistributionPoints WHERE ServerName = @DPName SELECT * FROM DPInfo WHERE ServerName = @DPName SELECT * FROM PkgServers_G WHERE NALPath like '%' + @DPName + '%' SELECT * FROM PkgServers_L WHERE NALPath like '%' + @DPName + '%' SELECT * FROM PkgStatus_G WHERE PkgServer like '%' + @DPName + '%' SELECT * FROM PkgStatus_L WHERE PkgServer like '%' + @DPName + '%' SELECT * FROM SysResList WHERE RoleName = 'SMS Distribution Point' AND ServerName = @DPName 

Site Control File (SCF) Properties

-- SCF Properties for DistMgr for current site 
SELECT SD.SiteCode, SC.ComponentName, SCP.Name, SCP.Value1, SCP.Value2, SCP.Value3 FROM SC_Component SC JOIN SC_SiteDefinition SD ON SD.SiteNumber = SC.SiteNumber JOIN SC_Component_Property SCP ON SCP.ComponentID = SC.ID WHERE SD.SiteCode = dbo.fnGetSiteCode() AND SC.ComponentName = 'SMS_DISTRIBUTION_MANAGER' 
-- SCF Properties for a DP
SELECT SRU.RoleName, SRU.ServerName, SRUP.* FROM vSMS_SC_SysResUse SRU JOIN vSMS_SC_SysResUse_Properties SRUP ON SRU.ID = SRUP.ID WHERE SRU.RoleName = 'SMS Distribution Point' AND SRU.ServerName = 'PS1DP1.CONTOSO.COM'

Packages containing specified software update

-- List all packages containing the given update Unique ID
SELECT distinct UI.ArticleID, CI.CI_UniqueID, CP.PkgID, P.Name FROM v_UpdateInfo UI JOIN v_ConfigurationItems CI ON UI.CI_ID = CI.CI_ID JOIN v_CIContents_All CIC ON CI.CI_ID = CIC.CI_ID JOIN CI_ContentPackages CP ON CP.Content_ID = CIC.Content_ID JOIN v_Package P ON CP.PkgID = P.PackageID WHERE CI.CI_UniqueID = '1f7b0ba7-3651-4c3b-9104-ca52fb4d44bf' 

Congratulations
Congratulations! Your Content Distribution problem has been resolved. If you’d like more information regarding content distribution, please see the following:

You can also post a question in our Configuration Manager support forum here:

Visit our blog for all the latest news, information and tech tips on Microsoft System Center Configuration Manager.




Additional Information
For additional information regarding content distribution in Microsoft System Center Configuration Manager, please see the following:

You can also post a question in our Configuration Manager support forum here:

Visit our blog for all the latest news, information and tech tips on Microsoft System Center Configuration Manager.




Properties

Article ID: 4000401 - Last Review: 2016, ഒക്ടോ 17 - Revision: 45

ഫീഡ്‌ബാക്ക്
ERROR: at System.Diagnostics.Process.Kill() at Microsoft.Support.SEOInfrastructureService.PhantomJS.PhantomJSRunner.WaitForExit(Process process, Int32 waitTime, StringBuilder dataBuilder, Boolean isTotalProcessTimeout)