One of our clients upgraded to Windows recently on 2 pcs When they now try to email (Using WW Client for Foxpro ) it comes up with Could'nt connect to server It is fine on the other PC's (and server) that they did not upgrade to Hardware guys that did the upgrade say the Pc's were upgraded to: Windows 10 1803

Any ideas or a fix ?

Hi All,
I was going to post a question here today also regarding an issue that has occurred with the recent Win10 1803 update. I have not tried email, but a couple of VFP Forms that use the IE ActiveX to access external websites have suddenly stopped working. The client cannot connect to the server, and I know the websites are up as I can connect to them on the same computer via IE and Google Chrome. This client computer is running Win10 Home. Yesterday, I searched the web, and this site, but have found nothing so far. I turned off the firewall, and relaxed the ActiveX Security settings to no avail. I also set the IE Emulation but that did not help either. It seems to be more of a security issue rather than an emulation issue. It seems something is blocking the IE ActiveX communication. This happened on 3 different computers. Uninstalling the update resolves the issue so it's something with the 1803. This is a little different than email, but similar... I am still searching for an answer on why this update has broken the IE ActiveX functionality and any help is greatly appreciated.

TIA,
Steve

Is your VFP application running from an SMB1 share? If so, read this thread for more info and workarounds:

https://support.west-wind.com/Thread57H0KHUE2.wwt

When you say IE ActiveX what exactly are you talking about? The Web browser control? And you're loading a site into the control?

FWIW, I run Win10 1803 here and have no issues with HTTP access or the IE Web Browser control (which I use in heavily in several applications), so I don't think it's directly OS related.

Now I think there might be more restrictions with TLS 1.2 that might be causing issues. Maybe the sites you're accessing are really old and use non-TLS 1.2 certificates and it's failing with certificate errors for denied SSL access?

+++ Rick ---

Yes, I am talking about the Web browser control. Sorry for the confusion...

I think it is running off an SMB1 Share, so I need to check into that further.

Thanks for the feedback.

Hi All,
I placed a copy of the .exe onto the local machine instead of running it off the network drive and it works like a champ. Thanks for the feedback!

Steve

Great, glad to hear that it worked for you.

Jon

Putting applications on a network drive changes the Internet Zone that the IE is running in and depending on the permissions of that zone it can cause problems.

Generally when dealing with network related features that require Internet Connections running on a local drive vs on a network is always a good first reality check to see if it'll work that way first.

+++ Rick ---

HI All . Thanks for your replies Seems to b related to security issue..but is there some switch that can be turned off in Win 10 1803 that will allow the email server to be contacted ?

A few people have suggested that perhaps running form a local pc may fix it....I don't want to have to do this as I will need to update every users pc .....currently the app runs from a network share

Just to add , that since the VFP app, also noticed that a dot net app (Uses standard Dot Net Smtp email functionality) is also giving errors when trying to email, so looks as if its something in 1803

OK, tried a few things, following on from suggestions here

1. Changed to run the app from Local Drive (The VFP app and Dot Net app ) Both Found the server fine and successfully emailed
2. Changed to run from the Network using Unc path (Had been using a Mapped drive) Still no luck
3. Ran as an Administrator Still no luck
4. Run in Windows 8 compatability mode Still no luck

So only way of running it was to run from Local C drive There must be a way though of running it form server ???? Surely Microsoft is not going to go around breaking existing applications, particularly where email is involved, which is probably required for most apps these days

I don't expect Microsoft to treat this as a bug or fix it. They've been very up front about eventually ending support for SMB1, and I think this is another move in that direction. In light of that, you've got three options:

1. Create a launcher exe that gets installed on each workstation. The only thing that launcher exe does is launch the "real" exe that's on the network share. My launcher consists of about a dozen lines of code. The first time a user runs it, it asks them to browse to the network share of the real exe and saves that path to an INI file. From that point on it simply reads the INI file and runs the other exe.
2. Install the full application locally on each workstation and use some kind of configuration file (INI or whatever) to point to the location of the application's Data, Reports, etc. on the network share.
3. Re-enable SMB 2/3 & opportunistic locking on the network share and set the FileInfoCacheLifetime, FileNotFoundCacheLifetime, & DirectoryCacheLifetime to 0 on each client workstation (to prevent table and index corruption).

Makes perfect sense.

Thanks Rick!