3 Replies Latest reply on May 4, 2018 8:00 AM by phoffmann

    Inventory scan failed :ldiscn32: the inventory server "XXX" did not respond

    BRajam Rookie

      Recently  we are facing issue with inventory scans not working on most of new client machines. We are able to successfully push the Landesk inventory agent  to a new PC. It seems to install fine but the PC is still sitting in Pending Unmanaged Client Deployment. It fails when sending scan results to the core server. When I tried to run a inventory scan manually ,it fails and displays the below error.




      Inventory Services seem to be up and running within the PC and core server.
      I can telnet from the PC to the core with ports 5007.
      Windows firewall is disabled.



      Appreciate your timely help and support on this


      Next, I havent configured anything under cloud services appliances,does it have anything do with this inventory scan fail?


        • 1. Re: Inventory scan failed :ldiscn32: the inventory server "XXX" did not respond
          phoffmann SupportEmployee

          As long as you're not using a CSA (Cloud Service Appliance) -- i.e. "are going over the internet", you won't need to have that stuff configued for inventory to work.


          Chances are this is -- pure and simple -- a networking problem (usually "shortname is used" / "can't resolve the name").


          Your device stays in "pending unmanaged" because the Core hasn't yet received an "actual" inventory scan, so all is logical so far.


          So - first thing:


          Run the following command line, see if that works:


          1 - Open up a CMD prompt (ideally -- "run as admin")

          2 - Go to "C:\Program Files (x86)\LANDesk\LDClient\"

          3 - Run the following command line (colour-coding things you need to replace with the SERVER IP to begin with).


          I'm using upper-case switches purely for better readability -- they're actually not case sensitive!


               ldiscn32.exe /V /F /SYNC /NTT= /S="" /I=HTTP://

          ... where you need to replace the ""-s with the actual IP of your Core.


          I want you to try an IP first, to eliminate your DNS being a problem .


          Now - assuming the above works, try replacing the ""-s with the FQDN of your Core Server.


          If THAT works, try replacing the the ""-s with the NETBIOS / shortname of your Core (at the latest, I would guess this is where it'll fail).


          What stuff does:

          /V ==> Run in verbose mode / with GUI enabled

          /F ==> Force a software scan (may as well get you a proper inventory)

          /SYNC ==> force sending the FULL scan file, not a delta file (needed since you didn't reach the Core yet).

          /NTT=... ==> Specifies how to talk to the inventory service.

          /S=... ==> Specifies the Core (overriding agent setting information !)

          /I=... ==> Points to the LDAPPL3 file on the Core which the client needs.




          Super bonus round ... (further troubleshooting)


          Check what your agent setting on the Core for CLIENT CONNECTIVITY says "in theory" ...


          ... and then cross-check that with the agent behaviour file that's on the client (under -- "C:\ProgramData\vulScan\").


          It'll be called something like "ClientConnectivityBehavior_{rest_of_name}.xml" ... you're looking for the "CORESERVER"-tag, as per the below section:


          (This is from my lab, so no big secret ).


          That allows you to cross-check what reference your agent *DOES* use versus what it SHOULD be using. If those two are the same -- great.


          If they are NOT the same, chances are you are in a catch-22 situation (where your agent can't contact your core because it has bad info -- and can't correct the info because it can't contact your core).


          How to solve this? Conveniently - very easily.


          Run THIS command line (again from the LDCLIENT directory):

          vulscan /coreserver="" /showui /updatebehavior

          ... that launches the vulnerability scanner with a few override options, specifying which Core to talk to (obviously change the IP address), forcing it to show UI (so you can see stuff as it happens) and specifying that it should ONLY check for updated agent settings (which it can then download).


          This isn't "the proper fix", but can get you out of a pinch.


          The "proper fix" is for you edit / fix your client connectivity agent setting, and/or re-build your agent installer (with the right config file?) to ensure that it's using up to date stuff.


          Couple of tips:

          • Don't use shortnames. DNS has enough issues with being reliable without NETBIOS messing things up.
          • If you can't trust your DNS (common enough, surprisingly), don't be shy about using IP!

            ... sure, you then can't use a DNS-alias when it's convenient, but equally, you won't get scerwed over by iffy DNS (or uses a HOSTS file entry for instance).


          Right - that should help .

          • 2. Re: Inventory scan failed :ldiscn32: the inventory server "XXX" did not respond
            BRajam Rookie

            Hi Phoffmann


            Many thanks for your detailed information.


            As you mentioned tried the command line scan with IP address of core server, but still  getting the same error



            Same error with FQDN and shortname as well.


            Core server is reachable from this client machine. any idea what could be wrong here?



            Next Super bonus round ... (further troubleshooting)
            I verified the ClientConnectivityBehavior_{rest_of_name}.xml, it does have the same as agent client connectivity  setting. FYI. I used shortname of coreserver in agent settings.

            As you mentioned,will create a agent with core IP address and give a try.


            Appreciate your help. Thanks in Advance

            • 3. Re: Inventory scan failed :ldiscn32: the inventory server "XXX" did not respond
              phoffmann SupportEmployee

              Hmm - interesting.


              I would argue that "Wireshark it" (from both ends) to see if the client is actually able to reach the Core. Generally, this is a case of "client cannot talk to the inventory service" ... which USUALLY translates as "can't resolve name", but could be blocked by something on the network (hence the suggestion to Wireshark it).


              In case the Inventory Service on the Core has gotten into a weird state, you may want to give it a re-start // check from another device whether it can send inventory all right.


              Let's start with those and go from there .