When you start Windows NT Connector for the first time, with no existing object cache present, the corresponding Java process’s memory usage is approximately 26 to 30 MB. However, the Windows NT Connector's memory usage can easily reach 100 MB during normal operations.
The Windows NT Connector periodically polls the Windows NT subcomponents, that is, Identity Synchronization for Windows NT Change Detector Service and the Identity Synchronization for Windows Password Filter DLL for changes. After the connector retrieves changes from a subcomponent, the connector processes the change and based on the configuration, it will or will not send the change over Message Queue. After the connector finishes processing the change, it removes the change from the subcomponents.
If the Windows NT Connector is unavailable for a longer period of time, then the subcomponents can accumulate a significant number of changes in memory. A typical change record requires less than 100 bytes of memory, so 10 MB of memory can accommodate 100,000 changes. However, this scenario is not likely to occur on Windows NT.
Both the Change Detector service and the Password Filter DLL service maintain some internal counters. You can use these counters (with the connector's log file) to determine how far behind the connector is with change processing compared to the subcomponents.
For example, the following is a user creation entry in the connector's log:
[01/Nov/2004:10:29:07.390 -0600] INFO 18 CNN102 example-wnt "The agent is sending the following inbound action to MQ: Type: CREATE SUL: NT {Data Attrs: [ADD userpassword: ****]} {Other Attrs: sn: test cn: Jane Test user_rid: 1004 dspswuserlink: RID=1004+DOMAIN=EXAMPLE subcomp_src: PASSWORD_FILTER usnchanged: 5}." (Action ID=CNN102-FFF4EFF25B-995, SN=0) |
The important fields in this entry are:
subcomp_src: PASSWORD_FILTER (indicates that the change was read from the Identity Synchronization for Windows Password Filter DLL)
usnchanged: 5 (indicates that the Password Filter DLL assigned change number 5 to this record)
If you open the registry editor and navigate to HKEY_LOCAL_MACHINE\\SOFTWARE\\Sun Microsystems\\Sun Java(TM) System Identity Synchronization for Windows\\1.1, you can view the following registry values:
"PfLastAckedChangeNumber"=hex:05,00,00,00,00,00,00,00 "PfLastAckedChangeTime"=hex:54,64,86,41 "PfHighestChangeNumber"=hex:05,00,00,00,00,00,00,00 "PfHighestChangeTime"=hex:52,64,86,41
Where:
PfLastAckedChangeNumber: Specifies the last change number the connector acknowledged to the Password Filter.
PfLastAckedChangeTime: Specifies what time the last update was received in the following format:
number of seconds since 00:00:00 UTC, January 1, 1970
PfHighestChangenumberr: Specifies the highest change number recorded by the Password Filter DLL. If this change number is the same as the PfLastAckedChangeNumber, then there are no changes buffered in the Password Filter DLL.
PfHighestChangeTimer: Specifies what time the change was processed by the Password Filter DLL.
The following is another example from the Identity Synchronization for Windows Change Detector:
[01/Nov/2004:10:30:31.802 -0600] INFO 18 CNN102 example-wnt "The agent is sending the following inbound action to MQ: Type: MODIFY SUL: NT {Data Attrs: } {Other Attrs: sn: test cn: Jane Test user_rid: 1004 dspswuserlink: RID=1004+DOMAIN=EXAMPLE subcomp_src: NT_CHANGE_DETECTOR usnchanged: 19}." (Action ID=CNN102-FFF4EFF25B-1162, SN=0)
In this example, the subcomp_src is set to NT_CHANGE_DETECTOR and the following counters are displayed in the same registry entry mentioned previously:
"LastProcessedSecLogRecordNumber"=dword:0000001b "LastProcessedSecLogTimeStamp"=dword:418664a7 "HighestChangeNumber"=dword:00000013
In this example, the Change Detector does not show the last acknowledged changenumber, but the value of HighestChangeNumber is the same as the value in the log entry.
To determine (approximately) how many unprocessed changes there are in the Change Detector, check the last log entry in which the subcomp_src is set to NT_CHANGE_DETECTOR, and then compare the usnchanged value in the log entry with the HighestChangeNumber in the registry.
The LastProcessedSecLog counter refers to the last-processed entry in the system's security log.
The psloglist.exe in the PsTools software bundle from http://www.sysinternals.com/ facilitates listing the contents of the security log and printing out the security log numbers. For example,
C:\>psloglist.exe security Security log on \\\\ EXAMPLE-WNT: [027] Security Type: AUDIT SUCCESS Computer: EXAMPLE-WNT Time: 11/1/04 10:30:31 AM ID: 642 User: Administrator\\EXAMPLE User Account Changed: Target Account Name: test Target Domain: EXAMPLE Target Account ID: S-1-5-21-975783841-454902410-2021868755-1004 Caller User Name: Administrator Caller Domain: EXAMPLE Caller Logon ID: (0x0,0x144B) Privileges: ... |
In this example, the log record number is 27 (which corresponds to the value in LastProcessedSecLogRecordNumber - 0x1b).