Description

In the root of the inventory of a machine we have Last Scan information for different sections. Here are the different section you can find in inventory:

• Last Antivirus Updates Scan Date
• Last Blocked Application Scan Date
• Last Compliance Scan Date
• Last Custom Definition Scan Date
• Last Driver Updates Scan Date
• Last Hardware Scan Date
• Last Security Check Date
• Last Software Scan Date
• Last Software Updates Scan Date
• Last Spyware Scan Date
• Last Update Scan Date
• Last Updated by Inventory Server
• last Vulnerabiltiy Scan Date

Inventory Scan Related Items

Note:A software scan only happens once a day by default. A hardware scan, software scan or a mini scan will change the "Last Updated by Inventory Server" field; even if the scan is discarded into the errorscan folder. A software scan can be forced when using the /F /SYNC switches. By default right clicking on a device in the console and choosing inventory scan does not force a software scan.

• Last Hardware Scan Date: An inventory scan for hardware has run on the client machine.
• Last Software Scan Date: An inventory scan that includes software information has run on the client machine. By default this runs only once a day.
• Last Updated by Inventory Server: This field updates when a hardware scan, software scan or miniscan is recieved by the inventory server service. This field will update regardless; even if the scan is discarded into the errorscan folder.

Security Scan Related Items

Note: Using a Scan and repair setting that is scanning for a group will not update any of these dates. Even if items in the group are types that would result in the date being updated.

• Last Antivirus Updates Scan Date: In the "Scan and Repair Settings" Antivirus Updates is checked off and run on the client machine.

• Last Blocked Application Scan Date: In the "Scan and Repair Settings" Blocked Application is checked off and run on the client machine.

• Last Driver Updates Scan Date: In the "Scan and Repair Settings" Driver Updates is checked off and run on the client machine.

• Last Compliance Scan Date: A compliance setting is applied to the client machine and has run.

• Last Custom Definition Scan Date: In the "Scan and Repair Settings" Custom Definitions is checked off and run on the client machine.

• Last Security Check Date: In the "Scan and Repair Settings" Security Threats is checked off and run on the client machine.

• Last Software Updates Scan Date: In the "Scan and Repair Settings" Software Updates is checked off and run on the client machine.

• Last Spyware Scan Date: In the "Scan and Repair Settings" Spyware is checked off and run on the client machine.

• Last Update Scan Date: In the "Scan and Repair Settings" LANDesk Updates is checked off and run on the client machine.

• Last Vulnerability Scan Date: In the "Scan and Repair Settings" Vulnerabilities is checked off and run on the client machine

Issue

Errors is Event Viewr: "Inventory data for {D259CB4C-35D4-2347-A497-BDAA768D75ED} is out of sync. A full scan will be forced'?"

In order to understand why you are receiving this warning, it is necessary to explain a little bit of the Inventory Scanner and how it works.

Delta Scanning: The first inventory scan that runs on an agent sends a full scan to the core server. It also stores that scan locally on the machine in a file called INVDELTA.dat. (The INVDELTA.dat is found in the c:\Program Files\LANDesk\LDClient\Data folder). To save time and bandwidth, all scans after that first scan only sends in the differences of the previous scan to the core server. So whenever an inventory scan runs it will compare the scan against the INVDELTA.dat, and only the differences are sent up to the core server. This is known as the delta scan.

Delta Scanning Synchronization:

During the inventory scan, there is a process to make sure that the delta scan that is going to be sent to the core server is accurate. The Inventory scanner on the client checks with the Inventory Server Service on the core server to determine if the INVDelta.dat file is accurate. If it is then the database is updated with just the changes since the last inventory scan. If not, then the delta scan will not be used and the machine will be flagged to do a Full Inventory Scan the next time the inventory scan is run on that machine. Following are the steps of Scanning Synchronization:

1. The Inventory Scanner (ldiscn32.exe) sends the managed device's ID to the Inventory Server Service (ldinv32.exe)
2. The Inventory Server Service examines an entry in the database known as the 'SYNC list' to see if the managed device's ID is listed. (This information used to be in the core servers registry, but now is kept in the database). If it is listed, then a full scan will be conducted on the managed device the next time the inventory scanner is ran.
3. The inventory scanner extracts "Last Hardware Scan Date" from INVDELTA.dat and inserts it in the 'Last Sync Date Field' of the Delta scan.
4. The Inventory server service compares the 'Last Sync Date' from the Delta with the 'Last Hardware Scan Date' in the database.
5. If the two dates match then the machine and the core server agree on the when the last inventory was conducted and are said to be 'Synchronized'. The inventory for that machine will then be updated with the information from the delta scan.
6. If the two dates don't match, then the Delta Scan is sent to the ErrorScan folder on the core server, and the device ID for that machine is written into the database Sync List so that a full scan will be forced the next time that machine scans.

Description

Currently, no information about the event logs of the devices is reported in the inventory of the device. Running the simple script attached on the devices you can retrieve the overwrite policy of the system event logs and store them in the registry.

Then modifying the LDAPPL3.TEMPLATE on the core you can tell the Inventory Scanner to retrieve these values and add them as custom values to the Inventory.

The script can be easily re-adapted to retrieve other properties of the event log files.

It is possible to find more information about the event logs properties at this URL on the Microsoft site: http://www.microsoft.com/technet/scriptcenter/guide/sas_log_iwbi.mspx?mfr=true

How to use the script

1. Modify the LDAPPL3.TEMPLATE that is in \\<coreserver>\ldlogon and add in the [Registry Info] section these lines:
   

   ;Event Log parameters
   KEY=HKLM,Software\EventsLogs,Application Policy,Custom Data - OS - Event Logs - Application Log Policy
   KEY=HKLM,Software\EventsLogs,Application Size,Custom Data - OS - Event Logs - Application Log Size

   KEY=HKLM,Software\EventsLogs,Security Policy,Custom Data - OS - Event Logs - Security Log Policy
   KEY=HKLM,Software\EventsLogs,Security Size,Custom Data - OS - Event Logs - Security Log Size

   KEY=HKLM,Software\EventsLogs,System Policy,Custom Data - OS - Event Logs - System Log Policy
   KEY=HKLM,Software\EventsLogs,System Size,Custom Data - OS - Event Logs - System Log Size

2. Press the button "Make available to Clients" in the Software Licese Monitoring window.
3. Run periodically the script EventLogInfo.vbs on the devices
4. The event logs parameters will be available in the inventory under the Custom Data - OS - Event Logs node.

Click on the link below to download the script

Issue

Error Message:

The description for Event ID ( 0 ) in Source (LANDesk Inventory Server) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Invalid Pointer

Cause

An invalid pointer reference occurs when a pointer's value is referenced even though the pointer doesn't point to a valid block. This is caused by not enough resources for the SQL server.

Resolution

Upgrading the memory on the SQL server has been found to resolve this issue. Multiply the total devices the Core Server will be managing by 2 MB to get a better estimate. For example, 5,000 devices require 6-10GB of RAM. Note this RAM would be dedicated to the use of Ivanti EPM, a dedicated SQL server is a recommendation to prevent performance issues.

Optional

Create a windows scheduled task that would restart the inventory service each night at 1 am or once a week depending on your network.

Here is a basic guideline on how to clean up an LDMS database.  If you have questions about any part of this process, please contact support.

1) Run the script listed in this document: How to Clean The EPM Database using a SQL script   This could take quite a while to complete if you have not run this script before.

2) Run the following query:  (This will clean up the unknown items section)

Truncate table metablocked

3) Run this query to update entries that have a null device ID: (Null device IDs will cause the service to crash if we try to update the record)

Update Computer

Set DeviceID='Unassigned'

where DeviceID is null

4) Clean up metadata with DB Repair tool: How to download the Database Repair Utility (DBRepair.exe)

- It's crucial to watch for components that should be listed as attributes.

• In the first screenshot above you can see that there are quite a few attributes being listed that should be lists or things that normally would be a group:  Groups, Software, Storage cards, Bios, warranties, OS, Scheduled task, Fujitsu all need to be cleaned out.
• In second screenshot we can see that the software section was being listed in modeled data since we know that this is a normal category that is in the database by default,  we should be removing anything from unmodeled data that already has a category
• The second screenshot also shows what we should be looking for in database doctor,  we can clearly see that it is listing add or remove programs as an attribute when it is a category.
• In the third screenshot we can see quite a few categories that exist in the inventory record by default,  we would also want to clean these out 98% of the time,  First expand each category to make sure they do not contain a custom value you have created.  Example:  Bios, Environment, LDApgroups,  LDAP,  Software, Memory, Network, Network Adapters, Landesk Management, and Environment are all instances of Categories that are in the Database by default.

If you are working in the DBRepair tool.   Then most categories can be deleted except for custom data.   It is still important to keep in mind that some of these entries can also be custom data entries that were modeled wrong.

To double check these entries.   You can Go to Tools > reporting > Managed Software list and check the custom entries to see if they match some of the attributes that are showing up here.   You will also want to check model attributes for any entries that you might remember adding via a data analytics rule.

Description

     This Article describes how to build a query that will return device that have been Updated by Inventory within X. Where X can be specified within hours. In this example I will show examples for the last 24, 12 and 6 hours.

GetDate():

The Get-Date cmdlet gets a DateTime object that represents the current date or a date that you specify. It can format the date and time in several Windows and UNIX formats. You can use Get-Date to generate a date or time character string, and then send the string to other cmdlets or programs.

Query Builder:

Depending on your use case you can either choose a Greater Than ">" statement to show results within the desired length of time or "<" Less Than"  for results outside of the desired time frame.

Build Your Query:

1. In the Windows console right click on My Queries and click New Query.
2. In the Machine Components section scroll near the bottom and select the attribute labeled: Last Updated by Inventory Server
3. In the Relational Operators section select the Greater Than symbol >
4. In the Display Scanned Values section, we will determine our time range by using the variable GetDate() with a switch that turns the variable a time in the past. For Example GetDate()-1would indicate today's date and time minus one day.

• Last 30 days

  • GetDate()-30

• Last 36 Hours

  • GetDate()-1.5

• Last 24 hours

  • GetDate()-1

• Last 12 hours

  • GetDate()-0.5

Purpose

The attached document provides information on performing an inventory scan on a device without an agent installed on the device or self-electing agentless scanning enabled on the network.

Note: We recommend utilizing the agentless scanner if you are able. For steps to enable the Agentless Scanner within LDMS 2016.3.x please see the article below:

Steps To Enable The Agentless Scanner in LDMS 2016.3 and Beyond

Resolution

Note: This resolution assumes that the device that needs to run the scan has the ability to establish a connection with the core server.

1. Connect to the core server's \ldlogon share and run the following command from an administrator command prompt:

Ldiscn32.exe /NTT=%coresevername% /s=%coreservername% /f /i=%coreservername%\ldlogon\LdAppl3.ini /sync /V

No Core Access Resolution

Note: This resolution assumes that no network connectivity can be made to the core and therefore all scanning files will need to be relocated to the device in which needs to be scanned.

1. In order to scan a device in which has no access to the core server as well as no agent installed the following files will need to be copied the devices local hard drive. Below is the list of files required to get obtain a scan:
   AMTScanner.exe
   ClientRollingLog.dll
   ClientRollingLog.log4net
   elogapi.dll
   GatherProducts.exe
   GPMM.exe
   HPScanner.exe
   Lclxclnt.dll
   ldaccount.dll
   ldapinfo.dll
   ldappl3.ini
   ldapwhoami.exe
   ldavhlpr.dll
   LDISCN32.exe
   LDServerRoles.exe
   LDMBBApi.dll
   LDProfile.exe
   libhttp.dll
   loc32vc0.dll
   LocalPrtInfo.exe
   log4net.dll
   ltapi.dll
   processrunner.dll
   psapi.dll
   ServerScanner.exe
   ThinClientScanner.exe
   vulscan.dll
   WMIRulesScan.exe
   
   
2. In order to run the scan, open an administrator command prompt window and run the following command:

Ldiscn32.exe /l- /o=scan.txt /f /i=LdAppl3.ini /sync /noui

Additional Information

About Inventory Scanner Switches

How to run Inventory Scanner on devices with no LDMS agent (Performing an Agentless Scan)

Docx and PDF files outlining the process have been attached to this document for easy access.

Issue

When attempting to perform an Inventory scan or Patch and Compliancescan request from Windows Console the Status of requested actions returns the Results seen below. Although this indicates that CBA is malfunctioning you can see in the image below that the Agent Status icons will often report correctly.

CBA 8, no certificates were found on the core server

Cause

     Most commonly presented on Core servers recently upgraded with an inline methodology. The Core server is using an old certificate that does not exist on the client when requesting connections.

Resolution

1. Validate that the HTTPS bindings of the Default Web Siteare configured to use the LANDesk Secure Token Serveras seen in the image to the right:

2. Move all but the latest modified *.cer, *.crt, *.key and *.0 files from LANDesk\Shared Files\Keys  to a new folder called Backup Keys

   • Note: The remaining .0 file should match the certificate found on the client

3. Flush all temporary ASP.NET files like so:

   1. Stop IIS (IISRESET /Stop)

   2. Delete all files and folders from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

   3. Start IIS (IISRESET /Start)

4. Restart all LANDesk and Managed Planet services with the following command in an elevated PowerShell:

   • Stop-Service -DisplayName LANDesk*,Managed* -Verbose -Force;  Start-Service -DisplayName LANDesk*,Managed* -Verbose

          If issue reoccurs, please perform the following steps:

          1. Open IIS Manager

          2. Go to Application Pools > LDAppMain > Advanced Settings...

          3. Change Maximum Worker Processes value to 2

          4. Change Regular Time Interval (minutes) value to 240

          Please contact Ivanti support if the above steps do not solve an issue.

Introduction

In some rare circumstances, the situation arises that - despite several attempts at deleting it - certain data objects do not get removed from the LANDesk Console.

Usually, this is more common to devices, but can potentially apply to any kind of data (such as "Custom Definitions" or anything else). The basic approach and troubleshooting steps are the same, regardless of what item it is exactly, that refuses to be deleted.

Symptoms include/tend to be the following:

• After apparently deleting an object (a device, a vulnerability, etc.) and either refreshing the view (via "F5" or pressing the refresh button) / re-opening the console, the allegedly deleted object is again/still present

           

KEY FACT - please note that SQL Express does not come with SQL Profiler, which will most likely be needed here. The Data Profiler is part of the full SQL Server Suite, so the "free" version does not have it. However, if you have SQL Server installed in your network somewhere, you can use its SQL Profiler to connect to a SQL Express instance just fine.

WHEN does this happen? WHY does this happen?

This is USUALLY seen in situations where SQL Server sits on a VM (as this can cause various timing issues to show their ugly heads). There's no "hard" rule to the "when" - it's effectively a case of "when something goes wrong with your DBMS" (Database Management System).

As to the "Why" ... well - this is more of a question to be asked of Microsoft / Oracle. As relational databases, this sort of thing *SHOULDN'T* happen - and it tends to do so only rarely. After all, the whole point of relational databases *IS* that data is connected to one another. To put things into perspective - in an entire year, EMEA support would get maybe 1-2 calls (for the entirety of the European region) per year, if that. So it's not a very common problem.

Most commonly, this problem has been seen on DBMS-servers that were virtualized, where perhaps some disk I/O couldn't be guaranteed and/or caused some race condition.

All the same, this sort of thing DOES happen from time to time in real-world environments (both Oracle and SQL-based), and all of them tend to require essentially the same plan of attack -- find which rule/constraint caused the problem. Once you know that, you can locate the data easily, and delete it manually. After this, it's a case of "rinse & repeat". In MOST situations, there is just a single occurrence of such orphaned data, but it is possible to run into more (especially if databases have never been maintained, for instance).

From an "inner logic WHY" perspective, the explanation is very straightforward at least. Here goes:

