Issues with on premise content in Microsoft Edge Browser?

[Amanda__Huber]

Hi Esri/GeoNet Community, 

We're looking for anyone who may have experienced or may be currently experiencing this same issue. 

When we view any ArcGIS Online application (Map Viewer, Operations Dashboard, WAB) with on premise content (hosted on our internal ArcGIS Server)  using the Microsoft Edge Browser it results in an error displaying the data. In AGOL Map Viewer or WAB it states that "The layer can not be added to the map." In Operations Dashboard the data simply cannot be displayed, and results in an error message "Not Fully Configured". (Please see attached)

We do not have this issue in any other browsers, Chrome, IE, Firefox, and Safari all work without issue.

We have been able to narrow down that this is strictly an internal network issue (everything is accessible off the network) and confirmed that this is not a firewall issue. We have also confimed with IT that our organization has no restrictions set on our Edge Browsers as well. 

One more detail, when using Fiddler this content is viewable and results in no errors or issues. We are aware that Fiddler inserts it's own certificate, but are not sure how we can use this evidence.

We are working closely with our IT department as well, but they are just as puzzled as we are. 

Thank you!

[BillFox]

Microsoft Edge goes Chromium (and macOS)

[MegHoole]

Katie Cullen Seems that we also have folks experiencing issues using Edge when trying to draw a public feature layer item (ArcGIS Server REST service) in AGO while on our network (I don't know if the same issue occurs outside of our network).  Seems that the "don't use edge" advice still holds?  Are there any updates available for this Edge browser issue?

[MikeSmith7]

We just experienced that as well.  In our situation for one of the gadgets we were using data that was linked to https://server:6433/xxxxxxxx.  The url would throw an invalid certificate error when accessed directly in the browser, but you don't see that in the widget.  Two scenarios fixed it.  Once we changed the service to be the http port 6080 and the guage then worked, then we fixed our url to be fully qualified (that matched the certificate on the arcgis server (https://server.domain.com:6443/xxxxxxx)

In any case that was our issue.

Mike

[ErikLash1]

Same problem after a stand-up of brand new 10.6.1 base deployment to replace prior deployment that had upgraded over multiple versions. Did not exist in 10.6.1 when upgrading over 10.4.1. Confined to both our "brand new" clean 10.6.1 install attempts.

Issue is quite extensive for our users > Any service running through either IE or Edge that has to authenticate through "ArcGIS.com" (ie in Web Map) fails with the message "The webpage you are viewing is trying to close the window. Do you want to close this window?".

JavaScript loads fine. No limitations on CORS in place.

Google and Firefox work fine. Affected browsers are IE and Edge both on prem and off-prem.  Only fix found so far is to add "https://www.arcgis.com" to the IE Options as a trusted site. Adding it to Portal as a trusted site made no difference.

Hugely problematic as our DB server is 2012 which means we can't upgrade to 10.7.1 to fix this and both our content producers as well as consumers are affected.

[JohnGrogan1]

We are experiencing this issue too and are trying to get a resolution to it before a roll-out of Windows 10.

IE Enterprise Mode had been used to force AGOL web apps to open in IE rather than Edge, but we then found that web apps that are embedded in iFrames in some pages on our website were displaying blank in Edge but opening the web app in a separate IE window.

Enterprise Mode rule was then disabled and we found that the embedded web apps worked fine in Edge, but not when browsing directly to the URL of the web app.

After some more experimentation it seems that any AGOL web app will work perfectly well in Edge if in an iFrame.

We use some ESRI UK web apps too (MyNearest and QuestionWhere)  and these seem to work fine in Edge (using on-premise ArcGIS Server map services).

[Amanda__Huber]

Katie Cullen‌ , Derek Law‌ , and ArcGIS Enterprise‌ , 

As more and more organizations contribute to this post it has become evident that this is a global issue. Does Esri have any intent to further investigate this issue?

[DerekLaw]

Hi Amanda,

Apologies for the late reply, I've been out on business travel the last several weeks.

> Does Esri have any intent to further investigate this issue?

Esri is always striving to resolve technical issues with its software. While users have identified issues when using IE and Edge web browsers, it is challenging to track down the specific cause(s). In this thread, there is not one specific issue and it covers a broad range of products. This is why we encourage users to contact esri Tech Support and help provide detailed repro use case(s) to help us investigate the issue(s) further. The more use cases, to more it helps us to hopefully better identify the problem(s).

Hope this helps,

[EliThomas]

My organization is also experiencing the same issue: cannot embed internal resources to any agol product and use Microsoft Edge internally.   This has first gone to our security team, Networking team and our internal Desktop support team to ensure that this is indeed an unresolved Esri issue.   

Esri case#: 02425017 

 I will follow up in this thread with the resolution. 

[ErikLash1]

Tech assist went as far as they could and we begrudgingly accepted closed with the resolution that we have to add "arcgis.com" to trusted site for every GIS user who authenticates on our services with IE or Edge when they are used in AGOL web maps.

End users should NEVER have to suffer through getting this message:

Just because our case closed doesn't mean the software isn't broken. It just means there is a hugely expensive workaround resolution that we have to go through.

Additional information:

In testing we temporarily fixed it internally by moving the Web Adapters to the machine on which the GIS Enterprise component is installed and running IIS rewrite rules to that machine from the public Gateway. In our case having the Webadaptors on a Gateway appears to contributing to the problem (or possibly creating it).  When the WA was on the component machine everything behaved normally.

We also messed with our IIS headers at the gateway in testing. It appears the Web Adapter when installed on the gateway IIS is creating a condition where there are multiple headers being injected into the web stream, not just the ones from the IIS configuration.

We set up and tested the the custom header for CORS "Access-Control-Allow-Origin" value="*" on the IIS even though this shouldn't be necessary if there are no restrictions required.  It completely fixed the IE/Edge issue with AGOL.

Unfortunately, it broke everything else, all other authentication to the GIS services from other domains stopped working - everything except AGOL using IE/Edge. 

Assessment of the web stream indicated a 2'nd CORS header being delivered from the IIS with a web adaptor installed on it.  One header turning into two as if a second CORS header was already set up.

ESRI needs to hop on this one and get it fixed.  This is certainly a problem for which their expertise and some software tweaking can contribute to a global solution.

[ErikLash1]

Further information related to associated MS IE/Edge bugs (unverified by me, just adding it to the discussion):

It appears this problem is related to crossing security zones.  Because the on-prem deployment is part of the Intranet and AGOL is not Edge/IE (now only Edge in my case). When the application is redirected across security zones, the session storage and local storage are cleared. When the session storage is cleared, this state is lost and hence results in broken experiences.

Known issues on Internet Explorer and Microsoft Edge (MSAL for JavaScript) - Microsoft identity plat... 

window.open handle lost when redirecting across internet and intranet zones - Microsoft Edge Develop... 

Local and session storage dropped when going between internet and intranet zones - Microsoft Edge De... 

---

Also appears could maybe be an issue with the window.close(): usage in postsignin.html that triggers Edge automatic script blocking.