10 Replies Latest reply on Feb 23, 2017 9:45 AM by phoffmann

    Searching for Office Files

    RobLent Specialist

      I have amended my ldappl3.template file with .doc and .xls extensions but the Inventory scanner does not seem to be pulling these back.


      (I fully understand that this could be a big database size boost but I have been asked to do this.)


      Any reason why these files are not being pulled back?


      I have left it for a couple of days and still nothing and I know that there are files of this type on the PC as I have made sure of that.

        • 1. Re: Searching for Office Files
          phoffmann SupportEmployee

          2 questions here, to clarify a few things:


          - What version are you on? (that's just so we're comparing apples to apples - not going to be a profound difference)

          - What exactly are you trying to do?


          Depending on your version of LANDesk, you may not need to use the LDAPPL3.TEMPLATE at all, but do this stuff through the GUI.


          Assuming you're on LANDesk Management Suite 9.6 or newer (I've not looked at 9.5 in a while), you actually configure this stuff in the GUI. Go to TOOLS >> REPORTING/MONITORING >> MANAGE SOFTWARE LIST:



          In the new tool, in the SETTINGS tab, you'll find all the stuff that used to be configurable via the file to now live in the database. You configure your settings here:



          Notice the computer-logo that I've put in a box too (2nd icon from the right). That'll actually write out the changes once you're done editing. To confirm, check out the LDAPPL3.INI file which should look something like this now:



          ... after that, your clients just need to send a full software inventory, and your data can be found in the inventory tree like this:



          ... hope that clarifies everything ?

          • 2. Re: Searching for Office Files
            RobLent Specialist

            Many thanks for the reply.


            I am currently on 9.5 SP3.  (We are almost ready to go to 2016 but am still testing the upgrade in our LAB.)


            I have done all the above and checked in the ldappl3.ini file on the client that the listed extensions are there and they are.  I have also made sure there is no path exceptions.


            To explain I have been asked to find some software that can scan PC's at our remote sites for office files as our security team want to see if anyone is saving files they should not be locally.


            Instead of buying new software I thought we could use LDMS as it is already deployed.


            But I don't seem to be getting the results I need.


            Any other thoughts?

            • 3. Re: Searching for Office Files
              phoffmann SupportEmployee

              OK - so on 9.5, you DO need to edit the LDAPPL3.TEMPLATE - we integrated the last of that stuff into the DB / UI only post 9.5. So you're correct there .


              I've dug up an old 9.5 SP3 Core I had gathering dust & checked it out - the steps are essentially the same. The one thing you may potentially have fallen afoul of is not forcing a software scan (this sort of custom data counts as part of the software scan) and by default we only scan for software 1x per day so as to reduce scan sizes.


              ... aha!


              So - it appears that I have good news & have bad news for you.

              • The good news is that you've done everything right from a configuration point of view.
              • The bad news is that it looks like that's a bug in that version of 9.5 - I've tried SP3 vanilla as well as the last post SP3 component patch around inventory (2016-0211 BASE) and both seem to "simply not pick up the file extensions I've configured".


              ... problem being that 9.5 is now EOL (End Of Life) and as such, we can't really log a defect against it ... as per my screenshots, 2016 works fine, and I'll quickly test against 9.6


              ... 9.6 with the 2016-0512/0518 component patch set works just fine / as expected too .


              So ... how to help you with being on an EOL version with that functionality bugging out? Hummm ...


              You COULD go an alternate route - via custom data. If you're going to be stuck on 9.5 for a while yet, that may be the best way forward in that situation. Depends if you're happy collecting the data via a script for instance. You'd then need to stick that data into a specific format - would you have the technical know-how/resource to do that, in general?


              Or ... if you're going to up-lift your version in the near future (depends on when you're expecting to have finished your validation testing).


              Important caveat for you to be aware of - do be aware that the inventory scanner will only scan local drivers - not network drives. So if you have some folks saving to someplace on - \\MyHiddenServer\MyHiddenShare\Mystufff\ - then you may not be able to find it this way.


              To help deal with that side of things (if you want to be "super thorough") you could always make sure that you collect the "recently opened" list of files that you care about from the registry (IIRC) as well (which would be custom data as well) potentially? Depends on how you want to skin that particular cat, as it were.


              So - couple of options for you. Sorry that you've stumbled over something that doesn't work in your release, but with that version having been EOL'ed for over 1/2 a year already, there's not much I can do .

              • 4. Re: Searching for Office Files
                RobLent Specialist

                Wow... and thank you for taking the time and effort in answering this for me.


                I thought I had done things correctly but was unsure.


                We do have the ability to script this if necessary but I will push to get the 2016 version in place as soon as possible if I can.


                Thank you again for all the research you have done and the splendid answer.

                • 5. Re: Searching for Office Files
                  RobLent Specialist

                  So I know this is an old thread but as we are no on 2016.3 I thought I would give this a go again.


                  But it does not seem to work for me again for some reason.


                  Done all of the above and I can see that the fie on the clients contains the .doc extension etc but nothing is coming back in the inventory scanner.


                  I have forced a Full Scan on a few clients and still nothing in the Inventory for the extensions I have defined.


                  Any thoughts why this would be in 2016.3?

                  • 6. Re: Searching for Office Files
                    phoffmann SupportEmployee

                    Not a problem at all, RobLent - let's see if we can get that sucker sorted out for you .


                    Works fine for me on 2016.3


                    Just to confirm.

                    • You've added the following (or something like it) in the "Manage Software List" tool to the "DataFileExtensions" section to cover your .DOC / .DOCX files?



                    • You've then clicked the "Make Available To Clients" button to write out the change (double check your LDAPPL3.INI on your Core to confirm). We write out the file once per day anyway, the "Make Available" thing just writes the chances out "right now" into the LDAPPL3 file(s).


                    - and -



                    • You then run the 'correct' inventory scan on the client. By "correct" I mean "you force a software scan" (via the "/F" parameter). For some (historical) reason, the custom data collection triggers / falls under the "software scan enabled" section - which by default will only happen 1x per day, unless you specify it via cmd-line parameter .



                    "/V" is just a switch to enable verbose scanning (GUI enabled), habit of mine.

                    "/SYNC" forces the client to send all of the data, rather than just a delta, to the Core.


                    ... that should be all you need. Here's what I get back for instance



                    • Options to help you figure stuff out if you're still not getting things:
                      • Make sure / check the client-side local LDAPPL3 file(s) to make sure that the "DataFileExtensions" changes/updates made it client-side (I'd be astonished if they didn't, but worth a look).
                      • As long as you force the inventory scan with the "/F" you should be golden now.


                    ... the only thing that'd come to mind as to why we wouldn't pick things up would be stuff around permissions (i.e. - the user context launching the inventory scanner doesn't have access to the relevant directory/directories).


                    That'd be stuff you should be able to capture in a PROCMON trace as well (Process Monitor is an awesome "WTF is going on?" type debugging tool for weird shenanigans to see if you have permissions issues in place for instance)


                    That SHOULD be enough to get you going ... there's not really a lot to go wrong, shy of ... (in summary)

                    • You forgot to commit the changes right away ("Make Available To Clients") -- but that's self-fixing, as we write out a fresh LDAPPL3 every day anyway.
                    • If the LDAPPL3 on the Core has been write-protected, you're in a spot of bother (yes, I've come across this -- no, no-one could ever explain to me how / why that was done) .
                    • If the LDAPPL3 update doesn't make it to the client you're not going to get the data (weirder networking issues have happened).
                    • Finally - file/directory permission issues may hobble you (Process Monitor should be able to highlight / confirm any access problems).
                    • "Mystery interfering app X" (often the AV?) may throw a spanner in the works because "reasons".


                    ... that's pretty much everything I can think of that could go awry. The thing works quite happily in principle.


                    If you have a "clean" lab-core, confirm the basic steps above (just to sanity check for yourself). And then work from there. There's not much to interfere / go wrong ... the above, is pretty much all I could think of.


                    Hope that helps.

                    • 7. Re: Searching for Office Files
                      RobLent Specialist

                      Thanks phoffmann,


                      Very detailed as usual. 


                      I have done all you mentioned and still getting no results as such.


                      Checked the local LDAPPL3 file on the clients and they have the updated settings in them.


                      On my test PC I ran the scan with the /f and /sync switches.


                      Let it run and checked the inventory but no results under the software section.


                      I have even deliberately created some folders and put some docs in them on the local PC to ensure there was something there to be found!


                      Interestingly I have also tested this on my laptop.  Now the local LDAPPL3 file has all the new extensions in there but this is only picking up PST files.  This also seems to be working correctly as two days ago I had to create a new PST file for a test and this has been picked up in the normal daily scan so I can see that this does work!!


                      It just does not seem to be working across the board!  All the agents are based o the same one just that laptops have slightly different agent settings for patch etc. than desktops.


                      Think I am going a bit mad here as from what I can see and from your post above everything is as it should be.

                      • 8. Re: Searching for Office Files
                        phoffmann SupportEmployee

                        Huh - OK ... not entirely sure why the scanner is not picking it up.


                        So - just to check ...

                        ... if you've enabled "Store scans" on the core, have a look at the inventory scan itself, to see if the problem is scanner side (it doesn't pick 'em up) or DB-side (for whatever reason, that data in the scans isn't making it into the DB).


                        Note that this data does *NOT* count as unmodelled / custom data normally - so it shouldn't show up under the "Unknown Items" as per here:

                        - Issue: Custom Data is not Entered - Using the Unknown Items Inventory Tool

                        - How to mass manage Blocked Inventory Items / Blocked Unknown Items


                        Now - 2 possibilities I see.


                        1 - the data isn't going in on the client side (which would likely need to be looked at with support). That we can check out / verify at least pretty easily.


                        Run the following command line on the client:

                        C:\Program Files (x86)\LANDesk\LDClient> ldiscn32.exe /V /L- /O=C:\temp\ScanOutput.txt /F /sync


                        <You can change the path / file-name for the output scan file - it's just a plain text file. Search the file for the data just to confirm whether it's in there or not.>


                        Here's a good search string to help you get to the right location:

                        Software - Data Files -


                        2 - The data *does* make it into the inventory scan, but there are issues with your database (most likely fixable) -- which again would be a ticket with support at this point.


                        It'd help (for reference) having an inventory scan of yours to look at this "just in case" for support anyway (so the output scan is going to be useful), and we'd probably need to have a full DB backup (usually necessary to see why DB's are acting up if they are).


                        ... so - at this point, I suspect "either way" it'll end up as a support ticket. Might (hopefully) be some kind of "duh" moment somewhere if someone else can get remote eyes on your Core, could be a genuine defect due to some bits on your desktop not "playing nice" or blocking us for whatever reason (stranger things have happened) or it could be a DB problem.


                        Either way, I think at this point, you'll need to poke support. On the plus side, at least you're now at a point where we CAN support / sustain you ,


                        <You can probably also point the support folks at this thread, so you can save yourself a lot of the "this is what I'm trying to do" explanation>.


                        We'll get it figured out.

                        • 9. Re: Searching for Office Files
                          RobLent Specialist

                          Ah ha... 


                          So it seems the client is not getting the detail locally.


                          Nothing in the output file for the Software - Data Files bit.


                          Time for that support call then.


                          Thanks for all your input phoffmann

                          • 10. Re: Searching for Office Files
                            phoffmann SupportEmployee

                            OK - interesting.


                            Does the client-local LDAPPL3.INI file have the relevant update bits? Could be that (for whatever reason) the client is not pulling down.


                            The LDAPPL3.INI should be here:

                            C:\Program Files (x86)\LANDesk\LDClient\Data\LDAPPL3.INI


                            There will be other LDAPPL3 files, but the INI is the one that matters.


                            If the client has got the updated content in the LDAPPL3, it's "something" that's indeed messing up the gathering.


                            If the client-local LDAPPL3 does NOT have the entry, then the client is behaving "as expected" based on not knowing to scan for those things.


                            In that case, we can try to "hard wire" it to talk to your Core with a few experiments. See if that helps (again, ONLY if the LDAPPL3 on the client doesn't get updated):


                            LDISCN32.EXE /V /F /SYNC /NTT={YOUR_CORE_BY_IP}:5007 /I=HTTP://{YOUR_CORE_BY_IP}/LDLOGON/LDAPPL3.LDZ


                            Most of these things are in agent-settings, but you can override them with command line parameters.


                            You can weird situation sometimes where DNS is "a tad flakey" at time, and in that situation, I tend to prefer hard-wiring the Core comms based on IP to see if that helps - for debugging purposes.


                            If the above helps, go and edit your "Client Connectivity" Agent Setting and make sure to use IP-addresses for your Core (as DNS can and does eff things up when it goes bad / questionable).


                            In other cases, you have some weird things like web-caching appliances screw you over - "aha - you're trying to access the HTTP-share on your Core. I have that cached with a file from 5 months ago. Here is is!"-type stuff. It's why I'm notoriously suspicious of anyone using www-caching appliances for ANYTHING related to the Core / SoftDist (it causes *so* many problems and doesn't solve anything).


                            See if that helps / is the case.


                            If it's just a case of "Yep - file is there ... client should know what to look for - but just doesn't" - then it is either down to permissions (Process Monitor for the win) for instance.


                            If you're not familiar with Process Monitor / Explorer, here's some awesome starting points (and this stuff is just from fellow LD folks):

                            - Using Process Monitor to capture system events

                            - Troubleshooting: Process Explorer tool to help monitor system and examination utility


                            After a bit of digging, there's also the following - very competently written by our own wcoffey :

                            - Understanding Process Monitor