Pull distribution points are a feature that was first introduced into Configuration Manager in version 2012 SP1. The concept is really very simple. When we designate a distribution point as a pull distribution point, it has the ability to pull content from another distribution point instead of directly from the site server. We can specify numerous source distribution points so that the server can get content from more than one location, which can provide some great options when working with a large implementation where either sites are daisy-chained or certain network routes are preferred. An added bonus of this is that they perform better than a full distribution point when scaled, and this, as a result, gives us a theoretical increase in the number of distribution points available per site when combined with standard distribution points.

Something to remember when using pull distribution points is that when we distribute content to the server, the content must be first available on one of the source distribution points. This can often confuse administrators as they see status messages reporting that content has not been distributed to the distribution point when it is simply waiting for the source to update.

A pull distribution point has one specific log file, C:WindowsCCMLogsPullDP.log, which is stored on the server that holds the role.

This log file specifically records details of content transfers between the source and destination distribution point. If we suspect that there are problems with a pull distribution point, then this is one of the first places to go and check.

Another feature first introduced in Configuration Manager 2012 SP1 was cloud distribution points. This is a variation on a standard distribution point and allows us to utilize our Microsoft Azure subscription to host a distribution point in the cloud. There are many advantages to this which are common with most cloud technologies that can be very useful, specifically in a large-scale distributed organization. We should be aware that although this role can be used as a fallback location for content, this is not a full distribution point and doesn't run a full server that we can make a remote desktop connection to, for example. Therefore, from a Configuration Manager point of view, there is a relatively limited amount of troubleshooting available when compared to a standard distribution point. We simply get an amount of storage available to us in Microsoft Azure and, as can be expected, particularly in a pay-as-you-go scenario, we can and would want to set some storage and transfer thresholds for alerting. These alerts will only appear in the Configuration Manager console in the Monitoring | Overview | Alerts workspace, so it is definitely worthwhile creating e-mail subscriptions for these. We will also be able to see this resource listed in our Microsoft Azure subscription and standard Azure-based troubleshooting applies from that regard.

It is also worth noting that cloud distribution points also have their own log files and do not necessarily appear in the same way as the standard log files. Both of these files are stored on the site system server by default in %ProgramFiles%Microsoft Configuration ManagerLogs:

The former contains general information about cloud distribution points in general from a Configuration Manager perspective. If there are one or more cloud distribution points, this file will contain information about all the storage and bandwidth statistics as well as recording information about the provisioning of content and any Configuration Manager administrator actions to change the state of the service that runs a cloud distribution point. The latter log file contains more specific information about a cloud distribution point and is named according to the GUID associated with that distribution point. This file contains details about storage and content access for that distribution point only.

The distribution point role offers the choice of enabling PXE to act as the network boot host for client machines. This is commonly used in OSD scenarios and is generally utilized quite heavily by many organizations. Just for the record, in versions of Configuration Manager prior to version 2012, this was a separate role. PXE services in Configuration Manager are based on Windows Deployment Services (WDS). WDS will be automatically installed as part of the distribution point role installation if this option is selected and it isn't already installed. Although WDS is utilized, Configuration Manager uses it purely as a platform and implements its own customization by adding a folder structure and custom boot images instead of using the default WDS files. The RemoteInstall folder is used in the same way as WDS, but we will find the following three extra folders over a standard WDS install:

Without going into too much detail, the SMSBoot folder contains the files required to actually perform the network boot. The SMSImages folder contains the boot images that we distribute to the distribution point from the Configuration Manager console. Finally, the SMSTemp folder is simply a temporary location used when boot images are updated.

There are several ports required for PXE booting and OSD that should be open where necessary on the distribution point server firewall and on any other firewalls between the client and the server:

Something else to consider when using PXE are any DHCP options that we may require on the DHCP server. In theory, we need not configure anything on your DHCP server; however, in practice, it is often the case in many environments where the relevant options need to be specified either by necessity or choice. This can be for a number of reasons including security policies or if multiple network boot providers are available on the network. The following ports may sometimes be required:

There is also a third option that should be used if the DHCP server is also the PXE server:

It is also worth noting that it can sometimes be useful to configure IP Helpers on the gateway of a subnet that can allow these services to traverse multiple subnets. By default, the network boot capabilities will only be available to the network it resides on. This is worth considering when troubleshooting issues including network boots responding from unexpected locations; however, this can also be a boundary-related issue.

Finally, we should understand the basic process of the handshake that takes place between a client and a distribution point when performing a network boot of a machine with Configuration Manager PXE. This will assist in troubleshooting PXE boot problems with Configuration Manager and, at least, identify at which point in the process the problem occurs. PXE boot problems are fairly common with Configuration Manager; however, majority of the time this is down due to environmental issues such as networking or user error such as incorrect hardware addresses. At a high level, the following is the order in which the PXE boot works: