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 KB2001.815

Problem: Membership Monitor reports do not include who made an account change, even though you have the Look Up Responsible Person checkbox checked on the control panel applet

This article applies to Membership Monitor.

Last Updated: 12 June 2015


    Membership Monitor reports do not include who made an account change, even though you have the Look Up Responsible Person checkbox checked on the control panel applet.


    Windows does not store information about who made changes to user accounts in the user account database (SAM or Active Directory). You can, however, enable auditing for these kinds of changes. When you do, Windows will create an entry in the Event Viewer Security Log at the time a user account is changed. By examining this log and decoding the SID information and Event ID numbers, it is possible to reconstruct most user account actions and thus determine "whodunnit" for any given change.


    Auditing must be enabled before any 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.)

    • Stand-alone Machines and Member Servers
      On stand-alone workstations, servers, or member servers, you must enable auditing on that machine (as opposed to enabling auditing on the domain, if a domain is present). Changes to that machine's user database will show up in the Security Log on that machine. In order for Membership Monitor to determine the responsible person, it must be able to read the Security Log on that machine.

    • NT4 Domain Accounts
      Changes to NT4 domain accounts always happen at the PDC, so this is where the Security Log information is recorded. Changes are propagated out to each BDC, but the BDCs do not generate auditing entries in their own Security Logs. Membership Monitor therefore needs to be able to read the Security Log on the NT4 PDC in order to determine the responsible person.

    • Single-Master Windows Domain Accounts
      If your Windows domain has only a single master, or if you do not have Active Directory enabled, then all audit information will be on the PDC emulator (FSMO). Membership Monitor will automatically detect this situation and treat the Single-Master Windows domain as if it were a regular NT4 domain.

    • Multi-Master Windows Domain Accounts
      When Active Directory is enabled, either in mixed mode or pure mode, then you may have more than one writable Domain Controller. In this case, the auditing information is recorded on whatever DC actually processes the original change. There is no way to determine, without examining the Security Log on every DC, where the change took place. When Membership Monitor is installed on a DC with Active Directory enabled, it will automatically examine the Security Logs of all DCs it can find when trying to look up the responsible person. If you install Membership Monitor on a non-DC machine but are monitoring the domain, Membership Monitor may not know to examine all of the Security Logs.

    If the relevant Security Log is not available at the time Membership Monitor tries to look up the responsible person (perhaps because the DC that audited the change is offline), or if the desired information isn't present (perhaps because auditing isn't enabled), then the information will be omitted from the report.

    In order to prevent needless network traffic, Membership Monitor first checks to see that user and group management auditing is enabled. If not, Membership Monitor will not bother reading through (possibly dozens of) Security Logs, looking for information that won't be present. Membership Monitor also performs this check when you enable lookups using the control panel applet. If you get a warning message when trying to enable lookups, then you should check your audit settings.


    Enable Success auditing for User and Group Management in the Security Policy for the machine or domain being monitored. The process for enabling local security auditing is slightly different for each operating system version. See these articles from the Microsoft Knowledgebase:

    To test that auditing is functioning properly, make some changes and then use Event Viewer to inspect the Security log and look for events with the Category Account Manager, Source Security, and Type Success Audit. If you cannot find audit records relating to user and group management, then you have not enabled auditing for the correct category, or you enabled it in the wrong place (on the domain when you meant to target a particular machine, on a machine when you meant to target the domain, or a local policy when you meant to specificy a domain policy). 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

    The user account used for running the Membership Monitor service must have sufficient rights to read the event logs on all machines being monitored. To test this, log in with the service account and use the Event Viewer to connect to the remote machines and verify that you are able to read both the local and remote event logs (particularly on the PDC, or the PDC emulators on Win2000 trees).

    You may change the Debugging Enabled Registry Setting for Membership Monitor to True in order to get more detailed information on what Membership Monitor is trying to do, and what information it finds in the Event Logs.


    Modifying Registry entries requires basic familiarity with the Windows Registry and its operations. Incorrect changes to the Registry can result in unpredictable, perhaps non-repairable, damage, up to and including a non-bootable system! Have a qualified technician make the changes for you if you are not comfortable with the process. We cannot be responsible for registry problems.

    Membership Monitor registry settings are located in:

                Membership Monitor

    Value Name:

    Value Type:

    Default Value:


    Debugging Enabled



    True or False

    If True, Membership Monitor will record extra information in the %systemroot%\system32\gwmm.log file. This information may help you diagnose the problem. If you cannot get lookups to work after double-checking that auditing in enabled and working, then change this value to True. Be sure to set this value back to False when you are done debugging to keep your log file from filling up with unnecessary output.

    Changes to the Debugging Enabled value take effect the next time Membership Monitor writes to the log. You do not have to stop and restart the service or reboot the machine.

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