Leitfaden zum Ausstieg aus der Abhängigkeit vom IE-Modus

1. Der Artikel in einem Satz

„Den IE-Modus im offiziellen Regelbetrieb sicher nutzen, die Abhängigkeit davon Schritt für Schritt verringern und ihn am Ende ganz auf null bringen“ ── das ist die realistische Strategie. Bevor Sie ihn wegwerfen, verwalten Sie ihn erst einmal ordentlich.

In diesem Artikel verwendete Begriffe

Zunächst fassen wir die Begriffe zusammen, die im weiteren Verlauf immer wieder vorkommen.

2. Hintergrund: Wie lange lässt sich der IE-Modus noch nutzen?

Wichtig ist hierbei: Nur weil der IE-Modus bis 2029 nutzbar ist, heißt das nicht, dass Sie ihn beruhigt liegen lassen können. Dieser Zeitraum ist lediglich eine „Frist, um planmäßig auszusteigen“, und um nicht erst kurz vor 2029 in Hektik zu geraten, bleibt nur, schon jetzt mit der Vorbereitung zu beginnen.

3. Warum lässt sich die Abhängigkeit vom IE-Modus so schwer loswerden?

Der IE-Modus ist ein Mechanismus innerhalb des Chromium-basierten Edge, der ausschließlich alte Sites mit der Trident-(MSHTML-)Engine rendert. Was diese Trident-Engine dabei übernimmt, ist Folgendes:

• Der alte Dokumentmodus (Document Mode)
• ActiveX-Steuerelemente / BHOs (Browser Helper Objects)
• Alte Sicherheitszonen-Einstellungen
• Die Kompatibilitätseinstellungen von Enterprise Mode

Solange Sie von diesen Elementen abhängen, löst eine bloße Aktualisierung des Browsers das Problem nicht. Der erste Schritt besteht darin, herauszufinden, worin die Abhängigkeit tatsächlich besteht.

Häufige Probleme in der Praxis

1. Falsch konfigurierter Dokumentmodus → Zerstörtes Layout, Skriptfehler
2. Fehlende Konfiguration neutraler Sites → Bei SSO (Single Sign-On) entstehen erneute Anmeldeschleifen oder Umleitungsschleifen
3. Falsches Format der Enterprise Mode Site List → Für die IE-Modus-Integration wird schema v.1 nicht unterstützt; eine Migration auf schema v.2 ist erforderlich
4. Edge verarbeitet nur eine einzige Sitelist → Die Edge-seitige Richtlinie hat Vorrang vor der IE-seitigen Richtlinie

Die Abhängigkeit klassifizieren: Zunächst klären, „wovon“ Sie abhängen

4. Schritt 1: Lebensverlängerung ── Zunächst sicher betreiben

1. Die Sitelist ordentlich verwalten (am wichtigsten)

Es ist gefährlich, das „Neuladen“ den Nutzern zu überlassen. Verwalten Sie es offiziell per Richtlinie.

Was zu tun ist: Wechseln Sie zu Cloud Site List Management und verwalten Sie zentral, wer welche Sites bis wann im IE-Modus nutzt.

Minimalbeispiel für das Sitelist-XML

Die Sitelist wird im schema v.2 der Enterprise Mode Site List geschrieben, also als XML mit dem Wurzelelement <site-list>. Die minimale Struktur besteht nur aus Folgendem:

<site-list version="1">
  <!-- Site, die im IE-Modus geöffnet wird -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- Authentifizierungsserver: wird in der Ausgangs-Engine geöffnet (neutrale Site) -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

Beim Schreiben sind folgende Punkte zu beachten:

• Bei url wird kein Protokoll angegeben. Schreiben Sie contoso.local, gilt der Eintrag sowohl für http als auch für https.
• Sites mit <open-in>IE11</open-in> werden im IE-Modus geöffnet.
• <compat-mode> gibt den auf der IE-Modus-Seite verwendeten Dokumentmodus an (z. B. IE8Enterprise, IE7Enterprise, Default).
• <open-in>None</open-in> kennzeichnet eine neutrale Site. Tragen Sie hier den Authentifizierungsserver ein.
• version ist die Versionsnummer der Sitelist. Erhöhen Sie den Wert, wenn Sie die Liste aktualisieren.

Für die Verteilung verwendete Gruppenrichtlinien

Um die Sitelist zu verteilen, konfigurieren Sie zwei Gruppenrichtlinien. Beide lassen sich sowohl unter „Benutzerkonfiguration“ als auch unter „Computerkonfiguration“ einstellen.

