Как избавиться от зависимости внутренних веб-систем от режима IE

1. Эта статья в двух словах

«Безопасно эксплуатировать режим IE как официально управляемый режим, постепенно сокращая зависимость, и в итоге свести использование режима IE к нулю» — вот реалистичная стратегия. Прежде чем выбрасывать, сначала научитесь этим управлять.

Термины, которые встречаются в статье

Сначала собираем слова, которые дальше появляются снова и снова.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Контекст: до какого момента можно использовать режим IE

Важно держать в голове: то, что режимом IE можно пользоваться до 2029 года, не означает, что можно спокойно оставить всё как есть. Этот период — исключительно «окно для планового выхода», и единственный способ не оказаться в панике накануне 2029 года — начать готовиться уже сейчас.

3. Почему не получается выйти из зависимости от режима IE

Режим IE — это механизм внутри Edge на базе Chromium, который отрисовывает только устаревшие сайты движком Trident (MSHTML). Этот движок Trident берёт на себя следующее:

• устаревшие режимы документа (Document Mode)
• элементы управления ActiveX / BHO (Browser Helper Object)
• устаревшие настройки зон безопасности
• параметры совместимости Enterprise Mode

Пока есть зависимость от этого, одним обновлением браузера проблема не решается. Первый шаг — понять, что именно держит систему.

Частые проблемы на практике

1. Ошибка настройки режима документа → «плывёт» вёрстка, ошибки скриптов
2. Не настроили нейтральные сайты → при SSO (единый вход) циклы повторной аутентификации или циклы перенаправления
3. Не тот формат Enterprise Mode Site List → для связки с режимом IE schema v.1 не поддерживается, нужен переход на schema v.2
4. Edge обрабатывает только один список сайтов → политика на стороне Edge имеет приоритет над политикой на стороне IE

Классификация зависимости: сначала определите, «от чего именно» вы зависите

4. Шаг 1. Продление жизни — сначала безопасная эксплуатация

1. Наладить полноценное управление списком сайтов (самое важное)

Оставлять «перезагрузку в режиме IE» на усмотрение пользователей опасно. Управляйте этим официально, через политику.

Что нужно сделать: перейти на Cloud Site List Management и централизованно управлять тем, кто, какие сайты и до какого срока использует в режиме IE.

Минимальный пример XML списка сайтов

Список пишут в schema v.2 Enterprise Mode Site List, то есть XML с корневым элементом <site-list>. Минимальная конструкция выглядит так.

<site-list version="1">
  <!-- Сайт, который открывается в режиме IE -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- Сервер аутентификации: открывать тем же движком, с которого пришли (нейтральный сайт) -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

На что смотреть при записи:

• В url протокол не пишут. Если указать contoso.local, правило действует и на http, и на https.
• Сайт с <open-in>IE11</open-in> открывается в режиме IE.
• <compat-mode> задаёт режим документа на стороне режима IE (IE8Enterprise, IE7Enterprise, Default и т. п.).
• <open-in>None</open-in> — это нейтральный сайт. Сюда кладут серверы аутентификации.
• version — номер версии списка. После обновления списка значение поднимают.

Групповые политики, которыми список распространяют

Чтобы раздать список сайтов, задают две групповые политики. Обе можно ставить и из «Конфигурации пользователя», и из «Конфигурации компьютера».

В качестве расположения списка можно задать URL по HTTPS (рекомендуется), путь к сетевому ресурсу или путь к локальному файлу. На стороне IE есть политика той же роли — «Use the Enterprise Mode IE website list» (Административные шаблоны > Компоненты Windows > Internet Explorer), но если задана политика на стороне Edge, она имеет приоритет. Так можно, например, всей компании раздавать боевой список политикой IE, а пилотному подразделению — проверочный список политикой Edge.

2. Закрепить настройки аутентификации

Когда в деле SSO, аутентификация часто ломается на переходах между режимом IE и режимом Edge.

Нейтральный сайт (Neutral Site) — это настройка, по которой и в режиме IE, и в режиме Edge сайт открывается «тем же движком, с которого пришли». Если сюда не зарегистрировать промежуточные сайты аутентификации и SSO, в момент перехода со страницы в режиме IE на сервер аутентификации происходит редирект на сторону Edge, и аутентификация не проходит. В документации Microsoft тоже сказано: чтобы режим IE работал корректно, серверы аутентификации и SSO нужно явно настроить как нейтральные сайты.

• Корректно настроить нейтральные сайты → явно указать серверы SSO через <open-in>None</open-in>
• При необходимости настроить совместное использование cookie (по умолчанию процессы Edge и Internet Explorer сеансовые cookie не разделяют)
• Пока неизвестно, какой сервер отвечает за аутентификацию, снимите сетевой журнал через edge://net-export и разберите, куда идут переходы
• Пока сервер аутентификации так и не удаётся определить, временно используйте политику «сохранять навигацию внутри страницы в режиме IE» (но отключите её, как только вопрос будет решён)

3. Освоить диагностические инструменты

Судить нужно не «на глаз», а по наблюдаемым данным.

4. То, что никак не удаётся исправить, — «изолировать»

5. Шаг 2. Стратегии выхода — как сокращать зависимость

Сравнительная таблица паттернов

★ — практический первый выбор.

Как читать «ориентировочные трудозатраты»

Человеко-месяцы в таблице — диапазон на одну внутреннюю систему, а не цифра, которую можно сразу ставить в смету. Даже внутри одного паттерна оценка может отличаться в несколько раз: число экранов, число URL в режиме IE, виды ActiveX / BHO, число путей SSO, число внешних интеграций, объём приёмочных тестов. Считайте таблицу способом сравнить относительный вес паттернов.

Когда оцениваете по делу, сначала посчитайте следующее и умножьте на свою практику (трудозатраты на доработку одного экрана, трудозатраты на проверку аутентификации одного пути).

• Число экранов и число форм/отчётов
• Число URL в режиме IE (результат инвентаризации Enterprise Site Discovery)
• Виды ActiveX / BHO и есть ли у каждого замена
• Число путей аутентификации и SSO
• Как долго старое и новое будут работать параллельно
• Число кейсов регрессионных тестов и доля тех, что нужно проверять вручную

Где применим каждый из паттернов

Поэтапный рефакторинг — наиболее реалистичный вариант.

• Нет необходимости переделывать всё разом
• Можно модернизировать экраны и функции по одному
• В период сосуществования старого и нового важно «проектирование маршрутов» (какой экран работает на каком движке)

Обёртка на WebView2 используется для того, чтобы заново провести границу.

• Не для того, чтобы сохранить зависимость от ActiveX или COM как есть
• Обязанности уровня ОС — «работа с файлами», «взаимодействие с оборудованием», «аутентификация Windows» — переносятся на нативную сторону, а веб-интерфейс модернизируется
• Однако стоит учитывать, что появляется ответственность за распространение WebView2 Runtime

Микрофронтенды эффективны только тогда, когда «границы команд» совпадают с «границами деплоя». Их не стоит внедрять только потому, что это модно.

Полная переработка — крайняя мера. Она нужна лишь в случаях, когда зависимость от ActiveX или BHO настолько глубока, что разобрать систему на части действительно невозможно.

6. Шаг 3. Конкретный порядок действий (дорожная карта)

Оценка → расстановка приоритетов → PoC → тестирование → развёртывание → эксплуатация

1. Оценка — инвентаризация зависимости

• Составить список целевых URL с помощью Enterprise Site Discovery
• Визуализировать сетевые переходы с помощью edge://net-export
• Классифицировать зависимость на «режим документа», «ActiveX/BHO», «аутентификация», «клиентские сертификаты», «файлы/печать», «оборудование/COM»

2. Расстановка приоритетов — с чего начать

Отсортируйте по следующим критериям:

• важность (по степени критичности простоя)
• число пользователей
• уровень подверженности рискам безопасности
• влияние на другие системы
• простота выделения (насколько чётко определены границы)

Особенно полезно заранее разделить «функции, которые продвигаются вперёд, если провести границу» и «функции, которые нужно переносить вместе с границей» — это существенно упрощает дальнейшее планирование.

3. PoC (проверка концепции) — попробовать на малом масштабе

Первую цель выбирайте из категории «высокая бизнес-ценность, умеренная зависимость» — один рабочий процесс.

Критериев успеха четыре:

1. Режим IE больше не нужен
2. SSO сохраняется
3. Производительность отклика сопоставима с исходной
4. Возможен откат (возврат к исходному состоянию)

4. Тестирование — учесть сосуществование старого и нового

• Современный путь → автоматическое тестирование Edge с помощью Playwright
• Путь через режим IE → диагностическая страница + ручная проверка
• В период сосуществования старого и нового нужно явно фиксировать, какой маршрут работает на каком движке (без этого воспроизвести дефект крайне сложно)

5. Развёртывание — расширять постепенно

• Canary-распространение (ранняя выкладка части пользователей)
• Обеспечить окно проверки с помощью Extended Stable (8-недельный цикл)
• Встроить в рабочий процесс интервалы обновления списка сайтов и требования к перезапуску браузера
• При использовании облачного списка сайтов не забывайте, что предпосылкой становится вход в Edge

6. Эксплуатация — продолжать сокращение

• Использовать функцию обратной связи Cloud Site List Management, чтобы выявлять сайты, добавленные пользователями, и ошибки конфигурации
• Поддерживать рабочий цикл, при котором список для режима IE сокращается ежемесячно
• «Меры продления жизни» всегда должны идти в паре с «эксплуатацией на сокращение»

Общая схема (блок-схема)

flowchart TD
    A[Инвентаризация целевых активов] --> B[Классификация зависимости]
    B --> C{Какой тип зависимости?}
    C -->|В основном режим документа и SSO| D[Официальная эксплуатация в режиме IE]
    C -->|В основном интеграция с ОС и COM| E[Переход на обёртку]
    C -->|Можно выделить по экранам| F[Поэтапный рефакторинг]
    C -->|Параллельная разработка нескольких команд| G[Микрофронтенды]
    C -->|Зависимость слишком глубока| H[Полная переработка]

    D --> I[Настройка нейтральных сайтов и cookie]
    E --> J[Граница WebView2/нативный код]
    F --> K[Сосуществование старого и нового, поэтапная замена]
    G --> K
    H --> L[Перепроектирование под новую архитектуру]

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

    M --> N[Автоматическое и эксплуатационное тестирование]
    N --> O[Поэтапное развёртывание]
    O --> P[Сбор данных об использовании и обратной связи]
    P --> Q[Сокращение списка для режима IE]
    Q --> R[Решение о прекращении использования]

7. Шаг 4. Управление (governance) — административная структура

Закрепить режим IE как «режим исключения»

• Для каждого нового URL, добавляемого в режим IE, обязательно указывайте следующее:
  • бизнес-владелец (кто несёт ответственность)
  • технический владелец (кто отвечает за техническую сторону)
  • дата истечения (до какого момента нужно выйти из зависимости)
  • план замены (каким образом выходить)
• Если существующий XML-список сайтов относится к schema v.1, перейдите на schema v.2, которая пригодна для связки с режимом IE
• Отслеживайте историю изменений через Cloud Site List Management или инструмент управления конфигурацией

Аспекты безопасности

• Фиксировать эксплуатацию на старой сборке Edge опасно → используйте актуальные ветки Stable/Beta
• Если нужен период проверки, используйте Extended Stable (8-недельный цикл)
• Для проверки качества GPO используйте Security Compliance Toolkit и Policy Analyzer
• К инцидентам чаще приводит не «уязвимость самого режима IE», а «небрежная эксплуатация браузера вокруг него»

Планирование от конечной даты

• Окончание поддержки режима IE: 2029 год
• Окончание обновлений Edge/WebView2 на Win10 22H2: октябрь 2028 года

Это «внешние рамки срока вывода из эксплуатации». Сначала стоит построить график, спланированный от конечной даты, чтобы свести зависимость к нулю до окончания поддержки.

8. Рекомендуемая стратегия по масштабу

Человеко-месяцы в этой таблице — тот же диапазон, что и «ориентировочные трудозатраты» на шаге 2. Если типичные условия (число экранов, сложность SSO, число подразделений) сильно отличаются от ваших, не подставляйте цифры как есть: заново сложите оценку от числа экранов и числа путей.

9. Частые ошибки и их устранение

10. Итог

Стандартная стратегия = официальная эксплуатация режима IE (предотвращение инцидентов)
           + видимость зависимости (инвентаризация)
           + поэтапное сокращение (выход по одному элементу за раз)

• При малом масштабе — поэтапный рефакторинг
• При крупном масштабе — контроль над списком сайтов + управление портфелем
• При жёстком бюджете — сдерживание через виртуализацию с одновременной остановкой новой зависимости
• Полная переработка — последний козырь
• Контейнеры, как правило, вне рассмотрения, VDI — временное укрытие, а режим IE — взлётная полоса (то, с чего вы должны в итоге взлететь)

Справочные ссылки

• Вопросы и ответы о жизненном цикле IE и Edge — политика в отношении режима IE до 2029 года
• Обзор режима IE — базовый материал об области поддержки
• Настройка политик режима IE — три уровня интегрированной настройки
• Enterprise site configuration strategy — нейтральные сайты, совместное использование cookie, schema v.2
• Enterprise Mode schema v.2 guidance — элементы XML списка сайтов и примеры записи
• Обзор каналов обновлений Microsoft Edge — циклы Stable и Extended Stable
• IE mode troubleshooting and FAQ — диагностическая страница, использование net-export
• Cloud Site List Management — централизованное управление в центре администрирования
• Enterprise Site Discovery — отправная точка инвентаризации
• Документация WebView2 — для оценки подхода с обёрткой
• Azure Virtual Desktop / RemoteApp — как мера изоляции
• Руководство по миграции Windows Containers — не подходит как место продления жизни GUI
• App Assure — область помощи с настройкой режима IE
• Playwright — автоматическое тестирование Edge
• single-spa — основы микрофронтендов
• webpack Module Federation — интеграция независимых сборок

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

До каких пор будет поддерживаться режим IE в Microsoft Edge?

Режим IE в Edge поддерживается как минимум до 2029 года, и о прекращении обещают уведомить за год. Обновления Edge / WebView2 Runtime на Windows 10 22H2 продолжатся как минимум до октября 2028 года. Но этот срок — окно, чтобы планомерно выйти из зависимости, а не повод оставить всё как есть. 2029 год нужно считать сроком завершения выхода и планировать от него назад, а не датой, когда только начинают готовиться. Само десктопное приложение IE11 уже снято с эксплуатации.

Почему не получается выйти из зависимости от режима IE?

Режим IE — это механизм внутри Edge на базе Chromium, который отрисовывает только устаревшие сайты движком Trident (MSHTML). Именно этот Trident берёт на себя старые режимы документа, элементы управления ActiveX и BHO, устаревшие настройки зон безопасности и параметры совместимости Enterprise Mode. Пока есть зависимость от этого, одним обновлением браузера проблема не решается. Первый шаг — разложить зависимость по категориям: режим документа, ActiveX/BHO, аутентификация и SSO, интеграция на стороне клиента, устаревшие рабочие практики — и понять, что именно держит систему.

Какие есть способы выйти из зависимости от режима IE?

Основных вариантов шесть: продолжение эксплуатации в режиме IE, обёртка на WebView2, поэтапный рефакторинг, микрофронтенды, полная переработка и изоляция через VDI / RemoteApp. Практический первый выбор — поэтапный рефакторинг: экраны и функции можно модернизировать по одному. Обёртка на WebView2 нужна не чтобы сохранить ActiveX, а чтобы обязанности уровня ОС — работу с файлами, взаимодействие с оборудованием — перенести на нативную сторону и заново провести границу. Полная переработка — крайняя мера, когда зависимость настолько глубока, что систему нельзя разобрать на части.

Что делать, если режим IE придётся использовать ещё какое-то время?

В первую очередь официально управлять списком сайтов через политику, а не оставлять «перезагрузку в режиме IE» на усмотрение пользователей. Переход на Cloud Site List Management даёт распространение нескольких списков, историю изменений и назначение по группам. Если в деле SSO, корректно настройте нейтральные сайты и при необходимости — совместное использование cookie. Кроме того, для каждого нового URL, который добавляете в режим IE, обязательно указывайте бизнес-владельца, технического владельца, дату истечения и план замены и свяжите это с рабочим циклом, в котором целевой список каждый месяц сокращается.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.