АйТи Фреш
Главная / Статьи / Windows и рабочие места
Windows и рабочие места

Почему OSConfig в Windows Server 2025 возвращает настройки обратно и как развести его с групповыми политиками

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~22 мин чтения
Почему OSConfig в Windows Server 2025 возвращает настройки обратно и как развести его с групповыми политиками
Иллюстрация к статье «Почему OSConfig в Windows Server 2025 возвращает настройки обратно и как развести его с групповыми политиками».

Сисадмин поправил параметр в gpedit.msc, перезагрузил сервер, ушёл домой — а утром параметр снова в прежнем значении. Или наоборот: настройка честно применилась, продержалась час и уехала обратно. На Windows Server 2025 это почти всегда одно и то же: сервер живёт под security baseline OSConfig, у которого включён drift control, и у параметра теперь два хозяина. Ниже — как я это диагностирую за двадцать минут, как развожу источники управления, почему Remove-OSConfigDesiredConfiguration не возвращает сервер в исходное состояние и что я делаю до применения baseline, чтобы потом было куда откатываться.

Это не глюк платформы — это drift control, и он работает ровно так, как задуман

OSConfig в Windows Server 2025 — не «скрипт, который один раз накатил настройки». Это платформа desired state configuration, встроенная в систему. Когда вы выполняете Set-OSConfigDesiredConfiguration с ключом -Default, сценарий не «отрабатывает и уходит», он остаётся активным. Дальше включается drift control: OSConfig периодически сверяет фактические значения с желаемыми и через refresh-задачу возвращает всё, что отклонилось. Microsoft описывает это прямым текстом в обзоре OSConfig: «OSConfig automatically corrects any system changes that deviate from the desired state. OSConfig makes the correction through a refresh task». То есть ваша ручная правка для платформы — это не новая политика, а дрейф, аварийное отклонение, которое положено исправить.

Второе — про конфликт с групповыми политиками. В документации по baseline есть абзац, который я показываю клиентам чаще всего: «If you're currently configuring the same settings with two different methods, one being OSConfig, expect conflicts. With drift control involved, you must remove one of the sources if the parameters differ, to prevent the settings from constantly changing between sources». Перевод простой: если один и тот же параметр задают и доменная GPO, и OSConfig, и значения разные — настройка будет переключаться постоянно. Не «может быть», а будет. Microsoft не предлагает арбитраж, приоритеты или merge — предлагает убрать один источник.

И третье, самое неприятное для тех, кто ищет «кто главнее». У OSConfig есть модель множественных авторитетов с порядком предпочтения, но выглядит она так: 1) облачный авторитет (Azure Policy), 2) локальный авторитет (Windows Admin Center и PowerShell), 3) любой другой инструмент развёртывания. Групповая политика в этом списке отдельной строкой не стоит — она попадает в «любой другой». Практический вывод: детерминированного арбитра между GPO и OSConfig на локальной машине нет. Кто записал последним — тот и прав, до следующего цикла gpupdate или следующего прохода refresh-задачи. Отсюда и «моргание» параметра, которое так пугает при разборе инцидента.

Диагностируется это парой команд. Их я запускаю первыми на сервере с жалобой «настройка не сохраняется»:

# Установлен ли модуль и какой версии
Get-Module -ListAvailable -Name Microsoft.OSConfig

# Что вообще применено и где отклонения
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  ft Name, @{ Name = "Status"; Expression={$_.Compliance.Status} },
     @{ Name = "Reason"; Expression={$_.Compliance.Reason} } -AutoSize -Wrap

Если модуль стоит и команда возвращает таблицу — сервер под управлением OSConfig, и дальше спорить с gpedit бессмысленно. Смотрите строки со статусом несоответствия: колонка Name называет параметр, а Reason объясняет, чем фактическое значение отличается от желаемого, — это и есть кандидаты на «перебили снаружи».

OSConfig поддерживается только на Windows Server 2025. Если вам кажется, что «то же самое» происходит на 2019 или 2022 — ищите причину в другом месте: в WSUS-политике, в SCM-шаблоне, в скрипте из планировщика или в Defender for Endpoint. OSConfig там просто нет.
Памятка: Это не глюк платформы — это drift control, и он работает ровно так, как задуман — схема
Памятка: Это не глюк платформы — это drift control, и он работает ровно так, как задуман. Открыть схему в полном размере

Разбор из практики: страховой брокер «Полисный двор», 12 рабочих мест, два сервера на 2025

Страховой брокер «Полисный двор»: 12 рабочих мест, домен на одном контроллере, клиенты — физлица и небольшие компании, поэтому персональных данных и сканов договоров в обороте много. Серверов два, оба на Windows Server 2025: DC-01 (контроллер домена, DNS, DHCP, файловые папки) и SRV-01 (1С, SQL Server и терминальный доступ на 10 сессий для брокеров, работающих из дома и с выездов). Летом их приходящий администратор — толковый специалист, без претензий — прочитал про новые baseline и накатил их за один вечер: на DC-01 сценарий DomainController, на SRV-01 — MemberServer. По документации это 347 параметров на контроллер и 344 на рядовой сервер в текущей версии baseline. Перезагрузил, отчитался, уехал в отпуск.

Ко мне обратились через три дня, формулировка была классическая: «сервер живёт своей жизнью». Симптомов было три. Первый: в RDP-сессиях на SRV-01 пропал проброс локальных дисков — брокеры не могли перетащить в терминал сканы полисов и паспортов с ноутбуков. Администратор снял запрет в локальной политике, помогло на полдня, потом запрет вернулся. Второй: доменная GPO задавала текст предупреждения при входе (требование их положения об обработке персональных данных) — текст то появлялся, то исчезал. Третий, самый противный: на SRV-01 периодически отваливалась ночная выгрузка архива договоров на старый сетевой NAS по SMB, причём не всегда, а «когда как».

Разбор занял один вечер. Первые два симптома — ровно та ситуация, о которой предупреждает Microsoft: один параметр, два источника. Проброс дисков в RDP baseline закрывает намеренно, это документированное поведение (в доке даже приведена готовая команда для отката именно этого параметра). Текст предупреждения при входе — параметр, который baseline тоже держит и который при кастомизации требует ручного ввода значения. Ручная правка в gpedit давала эффект до ближайшего прохода refresh-задачи, доменная GPO — до следующего. Настройка «переключалась между источниками», как в документации и написано.

Третий симптом оказался не конфликтом, а прямым следствием baseline: он поднимает минимум до SMB 3.0 и требует подписывания SMB на клиенте и на сервере. NAS у брокера старый, с Samba, где SMB3 формально есть, но подписывание вело себя нестабильно под нагрузкой. Это не «OSConfig сломал» — это «baseline сделал ровно то, что обещал, а инфраструктура к этому не готова». Разница принципиальная: в первом случае лечится разведением источников, во втором — либо обновлением NAS, либо осознанным отклонением от baseline.

Итог по стенду. Пересечений между доменными GPO и baseline на двух серверах набралось 19 параметров, из них реально конфликтующих (разные значения) — 5. Развели за два вечера, по одному окну с перезагрузкой на каждый сервер. Проброс дисков и текст входного баннера отдали OSConfig как единственному источнику, соответствующие настройки из доменных GPO убрали. Для NAS взяли отклонение от baseline на срок до замены железа и записали это в паспорт стенда — с датой и с фамилией директора, который согласовал.

Самая частая ошибка на этом этапе — начать «чинить» правкой в gpedit.msc на самом сервере. Локальная политика проиграет и доменной GPO, и drift control. Вы потратите день, получите пять перезагрузок и вернётесь туда же.
Почему OSConfig в Windows Server 2025 возвращает настройки обратно и как развести его с групповыми политиками — схема
Схема к статье. Открыть схему в полном размере