Als Speicherort der Sitelist können Sie eine HTTPS-URL (empfohlen), einen Netzwerkfreigabepfad oder einen lokalen Dateipfad angeben. Auch auf der IE-Seite gibt es mit „Use the Enterprise Mode IE website list“ (Administrative Vorlagen > Windows-Komponenten > Internet Explorer) eine Richtlinie mit derselben Aufgabe, doch sobald die Edge-seitige Richtlinie konfiguriert ist, hat diese Vorrang. So lässt sich beispielsweise die produktive Liste unternehmensweit über die IE-seitige Richtlinie verteilen, während nur an eine Pilotabteilung über die Edge-seitige Richtlinie eine Testliste ausgegeben wird.

2. Die Authentifizierungseinstellungen festigen

Ist SSO im Spiel, bricht die Authentifizierung beim Übergang zwischen IE-Modus und Edge-Modus häufig zusammen.

Neutrale Sites (Neutral Site) sind eine Einstellung, die sowohl im IE-Modus als auch im Edge-Modus festlegt, dass die Seite „in der Ausgangs-Engine geöffnet bleibt“. Registrieren Sie die Authentifizierungs-/SSO-Relaisite hier nicht, wird beim Sprung von einer im IE-Modus geöffneten Seite zum Authentifizierungsserver sofort zu Edge umgeleitet, und die Authentifizierung schlägt fehl. Auch die Microsoft-Dokumentation erklärt, dass Authentifizierungs-/SSO-Server explizit als neutrale Site konfiguriert werden müssen, damit der IE-Modus korrekt funktioniert.

• Neutrale Sites korrekt konfigurieren → SSO-Server explizit mit <open-in>None</open-in> angeben
• Bei Bedarf Cookie-Freigabe konfigurieren (standardmäßig teilen sich die Prozesse von Edge und Internet Explorer keine Sitzungscookies)
• Solange unklar ist, welcher Server der Authentifizierungsserver ist, mit edge://net-export Netzwerklogs erfassen und die Zielorte der Übergänge ermitteln
• Lässt sich der Authentifizierungsserver partout nicht identifizieren, vorübergehend die Richtlinie „In-Page-Navigation im IE-Modus beibehalten“ verwenden (aber deaktivieren, sobald die Sache geklärt ist)

3. Die Diagnosewerkzeuge beherrschen

Entscheiden Sie anhand von beobachteten Daten, nicht nach Gefühl.

4. Was sich partout nicht beheben lässt, „isolieren“

5. Schritt 2: Ausstiegsmaßnahmen ── Wie die Abhängigkeit verringern

Vergleichstabelle der Muster

★ ist in der Praxis die erste Wahl.

Wie der „Richtwert Aufwand“ zu lesen ist

Die Personenmonate in der Tabelle sind eine Spanne, die von einem einzelnen internen System ausgeht, und keine Zahl, die sich direkt für eine Kalkulation verwenden lässt. Selbst bei demselben Muster kann sich der Wert je nach Bildschirmanzahl, Anzahl der IE-Modus-Ziel-URLs, Art der ActiveX-/BHO-Komponenten, Anzahl der SSO-Pfade, Anzahl externer Anbindungen und Umfang der nötigen Abnahmetests um ein Mehrfaches unterscheiden. Betrachten Sie diese Tabelle als Mittel, um das „relative Gewicht zwischen den Mustern“ zu vergleichen.

Für eine tatsächliche Kalkulation zählen Sie zunächst Folgendes und multiplizieren es mit Ihren eigenen Erfahrungswerten (Umbauaufwand pro Bildschirm, Prüfaufwand für die Authentifizierung pro Pfad), um die Summe aufzubauen:

• Anzahl der Bildschirme und Berichte
• Anzahl der IE-Modus-Ziel-URLs (Ergebnis der Bestandsaufnahme mit Enterprise Site Discovery)
• Art der ActiveX-/BHO-Komponenten und ob jeweils eine Alternative existiert
• Anzahl der Authentifizierungs-/SSO-Pfade
• Dauer des parallelen Betriebs von Alt und Neu
• Anzahl der Regressionstestfälle und der Anteil davon, der eine manuelle Prüfung erfordert

Wo welches Muster passt

Schrittweises Refactoring ist am realistischsten.

• Es ist nicht nötig, sofort alles neu zu bauen
• Bildschirme oder Funktionen lassen sich einzeln modernisieren
• Während der Phase, in der Alt und Neu koexistieren, ist das „Flussdesign“ (welcher Bildschirm mit welcher Engine läuft) entscheidend

WebView2-Wrapper werden eingesetzt, um „die Grenzen neu zu ziehen“.

• Nicht dafür gedacht, ActiveX- oder COM-Abhängigkeiten unverändert zu bewahren
• OS-seitige Zuständigkeiten wie „Dateioperationen“, „Gerätekopplung“ und „Windows-Authentifizierung“ werden auf die native Seite verlagert, während die Web-UI-Seite modernisiert wird
• Zu beachten ist allerdings, dass dadurch die Verantwortung für die Verteilung der WebView2 Runtime entsteht

Micro-Frontends sind nur wirksam, wenn „Team-Grenzen“ und „Deployment-Grenzen“ übereinstimmen. Sie sollten nicht eingeführt werden, nur weil sie gerade im Trend liegen.

Ein komplettes Neuschreiben ist das letzte Mittel. Es kommt nur infrage, wenn die Abhängigkeit von ActiveX oder BHOs so tief ist, dass sich die Anwendung beim besten Willen nicht zerlegen lässt.

6. Schritt 3: Konkretes Vorgehen (Roadmap)

Bewertung → Priorisierung → PoC → Test → Rollout → Betrieb

1. Bewertung ── Bestandsaufnahme der Abhängigkeiten

• Mit Enterprise Site Discovery die Ziel-URLs auflisten
• Mit edge://net-export die Netzwerkübergänge sichtbar machen
• Die Abhängigkeit in „Dokumentmodus“, „ActiveX/BHO“, „Authentifizierung“, „Clientzertifikate“, „Datei/Druck“ und „Gerät/COM“ einteilen

2. Priorisierung ── Wo Sie ansetzen

Sortieren Sie nach folgenden Gesichtspunkten:

• Wichtigkeit (danach, wie problematisch ein Ausfall wäre)
• Anzahl der Nutzer
• Sicherheitsexposition
• Ausmaß der Auswirkungen auf andere Systeme
• Wie leicht sich eine Funktion herauslösen lässt (ob die Grenzen klar sind)

Trennen Sie insbesondere „Funktionen, die vorankommen, sobald man die Grenze zieht“ von „Funktionen, bei denen die gesamte Grenze verschoben werden muss“ – das erleichtert die anschließende Planung erheblich.

3. PoC (Proof of Concept) ── Klein anfangen

Beginnen Sie mit einem einzigen Workflow, der „hohen geschäftlichen Wert bei mittlerer Abhängigkeit“ bietet.

Die Erfolgskriterien sind die folgenden vier Punkte:

1. Der IE-Modus wird nicht mehr benötigt
2. SSO bleibt erhalten
3. Die Antwortleistung liegt auf einem vergleichbaren Niveau
4. Ein Rollback (Zurücksetzen auf den Ausgangszustand) ist möglich

4. Test ── Mit der Koexistenz von Alt und Neu umgehen

• Moderner Pfad → Automatisierte Edge-Tests mit Playwright
• IE-Modus-Pfad → Diagnoseseite + manuelle Prüfung
• Während der Koexistenzphase ausdrücklich festhalten, „welcher Pfad mit welcher Engine läuft“ (ohne diese Angabe wird die Reproduktion von Fehlern sehr schwierig)

5. Rollout ── Schrittweise ausweiten

• Canary-Verteilung (vorgezogenes Rollout an einen Teil der Nutzer)
• Mit Extended Stable (8-Wochen-Zyklus) ein Prüffenster sichern
• Aktualisierungsintervalle der Sitelist und Anforderungen an Browser-Neustarts in den Betriebsablauf einbauen
• Bei Verwendung der Cloud-Sitelist nicht vergessen, dass eine Edge-Anmeldung Voraussetzung ist

6. Betrieb ── Kontinuierlich reduzieren

• Mit der Feedback-Funktion von Cloud Site List Management von Nutzern hinzugefügte Sites oder Fehlkonfigurationen erfassen
• Einen Betriebszyklus etablieren, der die IE-Modus-Zielliste jeden Monat verkleinert
• „Lebensverlängernde Maßnahmen“ immer zusammen mit „reduzierendem Betrieb“ einsetzen

Der Gesamtablauf (Flussdiagramm)

