1. The up-to-dateness vector contains an entry for each domain controller that holds a full replica of the directory partition.
2. The high-watermark vector contains an entry for each domain controller that holds a full replica of the directory partition.
3. Each DC maintains its own, local only, Local USN, on each partition. In the mean time, each DC has a copy of originating USN table.
4. When an attribute is modified(added/removed ...), the local USN is increased by one and assigned to the attribute, the orginating DSA and originating USN are changed/assigned as well. Within an object, the highest USN of all attributes becomes the object's usnChanged, which is an attribute of an object
Note: The maping tables of attributes and USNs are stored locally on DC, they are not part of AD[After more research, I realized that this statement was wrong. Local USNs are stored in AD as well as a blob operational attribute, but you can't view them from normal LDAP]. However, usnChanged is part of an object. Keep in mind that the attribute "usnChanged" is not replicated therefore on different DCs it has different values.
Unlike Local USN, the originating USN/DSA will travel with the new attribute value when replication happens
5. When requested, source DC sends updates in increasing USN order to the destination DC, the destination DC will keep the USN(local to source dc) of the latest updates it receives from a specific DC/partition. This USN is called the High-Watermark to that particular DC/partition. It's guaranteed that object on source DC/partition that have a usnChanged value lower or equal to the High-Watermark have been replicated to Destination DC.
The above statement has two implication:
1) High-watermark is used to filter irrelevant objects from being considered when replication happens between two DCs
2) All High-Watermark values for different DC/partitions together is call High-Watermark vector. It contains value for only directly replication partners.
6. Up-To-Dateness vector is similar to High-Watermark vector except that it contains the highest originating USNs from all source DCs from which it ever gets updates. The source DC compares the Up-To-Dateness value(from Destination DC) to its local originating USN table to decide what attributes need to be replicated. In other words, is used to filter irrelevant attributes from being replicated
Search This Blog
May 16, 2005
May 15, 2005
LocalSystem vs. Service Account
1. LocalSystem has not password and few privilege(as computer acccount), Service Account has the context of the domain account (Actually, LocalSystem does have a password just like your own account, but normally you don't have to worry about it)
2. Whenever you change password of a Service Account, you have to make change in the corresponding service properties via services console
3. LocalSystem on a DC has all rights against AD, so it's not recommended to use LocalSystem for starting a non-builtin service on DC
4. LocalSystem is subjected to remove when you remove the computer out of the domain, while Service Account remains in AD
2. Whenever you change password of a Service Account, you have to make change in the corresponding service properties via services console
3. LocalSystem on a DC has all rights against AD, so it's not recommended to use LocalSystem for starting a non-builtin service on DC
4. LocalSystem is subjected to remove when you remove the computer out of the domain, while Service Account remains in AD
May 10, 2005
ObjectCategory vs. ObjectClass in a Search Filter
copy from "Windows 2000 Resource Kits"
Because of the existence of the class inheritance hierarchy in the schema, every object in Active Directory is in fact a member of many classes ? four or five on the average. For this reason, the objectClass index is prohibitively large (for example, 4n, where n is the number of objects in the system). In addition, objectClass has poor selectivity for many possible class values. For example, a search filter of (objectClass=securityPrincipal) returns every user and group object in the system.
On the other hand, objectCategory usually refers to the most specific class in the object's class hierarchy. Although objectClass can have multiple values, the attribute objectCategory has only one. Every Active Directory object has an objectCategory attribute whose value is a classSchema object.
Every classSchema object has an attribute called defaultObjectCategory, which is the object category of an instance of the class if none is specified by the user. For most classes, the defaultObjectCategory value is the class itself. In the search filter, you can specify objectCategory=X, where X is the ldapDisplayName of a class, and LDAP automatically expands the filter to objectCategory=. The objectCategory attribute has a syntax of distinguished name, and LDAP automatically converts the value for objectCategory to the distinguished name format. For example, if you use objectCategory=contact in the filter, the filter changes to objectCategory=cn=person,cn=schema,cn=configuration,dc= ("person" is the defaultObjectCategory for the class contact).
Because of the existence of the class inheritance hierarchy in the schema, every object in Active Directory is in fact a member of many classes ? four or five on the average. For this reason, the objectClass index is prohibitively large (for example, 4n, where n is the number of objects in the system). In addition, objectClass has poor selectivity for many possible class values. For example, a search filter of (objectClass=securityPrincipal) returns every user and group object in the system.
On the other hand, objectCategory usually refers to the most specific class in the object's class hierarchy. Although objectClass can have multiple values, the attribute objectCategory has only one. Every Active Directory object has an objectCategory attribute whose value is a classSchema object.
Every classSchema object has an attribute called defaultObjectCategory, which is the object category of an instance of the class if none is specified by the user. For most classes, the defaultObjectCategory value is the class itself. In the search filter, you can specify objectCategory=X, where X is the ldapDisplayName of a class, and LDAP automatically expands the filter to objectCategory=. The objectCategory attribute has a syntax of distinguished name, and LDAP automatically converts the value for objectCategory to the distinguished name format. For example, if you use objectCategory=contact in the filter, the filter changes to objectCategory=cn=person,cn=schema,cn=configuration,dc= ("person" is the defaultObjectCategory for the class contact).
Subscribe to:
Posts (Atom)