Damn the stamp of this twisted bug that has had me locked out too long to set up transaction log replication between a SQL 2012 database and an Azure SQL. And, furthermore, the solution that is on the blogosphere is not valid for this case.

I had a SQL 2012 SP1 server in a virtual machine, where there was a database that I wanted to take to the Cloud. My goal was to migrate to Azure SQL by activating a publish-subscribe service from SQL Server 2012 to Azure Server.

Work locally?

The first obstacle that I must take into account is that I have had to work locally. In other words, inside the MSSQL server machine.
When I tried to connect from another machine that was outside the domain, for some reason, in all cases, it threw me the error that gives title to this article.
So, with MSSM 2012 locally, setting up and launching the Distribution and Publisher services was easy and fast. The problems have come when wanting to subscribe to Azure SQL.
Again and again I got the blessed error and I tried to solve it with the advice I have read on google. And nothing at all.

Upgrade or die

Things began to straighten out when I realized that the minimum version of SQL 2012 is SP3, and the one I had was SP1. With great fear, I downloaded the service pack and installed it, but everything was perfect and without having to restart. Was the stress worth it? No… well, and yes. No, because it kept giving me the damn mistake. And yes, because the BD has improved its performance.
And so?


Well the solution, although it is a bit rough, is to download the latest version of MSSM (the 17.x at this time) and install it. The put-down is that it requires the restart of the machine (sends eggs in the XXI century). 
But with this version, the registration and implementation of the subscription and replication was a matter of four clicks.