locked
SCCM 2012 r2 - DTS Job Errors RRS feed

  • Question

  • Hi all,

    I have been struggling with this one for a while and hoping some genius out there can help me!

    Current setup:

    1 x Primary Site Server

    5 x Distribution Points

    1x SQL

    I can deploy packages fine to all DP's except one, and the strange thing is, about 10% of clients in the site work, while the rest remain on no messages received.. Their datatransferservice.log has the below in it (omitted our details):

    DTS job {AA743EF8-8D90-4A1E-ACB6-5FD6B4CEBB30} BITS job {359F8132-1AE8-48C5-A603-DF20B391AB9C} failed to download source file http://SERVER.ad.aie.edu:80/SMS_MP/.sms_pol?xxx2002C-xxx00013-BB8CD055.1_00 to destination C:\windows\CCM\Temp\{882EBEEB-D9C9-4E9A-B964-53A38A6F9AB0}.tmp with error 0x80200013

    The last thing execmgr sees is

    Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="xxx00013",ProgramID="Test", actionType 45l, value NULL, user NULL, session 4294967295l, level 0l, verbosity 30l

    ClientLocation - shows the correct MP

    Locationservices - Shows the client being in the correct site, which leads me to believe boundary groups are not an issue.

    This site has always had a problem with this, however we did some major network changes over the weekend and a lot of the clients in this site checked in for this first time, at which point i had individual IP address ranges for each subnet (3 or so).  I then changed it to one IP range to cover the new design of 15 or so subnets, the IP range is from the start of the first available IP, all the way to the last usable of the last VLAN, including gateways/ SVI's in between.

    I have tried repairing clients, re-installing, repairing WMI, manually rechecking policy and nothing works.  The clients are definitely online.

    Can anyone help me?

    Cheers

    Wednesday, June 15, 2016 11:56 PM

Answers

  • Turns out it was Sophos, which is weird as we have one in each site but it is only affecting this one.

    HTTP Scanning is turned on.

    Thursday, June 16, 2016 6:52 AM

All replies

  • If i try to browse to the policy location, the PC can get to it. 

    On the network side of things, there really isn't a pattern of which PC's are working as i thought it would be network related.  All clients that have succeeded are spread throughout the VLANs / network.

    • Edited by Shank89 Thursday, June 16, 2016 12:09 AM
    Thursday, June 16, 2016 12:07 AM
  • Are the clients using a proxy server? Is there any info on the IIS logs on the DP?

    If this post was helpful, please click the up arrow or propose as answer.

    Thursday, June 16, 2016 12:47 AM
  • Nope no proxy,

    Nothing really noteworthy in the logs, the last entry was:

    2016-06-16 01:01:06 10.17.63.4 GET /SMS_DP_SMSPKG$/xxx00015/sccm /Test%20Deployment.bat 80 - 10.17.33.202 Microsoft+BITS/7.5 - 200 0 0 196 0

    Which is the correct package

    Thursday, June 16, 2016 1:04 AM
  • Should a client have multiple GETs for the same single exe package?
    Thursday, June 16, 2016 1:18 AM
  • When you say "I can deploy packages fine to all DP's except one, and the strange thing is, about 10% of clients in the site work, while the rest remain on no messages received.. Their datatransferservice.log has the below in it (omitted our details):" - do you mean that you can distribute packages fine to that DP, yet the clients do not download packages from that specific DP?

    Is it something specific with that distribution point? If you change the boundary group to use a different DP, do the clients download the packages? (even though it will be slower)



    If this post was helpful, please click the up arrow or propose as answer.

    Thursday, June 16, 2016 1:30 AM
  • It doesn't seem like it is even getting to the stage of using the DP to install.

    According to the datatransferservice log it fails to get the policy and place it in the temp directory.

    I can test moving the group to a different site though.

    Thursday, June 16, 2016 1:43 AM
  • "do you mean that you can distribute packages fine to that DP, yet the clients do not download packages from that specific DP?"

    Sorry just saw this, yes packages distribute fine to all DP's, but within this site, some / most clients are having the same issues.

    Thursday, June 16, 2016 2:05 AM
  • Ok, changing the target DP did not work, only 10% of clients processed the package again.

    The clients that did process it, i could see they were pointing to the new DP in locationservices.

    The ones that did not work, locationservices did not mention anything about the new DP, also datatransfer log issued the same errors as earlier.

    Thursday, June 16, 2016 3:20 AM
  • Ok. If the client is having the issue with the working DP, sounds like you can rule out the DP as the issue and look at the specific clients. Its just one site where the clients live that are affected? You don't have any specific GPO's that could be affecting it? I am out of ideas here sorry. 

    https://technet.microsoft.com/en-us/library/cc720473(v=ws.10).aspx

    0x80200013

    BITS uses range headers in HTTP requests to request parts of a file. If the server or proxy server doesn’t understand Range requests and returns the full file instead of the requested range, BITS puts the job into the ERROR state with this error. Capture the network traffic during the error and examine if HTTP GET requests with “Range” header are getting valid responses. Check proxy servers to ensure that they are configured correctly to support Range requests.


    If this post was helpful, please click the up arrow or propose as answer.

    Thursday, June 16, 2016 3:55 AM
  • Correct one site, the client was installed via gpo with the /bits:foreground option as it was the only way i could get the installer to run.

    I did see that BITS error number, i recall doing that once, don't think it was using range.

    If it were, how would i fix that? It would be hard to troubleshoot every client as there are about 300+

    Thursday, June 16, 2016 4:19 AM
  • Turns out it was Sophos, which is weird as we have one in each site but it is only affecting this one.

    HTTP Scanning is turned on.

    Thursday, June 16, 2016 6:52 AM