flowchart TD
    A[Bestandsaufnahme der Zielsysteme] --> B[Abhängigkeiten klassifizieren]
    B --> C{Um welche Art von Abhängigkeit handelt es sich?}
    C -->|Vorwiegend Dokumentmodus/SSO| D[Offizieller IE-Modus-Betrieb]
    C -->|Vorwiegend OS-Integration/COM| E[Wrapper-Ansatz]
    C -->|Lässt sich Bildschirm für Bildschirm trennen| F[Schrittweises Refactoring]
    C -->|Mehrere Teams parallel| G[Micro-Frontends]
    C -->|Abhängigkeit zu tief| H[Komplettes Neuschreiben]

    D --> I[Neutrale Sites und Cookies abstimmen]
    E --> J[WebView2-/native Grenze]
    F --> K[Koexistenz von Alt und Neu, schrittweiser Ersatz]
    G --> K
    H --> L[Neuentwurf auf einer neuen Architektur]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[Automatisierte Tests und Betriebstests]
    N --> O[Schrittweiser Rollout]
    O --> P[Nutzungsdaten und Feedback sammeln]
    P --> Q[IE-Modus-Zielliste verkleinern]
    Q --> R[Entscheidung über die Abschaltung]

7. Schritt 4: Governance ── Der administrative Rahmen

Den IE-Modus als „Ausnahmebetrieb“ schriftlich festlegen

• Für jede neu hinzugefügte IE-Modus-Ziel-URL legen Sie zwingend folgende Angaben fest:
  • Fachlicher Verantwortlicher (wer trägt die Verantwortung)
  • Technischer Verantwortlicher (wer verwaltet es technisch)
  • Ablaufdatum (bis wann der Ausstieg erfolgt)
  • Ersatzplan (wie der Ausstieg erfolgt)
• Liegt die bestehende XML-Sitelist im schema v.1 vor, auf schema v.2 migrieren, das für die IE-Modus-Integration nutzbar ist
• Die Änderungshistorie mit Cloud Site List Management oder einem Konfigurationsmanagement-Tool nachverfolgen

Sicherheitsrelevante Hinweise

• Es ist gefährlich, eine alte Edge-Version fest im Betrieb zu halten → Verwenden Sie die aktuelle Stable-/Beta-Reihe
• Wird eine Prüfzeit benötigt, Extended Stable (8-Wochen-Zyklus) verwenden
• Für die Qualitätsprüfung von GPOs Security Compliance Toolkit und Policy Analyzer verwenden
• Nicht so sehr „Schwachstellen im IE-Modus selbst“, sondern eher „nachlässiger Browserbetrieb drumherum“ führt eher zu Zwischenfällen

Rückwärts vom Zeitplan aus denken

• Ende des IE-Modus-Supports: 2029
• Ende der Edge-/WebView2-Aktualisierungen für Win10 22H2: Oktober 2028

Das sind die „äußeren Eckpunkte der Rückzugsfrist“. Sie sollten zuerst einen rückwärts geplanten Zeitplan erstellen, der die Abhängigkeit vor Support-Ende auf null bringt.

8. Empfohlene Strategie nach Größenordnung

Auch die Personenmonate in dieser Tabelle sind eine Spanne unter denselben Annahmen wie der „Richtwert Aufwand“ in Schritt 2. Weichen die Angaben in der Spalte „Typische Bedingungen“ (Bildschirmanzahl, Komplexität des SSO, Anzahl der Abteilungen) stark von Ihrer eigenen Organisation ab, übernehmen Sie die Werte nicht direkt, sondern bauen Sie sie anhand der Bildschirm- und Pfadanzahl neu auf.

9. Häufige Fehler und Gegenmaßnahmen

10. Zusammenfassung

Standardstrategie = offizieller IE-Modus-Betrieb (Vorbeugung von Zwischenfällen)
           + Sichtbarmachung der Abhängigkeit (Bestandsaufnahme)
           + schrittweise Reduzierung (einzeln aussteigen)

• Bei kleiner Größenordnung schrittweises Refactoring
• Bei großer Größenordnung Sitelisten-Steuerung + Portfoliomanagement
• Bei knappem Budget mit Virtualisierung eindämmen und gleichzeitig neue Abhängigkeiten stoppen
• Ein komplettes Neuschreiben ist der letzte Trumpf
• Container stehen normalerweise nicht zur Wahl, VDI ist ein Unterschlupf, und der IE-Modus ist eine Startbahn (etwas, von dem aus man abhebt)

Referenzlinks

• Lifecycle-FAQ für IE und Edge — Die 2029-Richtlinie für den IE-Modus
• Übersicht über den IE-Modus — Grundlegende Informationen zum Support-Umfang
• Richtlinienkonfiguration des IE-Modus — Die drei Stufen der integrierten Konfiguration
• Enterprise site configuration strategy — Neutrale Sites, Cookie-Freigabe, schema v.2
• Enterprise Mode schema v.2 guidance — Elemente und Beispiele des Sitelist-XML
• Übersicht über die Update-Kanäle von Microsoft Edge — Die Zyklen von Stable und Extended Stable
• IE mode troubleshooting and FAQ — Diagnoseseite, Verwendung von net-export
• Cloud Site List Management — Zentrale Verwaltung im Admin Center
• Enterprise Site Discovery — Ausgangspunkt der Bestandsaufnahme
• WebView2-Dokumentation — Für die Prüfung des Wrapper-Ansatzes
• Azure Virtual Desktop / RemoteApp — Als Isolierungsmaßnahme
• Windows Containers – Migrationsleitfaden — Als GUI-Lebensverlängerungsziel ungeeignet
• App Assure — Umfang der Unterstützung bei der IE-Modus-Konfiguration
• Playwright — Automatisierte Edge-Tests
• single-spa — Grundlagen von Micro-Frontends
• webpack Module Federation — Integration unabhängiger Builds

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wie lange lässt sich der IE-Modus in Edge noch nutzen?

Der IE-Modus in Edge wird mindestens bis 2029 unterstützt, wobei die Richtlinie eine Ankündigung ein Jahr vor der Abschaltung vorsieht. Außerdem laufen die Aktualisierungen von Edge/WebView2 Runtime unter Windows 10 22H2 mindestens bis Oktober 2028. Dieser Zeitraum ist jedoch lediglich eine Frist für einen planmäßigen Ausstieg, und 2029 sollte nicht als Beginn der Vorbereitung, sondern als Termin für den Abschluss des Ausstiegs zurückgerechnet werden. Die IE11-Desktopanwendung selbst ist bereits ausgemustert.

Warum lässt sich die Abhängigkeit vom IE-Modus nicht ablegen?

Der IE-Modus ist ein Mechanismus innerhalb des Chromium-basierten Edge, der ausschließlich alte Sites mit der Trident-(MSHTML-)Engine rendert, und diese Trident-Engine übernimmt den alten Dokumentmodus, ActiveX-Steuerelemente und BHOs, alte Sicherheitszonen-Einstellungen sowie die Kompatibilitätseinstellungen von Enterprise Mode. Solange Sie von diesen Elementen abhängen, löst eine bloße Browser-Aktualisierung das Problem nicht. Der erste Schritt besteht darin, die Abhängigkeit in Dokumentmodus, ActiveX/BHO, Authentifizierung/SSO, clientseitige Integration und veraltete Betriebsannahmen einzuteilen und so herauszufinden, worin sie tatsächlich besteht.

Welche Methoden gibt es, um aus dem IE-Modus auszusteigen?

Die wichtigsten Optionen sind sechs: fortgesetzter IE-Modus-Betrieb, WebView2-Wrapper, schrittweises Refactoring, Micro-Frontends, komplettes Neuschreiben und VDI-/RemoteApp-Isolierung. In der Praxis ist schrittweises Refactoring die erste Wahl, weil sich Bildschirme oder Funktionen einzeln modernisieren lassen. WebView2-Wrapper dienen nicht dazu, ActiveX zu bewahren, sondern dazu, OS-seitige Zuständigkeiten wie Dateioperationen oder Gerätekopplung auf die native Seite zu verlagern und die Grenzen neu zu ziehen. Ein komplettes Neuschreiben ist das letzte Mittel, wenn die Abhängigkeit zu tief ist, um sich zerlegen zu lassen.

Was sollten Sie tun, wenn Sie den IE-Modus vorerst weiter nutzen?

Verwalten Sie zunächst die Sitelist offiziell per Richtlinie, statt das Neuladen den Nutzern zu überlassen. Beim Wechsel zu Cloud Site List Management werden die Verteilung mehrerer Listen, eine Änderungshistorie und Zuweisungen nach Gruppen möglich. Ist SSO im Spiel, konfigurieren Sie neutrale Sites korrekt und richten bei Bedarf die Cookie-Freigabe ein. Legen Sie außerdem für jede neu hinzugefügte IE-Modus-Ziel-URL zwingend einen fachlichen Verantwortlichen, einen technischen Verantwortlichen, ein Ablaufdatum und einen Ersatzplan fest, und verbinden Sie das mit einem Betriebszyklus, der die Zielliste jeden Monat verkleinert.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.