Инвентаризация пересечений: как за вечер понять, где именно вы столкнулись лбами

Разводить источники вслепую нельзя — вы просто перенесёте конфликт в другое место. Мне нужен список: какие параметры задаёт baseline, какие задают доменные политики, и где эти множества пересекаются. Состав baseline берётся прямо с машины через Get-OSConfigDesiredConfiguration (полный перечень настроек по каждому сценарию также опубликован в репозитории microsoft/osconfig на GitHub). Состав GPO — через Get-GPOReport в XML и парсинг.

# 1. Выгружаем состав применённого сценария в CSV
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Select-Object Name,
    @{n='Status';e={$_.Compliance.Status}},
    @{n='Reason';e={$_.Compliance.Reason}} |
  Export-Csv C:\audit\osconfig_memberserver.csv -NoTypeInformation -Encoding UTF8

# 2. Выгружаем все доменные политики одним отчётом
Get-GPO -All | ForEach-Object {
  Get-GPOReport -Guid $_.Id -ReportType Xml |
    Out-File "C:\audit\gpo\$($_.DisplayName -replace '[\\/:*?"<>|]','_').xml" -Encoding UTF8
}

# 3. Что реально прилетело на конкретный сервер
gpresult /scope computer /h C:\audit\rsop_srv01.html

Дальше — глазами. Автоматического маппинга «имя параметра OSConfig ↔ имя параметра GPO» не существует: имена в baseline человекочитаемые (AuditDetailedFileShare, RemoteDesktopServicesDoNotAllowDriveRedirection), в отчёте GPO — это ADMX-путь или имя политики безопасности. Совпадение ищется по смыслу. Звучит как ручной труд, и это он и есть, но для стенда на два-три сервера это один вечер, а не проект.

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

Не удаляйте настройку из GPO «на всякий случай», если она есть только в GPO и её нет в baseline. Разводить нужно именно пересечения. Массовая чистка политик под предлогом «теперь всем управляет OSConfig» — это отдельный инцидент, который вы устроите себе сами.

Правильное отклонение от baseline — не gpedit, а Set-OSConfigDesiredConfiguration

OSConfig не запрещает вам менять свои значения. Он запрещает менять их мимо себя. Для точечной кастомизации есть штатный путь — задать другое значение конкретной настройки внутри сценария, сохранив при этом контроль отклонений. После этого refresh-задача будет держать уже ваше значение, а не дефолтное значение baseline. Именно этого люди пытаются добиться правкой реестра — только здесь без вечных откатов. В примере из документации Microsoft аудит доступа к общим папкам (AuditDetailedFileShare) меняют с дефолтного значения 2 на 3.

# Изменить значение конкретной настройки внутри применённого сценария
Set-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WindowsServer/2025/MemberServer `
  -Setting AuditDetailedFileShare -Value 3

# Проверить, что новое значение принято
Get-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WindowsServer/2025/MemberServer `
  -Setting AuditDetailedFileShare

Отдельно про проброс дисков в RDP — это настолько частый вопрос, что Microsoft вынесла готовую команду прямо в раздел «чего ожидать после применения baseline». Обратите внимание: в этом конкретном примере в документации используется ключ -Name, а в разделе кастомизации — -Setting. Единого написания в доке нет, и это не придирка: команда с неверным ключом у вас просто не отработает. Я перед первым применением всегда сверяю фактический синтаксис на самой машине через Get-Command Set-OSConfigDesiredConfiguration -Syntax — это надёжнее любой статьи, включая эту.

