Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Windows NT Change Detection

The first time that you start the Windows NT Connector, with no existing object cache present, the corresponding Java process’s memory usage is approximately 26 – 30 Mbytes. However, the Windows NT Connector's memory usage can easily reach 100 Mbytes during normal operations.

The Windows NT Connector periodically polls the Windows NT subcomponents, that is, the Identity Synchronization for Windows NT Change Detector 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, the subcomponents can accumulate a significant number of changes in memory. A typical change record requires less than 100 bytes of memory, so 10 Mbytes of memory can accommodate 100,000 changes. However, this scenario is not likely to occur on a Windows NT system.

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 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

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, 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, 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 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 file in the PsTools software bundle at 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).