Replicating to remote subscribers/servers

  • I am running SQL Server 7.0 SP4 on NT 4. I have two remote servers (same platforms) I am trying to establish replication to. The Publisher/Distributor is local. The error message I receive is:

    Msg 14151, Sev 18: Replication-Distribution: agent SERVER1-DATABASE1-REMOTESERVER2-x failed. The process could not connect to Subscriber 'REMOTESERVER2'. NOTE: The step was retried the requested

    number of times (10) without succeeding. The step failed. [SQLSTATE

    42000]

    The three servers (1 local, 2 remote) are in different domains. I have not verified whether there are trusts between them. I've tried to modify each Distribution Agent to connect using the 'sa' login to the remote server, my own id (which has 'sa' permissions) or the local server's SQL Server Agent's Service startup account (domain admin. account). All three ways receive the same error -- failure to connect.

    Do I need to setup an NT domain account (with the same name/permissions as the local domain) on the remote domains? Do I have to have Trusts established -- bi-directional? I found a MS article (#Q160563) for SQL 6.5 that sort of implies such.

    Thank you for any information leading to the resolution of this error!

  • To enable SQL autentication in your replication, you should especified in the distribution agent job this parameters:

    -DistributorSecurityMode 0

    -DistributorLogin sa

    -DistributorPassword pass

    -SubscriberSecurityMode 0

    -SubscriberLogin sa

    -SubscriberPassword pass

    Check to see in all servers the same sa password.

  • Thanks, that gets around NT Auth. issues but didn't seem to help (whether both 'sa' passwords are the same or not). I still get "The process could not connect to Subscriber 'REMOTESERVER2'." and an ODBC error 08001 - "Client unable to establish connection." (Same as before.)

    Here is the Distributor command string:

    -Subscriber [REMOTESERVER2] -SubscriberDB [REMOTEDB] -Publisher [LOCALSERVER1] -Distributor LOCALSERVER1 -DistributorSecurityMode 0 -PublisherDB [LOCALDB] -LoginTimeout 60 -DistributorLogin sa -DistributorPassword sapswd -SubscriberSecurityMode 0 -SubscriberLogin sa -SubscriberPassword sapswd

    I do not receive any login failures on the Subscriber side (errorlog). What else can I check?

  • From your local server, create a linked server to the remote and try to execute a query like

    select * from remoteserver.master.dbo.sysdatabases,

    and tell if you could do it or not.

  • Yes - to both servers.

    When the subscriptions were created, there were Remote Servers defined/created by Replication. The Properties state: Map All Remote Logins To <Same Name>. The Check Password box is unchecked. The RPC box is checked.

  • One thing I've found is that a third Subscriber (local, same domain, etc.) that is functioning correctly has the presence of a table "Msreplication_subscriptions". This table does not exist in the two Subscribers where I am having the connection problems. I am not sure what the presence or non-presence of this table indicates but that is a noticeable difference and makes me scratch my head as to whether the two remote subscriptions have been defined correctly. I have dropped and readded them several times. No difference. Changed IDs several times, using NT authentication and then SQL authentication. Again, no difference.

    Any ideas as to what that "simple little detail" is that I may be overlooking? That's what I'm expecting the outcome to be. 🙂

    Thanks

  • After thinking about it, the table does not exist probably because the Distribution Agent cannot connect in order to create the table. It is a system table. So, I'm back to square one. Why can't the Agent connect.

  • I have called microsoft about a similar situation. In my situation the SQLSERVER AGENT login name does not have rights on the other domain. I generally get around the problem now by creating an account that has admin rights on all the domains

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply