June 25, 2012 at 10:28 am
I have tested this with SQL 2005 SP3 and SQL 2012 RTM, and I can verify that both versions are failing in the same manner. I have not tested with SQL 2008 or SQL 2008 R2.
When an admin configures replication, and configures a subscriber that is NOT currently a linked server, the replication adds the subscriber to sys.servers. Then the admin goes to add the server as a linked server, the configuration will appear through the interface to have completed successfully, but Remote Procedure Calls will never function, throwing error Msg 18483, Level 14, State 1, Line 1
Could not connect to server 'ServerB' because '' is not defined as a remote login at the server. Verify that you have specified the correct login name.
1. Create SQL Publication for Transactional Replication on Server A
2. Create SQL Subscriber for Push Replication on Server A targeting Server B, run all agents at the Distributor
3. Configure Linked Server on Server A targeting Server B, using current security context, enable Data Access, RPC, and RPC OUT as true
4. Test Linked Server B
SELECT * FROM ServerB.master.sys.databases = results
EXEC ServerB.master.dbo.sp_who2 = ERROR
Msg 18483, Level 14, State 1, Line 1
Could not connect to server 'ServerB' because '' is not defined as a remote login at the server. Verify that you have specified the correct login name.
For Server C, we are going to reverse the steps
5. Configure Linked Server on Server A targeting Server C, using current security context, enable Data Access, RPC, and RPC OUT as true
6. Create SQL Subscriber for Push Replication on Server A targeting Server C
7. Test Linked Server C
SELECT * FROM ServerC.master.sys.databases = results
EXEC ServerC.master.dbo.sp_who2 = results
You can reverse the steps to prove that it is not an issue only with ServerB. Simply drop the subscription, drop the linked server (drops MUST be performed in that order, you cannot drop a linked server that has a subscription), re-create the linked server to ServerB, and re-create the subscription. ServerB will test correctly. Then you can drop everything and configure the Subscription first and the linked server second, and test will reveal ServerB to fail with the error again.
This issue has been logged with Microsoft Connect, ID 750728. I am simply posting this here to increase the awareness of this bug.
June 29, 2012 at 7:54 am
Wow ... not much activity on these forums I guess. LOL.
Microsoft responded to my Connect Feedback at least:
Hi James Kerr,
thanks for taking the time to share your feedback, this is really important to us.
We will investigate the issue and get back to you.
Best regards
Jean-Yves Devant
Program Manager (Replication/CDC/CT)
SQL Server Engine Team
I am just looking for anyone else that can test this and let me know whether or not you experience the same issue.
Thanks!
June 29, 2012 at 11:18 am
Hit this earlier this week with SQL 2008 R2. Updated the Connect bug.
June 29, 2012 at 3:25 pm
Robert Davis (6/29/2012)
Hit this earlier this week with SQL 2008 R2. Updated the Connect bug.
So we can confirm that SQL 2005 SP3, SQL 2008 R2, SQL 2012 RTM all have this issue, meaning all the service packs and levels in-between probably have the same issue.
Thank you for your feedback!
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply