Greyware Automation Products, Inc.
Greyware Automation Products, Inc.   
     Home    Products    Store    Downloads    Customer Service    Site Search    
Log in  or   Create an account now -- FREE!        
Kb > Knowledgebase Article KB2002.410

Problem: System Change Log reports do not include who made an account change.

This article applies to System Change Log.

Last Updated: 19 November 2010


    System Change Log reports do not include who made a change to a monitored path, even though you have the Include User Information checkbox checked on the control panel applet.


    By default,


      File/Object Success Auditing must be enabled before any user account lookups can take place. If auditing is not enabled when a change happens, then there will be no record of the change. (i.e., you cannot enable auditing today and hope to find out who did something yesterday.)

      In order for System Change Log to determine the person responsible for making a change, it must be able to read the Security Log on the machine where the service is running and find the relevant audit records that correspond to a file/folder change. If the relevant Security Log entry is not present at the time System Change Log tries to look up the responsible person (perhaps because auditing isn't enabled or the wrong audit events are being logged), then the user account information will be omitted from the System Change Log report.

      IMPORTANT NOTE: The Security Log records the filename that was changed, and System Change Log matches this up with the monitored path information to determine who made the change. Unfortunately, the Security Log does not record the "real" path information for file changes on Windows 2000/XP/2003 dynamic volumes. The only information recorded is the system internal reference information saying where on the dynamic volume the file resides. There is currently no way to match this with a drive letter and path after the fact (the mappings allow going from drive letter and path to virtual location, but not backward). Therefore, System Change Log will never be able to provide "whodunnit" information for changes to file residing on dynamic drives. "Real" drives on your system (that is, hard disks with drive letters associated with them) can be monitored just fine.


      Enable Success auditing for the type of File/Object activity that corresponds to the type of changes you have set System Change Log to monitor. For example, if you have set System Change Log to monitor file deletions in a particular folder, set the

      To test that auditing is functioning properly, make some changes to a file in a folder for which auditing is enabled and then use Event Viewer to inspect the Security log and look for records with an Event code of 560 (Category Object Access, Source Security, etc.). At least one of the 560 entries should include the name of the file which was modified and the action taken.

      If you cannot find 560 audit records relating to the file change, then you have not successfully enabled auditing. You should double-check to be sure you have:

      1. Enabled overall success auditing for Object Access using the Local Security Policy MMC snap-in found in Administrative Tools (called File and Object Access and found in User Manager in NT4)
      2. Selected the correct auditing events to record for a specific folder using Explorer/My Computer (or File Manager in NT4)
      3. Disabled the Inherit from parent... option in the Advanced Security Settings for the folder unless you understand how auditing settings filter down from higher-level folders.

      Here is a sample showing something similar to what you should see if auditing is enabled correctly:

      Event Viewer Security Log

      Detail Record from Security Log

My Account  |   Contact Us  |   Privacy Policy  |   Printer-Friendly Version
Copyright © 1995-2022 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.