How to establish the synchronization of databases 1C?

Good afternoon, colleagues! Overdue this burning question:
There is a server 1C, it is updated to version 1C.Enterprise 8.3.12.1685. And there is a terminal server work with databases hosted on the server 1C. Both servers running Windows Server 2012 R2.
On the server 1S database is located Bukh 3.0 Spp 3.1. Between them on the previous platform, 8.3.11.2954 is configured to be synchronized. On 8.3.11.2954 sync worked fine, but to upgrade to the latest Wham configuration was forced to switch to 8.3.12.1685(anticipating a possible question, no, the test server is not). After the transition it became clear that sync was not working. When I try to connect(for example, in the window check the settings) I get this message:
Failed to connect to another program: object method not found (Connect)


What was tested:
1. To reinstall the platform on the server and the terminal
2. To put 8.3.15.1513
3. To register regsvr32 "C:\Program Files (x86)\1cv8\8.3.12.1685\bin\comcntr.dll"(server and client)
4. Create a COM application V83COMConnector(on the client)

What are the options? Maybe someone experienced this and was able to win?
PS the Option to demolish the 1C server completely and reinstall the spam due to the availability of databases of other clients, but if other options will not, you have, of course.
March 12th 20 at 13:06
3 answers
March 12th 20 at 13:08
Solution
The problem is solved. To resolve we had to create a new user with administrative rights, and run him out of the team
regsvr32 "C:\Program Files (x86)\1cv8\8.3.12.1685\bin\comcntr.dll"
March 12th 20 at 13:10
To register regsvr32

How is it done? What is the bitness of the server?
Windows? x64
1C x32

And check the team
regsvr32 "C:\Program Files (x86)\1cv8\8.3.12.1685\bin\comcntr.dll"

in the console from the administrator - sherman13 commented on March 12th 20 at 13:13
@sherman13what team recorded the dll? - Stevie commented on March 12th 20 at 13:16
@Stevie, added to the answer above - sherman13 commented on March 12th 20 at 13:19
@sherman13, try the command
C:\Windows\SysWOW64\regsvr32 - Stevie commented on March 12th 20 at 13:22
@Stevie, the same thing, alas( - sherman13 commented on March 12th 20 at 13:25
March 12th 20 at 13:12
8.3.11.2954, 8.3.12.1685, 8.3.15.1513 - you are confused? But your computer seems confused, as each of them registers its own V83COMConnector.

As Bukh and SPP installed on a single server, it is likely that they are there and exchanged. Hence the problem with the class is registered it there, but not on a terminal server. (I'm from the Russian-controlled configurations were not working - check your sync settings, maybe there is something on account to exchange server and exchange client).

Try to use the third Board from this article - it describes manually register COM. That would not confuse the versions of the platforms, recommending on your server is "old" to remove.
All unused platform I necessarily removed - this is too juicy a rake).

Created the com connector on the server. Also checked the settings for the client. Tried to sync on the server itself. Unfortunately, did not help.
In the settings there is a sync only the address of the server 1C, the database name, and username\password. Authentication, if that is used internally, the OS authentication is not used. - sherman13 commented on March 12th 20 at 13:15
On this minor note I have nothing I can tell. If I were in your place, that would translate the server in debug mode, set the checkbox "stop on error" and run the exchange. Next I would look at the context of the code where the error occurred.

A similar error in my France themselves faced when in office raised platform with 8.2 8.3 - in code synchronization of the ZKP and BU were attempts to create only V81COMConnector and V82COMConnector. I finished connector to 8.3 and it worked. But this is clearly not the case.

There could possibly be a trivial or a typo in your connection settings or the changed server ports. Or some mistake of the platform. - miles_Treut commented on March 12th 20 at 13:18
@miles_Treut, we will understand what to do. Me confused by the error message, to me it looks like 1C is really knocking on the wrong way, trying to start the connector. But that's where it's "not there" is... I'll Try to knock up a test server and it'll exercise. - sherman13 commented on March 12th 20 at 13:21
@miles_Treut, and if I understand correctly that the COM connection when you launch the sync is initialized on the server on which we went into the database and run the sync(terminal server)? - sherman13 commented on March 12th 20 at 13:24
@sherman13, I have no Bukh 3.0 and can't see how it is exactly implemented, but it's a managed application and, by default, different exchanges are taking place on the server, not the client. In the oldest systems such as УТ10 exchange physically happened from the user's computer. - miles_Treut commented on March 12th 20 at 13:27
@miles_Treut, okay, got it. check it out. Thank you - sherman13 commented on March 12th 20 at 13:30
@miles_Treutchecked. From the terminal server start without any issues. So yeah, CATFISH on the server is running.

Now we have to repeat it all on the battle server. - sherman13 commented on March 12th 20 at 13:33

Find more questions by tags 1C