Somebody asked me in passing how querying retiredReplDSASignatures (Retired-Repl-DSA-Signatures) for a given invocationID (Invocation-ID) can yield more than one result. Well, says I, as interesting a question as that is I'm afraid the answer is rather simple - the duplicate retired invocationID is most likely a result of you having performed an IFM installation of a domain controller.
When you perform an IFM installation a portion of the process is treated in a similar way to a restoration operation. Basically the source invocationID is written to the new DCs retiredReplDSASignatures attribute. The reason for this is when a connection object is created, the new DC checks its retiredReplDSASignatures to see if any retired invocation-IDs match the invocation-IDs in the up-to-dateness vector passed by the target domain controller. When installing from IFM there will be a match (there could actually be several) so the retired invocationID with the highest committed USN is used to determine a "transitive up-to-dateness". The net result being that only a subset of the database is replicated.
So, if you have promoted several DCs (or ADAM instances) from an IFM you will have several NTDSDSA objects with the same retired replication signature.
Event ID 1109 is logged on the newly promoted instance to acknowledge what has happened. That event looks like this:
Log Name: ADAM (msres)
Source: ADAM [msres] Replication
Date: 31/01/2008 12:55:35
Event ID: 1109
Task Category: Replication
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: rwdc.idmgmt.int
Description:
Active Directory Lightweight Directory Services has been restored from backup media, or has been configured to
host an application partition. The invocationID attribute for this directory server has been changed. The highest
update sequence number at the time the backup was created is as follows.
InvocationID attribute (old value):
27e573cc-02d5-452c-bed4-feaebe188d5b
InvocationID attribute (new value):
0dfa5e40-600b-4a05-99eb-084716b56f7e
Update sequence number:
13871
The invocationID is changed when a directory server is restored from backup media or is configured to host a
writeable application directory partition.
Illustration
To illustrate this point I've created an AD LDS (formerly ADAM) instance, created a backup and built a replica using the backup as the source for IFM. The instance is called msres and resides on two Win2008 servers who's roles are irrelevant to this discussion (although you can probably guess the roles of these servers from the name). Here's the output of running REPADMIN /SHOWSIG on both LDS instances:
d:\ntds\lds-data\msres\ifm-install>repadmin /showsig rodc:50389
Default-First-Site-Name\RODC$msres
Current DSA invocationID: 27e573cc-02d5-452c-bed4-feaebe188d5b
No retired signatures.
d:\ntds\lds-data\msres\ifm-install>repadmin /showsig rwdc:50389
Default-First-Site-Name\RWDC$msres
Current DSA invocationID: 0dfa5e40-600b-4a05-99eb-084716b56f7e
27e573cc-02d5-452c-bed4-feaebe188d5b retired on 2008-01-31 12:55:41 at USN 13871
To further explain what's happened here, the first instance I built was on RODC. I then backed up the instance using the IFM "context" of DSDBUTIL (see below for a quick "how to") and built a replica instance using the IFM. The result of which is that the second instance is built using the IFM as the initial directory load.
Appendix. How to create an IFM source for an AD DS or AD LDS replica.
The NT6.x Directory service has seen a number of updates, one of which is the new snapshot feature. Basically, you can mount a snapshot (backup) of the directory using DSAMAIN (essentially ADAM). This technology is built on VSS and is also used to create IFM sources. In previous versions of AD and ADAM you had to backup the system state and then restore the system state to an alternate location and use the resultant restored files. In Windows Server 2008 you simply perform a snapshot using DSDBUTIL (AD LDS) or NTDSUTIL (AD DS) which results in a "snapshotted" DIT file. The following is an example of how to create this snapshot. In this example I'm using an AD LDS instance and therefore using the DSDBUTIL application. For an AD DS instance you would use NTDSUTIL and would specify NTDS as the active instance as opposed to the "active instance <instance name>" command.
d:\ntds\lds-data\msres\backup>md 2008-01-31
d:\ntds\lds-data\msres\backup>dsdbutil
dsdbutil: activate instance msres
Active instance set to "msres".
dsdbutil: ifm
ifm: create full .\2008-01-31
Creating snapshot...
Snapshot set {94416f88-bcb0-4ba3-91ce-7b6c84bcf5cc} generated successfully.
Snapshot {ce821c22-5b18-4549-855d-c0d9485cee05} mounted as C:\$SNAP_200801311546_VOLUMED$\
Initiating DEFRAGMENTATION mode...
Source Database: C:\$SNAP_200801311546_VOLUMED$\ntds\lds-data\msres\db\adam
ntds.dit
Target Database: d:\ntds\lds-data\msres\backup\2008-01-31\adamntds.dit
Defragmentation Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Snapshot {ce821c22-5b18-4549-855d-c0d9485cee05} unmounted.
IFM media created successfully in d:\ntds\lds-data\msres\backup\2008-01-31
ifm: q
dsdbutil: q
d:\ntds\lds-data\msres\backup>dir 2008-01-31
Volume in drive D is data
Volume Serial Number is 9C7F-B0BB
Directory of d:\ntds\lds-data\msres\backup\2008-01-31
31/01/2008 12:47 <DIR> .
31/01/2008 12:47 <DIR> ..
31/01/2008 12:47 8,404,992 adamntds.dit
1 File(s) 8,404,992 bytes
2 Dir(s) 16,386,891,776 bytes free
d:\ntds\lds-data\msres\backup>
Breakdown
In the first line I simply create a new directory for the backup. I then launch DSDBUTIL and select the AD LDS instance that I wish to work with. In this case this is called MSRES. Once I've selected the instance to work with I change into the IFM context and issue the command create full .\2008-01-31. As the present working directory is the parent to the folder in which I wish to create the snapshot I simply use .\<DIR name>. Once this has finished I quit the context and then quit the application and then issue a DIR command to list the contents of the directory. There's only one file in the directory, in this case it's an 8.01MB ESE database file called ADAMNTDS.DIT.
Aside
As an aside, I thought I'd also illustrate how the person who asked me this question actually queried for this information. Now this is actually quite interesting, as it's a royal PITA to get this information because it's binary encoded. The easiest way, in my opinion, is to use the excellent ADFIND.
Using ADFIND we can easily check for any NTDSDSA objects that have a given retired invocationID with the following [somewhat inefficient] query:
(&(objectcategory=nTDSDSA)(retiredReplDSASignatures=*\CCs\E5\27\D5\02\2CE\BE\D4\FE\AE\BE\18\8D\5B*))
To run that through ADFIND, we use the -binenc switch and pass the invocationID as a string wrapped within {{GUID:}}, like so:
d:\ntds\lds-data\msres\data>adfind -h .:50389 -config -binenc -f "&(objectCategory=nTDSDSA)
(retiredReplDSASignatures=*{{GUID:27E573CC-02D5-452C-BED4-FEAEBE188D5B}}*)" -dn
AdFind V01.37.00cpp Joe Richards (
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
) June 2007
Transformed Filter: &(objectcategory=nTDSDSA)(retiredReplDSASignatures=
*\CCs\E5\27\D5\02\2CE\BE\D4\FE\AE\BE\18\8D\5B*)
Using server: rodc.idmgmt.int:50389
Directory: Windows Longhorn
Base DN: CN=Configuration,CN={B07EC3B1-ABF4-4050-8889-DC8FC1AEE18B}
dn:CN=NTDS Settings,CN=RWDC$msres,CN=Servers,CN=Default-First-Site-Name,
CN=Sites,CN=Configuration,CN={B07EC3B1-ABF4-4050-8889-DC8FC1AEE18B}
dn:CN=NTDS Settings,CN=RODC$msres,CN=Servers,CN=Default-First-Site-Name,
CN=Sites,CN=Configuration,CN={B07EC3B1-ABF4-4050-8889-DC8FC1AEE18B}
2 Objects returned
d:\ntds\lds-data\msres\data>
Note. linebreaks have been added for "readability" purposes. Each command is a single line.
The other likely way was to have stumbled across this info. when using REPADMIN /SHOWSIG as I did earlier, to illustrate an IFM-installed replica's retired invocationID.
|
