Ports and diagnostic collection

Match the port to the operation

Use this table to find the next test. Firewall rules depend on which machines need to talk: member-to-DC, DC-to-DC and cross-forest traffic have different requirements. Older systems and fixed RPC ports can change the list too. Microsoft’s AD firewall guide covers the endpoints and direction.

A TCP test answers one small question

Test-NetConnection -ComputerName 'dc1.contoso.com' -Port 135
Test-NetConnection -ComputerName 'dc1.contoso.com' -Port 389
Test-NetConnection -ComputerName 'dc1.contoso.com' -Port 9389

TcpTestSucceeded establishes that a TCP connection could be made from this machine at this time. It does not verify UDP, authenticate, test certificate trust, query a naming context or confirm the dynamic RPC endpoint returned by port 135. Follow the port test with the actual failed operation.

If LDP works and Get-ADUser fails, check ADWS and its authentication path. If LDAP searches work while replication fails with RPC unavailable, inspect endpoint mapping and the selected dynamic port from the destination DC to its source.

For ADWS, the -Server host:port value selects the directory instance behind the web service. It does not tell the cmdlet to open direct LDAP to that port. A mounted snapshot can be available through direct LDAP while ADWS on the same host is stopped or does not expose the instance. Microsoft’s server/port reference explains that extra hop.

Test from the participant that is failing

For replication, test from the destination toward its source. For a logon or policy failure, use the affected client’s network and identity. A successful test from your workstation in the datacenter won’t tell you whether the branch client can connect.

Keep name resolution with the test: target name, resolved address, selected protocol and actual remote endpoint. A test by IP can help isolate routing but can change authentication behavior, so a successful IP connection does not prove the original FQDN/SPN-based request will work.

Resolve the RPC endpoint, then test it

With Microsoft’s optional PortQry tool available, an active endpoint-mapper query is:

portqry.exe -n dc2.contoso.com -p tcp -e 135

Find the interface for the failed operation. Directory replication uses the DRS interface UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2. Take its ncacn_ip_tcp endpoint and test that TCP port from the failing destination. The port may be fixed or dynamically selected, so check the current answer before putting a number from old output into a firewall rule.

If the endpoint mapper replies but the DRS interface is absent, opening a larger firewall range will not register a missing service. If it returns an endpoint that cannot be reached, investigate that second connection. Microsoft’s endpoint-error procedure and PortQry reference explain the distinction.

UDP LISTENING or FILTERED is ambiguous when the tool cannot elicit a recognized service response. Do not interpret it as proof of a working LDAP locator exchange, DNS query or NTP sample. Use the protocol operation and its actual response.

Save events for the incident window

Get-WinEvent -ComputerName 'dc1.contoso.com' -FilterHashtable @{
    LogName = 'Directory Service'
    StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,LevelDisplayName,Message

Save the original EVTX if you’ll need event XML or provider fields later. Keep collection failures too: failing to read a remote log doesn’t mean the event never happened. Use timestamps to line up the client, DC and network records.

Message text is useful for reading, but automation should inspect the event’s named XML fields rather than fixed word positions in a localized sentence. Also retain provider, event version, record ID, computer and UTC TimeCreated. Two providers can use the same numeric event ID for unrelated events. Get-WinEvent’s reference covers structured filtering and saved-log queries.

Read the current diagnostic levels

On a DC, in an elevated session:

$diagnostics = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
Get-ItemProperty -LiteralPath $diagnostics

Categories include KCC, replication, garbage collection, LDAP interface, global catalog and field engineering. AD LDS uses its instance service’s diagnostics path. The numbers in the names identify categories; the values control verbosity.

Pick the category you need and save its previous value. Raising everything to 5 can fill the logs and bury the event you’re looking for. The required level depends on the problem: event 1644 query collection specifically uses Field Engineering level 5 with appropriate thresholds. Follow the category-specific steps in Microsoft’s diagnostic logging procedure.

Record and undo the collection change

For every diagnostic change, save the previous value, target, purpose, collection start/end and restoration result. Increase log capacity before a high-volume capture, collect during the symptom and restore normal settings afterward. Include any search thresholds changed alongside the logging level.

For an expensive-query case, use LDAP query diagnosis. For authentication, use the protocol’s own events rather than assuming a generic NTDS log category explains every failure.

Build a minimal correlated trace

Capture one recognizable reproduction, with its start/end time, caller and selected DC/service. Include endpoint mapping and the connection that follows it. If names or credentials look involved, collect DNS and authentication records too; a TCP reset rarely tells you which component caused the problem.

Compare client and server captures when packets appear to disappear, accounting for clock offset and capture location. Avoid a conclusion from an isolated retransmission or a trace started after the original bind. Microsoft’s RPC troubleshooting guide describes the endpoint-mapper and dynamic-port sequence and collection methods.