Skip to Content
1

ADS Connection

May 08 at 07:45 AM

407

avatar image
Former Member

Since Windows 1803 we cannot connect to ADS-Server as long as the client-application is located on the server where ADS is running. Starting our application from a local drive or another server works as before.

Error code is 5036: No connection to Advantage was found

Same behaviour when starting ARC from a disk on the server:

Error 6097: Bad IP address or port specified in the connection path or in the ADS.INI file. axServerconnect

launch from local drive works fine...

ADS.INI has correct entries!

Probably a windows-bug. Any Ideas for a workaround ?

10 |10000 characters needed characters left characters exceeded
Former Member
0
* Please Login or Register to Answer, Follow or Comment.

4 Answers

Joachim Dürr May 10 at 01:11 PM
0

5036 is a client side error. Without any details on the connection settings nobody could a give a valid answer. As for the 6097 it looks like your machine is preventing UDP communication on the desired port.

Share
10 |10000 characters needed characters left characters exceeded
Michael Loop
May 11 at 12:55 PM
0

I'm not sure what you mean when you distinguish between the server drive and the local drive.

It does sound like Windows has tightened security on local connections. Check your registry for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Advantage\Configuration\ALLOW_IPC_CONNECTIONS. If it is set to 1 or does not exist, try setting it to 0 and restarting your Advantage server. If it is set to 0, try setting it to 1. If neither of these help, reset it to its original value.

Portqry in your second example seems to be failing outright on the TCP connection. I wonder if it would give a different message if you used -p UDP.

You don't mention whether you are setting your protocol in ADS.INI. Try toggling between TCP and UDP.

If any of these work, you are still left with the mystery of what Microsoft changed.

Show 1 Share
10 |10000 characters needed characters left characters exceeded
Former Member

local drive: Application is located on the hard-disk of the workstation

server drive: Application is located on the hard-disk of the server

Portqry -p UDP gives the same result as BOTH

The registry-settings you mentioned don't make any difference

One more fact:

we have two file-servers, one with Windows Server 2008, the other with Windows Server 2012

on the 2008 server a connection can be established. 2012-server no connection possible (neither UDP nor TCP)

0
avatar image
Former Member May 11 at 07:58 AM
0

Some more details:

Testing Port 6262 on our server with the tool PortQryUI from Microsoft gives the following results:

On a Workstation with Windows 10 Version 1803:

Starting PortQryUI from local drive:

Starting portqry.exe -n 192.168.115.13 -e 6262 -p BOTH ...

Querying target system called: 192.168.115.13
Attempting to resolve IP address to a name...
IP address resolved to S3
querying...
TCP port 6262 (unknown service): LISTENING
UDP port 6262 (unknown service): LISTENING or FILTERED
portqry.exe -n 192.168.115.13 -e 6262 -p BOTH exits with return code 0x00000002.

Starting PortQryUI from server drive:

Starting portqry.exe -n 192.168.115.13 -e 6262 -p BOTH ...
Querying target system called: 192.168.115.13
Attempting to resolve IP address to a name...
IP address resolved to S3
querying...
Error Opening socket: Error 10022
A Winsock error has been encountered.

portqry.exe -n 192.168.115.13 -e 6262 -p BOTH exits with return code 0x00000063.

On a Workstation with Windows 10 Version 1709:

Starting PortQryUI from server drive:

Starting portqry.exe -n 192.168.115.13 -e 6262 -p BOTH ...
Querying target system called: 192.168.115.13
Attempting to resolve IP address to a name...
IP address resolved to S3
querying...
TCP port 6262 (unknown service): LISTENING
UDP port 6262 (unknown service): LISTENING or FILTERED
portqry.exe -n 192.168.115.13 -e 6262 -p BOTH exits with return code 0x00000002.

Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member May 15 at 05:53 AM
0

Enabling SMB2 on the server seems to solve the problem

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Thank you for this feedback.

As I mentioned in another thread, SMB1 contains vulnerabilities that enabled the Wannacry and Petya exploits. SMB2 has been disabled by default because of similar vulnerabilities, so be cautious with this solution.

When I try to reproduce your problem, I am not able. This may be because I had already been experimenting with connections to a server on the network. I opened ports 6262, 2989 and 138, which worked, but then disabling the new rules did not restore the problem.

Regards,

Mike Loop - SAP Product Support

0