Unfortunately, there are several ongoing issues with advanced proxy settings in FME, although it has been much improved lately. I'm not 100% certain of the details, but I suspect that the option "Bypass proxy server for local addresses" may not be honored by FME. That said, the proxy exception list should be honored, even with wildcards such as "*.domain.local". However, I have the impression that there may be functionality in FME that doesn't honor the exception list (major suspect: the FME Server publishing wizard), so be sure to test with the HTTPCaller, which seems to be among the better ones when it comes to proxy support.

I would first recommend that you upgrade to FME 2019.1, where the proxy support has been improved. Secondly, I would very much recommend that you raise this issue with Safe support, trying to get either Richard's or Rylan's attention, as they are already in the loop about these issues. The more that makes the case, the more likely it will be improved in a future release.

Hi David, Thanks for the feedback. It was some work I was doing with a web service on ArcGIS Portal that led me to this discovery.

Just discovered, when adding to the Custom Proxy Map pop up box initially it doesn't like the wildcard so I put in a valid value in here and altered it in the table where it accepted the wildcard. A bit of a workaround. I'll raise a case with Support.

While it may be possible to type in a wild card in the FME custom proxy maps dialog, it won't be honored as the functionality for wildcards hasn't been implemented (as far as I'm told).

Hi @david_r and @aiduser,

I have a same issue at a customer, but its on FME Server after upgrading FME Server 2018 (build 18284 - win64) to 2019.0.2 (Build 19260 - win64) and the workaround from aiduser does not solve the problem on FME Server.

Using the option Bypass proxy server for local addresses and enable Use System Proxy in IE they cannot reach internal sites, disable the Use System Proxy the internal sites are reachable again.

The post about Proxy setting option inside FME 2019.1 https://knowledge.safe.com/idea/33375/fme-server-proxy-settings-in-admin-gui.html is not relevant for the customer at this time (and doesn't have the bypass option if I'm right).

Anyone any idea what's causing this on FME Server and suggestion for a solution?

Regards,

Krien Guijt

I can confirm that this is the exact scenario several of our clients have been struggling with for a long time. Hopefully it'll get better by FME 2019.2 or 2020, as I know that they are currently working on improving special cases like these.

In the meantime, try contacting Safe support and ask for either @rylanatsafe or @richardatsafe, they are both up to date on the issue. The more that flags this as an issue, the higher the fix will be prioritized. Perhaps also link back to this thread when contacting them.

Hi @krien,

I would be interested in knowing how the domains are set up and if there are any other settings which may be effecting the proxy. Please make a case if you can.

If the following conditions are true my FME Server only uses the proxy when connecting to a server outside its domain:

1) Internet Options have:

Use Proxy Server for your LAN: Checked

Address and Port: filled in

Bypass Proxy server for local addresses: Checked

Automatically Detect Settings: UNcheckd

Use Automatic Configuration Script: UNchecked

2) Through the command line run as admin:

fme.exe APPLY_SETTINGS SYSTEM "Proxy/Proxy Setting" "Use System Proxy"

and any other relevant authorization parameters

You can check with fme.exe LIST_SETTINGS SYSTEM "Proxy" to confirm

3) The service account running the engine service is not localsystem

4) I have restarted FME Server

As soon as I un-check the bypass and restart the engine. The call will go through the proxy. It would be good to know the details of your workspace, and the domain set up so we can find the reason for this exception.

Hi @richardatsafe,

I'll ask the customer to apply the IE settings, answer your questions and open a case on this.

Final results will be posted here.

Krien

Hi @krien, I raised a support call and it turns out the Proxy settings were being honored by the HTTPCaller. I was using the AGOLReader and it was this particular transform that ignored the proxy settings in the System Settings. The inability to use wildcards in the FME Proxy Options pages was still an issue.

I could be wrong but I've found that the proxy settings that are set in FME Desktop under the same local admin account that runs the FME Server service affect the FME Server proxy settings. Perhaps safe can verify this and maybe this would fix your problem?

While FME Server can use a local bypass, it cannot use the exception list in Internet Options. I've posted on our community the idea to allow FME Server to use wildcard exceptions directly within our Web UI. Please vote it up and add details to it if its important to you.

Richard

Thanks for raising the issue, this is critical functionality for a long list of our most important clients, all sitting behind centrally managed proxy servers.

I can confirm that it´s still an issue in FME Server 2019.1.2: This is causing us a lot of problems for us since we highly depend on the wildcard. So adding every URL we connect to is not possible since we use hundreds of them. I really hope this will be fixed soon.

Yes, I agree this is a major issue and I really hope that Safe will be able to fix this once and for all very soon!

We've been having issues with this for more than 3 years now. We first encountered this problem, when trying to write to an internal ArcGIS Portal which is accessible without proxy only. In the beginning, I thought that I could work around this issue by not using ArcGIS PortalReader/Writer and instead building my own features with the JSONTemplater and using HTTPCaller and the ArcGIS Rest API.

However, there are still issues with using custom proxy maps. If I only read and write from our internal Portal, the custom proxy map within FME is considered. If I add a File Geodatabase Reader or Writer to my workspace, FME Desktop completely ignores the custom proxy map - even for HTTP Caller (FME(R) 2019.1.3.1 (20191019 - Build 19643) .

This leads me to believe that system variables which are used by both database connectors and webconnections might be part of the problem.

It would be great if this problem could be solved once and for all since being able to use webconnections, Portal Reader and HTTPCallers is at the heart of many of our workflows.