May 28, 2008 at 2:05 pm
Objective: Merged replication
Progress: Followed tutorial as far as creating snapshot. Creating snapshot failed - target machine actively refuses connection.
Have googled, searched here and dozens of other forums (over 300 threads read). Have verified:
1. TCP/IP is enabled protocol (SAC is correctly configured both sides).
2. Via telnet, connectivity works.
3. Via event logs, confirm that at Windows server level connection occurs (System logins confirmed)
4. Have given all related logins sysadmin rights and use Builtin\ Administrator rights (bad in production, but eliminates lots of possible evil-doers within SQL Server)
5. Have ensured that 'deny' privileges do NOT exist in either database.
6. tracert connects in single hop. Is this sufficient to prove firewall is NOT an issue (both machines should be on same side of any DMZ or firewall)
7. I am not a network person, but I've run netstat on both sides to verify that ports 1433/1434 are active and open. I've also confirmed that, when under SSMS I mapped from Server A to a database in Server B, that I actually have connectivity established and 'should be able to reach AdventureWorks on Server B.
Configuration: Server B is clean machine, Windows Server 2003, new install of SQL Server 2005, brought up to SP 2. Server A is dirty machine, Windows Server 2000 with old install of SS2k5 SP 2.
What else can I try, or where else can I look? I keep wondering what obvious oversight I've made, but I'm not finding it....
Diagnostics: Error code 10061 (was originally 18456, Severity 14, State 11); log details upon request.
May 28, 2008 at 9:37 pm
Could you register one server from another? This should be the first step while configuring a replication.
May 28, 2008 at 9:55 pm
error: the target machine actively refused it?
Have you checked this KB about this error?
May 29, 2008 at 8:33 am
SQL ORACLE (5/28/2008)
Could you register one server from another? This should be the first step while configuring a replication.
Interestingly enough, 'registering' a server is not mentioned in the tutorial.
However, I can register, sort of, in one direction, but not the other. When I register, I can netstat to verify the connectivity exists, but I cannot login to the other server. I am using mixed mode authentication, have established my personal (administrator) login as an administrator on the other server, ensured that I am part of the buildin\administrator group, and even used sql server login using a valid sql server id. All fail equally.
May 29, 2008 at 8:41 am
Vivien Xing (5/28/2008)
error: the target machine actively refused it?Have you checked this KB about this error?
Vivien - thank you for the suggestion. It looks like a marker of what could happen down the road, but I'm not certain that VSS is even in play here, yet. Certainly none of the listed error messages in the kb article appear any of the system or sql server logs. However, I was only at the stage of creating a snapshot. In my Win 2k server machine, there was no registry entry to correlate SS2k5 EE to VSS (which seems to be an ok state of affairs, per the kb article).
My brief take (pending further research, thought and exploration) is that you have saved me work down the road, but this is not germaine to my current problem. But it's still another arrow in the quiver that WILL be needed after this issue is resolved.
May 29, 2008 at 9:26 pm
The reason why we should register a server from another is to test the connection before configuration.
June 2, 2008 at 7:40 am
SQL ORACLE (5/29/2008)
The reason why we should register a server from another is to test the connection before configuration.
True. However, even after testing the connection and verifying that one server can see the other, I am still unable to replicate across from one system to another, and the diagnostics are deliberately ambiguous.
Also, as it turns out, I was violating one of the assumptions of the tutorial, so I cannot fault the tutorial for omitting anything I need to do.
However, I've since come up against another 'old' bump in the road - in attempting to clean up any clutter, I've violated the process by using a 'back door' to eliminate old clutter, and now I cannot perform any merge replication from one of my two machines without either re-installing SS2k5 EE or a LOT of executables to restore the database (and it seems that there is no clear understanding of what causes the 208 error message regarding dbo.sysmergepublications.
Clearly, replication is NOT for the faint of heart.
June 2, 2008 at 7:45 am
Check the Windows error log and try to ping the server to check for any network issues. Try to check your TCP/IP and namedpipe is enable or not too?
MCP, MCTS (GDBA/EDA)
June 2, 2008 at 8:03 am
1. TCP/IP is enabled, named pipes is not.
2. OUTSIDE any domain service, so I only have TCP/IP as a connection option, true? Or can one use 'named pipes' outside a domain?
3. I am able to connect each server to the other and explore the databases housed on the other server. So the aliasing I've created works to support connectivity, but I'm still unable to connect in replication.
June 2, 2008 at 8:57 am
Replication normally does NOTworks with ALIASES for named pull subscriptions.
You must use anonymous subscribers or Push subscription.
* Noel
June 2, 2008 at 11:47 am
I'm attempting to push. It's the 'push back' on authentication that's obstructing my progress.
June 11, 2008 at 7:51 am
Sorry for the lagged response - I was diverted for a bit, but am now back.
Noeld - 'named' subscription? This is a push, not a pull.
Everyone - on a more mundane note; I'm now getting a 'simple' login failed error diagnostic. Other than entering the password into an editor (notepad, wordpad, etc) and copying into the password field, is there a 'cleaner' way to verify that the correct passwords are being used?
For instance, I have established connectivity between both machines, using correctly configured Alias, and can see all relevant databases from either machine (both publisher and subscriber). If I use an editor and 'reaffirm' the passwords to be an exact match in that way, I should ensure that password errors are not causing the error, correct?
June 16, 2008 at 2:29 pm
For those of you who wondered what might have happened.... I had confused myself by entering a Windows login and password into a SQL Server place for login and password, violating one of the core rules that would allow replication to work using TCP/IP - you must use Windows security, not SQL Server security.
Once I set the radio button to 'fake' the windows security (which is why the login and password must be identical on both subscriber and publisher), i was able to successfully connect. From there it was fairly direct to create a publication and a subscription, deliver the content across the LAN, and prove that the merge replication works by making changes on both systems and verify that they propogated across.
Yet to do: force a scheduled 'checking' for merge replication, track down a couple of interesting error messages I get both within SSMS AND in system logs (security related) which seem to be synchronization related, and I can proceed to some 'fancier' tests to better understand the details of publication behavior.
WHEW! Thanks for all the responses, and shame on me for being blind to my own misunderstanding. I ended up looking at a working replication, saw the different setting, realized I could have had a V-8, and was on my way...
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply