Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
Question about checkprop feature of repadmin

已答复 Question about checkprop feature of repadmin

  • Monday, January 28, 2013 4:05 PM
     
     
    Sign In to Vote
    0

    I'm working my way through the repadmin white paper found here.

    http://www.microsoft.com/en-us/download/details.aspx?id=9028

    I'm a bit confused by the checkprop feature.  I believe the intent of the command is to determine whether or not all domain controllers are up to date with respect to a particular domain controller. 

    The syntax of the command is as follows

    repadmin /checkprop <DC_LIST> <NamingContext> <OriginatingDCInvocationID> <OriginatingUSN>

    I have several questions about the command

    1. DC_LIST:  I believe I have to specify a DC here because repadmin may not be run from a domain controller.  Is that correct?  If I am running repadmin /checkprop from a DC called "foodc1" but specify "foodc3" for the "DC_List" argument then foodc3 will make all of the queries that checkprop needs to make.  Is that correct?
    2. NamingContext:  I'm confused by the need to specify a naming context.  If the point of checkprop is to check if all domain controllers are up to date with respect to a particular domain controller and a particular USN then why specify a naming context at all?  I suspect there is something about USNs and naming contexts which I don't understand here.
    3. OriginatingInvocationID:  I understand that this is the invocationID of the AD database on the domain controller which is your baseline for checking replication up to dateness across all domain controllers.  However why does it need to be in GUID format, why not just specify the name of a DC.  One thought I have is that you might need to use checkprop to see how far a change which originated on a now dead (or authoratively restored) DC got.  Is this correct?
    4. OriginatingUSN:  Why do I need to specify this at all?  The example in the repadmin whitepaper has you use repadmin /showutdvec to get the highest USN from the baseline DC (same DC as the originatingInvocationID).  However if that is the case why specify it at all?  One thought I had was you may want to get the USN of a particular attribute and run that against checkprop.  Then you could see how far a particular attribute from the dead DC has replicated throughout your environment.  Is that correct?  Are there other reasons or tricks?
    5. I'm making the assumption that the Originating USN needs to be from an attribute on the OriginatingInvocationID.  It seems to me that it doesn't make sense otherwise.  Is this a correct assumption?

    I'd appreciate any comments or answers to my questions.  I feel I might be missing something fundamental, particularly around the interaction of USNs and naming contexts. 

    Thank you for any help

    Craig.

     

All Replies

  • Monday, January 28, 2013 7:10 PM
     
     Proposed Answer
    Sign In to Vote
    0

    Hello,

    You need read this link:

    How Up to Date Are My Domain Controllers?

    But, my suggestion is, read this great article (If you want to check to everything is OK between DC's):

    (2006-12-09) DC-GUIDs And Invocation IDs (Jorge de Almeida Pinto - MVP)

    Regards

    • Proposed As Answer by i.biswajith Tuesday, January 29, 2013 10:23 AM
    •  
     
  • Tuesday, January 29, 2013 7:48 PM
     
     
    Sign In to Vote
    0

    Hello

    Thank you for your response. 

    The first link is just the checkprop section of the repadmin white paper.  That is actually the blurb that inspired the questions I have.

    The second article did help a bit.  It confirmed my thought that a USN only has meaning if you know which invocationID it came from.  It didn't really answer my other questions though.

     
  • Wednesday, January 30, 2013 12:10 AM
     
     Answered
    Sign In to Vote
    1

    Hello,

    I understood, what is exactly your problem. you need read more and understand about replication.

    I give you some quik infos and links:

    Why GUIDs:

    Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object's GUID will yield results if the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to find. The values of other object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it keeps that value for life.

    Where & Why DC or DSA object GUID:

    The DC GUID is stored in the attribute objectGUID, that identifies the DC in the forest, then it does not matter in which domain is the DC within a single forest. The objectGUID is also used to determine of the DCs for a replication topology. if you check Forward Lookup Zone, _msdcs.root_domain, you can see a CNAME record for objectGUID.

    Update Sequence Number (USN)
    For every change that occurs on a domain controller (whether replicated inbound or an originating write) the update sequence number is incremented by one.

    Highest Committed USN
    This is held within RootDSE on every domain controller and is the highest USN committed to the database for that server. This is an attribute of RootDSE and is not replicated to the other domain controllers.

    Originating Update
    A domain controller that sets an attribute or builds an object performs an originating update of that attribute or object. The originating update can be seen within the metadata of the object and is used for interpreting which domain controller performed the change to an object.

    High-Watermark
    Each destination DC contains a high-watermark value of its interpretation of the upstream (or source) DC’s highest committed USN. If DC2’s high-watermark for DC1 is 3000 then DC1 can assume that DC2 already has knowledge of all changes less than or equal to USN 3000. The high-watermark is per replication link and knowledge a DC has of each direct replication partner. Although there may be hundreds of DCs within a domain, it’s possible DC2 only replicates with a handful of them and, therefore, would only have knowledge of the high-watermark of those DCs. The high-watermark prevents irrelevant objects from being considered by the source domain controller with respect to a single destination.

    Up-to-Dateness Vector
    Any DC that has ever made an originating update will have an entry in the up-to-dateness vector. This is per partition. We use the up-to-dateness vector to determine (rather filter out) attributes to objects that a downstream replication partner may have already received from a different source DC. Each DC has its own copy of the up-to-dateness vector for all domain controllers that replicate a specific partition.

    Version
    The term “version” refers to the version number of an attribute. An authoritative restore of an object will increment the version number of every attribute by a specific value.

    When changed invocationId:

    If a new application directory partition is created or existing application directory partition is deleted and recreated.

    If a restore process of Active Directory from MS supported backup.

    What are Naming Contexts?

    Each domain controller in a domain forest controlled by Active Directory Domain Services includes directory partitions. Directory partitions are also known as naming contexts. A directory partition is a contiguous portion of the overall directory that has independent replication scope and scheduling data. By default, the Active Directory Domain Service for an enterprise contains the following partitions: Schema Partition, Configuration Partition, Domain Partition

    2. Is repadmin /checkprop used for checking the properties of an object across all DCs that have a replica of the NC the object is in?

    I assume I only have to provide one DC for dclist. As I have to know the NC, originating DC's invocation GUID and the Originating USN to create/modify the object all at once, I assume this can be used to check if a newly created/modified object's status across the domain. Like when a new user has been created.

    Yes, that is correct.


    And ..................

    Now, please read this links:

    How Active Directory Replication Topology Works

    How the Active Directory Replication Model Works

    Active Directory Replication In Depth (Brian Desmond - MVP)

    What is the invocationID? (Florian Frommherz)

    Contexts and Directory Partitions (Windows)

    Follow up on "The Goodness that is Repadmin.exe" (Active Directory Blog)

    Regards




     
  • Thursday, January 31, 2013 2:34 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi,

    Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

     

    If you have any feedback on our support, please click here .

     

    Cataleya Li
    TechNet Community Support