10 Replies Latest reply on Mar 21, 2016 7:39 AM by dcruzd

    Audit Trail


      Hi All,


      Does anyone know where I can find the log file about the console login? We want to find out the people who logged on to the LANDesk console.





        • 1. Re: Audit Trail
          MarXtar ITSMMVPGroup

          There isn't a log for that type of activity.


          Mark McGinn

          MarXtar Ltd


          LANDesk Silver ESP


          The One-Stop Shop for LANDesk Enhancements

          - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

          • 2. Re: Audit Trail
            zman Master

            So as Mark indicated no real auditing of this event, however, you can scrape the console.exe.log file for who logged into the console. If you have a lot of remote consoles this can be a PITA, but can be done. If you are logging in with domain credentials domain\account, you can use find/grep on the file to extract all the logins.


            Also, please post what version of the software you are using.

            • 3. Re: Audit Trail
              MarXtar ITSMMVPGroup

              That's a good point zman. I really think this is an area where LANDesk could do with improving capabilities. Too many opportunities for LANDesk console users to go unaudited.


              Mark McGinn

              MarXtar Ltd


              LANDesk Silver ESP


              The One-Stop Shop for LANDesk Enhancements

              - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

              • 4. Re: Audit Trail
                zman Master

                Yep, been asking for this for sometime. There is a an ER http://community.landesk.com/support/ideas/1489 and I've seen some early prototypes but nothing lately.  Here were my very rough notes from a while back - straight from the head:


                LANDesk Management Suite Auditing Notes

                LDMS should have a centralized audit function.  As the tool penetrates larger markets and more diversified environments, auditing is imperative.  In environments where there are multiple LANDesk administrators and regulatory, political, security, or other operational requirements there is currently no way to track LDMS object modifications, addition, deletions, etc…  These object changes can have a significant impact on performance, client user experience, and negative political ramifications.

                The scope of Auditing should initially be limited to Core auditing in the first phase and then research client side auditing (e.g., client side events such as software distribution). Audit information should be in a separate DB, not stored locally on the core (e.g., event logs, etc…)  SNMP integration may be evaluated to publish audits to external audit/logging systems.

                I believe that at a minimum the following should be tracked whether initiated by user or automated task (LPM):

                • Create
                • Change
                • Delete

                Whenever a object is altered the following information should be recorded:

                • Username
                • ComputerName
                • IP Address
                • Date Time
                • Object Name – (e.g., Scheduled Task, Query, Distribution Package, etc…)
                • Action – Create – Change – Delete.
                • Detail – What was Created – Changed – Deleted. 

                With the realization that this can place an increased performance and storage burden on LANDesk, the auditing feature should have:

                • Global Settings
                  • Ability to turn auditing on and off per core
                  • Ability to replicate all aspects of auditing between cores.
                  • Visual indicator per function/object whether auditing is on or off
                  • Ability to automagically purge auditing events based on X days. Archiving feature would be nice for audits.
                  • Ability to acknowledge Audits Events.
                  • Ability to Audit when SPs, post patches, hotfixes are applied to the core.
                  • Function
                    • Ability to turn on and off auditing per function (e.g., Scheduled Tasks, RC, etc…)
                    • Object
                      • Ability to turn on and off auditing per Object (e.g., Specific  Scheduled Task).

                Define audit records as

                • Critical
                • Information
                • Error

                Rollup audit logs for reporting.  Keep audit data in sql. Separate DB.

                Combine logs and Audits into one  – inventory history – and audit.


                1. Functions
                  1. Software Distribution

                                                                               i.      Queries – LDMS and LDAP

                                                                             ii.      Scheduled Tasks

                                                                            iii.      Distribution Packages

                                                                           iv.      Delivery Methods

                                                                             v.      Directory Manager

                                                                           vi.      Scripts

                                                                          vii.      Launchpad

                1. OSD
                2. Administration

                                                                               i.      Core Replication

                                                                             ii.      Alerting

                                                                            iii.      Agent Config

                                                                           iv.      Custom Data Forms

                                                                             v.      UDD

                                                                           vi.      All items under Configure, etc

                1. Power Management
                2. Reporting

                                                                               i.      Logs – should be integrated into Auditing feature

                                                                             ii.      SLM

                                                                            iii.      Reports

                1. Security and Compliance

                                                                               i.      Scan Folder

                                                                             ii.      Groups

                                                                            iii.      Settings

                1. Console Users

                                                                               i.      Console users logon and logoff times

                                                                             ii.      Logon failures

                1. RBA

                                                                               i.      Any changes made to RBA settings.

                UI for the Auditing

                • Filtering based on
                  • Audit Type – Critical – Information….
                  • Source – Core, Client (if you decide to do client side auditing).
                  • Date
                  • Audit ID.


                I know we spoke about dashboards and such and the inability to “guess” what a user would like to see,  and below is a swag at what I would like:

                • Audit summary
                  • Amount of Critical events over the last X time frame.
                  • LANDesk Function (e.g., patch, software dist., etc…) causing the most critical events over the last X time frame.
                  • This would change significantly if you did client side auditing.
                • 5. Re: Audit Trail

                  Yep, LANDesk really needs to improve the functionality here. At the very least, they should output audit logging info to the Windows Event logs.

                  • 6. Re: Audit Trail
                    JonnyB SupportEmployee

                    There is an option to add auditing events in the Configure > Auditing Configuration section



                    • 8. Re: Audit Trail

                      I do not have that tab on any of our 6 cores and they are all running LDMS 9.5 SP1. What's the deal there? When was that functionality added?

                      • 9. Re: Audit Trail

                        Thanks much. Just got it turned on.


                        Not sure why the LANDesk Administrator role doesn't have the rights to view this...after all, it has the rights to grant access to the role.

                        • 10. Re: Audit Trail



                          I would like to know if there has been progress with auditing in Landesk.


                          Here is a list of actions that I would like tracked.


                          1) No of build jobs that were done over a defined time period, the serial number of machines that were used and the name of the admin who scheduled the jobs.

                          2) Who deployed what software and when.

                          3) Historical user information of an asset.