One of the new features introduced with Service Pack 1 for Configuration Manager 2012 is pull distribution points. While a traditional distribution point is force feed its contents by distribution manager and package transfer manager from the parent site a pull distribution point will pull down the content itself.
So why is this useful? In all versions of Configuration Manager (back to SMS 1) content has been copied down from primary to secondary site to distribution point and basically following the same flow as site control file updates and reversing the path of status messages and inventory information.
With Configuration Manager 2012 we basically lost the ability to create hierarchies deeper than 3-4 layers (Central Administration Site, Primary Sites, Secondary Sites and then possible remote DPs). A seldom used feature is that while SQL replication between a primary and secondary site is always direct and secondary to secondary is impossible we can allow content to be replicated from one secondary site to another.
For geographically dispersed hierarchies it can make good sense to optimize content distribution to the network topology. Consider an environment where you have a fully meshed network (MPLS) and you have a primary in Europe and two remote offices in Asia, Bangkok and Hanoi. Prior to SP1 you would need to install a secondary site in each Asian location to allow content to be replicated Europe -> Bangkok -> Hanoi. After SP1 you can configure Bangkok as a pull distribution point retrieving content from Europe and Hanoi as a pull distribution retrieving content from Bangkok. Another scenario would be to have a hierarchy spanning two locations. In the “remote” location you wish to have two DPs for redundancy and performance. Prior to SP1 both DPs would receive content from the primary site doubling the network load.
Last scenario is if you have a large number of remote DPs (more than 50) under a single primary. In this case you start running into limitations in distribution manager and see limited performance.
So how does it work?
After enabling a distribution point as a pull DP you can see that the DP will install sms_dp$\sms\bin\pulldp.msi (logging to pulldp_install.log in the same folder) so in case of problems with the installation this is the file to examine. The installation is initiated from distribution manager (see distmgr.log)
When a package is assigned to a pull DP distribution manager will instruct package transfer manager to transfer the package. Package transfer manager will build an xml file by calling fnGetPullDPXMLNotification. The pull DP will use this xml to initiate a BITS transfer of the package specified in the XML and store the local file into \sms_DP$\<package_id> when the content has been downloaded it is inserted into the DP and made available.
When you configure a distribution point as a pull DP the ability to schedule and limit bandwidth consumption is lost (the tabs are simply removed from the properties of the DP). You can still configure some of these settings but since a pull DP uses BITS you need to control BITS.
If you need to troubleshot a pull DP start with sms_dp$\sms\logs\smsdpprov.log and either bitsadmin.exe /list /allusers or for the PowerShell folks Get-BitsTransfer –AllUsers
You should look out for status messages with id 8212. These indicates that a pull DP cannot find the needed content on the specified source DPs.
I am pretty happy about this feature since it allows for speedier content replication and many of my customers have highly saturated or very high latency links. I wish however that Microsoft had also included a feature to prioritize source distribution points. That is allowing me to specify which DPs to service first. As it is right now Distribution Manager / Package Transfer Manager might generate the requests for the Pull DPs prior to copying contents to the source DPs.