13 Replies Latest reply on Oct 5, 2018 2:02 AM by phoffmann

    Inventory scan isn't updating Custom Data values

    Rookie

      Last week I added some Custom Data fields (registry values for Java Update info).  After the inventory scan, the values showed up for the machines (JavaRT & Policy)

      Untitled.png

       

      Over the weekend I ran a job to update the registry enties to what we require and inventory got updated as picture above.   However, upon reboot, the registry entries reset to the original values (that;s a different can of worms).

       

      The Inventory has not reverted even with a FULL SYCN SCAN.   If I use REGEDIT on the machine the values are different then the LDMS Inventory.

      At this point I can't trust the Custom Data I have in inventory.

       

      How can I get this corrected?

       

      I'm running LDMS 9.0, SP3.

       

      Thanks for your help.

        • 1. Re: Inventory scan isn't updating Custom Data values
          MrGadget Expert

          I don't have an answer but here are some thinking points.

           

          1. The values show up in inventory, this shows the inventory scanner is reading the registry entries so it is working as it is suppose to.

           

          2. You change the registy entries and on reboot the registry entries you made aren't there. This suggests something running on the computer is constantly writing to these registry entries.

           

          3.The Inventory has not reverted even with Full Sync Scan. Are you actually doing a Full sync scan? Manual right click on computer in console- Inventory scan- Full sync scan.

          The inventory after a Full Sync Scan should show exactly what it read from the registry.

          Run this on the computer   ldiscn32.exe /o=C:\scaninfo.txt  (You'll probably have to CD to the landesk\ldclient folder to run this)

          This will put the finding of the inventory scan in a file call scaninfo.txt in C:\  (This does not send the results to the core.)

          Look in there and see if the correct custom data is being picked up. If it is somehow its not being sent to the core during a normal Full ync scan.

          • 2. Re: Inventory scan isn't updating Custom Data values
            Rookie

            Mr Gadget-

             

            Thanks for your response.

             

            1) Yes, I would agree that the inventory scanner reported the values it saw the first time it read the new Custom Data fields I created.

             

            2) Yes, I did run a FULL SYNC SCAN (right click | Inventory Scan | FULL SYNC SCAN).  I've run this repeatedly.

             

            3) I ran the file to a text file on my desktop.  The file had "wrong" values. It contained the values I see in Inventory. 

             

             

            It appears that once established, the CUSTOM DATA fields are never updated again.

            • 3. Re: Inventory scan isn't updating Custom Data values
              bcarmody Rookie

              I'm replying to this old thread in hopes that someone might have seen this and know of a solution. We are running into the exact same issue here. We have a process we run periodically to change the common local account passwords on all of our endpoints. When we do this, we modify a registry value noting that the passwords were changed for that period. We have Custom Data set up to monitor this. The task runs properly and updates the registry value properly. However, it seems to take some time before the computer inventory in the LanDesk console recognizes the change. I'd like to say that it eventually does recognize it, although I can't say with 100% certainty, but it seems to take quite a bit of time on some computers and no number if inventory scans speeds it up. As the OP did, I have confirmed on multiple machines that the registry value was updated and have run full scans with output to a text file. While the registry is correct, the outputted text file still contains the incorrect value.

               

              I feel this has been happening for a while with other Custom Data entries as the behavior has always been erratic. I haven't thought much of it though until now when I need to report the status of these updates to leadership and the numbers can't be trusted.

               

              Any help is appreciated. Thanks in advance.

              Cust_Data1.JPG

              1 of 1 people found this helpful
              • 4. Re: Inventory scan isn't updating Custom Data values
                meltdowner Apprentice

                I'm experiencing the same problem right now.  In my case, I've created a query that pulls the ReleaseID from the registry (aka the windows 10 version number 1703/1709/1803 so forth).  The data was there and working at one point.  Now, computers that I know have had their version change do not show in landesk.

                • 5. Re: Inventory scan isn't updating Custom Data values
                  phoffmann SupportEmployee

                  I would suggest potentially starting a new thread for this, but the following should help a bit.

                   

                  • Run an output scan ( LDISCN32 /F /O=C:\Temp\MyOutput.scn ) on a device where "stuff don't work", and have a look inside the SCN file (it's just a text file) whether your custom data is in there in the first place.
                    • If it is, proceed further down.
                    • If the custom data ISN'T there, then see what happened to the registry location being queried / searched. Usually a permissions issue can be a problem, and/or "the registry key moved somewhere else now" tends to be the other big variant.

                   

                   

                  • That should cover the 2 most likely scenarios ... let's begin here & go from there.
                  • 6. Re: Inventory scan isn't updating Custom Data values
                    meltdowner Apprentice

                    Hey again Pat,

                    I did all of the things you suggested.

                     

                    The registry key is there, the custom data item was "made available to the clients" and scans were FULL SYNC SCAN.  The output.scn does not show the custom data item being added; it does not exist.

                     

                    I also, restarted the inventory service.  Cleared the "blocked inventory items". <---the item I want was NOT in that list by the way.

                     

                    What makes this extra fun to diagnose is that LANDesk has two completely separate features called "custom data forms".  One being a form the user fills out, the other being this "custom registry key".  Might want to suggest to change these names.

                     

                    I will open a support ticket.

                    • 7. Re: Inventory scan isn't updating Custom Data values
                      Rick.Smith1 Specialist

                      meltdowner does anything get imported in the SCN file? If you several devices importing the data and a handful that are not, you might check to see if something got installed on those devices now causing the SCN files to get rejected and they are actually ending up in the errorscan folder. You can check the event log on the core to see if SCN files are having issues and there are entries about needing to enlarge certain columns. The original post seemed to be getting some data but not all.

                       

                      If you are getting no data at all in the SCN file, double check your setting in the custom inventory data area. Are you specifying the right HKLM vs HKLM64 options?

                       

                      Rick

                      • 8. Re: Inventory scan isn't updating Custom Data values
                        JoeDrwiega SupportEmployee

                        Did you make the change to Update Clients in Manage Software and validate that ldappl3.ini is updated with the registry info? Also some things to check:

                         

                        • If your ldappl3.ini on the client has the custom data entries, but the scan doesn't have those attributes, then that generally means the inventory scanner is failing to access the key.
                          • Usually running a Procmon capture will identify the reason why. Often permissions.

                         

                        • If your ldappl3.ini on the client doesn't have the custom data entries, but the one on your core does, then the client isn't updating its ldappl3.ini, and may not even be configured to.
                          • Check your agent config's Inventory Settings and ensure "auto update lappl3" is checked.
                          • Check your agent's proxyhost.log under C:\Program Files (x86)\LANDesk\Shared Files to see what kind of error is returned calling LDDownloader, if any

                         

                        • If your ldappl3.ini on the core doesn't have the custom data entries, then the core has failed to rebuild the file.
                          • Head to %ldms_home%ldlogon and delete all files with "ldappl3" in the name, except for ldappl3.template. Then hit "Make available to clients" again to rebuild the file.
                        2 of 2 people found this helpful
                        • 9. Re: Inventory scan isn't updating Custom Data values
                          meltdowner Apprentice

                          Yes, the inventory does in fact update if I were to install a new version of say, Firefox, and run an inventory scan.

                          The key is accessible so that's not it.  No matter what key I try it cannot be read.

                          The client agents are configured, and always have been, to auto update the ldappl3.

                          The ldapp3 is being updating by the core, it has the registry keys in it that I want to query.

                          proxy host doesnt seem to have any errors.  Has the following on repeat, basically:

                           

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:FIPS mode = 1

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:About to determine if we go direct: bRequestIsForCore = 1, g_core = LANDESK01.ck.c-k.com, host = LANDESK01.ck.c-k.com:80, headerHost = LANDESK01.ck.c-k.com

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:Made direct (non-proxy) connection to LANDESK01.ck.c-k.com:80

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:Call UpdateCSAROIFile() with numberofDirectConnectSuccess = 1 numberofDirectConnectFailure = 0  csaName =  bCsaSuccess = 1

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:127.0.0.1:60738 Connection close 0 0 0 0

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:127.0.0.1:60738 - - [02/Oct/2018:19:02:09 -0600] "GET http://LANDESK01.ck.c-k.com/ScanInstructions/AgentStateServices/GetLastStateToken/{631FF3F5-198A-F640-A842-30A0B1F20CC9}/192.168.1.0--24/D404CDA48180/eb6c6731-bb65-4e25-b8f6-983ee3113ca6 HTTP/1.1" 200 261 545

                          2018-10-03 00:02:09(13064-26916) proxyhost.exe:127.0.0.1:60738 EOS on request

                          2018-10-03 00:02:46(31660-11076) proxyhost.exe:FIPS mode = 1

                          2018-10-03 00:02:46(31660-11076) proxyhost.exe:About to determine if we go direct: bRequestIsForCore = 1, g_core = LANDESK01.ck.c-k.com, host = LANDESK01.ck.c-k.com:80, headerHost = LANDESK01.ck.c-k.com

                          2018-10-03 00:02:48(31660-11076) proxyhost.exe:Made direct (non-proxy) connection to LANDESK01.ck.c-k.com:80

                          2018-10-03 00:02:48(31660-11076) proxyhost.exe:Call UpdateCSAROIFile() with numberofDirectConnectSuccess = 1 numberofDirectConnectFailure = 0  csaName =  bCsaSuccess = 1

                          2018-10-03 00:02:48(31660-11076) proxyhost.exe:127.0.0.1:60742 Connection close 0 0 0 0

                          2018-10-03 00:02:48(31660-11076) proxyhost.exe:127.0.0.1:60742 - - [02/Oct/2018:19:02:48 -0600] "GET http://LANDESK01.ck.c-k.com/ScanInstructions/AgentStateServices/GetLastStateToken/{631FF3F5-198A-F640-A842-30A0B1F20CC9}/192.168.1.0--24/D404CDA48180/eb6c6731-bb65-4e25-b8f6-983ee3113ca6 HTTP/1.1" 200 261 545

                          2018-10-03 00:02:48(31660-11076) proxyhost.exe:127.0.0.1:60742 EOS on request

                           

                          Seems that the rebuilt file has my custom settings but still, after running a full sync scan on any client, it does not return the values of my registry keys and I verified those keys are viewable, even by non-admins, and exist.

                          • 10. Re: Inventory scan isn't updating Custom Data values
                            meltdowner Apprentice

                            I was able to resolve this.  The patch folder was moved to a separate drive looks to be the root cause of this.

                             

                            The ldapp3.ini file was being updated in the wrong directory, or files were being split to two separate directories.  I moved all files that had an modified date of today, to both the c:\programs files\landesk\managementsuite\ldlogon\ and d:\ldlogon to both of the directories.

                             

                            Now the clients are updating with my custom data profiles.

                             

                            This is odd, why is the ivanati endpoint manager producing files in two separate locations?

                            1 of 1 people found this helpful
                            • 11. Re: Inventory scan isn't updating Custom Data values
                              JoeDrwiega SupportEmployee

                              Well hopefully this was the doc used to move the patch folder: How to change the default Patch Location for Patch and Compliance Manager

                               

                              Also be sure no one changed the Web Share for Ldlogon\Patch and just created a New Web Share like LDPatch that associates the directory to the new Patch location like D:\Patch and then download location reflect this.

                               

                              Be sure to test all changes and verify it fixes your issues as well.

                              • 12. Re: Inventory scan isn't updating Custom Data values
                                meltdowner Apprentice

                                Hey Joe, we did follow that originally.  Our patches do work, with the exception of any office 365 patch (sigh, that's another topic).

                                 

                                I am still concerned as to why the Endpoint Manager is putting files in the WRONG ldlogon folder.

                                 

                                To explain the setup better, we have this:

                                 

                                C:\Program Files\LANDesk\ManagementSuite\ldlogon  <--- standard location

                                D:\ldlogon\packages <--------THIS IS WHERE THE ldapp3.ini files were being placed when they SHOULD have been in the above directory!  For clarity, they are being placed in D:\ldlogon

                                D:\patch  <---works

                                 

                                The D:\ is a separate volume on our main server which we can expand if needed using VMWare.

                                 

                                The question is, why is landesk using D:\ldlogon AT ALL?  It it contains is the packages folder.  If you navigate to Http:/landeskserver/ldlogon  it displays the contents of "C:\Program Files\LANDesk\ManagementSuite\ldlogon"

                                 

                                So why the HE double hocket sticks is anything being put in this D:\ldlogon folder?  It should be empty except for my Packages folder.

                                • 13. Re: Inventory scan isn't updating Custom Data values
                                  phoffmann SupportEmployee

                                  You may want to trawl through the DB / agent settings, to see if you've got an agent-setting (or even an INI-change ) that says to put down an agent onto D:\ perhaps?

                                   

                                  It's not something that "should happen on its own" and USUALLY such things end up being "as configured" ("by someone" ... often enough, "by someone who had no business doing such a change") in my experience.

                                   

                                  Certainly it doesn't feel like normal behaviour ... but without going through either the DB and/or your agent-install INI files / agent behaviour files, I don't think there's a lot to do to guess what & why it's behaving so oddly.

                                   

                                  To help with the SQL side of things, here's a SQL Script / stored procedure which parses the ENTIRE database for a string. Can be VERY handy (and obvious - take quite a while) for chasing down odd things as a starting point. I've been using this script/stored procedure for nearly 2 decades for anything from reverse-engineering data structures/flows to locating all manner of oddities. Hope it helps you too!

                                   

                                  CREATE PROC SearchAllTables

                                   

                                  (

                                  @SearchStr nvarchar(100)

                                  )

                                  AS

                                  BEGIN


                                  -- Copyright (C)) 2002 Narayana Vyas Kondreddi. All rights reserved.

                                  -- Purpose: To search all columns of all tables for a given search string

                                  -- Written by: Narayana Vyas Kondreddi

                                  -- Site: http://vyaskn.tripod.com

                                  -- Tested on: SQL Server 7.0 and SQL Server 2000

                                  -- Date modified: 28th July 2002 22:50 GMT



                                  CREATE TABLE #Results (ColumnName nvarchar(370), ColumnValue nvarchar(3630))


                                  SET NOCOUNT ON


                                  DECLARE @TableName nvarchar(256), @ColumnName nvarchar(128), @SearchStr2 nvarchar(110)

                                  SET @TableName = ''

                                  SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''')


                                  WHILE @TableName IS NOT NULL

                                  BEGIN

                                  SET @ColumnName = ''

                                  SET @TableName =

                                  (

                                  SELECT MIN(QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME))

                                  FROM INFORMATION_SCHEMA.TABLES

                                  WHERE TABLE_TYPE = 'BASE TABLE'

                                  AND QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME) > @TableName

                                  AND OBJECTPROPERTY(

                                  OBJECT_ID(

                                  QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME)

                                  ), 'IsMSShipped'

                                  ) = 0

                                  )


                                  WHILE (@TableName IS NOT NULL) AND (@ColumnName IS NOT NULL)

                                  BEGIN

                                  SET @ColumnName =

                                  (

                                  SELECT MIN(QUOTENAME(COLUMN_NAME))

                                  FROM INFORMATION_SCHEMA.COLUMNS

                                  WHERE TABLE_SCHEMA = PARSENAME(@TableName, 2)

                                  AND TABLE_NAME = PARSENAME(@TableName, 1)

                                  AND DATA_TYPE IN ('char', 'varchar', 'nchar', 'nvarchar')

                                  AND QUOTENAME(COLUMN_NAME) > @ColumnName

                                  )


                                  IF @ColumnName IS NOT NULL

                                  BEGIN

                                  INSERT INTO #Results

                                  EXEC

                                  (

                                  'SELECT ''' + @TableName + '.' + @ColumnName + ''', LEFT(' + @ColumnName + ', 3630)

                                  FROM ' + @TableName + ' (NOLOCK) ' +

                                  ' WHERE ' + @ColumnName + ' LIKE ' + @SearchStr2

                                  )

                                  END

                                  END

                                  END


                                  SELECT ColumnName, ColumnValue FROM #Results

                                  END


                                  -- How to run the stored procedure.

                                  -- Execute the following in SQL Query Analyzer:

                                  -- EXEC SearchAllTables 'String'

                                  1 of 1 people found this helpful