What file extension does the configuration file have?
If it an unusual extension you could go into Reporting - Manage Software List - Settings and add the file extension to "DataFileExtensions" - with this you will get a section in the software part of the entry that shows all files of this extension.
If it is a standard extension then you need to go to the same place and add the extension to the ScanExtensions section. If it is in there ten it can be scanned. Once there you will probably find that what you added in "to be scannd" now works.
Don't forget to use the "Make available to clients" button to submit your changes. Client will need to perform a software scan for the information to be returned (they update their ldappl3 file at that point). You will find the discovered file in Software - Package in the inventory.
MarXtar Ltd/MarXtar Corporation
LANDESK One Development Partner
Try MarXtar State Management for LANDESK to Better Understand and Manage your Assets
I added .xml to the "ScanExtensions" section and made it available to clients. I then ran a full sync scan on a test machine. After that i was still unable to find the target XML, or any XML in the test computer's inventory. Am I missing something? Is there something else I can try?
Is it possibly being blocked? Go to Configure | Services and then the Inventory tab and click on the Unknown Items button.
I checked where indicated and I do not see any unknown items listed curretnly.
I just got back from a short vacation so I thought I would give this thread a bump to see if someone might have a solution for me. Thanks for taking the time to read this.
What's the location of the file? Is it in one of the excluded directories perhaps?
If you search through the To Be Scanned list, is it listed?
The exact file I am trying to scan for is located here:
C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\system\configuration.xml
It does not look like Program Data is in the excluded folders list.
Yes, if I put the file name in the "to be scanned" search box it does come up.
Okay, you might want to go and take a manual look at your ldappl3.ini file on your core. This is under whatever drive letter you have LANDesk management suite installed on, and then the usual folder structure will be "Program files\LANDesk\Managementsuite\ldlogon\". Unless its a 32 bit version of LDMS (i.e. 9.5 or earlier), then program files (x86), instead.
In the ldappl3.ini file there should be a line that begins with: "DataFileExtensions="
This is an example line from my lab 2016 core:
This is the same line from my lab 9.5 core:
DataFileExtensions=.pst .ost .sql
If your extension is here, then you SHOULD have inventory by now for any XML files throughout your inventory.
Create an LDMS query and look for the presence of any XML files to verify. The query should look like "Computer"."Software"."Data Files"."Path" LIKE ".XML"
I've explained the process in the following thread (with screenshots) - that should hopefully help you along a bit:
Hope that helps .
I would suggest creating a custom definition in Patch Management. You could create a "vulnerability" if the file exists (or doesn't exist depending on your preference). Then you can report on the vulnerability.
I'd remove .xml from ScanExtensions. It only needs to be under DataFileExtensions. It does not need to be in both.
SEEMS like you're doing the right things. Let's check things logically then...
1 - Check the LDAPPL3.INI on the Core - does it have the correct entries for the scan extensions?
=> The stuff you edit in the console gets written to the database. In some cases, people / applications write-protect the LDAPPL3 on the Core and thus such updates can never really take place.
2 - If the LDAPPL3.INI on the Core is fine, check the LDAPPL3.INI on the client (the one he's downloaded). That sits in LDCLIENT\DATA usually - so "C:\Program Files (x86)\LANDesk\LDClient\Data\".
3 - If the client has got the right file & thus knows what to do, create an output file like so, using LDISCN32 in the LDCLIENT directory:
ldiscn32.exe /v /f /sync /pd /sae /O=zz_out.txt
... and then have a look in the zz_out.txt file (all inventory scans are just text files) ... does the client pick up stuff (as it should)?
... let's go with this & approach this logically & see where it leads us. The stuff works in LD 2016 - I'm pretty sure I've tried this even with an unpatched 2016 install.
>I would suggest creating a custom definition in Patch Management. You could create a "vulnerability" if the file exists (or doesn't exist depending on your preference). Then you can report on the vulnerability.
I am doing this currently, but it is not an optimal solution. It's harder to manage than a quarry and it's not really a "vulnerability" anyway. I don't want it showing up in our vulnerability counts.