Getting SQL Server error 1418: mirroring endpoint fix
Solved Email & Outlook
BA
Barry Allen
October 5, 2017
2 replies
7,460 views
Reviewed by moderators

Setting up database mirroring between two servers and the ALTER DATABASE SET PARTNER step fails with error 1418, the server network address cannot be reached or does not exist.

Both machines ping each other fine. What is 1418 actually checking that ping does not?

Accepted Answer
Verified by David Taylor, Database Expert ยท Reviewed October 2017

Ping proves the machines see each other, 1418 fails because the mirroring endpoints do not: specific ports, specific listeners, specific permissions, none of which ICMP touches. The checklist that finds the break, in the order it usually breaks:

1
Endpoints exist and listen on both servers: SELECT name, state_desc, port FROM sys.tcp_endpoints WHERE type_desc = 'DATABASE_MIRRORING' on each. Missing means CREATE ENDPOINT Mirroring STATE = STARTED AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING (ROLE = PARTNER), stopped means ALTER ENDPOINT to STARTED. Confirm the OS agrees with netstat -an finding the port LISTENING.
2
The port crosses the network: from each server, Test-NetConnection otherserver -Port 5022 in PowerShell. Ping succeeding while this fails convicts a firewall, add an inbound rule for the endpoint port on both Windows firewalls and whatever sits between the machines.
3
The service accounts may connect: the account running SQL Server on each machine needs CONNECT on the other's endpoint. Domain accounts get GRANT CONNECT ON ENDPOINT::Mirroring TO [DOMAIN\sqlaccount], machines running as local defaults like NT Service accounts cannot authenticate across, either switch the services to domain accounts or create certificate authentication for the endpoints.
4
The SET PARTNER string matches reality: fully qualified TCP://server.domain.com:5022 with the FQDN the servers resolve, the exact port from step one, and the sequence rule that the mirror runs its SET PARTNER first, then the principal. Rerun after the fixes, 1418 clears the moment all four hold.

When all four check out and 1418 persists, the residue is usually name resolution inconsistency, one server resolving the FQDN to an address the other does not answer mirroring on, a multi homed machine or stale DNS, visible by comparing what the FQDN resolves to on each side against where the endpoint actually listens. And a placement note rather than a fix: mirroring has been deprecated in favor of Availability Groups since 2012, sturdy where it already runs, but new deployments in 2017 deserve the AG conversation first.

Step three was the break, both services ran as NT Service defaults. Switched to domain accounts, granted CONNECT both ways and SET PARTNER succeeded on the next attempt. The AG note is heard, this mirror is a stopgap with a documented expiry now.