Some Clients not using Local Distribution Point RRS feed

  • Question

  • I have a new physcial site that we are wanting to put the SCCM client on the workstations. The local DP has been setup and the SCCM 2012 config settings for the new site have been made. I did a manual push to 5 workstations and monitored the ccmsetup.log. I had some clients using the local DP for the client install and some went back across the WAN to the MP to get the files. The ones that come back across the WAN to the MP have this in their log shown below. It does not appear to be boundary related or Client OS as they are in the same subnet that is configured and have both xp and win7 working and not working. I found a few others have had this issue come up searching the web, but none of solutions helped in my situation. The client is installing on all of the workstations I have manually pushed it to. I just can't figure out why some are not using the local DP and YES I have verified that the ones not using the local DP are in the same boundary group as the ones that do. 

    Any help is appreciated. FVH081-DP1 is the local DP and AHDC400 is my MP

    Only one MP AHDC400.phs-sfalls.amck.net is specified. Use it. ccmsetup 1/23/2015 2:56:41 PM 2728 (0x0AA8)
    Searching for DP locations from MP(s)... ccmsetup 1/23/2015 2:56:41 PM 2728 (0x0AA8)
    Current AD site of machine is FVH LocationServices 1/23/2015 2:56:41 PM 2728 (0x0AA8)
    Local Machine is joined to an AD domain LocationServices 1/23/2015 2:56:41 PM 2728 (0x0AA8)
    Current AD forest name is amck.net, domain name is fvh.amck.net LocationServices 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    DhcpGetOriginalSubnetMask entry point not supported. LocationServices 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Begin checking Alternate Network Configuration LocationServices 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Finished checking Alternate Network Configuration LocationServices 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Adapter {AB6BAB2C-7B65-441A-A83C-C91FF8B8498D} is DHCP enabled. Checking quarantine status. LocationServices 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Sending message body '<ContentLocationRequest SchemaVersion="1.00">
      <AssignedSite SiteCode="MCK"/>
      <ClientLocationInfo LocationType="SMSPACKAGE" DistributeOnDemand="0" UseProtected="0" AllowCaching="0" BranchDPFlags="0" AllowHTTP="1" AllowSMB="0" AllowMulticast="0" UseInternetDP="0">
        <ADSite Name="FVH"/>
        <Forest Name="amck.net"/>
        <Domain Name="fvh.amck.net"/>
    <IPAddress SubnetAddress="" Address=""/>
    ' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Sending message header '<Msg SchemaVersion="1.1"><ID>{DA5C91BE-3A3E-4E14-AF6E-DB0E9AC36878}</ID><SourceHost>FVHH008</SourceHost><TargetAddress>mp:[http]MP_LocationManager</TargetAddress><ReplyTo>direct:FVHH008:LS_ReplyLocations</ReplyTo><Priority>3</Priority><Timeout>600</Timeout><ReqVersion>5931</ReqVersion><TargetHost>AHDC400.phs-sfalls.amck.net</TargetHost><TargetEndpoint>MP_LocationManager</TargetEndpoint><ReplyMode>Sync</ReplyMode><Protocol>http</Protocol><SentTime>2015-01-23T20:56:42Z</SentTime><Body Type="ByteRange" Offset="0" Length="1068"/><Hooks><Hook3 Name="zlib-compress"/></Hooks><Payload Type="inline"/></Msg>' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    CCM_POST 'HTTP://AHDC400.phs-sfalls.amck.net/ccm_system/request' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Content boundary is '--aAbBcCdDv1234567890VxXyYzZ' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Received header '<Msg SchemaVersion="1.1">
     <TargetHost>FVHH008</TargetHost><TargetEndpoint>LS_ReplyLocations</TargetEndpoint><ReplyMode>Sync</ReplyMode><Protocol>http</Protocol><SentTime>2015-01-23T20:56:42Z</SentTime><Body Type="ByteRange" Offset="0" Length="2590"/><Hooks><Hook3 Name="zlib-compress"/><Hook Name="authenticate"><Property Name="Signature">3082018F06092A864886F70D010702A08201803082017C020101310B300906052B0E03021A0500300B06092A864886F70D0107013182015B30820157020101303430203110300E0603550403130741484443343030310C300A06035504031303534D53021058042BA685CEB3A74AC16009523D655A300906052B0E03021A0500300D06092A864886F70D0101010500048201002E2019E353A4244A8CA9D2451A6206393F00541279E76F3EFEED3C768C36F01EB88834E74E53D3063FC56D5A899C604036B8DCBACC765156270E5417D0A384440A2B29B08487F9BCEB84C3642D736587692675CBFB78DAF8017D94C5782E5166868F7B0B01E006319B1BDF6FA37DE9AFE5389C5CADF3A72572B08D01D68EE369C9830F4952B6C1B38F710B87888C65C27EB8176B8064BC392DB06C966112F119AD62E53C7B79EC26CEA9CFE027D401E535EAB166E18A5F37CB806EC21AF66510A41B5B4936953682DAF157EA50E02D51DF8A78DE4E12A368AE7693EEC37ACFAAC16ACF4C5DA0838F5821413C79A478DBAF1DCDAE23F6734C1D70882D3CBF4433</Property><Property Name="AuthSenderMachine">AHDC400;AHDC400.phs-sfalls.amck.net;</Property><Property Name="MPSiteCode">MCK</Property></Hook></Hooks><Payload Type="inline"/></Msg>' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Received reply body '<ContentLocationReply SchemaVersion="1.00"><ContentInfo PackageFlags="16777216"><ContentHashValues/></ContentInfo><Sites><Site><MPSite SiteCode="MCK" MasterSiteCode="MCK" SiteLocality="LOCAL" IISPreferedPort="80" IISSSLPreferedPort="443"/><LocationRecords><LocationRecord><URL Name="http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSPKG$/AHS00002" Signature="http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSSIG$/AHS00002"/><ADSite Name="FVH"/><IPSubnets><IPSubnet Address=""/><IPSubnet Address=""/></IPSubnets><Metric Value=""/><Version>7804</Version><Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities><ServerRemoteName>FVH081-DP1.phs-sfalls.amck.net</ServerRemoteName><DPType>SERVER</DPType><Windows Trust="1"/><Locality>LOCAL</Locality></LocationRecord></LocationRecords></Site><Site><MPSite SiteCode="MCK" MasterSiteCode="MCK" SiteLocality="LOCAL"/><LocationRecords/></Site></Sites><ClientPackage FullPackageID="AHS00002" FullPackageVersion="1" FullPackageHash="5EF3A189C48F3469440A83026EC8ECD36EAD6EAF3B5D35663F8201BDE175413C" MinimumClientVersion="5.00.7804.1000" RandomizeMaxDays="7" ProgramEnabled="false" LastModifiedTime="30282566;3841038464" SiteVersionMatch="true" SiteVersion="5.00.7804.1000" EnablePeerCache="true"/></ContentLocationReply>' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Found local location 'http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSPKG$/AHS00002' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Discovered 1 local DP locations. ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    PROPFIND 'http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSPKG$/AHS00002' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Got 401 challenge Retrying with Windows Auth... ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    PROPFIND 'http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSPKG$/AHS00002' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Failed to correctly receive a WEBDAV HTTP request.. (StatusCode at WinHttpQueryHeaders: 401) ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Failed to check url http://FVH081-DP1.phs-sfalls.amck.net/SMS_DP_SMSPKG$/AHS00002. Error 0x80004005 ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    Enumerated all 1 local DP locations but none of them is good. Fallback to MP. ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    GET 'HTTP://AHDC400.phs-sfalls.amck.net/CCM_Client/ccmsetup.cab' ccmsetup 1/23/2015 2:56:42 PM 2728 (0x0AA8)
    C:\WINDOWS\ccmsetup\ccmsetup.cab is Microsoft trusted. ccmsetup 1/23/2015 2:56:43 PM 2728 (0x0AA8)

    Friday, January 23, 2015 9:58 PM


  • Yes the local client setup log points that out. You said the IIS logs on the DP do not show anything regarding the clients getting an access error in its logs.

    The Dp is not in the same domain as the workstations, it is in the same domain as the SCCM server. We have the same setup with another child domain and that one works fine.

    If AD replication could be a possible cause of this, I guess we should get the problem DC in that child domain cleaned up first.

    I appreciate the suggestions, thanks.

    Monday, January 26, 2015 10:20 PM

All replies

  • What type of boundary are you using? Subnet ID, Range, AD?


    Friday, January 23, 2015 10:03 PM
  • Based upon the last 10 lines (or so) of the log file, it does find a local DP names FVH081-DP1 but when it tried to access the content there, it failed the authentication attempt and fell back to using the MP: AHDC400-phs-sfalls.

    Lots of things can cause auth failures like AD replication, bad accounts, etc. If you check the corresponding IIS logs on the DP, you may/should get further details on why the auth attempt failed.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, January 23, 2015 10:53 PM
  • Subnets

    Monday, January 26, 2015 1:47 PM
  • AD replication? I think you may have something there. That site is a child domain of the forest we are in. It has a DC that is having some replication issues. I will check the IIS logs on the DP. Thanks
    Monday, January 26, 2015 1:48 PM
  • Nothing in the IIS logs on the DP except for one of the workstations that was able to connect and download the client successfully. Can you give me more info on how AD replication issues might affect the clients in this way?
    Monday, January 26, 2015 2:34 PM
  • As mentioned, that's simply one of many different things that could disrupt authentication. Based on the logs, authentication is clearly failing here -- no authentication means no authorization which in turn means no access to the resource(s) attempting to be accessed. 

    You'll need to correlate the IIS logs with client failures (timestamps will be useful here) to get additional info.

    Are there multiple domains or forests involved here?

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, January 26, 2015 2:44 PM
  • Single forest with mutiple child domains. SCCM is in one child domain trying to get this other child domain's workstations as clients. We have the same setup for another child domain and it worked without any issues.

    The IIS log file in C:\inetpub\logs\logfiles\w3svc1 only shows the successful installs. There are no entries about any failures in the log to correlate unfortunately. All failures have been XP SP3 machines except for one Win7 pc and all successes have been Win7 except for one xp machine.

    You wouldn't think it is network related because some workstations can access the DP fine.

    It's not boundaries because the successes and failures are all sharing the same subnet that is configured.

    Wasn't MSI 4.5 required for SCCM 2012 clients?

    Monday, January 26, 2015 8:36 PM
  • I'll say it again just to reinforce, the log clearly shows authentication errors -- that's what WINHTTP 401 is. That is the root cause (within ConfigMgr at least) of the issue. This is not necessarily a network issue.

    The Windows Installer version at this point is irrelevant as it's simply trying to download a file.

    Is the DP in the same domain as this client? Based upon the above log, it does not appear to be. What about the other clients?

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, January 26, 2015 9:37 PM
  • Yes the local client setup log points that out. You said the IIS logs on the DP do not show anything regarding the clients getting an access error in its logs.

    The Dp is not in the same domain as the workstations, it is in the same domain as the SCCM server. We have the same setup with another child domain and that one works fine.

    If AD replication could be a possible cause of this, I guess we should get the problem DC in that child domain cleaned up first.

    I appreciate the suggestions, thanks.

    Monday, January 26, 2015 10:20 PM