Environment
Situation
Setting up a filter (User object class, email address attribute), and a policy to take a <sync> on a User, a query was done to see if email address is populated, and if not to go find a unique email address and assign it to the user.
Using dxcmd, a resync on this driver was done. Waiting a while for it to finish, not all objects were modified. Looking at the level 3 trace, there are exactly 27,600 <sync> events processed. The tree has about 85,000 users in it.
Resolution
Resync checks every entry for attributes in the filter. If none of the attributes in the filter (mailLocalAddress and mailRoutingAddress in this case) are present in the entry, it doesn't get queued up. In this case, there are only 10776 entries in this dib that have any of these attributes.
As a workaround for this problem, there can be an attribute in the filter (as notify) that is always available. Adding 'Object Class' to the filter and all can see 85758 resync entries for this driver. (resyncing everything, no timestamp specified)
Additional Information
This is information from the customer's tests:
Changing the Filter to include Object Class does affect the results and seems to help. I set up a test (Null) driver, on the server from which you have that DIB set to work with.
First test, Filter is:
<filter-class class-name="User" publisher="ignore"
publisher-create-homedir="true" publisher-track-template-member="false"
subscriber="sync">
<filter-attr attr-name="mailLocalAddress"
merge-authority="default" publisher="ignore" publisher-optimize-modify="true" subscriber="notify"/>
<filter-attr attr-name="mailRoutingAddress"
merge-authority="default" publisher="ignore" publisher-optimize-modify="true" subscriber="notify"/>
</filter-class>
As before, I issued a resync from dxcmd, and the results are:
Enter name of file for response:
<?xml version="1.0" encoding="UTF-8"?><driver-info
driver-dn="Test.DS2.DirXML.NOVELL.IDVAULT"
server-dn="linuxvm1.NOVELL.IDVAULT"
timestamp="20081218173133.704Z">
<subscriber>
<cache>
<size>601814</size>
<unprocessed-size>601814</unprocessed-size>
<transactions>
<oldest>20081218171805.703Z</oldest>
<newest>20081218172936.646Z</newest>
<counts>
<resync-entry>10120</resync-entry>
</counts>
</transactions>
</cache>
</subscriber>
</driver-info>
I changed the Filter to add Object Class:
<filter-class class-name="User" publisher="ignore"
publisher-create-homedir="true" publisher-track-template-member="false"
subscriber="sync">
<filter-attr attr-name="mailLocalAddress"
merge-authority="default" publisher="ignore" publisher-optimize-modify="true"
subscriber="notify"/>
<filter-attr attr-name="mailRoutingAddress"
merge-authority="default" publisher="ignore" publisher-optimize-modify="true"
subscriber="notify"/>
<filter-attr attr-name="Object Class" merge-authority="default"
publisher="ignore" publisher-optimize-modify="true" subscriber="notify"/>
</filter-class>
cleared the *.TAO file, and issued a resync again, and got:
Enter name of file for response:
<?xml version="1.0" encoding="UTF-8"?><driver-info
driver-dn="Test.DS2.DirXML.NOVELL.IDVAULT"
server-dn="linuxvm1.NOVELL.IDVAULT"
timestamp="20081218190232.200Z">
<subscriber>
<cache>
<size>5062501</size>
<unprocessed-size>5062501</unprocessed-size>
<transactions>
<oldest>20081218173821.515Z</oldest>
<newest>20081218185914.818Z</newest>
<counts>
<resync-entry>85102</resync-entry>
</counts>
</transactions>
</cache>
</subscriber>
</driver-info>
If I use ldapsearch to check the tree, the User count appears to be correct:
user1@localhost:~> ldapsearch -x -LLL -H ldaps://<serverIPaddress> -Dcn=user1,ou=admins,o=niu -W -b o=niu
'(&(objectclass=user)(|(maillocaladdress=*)(mailroutingaddress=*)))' dn | grep dn: | wc -l
Enter LDAP Password:
10120
user11@localhost:~> ldapsearch -x -LLL -H ldaps://<serverDNSname> -D n=user1,ou=admins,o=niu -W -b o=niu 'objectclass=user' dn | grep dn: | wc -l
Enter LDAP Password:
85102
Only objects matching the Filter are included in a resync. For the moment, it looks like adding Object Class to the Filter provides a workaround that I think will work. I will have to investigate this further, but at least knowing that this is how it works helps explain what I was seeing, and gives me what I need to work around it.