4 Replies Latest reply on Feb 24, 2017 9:05 AM by phoffmann

    Failed to download patches. Error code 12

    Javi Rookie

      Hi

       

      When we try to download patches using Landesk, it fails with next error message in vulscan.log:

       

      Fri, 17 Feb 2017 14:24:39 Download failed unable to get path, error code: 12 file: http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe

      Fri, 17 Feb 2017 14:24:39 Failed to download http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe.  Error code 12

      Fri, 17 Feb 2017 14:24:39 http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe Error

      Fri, 17 Feb 2017 14:24:40 Download Failure: Error 80004005 downloading http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe

      Fri, 17 Feb 2017 14:24:40 Last status: Error. No se pudo descargar http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe

      Fri, 17 Feb 2017 14:24:40 DeferredReportAction: name 'CitrixReceiver4.6.exe', code '0', type '-1', status 'Error en la descarga del archivo CitrixReceiver4.6.exe'

       

      I have tried with diferent patches, and error is the same.

       

      If we try to download patches accesing URL http://landesk_server/LDLogon/patch/INTL/Citrix/CitrixReceiver4.6.exe , we can do it with no problems.

       

      Any ideas?

       

      Thanks in advance

       

      Regards

        • 1. Re: Failed to download patches. Error code 12
          cloevin Apprentice

          It sounds like a permission issue possibly on the IIS side.  Do you have a packages directory you use to push out software?   Create that citrix package using UNC with a distribution package and see if you get the same error. If it works, look over your IIS permission of the Patch directory

           

          Just an example

          \\server\packages\citrix\citrixReceiver4.6.exe /silent

          • 2. Re: Failed to download patches. Error code 12
            phoffmann SupportEmployee

            If you follow the steps HERE - How to enable Xtrace Diagnostic Logging  - that'll let you know how to enable max verbosity on logging (check the bottom comments for a copy'able .REG file in effect).

             

            That'll give you (or our support) a better idea as to what's actually going on, as the downloader bits will be a LOT more chatty.

             

            Checking the IIS side of things as per the above comment would be quite useful too - first to make sure THAT the client is downloading the file from IIS (could be that he's downloading a corrupted/broken file from a peer for instance & failing upon the local hash check).

             

            If you want to help control the download side of things by hand easily, check out this article as well -- How to use PEDownloader.exe to Duplicate / Troubleshoot Software Distribution .

             

            Finally, the following are also helpful:

            - How to troubleshoot Download Failures in Software Distribution (Advanced)

            - How to quickly troubleshoot a Software Distribution job

            - Error: "Failed to download additional files"

             

            Hope that helps.

             

            (And yes, that may SEEM like a bit overkill, but it helps you to understand what logs/binaries do what - helps you paint a much fuller picture) .

            • 3. Re: Failed to download patches. Error code 12
              Javi Rookie

              Hi phoffmann, cloevin

               

                   First of all, thanks for your help.

               

                   I dont think it is a problem of IIS permissions. As I said I can download patches accesing URL http://landesk_server/LDLogon/patch/INTL/

                   If I try to download patches using UNC with a distribution package, it fails also

               

                   I have enabled Xtrace Diagnostic Logging to check if log give us more information, but I don´t find anything special:

               

              Fri, 24 Feb 2017 13:33:58 Curl TRANSMIT: 406 bytes

              Fri, 24 Feb 2017 13:33:58 Curl INFO: upload completely sent off: 406 out of 406 bytes

               

              Fri, 24 Feb 2017 13:33:58 Curl INFO: Server Microsoft-IIS/8.5 is not blacklisted

               

              Fri, 24 Feb 2017 13:33:58 Curl INFO: Connection #0 to host 127.0.0.1 left intact

               

              Fri, 24 Feb 2017 13:33:58 CreateFile failed with 53

              Fri, 24 Feb 2017 13:33:58 Download failed unable to get path, error code: 12 file: http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe

              Fri, 24 Feb 2017 13:33:58 Pushing http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe
              to done

              Fri, 24 Feb 2017 13:33:58 Failed to download http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe.  Error code 12

              Fri, 24 Feb 2017 13:33:58 http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe
              Error

              Fri, 24 Feb 2017 13:33:58 PushToDoneTail: m_fileDoneCount = 1, m_fileCount = 0

              Fri, 24 Feb 2017 13:33:58 About to release m_workCompleteSemaphore

              Fri, 24 Feb 2017 13:33:58 Download Complete: 0 successful, 1 failed

              Fri, 24 Feb 2017 13:33:58 Actual download of data took 0 ms, but slept 0 ms of that time,
              0.000000 bandwidth used

              Fri, 24 Feb 2017 13:33:58 Push of files took 0 ms, but slept 0 ms of that time, 0.000000
              bandwidth used

              Fri, 24 Feb 2017 13:33:58 DiscoveryWorkerThread: thread 7416 exiting

              Fri, 24 Feb 2017 13:33:59 Download Failure: Error 80004005 downloading http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe

              Fri, 24 Feb 2017 13:33:59 Last status: Error. No se pudo descargar http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe

              Fri, 24 Feb 2017 13:33:59 DeferredReportAction: name 'windows-kb890830-x64-v5.45.exe', code
              '0', type '-1', status 'Error en la descarga del archivo windows-kb890830-x64-v5.45.exe'

              Fri, 24 Feb 2017 13:33:59 client policy file:
              C:\ProgramData\LANDesk\Policies\CP.154.RunNow._4s&#47vetlT7NlciunashPis1tN7e0=.xml

              Fri, 24 Feb 2017 13:33:59 Reading policy parameters

              Fri, 24 Feb 2017 13:33:59    group=LANDESK_SERVER.domain_v2208

              Fri, 24 Feb 2017 13:33:59    fixnow=True

              Fri, 24 Feb 2017 13:33:59   IgnoreSubsequentAttempts=False

              Fri, 24 Feb 2017 13:33:59    MCast_FileCount=1

              Fri, 24 Feb 2017 13:33:59    MCast_0=http://Landesk_Server/LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe

              Fri, 24 Feb 2017 13:33:59 Local Task API not initialized, method will fail

              Fri, 24 Feb 2017 13:33:59 App killer is stopping

              Fri, 24 Feb 2017 13:33:59 RunPatches completed.  1
              processed.  0 installed.  1 failures.

              Fri, 24 Feb 2017 13:33:59 Enviando el histórico anterior al servidor central

              Fri, 24 Feb 2017 13:33:59 HTTP POST: http://LANDESK_SERVER.domain:443/WSStatusEvents/EventHandler.asmx

              Fri, 24 Feb 2017 13:33:59 Setting a proxy...

              Fri, 24 Feb 2017 13:33:59 Setting socket timeout to 1000 * 60 * 4

              Fri, 24 Feb 2017 13:34:01 Success

              Fri, 24 Feb 2017 13:34:01 Last status: Listo

              Fri, 24 Feb 2017 13:34:01 Reboot action set to 'never.' Not rebooting.

              Fri, 24 Feb 2017 13:34:01 Reboot and rescan.  Rescan set to false, so doing nothing.

              Fri, 24 Feb 2017 13:34:01 Will not 'continue' because reboot is needed

              Fri, 24 Feb 2017 13:34:01 ReleaseMutex 'Global\vulscan_scan' succeeded. Code: 0

              Fri, 24 Feb 2017 13:34:01 Enviando estado al servidor central

              Fri, 24 Feb 2017 13:34:01 HTTP POST: http://LANDESK_SERVER.domain:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=idn1554_taskid154.logz

              Fri, 24 Feb 2017 13:34:01 Setting a proxy...

              Fri, 24 Feb 2017 13:34:01 Setting socket timeout to 1000 * 60 * 4

              Fri, 24 Feb 2017 13:34:01 Success

              Fri, 24 Feb 2017 13:34:01 Freeing the compressed results.

               

                   Also, if I use pedownloader tool to check if I can download patchs from client, it works ok

               

               

                   Any help would be appreciated

               

              Thanks in advance

               

              regards

              • 4. Re: Failed to download patches. Error code 12
                phoffmann SupportEmployee

                Huh - OK ... bit of an odd one (code for - "not seen that one before").

                 

                So the first question is what's throwing the error 12 (it's not an IIS error, it may or may not be "us" - could be all sorts of things). We tend to just try and "get anything" around errors.

                 

                Not seen something like this though. Odd.

                 

                So ... things I'd suggest checking to make sure.

                • When you run the repair task on the client, does it ...
                  • ... actually register a 'poke' in the IIS log(s) on the Core -- default location for them would usually be this -- C:\inetpub\logs\LogFiles\W3SVC1\ -- ?
                    • Note that IIS logs are *always* logged in GMT. So adjust to your timezone!
                    • ... you'd be looking for something like the following line:

                {DATE} {TIME} {IP_OF_CORE} GET /LDLogon/patch/INTL/Microsoft/windows-kb890830-x64-v5.45.exe - 80 - {IP_Of_Client} - - 200 0 995 262144 127 16

                 

                If you're not sure how to read IIS logs, grab the presentation materials I've attached to the following article -- [Tech Brief On-Demand Webinar 2016] Provisioning with LANDESK Management Suite  -- towards the end, I include a crash-course in reading IIS logs (it's quite easy, if you don't let yourself get intimidated by the wall of text). The video will cover some of that in a "flying over it" method towards the end.

                 

                ... as it happens, I've still got a "mini" version of that stuff, so I've attached the "just IIS" related stuff as a PDF for your benefit.

                 

                As an alternative, set up the same file as a soft dist package & roll it out to that one client. The purpose here is to trouble shoot (see THIS article - Error: "Failed to download additional files" - for information on logs to be checking). Note that most logs mentioned in the article are now in one of the following two locations:

                - C:\Program Files (x86)\LANDesk\LDClient\Data\

                - C:\ProgramData\LANDesk\Log\

                 

                If you're comfortable with Wireshark, you may want to run a trace there, just to see what you're talking with (in case there's any kind of www-caching appliance you're not aware of, for instance).

                 

                Now the thing(s) I'm trying to make sense of:

                • Does the clients' VULSCAN successfully even touch that www-share?
                  • ... clearly we can talk with IIS on the Core "in some fashion" as Vulscan wouldn't have gotten as far as it currently got without that.
                  • ... but, I've seen things like www-caching appliances screw around with HTTP-offered downloads.
                • ... whilst the log doesn't show that we download as much as a single byte via VULSCAN, it may be worth checking the following -- C:\Program Files (x86)\LANDesk\LDClient\CurrentDownloads.log -- that's a mini-log that's helpful in understanding where we're trying to go to, in order to download a file. In this case, I'm not seeing anything like peer download going on (or - in fact - a download followed by a rejection of the calculated hash).

                 

                ... it's the fact that 0 bytes get downloaded that has me scratching my head (and why I suspect that there's some nonsense like www-chaching appliances or so happening) ...

                 

                Even further confused by the fact that PEDownloader "works" ... Vulscan uses the same SoftDist API's ...although ... you did specify "allowSource" but not "AllowPeer" (which may be a red herring, I'm just trying to make sense of things). Just trying to make sense if the problem comes from peer download side of things ... This is why PEDownload / the SoftDist angle may come in handy.

                 

                =============

                 

                Let me dig some more ... AHA - found it.

                 

                I've also attached "Peer-Download Annotated Logs.7z", which I've done for another customer about a year ago, to explain what logs do what. That may help you.

                 

                Please note that you may not see the log interactions by use of PEDownloader alone, as it doesn't care about logging in the same way SDCLIENT & co do! You should still see requests logged on "other peers" for instance, but not necessarily on the client you're running PEDownloader itself on.

                 

                =============

                 

                You may need to go through support for this ultimately - but having an idea via Wireshark and co - what's going on network wise will help (and be useful to support too). If we can talk to the Core's IIS in principle (which we must do for vulscan to get as far as it can), pretty much the only thing that makes sense to me at this point to screw you over would be something like a www-caching appliance.

                 

                BUT ... that should equally screw you over when you're downloading something via PEDownloader ... unless there's something messed up with Vulscan specifically in your environment? You may want to try and do a clean uninstall / reboot / re-install of the LD agent, just in case there's some DLL or so not registered for instance.

                 

                I'd be "happier" with a "I downloaded stuff, but rejected it 'cos I didn't like the hash" as that would be more easily traceable as to what you're downloading and from where. It's the whole 0 bytes thing that doesn't make a lick of sense ... most peculiar.