2 Replies Latest reply on Apr 15, 2012 4:28 PM by jkhill

    scheduled inventory scan

    jkhill Specialist

      I'm having a hard time getting a scheduled inventory scan to work.


      I have an inventory scan job that I believe came with LDMS called inventoryscanner.  It includes this line:

      ;--- assumes that ldappl3.ini is in same dir as the .exe
      REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\LDISCN32.EXE<qt/> /NTT=%server%:5007 /S="%server%" /I=HTTP://%server%/ldlogon/ldappl3.ldz /NOUI /NOCD /f /sync



      A few months ago I set this up in a scheduled task.  I've used it occasionally and always just assumed it worked. 


      Yesterday I had a time-sensitive software distribution and I needed to run an inventory between two tasks (the first task removed old software; the second installed the new).


      About 20 minutes after I'd run the inventory scanner I decided to be anal and checked a query to confirm that none of the PCs still had the old software.  It reported that most did - not becuse the distribution job hadn't worked but because the inventory scan had not been triggered.  After 40 minutes I checked again and another 20-30 machines (out of 600) had rescanned and dropped out of the query.  I went back to the task and confirmed that it reported all the machines as Done - No Error.  Four *hours* later there were still over a hundred machines that hadn't submitted scan results, so right-clicked on each one and selected Inventory Scan | hardware and software scan.  Each machine took <5 minutes to complete.


      So what's the deal?  Is the only way to get trustworthy scan results to run them by hand?  Or am I doing something wrong?

        • 1. Re: scheduled inventory scan
          MarXtar ITSMMVPGroup

          Nothing wrong with the script. Most likely is that since you are doing a full scan including software on all of your machines your inventory service isn't able to process all of the scans so quickly. LDMS receives the scan and writes it to a file pending writing it to the database when it has the time since the SQL is slower/higher load than the file write. At peak times if you look at <coreserver>\ldmain\ldscan then you will see a lot of .scn files building up.


          There are some configuration items to help speed this up in the advanced section of the inventory scanner, but first things first, see if this is your issue.


          Mark McGinn

          MarXtar Ltd


          LANDesk Silver ESP


          The One-Stop Shop for LANDesk Enhancements

          - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

          - State Notifier - Real-Time Device & User State Inventory Updating & Alerting

          1 of 1 people found this helpful
          • 2. Re: scheduled inventory scan
            jkhill Specialist

            Thanks for your response.  I had forgotten about the ldscans folder.  Watching it gave me the insight I needed, which was to remove /sync from the script.


            5:02: started job against 469 PCs and servers.

            5:15:  461 .scn files in ldscan folder.  Most arrived by the five minute mark but more continue to appear.

            5:23:  175 .scan files from 5:04 are still alive.  No new files since 5:19.

            5:35:  67 objects remaining timestamped 5:04.  Last new file at 5:24.

            5:37:  initiated a hardware/software scan on one machine whose file was dated 5:13 (meaning it prob won't be ingested for another


            fifteen minutes).  Scan completed in 52 seconds but did not, as you suggested it would not, immediately appear in the database.  Interestingly, the .scn file was only 56KB, versus 1MB - 2.2MB for all the others.  This made me take another look at the command in the script, where I was surprised to see /sync, which I hadn't noticed before.

            5:44:  I ran the same command as the script, minus /sync, on my own PC.  The resulting .scn file is 250KB, much less than the others, though more than what I got from a console-triggered scan.  Interesting.  Meanwhile,


            197 of the original .scn files remain.

            5:56:  89 of the original files



            ~6:00:  done.


            These are actually significantly better results than I experienced yesterday, but still disappointing compared to what I was hoping for.


            I decided to test again, this time making a copy of the script and removing /sync from the command line.Using the /sync discovery from the first test, I removed /sync from it.

            6:10:  started job

            6:12:  195 .scn files.  Average size:  81KB!

            6:14:  300 .scn files.

            6:16: 120 .scn files. 

            6:17:  empty.  Checked the console and all the machines that could respond have an updated scan date.


            Now *that*'s more like it.