Replication to DMZ - The process could not connect to Subscriber

Last Post 13 Jul 2005 06:48 AM by SQL_Jr. 5 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
RSP_SQL
New Member
New Member

--
07 Jul 2005 10:49 AM
Ok, forum, please help! After hours of trying I'm at a loss.

I am attempting to set up Transactional Replication to a DMZ server. All the ports are open and configured, sql servers registered, aliases set up, etc. Publication also set up, and Snapshot runs successfully. Finally, when I go to PUSH the subscription, I continue to get the error:
The process could not connect to Subscriber

To complicate matters, both servers on either end are clustered. I did create a local account on both servers, with same username and password, and configured it for the SQLAgent on both sides.

In the subscription properties, I use a sql authenticated account, and tried service account as well.

I set up the alias using the IP address and TCP\IP.

What am I doing wrong! Please help me.................TIA
jorge.rivera
New Member
New Member

--
07 Jul 2005 02:38 PM
Hi RSP,

The initial snap shot can´t be executed at this time in the subscriber, because you can't connect the second server, at this moment the publisher you see 2 jobs, snap shot and log reader.

I think the problems if for 2 reasons.

Security Account Used, use an domain account in the agents
The ports opened in the firewall need be opened in two ways

Location of Snapshot Files
The folder in which the snapshots are stored must be available to all Subscribers on the network. To ensure secure access to the initial snapshot files of your replicated data, it is recommended you use an explicit share instead of an administration share (for example, C$) for which you cannot grant specific permissions. The administrative share is used as a default only because it will always exist on Windows NT 4.0 and Windows 2000 (but it cannot be accessed except by an administrator account).

Testing Agent Connectivity
When implementing replication, make sure that the replication agents can communicate with all servers involved in the replication topology. One way to test agent connectivity is to log in to the required server and database using SQL Query Analyzer or osql using the same login that the replication agent will be using (or typically the login that SQL Server Agent is using).
SQL_Jr
New Member
New Member

--
08 Jul 2005 08:05 AM
I actually have a similar issue.

I have another related repl question: for two-replication does MS DTC IP address also have to be permissioned on both sides? Thx again
jorge.rivera
New Member
New Member

--
08 Jul 2005 08:34 AM
Hi SQL_jr,

in several times, i find problems due to MSDTC services, and when request acces to Network Admin, I sends all ip address configured in the cluster.
MSDTC is used for replication proccess, they need access in the Firewall

SQL_Jr
New Member
New Member

--
13 Jul 2005 06:48 AM
Hi:

I have created a local account (same login and p/w) on each side of the Replcation. I can log on to both servers with the account. Again, when I push the publication to the subscriber, I get the same error and that repl_svc (the acct i created) cannot logon to the subscriber (in the DMZ).
Mind you I only changed the SQLAgent account to reflect repl_svc, not the MSSQL account. It was mentioned that replication uses the SQLAgent (correct?)
As for the snapshot location, I'm not sure what you're talking about, since the server are not trusted and cannot access shares. Snapshot has run successfully, its the PUSH to SUBCRIBER that is failing, due to logon failure. Why is this happening? Please help!
SQL_Jr
New Member
New Member

--
14 Jul 2005 05:47 AM

We have successfully configured our environment, and wanted to share a few tips that might help you.
First, as you know, you need to create to local accounts with same name and p/w, and run SQLAgent on both sides with this account. Give the accounts the usual requirments:
    Log on as a service;
    Log on as a batch job;
    Replace a process level token;
    Adjust memory Quotes for a process;
    Act as part of the OS;
    Bypass traverse checking

Now, given the fact that they are clustered services, you must log in locally to each node and set up the account as above, and set the service account for SQLAgent on each side. On the active ownership node, recycle the sqlagent service via the Cluster Administrator, Take Offline/Bring Online.
Another thing, create client aliases on each side for both server participating in Replication. DO NOT USE THE IP ADDRESS, this causes issues. Be consistent and use the same alias for each.
Finally, see this great article that helped us out immensely: SQL Server Replication Across Domains and the Internet..
You are not authorized to post a reply.

Acceptable Use Policy