Using Repadmin with ADLDS and Lingering objects
Hi! Linda Taylor here from the UK Directory Services escalation team. This time on ADLDS, Repadmin, lingering objects and even PowerShell….
The other day a colleague was trying to remove a lingering object in ADLDS. He asked me about which repadmin syntax would work for ADLDS and it occurred to us both that all the documented examples we found for repadmin were only for AD DS.
So, here are some ADLDS specific examples of repadmin use.
For the purpose of this post I will be using 2 servers with ADLDS. Both servers belong to Root.contoso.com Domain and they replicate a partition called DC=Fabrikam.
1. Who is replicating my partition?
If you have many servers in your replica set you may want to find out which ADLDS servers are replicating a specific partition. ….Yes! The AD PowerShell module works against ADLDS.
You just need to add the :port on the end of the servername.
One way to list which servers are replicating a specific application partition is to query the attribute msDs-MasteredBy on the respective partition. This attribute contains a list of NTDS server settings objects for the servers which replicate this partition.
You can do this with ADSIEDIT or ldp.exe or PowerShell or any other means.
Powershell Example: Use the Get-ADObject comandlet and I will target my command at localhost:51995. (I am running this on RootDC1)
Notice there are 2 NTDS Settings objects returned and servername is recorded as ServerName$ADLDSInstanceName.
So this tells me that according to localhost:51995 , DC=Fabrikam partition is replicated between Server LDS1$instance1 and server ROOTDC1$instance1.
2. REPADMIN for ADLDS
Generic rules and Tips:
- For most commands the golden rule is to simply use the port inside the DSA_NAME or DSA_LIST parameters like lds1:50002 or lds1.contoso.com:50002. That’s it!
For example:
- There are some things which do not apply to ADLDS. That is anything which involves FSMO’s like PDC and RID which ADLDS does not have or Global Catalog – again no such thing in ADLDS.
- A very useful switch for ADLDS is the /homeserver switch:
Usually by default repadmin assumes you are working with AD and will use the locator or attempt to connect to local server on port 389 if this fails. However, for ADLDS the /Homeserver switch allows you to specify an ADLDS server:port.
For example, If you want to get replication status for all ADLDS servers in a configuration set (like for AD you would run repadmin /showrepl * /csv), for ADLDS you can run the following:
Repadmin /showrepl /homeserver:localhost:50002 * /csv >out.csv
Then you can open the OUT.CSV using something like Excel or even notepad and view a nice summary of the replication status for all servers. You can then sort this and chop it around to your liking.
The below explanation of HOMESERVER is taken from repadmin /listhelp output:
| If the DSA_LIST argument is a resolvable server name (such as a DNS or WINS name) this will be used as the homeserver. If a non-resolvable parameter is used for the DSA_LIST, repadmin will use the locator to find a server to be used as the homeserver. If the locator does not find a server, repadmin will try the local box (port 389). The /homeserver:[dns name] option is available to explicitly control home server selection. This is especially useful when there are more than one forest or configuration set possible. For example, the DSA_LIST command "fsmo_istg:site1" would target the locally joined domain's directory, so to target an AD/LDS instance, /homeserver:adldsinstance:50000 could be used to resolve the fsmo_istg to site1 defined in the ADAM configuration set on adldsinstance:50000 instead of the fsmo_istg to site1 defined in the locally joined domain. |
Finally, a particular gotcha that can send you in the wrong troubleshooting direction is a LDAP 0x51 “server down” error which is returned if you forget to add the DSA_NAME and/or port to your repadmin command. Like this:
3. Lingering objects in ADLDS
Just like in AD, you can get lingering objects in AD LDS .The only difference being that there is no Global Catalog in ADLDS, and thus no lingering objects are possible in a Read Only partition.
EVENT ID 1988 or 2042:
If you bring an outdated instance (past TSL) back online In ADLDS you may see event 1988 as per https://support.microsoft.com/kb/870695/EN-US “Outdated Active Directory objects generate event ID 1988”.
On WS 2012 R2 you will see event 2042 telling you that it has been over TombStoneLifetime since you last replicated so replication is disabled.
What to do next?
First you want to check for lingering objects and remove if necessary.
1. To check for lingering objects you can use repadmin /removelingeringobjects with the /advisory_mode
My colleague Ian Farr or “Posh chap” as we call him, recently worked with a customer on such a case and put together a great PowerShell blog with a One-Liner for detecting and removing lingering objects from ADLDS with PowerShell. Check it out here:
Example event 1946:
2. Once you have detected any lingering objects and you have made a decision that you need to remove them, you can remove them using the same repadmin command as in Iain’s blog but without the advisory_mode.
Example command to remove lingering objects:
| Repadmin /removelingeringobjects lds1:50002 8fc92fdd-e5ec-45fb-b7d3-120f9f9f192 DC=Fabrikam |
Where Lds1:50002 is the LDS instance and port where to remove lingering objects
8fc92fdd-e5ec-45fb-b7d3-120f9f9f192 is DSA guid of a good LDS server/instance
DC=Fabrikam is the partition where to remove lingering objects
For each lingering object removed you will see event 1945.
You can use Iain’s one-liner again to get a list of all the objects which were removed.
As a good practice you should also do the lingering object checks for the Configuration partition.
Once all lingering objects are removed replication can be re-enabled again and you can go down the pub…(maybe).
I hope this is useful.
Linda.
Comments
- Anonymous
November 06, 2015
The comment has been removed