To add an attribute to the Filtered Attribute Set (the stuff that wont replicate to a RODC) you first need to know what the existing value of the searchflags is.
For this example, working with the “drink” attribute of the user class. Goodness knows we cant risk having the drink attribute compromised, so safety first, lets exclude it from RODC replication.
To view the current search flags, use ldifde: “ldifde -d CN=drink,CN=Schema,CN=Configuration,DC=duffey,DC=info -f en_ldif -l searchflags”
In the case of the drink atribute the output is:
This works well because i can just add the search flag i need. If this was any value other than zero a bitwise operation is required to maintain the values already set and add the new ones.
To change the value to include Filtered Attribute Set and also Confidential (cant be viewed by any old authenticated user) i modify the ldifde output to:
Dont miss the “-” on the bottom line. Its a required terminator for the ldif file.
To import i run the command: “ldifde -i -f en_fas.ldif”
If i use ADSIedit now i can see the properties of the drink attribute and verify that this should not make its way to a RODC:
Looks good, now to double check the RODC to make sure the attribute doesnt exist for my users:
Check the attribute on a RWDC:
Now log on to the RODC:
So the setting has applied successfully. The attribute still exists on the user class, but its values are never replicated to a RODC.
Viewing the FAS
You can use LDP to look at what is included in the FAS (http://support.microsoft.com/kb/269181):
The filter to save typing is: (SearchFlags:1.2.840.1135126.96.36.1993:=512)
Powershell: “Get-ADObject -LDAPFilter “(&(ObjectClass=attributeSchema)(SearchFlags:1.2.840.1135188.8.131.523:=512))” -SearchBase ‘cn=Schema,cn=Configuration,dc=duffey,dc=info’ -server 192.168.1.2 -SearchScope Subtree | ft name, objectGUID”