• Thomas Pollinger
• 24.05.2017
• DE

Schon gewusst? "Microsoft Edge, Firmennetzwerk und eine proxy.pac"

In den letzten Tagen hatte ich eine interessante Begegnung mit einem erstmal unerklärlichen Verhalten. Es ging darum, den Microsoft Edge zusammen mit Web Site Management (RedDot CMS) Server, im neusten Release 16 zu testen. Denn mein Arbeitsplatz besteht nun aus einem Windows 10 (1607) System.

Als ich dann so fröhlich beim testen war, hatte sich der Microsoft Edge immer mal wieder verabschiedet. Danach ließ sich dieser Browser auch nicht mehr korrekt starten und auch der IE11, auf dem selben System, hatte so seine Probleme danach. Als erstes denkt man sich das könnte am Web Site Management liegen. Nee, ganz im Gegenteil - WSM war nicht die Ursache für dieses, erstmal unerklärliche, Verhalten. 

Nach einigen Tagen hatte ich herausgefunden, dass dieses Verhalten nur im Firmennetzwerk haufgetreten ist. Remote, also per VPN lief alles ohne Probleme. Man konnte schnell, fast fehlerfrei und stabil mit Microsoft Edge im Web Site Management Server arbeiten. Auch im Delivery Server zeigt sich der Microsoft Edge richtig gut.

Doch warum habe ich so viele Probleme vor Ort im Firmennetzwerk? Diese Frage stelle ich mir mehrere Tage und habe mich mit einem Kollegen aus unserer Netzwerktruppe kurzgeschlossen. Was wir dann über die nachfolgenden Tage, als wir Tonnen an HTTP-Datenverkehr intern durchgeschaut haben, herausbekommen haben war mehr als nur interessant.

Es ist ein, auch im Netz diskutiertes Verhalten, welches Microsoft Edge im Zusammenspiel mit einem Firmennetzwerk und einer Proxy.pac zeigt. ;)
 

Was ist eine Proxy.pac?

"Anhand einer Proxy-Auto-Config-Datei (PAC-Datei) kann ein Webbrowser automatisch den passenden Proxyserver für eine gewünschte URL finden. Eine PAC-Datei enthält eine JavaScript-Funktion FindProxyForURL(url, host). Diese Funktion gibt einen String mit einer oder mehreren Proxyspezifikationen zurück; mit mehreren Spezifikationen wird ein Fallback bzw. Failover für den Fall möglich, dass ein Server nicht antwortet. Der Browser holt sich diese PAC-Datei, bevor er weitere Seiten anfordert. Die URL der PAC-Datei kann entweder von Hand angegeben werden oder über das Web Proxy Autodiscovery Protocol automatisch gefunden werden." (Quelle: Wikipedia)
 

Was ist ein Firmennetzwerk (Corporate Network) ?

"Ein Corporate Network (CN) dient der Vernetzung räumlich verteilter Einzelnetze einer Organisation (Unternehmen, Militär, Polizei) miteinander. Ein CN ist ein geschlossenes und privates Kommunikationsnetz. So können zum Beispiel im Bereich Rechnernetze bundesweit verteilte Rechnernetze (LAN) mittels MPLS und CN Technologie miteinander vernetzt werden und über eine gemeinsame Firewall an das Internet angebunden werden. In der Telekommunikation spricht man von einem CN, wenn Telefonanlagen (zum Beispiel über Standleitungen) miteinander vernetzt sind." (Quelle: Wikipedia)
 

Und warum macht das Ärger?

Als mein Kollege und ich den HTTP-Datenverkehr analysiert hatten, kam eine Auffälligkeit hervor. Es wurde seitens Microsoft immer wieder der FQDN "tumri.com" angefragt. Sobald diese Anfrage losgeschickt wurde, hatte der Browser seine "Wartezeit" bekommen. Ursache dafür ist ein DNS-Timeout, welche durch die fehlende Erreichbarkeit von "tumri.com" hervorgerufen wurde. Nach einer kleineren Suche im Netz, sind wir auf den Artikel Trouble with Microsoft Edge in a domain network gestoßen, welcher genau das Problem bei uns beschreibt.
 

