Skip to Content

ADS Connection

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 ?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • May 10 at 01:11 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • May 11 at 12:55 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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)

  • May 11 at 07:58 AM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • May 15 at 05:53 AM

    Enabling SMB2 on the server seems to solve the problem

    Add comment
    10|10000 characters needed 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