banshee is under active development: collectors will keep changing, and a version you publish will likely need adjustments. For stable use, wait for version 1.0.0.

Active Directory

banshee/active-directory-collection/active-directory/winrm/

replication

The inbound Active Directory replication of a domain controller: failures and lag per partner and partition, by WinRM and PowerShell

  • active-directory
  • domain-controller
  • replication
  • winrm
  • powershell

by banshee1 installation2 versions

v2Latest

Published on October 28, 2026. One naming convention across collections; documentation completed.

Active Directory replication, by WinRM

Returns, for each partner a domain controller replicates from and each partition it replicates, the failures since the last success, the result of the last attempt and the minutes since the last success. Three watches are proposed; the first two, checked, raise on a failing link and on a late one.

Versions

A domain controller running Windows Server 2012 or later, with Windows PowerShell 3.0 or later, as the prerequisites name them. Generic: no folder of version. That every release answers alike is assumed, not yet checked on a real domain controller.

How it works

The collector runs one PowerShell script, by WinRM, that reads the inbound replication partners of the domain controller through the classes of .NET that Microsoft documents:

$ErrorActionPreference = 'Stop'; [Console]::OutputEncoding = New-Object System.Text.UTF8Encoding; $computer = Get-CimInstance Win32_ComputerSystem; $server = $computer.DNSHostName + '.' + $computer.Domain; $context = New-Object DirectoryServices.ActiveDirectory.DirectoryContext('DirectoryServer', $server); $dc = [DirectoryServices.ActiveDirectory.DomainController]::GetDomainController($context); $now = Get-Date; $links = @($dc.GetAllReplicationNeighbors() | ForEach-Object { @{source = $_.SourceServer; partition = $_.PartitionName; failures = $_.ConsecutiveFailureCount; result = $_.LastSyncResult; minutes = [long]($now - $_.LastSuccessfulSync).TotalMinutes} }); ConvertTo-Json -Compress -Depth 4 -InputObject @{links = $links}
  • WinRM hands the script to PowerShell itself: the script is the one of active-directory/ssh/replication, without the powershell -Command "…" that cmd.exe needs there.
  • DomainController.GetAllReplicationNeighbors returns one ReplicationNeighbor per partner and partition (Microsoft, .NET, System.DirectoryServices.ActiveDirectory): the domain, the configuration, the schema and the application partitions (DomainDnsZones, ForestDnsZones) the domain controller holds. It is the same information as repadmin /showrepl.
  • A link is named <partner>/<partition>: dc02.corp.example/DC=corp,DC=example. A partner whose server object was deleted is named (deleted partner).
  • failures is ConsecutiveFailureCount, the failures since the last successful replication cycle; result is LastSyncResult, the Windows error code of the last attempt, 0 when it succeeded, to look up in the system error codes of Windows.
  • lag is the minutes since LastSuccessfulSync, counted on the domain controller: .NET gives that time in the local time of the domain controller, and the script compares it with the local time of the same clock. A link that never succeeded gives a lag of several centuries.
  • No inbound partner at all stops the collector as misconfigured: a domain with a single domain controller has no replication to watch. An answer that is not the expected JSON stops it as misconfigured too.

Nothing is written to the Windows or to the directory: the script only reads, and triggers no replication.

Prerequisites

  • A domain controller running Windows Server 2012 or later, with Windows PowerShell 3.0 or later.
  • The WinRM service listening in HTTPS, on TCP 5986 or the port set in protocol:winrm:port, open in the Windows firewall to the poller, with a certificate the poller judges by the TLS profile of the probe or pins in protocol:winrm:fingerprint: the steps are those of the windows/winrm/services collector of banshee/windows-collection. NTLM authentication, which the WinRM service accepts as installed.
  • An account of the domain for monitoring, without administrator rights, set in protocol:winrm:user (DOMAIN\account or account@domain) with its password in protocol:winrm:password, member of the group "Remote Management Users" of the domain (on a domain controller, the built-in group of the Builtin container). No other group is given here: Microsoft does not document the right DsReplicaGetInfo, under GetAllReplicationNeighbors, asks for (see Limits).

Outputs

NameLabelUnitPer instance
failuresFailures since the last success—yes, per link
resultResult of the last attempt—yes, per link
lagSince the last successminyes, per link

Watches

NameTitleKindDefaultsChecked by default
failingReplication failinghigh threshold, on failureswarning above 0, critical above 2yes
lateReplication latehigh threshold, on lagwarning above 360 min, critical above 1440 minyes
missingReplication link missingexpected instances, on failuresno link named: it raises nothing until names are set on the probeno

Replication inside a site follows each change within minutes; between sites, it follows the schedule of the site link, every 180 minutes by default. A forest whose site links replicate less often raises "Replication late" until its thresholds are set on the probe. dcdiag reports a latency above 12 hours in its Replications test (Microsoft, "dcdiag"); the critical default is 24 hours.

Limits

  • Only the inbound side is read: a partner that does not take the changes of this domain controller is seen on that partner.
  • Not yet checked on a real domain controller: the execution; that an account without administrator rights may read the replication partners (Microsoft documents no right for DsReplicaGetInfo; repadmin /showrepl is commonly run without one). If it may not, the collector stops as misconfigured with the error of Windows, and the account needs the right to be given; it is never a reason to use an administrator.