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

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

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

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

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

Почему не получается избавиться от зависимости от режима 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

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

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

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

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

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

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

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

• Корректно настроить нейтральные сайты (Neutral Site) → явно указать серверы SSO
• При необходимости настроить совместное использование cookie
• Пока сервер аутентификации точно определить не удаётся, временно использовать политику «сохранять навигацию внутри страницы в режиме IE» (но отключить её, как только вопрос будет решён)

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 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[Решение о прекращении использования]

Шаг 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 года

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

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

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

Итог

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

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

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

• Lifecycle FAQ for IE and Edge — политика в отношении режима IE до 2029 года
• Overview of IE mode — базовый материал об области поддержки
• Configure IE mode policies — три уровня интегрированной настройки
• Enterprise site configuration strategy — нейтральные сайты, совместное использование cookie, schema v.2
• IE mode troubleshooting and FAQ — диагностическая страница, использование net-export
• Cloud Site List Management — централизованное управление в центре администрирования
• Enterprise Site Discovery — отправная точка инвентаризации
• WebView2 documentation — для оценки подхода с обёрткой
• Azure Virtual Desktop / RemoteApp — как мера изоляции
• Windows Containers migration guide — не подходит как место продления жизни GUI
• App Assure — область поддержки настройки режима IE
• Playwright — автоматическое тестирование Edge
• single-spa — основы микрофронтендов
• webpack Module Federation — интеграция независимых сборок

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

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

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

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

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

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

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

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

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

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

Почему не получается избавиться от зависимости от режима 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.