TCP/IPtricks in Merge Replication?

  • BOL has a merge replication tutorial that specifies the creation of specific (Windows) Login-IDs and how to set appropriate privileges to allow the initial snapshot to be created.

    I have two non-Domain servers. I follow all the directions. My publisher-machine based process is unable to login to the subscriber- machine - receiving the error number 18456, Severity 14, State 11 [Valid Login but server access failure].

    What does that mean? 'server access failure'? I followed the tutorial's directions on granting access to specific databases. Do I need to be careful which database is used to connect with first?

  • OK... I've made progress. Now I'm getting Error 18456, successfully connecting to the server with a valid login, but have a server access failure. What settings do I need to set to get into the database? Do I have to provide folder-level access for the Windows login-ID I'm using?

    Incidentally, I have no log entries in the subscriber server anywhere, and profiler does not show even a login attempt. From this I conclude the failure occurs in trying to connect INTO the sql server environment on the subscriber, before I ever reach SQL Server application in any form. Does that make sense?

  • OK. I'm making progress, but still thwarted in my ultimate objective. Because I'm 'outside' our domain server/service, I am using IP addressing to go from one server to another. I've successfully created an alias, connected to the subscriber, and created the 'environment' for receiving the publication.

    But then I get Error 18456, which means my login protocol is still violated. Any tips on what to look at, what to look for, or what I may need to do to my alias to break through this obstacle?

  • I just started working on a merge replication project for the first time and I remember somewhere in the documentation I was reading that you have to use the Machine Name for connections not the IP address. You should be able to get around that by hard coding the publisher name and IP address into the LMHOST file. I did that from my home machine because when connecting through our VPN the DNS wasn't working.

  • I thought machine names only had meaning in a network context when you were operating with domain servers. Am I wrong about that? Both my publisher and subscriber are outside domain services and only the IP address has meaning until you actually reach the machine.

  • HOSTS or LMHOSTS are a way to BYPASS DNS queries. so your network client does not need to resolve the Computer Name.


    * Noel

  • noeld (6/4/2008)


    HOSTS or LMHOSTS are a way to BYPASS DNS queries. so your network client does not need to resolve the Computer Name.

    I can appreciate the use to avoid DNS resolution when it's called for, but an IP address also circumvents the need, doesn't it? Or does having the content in HOSTS or LMHOSTS supplement the IP address information in such a way that the DNS question never arises?

    Scenario: I'm in location A, and using merge replication as a d/r protection (never mind why) at location B, 350 miles away. All I can be expected to truly know (and trust) is the IP address, right? Unless I'm traveling the 350 miles to location B or take someone's word for it, right? But taking someone's word brings us back to a 'trusted' relationship, which violates our assumptions of IP address only....

  • That is totally right.

    The problem is that "replication code" does not like IP addresses as Server names.


    * Noel

  • You may want to try Web Synchronization feature but you will still have to use a Domain name with a security certificate instead of an IP address. I just got mine up and working with this setup and I had to use a domain name or machine name as the server portion.

    I used the HOSTS file in %windows%\system32\drivers\etc folder to bypase the DNS lookup. I entered our WAN IP address as the IP for the publisher machine name and then configured work firewall to look at LAN IP for HTTP and SSL connections. I created a certificate using the selfssl utility in the iis resource kit.

    We also employ a VPN system but a public internet access was required.

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

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