Replication Monitor fails with "requires actual server name" when Distributor is on Always On AG registered via Listener Name — SQL Server 2022

Don Ferguson 0 Reputation points
2026-07-14T01:09:46.5633333+00:00

Environment:

  • SQL Server 2022 RTM-CU22 (KB5068450) - 16.0.4225.2 (X64)
  • SSMS 19.x and 20.7.0 (tested both — same behavior on each)
  • Publisher: PUBLISHER_HOST (standalone, default instance)
  • Publisher Database: PUBLISHER_DB
  • Distributor: Hosted on Always On Availability Group
    • AG Listener Name: DIST_LISTENER
    • Distributor Instance: DIST_INSTANCE
    • Full Listener+Instance: DIST_LISTENER\DIST_INSTANCE
    • Physical Node 1: DIST_NODE1\DIST_INSTANCE
    • Physical Node 2: DIST_NODE2\DIST_INSTANCE
    • Non-default port in use
    • SQL aliases configured via cliconfg.exe (both 32-bit and 64-bit) on all relevant servers mapping: DIST_LISTENER → DIST_LISTENER,<port> DIST_LISTENER\DIST_INSTANCE → DIST_LISTENER,<port>

SETUP FOLLOWED:

Microsoft documentation for configuring distribution on an

Always On Availability Group was followed:

https://learn.microsoft.com/en-us/sql/relational-databases/replication/

configure-distribution-availability-group

Per that documentation, sp_adddistributor was called using the

AG listener name:

EXEC sp_adddistributor 

    @distributor = N'DIST_LISTENER\DIST_INSTANCE',

    @password    = N'[password]';

sp_helpdistributor output confirms:

  • distributor column shows: DIST_LISTENER\DIST_INSTANCE
  • distribution_listener column shows: DIST_LISTENER ← Correctly set

repl_distributor linked server:

  • data_source points to: DIST_LISTENER,<port>
  • provider: MSOLEDBSQL

On the distributor nodes, server properties confirm:

@@SERVERNAME                         = DIST_NODE1\DIST_INSTANCE

SERVERPROPERTY('MachineName')        = DIST_NODE1

SERVERPROPERTY('ServerName')         = DIST_NODE1\DIST_INSTANCE  

SERVERPROPERTY('PhysicalNetBIOS')    = DIST_NODE1

REPLICATION STATUS:

Replication is fully functional:

  • Log Reader Agent: running successfully
  • Distribution Agent: running successfully
  • Data flowing correctly to all subscribers
  • All agent jobs running without error
  • sp_testlinkedserver 'repl_distributor' succeeds
  • Replication has survived AG failover correctly

THE PROBLEM:

Replication Monitor (RepMon) in SSMS fails to connect to the

distributor. This is purely a monitoring/RepMon issue —

replication itself is healthy.

When attempting to register the publisher in RepMon the

following sequence occurs:

STEP 1:

RepMon displays this informational prompt:

"Status information for Publisher 'PUBLISHER_HOST' is stored

at its Distributor, 'DIST_LISTENER\DIST_INSTANCE'. In the

following dialog box, specify how Replication Monitor should

connect to the Distributor."

Clicking OK produces a Connect to Server dialog where:

  • Server Name field shows: DIST_LISTENER\DIST_INSTANCE
  • Server Name field is GRAYED OUT — cannot be changed

STEP 2:

Clicking Connect produces this error:

TITLE: Connect to Server

"Cannot connect to DIST_LISTENER\DIST_INSTANCE.

SQL Server replication requires the actual server name to

make a connection to the server. Specify the actual server

name, ''. (Replication.utilities)"

Note: The quotes at the end of the error message are EMPTY.

No physical server name is being returned to populate

the error message.

ROOT CAUSE ANALYSIS:

The error originates from a validation check in

Replication.utilities that compares the connection target

against @@SERVERNAME:

RepMon connection target: DIST_LISTENER\DIST_INSTANCE

                          ↑ AG listener name

@@SERVERNAME on distributor: DIST_NODE1\DIST_INSTANCE

                            ↑ Physical node name

DIST_LISTENER ≠ DIST_NODE1 → Validation fails → Error thrown

The empty quotes in the error message suggest that when

Replication.utilities attempts to retrieve the physical

server name to populate the error message, it is either:

  • Unable to complete enough of the connection to retrieve it
  • Receiving an unexpected response through the listener

This creates a direct conflict between two Microsoft requirements:

CONFLICT:

┌─────────────────────────────────────────────────────────────┐

│ Microsoft AG Distributor documentation states: │

│ → Register distributor using the AG listener name │

│ │

│ Replication.utilities validation requires: │

│ → Connection name must match @@SERVERNAME (physical name) │

│ │

│ These two requirements are mutually exclusive │

│ in the current implementation │

└─────────────────────────────────────────────────────────────┘

The Replication.utilities validation logic appears to predate

Always On availability groups and does not appear to have been

updated to recognize AG listener names as valid distributor

connection targets.

