Using Repadmin with ADLDS and Lingering objects

First published on TechNet on Nov 06, 2015


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 .

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 Domain and they replicate a partition called


LDS1 runs ADLDS on port 50002.
RootDC1 runs ADLDS on port 51995.

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


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


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


So this tells me that according to localhost:51995 ,


partition is between Server LDS1$instance1 and server ROOTDC1$instance1.


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 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



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


switch allows you to specify an ADLDS server:port.

For example, If you want to get 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


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:[ 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,


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 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

“Outdated 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 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


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






is the LDS instance and port where to remove lingering objects


is DSA guid of a good LDS server/instance


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.



This article was originally published by Microsoft's Directory Services Team. You can find the original article here.