Now that we have an understanding of the various features and functions of a distribution point, we should get down to the different ways in which we can troubleshoot it and what resources we have available to do so.
As always, the console will provide us with good high-level, at-a-glance information about the health state of our distribution points. Looking first in the Monitoring | Overview | Distribution Status workspace, we will see that we can take a look at the following items:
The Content Status workspace will show us various details of each content item including its distribution status, which can be viewed in the lower half of the split pane view. We should note that the pie chart shown in the following screenshot is relative to the number of distribution points that the content has been distributed to:
From this view, we can click on the View Status link to take us to a more detailed view of the content item. Here we can see which distribution points the content distributed to successfully or otherwise. This is particularly useful to get a quick glance as an indicator if we have a troublesome content item that has issues being distributed.
This workspace will cover all distribution point groups in our site and similar to the content status will give us a high-level red, amber, green status of our distribution point group. Selecting View Status will again take us to a more detailed view in the same template as content status but relevant to the distribution points within that group. This is particularly useful to get a quick glance as an indicator if we have a troublesome distribution point within a group.
The configuration status view is another at-a-glance view—this time for the configuration state of our distribution point. This includes whether PXE, multicast, or content validation is enabled on our distribution point complete with a message count for that server and a success, in progress, warning, or error status icon. The status icons are only governed by the validation of content on the distribution point and not by any configuration options.
The status rules are as follows and all content is classed as a package when it comes to distribution:
Rule |
Status Code |
Status |
---|---|---|
If the package count on the DP equals the number of packages that the Configuration Manager database thinks should be installed. |
|
|
If the package count on the DP equals the number of packages that the Configuration Manager database thinks should be installed and there are packages in progress. |
|
|
If the package count on the DP equals the number of packages that the Configuration Manager database thinks should be installed, there are packages in progress, and there are also some package errors. |
|
|
Any other condition |
|
|
Each time a package is distributed, the content is validated and a comparison made between the site copy and the distribution point copy. This is how the package count is made and used in a comparison to produce the resultant status. The status messages available in this view are also very useful as they give us a slightly lower level of detail regarding the processing activity and configuration changes for the distribution point.
We have covered log files in general in an earlier chapter, but as distribution points have a fundamental role in Configuration Manager, we should also be aware of a the specific log files which apply. Unless stated otherwise, these log files can be found in the \<DPServer>SMS_DP$smslogs
.
LogFile |
Description |
---|---|
|
This file will give us all the information about extraction of the files on the distribution point that are compressed when stored. This file is found on the distribution point itself unless it is on the same server as the site server. |
|
This log file contains information about the |
|
As we might expect from the name, this file holds details about PXE responses provided by the site system to clients and also includes information about the expansion of the boot images and boot files in the |
|
If we have enabled the distribution point as a pull distribution point, then this is the installation log which will show us the return code with verbose logging of the installation. |
|
This log file relates to the |
On a distribution point, there is a WMI database that holds account of all the content that was distributed to it. This is stored in the WMI namespace ROOTSCCMDP
and the class we should look at is SMS_PackagesInContLib
.
We could use the following PowerShell on a distribution point to check for the existence of an item on a distribution point as sometimes we can experience mismatches between the site server and the distribution point. This will then validate whether the distribution point itself has a record of the package as the view in the console will reflect what the site database thinks we have on the distribution point.
Get-WmiObject –Namespace rootsccmdp –Class SMS_PackagesInContLib | Where-Object PackageID –eq 'INF00005'
If a package is found, the output will be similar to the following:
__GENUS : 2 __CLASS : SMS_PackagesInContLib __SUPERCLASS : __DYNASTY : SMS_PackagesInContLib __RELPATH : SMS_PackagesInContLib.PackageID="INF00005" __PROPERTY_COUNT : 2 __DERIVATION : {} __SERVER : DEMO-DPM01 __NAMESPACE : ROOTsccmdp __PATH : \DEMO-DPM01ROOTsccmdp:SMS_PackagesInContLib.PackageID="INF00005" PackageID : INF00005 PackageShareLocation : PSComputerName : DEMO-DPM01
We should obviously replace the PackageID
with the value we are looking for. This task can also be carried out using any of the WMI tools listed in the troubleshooting toolkit. However, PowerShell is flexible in that we can swap the value for a variable and even make a quick script to prompt each time.
On occasion, we can also see errors like the following reported in the console and in the smsdpmon.log
:
"The package data in WMI is not consistent to PkgLib"
or
"Package INF00005 can't be found in PkgLib"
These are typical of content mismatches. After making some checks in the console and with the preceding PowerShell, we can add a | Remove-WmiObject
to the PowerShell to remove the content if it is orphaned.
Troubleshooting PXE can be somewhat of a minefield and is often dependent on environmental factors such as DHCP options and networking. In conjunction with the process explained earlier in this chapter, it is suggested that we bookmark one of the lists that are available through a web search as they give reasonable explanation of the problems associated with PXE errors. Some of the common error codes experienced with Configuration Manager are among this list and are given as follows:
Code |
Description |
Typical Symptom |
---|---|---|
|
No DHCP or proxy DHCP offers were received. |
The client cannot contact the DHCP or PXE server, check network connectivity, firewalls, and routing, particularly if across subnets. |
|
No boot filename was received. |
The DHCP option |
|
TFTP download failed. |
This can occur once the TFTP download has started. As previously, check DHCP options and ensure an |
|
Media test failed, check cable. |
Speaks for itself really, make cable and network connection checks. |
|
TFTP error: File not found. |
This generally means that the |
|
Proxy DHCP service did not reply to request on port |
Check that your DHCP options are specified correctly and that the relevant services are running on those servers. |
|
The specified file was not found Or File not found |
The PXE server is responding to the request; however, the file that it instructs the client to boot to is not there. A redistribution or validation of the boot image may resolve this. |
|
Access violation. |
This can occur in combination with the next two error codes. Commonly it can refer to the DHCP options being incorrectly configured. |
|
Error Received from TFTP Server. |
As in the previous message, this most commonly suggests that the boot file (DHCP option |
|
Exiting PXE Rom. |
This is simply a notification that the client is exiting the PXE process and is commonly seen in combination with other errors at the end of an error list. |
|
Could not locate boot server. |
Similar to |
This is by no means an exhaustive list; therefore, it is suggested we reference a web search for a specific error outside of this. We should also not rule out a very common factor, however, which is normally between the desk and the chair. It is a very common problem that a mistyped MAC address was entered during the import of a manual machine entry record, and, in many cases, this is the most common PXE-related issue seen.
18.117.186.92