ADDITIONAL CONTEXT:

  • MSredirected_publishers was examined — sp_redirect_publisher is not applicable in this scenario as the publisher is a standalone instance, not in an AG
  • The distribution_listener column in MSdistributor_properties is correctly populated with DIST_LISTENER, confirming that the AG-aware distributor configuration was applied
  • Both 32-bit and 64-bit SQL aliases are correctly configured on all servers involved (publisher, distributor nodes, subscriber nodes)
  • This was tested on SSMS 19.x and SSMS 20.7.0 with identical results, ruling out an SSMS version-specific bug

SPECIFIC QUESTIONS:

  1. BUG OR BY DESIGN? Is the failure of Replication.utilities to accept an AG listener name as a valid distributor connection a known bug with a fix in a future CU, or is it by design?
  2. DOCUMENTATION CONFLICT: If the correct approach is actually to register the distributor using the physical node name rather than the listener name, this directly contradicts the current Microsoft documentation at the link above. The documentation should be updated to reflect the correct procedure.
  3. FAILOVER SAFETY: If registering with the physical node name is the correct approach, is there documented confirmation that SQL Server will correctly redirect all distributor connections through the AG listener after a failover — specifically using the repl_distributor linked server listener reference rather than falling back to the registered physical node name? This confirmation is critical before making any changes to a production replication environment.
  4. SUPPORTED CONFIGURATION: What is the fully supported configuration that satisfies ALL of the following simultaneously: a) Distributor hosted on AG with listener-based connectivity b) Replication agents function correctly post-failover c) Replication Monitor functions correctly in SSMS d) Non-default port with alias-based resolution At this time conditions (a), (b) and (d) are all met. Only condition (c) is failing.
SQL Server Database Engine
0 comments No comments

Answer recommended by moderator
Don Ferguson 0 Reputation points
2026-07-14T17:00:31.7833333+00:00

UPDATE / RESOLUTION FOUND:

After extensive troubleshooting, a working path has been discovered

that allows Replication Monitor to connect successfully without any

configuration changes.

THE WORKAROUND:

The key is HOW you add the publisher to Replication Monitor.

TRADITIONAL METHOD (fails in this configuration):

  1. Open Replication Monitor in SSMS
  2. Right-click Replication Monitor → "Add Publisher"
  3. Enter the Publisher name directly
  4. RepMon retrieves the distributor name from publisher metadata
  5. RepMon attempts to connect to distributor via that name
  6. Hits Replication.utilities physical name validation
  7. Throws: "SQL Server replication requires the actual server name to make a connection to the server. Specify the actual server name, ''"
  8. ❌ Fails

WORKING METHOD (connect through distributor first):

  1. Open Replication Monitor in SSMS
  2. Right-click Replication Monitor → "Add Publisher"
  3. Instead of entering the Publisher name directly, select the option to connect via the Distributor
  4. Connect directly to the Distributor listener: [ListenerName\InstanceName] or [ListenerName,Port]
  5. Publishers registered to that distributor appear automatically
  6. Add the publisher from that list
  7. ✅ Replication Monitor connects and displays successfully

WHY THIS WORKS:

When connecting through the distributor directly, RepMon never

has to resolve the distributor name FROM the publisher's metadata.

This bypasses the Replication.utilities validation path that

compares the connection target name against @@SERVERNAME on the

distributor node.

When adding the publisher directly (traditional method), the

following conflict occurs:

Publisher metadata returns distributor as:

  [ListenerName\InstanceName]

Replication.utilities then validates by comparing:

  Connection target:    [ListenerName\InstanceName]  

  @@SERVERNAME on node: [PhysicalNodeName\InstanceName]

  These don't match → error thrown

IMPORTANT NOTES:

  • This was tested on SQL Server 2022 (RTM-CU22) (KB5068450) 16.0.4225.2 (X64)
  • Tested with SSMS 19.x and SSMS 20.7.0
  • Replication was configured per Microsoft documentation with the distributor registered using the AG listener name
  • No changes to the underlying replication configuration were required — this is purely a RepMon entry point difference

UNDERLYING ISSUE STILL EXISTS:

While this workaround is effective, the root conflict between:

  1. Microsoft AG Distributor documentation requiring the listener name in sp_adddistributor AND
  2. Replication.utilities requiring connections to match @@SERVERNAME (physical node name)

...remains unresolved at the product level. The traditional

publisher-first entry path in Replication Monitor does not

work in this configuration and gives a misleading error message

with no guidance toward this workaround.

It would be beneficial for Microsoft to either:

  • Update Replication.utilities validation to correctly handle AG listener names as valid distributor targets
  • Update SSMS Replication Monitor documentation to note that when the distributor is hosted on an AG, publishers should be added via the distributor connection path rather than the traditional publisher-first path
  • Improve the error message to indicate the actual cause and suggest the distributor-first workaround

Hopefully this saves someone else the extensive troubleshooting

this required to discover.

Was this answer helpful?

0 comments No comments

0 additional answers

Sort by: Newest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.