• The LANDesk-console goes through what inventory data it's aware that the troublesome data-object has and creates its own "tree" structure as to what data needs to be deleted and in what order.
• This is a DYNAMIC process because different devices will have different levels of data.
• The console then goes and executes its built SQL-plan without committing the TRANSACT statement until the very end.
• Because there are some orphaned data (that isn't visible in the inventory tree) linked to the object being deleted, the DBMS will protest the deletion at the latest when we try to delete the root item itself (i.e.. "delete device X from COMPUTER-table").

• ... and because the DBMS stops/fails this delete statement, the ENTIRE transaction is rolled back and nothing is deleted (after all - this *IS* a relational database).
• ... which is why the apparently deleted object re-appears when you refresh the console view - it is in fact NOT deleted.

Preparations

There's nothing to stop you from running the SQL trace on a live server - from a technical point of view. However, from a "quality of life" and "minimizing disruption" basis, it's worth taking a full DB backup from the live system and restoring it into a lab system. The reasons for this are various:

• First of all - you now *HAVE* a full DB backup in case you "delete the wrong thing" or so by accident.

 

• You can merrily stop ALL services (32-bit console doesn't need any to start) or "nearly all services" (if the problem is relying on 1 service running). Either way, you will massively reduce the amount of clutter in your SQL trace. Even when "apparently idling", there's a continuous stream of pokes & prods from the Scheduler service (for instance) to check if it needs to do something / anything.

 

• You can "test" around in relative safety of not breaking a live server, thus developing all the necessary SQL (and being able to test & re-test) in a safe environment, until you have all of the SQL "prepped and ready" and can thus minimise any "downtime" (due to stopping of services) in live to a minimum.

    

Again, the idea is to stop ALL services, but the most important thing is to do this on a "quiet" server, so as not to drown in SQL statements. Yes, this stuff can be filtered, but why create yourself needless headaches & obstacles to be overcome?

IMPORTANT REMINDER:

Because you're going to perform some sort of DELETE-action, do make sure to have stopped the LANDesk Inventory Service BEFORE doing so. This is the ONE service that *MUST* be stopped when performing deletions in the database as a safeguard. The rest is usually fine (though best practice is always "stop everything" on a cautionary side - though this is not often realistic).

    

Identifying & Fixing The Problem

For this part, you *WILL* need some SQL expertise. Or "if not you yourself", then you need someone who does (i.e. - your friendly DBA, who I assume exists).

I will show/give examples for SQL Server below.

For Oracle databases, the process is effectively the same - but you'll need to talk to your Oracle DBA about performing the trace. That would blow the scope of this document considerably.

WARNING:

Please be *CAREFUL* when performing these operations. You're deleting things directly in the database ... PLEASE make sure you have a full backup. That way, *IF* something goes wrong, you are not left up a creek without a paddle.

 

This isn't a "High Risk"-operation per-se ... but if things *CAN* go wrong (such as databases breaking because you've never made a backup), this sort of stuff DOES tend to happen.

           

Step 1 - Identify Affected Devices/Items

This part should be relatively simple, as you should be aware of what you can delete and what "re-pops".

If you fancy a "tabula rasa" approach, you can even try to delete *ALL* items (i.e. - "devices") and then press "F5" or refresh, and see what comes back. Since you're doing this (I hope) on a lab/test-server with a backup of the live database, there should be no problems here (other than potentially time - deleting 20,000 devices from a DB will take a long time). So - be reasonable with what you're trying to do versus what you need to achieve.

Usually, it's just 1-2 items that have orphaned data ... not everything.

Step 2 - Preparing the SQL Trace

After it's finished loading, SQL Profiler doesn't show much of anything - you need to start a trace to get somewhere.

After selecting this option, the first thing you're greeted with is very similar to a SQL Enterprise Manager login - please provide credentials for the SQL Server you're intending to trace (note that this is the SQL *SERVER* - not "the individual database" at this point!). Once you've entered your credentials, hit the "CONNECT"-button.

After a successful login, you will be greeted with a screen like this one:

One of the first things you should do is to go to the "EVENTS SELECTION"-tab where you  should enable:

• Show All Events
• Show All Columns

          

Which is located in the lower right.

Enabling all these events/columns will give you - often necessary - additional options that are needed during troubleshooting.

Click on the COLUMN FILTERS-button - this allows you to filter "where" you're collecting data from in various regards - be it "by database", "by application" or even by CPU. In general, you're most likely interested in capturing "everything that goes to Database X" ... so you should select the DATABAENAME-section and enter the name of your intended DB to be traced in the LIKE-filter, like so:

When done, you can click on the "OK"-button to close that window.

Now - let's have a look at what we're looking at in regards to the other TRACE PROPERTIES ... specifically - what events we're going to trace. By default, you should see something like the following:

Here are the options you're generally interested in:

 

ERRORS AND WARNINGS

    => ErrorLog

    => EventLog

    => Execution Warnings

    => User Error Message

 

STORED PROCEDURES:

    => RPC: Completed

    => RPC: Starting

 

 

TSQL:

    => SQL: BatchCompleted

    => SQL: BatchStarting

           

You can right-click on the "SECURITY AUDIT"-section and use the "DESELECT EVENT CATEGORY"-option since we're not interested (usually) in tracking audit problems, but only SQL execution errors.

Realistically, the given settings are prone to a little overkill, but it's easier to filter through "too much logging" than to not log what you actually need.

NORMALLY, the exception you will be looking for is of the "USER ERROR MESSAGE" time, but it could be different, so I like to make sure / be on the paranoid side. To be honest - this isn't about "making an efficient SQL capture" - it's about capturing all the relevant SQL  and then filtering out the irrelevant chaff.

IMPORTANT REMINDER:

Make sure you've covered all the steps from SECTION III - PREPARATIONS - as having unnecessary services running at the time of the trace will pollute / clog your SQL trace CONSIDERABLY!

       

And you're ready to start the trace now ...

IV.C - Step 3 - SQL-trace an attempted deletion of the device(-s) in question.

This is a straightforward part. Just switch to the application (often - the 32-bit console) that is causing you grief, and perform whatever operation doesn't perform successfully.

And then stop the trace ... by pressing the "red stop"-button at the top.

That's really all there is to this part - the "heavy lifting" comes in evaluating the trace.

IV.D - Step 4 - Evaluating The SQL-trace.

It's not all bad news, however. As a general rule "normal" operations / successful operations are colored in *BLACK* - while exceptions & errors show up as a nice, distinctive *RED* amongst the text. You can also search for the keyword "Error" or "Failed", but depending on what you're dealing with (especially what data-strings you're dealing with) this can be a bit more of a pain.

Note that the "full line of SQL" (or full event description) of whatever line you've got highlighted is shown at the bottom. SQL Profiler does *NOT*  show you the results of a SQL statement - it shows you only "what was run / what went wrong" ... in order to play with the actual SQL, you need to have a means to query the DB open (usually - query analyzer in SQL Enterprise Manager).

A couple of otherwise useful data columns tend to be:

• CPU => # of CPU milliseconds used for an operation. If there are some operations that stand out, it might be worth looking at those for potential I/O or re-indexing needs.
• READS / WRITES =>  can be useful
• DURATION => helps you identify straight up what SQL statement(-s) are clogging your DBMS up. Usually, a great way to identify what tables/views cause you problems.

In case you need to deal with truly large SQL traces (I've had some be 1,000+ MB), you can make your life a lot easier by simply saving the SQL trace into a database table

This allows you to then run simple SELECT-type queries against a DB-table (all of the data columns you traced are saved). It's a great way of determining "top usage" in terms of CPU % and Read/Write performance, should it be needed.

Now then - back to our actual SQL trace - often the ERROR-message(-s) will be towards the end of the trace (since usually, that's where the process fails and thus gives up, after running into an exception). So - let's look at our example here:

In this case, for instance, our error text reads as follows:

The DELETE statement conflicted with the REFERENCE constraint "R_DataProtClient". The conflict occurred in database "{DATABASE-NAME}", table "dbo.DataProtClient", column 'Computer_Idn'.

           

I'm highlighting 3 separate items here:

* "constraint "R_DataProtClient""

=> This is the constraint that caused the conflict / failure of the DELETE statement/transaction. In LANDesk, pretty much EVERY foreign relationship constraint is named in this format:

""

R_{table-name}

""

 

* "table "dbo.DataProtClient", column 'Computer_Idn'."

=> In case this will make your life easier, here's an alternate pointer at what table you need to look at (and what primary key is giving you grief).

 

* "{DATABASE-NAME}"

=> This you should know, since this is the database you're tracing. But, if you're having to trace several DB's for some reason, this helps you narrow things down.

           

There will be a DELETE statement before this error - this will incorporate any unique identifier that's being referenced (usually a COMPUTER_IDN) so you know what value to look for in the problematic table.

The next step is to then go and delete it.

IV.E- Step 5 - Finding & Deleting The Orphaned Data.

In *THIS* particular example, we've got a few troublesome computers (COMPUTER_IDN's 646, 647 and 648) who have failed to be deleted due to a foreign key/relationship constraint into the DATAPROTCLIENT-table. After running a select on the table, we can see that - indeed - the clients DO have entries in that table. Why this data has been orphaned, we can't say (as it doesn't show up in inventory), but this is what's causing us problems.

So - let's delete it ... let's look at our table:

Since we have found the troublesome table, and we know the troublesome COMPUTER_IDN's it's a simple case of a 1-line SQL statement to rid us of the relevant orphaned data.

delete from DataProtClient where COMPUTER_IDN in (646, 647, 648)

    

would sort this bit of orphaned data out.

NOTE:

It is possible that when you attempt to delete these devices, this may fail - again - due to another constraint.

 

In such an event, you need to follow this table constraint as well, and repeat the steps here - until you come to the "end branch" of the data, and then delete your way through the various tables in the hierarchy established.

 

Multi-level dependencies are NOT common with orphaned data (most cases it's just the one level) - I'm just highlighting the possibility of it as a "just in case".

 

Now - with this done ... let's TRY AGAIN .

IV.F - Step 6 - Try Again / You Should Be Done

Normally, you will just have a single instance of orphaned data to contend with.

In some, rare cases, you may have several - in which will require you to repeat the whole SQL tracing process (so that you know where / why the delete action failed this time). If you have more than 2 instances of orphaned data, I would strongly recommend having a chat with your DBA team about checking the consistency/health of your database, as things should be getting rather suspect at this point.

So in most cases, you would need to just do the following:

• *Stop* the LANDesk Inventory Service on the (live) Core
• Run your SQL delete statement(-s)

 

• Re-start the LANDesk Inventory Service on the (live) Core
• Delete the items / devices you had problems deleting before.

    

The last 2 steps are interchangeable - but the first two are *NOT*.

V - Things To Look Out For:

If you've followed the advice & guidance presented here, there's really not much to look out for / things that can be gotten wrong.

The biggest thing really is to "muck around" on a copy of the live DB in a safe environment - that removes the greatest element of risk in the equation.

Other than this, the only real key element to remember is to STOP the LANDesk Inventory Service before deleting anything.

VI - Conclusion:

The article should cover everything that's required to identify the problem, set up a SQL trace to identify the source/location of any orphaned data, and help in deleting the relevant entries, as well as a process to do so safely.

Download

DISCLAIMER

USE OF THE DBRepair.EXE APPLICATION SOFTWARE IS SOLELY AT THE USER’S AND/OR COMPANY’S OWN RISK.  THIS SOFTWARE APPLICATION IS AVAILABLE “AS IS,” AND LANDESK SPECIFICALLY DISCLAIMS ALL WARRANTIES INCLUDING ANY IMPLIED WARRANTIES.

Download the appropriate attachment and extract dbrepair.exe to the ManagementSuite directory on the core server. The path to the ManagementSuite directory is by default C:\Program Files\LANDesk\ManagementSuite.

Instructions for Use

1. Stop the inventory server service on the core server before running DBRepair.
2. Verify that DBRepair.exeis in the ManagementSuite directory. Double click DBRepair.exe to run it.
   
   Note: Once DBRepair.exe opens, anything that appears in the tree is unmodeleddata. This includes either custom data that you have deliberately added (via a custom data form or by modifying ldappl3.ini) or data corruption.
   
   
3. Delete database corruption if ifis present as it can cause various issues.
   
   Note: If you have no custom data that you want to keep, then click on Computer at the top of the window and click the 'clean' button. If you have some custom data that you want to keep, click on the data you do  *NOT* want to keep, and click the 'clean' button.  You will need to remove (clean) each unwanted item individually.
   
   
4. Close DBrepair.exe.
5. Restart the Inventory Server service.

Example

If an item in the DBRepair.exe tree list appears to be a valid part of the inventory tree, it's not. Keep in mind that everything listed is unmodeleddata, so it can be safely removed. You only need to keep the items that you have added specifically as Custom Data.

DBRepair.exe that looks like this:

Computer

-Custom Data

-Motherboard

-Loftwa6re

Normally there is no such value as Loftwa6re. Clearly, the Loftwa6re item represents database corruption. However, even though Motherboard looks valid, by virtue of it being in this list, it is not valid and it should be removed.

One of the most powerful features of the LANDesk inventory scan is the ability to read data from custom-defined registry keys. This can provide for means on importing data into inventory that would not normally be gathered otherwise.

However, some of the more interesting data cannot be gathered directly by LANDesk. This problem arises for several reasons:

• Windows stores some information on a per-user basis under the HKEY_CURRENT_USER (HKCU) registry root
• Windows does not allow users to read each other's HKCU roots
• Our agent's scheduled inventory scans run as LocalSystem, so it does not have access to the per-user configuration in HKCU

This doesn't mean that this data is completely unavailable. Instead, a two-pronged approach is necessary:

• Create and deploy a script or batch file to write the data somewhere under HKEY_LOCAL_MACHINE (HKLM)
• Configure LANDesk to gather the HKLM registry key and add it to inventory

One of the easiest ways to automate registry manipulation is by use of VBScript (VBS). Windows provides a built-in VBS interpreter and LANDesk supports VBS software packages. This article can be used as an example of implementation; while it deals specifically with gathering a user's printers the concepts should be easily applied to other tasks.

WARNING! This script file reads and modifies machines' registries. It is completely unsupported by LANDesk, so please make sure you understand what it does before deploying.

1. Determine the source of the data you're looking for. In this example, we're going to read printer addresses from HKCU\Printers\Settings
2. Write a script to read data from the source in HKCU and write it to a location in HKLM. A good spot, used in this example, is HKLM\SOFTWARE\LANDesk\CustomData

' Constants (taken from WinReg.h)
Const HKEY_CURRENT_USER   = &H80000001
Const HKEY_LOCAL_MACHINE  = &H80000002

' Choose computer name
strComputer = "." ' Use . for current machine
Set StdOut = WScript.StdOut

' Connect to registry provider on target machine with current user
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")

' Define the registry key to read values from
strKeySource = "Printers\Settings"
strKeyDest = "SOFTWARE\LANDesk\CustomData"

' Create the destination key
oReg.CreateKey HKEY_LOCAL_MACHINE,strKeyDest

' Enum the subkeys of the key path we've chosen
oReg.EnumValues HKEY_CURRENT_USER, strKeySource, arrValueNames, arrValueTypes

For i = LBound(arrValueNames) To UBound(arrValueNames)

           oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyDest,"Printer" & i,arrValueNames(i)

Next

3. Create a distribution package in the LDMS console that deploys the script
   1. The package needs to be a 'Windows Script Host' package
   2. In the 'Accounts' section of the package properties, make sure to select 'Current user's account' to get access to the HKCU registry root
4. Deploy the new package to targeted devices
   • Target devices must have a user logged in, otherwise the task will fail
5. Configure the LANDesk agent to read the new registry keys
   • LANDesk Management Suite 9.0
   • LANDesk Management Suite 9.5
6. Manually run an inventory scan on the devices, or wait for the next scheduled inventory scan to complete
   • If the custom data fails to show up, ensure that it's not blocked

Although LANDesk can't directly read HKCU keys, there are a variety of ways to work around this. The above is just one example; other options include batch files or other scripting languages to get the data moved.

Troubleshooting Inventory

Inventory Installation

Inventory is installed as a result of the agent installation and includes and/or uses the following files:

Installation files

• LDIScn32.exe
• ldapwhoami.exe
• AMTScanner.exe
• ClientRollingLog.dll
• ClientRollingLog.log4net
• elogapi.dll
• GatherProducts.exe
• GPMM.exe
• HPScanner.exe
• Lclxclnt.dll
• ldaccount.dll
• ldapinfo.dll
• ldappl3.ini
• ldapwhoami.exe
• ldavhlpr.dll
• LDISCN32.exe
• LDServerRoles.exe
• LDMBBApi.dll
• LDProfile.exe
• libhttp.dll
• loc32vc0.dll
• LocalPrtInfo.exe
• log4net.dll
• ltapi.dll
• processrunner.dll
• psapi.dll
• ServerScanner.exe
• ThinClientScanner.exe
• vulscan.dll
• WMIRulesScan.exe

Possible Installation issues

If the following option is checked within the agent configuration when the agent is deployed, you could possibly see a delay in the installation completing and the first inventory scan being sent:

To start: How to use 10 simple checks to Troubleshoot Inventory - Devices not updating, Duplicated or Missing Scans

In order to effectively troubleshoot Inventory a general understanding of the Inventory workflow is necessary.

Inventory Service Settings

Settings for the inventory service can be found on the core server by opening the 'Ivanti Configure Services' (SvcCfg.exe) application from the Start Menu, from the \Program Files\LANDesk\ManagementSuite\ directory, or by navigating to Configure > Services > Inventory.

For additional information on these settings as well as the Advanced Settings please click here.

Inventory Client Settings

Client inventory settings can be found within the agent configuration or agent settings options within the 'Configuration' menu in EPM.

For additional information on the client settings please click here.

General Inventory workflow

Initiating an Inventory Scan

Inventory Scans are initiated on the client by calling LDISCN32.exe.

LDISCN32.EXE is located in the LDCLIENT directory on the client.

Typically if there is an issue related to the scanner you will be asked to gather a debug output file.

From the run line on client computer run the following command:
"C:\Program Files\LANDesk\LDClient\LDISCN32.EXE" /F /O=c:\ioutput.txt

This will create an output debug file with additional troubleshooting information.

Client Initiated

1. Inventory scan launched through the Local Scheduler on the client
   
2. Inventory Scanner is run from the Ivanti Management Program group on the core server using the following syntax:
   

   "C:\Program Files (x86)\LANDesk\LDClient\LDICN32.EXE" /V

• A Managed Script is Scheduled and run the client computer through Scheduled Tasks.  This is accessed by going to the Distribution tool group, and then the Manage Scripts tool.  Within that tool there is an "inventoryscanner" script that contains the following commands:

Core Initiated

1. Right-clicking a computer or computers and selecting Hardware Scan, Hardware and Software Scan, or Full Sync Scan
2. Using the Manage Scripts tool.  Go to the Distribution tool set and select "Manage Scripts".  Within there is an "inventoryscanner" script.  Right click this script and schedule it.

Scanning for additional data such as registry keys, additional file types, etc

Scanning for additional data and other additional Inventory settings can be found in the Manage Software tool.

For additional information:https://help.ivanti.com/docs/help/en_US/LDMS/10.0/Windows/inv-c-settings.htm?Highlight=manage software

Communication with the Core Server

1. Inventory Scanner connects to the Core Server to get Scan Instructions using the Syntax below
   
   GET /ScanInstructions/InventoryService/PING/{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} (Where xxx .. is the Computers Device ID)
   After the Inventory Scanner completes running it posts the information to the Core "PostingData" web service using the following syntax taken from the IIS log:
   
   

   POST /postingData/scan.upload prefix=ldscan\decomp&suffix=.SCN

data-mce-style="padding-left: 30px;" style="padding-left:30px"

• TMP = This is a temporary file used when a client communicates to the core server.
• SCN = This is a regular scan file waiting for the Inventory Server to process.

By default, the server has a limit in scan file size of 10000000 (or 10 meg) for scan files.  This number can be modified in Configure Services -> Inventory -> Advanced Settings -> Max Scan File Size. If the number exceeds the set amount, scans will be moved to the ERRORBIGSCAN folder If the scan files in the LDSCAN folder exceed this number you can change this number to a more suitable one.

Inventory Server Service

Inventory Server Service file location

"C:\Program Files\LANDesk\ManagementSuite\LDInv32.exe"

Inventory Server Service Log Files

The service log file is located here: C:\ProgramData\LANDesk\LDINV32.LOGThe Event Viewer is an excellent way to view activity for the Inventory Server Service.  Useful events will be listed in the Windows Logs - Application section.You can filter by Event Levels "Critical", "Warning", and "Error" and then filter the Sources to show "LANDesk Inventory Server" to show only events relating to the Inventory Server Service.

1. From the Event Viewer - Windows Logs - Application log, click on the "Filter Current log" in the right-hand pane.
2. Select "Critical", "Warning", and "Error" in the "Event Level" section.

There are three different types of messages to look for:

• Out of sync scans: By default, the Inventory Server will "flag" a machine as out of sync if it hasn't heard from the machine in more than 24 hours. This basically means that the next time the device sends in an inventory scan it will be a full scan. When experiencing problems and backups with inventory a large number of these log entries are normal as the inventory catches up over the next 1-2 days.
• Errors: There are many possible errors that the Inventory Server can log so without going into detail it would be best to search the community for the error in question. There is usually a document or discussion that explains the error in more detail and how to correct it.
• Blocked Inventory Items: The Inventory Server will flag unknown or unexpected information in a scan file and block the scan from being inserted into the database. That information is recorded on the core under Configure - Services - Inventory Server - Unknown Items. Most of these entries are normal and should be left as blocked as they may contain corrupt information that doesn't need to be in the database, however, when using Custom Data, for example, the information may need to be allowed.

Possible Issues

Issue: Unable to start LANDESK Inventory Server Service and settings missing from Configure Services

Issue: Core Will Not Process Inventory Scan Due To Large File Size

Error: "The Inventory Server Did Not respond" when running Inventory Scan

Error: Committing on Table...Increased column size might be necessary (Event ID 4100)

Reinstalling the service

At times it may be necessary to remove and re-install the LANDesk Inventory Server service.

"C:\Program files\LANDesk\ManagementSuite\LDInv32.exe" /Remove"

"C:\Program files\LANDesk\ManagementSuite\LDInv32.exe" /install"

Managed Planet Core Scan Processor Service

If the "Enable Real-time Processing" option is turned on in Data Analytics the Inventory Scanner service will ask the core for Scan Instructions and normal scan instructions plus additional instructions are sent with Data Analytics data.  This includes active rules that are set in Data Analytics.

The service watches the LDSCAN folder for the .MP or .MINIMP files.  The Managed Planet Core Scan Processor service must be running in order to process scan files as they come in.

When the "Enable Real-time" processing function is turned on in Data Analytics the Intermediate File Extension in Configure Services -> Inventory -> Advanced settings is set to ".MP' as depicted below.

If the Managed Planet Core Scan Process Service is not consuming the Data Analytics scan process and they are piling up in the MP_TEMP folder, check the account that the Managed Planet service runs with.  This account must have rights to access the LDSCAN folder.

Basic Troubleshooting Guide - Data Translation Services - Real-Time Processing

Enable Core Scan Debugging and Data Analytics Logging

Communication with the Core Server

The Communication process with the Web Service is the same as the regular process, but the files have a .MP or .MINIMP suffix and instead of the regular Inventory Server service processing the file the file is processed by the Management Planet Core Scan processor service and then modifies the scan file to ready it for LANDesk Inventory Server service and is moved to the regular LDSCAN folder.

Service file location

"C:\Program Files\LANDesk\ManagementSuite\MPCore.exe"

Log Files

C:\Program Files\LANDesk\ManagementSuite\log\MPCore.Exe.Log

Possible Issues

Issue: MP files are collecting in the LDSCAN folder

Thousands of .MP files are stacking up in the LDSCAN folder

The following rules should not be made active due to performance impact:

Web Import

B2B Connectors

Import Data

Calculate Data

Tasks

Inventory is run based upon the criteria inventory settings criteria within the agent configuration. You can view the scheduler tasks through the local scheduler on the device by following the documentation below:

How To: View Local Scheduler Tasks on a Client

When running a task from the core server you may encounter various Status messages as the scan progresses,

Directories

Registry Keys

Database Tables and Inventory Information

Quick SQL Script to find all of your Inventory Attributes in your LANDesk Database

How to determine the table size of a Microsoft SQL Server database

How to find out Database information for Inventory Items by the Object or Attribute name

Gathering logging information for Ivanti support

About Inventory Scanner Switches

How to generate an inventory output file from a client for LANDESK support to do further troubleshooting?

How To: Enable XTrace Diagnostic Logging for the LANDESK Core and Clients

Standard Log Files

Windows Application Event Viewer - Most LANDesk Inventory Server errors or exceptions are logged to the Application Log

Gatherproducts.log - \Program Files (x86)\LANDesk\LDClient\Data

ldiscn32.log - \ProgramData\LANDesk\Log

LDInv32.exe.log - \Program Files\LANDesk\ManagementSuite\log\

Trace Log Files

ldapwhoamixtrace logging - ldapwhoami.log - \ProgramData\LANDesk\Log

Note: This log file will only be created if xtrace in enabled.

Debug Logging

Debug Scanner log - ldiscn32.log - \Program Files (x86)\LANDesk\LDClient\Data
Inventory Server Service log - ldinv32.exexxxxx_xxxxx.log - \Program Files\LANDesk\ManagementSuite\log\LDInv32.exexxxxx_xxxxx.log

Note: This is the rolling log and must be manually enabled in Configure | Services | Inventory | Advanced Settings | Use Rolling Log = 1 on the core server.

Performance Issues

Performance issues are typically manifested by scans not processing or scan processing too slowly.  Further information on making sure this process goes smoothly can be found here in How to keep inventory up to date and flowing correctly.

Check the DoDelta setting through Configure Services

Ensure this setting is set to 1 unless otherwise specified, otherwise, every scan that comes in will be a full scan which can inhibit performance.

About Inventory Delta Scans

Active Rules configured incorrectly

What rules should be Scheduled and not included in the DTS Active group for Data Analytics?

Overall tuning for EPM and MSSQL

IIS Troubleshooting and LANDESK Management Suite: 101

Recommendations for tuning EPM (LDMS) and MS SQL for large enterprise Core Servers

How to troubleshoot IIS using Log Parser Studio from Microsoft

Purpose

Inventory can be perhaps called the backbone of LANDESK. Almost everything relies on inventory. Remote Control, Provisioning, Reporting, and the list goes on and on. In fact some provisioning tasks cannot be launched without the ability for a mini scan to reach the core server and be processed in a timely manner. Remote Control may fail if the IP address in inventory is not up to date and these are just some examples. If there is one thing a LANDESK Admin should understand and keep working it would be inventory. This guide was written to help understand the basic way that inventory works and how to troubleshoot common problems. This is not an in-depth guide on everything that can go wrong with inventory but more the basic information that every administrator should know.

Flow

Although this document is going to cover core and client-side inventory most of the flow happens on the core side. Inventory (like several other folders in LANDESK (alertqueue, brokerreq, sdstatus, vulscanresults)) are queue folders. That is...files arrive at the core and are distributed into these folders. Services on the core then watch these folders and process the files contained within. Since these are queues several problems can arise if the folders get backed up.  The C:\Program Files\LANDESK\ManagementSuite\LDScan folder is the queue folder that this document is focusing on and we will first cover file types found in the folder as well as the sub-folders.

Services that watch the LDScan Folder:

• Management Planet Core Scan Processor (LANDesk Data Analytics or LDDA)
• LANDesk Inventory Server

File Types:

• MINIMP = This is a mini scan waiting for the Core Scan Processor (LDDA) to process
• MINISCN = This is a mini scan waiting for the Inventory Server to process.
• MP = This is a regular scan file waiting for the Core Scan Process (LDDA) to process
• SCN = This is a regular scan file waiting for the Inventory Server to process.
• TMP = This is a temporary file used when a client communicates to the core server.

Sub-folders:

• ErrorBigScan = Inventory has a default scan file size limit of 10mb. Any scan larger than this will end up in this folder instead of the database. The size can be increased in the Configure - Services - Inventory Tab - Advanced Settings button, however, the larger the size the more time it will take for the Inventory Server to enter the file into the database.
• ErrorScan = If the inventory has a problem with the scan received it will end up in this folder and a message in the OS Application Event Log will be generated.
• Storage = This is an optional folder that may or may not show up. By default the inventory server will remove all scans unless the option is turned on to keep them.
• ErrorTrans = These are scans that had a problem while transmitted to the core.
• Decomp = Scans related to encryption/compression

Process:

1. Scans arrive at the core server. If LDDA is licensed and enabled on the core then the files will be MP or MINIMP, otherwise they will be MINISCN or SCN.
2. If LDDA is in use the Management Planet Core Scan Processor (LDDA) will pickup the files and run it's active rules on them.
3. Once LDDA is done (or if it's not enabled) the file type will be changed to MINISCN or SCN.
4. The Inventory Server picks up the files and enters them into the database.

Core Side Problems:

Since the LDScan folder is a queue folder it's important to tell if the queue is completely stopped or working slowly. The folder (like all queue folders) should be empty or be processing at a good speed at any given time. Troubleshooting steps will depend entirely on how the queue is working.

Techniques for watching the LDScan folder:

• Using the right-click properties window over and over and over. This will produce a high number of files (as it includes sub-folders) but after repeated attempts at this, you should be able to tell if the total number of files is going down consistently or never going down and going up instead.

• Clicking on a file in the LDScan folder. This option is available to newer OS's and will produce a total number at the bottom.

Complete Stoppage: The number of files in the LDScan folder is never going down or staying the same.

Troubleshooting possibilities:

• Restart the corresponding service. See the "File Types" section at the top of this document. As mentioned before there are two services that watch this folder to it depends on the file type as to which service gets restarted.
  • "LANDesk Inventory Server"
  • "Managed Planet Core Scan Processor"
• Check the event logs for errors
• Activate the core server using the "Core Server Activation" utility.

Slow Processing: The number of files is decreasing but at a slow rate.

• Just like the complete stoppage above look at the "File Types" section at the top of this article to see which service is at fault.
  • Managed Planet Core Scan Processor
    • Check for Web Rules that are running as Active. Active rules run for each inventory scan received. Some rules scrape the web and can be VERY costly in regards to CPU and memory. Some web rules are fine and are enabled by default (like Lenovo Warranty Info, IBM Warranty Info, HP\Compaq Warranty Info, and Gateway Warranty Info) however others like Apple rules etc should not be run actively. Right-click these rules and "Set Inactive" and then restart the Managed Planet Core Scan Processor service.
    • Make sure the Advanced Inventory settings for "Do Delta" are not turned off. Full scans will make the Core Scan Processor run all of its rules and slow the process down.
  • Inventory Server
    • The primary job of the Inventory Server is to process the scan files and insert them into the database. Therefore the service is generating SQL (primarily insert statements) and running them on the database server.
      • Test the connection between the core and the database server. There are in-depth documents on doing this but most of the time a simple ping test will suffice.
      • Analyze database performance. This may need to be done by a DBA and/or perhaps using a SQL Trace to analyze what tables are taking a long time to process. Generally, as long as proper database maintenance is being performed this usually isn't a problem. Otherwise, the database server may need to be upgraded.
      • Large scans files. The default maximum scan file size is 10mb. The default size can be changed to allow for larger scans to process. The bigger the scan the longer it will take the Inventory Server to insert them into the database.

OS Application Event Log: The Inventory Server specifically will log errors and warnings regarding scans and other problems in this log. It is important to understand the events and what they mean.

• Out of sync scans: By default, the Inventory Server will "flag" a machine as out of sync if it hasn't heard from the machine in more than 24 hours. This basically means that the next time the device sends in an inventory scan it will be a full scan. When experiencing problems and backups with inventory a large number of these log entries are normal as the inventory catches up over the next 1-2 days.
• Errors: There are many possible errors that the Inventory Server can log so without going into detail it would be best to search the community for the error in question. There is usually a document or discussion that explains the error in more detail and how to correct it.
• Blocked Inventory Items: The Inventory Server will flag unknown or unexpected information in a scan file and block the scan from being inserted into the database. That information is recorded on the core under Configure - Services - Inventory Server - Unknown Items. Most of these entries are normal and should be left as blocked as they may contain corrupt information that doesn't need to be in the database, however, when using Custom Data, for example, the information may need to be allowed.

Client Side Problems: Below are some ideas on different types of scans as well as the general process the Inventory Scanner goes through. Most of the time port blockage and name resolution are common issues but the following link can help as well. The link contains switches that can be passed to the Inventory Scanner and used in troubleshooting.

Inventory Scanner Switches

Type of scans:

• Full = Self-explanatory. A full hardware and software scan of the device.
• Delta = Changes. This scan will only contain the changes since the last full scan was performed. This is a default setting on the core server.
• Mini = A simple scan that contains basic information in order to communicate an IP address change on the device. These scans help keep the core server up to date on where the device is located on the network.

General Process:

The first thing the Inventory Scanner on a device does is attempts to contact the Inventory Server on port 5007. (this will also involve name resolution as well). Assuming that connection is made the device will check/update it's copy of the ldappl3 file. The ldappl3 is a central configuration file maintained by the core that defines what the Inventory Scanner should scan for. After the check for ldappl3 is done the scanner will scan the device and communicate the scan up to the core server.

Generating and output scan and carrying it to the Core Server: Below are methods of generating an output scan on a device. To test communication and other issues with inventory it's helpful to manually move these scans to the core server and drop them into the LDScan folder. This can be done repeated times for troubleshooting as well.

• Macintosh
  • Output scan for Macintosh Machines
• Windows
  • How to generate an output scan

Problem

When running inventory scan on Mac, you may see the following:

Error in Landesk.log:

ldiscan: (CFNetwork) TCP Conn 0x7ff78af0e320 canceled

ldiscan: (libnetwork.dylib) [com.apple.network:] [6 <private> stream, pid: 2585] cancelled

ldiscan: Failed to send scan file to server.

ldiscan: (CoreFoundation) Loading Preferences From System CFPrefsD

ldiscan: Releasing the lock on ldscan.

Error in System.log:

ldiscan[24551]: Last scan date: Wed Jun 27 2018, 13:46:01 EDT

ldiscan[24551]: Last scan occured more than 24 hours old (1197 hours, 49 minutes)

ldiscan[24551]: Last scan date: Wed Jun 27 2018, 13:46:01 EDT

ldiscan[24551]: Last scan occured more than 24 hours old (1197 hours, 49 minutes)

ldiscan[24551]: Setting up core server connection: CoreServerName.domain.com

ldiscan[24551]: Error, unable to connect to the core server

ldiscan[24551]: Last scan date: Wed Jun 27 2018, 13:46:01 EDT

ldiscan[24551]: Last scan occured more than 24 hours old (1197 hours, 49 minutes)

ldiscan[24551]: No destination. Not scanning to the core, and not scanning to file, stopping scanning now.

ldiscan[24551]: Releasing the lock on ldscan.

Cause

Mac Agent has too many .0 certificates

Solution

Having too many certificates on your clients can cause confusion on which one to use. If you run into this issue, you may need to clean them up on the client.

1. On the core server, open C:\Program Files\LANDesk\Shared Files\keys\protect.ini in notepad.
2. Take the value of "Hash=" and find the .0 file with that name on your Mac device:
   1. Should be under MacHD>usr>local>LANDesk>common>cbaroot>certs
3. Copy all .0 files on the client to a new folder except for the "Hash=" value certificate

If this resolves the issue, be sure to uncheck the problem certs from your client connectivity settings and delete those certs from C:\Program Files\LANDesk\ManagementSuite\ldlogon to prevent the issue from coming back when you reinstall the agent.

How to set up a simple SQL trace for troubleshooting database related issues

To reduce the size of the trace and the amount of data in the trace to filter through, please stop all Ivanti/LANDesk Services prior to running the SQL trace.  To make stopping the Ivanti/LANDESK services fast and easy, go to this link and get the batch file: How to Stop/Start all LANDESK Services at Once

Simple Trace

1. Open up the 'SQL Server Management Studio'
2. Go to 'Tools' and open 'SQL Server Profiler'
3. Select the tab that says 'Events Selection'
4. Uncheck All for 'Audit Login', 'Audit Logout', 'Existing Connections'
5. Check the 'Show All Events' box in the bottom right corner
6. Find and expand 'Errors and Warnings' and put a check in each box under the column 'TextData' and select the leftmost check box (to select entire row) by 'User Error Messages'
   
7. Find and expand 'OLEDB' and put a check in the left most box next to 'OLEDB Errors'
8. Find and expand 'Stored Procedures' and put a check in the left most box for 'RPC Output Parameter', 'RPC:Completed', RPC:Starting', 'SP:StmtCompleted', and 'SP:StmtStarting'.
9. If you have multiple databases on the SQL server, you will need to select both 'Show All Events' and 'Show All Columns', then open 'Column Filters' and select 'DatabaseName' > 'Like', and enter the name of the LANDESK database.
10. Start trace
11. Then try to recreate the issue.
12. Once you see the issue, Stop the trace and save the trace file.

Advanced Trace

1. Open up the 'SQL Server Management Studio'
2. Go to 'Tools' and open 'SQL Server Profiler'
3. Select the tab that says 'Events Selection'
4. Uncheck All for 'Audit Login', 'Audit Logout', 'Existing Connections'
5. Check the 'Show All Events' box in the bottom right corner
6. Find and expand 'Errors and Warnings' and put a check in each box under the column 'TextData' and select the leftmost check box (to select entire row) by 'User Error Messages'
   
7. Find and expand'Locks' and put a check in the left most box next to 'Lock:Deadlock'
8. Find and expand 'OLEDB' and put a check in the left most box next to 'OLEDB Errors'
9. Find and expand 'Performance' and put a check in the leftmost checkbox by 'SQL:FullTextQuery' and 'Showplan All'
10. Find and expand 'Stored Procedures' and put a check in the left most box for 'RPC Output Parameter', 'RPC:Completed', RPC:Starting', 'SP:StmtCompleted', and 'SP:StmtStarting'.
11. If you have multiple databases on the SQL server, you will need to select both 'Show All Events' and 'Show All Columns', then open 'Column Filters' and select 'DatabaseName' > 'Like', and enter the name of the LANDESK database.
12. Start trace
13. Then try to recreate the issue.
14. Once you see the issue, Stop the trace and save the trace file.

Once you have finished you can use the same batch file to restart all the Ivant/LANDESK services, or you can reboot the core.

• About the Changeslog.xml
• Changing the number of days of Inventory Change History storage
• Possible Issues with gathering Inventory Change history in the Changeslog.xml

About the Changeslog.xml

This document describes the purpose of the Changeslog.xml file that can be found in the LDCLIENT\DATA folder on a client.

The purpose of the Changeslog.xml file on a client is to keep a running history of changes that have been made on the client.  90 days of history is kept by default and is set in the following manner in the Inventory Settings on a client:

Changing the number of days of Inventory Change History storage

1. Open the Agent Settings tool in the EPM console.
2. Open the Inventory Settings you wish to edit.
3. Go to the "Scanner Settings" section and notice the "Change History Storage (days)" option.
4. Make a change to the number of days if desired.

This "Change History Storage (days)" option is not to be confused with the Inventory History option underneath the Configure --> Inventory History option within the EPM console.

The "Change History Storage (days)" option simply sets how many days the change history will be stored in the Changeslog.xml file on the client.

This Changeslog.xml file is simply used for troubleshooting purposes or for those that desire to keep a trackable history of changes.

This Changeslog.xml can be accessed through the Diagnostics tool by right-clicking a computer and selecting "Diagnostics" from the resulting menu.  This opens up a connection to the client and downloads the .XML file for viewing on the core server.  This is on a client by client basis as you view them in the Diagnostics tool.

However, only the first 50,000 lines are viewable within the Diagnostics tool, otherwise, an external editor can be used to view this file.

The changeslog.xml keeps change storage information in the following format:

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:1) - Start Time" oldvalue="1545206129" newvalue="1545490529"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:4) - Start Time" oldvalue="1545223252" newvalue="1545494072"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:5) - Start Time" oldvalue="1545204138" newvalue="1545492138"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:6) - Start Time" oldvalue="1545225341" newvalue="1545509105"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:7) - Start Time" oldvalue="1545255997" newvalue="1545520318"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Executable Path" oldvalue="" newvalue="C:\Program Files (x86)\LANDesk\LDClient\vulscan.exe"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Start Time" oldvalue="" newvalue="1545523502"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Frequency" oldvalue="" newvalue="86400"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Command Line" oldvalue="" newvalue="/continue"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Handle" oldvalue="" newvalue="893751"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - AutoDelay Filter" oldvalue="" newvalue="MinDelayMinutes : 0 ; MaxDelayMinutes : 5"/>

<change timestamp="2018-12-22T14:10:28+0:00" bnf="LANDesk Management - Local Scheduler - Scheduled Tasks - (Number:9) - Time of Day Filter" oldvalue="" newvalue="0 to 23"/>

This shows changes to the Local Scheduler tasks occurring showing when the task changes and the values that changed.

In addition file change information can be stored and include extremely detailed change information such as the following:

• File version
• File Size
• Filename
• Vendor
• File Date
• MS-DOS Name
• File Attributes
• Original Filename
• Company
• File Description
• Internal Name
• Copyright
• Product Name
• Product Version
• Private Build
• Comments
• Digitally Signed
• Digital Signature Signer
• MD5 Hash
• SHA1 Hash
• SHA256 Hash

Example:

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Version" oldvalue="" newvalue="4.0.30319.36373 built by: FX452RTMLDR"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - File Size" oldvalue="" newvalue="176824"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Name" oldvalue="" newvalue="ComSvcConfig.exe"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Vendor" oldvalue="" newvalue="Microsoft Corporation"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - File Date" oldvalue="" newvalue="1480561462"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - MSDOS Name" oldvalue="" newvalue="COMSVC~1.EXE"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Attribute Read Only" oldvalue="" newvalue="No"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Attribute System" oldvalue="" newvalue="No"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Attribute Hidden" oldvalue="" newvalue="No"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Original Filename" oldvalue="" newvalue="ComSvcConfig.exe"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Company Name" oldvalue="" newvalue="Microsoft Corporation"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - File Description" oldvalue="" newvalue="ComSvcConfig.exe"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Internal Name" oldvalue="" newvalue="ComSvcConfig.exe"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Copyright" oldvalue="" newvalue="? Microsoft Corporation.  All rights reserved."/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Product Name" oldvalue="" newvalue="Microsoft? .NET Framework"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Product Version" oldvalue="" newvalue="4.0.30319.36373"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Private Build" oldvalue="" newvalue="DDBLD366B"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Comments" oldvalue="" newvalue="Flavor=Retail"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Digitally Signed" oldvalue="" newvalue="Yes"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - Digital Signature Signer" oldvalue="" newvalue="Microsoft Corporation"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - MD5 Hash" oldvalue="" newvalue="7425BCAEC89F645738C06ACB75E16CB0"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - SHA1 Hash" oldvalue="" newvalue="46B934C260895D256C55F93D43491EDD889C2F25"/>

<change timestamp="2018-12-09T04:15:36+0:00" bnf="Software - Package - (Path:C:\WINDOWS\MICROSOFT.NET\FRAMEWORK64\V4.0.30319\COMSVCCONFIG.EXE) - SHA256 Hash" oldvalue="" newvalue="F417BD6063BB2CCAAB92FDECE10E29C235F716D181A39FC5760EE21633ED2C92"/>

Possible Issues with gathering Inventory Change history in the Changeslog.xml

Possible issue: Inventory Scanner crash

Due to extremely detailed file information being gathered ~ 23 lines of information is stored per file.

On some computers that have a large number of files, this can cause issues with the Inventory Scanner being able to load and write to this file.  With the Inventory Scanner being a 32-bit application it can only load into memory a limited amount of data.  The excessive amounts of data that can occur in the Changeslog.xml file can cause it to crash while scanning and not update to the core server.  Instances have been seen showing 500+ meg (2 million lines) Changeslog.xml files that are storing information for 90 days.  In this case, it is recommended to change the "Change History Storage (days)" option to a shorter period of time such as 30 days.  Making this change will truncate the existing data from 90 days down to 30 days, thus keeping some Inventory change history data.  If there is no need to keep historical information go ahead and change this to 0 days.  These steps are detailed at the start of this article.

In addition, it is advised as a best practice for Inventory Scanning, in general, to add several folders to the "Exclude Folders" list within the Manage Software List.

Here are the steps to do so:

1. Open the Reporting/Monitoring tool group in the EPM console
2. Open the Manage Software List.
3. Select "Settings" in the left-hand pane.
4. In the right-hand pane select "Exclude Folders"
5. Add three new folder paths
   
   %windir%\WinSxS\
   %windir%\Servicing\
   %windir%\Assembly\
   
   Note: Be sure to include the trailing "\" or the exclusion will not work.
6. After making these changes click the "Make Available to Clients" button in the toolbar.  This is the 2nd icon from the right (next to the [?] Help button).
   This will save the changes and the Inventory scanner will download these changes on the next full scan of the system.

How to limit or prevent software scanning on specific devices or drives

Description

This article is for EPM Administrators that have file servers or other devices where running a full software Inventory scan is utilizing resources and is not necessary. Where an EPM agent is used to manage the device but scanning all the software on the entire machine or certain drives is not desired.

Resolution 1

Limit the software scanning by drive or directory

Doing this will have the following effect:

The Inventory Scanner will still gather Application Suites and OS Updates (from the uninstall key) and the associated installed packages and their usage data (from the registry).  Therefore this does not completely cut out scanning for applications and packages.

This can be done in the Managed Software List as shown below:

1. Open the Reporting and Monitoring tool grou
2. Open the Manage Software List tool
3. Select "Settings" in the left-hand pane
4. Double-click "Excluded folders" in the right hand pane and add desired directories and/or drives.
   Note: Your entry must have a trailing "\" (backslash) in order to be recursive.

Resolution 2

Removing software scan altogether

The inventory scanner has a /F- switch that can be used. When this switch is used then the inventory scanner does not do any software scan. It will not pull Application Suites, OS Updates, usage, or packages associated with Application Suites.

If software scanning is not desired however information from the uninstall key is needed then use the /RSS switch after the /F-. This will return the application suites.

The implementation does not require modification of the ldappl3.ini file.

Instead only modify the localscheduler tasks and shortcuts following instructions above but using a command line based on this sample:

LOCALSCH.EXE /taskid=777 /exe="c:\program files\landesk\LDCLIENT\LDIScn32.EXE" /cmd="/NTT=CoreFQDN:5007 /S=CoreFQDN /F- /NOUI" /freq=86400

After changing the local scheduler tasks, add the /F- to the inventory scanner shortcut.