1 2 Previous Next 15 Replies Latest reply on Mar 14, 2018 10:01 AM by phoffmann

    How does the inventory really work  ?

    Marco_F Apprentice

      Hello everyone,


      I am a new Ivanti user and this is my first post.


      I am a bit frustrated regarding the inventory local scheduler and I wonder if is there somebody that is facing the same issue.


      Basically, in the Local Scheduler Command I configured the settings you can see in the attached file but I am not able to handle these tasks as desidered.


      Although these settings, all my PCs run the inventory scan in different days and not the same days I would like for.


      I mean, I would like that my inventories always run on Monday-Wednesda and Friday from 1:00pm to 2:00pm but it is not and I do not understand why !!


      I configured the inventory starting from Monday till Friday but it seems that it considers Saturdays and Sundays too.


      So, is it right (by design) or is it a bug ?


      Just another example of a PC which will try to start the inventory on Saturday (...but it will not start it because of it will be turned off on that day):


      7: C:\Program Files (x86)\LANDesk\LDClient\ldiscn32.exe /noui

           handle    : 777

           start     : Sat Mar 10 13:00:02 2018

           frequency : 172800

           Filter 1  : Time of Day 13 to 14

           Filter 2  : Day of Week 1 to 5


      I can understad a mini-inventory (in different days) only when a PC changes its IP address but this is a setting that has been rightly configured:


        8: C:\Program Files (x86)\LANDesk\LDClient\ldiscn32.exe /mini /noui

           handle    : 778

           start     : Fri Mar  9 09:25:34 2018

           frequency : 600

           Filter 1  : IP Address Change Filter


      Lastly, but not less important:


      I have some users that complaint about the inventory because of it takes long time before finishing (sometimes till 2 or more hours) and I can not understand this too.


      As far as I know,  based on this URL:


      Inventory Delta Scan Whitepaper


      the PCs should run a really slight inventory if there is nothing changed from the previuos one but it does not seems because, as I wrote, it seems that inventory always scans all the folders and path that have been already scanned.


      I really appreciate any useful information or tip on how to "fix" my issues.




        • 1. Re: How does the inventory really work  ?
          phoffmann SupportEmployee

          Couple of basics:

          • Always state what major version you're on & what minor service update you're on (i.e. "I'm on EPM 2017.3 + SU") for reference. Helps with context & is a good habit to get into.
          • Always state what clients you're dealing with (in this case it's obvious it's Windows). But "Windows is different to MAC is different to Linux" in a bunch of ways, and those differences can be key. Just building good habits is all.


          Now - on to this issue at hand.


          A few basics:

          Inventory taking 2 hrs is "unusual", but not necessarily a problem. Your first important point here is that you're running without the UI -- so we're running at whatever you've configured in the agent setting in terms of "CPU utilisation" (My guess is - "very low").


          This would be more of a serious concern if you'd see a case of "Inventory is eating 99% CPU for 2 hours", but I would expect that "the process may take 2 hours to finish, but barely touches the CPU". So I would expect this to be a case of "working as configured".


          One way to "confirm" this in essence, is to run an inventory scan with GUI enabled (which will run "at full speed"). A few more bits of info here in the debugging section below!


          Debugging suggestions:

          First of all -- run an inventory scan with GUI enabled & useful debug-options. I'm going to give you my favourite which is a great "catch-all" for all manner of situations (some won't be relevant here):


          Use this command line:


          ldiscn32.exe /v /f /sync /pd /sae /debug


          Here's what the various switches do:

          • "/V" -- run in "verbose" mode (i.e.: show GUI, run at 100% rather than CPU utilisation specified in the agent behaviour).
          • "/F" -- force a software scan to be included as part of the inventory scan (useful for various "non synching issues").
          • "/SYNC" -- Force/ovveride the option to send a full (non-delta) inventory scan to the Core (usefulf for issues around devices not synching properly). Shouldn't be a factor in this particular case.
          • "/PD" -- Force/ovveride the option to send all product definitions as part of the inventory scan. Useful in case of data issues / general troubleshooting.
          • "/SAE" -- Force/ovveride the option to send all executed binaries as part of the inventory scan. Useful in case of data issues / general troubleshooting.
          • "/DEBUG" -- Forces/enables the use of debug-option to be logged. DON'T do this "company wide", as this fills a LOT of data into a dedicated log (see below).


          NOTE -- when using the "/debug" switch, we populate the following file (with VERY detailed) information:

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



          ... be prepared to clear out that file BEFORE running with the debug switch & copy it off / delete it after running with debug enabled. It's VERY easy to get to 10+ MB of data with debug enabled on a single scan even on a clean device.


          BUT ... it'll give you VERY detailed information what's going on & how long it's taking (so may help you here if needed).


          Compare a "GUI-enabled" and a normal, GUI disabled inventory scan, in case there's oddities.


          About scheduler type stuff:

          • Read this -- Local Scheduler and being aware of time creep .
            Notice that we'll *START* based on the FINISH time ... and due to your filter, that may/will be "the next day" to be a legitimate thing again.

            So it's important you understand "what you've configured" (versus "what you intended") filter wise.

            <This is something that catches a lot of folks off guard / is a common learning curve. It's not "a biggie", but just something that's not commonly considered.>
          • Any particular reason you've got an interval of 172800 (seconds) / that's every 48 hours...?
            I would suggest just running it every 12 hours (since you've got a time-window configured), to ensure you get a scan every day for instance.


          Right - that should be a good starter for 10 / some basic snippets of how things work.

          • 2. Re: How does the inventory really work  ?
            phoffmann SupportEmployee

            Apologies for the "Wall of info", but there's a lot of concepts to get across / make you aware of.

            • 3. Re: How does the inventory really work  ?
              Marco_F Apprentice

              Thank you very much for your reply.


              ...and you are right, I forgot to write some useful information:


              1) we have EPM 2017.1 SU1 and the O.S is definitely Windows.


              We have just migrated from another competitor (after more than 10 years)  to Ivanti and, as I was used to be, I would like to configure 3 days a week at 12:30pm.

              With Ivanti, I can configure the start time at 1:00pm instead of 1:00pm, but this is not a huge problem (although my Company's lunch break is at 12:30pm).

              My willing is to be allowed to configure specific days, Mon-Thu-Fri (like before) for all my users...but as I am understanding, I can not !


              I just wonder why Ivanti does not allow IT administrators to configure specific days (like in the Patch and Software distribution) for inventory too.


              However, going back to your consideration, to be sure I understood well I would like to share with you the following example:


              Inventory task:

              Task must run between 1:00pm and 2:00pm

              every 2days

              From Monday to Friday


              Monday: PC runs the inventory and it works for more than 1 hour and finishes at 2:15pm

              Wedsnesday: it runs the inventory at 1:00pm too and, this time, it finishes at 1:45pm


              Friday: it runs at 1:pm again.

              Am I right ?


              If yes, it should always run the inventory on the same days. Or not ? And why it considers Saturday and Sunday when I configured "from Monday to Friday" ?


              2) Most important, machines "affected" by this issue (I mean...inventory takes too long...) have the disk usage up to 100% for more than 1 (sometimes) 2 hours...and for me...this is not normal.

              and we never faced an issue like this with the old software...and on the same PCs !!...and, to be clear, we never configured folders exclusions too...) !!


              So, I do not understand what Ivanti intends for Delta inventory; I have clear that, once the agent is installed, the first time it runs a full HW/SW inventory and it should take long time...and in that case it is OK...but then ?

              When it really runs a delta inventory ? What does really mean delta for you ?


              Followin my colleagues's complaints...for me...it is always a FULL inventory.


              Phoffmann...any further clarification is really appreciated :-)



              • 4. Re: How does the inventory really work  ?
                Marco_F Apprentice

                ...I also forgot to ask you where can I check the CPU utilisation in the agent behaviour.

                • 5. Re: How does the inventory really work  ?
                  phoffmann SupportEmployee

                  OK - if you have 100% disk utilisation for 1-2 hours, THAT is definitely not normal.


                  First "suspect" I would look at is your AV. Depending on who you have, do you have something called "Process Level Scanning" enabled (the exact name varies by AV vendor). Sophos calls it "On-access" scanning for instance. If your AV has that sort of feature, you may want to add exceptions for the following two binaries to it:

                  • ldiscn32.exe (our inventory scanner).
                  • vulscan.exe (our vulnerability scanner).


                  Process Level scanning works like this:

                  Instead of "just scanning the .EXE that tries to run", Process level scanning scas "the .exe that tries to run and EVERYTHING that exe tries to touch", So for an inventory scan, that's equivalent to a full disk scan (more or less).


                  ... and since our inventory scanner trawls most of the hard drive for sofware information, we would get the AV to scan for most/all of the hard drive for one. So that's probably the single most common problem in that regard.


                  That would be my number 1 suspect (and USUALLY am proven right). If that's not it, then that's definitely something we need to look at.




                  In regards to CPU usage, that one is my bad. I was incorrectly referring to a feature of the patch module (inventory automatically tries to "go softer" with the GUI disabled).




                  In regards to Local Scheduler -- you can see a nice GUI-based approach to defining those tasks in MANAGE SCRIPTS --> NEW LOCAL SCHEDULER SCRIPT. You can equally have the entire power of it visible via this -- Localsch.exe command line parameters .




                  In regards to versions, one thing for you to be aware of / an FYI is the following.


                  Version xxxx.1 is the "new hotness" first new feature release in the year. I.e. - the first release of EPM 2018 will be 2018.1. The ".1" release is primarily meant for early adopters / people who are "dying" for "new feature X". This .1 release will only be expected to get about 2-3 service updates, and "that's it" ... people would need to upgrade to the xxxx.3 release.


                  The ".3" release is the "long term sustaining" release. It too will likely have a FEW functional improvements (but likely fewer than its .1 release), but thats the release that'll keep getting supported for a few years.


                  This isn't mean to send you into a panic of any sort. Just a simple "hey - FYI". In case you ever get a "hey, we want to give you the latest patch" type response / thing, you'd need to update to 2017.3 first.


                  For "completeness" sake, if I recall correctly, the "latest (and last) update" for 2017.1 was ... SU2 actually (which came out about August 2017). Anything after that was 2017.3 + onward.


                  <Not suggesting that there was a "LDISCN32 munches 100% disk" type bug in there -- that binary has overall seen not too much performance based change in the past. So it's usually down to "other" things like AV going crazy over us scanning most of the HDD>.




                  Re: Scheduler "time creep" -- your interpretation of how it works, is incorrect. I walk through how the scheduler logic works at this sub-topic here -- https://community.ivanti.com/docs/DOC-27635#jive_content_id_III__Task_reruns_and_the_time_creep .


                  Essentially, imagine the following:


                  Day 1 - you start at 13:00 and finish at 14:15.


                  Day 3 (because you have a 48 hour delay), we will check at 14:15 onward, whether we can run (we check on filters. I.e "is it the right day / time for me to run). If not, we'll "wait" (checking every 20 seconds), until all the filter configured conditions are OK.


                  Now, because you're "time of day" filter is set to run between 13:00 - 14:00, and our previous "end" time was 14:15, we'd need to wait until day 4 at 13:00 to be able to run again.


                  The way to fix this to run "every other day" is essentially the following:

                  • DAY filter of:"Monday - Friday" (you want to run during the workign week).
                  • HOUR filter of "13:00 - 14:00" (you wanted that specific window)
                  • Recurring FREQUENCY of 30 hours (more than 24 hrs, so we'd be "guaranteed" to be over 1 day, and run into a time-window that's outside of the 13:00-14:00 range).
                    Effectively, Local Scheduler would "check" to run from 20:15 "the next day" for filters ... but since 20:15 is "not between 13:00 - 14:00" it would wait for that condition to be OK.


                  ... does that make sense? Just a little matter of getting used to how to think in that particular logic.




                  So - let's start with disabling the AV / adding an exception, and checking whether that helps the 100% disk usage.


                  Yes, the inventory scanner will scan software stuff, but there's no real way that it would/should hammer the HDD to the tune of 100% for 1+ hrs.

                  1 of 1 people found this helpful
                  • 6. Re: How does the inventory really work  ?
                    Marco_F Apprentice

                    Well,  I got a lot of useful information and I am going to reply to some of them


                    1) When we configured the Ivanti Core, first thing we do was to exclude all files listed at the following link in the McAfee ePO:


                    Antivirus Exclusions for an Ivanti EPM Client


                    plus these:




                    so it should be OK and the "mcshield" process should not be the problem!!!


                    For this issue, we opened a SR too with the Support and, as a troubleshouting, they suggested to us to do this:




                    Now, the main issue related to the above link seems to be mitigated but some PCs still run their inventories for too much and with a unaccepttable disk usage %.


                    We also asked for what feature we are going to loss disabling this field but, for now, we do not get any really useful answer.


                    So, in your view, do some PCs take more than the usual time because of there should be plenty of files to be scan ? I mean...in some cases, more than 1.000.000 files...although they are not the only one with a so huge number of files

                    2) Thank you for advising me about the right meaning of the versions...I think it is a very useful information and I will keep in my mind


                    3) I like your tip...I have just configured a new agent inventory and deploied it on all my IT colleague's PC so I will check its behaviour over the next weeks and, if it works, I will deploy it on all our PCs.

                    • 7. Re: How does the inventory really work  ?
                      phoffmann SupportEmployee

                      Having the "/debug" thing enabled should give a lot of details on "what's going on" during the slowdown. It should remove a lot of the guesswork out of this.


                      While we *CAN* be configured to "literally" scan for every executable on the Core (knowns as "Mode=All" scanning), that's not normally what happens.


                      What we pick up normally is:

                      • Stuff that's installed (so registered with one of a few Windows Repo's such as "Add/Remove..." or a program group), as well as anything that's a shortcut.
                      • Stuff that's been executed (so "Putty.exe" doesn't need to be installed, and was run from "C:\Zz\MySneakyDir\" for instance).
                      • Another "overhead" on inventory scanning is if you send file-hashes (that's something that's disabled by default), which is an advanced setting for the inventory on the Core.


                      That's about it that comes to mind ... there *ARE* ways with which you can configure yourself "into trouble" as it were, but other than the WMI-rules stuff, those options don't tend to be enabled by default (and need awareness that they exist & usually come with a warning note).


                      The debug-log should give us an idea what's going on while "things are slow", and from that we should be able to figure out what's what. Certainly not standard/desired behaviour.

                      • 8. Re: How does the inventory really work  ?
                        phoffmann SupportEmployee

                        As an addendum (as I'm a paranoid / distrusting sort) ... do try to disable the AV "for a laugh" on one of those devices.


                        I have this sneaking suspicion (/memory) that even though we have configured an explicit(!) exception in an AV for a process, that the equivalent of Process Level Scanning still happened (for some reason). Can't remember which AV that was with (or how long ago, but "the suspicion" tends to stick as a result of the bad memory) ...


                        I tend to operate on a "Trust ... but make sure..." basis (usually with good reason).


                        Another potential interesting tool to have a peek at would be SysInternals Process Monitor ... it can give some insights into what's going actually on and why (but let's start with the "simpler" approach of first looking at the debug log for instance).

                        • 9. Re: How does the inventory really work  ?

                          For what it's worth, below is some information of Delta scans. It seems like you think delta scans are less resource intensive on the client, which isn't the case.


                          Delta scanning is meant to decrease network load and load on your core server by only sending a diff, or delta, of the current inventory scan and the last inventory scan. It does this by storing the results of a scan in a file called invdelta.dat under LDClient\Data.


                          The next time a scan runs, it runs a full scan as normal, and then it compares the current scan file to the previous scan stored in invdelta.dat. It then only sends any data that is different between the 2 (as well as entries telling the inventory server what to remove, if something has been removed), and some basic data that is always sent such as NIC Address, IP Address, Device ID, etc. But it still needs to get the full scan on the client to have something to compare to the previous scan.


                          On the topic of disk usage, aside from what phoffmann already said with the debug log, I would also check out the GatherProducts.exe process as it can run into issues that cause high disk usage. More info on that process is here: About GatherProducts.Exe

                          1 of 1 people found this helpful
                          • 10. Re: How does the inventory really work  ?
                            Marco_F Apprentice

                            Thank you !

                            Now I understood better about the Delta inventory.

                            Regarding the GatherProducts, as far as I know, if I will disable it, I should not able to collect software meetering in the data analytic.

                            • 11. Re: How does the inventory really work  ?

                              GatherProducts corresponds to what you would see show up as "Automatically Discovered products" in SLM, and the Software.Product entry in inventory. DA doesn't use that, it instead uses data under Software.Package to create entries under Software.Licensed Software. So you would still need software metering data if you use DA.


                              That said, I wouldn't necessarily recommend disabling it anyways. Just checking disk usage for that process when you run a full inventory scan, and checking the GatherProducts.log to see if it's butting its head against something, as that log tends to be quite verbose and tell you exactly what it's doing or failing to do.


                              One of the biggest causes of high resource usage on that exe is when it wants to check something and it's not allowed to. I believe it retries another 9 times per file/process before giving up. As you can imagine, doing that several thousand times per second could definitely cause some higher CPU usage. And that exe exists solely to scan the disk for products to try to generate product definitions, so it's inherently disk bound.


                              The inventory scanner has a lot of "subscanners", like WMIRulesScan.exe, HPScanner.exe, etc. So often it can be hard to narrow down resource usage issues when you just look at ldiscn32.exe itself, since at any given point in the scan it may not actually be doing anything, instead letting a purpose built subscanner get data. It helps to watch those other processes and see if something stands out.

                              • 12. Re: How does the inventory really work  ?
                                Marco_F Apprentice

                                OK, I will do a test with the AV disabled although, while the inventory was running, I did not noticed any AV process running.


                                I will check the new inventory scheduled task on the Pilot group and I will confirm to you if it works as well as I would like (...and I think you gave me a very useful suggestion)


                                One more question: I ran an inventory with all the switches suggested but can you please help to to understand well what kind of useful information I could read into this log ?


                                Thank you in advance.

                                • 13. Re: How does the inventory really work  ?
                                  phoffmann SupportEmployee

                                  That depends on what you're looking for.


                                  For one, you're initially looking for "what part of inventory" takes so long ... that may then help understanding WHY.


                                  Say -- scanning the network info takes "a long time" (it'd be a first, but stranger things have happened) ... it'll narrow things down.


                                  Similar if it's either "the entire software scan" or "just scanning for MS Office components" ... essentially, you're using the time-stamps of debug-mode as a way to identify where / when you run into problems ... especially if you compare it against a "healthy" device, so you can find out where behaviour starts being aberrant.


                                  It's not likely to have a an immedaite "I-WIN" type button that'll lead you straight to the source of the problem. But there's a very strong chance of it providing you (/us) with a few initial breadcrumbs to points us in the right area / direction.


                                  Does that make sense?


                                  It's not a "non plus ultra" troubleshooting tool - but if you've got "odd behaviour", it's a big help in trying to figure out "which part" is causing you grief, as it were .

                                  • 14. Re: How does the inventory really work  ?
                                    Marco_F Apprentice

                                    I understood.

                                    I think the main problem is that some PCs have more than 1.000.000 files to scan and that's why it takes all this time.

                                    Next time someone will complaints about this issue, I will run the inventory in debug mode...hopefully to find out this issue.

                                    I will keep informed you

                                    1 2 Previous Next