The server network address “TCP://ServerName.abc.local:5022″ cannot be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (Microsoft SQL Server, Error: 1418)

Reason behind Error 1418

Main reason behind database mirroring error 1418 is because the specified server network address cannot be reached or does not exist. The server network address cannot be reached because of multiple reasons. Some of them are given below.

• Principal, Mirror and Witness servers are not talking to each other.
• Wrong network address name, mirror server instance name or port number.
• Mirror database is not ready for mirroring.
• Principal or mirror server instance is behind a firewall.
• You are using local system account to run SQL Server services and not using certificates for authentication.
• SQL Server services are running with different domain accounts on Principal and Mirror server and service accounts don’t have enough permission on endpoints.
• Different endpoint encryption value set on Principal, Mirror and Witness server.
• Endpoints are not started on the partner servers.
• Principal server instance is not listening on the port assigned to its database mirroring endpoint.

We need to verify each option mentioned above carefully to fix this error.

Solution

The solution of this issue may vary case to case depending on the nature of issue. To fix this issue we need to find out the main root cause behind error 1418. The root cause may be anything that is given in above section. Here I will describe each probable reason given above and its solution to fix this issue. Make sure to go through with each point given in this article.

Principal, Mirror and Witness Servers Should be Accessible

Make sure that SQL Server Instances installed on Principal, Mirror & Witness servers are accessible to each other. If remote login for any SQL Server instance is not enabled then you might get this issue. You can enable remote connectivity by enabling TCP/IP and Named Pipes protocols in SQL Server Configuration Manager. Each system must access the ports of the other SQL Server instances over TCP. You can try telnet the SQL Server ports of other partners.

Verify Correct System Details 

Sometimes we entered wrong details that end up with throwing errors. Make sure to verify the network address name, mirror server instance name and its port numbers are correct. You can recheck all the details whether you have entered them correctly or not.

Mirror Database Preparation

Verify that the mirror database is ready for database mirroring. We should prepare mirror database before configuring or during configuring database mirroring. It is suggested to keep identical drive path for mirror database files. Below are the steps you should take care for preparing your mirroring database.

• Run full backup and subsequent transactional log backup of the Principal database and copy it to the Mirror server.
• Restore database with same name in norecovery state on Mirror server with the copied backup files from above step. You must ensure that restored database on mirror server should be in restoring mode before starting database mirroring configuration.

Firewall/Ports

One of the probable reason to get error 1418 is partner servers are behind firewall. Make sure that the principal server instance and destination mirror server instance is not behind a firewall and they should talk to each other. Principal server, Mirror server and witness server should be accessible to each other.

Verify that SQL Server port and endpoint ports are enabled and accessible via telnet. If not or you are not able to telnet any of the partner instance from any server participating in mirroring then you should ask your network admins to open these ports to establish the connectivity over given port.

Endpoints

Make sure that endpoint has been created on principal, mirror and witness servers. Verify that the endpoints are started on each partner server instances. You can check endpoint status by running below T-SQL query on each instance.

SELECT state_desc FROM sys.database_mirroring_endpoints

If either endpoint is not started, execute below ALTER ENDPOINT statement to start it.

#Change the name of your endpoints. Here endpoint name is Mirroring
ALTER ENDPOINT Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT = <port_number>)
FOR database_mirroring (ROLE = ALL);
GO

Recheck that the principal server instance is listening on the port assigned to its database mirroring endpoint and the mirror server instance is listening on its port. If a partner is not listening on its assigned port, modify the database mirroring endpoint to listen on a different port.

Sometimes this issue got fixed by dropping the existing endpoint and recreate it again on partner servers.

Service Accounts

Do not use local system account to run SQL Server services. If you don’t have any choice and want to use local system then ensure to use certificates for authentications.

Make sure that service accounts that you are using to run SQL Server services must have CONNECT permission to mirroring endpoints. Also, if you are configuring database mirroring between two domains then the login of one account must be created in master database on the other computer, and that login must be granted CONNECT permissions on the endpoint.

It’s always advisable to use same service accounts to run SQL Server services on all three Instances on Principal, Mirror and Witness server.

You can comment us your experience about fixing this issue. We will update this article with your solution that you have used to fix this issue.

I hope you like this article. Please follow us on our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 15141: The server principal owns one or more endpoints and cannot be dropped
• Fix AOAG Error 35250: Joining database on Secondary Replica resulted in an error
• How to Upgrade or Patch Availability Group Instances?
• SQL Server Always On Interview Questions and Answers

The post Fix Error 1418: The server network address cannot be reached or does not exist. appeared first on Techyaz.com.

Microsoft SQL Server Error 35250

We generally get this error whenever there is a communication issue between endpoints of both replicas or any replica unable to connect to the endpoints cause this error to generate. You will see below error texts if you are getting this issue.

Alwayson Error 35250
Failed to Join the database ‘DBName’ to the availability group ‘AOAG-Name’ on the availability replica ‘Availability Replica Name’

There are many reasons behind this error that we will discuss in next section. You might also get below text if you are using T-SQL.

Below is the screenshot of this error.

Solution

You should check below points based on attached article MSDN link whenever you get this error.

• Inbound Port 5022 Traffic is Blocked
• Endpoint is not created or started
• Endpoint permissions
• SQL Server is not listening on port 5022

But if everything is ok and you are still not able to diagnose this issue, then you should keep reading this article.

I checked everything and all was well on both replicas.  As we know that there should be Grant CONNECT permission on Always On endpoint. I was reassigning GRANT CONNECT on the endpoint and came to know that the SQL Server service account was not added to the SQL Server instance of secondary replica. That is why we faced this error. Let’s first get the endpoint and then we will run Grant connect on endpoint to see the issue. Run below command to get the name of endpoint that is using in this alwayson configuration.

We can see endpoint name is hadr_endpoint. Now run below command to grant connect permission on endpoint hadr_endpoint. The login name is the service account that is used to run SQL Server services.

You can see, error is saying that the account doesn’t exist on SQL Server.

Although you can directly check this step in SSMS as a prerequisite once error is reported. The SQL Server service accounts should be added to SQL Server Instances. I checked this account on both replica and found that it was very much there on primary replica but it was not created on secondary replica. That was the missing point which caused this issue.

Now create this service account on secondary replica as well or where it was missing on any of the replica then you can try to re-add the database to the AOAG configuration. This time your database will be added to the AOAG configuration. If you are facing issue during joining database to the AOAG configuration then you can remove the existing AOAG and reconfigure it.

Your issue will be fixed if you check and follow all above suggested points including the one mentioned in MSDN link. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Fix AOAG Error 976:Cannot Connect to Secondary Replica
• How to fix AOAG Listener Issue 19471: The handle is Invalid
• Fix Listener Issue that came during AOAG Configuration
• How to fix Error 15141: The Server Principal owns one or more endpoints
• Fixing Application connectivity Issue after AOAG automatic failover

The post SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error appeared first on Techyaz.com.