4 Replies Latest reply on Feb 8, 2013 9:47 PM by Catalysttgj

    Inventory reporting

    Rookie

      Using landesk managment suite ver 9 and running into an issue with reporting date differences between vulnerability and hardware reports. Date difference showing up to a 5 months difference.

       

      Not all clients are having reporting issue...Also noticed after a .NET update some of the delinquent clients do respond and update Vulnerability scan.

        • 1. Re: Inventory reporting
          Apprentice

          Vulnerability scan and Inventory scan are handled by two different processes. You may want to run both inventory and vulscan and check to see if the dates updated. It could have a bad record sometimes i see perfect clients having trouble updating. If you have access to the client you can also just delete the record from the database and have the client full scan back in again. Something to start with.

          • 2. Re: Inventory reporting
            Frank Wils ITSMMVPGroup

            Look here for a good explanation of all the different scan dates and what updates them:

            http://community.landesk.com/support/docs/DOC-6928

             

            Frank

            • 3. Re: Inventory reporting
              Rookie

              What file do you delete on the client ? Does update if I force the scan from the client ( programs\Landesk Management Suite\security scan}.

               

              Only an issue on about 10% of managed clients.

               

               

              Thanks

              • 4. Re: Inventory reporting
                Catalysttgj Expert

                If you're seeing vulscan dates that do not seem correct or otherwise suspect for one reason or another, it would be a good idea to pick out a few problem machines, remote control them and get access to the vuscan log files on each and see what the heck they're doing. You might be having a server performance issue. We saw all sorts of issues when our hardware was overwhelmed. The typical result was failure on the client end communicating to the core but specifically to the uploading only. Most machines would perform the scan fine, but they just had trouble uploading the results which often included updating the last vulscan date. These types of issues will be easier to observe looking at the logs on the client end. The vulscan logs are located under C:\Documents and Settings\All Users\Application Data\Vulscan on XP and other OS's that still use the "Documents and Settings" folder. For the newer OS's like win7 you'll need to look under C:\ProgamData\Vulscan. The logs begin with vulscan, usually include a number and have extension .log, or sometimes they may have a PID reference in their name too. Look at the date modified to determine the order that these logs were made. Use the dates to help determine what kicked them, like scheduled vs. something else.

                 

                Also, HP_BD was suggesting that you delete the device from the DB and then get the device to perform an inventory scan again to get it back in the DB. Sort of a reset, but don't cut yourself off from the device before you do this. You might want to remote control the device first, so you can kick off that inventory scan, after you delete it from the DB. Personally, i'd look at all logs on the machine first related to landesk.

                 

                I think you've got a problem with either performance or maybe its a local scheduler issue. You can review how your security scans are getting called by the local scheduler in its log which is in the agent's install location under LDclient. Just look for localscheduler.log in there and see whats going on with the vulscan calls. Maybe its not doing them for some reason?

                 

                If you do turn out to have a performance issue, you might simply need more worker processes for the vulnerability app pool, i believe. I'm not looking right at it, but we had to increase ours on our new equipment. Its a typical adjustment for something like this.

                 

                ALSO worth mention... the different categories that can be included in a security scan affect the size of an uploaded xmlz file from each client. An example, if a scan includes spyware/blocked apps, it will have a markedly larger scan file, so if you happen to have all your clients doing this every time, and you suspect a performance issue, you might consider changing your schedule on your agents to not include this category for a bit, and see if you get better scan results over all. We changed our scheduled scans to only perform a spyware/blocked apps weekly on each machine, and we staggered the machines so that they were spread out through the week and not doing this scan on the same day. Its a little tricky to do all this, but it can make a big difference.

                 

                Good luck!