none
Calling back with empty distribution points list

    Question

  • I have an issue where I am seeing the message "Calling back with empty distribution points list" in the LocationServices.log.  When looking this message on the internet, others indicate its a boundary issue where the DP cannot be found.  I have one boundary group configured with 22 AD sites for automatic site assignment as there is only one ConfigMgr 2012 server.  Auto site assignment works fine.  I then have individual boundary groups for each of the 22 locations defining the DP at their location using their AD site.  I understand this to be the best practice to keep the Automatic Site Assignment in a different boundary group than the content location assignment.  I have verified that all IP subnets are in the proper AD Sites.

    Here is where it gets weird.  I deploy a mandatory app (Adobe Reader used for test) and the client shows the following (see below) in the LocationServices.log. I then reconfigure the MSI deployment type under the Content tab to:

    1.  Check "All clients to use a fallback source location for content"
    2.  Deployment Options: choose "Download content from distribution point and run locally" from the dropdown

    With these two settings I can trigger a client "machine policy retrieval..." and immediately the client notifies and starts downloading the app and installs it successfully.  The only problem is I don't have a fallback status point role installed.  I have tested this on a wired and wireless laptop where the ConfigMgr server was on the local LAN.

    LocationServices.log:

    <![LOG[Calling back with locations for location request {4E113B29-9034-4645-8976-5D504D791609}]LOG]!><time="03:54:12.196+300" date="07-11-2013" component="LocationServices" context="" type="1" thread="1100" file="replylocationsendpoint.cpp:219">
    <![LOG[Current AD site of machine is XYZ]LOG]!><time="04:26:34.147+300" date="07-11-2013" component="LocationServices" context="" type="1" thread="4876" file="lsad.cpp:746">
    <![LOG[Current AD site of machine is XYZ]LOG]!><time="04:26:34.295+300" date="07-11-2013" component="LocationServices" context="" type="1" thread="5360" file="lsad.cpp:746">
    <![LOG[Calling back with empty distribution points list]LOG]!><time="04:26:34.309+300" date="07-11-2013" component="LocationServices" context="" type="2" thread="5360" file="lsutils.cpp:423">

    The above log does detect the correct AD site and the correct MP.

    Any ideas?


    • Edited by mniccum Friday, July 12, 2013 1:16 AM
    Friday, July 12, 2013 1:11 AM

All replies

  • With these two settings I can trigger a client "machine policy retrieval..." and immediately the client notifies and starts downloading the app and installs it successfully.  The only problem is I don't have a fallback status point role installed


    There's no fallback status point involved!
    See the screenshot you provided: "All clients to use a fallback source location for content". That's not a FSP.
    That can be configured in the properties of a DP: \Administration\Overview\Site Configuration\Servers and Site System Roles on the Boundary Groups tab. 'fallback source location' is used when the client is not within any boundary/groups at all or within slow boundaries.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, July 12, 2013 7:05 AM
  • There's no fallback status point involved!
    See the screenshot you provided: "All clients to use a fallback source location for content". That's not a FSP.
    That can be configured in the properties of a DP: \Administration\Overview\Site Configuration\Servers and Site System Roles on the Boundary Groups tab. 'fallback source location' is used when the client is not within any boundary/groups at all or within slow boundaries.


    Torsten Meringer | http://www.mssccmfaq.de

    Nor is that what an FSP is for ;-)  I misread that.  So does this sound like a boundary issue?

    Thanks

    Friday, July 12, 2013 2:35 PM
  • There's no fallback status point involved!
    See the screenshot you provided: "All clients to use a fallback source location for content". That's not a FSP.
    That can be configured in the properties of a DP: \Administration\Overview\Site Configuration\Servers and Site System Roles on the Boundary Groups tab. 'fallback source location' is used when the client is not within any boundary/groups at all or within slow boundaries.


    Torsten Meringer | http://www.mssccmfaq.de

    Scenario:

    AD Site XYZ has 10.20.0.0/16 (supernet?) assigned to it.

    There is a separate Boundary Group for site assignment.

    There is a Boundary Group for content location which includes site XYZ

    When clients are distributed software that fall into the XYZ site they do not receive the software and I see the entry "Calling back with empty distribution points list" in the LocationServices.log.

    Questions:

    1.  Is this because supernetting is not supported and can cause intermittent issues?

    2.  Can this be alleviated by adding the IP range of the clients to the existing Boundary Group that already contains the XYZ site?

    3.  Content locations can overlap (right?) ...so I assume this is a valid solution.

    I understand IP ranges cause more expensive SQL queries but other than reworking the AD site subnets, this is the only solution I can think of that will quickly remediate the issue while the longer term resolution is implemented.

    Thanks

    Monday, July 15, 2013 3:04 PM
  • Scenario:

    AD Site XYZ has 10.20.0.0/16 (supernet?) assigned to it.

    There is a separate Boundary Group for site assignment.

    There is a Boundary Group for content location which includes site XYZ

    When clients are distributed software that fall into the XYZ site they do not receive the software and I see the entry "Calling back with empty distribution points list" in the LocationServices.log.

    Questions:

    1.  Is this because supernetting is not supported and can cause intermittent issues?

    2.  Can this be alleviated by adding the IP range of the clients to the existing Boundary Group that already contains the XYZ site?

    3.  Content locations can overlap (right?) ...so I assume this is a valid solution.

    I understand IP ranges cause more expensive SQL queries but other than reworking the AD site subnets, this is the only solution I can think of that will quickly remediate the issue while the longer term resolution is implemented.

    Thanks

    Update:

    By adding the subnet range, the client receives the application.

    Questions:

    http://technet.microsoft.com/en-us/library/gg712679.aspx

    Configuration Manager does not support the direct entry of a supernet as a boundary. Instead, use the IP address range boundary type. When Active Directory Forest Discovery identifies a supernet that is assigned to an Active Directory site, Configuration Manager converts the supernet into an IP address range boundary.

    1.  Does the above mean if I used an AD Site from Forest Discovery that contained a supernet it would automatically convert it to a subnet range under the covers?

    2.  Does this mean you can use the AD Site? (as the supernet attached to the AD site was converted to a subnet range)

    3.  Or does it mean I need to use a subnet range in place of the AD Sites that contain supernets?

    Update 2:

    4.  While I am at it, Is it better to create one big Class B subnet range or break it up into only the used Class C subnets?  Maybe only a few of the Class C's are used out of the entire Class B supernet that's assigned to the AD Site.

    Note:  If I would have checked the box in the Forest discovery to make IP ranges from the discovered subnets it would have created large Class B IP ranges which are apparently a very expensive SQL query.  In my case I think it would be best to turn off Forest Discovery all together and just create IP ranges.  True?  This way AD Sites could remain as is and only updates to ConfigMgr would need to be made if a new subnet was added.  AD Sites were just a good non-manual solution.  Just don't use supernets in them.

    In this particular instance I only have 1100 clients and one ConfigMgr server with SQL local so maybe it would not make that much of a difference.  I could see in larger deployments where this could kill performance.

    Thanks


    • Edited by mniccum Monday, July 15, 2013 5:13 PM Updated
    Monday, July 15, 2013 3:39 PM