Локальный Exchange или облако: кто отвечает за обновления

За локальный Exchange отвечаете вы: проверяете поддержку, ставите обновления, планируете перезапуск и проверяете восстановление. В Exchange Online обслуживание инфраструктуры выполняет Microsoft, но сбои службы и ваши настройки никуда не исчезают. Ниже разбираю разницу без обещаний «нулевого риска» и показываю, что проверить до решения.

Локальный Exchange: обновление становится вашей работой

Локальный Exchange даёт контроль над размещением и интеграциями, но сопровождение тоже остаётся у владельца. Для Exchange Server важны не только Security Update, но и поддерживаемая версия, накопительный пакет, состояние Windows и Active Directory, резервные копии и план возврата. Microsoft рекомендует перед обновлением проверить резервные копии Exchange и Active Directory, испытать обновление вне рабочей среды, сохранить индивидуальные настройки и перезапустить сервер после установки. Это не прихоть инструкций: Exchange меняет файлы приложения и настройки, а часть локальных изменений может быть перезаписана.

У Exchange Server 2016 и 2019 поддержка завершилась 14 октября 2025 года. После этой даты обычные исправления безопасности для этих версий не предоставляются. Исключение — организации, подключённые к программе Extended Security Update: они имеют право получать определённые обновления безопасности, в том числе выпуски после декабря 2025 года. ESU не превращает старую версию в полноценно поддерживаемый продукт; если организация в программе не участвует, Microsoft указывает путь на Exchange Server Subscription Edition (SE) или миграцию в Microsoft 365. Сначала проверьте статус и конкретную сборку в таблице Microsoft, а не ориентируйтесь на слова «сервер пока работает».

Для CU Microsoft описывает полную установку продукта: предыдущие CU по очереди ставить не требуется. Но «полный пакет» не значит «без окна работ»: установка требует перезапуска компьютера, а значит, нужно планировать доступность почты. Если у вас несколько серверов в Database Availability Group (DAG), документация описывает перевод обновляемого участника в режим обслуживания и последовательную работу с узлами. Один сервер без избыточности — другая история: его перезапуск пользователи заметят. Я не обещаю, что окно обслуживания волшебно исчезнет от хорошего настроения администратора.

Практический порядок перед работами такой: установить, какая версия и сборка действительно работает; проверить применимые обновления и дополнительные действия в Health Checker; посмотреть совместимость надстроек и интеграций; проверить доступность и читаемость резервной копии; провести обновление на тестовой системе; назначить окно, проверить почтовый поток и клиентский доступ после перезапуска. Если резервную копию ни разу не восстанавливали, это пока надежда, а не план восстановления. Для такого разбора и перехода можно заказать аудит корпоративной почты.

Exchange Online: обслуживание у Microsoft, ответственность разделена

В Exchange Online компания не устанавливает CU на сервер Microsoft и не перезапускает его по собственному графику. Обслуживание платформы выполняет поставщик; клиент не устанавливает серверные обновления вручную. Но это не универсальная кнопка «защищено мгновенно»: детали обслуживания и защиты зависят от конкретной проблемы и условий службы. В локальной среде исправление нужно установить самостоятельно, а в гибридной конфигурации оставшиеся локальные серверы всё равно требуют обновлений безопасности. «Почтовые ящики уже в облаке» не означает, что оставленный Exchange можно бросить без патчей.

Облако меняет того, кто отвечает за физические серверы и обслуживание службы, но не отменяет работу администратора организации. Остаются учётные записи, многофакторная аутентификация, права доступа, транспортные правила, доменные записи, устройства пользователей и план восстановления данных. Также остаётся зависимость от доступности интернет-канала и самой службы. Microsoft публикует состояние Exchange Online в Service health центра администрирования Microsoft 365 и описывает инциденты службы; при сбое клиенту нужно смотреть сообщения по своему tenant и статус конкретных функций. Фраза «Microsoft всё чинит» не помогает пользователю, которому надо отправить счёт прямо сейчас.

В облаке вы отдаёте поставщику часть контроля над техническим графиком обслуживания. Это плата за то, что ваша команда не обновляет серверную ОС и Exchange вручную. При этом нельзя честно заявить, будто любой сбой затронет все ящики одновременно или что инциденты гарантированно длятся часами: масштаб и длительность зависят от события. Для сравнения смотрите на договорные обязательства и отчёты о доступности, а не на единичный громкий инцидент. И не смешивайте SLA со стопроцентной доступностью: это условия сервиса, а не обещание, что почта никогда не остановится.

Наконец, Exchange Online сам по себе не равен «безопаснее при любых настройках». Актуальная облачная платформа снимает с вашей команды часть задач обновления сервера. Защита конкретного ящика всё равно зависит от защиты входа, администрирования, правил пересылки и резервирования тех данных, которые вы обязаны сохранять. Если локальный сервер годами не обновляли, это серьёзный аргумент пересмотреть архитектуру; это не доказательство статистического превосходства облака во всех организациях. Сравнивайте реальные процессы и риски своей среды, а не придуманные коэффициенты атак.

Кейс студии «Жасмин-М»: что показывают цифры простоя

В исходном кейсе студии «Жасмин-М» указаны примерно 30 сотрудников, Exchange 2016 и обновление, на которое администратор отвёл вечер пятницы. В описании фигурируют около четырёх часов на работы и ещё шесть часов восстановления из резервной копии. Я оставляю эти цифры как параметры именно этого кейса, не как норматив для Exchange и не как прогноз для вашей компании. Время установки зависит от версии, состояния сервера, объёма проверок и того, что именно пришлось восстанавливать.

Важно не приписывать повреждение базы самому обновлению без подтверждённого разбора причин. Обновление, перезапуск и обнаруженная после работ неисправность могли совпасть по времени, но последовательность событий ещё не устанавливает причину. В редакции исходную причинную связку убираю: достоверный вывод здесь скромнее — проверка восстановления и заранее подготовленный план существенно важны. Если бэкап оказался непригоден или процедура восстановления не отработана, плановое окно легко превращается в длинный инцидент. Это достаточно неприятно и без драматических украшений.

Для студии выбор облака мог снять с её команды установку CU и обслуживание почтовых серверов. Оценивать переход стоит по сценарию переноса без простоя, а не по обещанию, что простоя не будет совсем. Он не доказывает, что переезд гарантирует ноль часов простоя, автоматически возвращает потерянные сделки или всегда заканчивается за два дня. Сам перенос включает инвентаризацию ящиков и общих ресурсов, настройку домена и маршрутизации, перенос данных, проверку доступа на компьютерах и телефонах, а затем разбор ошибок синхронизации. Если оставить прежний локальный сервер ради управления каталогом или гибридной схемы, обновлять его всё равно придётся.

Я оцениваю такой кейс не по красивому «до/после», а по измеримым вещам: сколько ящиков перенесли, какие общие ящики и календари проверили, сколько писем осталось в очереди, кто подтвердил получение и отправку тестовых сообщений, что делать при ошибке DNS. В публикации о студии нет подтверждения финансовых потерь, поэтому говорить о потерянных сделках как об установленном результате нельзя. После смены платформы полезна отдельная сверка почты после переноса. Урок проще: выделенное окно и рабочее восстановление надо проверить до изменения почтовой системы, а при миграции вести сверку после переноса.

Сравниваем расходы: сервер, работа людей и подписка

У локальной системы расходы не заканчиваются на покупке лицензии. В расчёт входят серверное оборудование или виртуальная площадка, лицензирование Exchange и Windows, электричество, резервное копирование, мониторинг, защита доступа, обновления и время специалиста. Для коммерческого использования Exchange Server предусмотрены серверные и клиентские лицензии; детали зависят от редакции, прав доступа и текущих лицензионных условий. Поэтому «сервер уже купили» — не полный расчёт стоимости владения. Это только одна строка сметы, иногда не самая большая.

У Microsoft 365 вместо части расходов на собственную инфраструктуру появляется регулярная подписка на пользователей и административная работа вокруг облачной среды. В стоимость тарифа входят определённые возможности и ограничения, которые надо сверять по выбранному плану и региону покупки. Нельзя без расчёта обещать, что облако всегда дешевле: у компании могут быть большие ящики, дополнительные требования к хранению, лицензии безопасности или интеграции. С другой стороны, локальная система тоже не становится бесплатной после установки. Сравнивайте горизонт в несколько лет: лицензии, сопровождение, резервирование, простой, миграцию и планируемое обновление оборудования. Для бюджета пригодится сравнение стоимости корпоративной почты.

Для небольшой организации я обычно прошу выписать не только ежемесячный платёж, но и часы команды. Кто реагирует на бюллетень безопасности? Кто проверяет, применим ли он к установленной сборке? Кто может начать восстановление вечером или в выходной? Если ответ — один занятой сотрудник без подмены, это риск концентрации, а не экономия. Если на сервере есть резервирование, понятный график обновлений и компетентный администратор, локальная схема может быть оправдана. Важно оплатить реальный процесс, а не только строку «сервер».

Когда оставить Exchange у себя, а когда готовить переход

Локальное размещение имеет смысл рассматривать, если для него есть конкретная причина: обязательное условие по размещению данных, интеграция с внутренней системой, которую нельзя безопасно перестроить, или уже поддерживаемая архитектура с резервированием и ответственными специалистами. Требование хранить данные «внутри страны» надо проверять по применимым правилам и условиям выбранного сервиса. Microsoft описывает географию хранения данных и, в определённых планах, средства выбора географического расположения; это не универсальная гарантия для любой страны, тарифа и набора данных. Попросите юриста и поставщика подтвердить требования до проекта.

Миграция не всегда означает полное удаление локального Exchange. В гибридной среде или при сохранении синхронизации локального каталога могут остаться серверные компоненты и административные инструменты. Microsoft отдельно предупреждает: если организация переносит ящики в Microsoft 365, но продолжает управлять пользователями через синхронизацию с Active Directory, ей может понадобиться оставить Exchange-сервер. Любой оставшийся сервер должен получать нужные обновления. Этот нюанс меняет и оценку безопасности, и бюджет поддержки: гибрид нельзя посчитать как «переехали — сервер выключили», пока не проверена схема управления получателями.

Сам срок переноса нельзя обещать только по числу сотрудников. На него влияют размер и количество ящиков, скорость канала, исходная система, состояние каталога, сложность маршрутизации, объём общих ящиков и время на контроль пользователей. Microsoft публикует ориентиры по длительности операций миграции и прямо отмечает, что результат конкретной среды может отличаться. Поэтому ответ на вопрос «успеем ли за выходные?» появляется после обследования и пробного переноса, а не из таблицы с числом сотрудников. Планируйте отдельное время на подготовку, перенос и проверку.

Мой короткий фильтр решения такой: есть обязательное локальное требование и кто-то реально отвечает за обновления и восстановление — оцениваем обновление Exchange SE и стоимость поддержки; нет такого требования и команда не хочет сопровождать почтовый сервер — считаем миграцию в Exchange Online. В обоих случаях проверяем, где будут данные, какие компоненты останутся локально, как восстановить нужную информацию и кто принимает решение при инциденте. Я выбираю не «облако всегда» и не «свой сервер надёжнее», а вариант, у которого владелец понимает свои обязанности и способен их выполнить.

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