Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Windows NT Change Detection

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:

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

[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).