Cross-Domain Replication

Hi All - Need some Replication help...

I built SP's to create the Distributor/Publisher and Subscriber parts of Snapshot Replication. All run fine on 2 SQL2K installs on the SAME Domain.

BUT if I try to cross to another Domain (SQL2K as well) = NO JOY.

Error @. Subscriber doing a PULL: "Cannot connect to Distributor..."

Tried using sa, administrator, NEW Local user, etc. & continue getting the error. ALSO tried changing the Login of SQL & SQL Agent Services to the SAME Login on BOTH machines.

Help me beautiful SQL Gurus!!!

RobbieDAre the domains are trusted?|||Satya - They are SUPPOSED to be, but we haven't successfully confirmed it.

One small detail that I KNOW is related:
When adding a SQL instance in EM from the 'other' Domain, we HAVE TO use the Full Name of the server ie. Machine.Domain.com.

R|||Sounds like TRUST between domains are not properly authenticated, what are privileges and kind of account used to start SQL Services on both the machines.

Also check whether subscriber is enabled as a subscriber or chances of not impersonating the sql server agent account.

To do so In EM go to Tools | Replication |Configure Publishers, subscribers, and distributors, select the subscribers tab, ensure the check box beside your subscriber is enabled, and then click on the three ellipses beside your server. Ensure that the impersonate option is selected.|||Thanks satya.

Have set up the same LOCAL (NOT Domain) account on each Server with Admin rights. The SQL & Agent services on both boxes ALL start with that identical user.

Setup should be okay. Leaving the Publisher/Dist. the SAME, if I attempt a new subscription to another SQL install on the SAME Domain = it works.

Robbie|||I feel there is a glitch to workout the replication the SQL service account must have privilege to access the other domain's server.

Try to create an account with same name on both the domains and give required permissions (I think Admin is required) to carry on.

Then after try the replication process.|||Satya -

Have done as you suggested & still the same problem.

Other things we have tried:
1) Running DCOM utility changing launch permissions to the NEW User.
2) Changed the "Logon as Batch Job" service to the new User.

I have almost exhausted a local Consultant!!!

There was an artice on www.SSWUG.org regarding these changes, but little else we hadn't tried.

Thanks for helping|||May i dare adding my suggestion, i had the same problem. I had to setup replication b/w two different domains over the internet. The domains didn't have trust-relationship. I tried connecting the subscriber through SA and windows-users, same problem u mentioned.
I squared it away by doing this:
Made a user SQLREP (member of domain-users group) in both domains. Added the user into the local-administrator groups of both the servers(publisher and subscriber).
Checked "THE ACCOUNT IS TRUSTED FOR DELEGATION" option in the "Account-Properties" of this user at both Domain-Controllers. Note: the password for this user must be same at both ends.
SQLREP is the startup-service agent account for both the servers.
Subscriber connects to the other domain through VPN.
With this option; it allows the SQLREP user to be validated on both domains and i can access the systems(over the internet through VPN) only through this user. If i change the password of the user at any side, replication fails.
Obviously if ur domains or on LAN, exclude the VPN setup.
May be i am re-inventing the wheel!! Satya has already mentioned.

Regards!!|||You're NOT going to believe this Satya & Talat...

We just found OUR problem - which may or may not be the same for others.

We had to change the DCOM impersonations for ALL the Replication modules. Not just the Snapshot & Remote Distributer - ALL of them.

Also, we had to add the IP's to the HOSTS file of the Fully-Qualified names of all the machines involved in the Replication.

A busy operation!!!

Thanks for all your help & Happy Friday!

Robbie|||Glad you found the culprit and resolved the issue and also appreciate for posting the resolution though.