WSUS или Intune для сети без облака?

Если компьютеры не могут обращаться к облачным службам Microsoft, Intune не сможет управлять их обновлениями. Для действительно изолированного контура выбор сводится к WSUS либо к более крупной локальной системе управления, которая использует WSUS как источник метаданных. Это ограничение архитектуры, а не вопрос удобства или привычки администратора.

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

Сначала определите, что именно запрещено

Если запрещено хранить корпоративные данные в облаке, но рабочим станциям разрешен исходящий HTTPS-доступ к службам Microsoft, Intune технически возможен. Политики и состояние устройств будут обрабатываться облачной службой, а пакеты Windows компьютеры обычно получат прямо из Windows Update. Это уже облачное управление, даже если локальные файлы и бизнес-системы остаются внутри организации.

Если запрещен любой обмен управляющими данными с публичным облаком, Intune отпадает. Прокси с белым списком адресов не меняет сути: устройство регистрируется в службе, получает политику и отправляет состояние через интернет. В документации Microsoft Learn по кольцам обновлений прямо указано, что устройствам нужен доступ к конечным точкам Intune и Windows Update. Для Windows Autopatch требуется еще и доступ к его конечным точкам.

Третий режим строже: у сегмента нет даже прямого доступа в интернет, но регламент разрешает перенос подписанных пакетов через промежуточную зону или носитель. Здесь работает WSUS с сервером-источником во внешнем контуре и автономным WSUS внутри. Между ними переносят содержимое и метаданные. Если перенос тоже запрещен, ни WSUS, ни Intune не создадут обновления из воздуха. Организации понадобится отдельная процедура допуска файлов в контур.

Запишите режим одной проверяемой фразой. Например: «Клиенты производственного VLAN не устанавливают исходящие соединения; обновления поступают только с локального узла по HTTPS; перенос между зонами проходит проверку и оформляется заявкой». Такая формулировка сразу исключает Intune и задает требования к WSUS. Фраза «облако не используем» ничего не говорит о маршрутах, телеметрии и разрешенном переносе.

WSUS подходит закрытому контуру, хотя уже не развивается

WSUS дает локальную точку синхронизации, одобрения и раздачи обновлений Microsoft. Клиенты узнают адрес сервера через групповую политику, сканируют каталог, скачивают одобренные пакеты внутри сети и сообщают результат обратно. Администратор может разделить машины на группы и разрешать одно обновление в разные даты.

В сентябре 2024 года Microsoft объявила WSUS устаревшим компонентом. Это слово часто трактуют неверно. Microsoft не добавляет новые функции, но роль остается в поддерживаемых версиях Windows Server, включая Windows Server 2025, и получает исправления по жизненному циклу продукта. Существующую установку не требуется срочно выключать. Новую архитектуру на десять лет вперед тоже не стоит строить так, будто WSUS снова начнет развиваться.

Для закрытой сети этот статус создает неприятный, но рациональный выбор. Рекомендуемые Microsoft облачные средства не выполняют требование изоляции, а поддерживаемый локальный компонент выполняет. Значит, WSUS можно принять как контролируемый технический долг: зафиксировать срок пересмотра, автоматизировать обслуживание, хранить конфигурацию и не связывать с ним функции, которых у него нет.

WSUS управляет обновлениями продуктов Microsoft, доступными через Microsoft Update. Он не превращается в полноценное управление конечными устройствами. Инвентаризация стороннего ПО, развертывание любых приложений, удаленные действия и сложная оркестрация потребуют других средств. Смешивать вопрос доставки исправлений Windows с вопросом полного управления рабочим местом удобно на презентации, но вредно в проекте.

Еще одна граница проходит между WSUS и Microsoft Configuration Manager. Configuration Manager использует точку обновления программного обеспечения, связанную с WSUS, но добавляет коллекции, окна обслуживания, развертывания, расширенную отчетность и распространение содержимого. Для 300 обычных офисных ПК один только объем редко оправдывает такую систему. В регулируемом производстве или при наличии уже действующей инфраструктуры Configuration Manager требования могут оправдать ее независимо от размера парка.

Инфраструктура WSUS мала, а уход за ней постоянен

Для 300 клиентов обычно достаточно одного локального WSUS на поддерживаемом Windows Server, если между площадками есть надежная связь и один отказ не нарушает обязательный срок установки. Серверу нужны роль WSUS, IIS, база Windows Internal Database либо SQL Server и хранилище содержимого. Точный размер диска нельзя честно назвать без списка продуктов, языков, драйверов и типа файлов обновлений. Выбор «скачивать все подряд» быстро делает расчет бессмысленным.

Начните с матрицы того, что реально установлено: версии Windows, Windows Server, Microsoft 365 Apps, языки и архитектуры. Включайте только нужные продукты и классификации. Драйверы через WSUS требуют отдельного решения, поскольку их каталог и жизненный цикл способны сильно увеличить объем и нагрузку на обслуживание. Я обычно оставляю драйверы в процессе управления моделями оборудования, а не одобряю весь класс автоматически.

Установка роли занимает меньше времени, чем приведение ее в рабочее состояние. Нужно настроить TLS, привязки IIS, прокси или вышестоящий сервер, группы компьютеров, GPO клиентов, расписание синхронизации, правила одобрения, резервное копирование и мониторинг. Если филиал связан узким каналом, понадобятся дочерний WSUS, кэш или расписание передачи. Само число 300 не сообщает, находятся ли машины в одном здании или в тридцати удаленных кабинетах.

База SUSDB нуждается в регулярной очистке и переиндексации. Документация Microsoft по обслуживанию WSUS предупреждает, что длительность очистки зависит от ресурсов сервера, выбранных продуктов, классификаций и накопленного мусора. На заброшенной базе первая очистка может идти очень долго. Поэтому обслуживание должно быть заданием по расписанию с журналом результата, а не кнопкой, которую нажимают после жалобы на консоль.

Минимальный эксплуатационный набор выглядит так:

• ежедневная проверка последней синхронизации и ошибок загрузки;
• ежемесячное отклонение замененных и истекших обновлений по утвержденному правилу;
• очистка SUSDB и ненужного содержимого по расписанию;
• резервное копирование базы и сохранение конфигурации IIS и GPO;
• контроль свободного места, очереди IIS и доли клиентов без свежего отчета.

Windows Internal Database подходит небольшому отдельному WSUS, но она не отменяет обслуживание. SQL Server удобнее, если в организации уже есть стандартная платформа резервного копирования и мониторинга SQL. Покупать SQL только ради 300 клиентов обычно нет смысла. Решение зависит от действующих компетенций, а не от попытки сделать WSUS «корпоративнее» дорогой лицензией.

Изолированный сегмент превращает обновление в логистику

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

Microsoft описывает экспорт и импорт метаданных через WsusUtil. Рабочая последовательность для пакета выглядит так:

cd "$env:ProgramFiles\Update Services\Tools"
.\wsusutil.exe export export.xml.gz export.log
# После контролируемого переноса пакета на автономный сервер:
.\wsusutil.exe import export.xml.gz import.log

Файл export.xml.gz содержит метаданные, а не все двоичные пакеты. Каталог WSUSContent нужно перенести отдельно до импорта метаданных. После операции проверьте export.log и import.log, состояние загрузки обновлений во внутренней консоли и применимость на тестовом клиенте. Успешное завершение команды еще не доказывает, что нужный пакет попал на диск и разрешен нужной группе.

Для одиночных исправлений из Microsoft Update Catalog старая кнопка импорта WSUS больше не годится: она зависела от ActiveX. Microsoft заменила этот путь скриптом PowerShell ImportUpdateToWSUS.ps1, которому передают UpdateID. Формат команды из документации выглядит так:

.\ImportUpdateToWSUS.ps1 -WsusServer wsus-gateway -PortNumber 8531 -UseSsl -UpdateIdFilePath C:\Transfer\UpdateIDs.txt

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

На практике больше всего времени съедает не команда, а контроль переноса: кто сформировал набор, кто проверил подписи и антивирусом, какой носитель использовался, какие хэши зафиксированы, кто допустил пакет внутрь и что произошло на пилотных машинах. В организации с формальным межсетевым шлюзом это полноценный ежемесячный процесс. Его трудоемкость надо сравнивать с облачной подпиской, а не считать WSUS бесплатным только потому, что роль входит в Windows Server.

Одобрение и срок установки означают разные вещи

WSUS хорошо отвечает на вопрос «каким группам предложить это обновление», но само одобрение не гарантирует установку к определенному часу. Клиент может быть выключен, не связаться с сервером, ждать окна обслуживания или требовать перезагрузку. Отчет «Needed» означает другую ситуацию, чем «Installed pending reboot», и обе отличаются от клиента, который давно не отправлял статус.

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

Политики Windows Update позволяют задать крайние сроки для качественных и функциональных обновлений, льготный период и поведение перезапуска. Microsoft объясняет, что после эффективного крайнего срока Windows может принудительно перезагрузить устройство независимо от часов активности. Это полезный контроль, но опасный для кассового места, медицинской станции или оператора производства. Сначала разделите устройства по допустимому окну простоя, затем назначайте срок.

Проверить, куда конкретный клиент ходит за обновлениями и какие параметры получил, можно без консоли WSUS:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
  Select-Object WUServer,WUStatusServer,TargetGroup
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' |
  Select-Object NoAutoUpdate,AUOptions,ScheduledInstallDay,ScheduledInstallTime

Ожидаемый результат первой команды содержит адрес локального WSUS в WUServer и WUStatusServer, а при клиентском распределении также имя группы в TargetGroup. Пустые значения или адрес старого сервера объясняют многие случаи «WSUS не видит компьютер». Вторая команда показывает полученную конфигурацию автоматики, но итоговую политику нужно сверять с gpresult, потому что конфликтующие GPO способны переписать значения.

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

Intune убирает сервер, но требует облачные связи

Intune хранит политики управления в облаке и применяет к группам устройств кольца обновлений Windows. Администратор задает отсрочки, крайние сроки, часы активности, уведомления и параметры перезапуска. Отдельные политики могут закреплять версию функционального обновления, ускорять качественное исправление и управлять драйверами. Клиенты получают содержимое из Windows Update, а не с локального сервера Intune.

Поэтому фраза «у Intune нет локального сервера» верна только в бухгалтерском смысле. Инфраструктура перемещается в зависимости: лицензии Intune, регистрация устройств, идентификация пользователей и устройств, разрешенные конечные точки, DNS, TLS-инспекция, прокси и стабильный интернет. Если служба сетевой безопасности не готова поддерживать меняющийся набор адресов Microsoft, экономия на одном Windows Server быстро исчезнет в межкомандных согласованиях.

Microsoft требует интернет-доступ для устройств под управлением Intune. Для колец обновлений нужны как минимум службы Intune и Windows Update, а конкретный набор функций добавляет свои адреса. Разрешить один IP-адрес нельзя считать устойчивой схемой: облачные адреса и сервисные теги меняются. Организации нужен владелец белого списка и процесс изменения правил межсетевого экрана.

Intune дает более удобное назначение политик на динамические группы и лучше подходит ноутбукам, которые редко появляются в офисной сети. Администратору не нужно чистить SUSDB и хранить пакеты. Однако отчет тоже зависит от связи клиента и корректной телеметрии. Команда Pause дойдет только после следующей регистрации устройства; Microsoft отдельно предупреждает, что машина может успеть установить запланированное обновление до получения паузы.

Лицензирование нужно считать по действующему соглашению Microsoft, а не по найденной таблице из старого проекта. Базовой предпосылкой для колец служит Microsoft Intune Plan 1, но состав корпоративных пакетов и права меняются. Для честного сравнения запросите у поставщика строку лицензирования на все 300 управляемых устройств или пользователей и отдельно отметьте функции, которые требуют других подписок.

Если политика организации допускает облачное MDM, но запрещает загрузку каждого пакета через внешний канал, стоит рассмотреть Delivery Optimization и Microsoft Connected Cache в допустимой архитектуре. Они могут уменьшить повторную передачу содержимого. Они не превращают Intune в автономный продукт: клиентам все равно нужны облачные управляющие связи, а кэш надо проектировать и сопровождать.

На 300 машинах труд определяет процесс, а не масштаб

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

У WSUS постоянные работы сосредоточены вокруг сервера и содержимого. Администратор проверяет синхронизацию, просматривает новые обновления, одобряет пилот, следит за загрузкой, чистит базу и разбирает клиентов без статуса. В закрытом контуре добавляются экспорт, проверка, физический или шлюзовой перенос и импорт. Большую часть можно автоматизировать, кроме решения о допуске и реакции на сбой пилота.

У Intune исчезают SUSDB, IIS и локальный каталог. Остаются кольца, назначения, конфликты политик, отчеты, устройства без связи и обращения о перезапуске. Появляются работа с лицензиями, регистрацией, облачными ролями и сетевыми адресами. Если эти процессы уже действуют для Microsoft 365 и Entra, предельная нагрузка невелика. Если организация начинает их только ради обновлений 300 стационарных ПК, проект будет заметно шире настройки патчей.

Для оценки попросите администратора пройти один месячный цикл на пилоте и записать операции, которые требуют решения человека. Не измеряйте время установки пакетов, пока сервер работает сам. Измеряйте разбор ошибок, согласование исключений, подготовку переноса, проверку отчетов и общение с владельцами систем. Именно эти задачи повторятся в эксплуатации.

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

Кольца нужны обоим подходам

Независимо от продукта не отправляйте ежемесячное обновление сразу на все 300 машин. Я бы начал с 10-15 устройств ИТ, затем расширил пилот до 30-50 рабочих мест, которые покрывают модели оборудования и важные приложения, а после выдержки открыл обновление остальному парку. Это проектная отправная точка, не универсальная норма. Размеры групп меняют после нескольких циклов по фактическим сбоям.

Пилот должен отличаться временем, а не качеством проверки. В него входят реальные пользователи и реальные периферийные устройства: печать, сканеры, криптографические средства, VPN, средства защиты и профильные приложения. Пять одинаковых виртуальных машин проверят загрузку Windows, но не обнаружат отказ драйвера токена на рабочем месте бухгалтера.

В WSUS создайте группы IT-Pilot, Business-Pilot и Production, назначайте одобрения последовательно и не смешивайте автоматическое одобрение с немедленной установкой в производстве. Автоматически можно одобрять определения защитных средств или другой согласованный класс, но ежемесячные накопительные обновления разумно пропускать через короткую выдержку. Функциональные обновления Windows ведите отдельным проектом, поскольку их риск и время установки отличаются.

В Intune те же волны реализуют кольца и группы назначения. Не накладывайте несколько колец на одно устройство без ясного приоритета: конфликтующие параметры затрудняют объяснение результата. Для функционального обновления задавайте целевую версию отдельной политикой, а кольцом управляйте поведением установки и перезапуска. Так администратор различает «какую версию предлагаем» и «когда устройство обязано завершить установку».

Критерий перехода между кольцами должен быть записан заранее. Например: нет блокирующего сбоя загрузки и профильных приложений, все доступные пилотные устройства отчитались, владельцы критичных систем подтвердили проверку. Процент успешных установок сам по себе слабый критерий, если оставшийся сбой пришелся на единственную станцию, которая управляет дорогим оборудованием.

Нужен и критерий остановки. При проблемном обновлении WSUS позволяет снять одобрение для следующих групп, но уже установившие его машины не откатятся автоматически. В Intune можно приостановить кольцо, однако команда зависит от следующего обращения устройства к службе. План восстановления должен существовать до развертывания: удаление пакета, восстановление образа, замена станции или временный обход в приложении.

Отчет должен доказывать результат по каждой машине

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

WSUS показывает состояния по обновлениям и компьютерам, но его отчеты требуют дисциплины. Удаляйте или выводите из области старые объекты, следите за дубликатами после клонирования, задайте порог устаревшего контакта. Для расследования на клиенте используйте журналы Windows Update и фактическую историю пакетов. Команда ниже дает список последних установленных исправлений, но не доказывает применимость отсутствующего пакета:

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 15 HotFixID,InstalledOn,Description

Это важное различие: инвентаризация установленных KB и оценка соответствия не равны. Накопительное обновление может заменять более старый KB, поэтому простая проверка одного номера иногда дает ложное нарушение. WSUS или служба Windows Update оценивает применимость с учетом версии, архитектуры и цепочки замены. Для аудита храните правило, по которому система считала устройство соответствующим на дату отчета.

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

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

Решение принимают по сетевой границе

Если у всех 300 компьютеров есть разрешенный прямой доступ к службам Microsoft и организация принимает облачное управление, Intune обычно снижает локальную эксплуатационную нагрузку. Особенно это заметно на ноутбуках вне корпоративной сети и при уже действующих Entra ID, Intune и процессах лицензирования. Покупать и внедрять Intune только ради одного закрытого VLAN нелогично.

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

Если сегмент физически или логически изолирован, используйте пару внешнего и внутреннего WSUS с регламентированным экспортом, переносом и импортом. Сразу включите стоимость этой процедуры в трудозатраты. При жестких окнах обслуживания, сложной отчетности и развертывании стороннего ПО оцените Configuration Manager или другую локальную систему, но не называйте Intune автономным вариантом.

Перед закупкой проведите проверку на 10-20 разнородных машинах. Для WSUS подтвердите сканирование, скачивание, отчет, крайний срок и восстановление после неудачного пакета. Для Intune подтвердите регистрацию через действующий прокси, доступ ко всем нужным конечным точкам, получение политики, загрузку содержимого и полноту отчета. Пилот должен пройти в тех же сетевых правилах, что и производство.

GSE.kz как системный интегратор может помочь спроектировать локальную инфраструктуру и поставить серверы для такого контура, не привязывая решение к одному производителю компонентов. Но решение о WSUS или Intune все равно начинается с подписанной схемы потоков данных. Без нее любой расчет на 300 машин будет точным ответом на неверно поставленный вопрос.

Мой выбор для заявленного условия «без выхода в облако» прост: WSUS, если под условием действительно понимается запрет облачных соединений. Я бы одновременно записал его статус устаревшего компонента как риск, назначил владельца обслуживания и ежегодно пересматривал доступные локальные варианты. Если заказчик на самом деле разрешает ограниченный интернет и облачную регистрацию, сравнение нужно открыть заново: тогда Intune становится сильнее, особенно для мобильных устройств, но это уже другая граница доверия.