Lösung!

Eine echt Lösung gibt es nach aktuellem Wissensstand nicht, jedoch einen Workaround, welcher sehr gut funktioniert. Ursache für das Verhalten ist der o.g. DNS-Timeout und diesen gilt es zu verhindern.

Also haben wir den FQDN erreichbar gemacht, in dem wir die lokale (auf dem System liegende) hosts Datei angepasst haben.

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost

# Fix for Edge and IE11 to prevent DNS-Timeouts
    8.8.8.8     tumri.com

Dateipfad: C:\Windows\System32\drivers\etc\hosts

Wir haben einfach den FQDN "tumri.com" auf eine schnell erreichbare IP-Adresse gelegt. In diesem Fall den bekannten Google DNS-Server "8.8.8.8" ;)

Nach dieser kleinen Anpassung, läuft der Microsoft Edge und auch IE11 unter Windows 10 extrem schnell und zuverlässig. Auch das Arbeiten in Web Site Management Server oder Delivery Server macht nun richtig Spaß.
 

Aber warum tritt diesen Verhalten überhaupt auf?

Grund für das Verhalten ist erstmal die proxy.pac, welche im Browser eingestellt ist. Diese wird in der Regel von der OfficeIT per GroupPolicyObject (GPO) verteilt.

Bei der proxy.pac ist es so, dass jede DNS-Anfrage über die proxy.pac geprüft wird. Denn, wie schon weiter oben beschrieben, stehen dort Anweisungen drinnen, welche dem Browser sagen über welchen Netzwerk-Proxy er für bestimmte Anfragen gehen soll. 

Wenn nun eine DNS-Anfrage auf sich warten lässt und somit die Pürfung der proxy.pac unterbrochen wird. Zeigt sich das Verhalten "der Browser reagiert nicht mehr" und man meint die Applikation wäre "abgestürzt" ;)

---

Hinweis: Wenn statt einer proxy.pac, der Netzwerk-Proxy direkt in den Internet-Optionen von Windows 10 eingestellt ist, tritt das o.g. Verhalten nicht auf und der Workaround ist somit nicht notwendig.

---

Fazit

Der Microsoft Edge macht erstmal einen soliden Eindruck. Auch im Zusammenspiel mit Web Site Management Server und Delivery Server gibt es nur wenige Kleinigkeiten (welche schon an OpenText™ zur Prüfung gemeldet worden sind) die nicht gehen. 

In Punkto Geschwindigkeit steht der Edge z.B. dem Chrome in nichts nach. Meinerseits habe sogar den Eindruck, dass der Edge in einigen Bereich schneller als Chrome ist. Dies müsste man nochmals im Detail prüfen und validieren, jedoch ist dies auf Grund des Gesamteindruck von Microsoft Edge erstmal nicht nötig.

Warum Microsoft die o.g. Abfrage an "tumri.com" beim starten des Microsoft Edge bzw. generell in Windows 10 losschickt, müsste man noch im Detail prüfen. Ob es dafür eine Korrektur in einem kommenden Update von Windows 10 geben wird, muss man ebenfalls beobachten. 

Da jedoch ein Workaround vorhanden ist, der sich einfach umsetzen lässt und zuverlässig funktioniert. Ist an dieser Front erstmal die Lage entspannt und man kann schnell, einfach und stabil mit dem Microsoft Edge in Web Site Management arbeiten.

Womit wieder bewiesen wäre, dass nicht jedes seltsame Verhalten direkt von Web Site Management ausgelöst wird oder in der Software selbst enthalten ist. Denn es gibt sehr viele Abhängigkeiten im Zusammenspiel mit z.B. dem Betriebssystem des Clients oder Servers, dass nicht in einer Software wie WSM abgefangen oder kontrolliert werden kann.

Und nun viel Spaß mit Microsoft Edge und Web Site Management (RedDot CMS) - es lohnt sich damit zu arbeiten. ;)

---

Über den Autor: