Поддержка Windows Server 2012 R2 полностью закончилась 10 октября 2023 года. Обновления безопасности больше не выходят. Если ваши серверы всё ещё на этой версии, они уже сейчас работают без защиты от новых уязвимостей (и это серьёзная проблема, а не просто формальность).
Текущая ситуация: почему это критично
Короче, ситуация такая. Extended Support для Server 2012 R2 закончился в октябре 2023. Прошло больше двух лет. За это время Microsoft выпустила десятки патчей безопасности для новых версий Windows Server, а 2012 R2 не получил ни одного.
Каждая найденная уязвимость в SMB, RDP, Active Directory, DNS, HTTP.sys, Print Spooler теперь навсегда открыта на ваших серверах 2012 R2. И таких уязвимостей набирается всё больше с каждым месяцем. На самом деле, за 2024-2025 годы было найдено более двух десятков критических уязвимостей в Windows Server, ни одна из которых не была закрыта для 2012 R2.
Тут такое дело. Злоумышленники специально ищут серверы на устаревших ОС. Это лёгкие цели. Сканируешь диапазон IP, находишь Server 2012, используешь публичный эксплойт. Готово. И не нужно быть хакером-гением, достаточно скачать готовый инструмент.
Мой коллега Сергей из Воронежа до последнего тянул с миграцией. На его Fujitsu Primergy RX300 S8 работал файловый сервер на Server 2012 R2. В феврале 2024 через уязвимость в SMB шифровальщик зашифровал 3 терабайта данных. Бэкап был. Но простой составил 4 дня. Клиенты ждали. Убытки считали неделю.
Extended Security Updates: ещё можно успеть
Microsoft предлагает программу ESU (Extended Security Updates). Платная. Для Server 2012 R2 доступны три года ESU:
- Год 1 (октябрь 2023 — октябрь 2024): 75% стоимости лицензии
- Год 2 (октябрь 2024 — октябрь 2025): 75%
- Год 3 (октябрь 2025 — октябрь 2026): 75%
Если честно, платить 225% стоимости лицензии за три года патчей это дорого. За эти деньги можно купить Server 2022 и мигрировать. ESU это временная мера, а не решение.
Вот в чём прикол: если серверы подключены к Azure Arc, ESU можно получить бесплатно. Но это значит привязку к облаку Microsoft и необходимость установки агента Azure Arc на каждый сервер. Для организаций, которые принципиально работают локально, это может быть неприемлемо.
Кстати, третий год ESU заканчивается в октябре 2026. После этого даже за деньги обновлений не будет. Так что ESU это только отсрочка, а не спасение. Если вы сейчас на ESU, считайте это последним предупреждением: мигрируйте, пока есть время и поддержка ещё действует.
Куда мигрировать
Три варианта, на самом деле.
Windows Server 2022. Проверенная версия, поддержка до 2031. Рекомендуется для большинства сценариев. Стабильная, хорошо документированная, все вендоры уже сертифицировали совместимость.
Windows Server 2025. Самая свежая. Поддержка до 2034+. Если железо позволяет и приложения совместимы, это лучший выбор на перспективу. Новые функции безопасности, улучшенная производительность Hyper-V, поддержка горячих патчей (hotpatching) без перезагрузки.
Облако (Azure, AWS). Если железо старое и менять его дорого. Перенести сервисы в облако может быть дешевле покупки нового оборудования. Особенно актуально для компаний с 1-3 серверами, где содержать серверную экономически нецелесообразно.
Обновление на месте (in-place upgrade) с 2012 R2 возможно только до Server 2019. Прямого пути на 2022 нет. Поэтому чистая установка и миграция это единственный правильный вариант. Не пытайтесь обновить 2012 R2 до 2019, а потом до 2022, это путь к проблемам. Каждое промежуточное обновление добавляет риск несовместимости и накапливает мусор в реестре.
Тут такое дело: при выборе между 2022 и 2025 учитывайте совместимость с вашим ПО. Server 2022 уже проверен временем, все основные вендоры (1С, Oracle, SAP) сертифицировали свои продукты. Server 2025 новее, и некоторые вендоры могут ещё не подтвердить совместимость. Уточняйте у производителя вашего критичного софта.
План миграции файлового сервера
Файловый сервер мигрируется проще всего. Знаете что, даже новичок справится, если следовать этому плану.
# На новом Server 2022 устанавливаем роль файлового сервера
Install-WindowsFeature FS-FileServer
# Копируем данные с сохранением прав (Robocopy наше всё)
# Ключи: /MIR зеркало, /SEC права, /B режим бэкапа
# /R:3 три попытки при ошибке, /W:5 пауза 5 секунд
robocopy \OLD-SRVData E:Data /MIR /SEC /B /R:3 /W:5 /LOG:C:migration.log
# Проверяем логи на ошибки
# Обратите внимание на строки с "FAILED"
Get-Content C:migration.log | Select-String "FAILED"
# Проверяем количество скопированных файлов
Get-Content C:migration.log | Select-String "Files :"По факту, Robocopy это лучший инструмент для миграции файловых серверов. Он копирует всё: файлы, папки, NTFS-права, аудит. Ключ /MIR создаёт точное зеркало. Ключ /SEC переносит права доступа. Если копирование прервётся (а при терабайтах данных это случается), просто запустите Robocopy снова, он продолжит с того места, где остановился.
Грубо говоря, план такой: первый прогон Robocopy делаете днём, копируете основную массу данных. Второй прогон ночью перед переключением, он скопирует только изменения (дельту). Утром переключаете DNS-имя на новый сервер. Пользователи приходят на работу и даже не замечают, что сервер другой.
Миграция Active Directory
Контроллер домена на 2012 R2 мигрируется сложнее. Но принцип тот же: ставим новый, переносим роли, выводим старый.
# Проверяем текущий функциональный уровень
# Если уровень 2012 R2, после миграции можно поднять
Get-ADForest | Select-Object ForestMode
Get-ADDomain | Select-Object DomainMode
# На новом сервере 2022 ставим AD DS
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# Повышаем до контроллера домена
Install-ADDSDomainController -DomainName "company.local" -InstallDns:$true
# Ждём полной репликации (может занять от минут до часов)
repadmin /replsummary
# Переносим FSMO-роли на новый DC
Move-ADDirectoryServerOperationMasterRole -Identity "DC-NEW" `
-OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster
# Проверяем, что роли перенеслись
netdom query fsmoСамое важное это FSMO-роли. Перенесли их на новый контроллер, подождали полной репликации, можно спокойно понижать старый. Но не спешите. Оставьте старый DC работающим хотя бы неделю после переноса ролей. Если что-то пойдёт не так, откатиться будет проще.
На самом деле, самая частая ошибка при миграции AD это не проверить репликацию перед переносом ролей. Запустите repadmin /replsummary и убедитесь, что ошибок нет. Если есть, сначала исправьте их, а потом переносите роли.
Миграция DHCP и DNS
Тут такое дело: DHCP мигрируется одной командой.
# На старом сервере экспортируем конфигурацию DHCP
Export-DhcpServer -File C:dhcp-export.xml -Leases
# Копируем файл на новый сервер
# На новом сервере импортируем
Import-DhcpServer -File C:dhcp-export.xml -BackupPath C:dhcp-backup -Leases
# DNS зоны реплицируются автоматически через AD
# Но проверьте зоны прямого и обратного просмотра
Get-DnsServerZoneСовместимость приложений
Это главный вопрос. Будет ли 1С работать? А Oracle? А legacy-приложение, написанное 10 лет назад?
Большинство приложений, работающих на Server 2012 R2, работают и на Server 2022. Исключения:
- Приложения, зависящие от .NET Framework 3.5 (нужно установить компонент отдельно)
- 32-битные приложения с драйверами ядра
- Софт, привязанный к конкретной версии IIS (на 2012 R2 это IIS 8.5, на 2022 это IIS 10)
- Старые версии SQL Server (SQL 2008 и старше не поддерживаются на Server 2022)
- Приложения, использующие устаревшие криптографические алгоритмы (SHA-1, SSL 3.0)
Кстати, перед миграцией разверните тестовый сервер на 2022 и проверьте все критичные приложения. Это обязательный шаг, который сэкономит нервы и время.
Мария, IT-директор строительной компании из Казани, при миграции с 2012 R2 обнаружила, что их система документооборота не работает на Server 2022. Пришлось сначала обновить СЭД, потом уже мигрировать сервер. Хорошо, что проверила на тестовом стенде (Lenovo ThinkSystem ST250), а не на продакшене.
Миграция SQL Server
Если на Server 2012 R2 крутится SQL Server, его тоже нужно обновлять. SQL Server 2012 и 2014 уже не поддерживаются.
# Проверяем версию SQL Server
SELECT @@VERSION
# Бэкапим все базы перед миграцией
BACKUP DATABASE [MyDatabase] TO DISK = 'D:BackupsMyDatabase_migration.bak' WITH COMPRESSION, INIT
# На новом сервере восстанавливаем бэкап
RESTORE DATABASE [MyDatabase] FROM DISK = 'D:BackupsMyDatabase_migration.bak'
WITH MOVE 'MyDatabase' TO 'E:SQLDataMyDatabase.mdf',
MOVE 'MyDatabase_log' TO 'E:SQLLogMyDatabase_log.ldf'На самом деле, для SQL Server миграция через backup/restore самый надёжный способ. Отсоединять базы (detach/attach) рискованнее, потому что если файлы повредятся при копировании, вы потеряете данные без возможности восстановления.
Кстати, при переходе на новую версию SQL Server проверьте уровень совместимости баз данных. Старые базы могут работать на новом SQL Server в режиме совместимости, но для получения новых возможностей (и производительности) стоит повысить уровень совместимости.
Стоимость миграции: считаем бюджет
Грубо говоря, бюджет миграции складывается из:
- Лицензии Windows Server 2022 (Standard или Datacenter)
- CAL-лицензии (User CAL или Device CAL на каждого пользователя/устройство)
- Новое серверное оборудование (если старое больше 7 лет)
- SQL Server лицензия (если используется)
- Рабочее время IT-специалиста на миграцию (от 2 дней до 2 недель)
- Простой во время переключения (обычно 2-4 часа)
Если честно, сравните эту сумму со стоимостью простоя от шифровальщика. Или со штрафом за нарушение ФЗ-152, если персональные данные утекут через непатченный сервер. Миграция всегда дешевле.
Что делать прямо сейчас
Не откладывайте. План действий:
- Составьте список всех серверов на 2012 R2 и запишите роли каждого
- Определите зависимости между серверами (AD, DNS, DHCP, файловые шары)
- Проверьте совместимость приложений с Server 2022 на тестовом стенде
- Купите лицензии. В keytrust24.store есть ключи Windows Server 2022 Standard и Datacenter с моментальной доставкой
- Разверните новые серверы параллельно со старыми
- Мигрируйте, начиная с наименее критичных серверов (файловые, принт-серверы)
- В последнюю очередь мигрируйте контроллеры домена
А ещё обновите железо, если оно старше 7-8 лет. Server 2012 R2 часто работает на серверах, которые уже исчерпали свой ресурс. Новое железо плюс новая ОС это надёжность на следующие 5-7 лет. Диски изнашиваются, блоки питания деградируют, вентиляторы забиваются пылью.
Знаете что? Главная ошибка при миграции это бесконечное откладывание. «Давайте после нового года», «давайте после отчётного периода», «давайте когда Иванов вернётся из отпуска». С каждым днём риск взлома растёт, а задача миграции не становится проще.
Ну и не забывайте про CAL-лицензии. При переходе на новую версию сервера клиентские лицензии тоже нужно обновить. CAL от Server 2012 R2 не подходит к Server 2022. Это отдельная статья расходов, о которой часто забывают при планировании бюджета миграции.
Автоматизация проверки серверов на устаревшие ОС
Короче, если у вас в сети много серверов, можно пропустить какой-нибудь на Server 2012 R2. Вот скрипт, который найдёт все серверы с устаревшими ОС в домене.
# Находим все серверы в AD с устаревшими ОС
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} `
-Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
Where-Object { $_.OperatingSystem -match "2012|2008|2003" } |
Select-Object Name, OperatingSystem, LastLogonDate |
Sort-Object OperatingSystem |
Format-Table -AutoSize
# Экспортируем в CSV для отчёта руководству
Get-ADComputer -Filter {OperatingSystem -like "*Server 2012*"} `
-Properties OperatingSystem, LastLogonDate, IPv4Address |
Export-Csv "C:ReportsOldServers.csv" -NoTypeInformation -Encoding UTF8Мой коллега Павел из Екатеринбурга (администрирует сеть в холдинге из трёх компаний, общий парк 15 серверов) запустил этот скрипт и обнаружил два сервера на Windows Server 2008 R2, о которых все забыли. Один был принт-сервером в подвальном офисе, второй крутил старую версию внутреннего портала. Оба работали без обновлений безопасности уже пять лет. По факту, это были открытые двери в корпоративную сеть.
Миграция Hyper-V виртуальных машин
Если честно, часто Server 2012 R2 работает как хост Hyper-V с кучей виртуальных машин. Миграция в таком случае сложнее, потому что нужно перенести не один сервер, а несколько.
# Экспортируем виртуальную машину с 2012 R2
Export-VM -Name "VM-FileServer" -Path "E:VMExport"
# На новом хосте Server 2022 импортируем
Import-VM -Path "E:VMExportVM-FileServerVirtual Machines*.vmcx" `
-Copy -GenerateNewId
# Если формат конфигурации VM старый (.xml), конвертируем
# Server 2022 автоматически обновит формат при импорте
# Проверяем что VM работает
Get-VM | Select-Object Name, State, VersionВот в чём прикол: при переносе VM со старого Hyper-V версия конфигурации обновляется автоматически. Но обратно понизить нельзя. Поэтому перед импортом убедитесь, что старый хост вам больше не нужен. А ещё проверьте, что Integration Services внутри каждой VM обновлены до актуальной версии. Устаревшие Integration Services могут вызывать проблемы с сетью и производительностью дисков на новом хосте.
