OT: ADS & Win 10 April Update RESOLUTION

[Enrico Maria Giordano]

I'm facing this problem: an EXE stored on a LAN shared hard drive and run from a Win10 client gets the communications completely blocked (http, ftp). I found a workaround moving the EXE on the local hard drive (and then set the current directory on the remote one).

Any ideas?

EMG

[TimStone]

I don't know how long it will be before we actually understand all that MSFT did in this update to revise networking. Many are working to discover the problems and fixes.

The problem with ADS is that it must "discover" the server if it is not pre-set in the .ini file. Because of dynamic IP's being so popular, often the discovery process was installed by default. That is what was broken in the 1803 update. Also communication takes place on port 6262. Although a rule was in place to open it on ADS installations, the update removed those rules and they had to be setup again.

ADS uses port 2989 on UDP for it's own "discovery" of it's server. Even opening that port does not automatically allow for the process to work ( for an ADS client to find it's server ).

Once a link is established between the client and the server ( which the ads.ini does if setup ), then there is no problem. The communication continues while because the server address has been retained by ADS while active.

This is not a problem unique to ADS. It has created havoc for many programs and server systems including reports of issues for Oracle.

I'm afraid debugging your own situation may be exhausting because we don't know the basic changes. There are many different actions that have worked for some people, but not all, and not consistently. I do not run .EXE's across the network. It is too slow. I always install them locally. I have a startup program that checks to see if a newer version is available on the server, and if so copies it over, and then it starts the latest primary application. If the latest is already installed it instantly starts the application. Thus even in large networks, the local .exe is always current, and the speed of execution is very fast. This has not been bothered by the 1803 update.

I wish you the best in finding the answers.

[Enrico Maria Giordano]

Tim,

Thank you for the info. Only a note:

I do not run .EXE's across the network. It is too slow.

I Always run EXEs across the network and never found them slow.

EMG

[peterk]

HI all

We have found the following

The WIN 10 April update removed support for SMB1 and now supports SMB2 upwards only, due to the SMB1 protocol being ancient and incapable of supporting the requirements of modern networking security, su understandable. This is the key problem. Therefore for any networking with these Win10 clients to work the server must also support SMB2 (both client and server must support the minimum of each side). Thus old Linux servers that are configured with Samba SMb1 will require upgrade / replacement to support SMB2 to work. Old Win2003 servers do not support SMB2 per my understanding and will need upgrading to 2008/12/16.

Tim's ads.ini fix works if SMB2 is enabled on the server, which it normally would be. However we had a case where it was not (only SMB1 on the server), and with this the Win10 April update clients could not discover/find Advantage even with the Ads.ini file. We concluded that even with the ADS.ini present, Advantage client still uses a bit of SMB protocol to translate the drive to the server / discover it before changing to socket comms only.

Its relatively easy to check / set the SMB on the client and server via the registry settings as follows:

Server -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanServer\Parameters", Smb2 (0 to disable, 1 to enable) + reboot
Workstation -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanWorkstation\Parameters", Smb2 (0 to disable, 1 to enable) + reboot

We also always disable file and directory caching ( oplocks ) to prevent cdx corruption at non-advantage sites, via the registry settings ( but this is an old non related issue)

Hope this helps someone

Regards
Peter

[Horizon]

HI all

We have found the following

The WIN 10 April update removed support for SMB1 and now supports SMB2 upwards only, due to the SMB1 protocol being ancient and incapable of supporting the requirements of modern networking security, su understandable. This is the key problem. Therefore for any networking with these Win10 clients to work the server must also support SMB2 (both client and server must support the minimum of each side). Thus old Linux servers that are configured with Samba SMb1 will require upgrade / replacement to support SMB2 to work. Old Win2003 servers do not support SMB2 per my understanding and will need upgrading to 2008/12/16.

Tim's ads.ini fix works if SMB2 is enabled on the server, which it normally would be. However we had a case where it was not (only SMB1 on the server), and with this the Win10 April update clients could not discover/find Advantage even with the Ads.ini file. We concluded that even with the ADS.ini present, Advantage client still uses a bit of SMB protocol to translate the drive to the server / discover it before changing to socket comms only.

Its relatively easy to check / set the SMB on the client and server via the registry settings as follows:

Server -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanServer\Parameters", Smb2 (0 to disable, 1 to enable) + reboot
Workstation -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanWorkstation\Parameters", Smb2 (0 to disable, 1 to enable) + reboot

We also always disable file and directory caching ( oplocks ) to prevent cdx corruption at non-advantage sites, via the registry settings ( but this is an old non related issue)

Hope this helps someone

Regards
Peter

Hi,

I tried to Enrico's proposal and it works.

After I have tried Peter's proposal. And my application works again in network share folder with changing client and servers side Smb2 set to 1.

(I have not tried RDP connection. Because I must restart server. There are clients that is connected.)

[Otto]

Hello,
there is a topic on the Alaska forum.
https://www.xbaseforum.de/viewtopic.php?f=32&t=9014

Joachim und Alaska haben einstimmig darauf hingewiesen, es mal mit der Portangabe direkt im Connection-String zu versuchen. Also in diesem Fall "DBE=ADSDBE; SERVER=\\192.168.2.206:6262\...". Und damit klappt das dann. Kleine Änderung, große Wirkung.

Regards,
Otto

[Enrico Maria Giordano]

HI all

We have found the following

The WIN 10 April update removed support for SMB1 and now supports SMB2 upwards only, due to the SMB1 protocol being ancient and incapable of supporting the requirements of modern networking security, su understandable. This is the key problem. Therefore for any networking with these Win10 clients to work the server must also support SMB2 (both client and server must support the minimum of each side). Thus old Linux servers that are configured with Samba SMb1 will require upgrade / replacement to support SMB2 to work. Old Win2003 servers do not support SMB2 per my understanding and will need upgrading to 2008/12/16.

Tim's ads.ini fix works if SMB2 is enabled on the server, which it normally would be. However we had a case where it was not (only SMB1 on the server), and with this the Win10 April update clients could not discover/find Advantage even with the Ads.ini file. We concluded that even with the ADS.ini present, Advantage client still uses a bit of SMB protocol to translate the drive to the server / discover it before changing to socket comms only.

Its relatively easy to check / set the SMB on the client and server via the registry settings as follows:

Server -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanServer\Parameters", Smb2 (0 to disable, 1 to enable) + reboot
Workstation -> HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\LanmanWorkstation\Parameters", Smb2 (0 to disable, 1 to enable) + reboot

We also always disable file and directory caching ( oplocks ) to prevent cdx corruption at non-advantage sites, via the registry settings ( but this is an old non related issue)

Hope this helps someone

Regards
Peter

It woked, thank you!

EMG

[peterk]

We had another situation yesterday that probably explains Tim's comments about some people replacing Win Defender with a different firewall to solve the Win 10 April edition issues.

One of our apps, running on a Win10 April edition workstation, would freeze 10 secs after startup. It was pulling the exe from the shared network drive which is how we install all our apps.
We tracked the freeze to a timer that opened a listening socket 10 secs after the app started.
This blocking listening socket was not responding and because the app is single threaded it hung the whole app making it freeze

We copied the exe to local C drive and ran it from there and the problem went away.

This happened because Windows Defender was blocking the socket/port when we ran the exe off the network drive. Win Defender did not block the socket if we ran the exe off the local c: drive.

This makes sense - Win Defender would apply stricter rules to network originated exe's
We examined Win Defender setup and found that while It allowed the exe to be loaded from the network drive, it was blocking the app's listening socket connection when the exe was loaded from the network drive

We tried to remove this rule from Win Defender / allow the listening socket but found it very difficult / impossible to change the Win Defender config or to disable the Win Defender service, which I suppose is exactly what MS want!, which is why some users would have just un-installed it.

NB On this particular Win10 workstation, IT staff had re-enabled SMB1 (because the old Linux server did not support SMB2). We re-tested running the app on a different Win10 April edition workstation using SMB2 with the exe pulled from the server drive - no issues at all

Conclusion:
As part of discouraging use of SM1, MS did the following in the Win 10 April edition
- disabled SMB1 protocol
- changed Win Defender to apply stricter rules to SMB1 traffic (vs SMB 2) traffic, for Win 10 workstations if SMB1 is re-enabled

SMB1 is ancient and is the protocol that is abused by many viruses to discover and spread to multiple networked machines easily and quickly. In our modern world we must simple not use it, it is not secure enough, unless you particularly want to be a ransomware victim…

Peter

[bradmaudlin]

Tim,

Thanks for all of this information.
I have used the LOCAL ADS with my software and have a need to access the data Remotely (through the Internet).
I am looking at using SAP's ADS. Do you use v11 or v12?
I have contacted a sales associate at SAP, but they couldn't fine any pricing info and said they would pass it on to someone else.
Do you have a knowledgeable sales person that you use at SAP?

Again, thanks for all the great info you post on this forum... (I might be asking some questions once I get it purchased and setup on my Server, although the 30-day trial of v12 seemed to work without too many issues).

Brad Maudlin
C&M Business Machines, Inc

[TimStone]

Brad,

I use Version 12, but my clients are on 7 through 12.

Do you want to set up a reseller account or just buy a copy ? I have a reseller account so I can sell it to you, but if you want to sell it to clients, you need to go through the process of being set up with them. Email me ( timstone at masterlinksoftware dot com ) and I can put you in touch with the person who controls my account. Of course if you just a copy for yourself, I can arrange that. The normal retail is $650 US per 5 users. Simply multiply that times the number of users ( ie x2 for a 10 user, x3 for a 15 user, etc ).

Email me directly with any questions.

[Jack]

Hi,
2 month ago, a have the same problem . When a program was started from a network drive (on a Win 10 computer) , it was not possible to establish a connection with MS SqlServer .

Now, in August, after new updates from Microsoft , it is possible the start the program from network drive .

Strange !

Philippe