# Вернуть проброс локальных дисков в RDP (пример из документации Microsoft)
Set-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WindowsServer/2025/<ВашаРоль> `
  -Name RemoteDesktopServicesDoNotAllowDriveRedirection -Value 0

# Сверить реальный синтаксис установленного модуля
Get-Command Set-OSConfigDesiredConfiguration -Syntax

Ещё одна мелочь, на которой спотыкаются в первый раз: часть настроек при кастомизации требует интерактивного ввода значения. Это MessageTextUserLogon, MessageTextUserLogonTitle, RenameAdministratorAccount и RenameGuestAccount. Команда остановится и будет ждать, пока вы введёте текст и нажмёте Enter. В интерактивной сессии это нормально, а вот в скрипте развёртывания или в задании планировщика вы получите зависший процесс. Такие настройки я выношу из автоматизации отдельным ручным шагом чек-листа.

Если параметр нужен вам иным на всех серверах — задавайте его через OSConfig и убирайте из GPO. Если параметр нужен только на одном сервере — тем более через OSConfig: доменная политика для одного хоста порождает WMI-фильтры и отдельные OU, которые потом никто не помнит.
Порядок действий: Правильное отклонение от baseline — не gpedit, а Set-OSConfigDesiredConfiguration — схема
Порядок действий: Правильное отклонение от baseline — не gpedit, а Set-OSConfigDesiredConfiguration. Открыть схему в полном размере

Remove не значит откат: почему я делаю снимок конфигурации до применения baseline

Это место, где ожидания расходятся с реальностью сильнее всего. Логика админа понятна: применил — не понравилось — удалил — вернулось как было. С OSConfig так не работает, и Microsoft честно об этом пишет: при удалении baseline, когда OSConfig возвращает параметры безопасности, он не может гарантировать, что они вернутся к состоянию до управления. Результат зависит от конкретной настройки. Там же оговорка, что это поведение соответствует возможностям политик Microsoft Intune — то есть это не баг реализации, а принятая модель.

Почему так. Baseline трогает сотни параметров в разных подсистемах: реестр, локальная политика безопасности, расширенный аудит, конфигурация SMB, TLS-провайдеры, VBS и Credential Guard, брандмауэр. Для части из них «состояние до» — это вообще не значение, а отсутствие значения, а для части откат означал бы понижение уровня защиты. Платформа выбирает предсказуемость применения, а не полноту отката. Практический вывод жёсткий: сервер после Remove-OSConfigDesiredConfiguration — это не «сервер как раньше», а «сервер в третьем, ранее не существовавшем состоянии».

Поэтому мой регламент простой и без исключений: снимок конфигурации до применения. На виртуалках это снапшот; контроллер домена я снимаю на выключенной машине и держу в голове, что откат DC из снапшота при нескольких контроллерах — отдельный риск для репликации, даже при поддержке VM-GenerationID гипервизором. Плюс, независимо от снапшота, текстовые бэкапы, которые можно сравнить дифом через месяц:

New-Item -ItemType Directory -Force C:\audit\before | Out-Null

# Локальная политика безопасности
secedit /export /cfg C:\audit\before\secpol.inf

# Расширенный аудит
auditpol /backup /file:C:\audit\before\auditpol.csv

# Брандмауэр и SMB
netsh advfirewall export C:\audit\before\firewall.wfw
Get-SmbServerConfiguration | Export-Clixml C:\audit\before\smbserver.xml
Get-SmbClientConfiguration | Export-Clixml C:\audit\before\smbclient.xml

# Ключевые ветки реестра
reg export "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" C:\audit\before\lsa.reg /y
reg export "HKLM\SOFTWARE\Policies\Microsoft" C:\audit\before\policies.reg /y

Отдельно про пароль локального администратора. После применения baseline для ролей MemberServer и WorkgroupMember вы обязаны сменить пароль локального админа — новый должен удовлетворять требованиям сложности и быть не короче 14 символов. Это документированное требование, а не рекомендация. Если у вас в стенде остались рабочие процессы, где локальный админ используется для служб или скриптов — планируйте смену заранее, иначе получите неработающую службу в самый неудачный момент.

Если вам нужен именно гарантированный откат — единственный честный механизм это снапшот или полноценный бэкап системного состояния. Remove-OSConfigDesiredConfiguration к таким механизмам не относится, и рассчитывать на него как на кнопку «отменить» нельзя.

Перезагрузки, версии baseline и обновления модуля

Про перезагрузки в документации сказано аккуратно, и это важно для планирования окна. При применении и при удалении baseline перезагрузка обязательна — без неё изменения не вступят в силу полностью. А вот при кастомизации отдельного параметра перезагрузка может понадобиться, а может и нет: зависит от того, какую функцию безопасности вы правите. Моя тактика: правку одного параметра делаю без окна, но проверяю фактическое состояние подсистемы после применения, а не только вывод Get-OSConfigDesiredConfiguration. Например, поменяли параметр RDP — зашли в новую сессию и проверили руками.

Версионирование baseline устроено неочевидно, и это ловушка. Сами baseline версионируются и едут внутри PowerShell-модуля Microsoft.OSConfig. Более новый модуль приносит более новую версию baseline, которая полностью замещает предыдущую, а не накатывается поверх как инкрементальный патч. При этом имя сценария версии не содержит: SecurityBaseline/WindowsServer/2025/MemberServer всегда означает «текущая версия baseline из установленного у вас модуля». То есть одна и та же команда на двух серверах с разными версиями модуля даст разный набор настроек.

Масштаб расхождения между версиями не косметический. По changelog Microsoft, число настроек выросло: у контроллера домена с 319 до 347, у рядового сервера с 318 до 344, у workgroup-сервера с 294 до 319. Три десятка новых параметров — это вполне достаточно, чтобы поймать новый конфликт с GPO там, где вчера всё было тихо. Поэтому обновление модуля я приравниваю к изменению конфигурации: сначала пилот на одном некритичном сервере, потом остальные.

# Узнать установленную версию модуля
Get-Module -ListAvailable -Name Microsoft.OSConfig

# Обновление на новую версию baseline
Update-Module -Name Microsoft.OSConfig
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Default
# при наличии ранее применённой версии будет запрос на её удаление — подтвердить
# затем перезагрузка

Полезно знать и параметры самого контроля отклонений. В модуле есть отдельные командлеты Get-OSConfigDriftControl и Set-OSConfigDriftControl: первый показывает, включён ли drift control и с каким периодом работает refresh-задача, второй меняет период. На время разбора конфликта я не выключаю контроль, а сначала смотрю период — он объясняет, через сколько «моргает» параметр. Синтаксис, как и везде в этом модуле, сверяю на машине, потому что ключи между версиями модуля менялись.

# Состояние и период drift control
Get-OSConfigDriftControl

# Точный синтаксис установленной версии модуля
Get-Command Set-OSConfigDriftControl -Syntax

И маленькая, но полезная деталь для тех, у кого серверы без выхода в интернет (в небольших компаниях это частая история): модуль ставится и офлайн. Можно скачать nupkg с PowerShell Gallery руками, можно положить модуль на файловую шару через Save-Module и подтянуть оттуда Import-Module. Второй вариант мне нравится больше — он же даёт единую версию модуля на всём парке, что напрямую решает проблему «на разных серверах разный baseline под одним именем».

Зафиксируйте версию модуля Microsoft.OSConfig в паспорте стенда рядом с версией ОС. Без этой записи через полгода вы не сможете объяснить, почему два одинаковых сервера с одинаковой командой применения ведут себя по-разному.
Памятка: Перезагрузки, версии baseline и обновления модуля — схема
Памятка: Перезагрузки, версии baseline и обновления модуля. Открыть схему в полном размере

Что ломается сразу после baseline, а где страхи преувеличены

Ниже — список из практики: что реально придётся чинить в первые сутки после применения baseline. Порядок — по частоте обращений от пользователей, а не по значимости для безопасности: сначала лечу то, что мешает людям работать, потом всё остальное.

Теперь про страхи. Самый распространённый — «OSConfig развалит нам разделение административных уровней и мы потеряем доступ». Здесь я скорее успокою: baseline не переписывает членство в группах и не трогает вашу структуру OU. Но он действительно включает фильтрацию UAC для удалённых подключений локальных учётных записей (локальный админ, зашедший по сети, получает токен обычного пользователя), требует подписывания SMB и ужесточает делегирование учётных данных. Если ваши процедуры сопровождения построены на локальных админах и psexec — они перестанут работать, и это будет выглядеть как «сломался доступ». Лечится не снятием baseline, а переходом на доменные учётки и нормальный jump-host.

Второй преувеличенный страх — «drift control будет постоянно откатывать наши изменения, и мы потеряем управление». Не будет, если у параметра один хозяин. Drift control откатывает только то, что входит в применённый сценарий, и только когда фактическое значение разошлось с желаемым. Всё, чего в baseline нет, живёт как жило: ваши GPO по установке принтеров, сопоставлению дисков, WSUS и прочему работают ровно так же, как работали.

А вот чего я бы не делал в маленькой инфраструктуре — не применял бы baseline на все серверы разом «чтобы одинаково». Когда серверов два, как у «Полисного двора», пилотом становится тестовая ВМ, развёрнутая из той же сборки, что и рабочий сервер: неделю живу с ней, собираю список отклонений и только потом иду на сервер приложений. Контроллер домена — последним, потому что там цена ошибки самая высокая, а откат, как мы выяснили выше, неполный.

Ошибки трансляции SID в выводе — не повод откатывать baseline. Microsoft прямо указывает, что в специфичных доменных конфигурациях они встречаются, не влияют на остальную часть определения baseline и их можно игнорировать.

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

Можно ли просто отключить drift control и оставить настройки baseline применёнными?

По документации drift control включается вместе со сценарием, а при выключении функции OSConfig отключает и refresh-задачу — после чего система снова становится доступной для правки другими инструментами. Но я не рекомендую этот путь как штатный: вы получаете «однократно применённые 344 параметра», которые дальше никто не контролирует, и через полгода реальное состояние сервера будет неизвестно никому. Лучше оставить контроль включённым и развести источники. Текущее состояние и период refresh-задачи показывает Get-OSConfigDriftControl.

Что сильнее — доменная GPO или OSConfig?

Однозначного арбитра нет. У OSConfig есть порядок предпочтения авторитетов (Azure Policy, затем локальные Windows Admin Center и PowerShell, затем прочие инструменты), но групповая политика в нём отдельной строкой не указана. На практике параметр переключается: gpupdate ставит своё значение, refresh-задача возвращает своё. Именно поэтому Microsoft рекомендует не искать приоритет, а убрать один из источников.

Remove-OSConfigDesiredConfiguration вернёт сервер в состояние до применения baseline?

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

Нужна ли перезагрузка после изменения одного параметра?

Зависит от параметра. При применении и удалении baseline перезагрузка обязательна, а при кастомизации отдельной настройки она может потребоваться в зависимости от того, какую функцию безопасности вы правите. Я всегда проверяю фактическое поведение подсистемы после правки, а не только статус в выводе Get-OSConfigDesiredConfiguration.

Работает ли OSConfig на Windows Server 2019 и 2022?

Нет. Microsoft явно указывает, что OSConfig не поддерживает версии Windows Server ранее 2025. Если похожее поведение наблюдается на 2019 или 2022, причина в другом: старые SCM-шаблоны, скрипты в планировщике, политики Defender for Endpoint или сторонние агенты соответствия.

Как узнать, какая версия baseline применена на сервере?

Имя сценария версию не содержит, поэтому смотреть надо на модуль: Get-Module -ListAvailable -Name Microsoft.OSConfig. Версия baseline едет внутри модуля, и новая версия полностью замещает предыдущую, а не дополняет её. Чтобы серверы вели себя одинаково, версия модуля должна быть одинаковой на всём парке — удобнее всего раздавать модуль с общей файловой шары через Save-Module.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи