Установка и базовая настройка Windows Server 2025 (с включением брандмауэра, обновлений, ролей)
Каждый проект в нашей лаборатории начинается одинаково: чистый сервер, пустая консоль и куча вопросов о том, что настраивать в первую очередь. Windows Server 2025 — это база, на которой потом вырастет весь остальной стек: контроллер домена, файловый сервер, Hyper-V, RDS. Если фундамент залит криво, все следующие статьи серии дадутся тебе тяжелее, поэтому в этот раз мы не спешим и проходим установку и базовую настройку максимально аккуратно, шаг за шагом, с объяснением, зачем нужен каждый пункт.
Возьмём за основу нашу лабораторную сеть 192.168.10.0/24 и домен itpages.lab.local. Первый сервер, который мы поднимаем, назовём srv-dc01 — в будущем он станет контроллером домена, но в этой статье мы доводим его только до состояния «чистый, обновлённый, безопасный сервер с нужными ролями». Всё остальное — контроллер домена, DHCP, DNS, групповые политики — тема следующих статей серии, и здесь мы намеренно не забегаем вперёд.
Прежде чем начать, стоит договориться о минимальных требованиях. Для лабораторного стенда достаточно 2 vCPU, 4 ГБ оперативной памяти и 60 ГБ диска — этого хватит и под роль контроллера домена, и под базовые сервисы. Для продакшн-окружения цифры считаются исходя из реальной нагрузки, но сам принцип планирования дисков, сети и ролей остаётся тем же. Не поленись заранее набросать таблицу серверов будущей лаборатории: имя, роль, IP-адрес — это займёт пять минут, но избавит от путаницы, когда серверов станет десяток.
Подготовка и установка системы
Скачай ISO-образ Windows Server 2025 (Standard или Datacenter — для лаборатории обычно достаточно Standard с Desktop Experience, если планируешь администрировать через GUI, либо Server Core, если хочешь минимизировать поверхность атаки и держать под рукой только PowerShell). Смонтируй образ на виртуальную машину или физический сервер и запусти установку обычным порядком: язык, редакция, лицензионное соглашение, тип установки «Custom», выбор диска.
На этапе разметки диска, если сервер в перспективе станет файловым или контроллером домена с отдельным томом под базу NTDS и логи, есть смысл сразу выделить второй раздел. Это избавит от необходимости расширять диск на живой системе позже, а заодно упростит настройку резервного копирования — про него мы подробно поговорим в статье про восстановление Active Directory.
После первой загрузки система попросит задать пароль локального администратора. Используй сложный пароль длиной от 14 символов, с буквами разного регистра, цифрами и спецсимволами — впоследствии это будет учётная запись, к которой ты обращаешься в аварийных ситуациях, когда домен недоступен, так что пароль стоит сохранить в менеджере паролей, а не в текстовом файле на рабочем столе.
Активация и часовой пояс
Сразу после установки имеет смысл выставить правильный часовой пояс — расхождение времени между будущими серверами домена приводит к неочевидным ошибкам аутентификации Kerberos, и разбирать их куда неприятнее, чем один раз настроить время сейчас, пока сервер ещё не обслуживает продакшн-нагрузку.
Set-TimeZone -Id "Russian Standard Time"
Get-TimeZone
w32tm /resync /force
Если у тебя есть лицензионный ключ, активируй систему следующей командой; в лаборатории можно временно работать и без активации, но для продакшена откладывать этот шаг не стоит — неактивированная система рано или поздно начнёт напоминать об этом всплывающими окнами и урезанным функционалом.
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /ato
Настройка сетевого адаптера
Серверу нужен статический IP-адрес — DHCP для контроллеров домена и других инфраструктурных серверов не используется принципиально, иначе при перевыдаче аренды весь домен может «уплыть» на другой адрес и стать недоступным для клиентов. Открой PowerShell от имени администратора и настрой сеть:
Get-NetAdapter
New-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress 192.168.10.10 -PrefixLength 24 -DefaultGateway 192.168.10.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 127.0.0.1,192.168.10.1
На этом этапе DNS временно указывает на шлюз или провайдерский DNS — после развёртывания контроллера домена (следующая статья серии) адрес поменяется на локальный DNS-сервер. Проверить, что адрес назначился корректно и сервер видит шлюз, можно так:
Get-NetIPConfiguration
Test-Connection -ComputerName 192.168.10.1 -Count 2
Если в системе несколько сетевых адаптеров (например, отдельный интерфейс для управления и отдельный для трафика виртуальных машин на будущем Hyper-V хосте), переименуй их сразу в понятные имена вроде «MGMT» и «LAN» — команда Rename-NetAdapter сильно упрощает жизнь, когда через полгода приходится разбираться, какой интерфейс за что отвечает.
Переименование сервера и перезагрузка
Дай серверу осмысленное имя — это упростит жизнь тебе и коллегам через полгода, когда в консоли будет полсотни машин, и когда придётся быстро понять, какой srv-xx01 за что отвечает. В нашей лаборатории мы придерживаемся схемы srv-роль-номер: srv-dc01, srv-fs01, srv-hv01, а пограничный маршрутизатор называем rtr-edge01.
Rename-Computer -NewName "srv-dc01" -Restart
Установка обновлений
Свежеустановленный сервер обычно отстаёт от актуальных патчей на несколько месяцев. Установи модуль PSWindowsUpdate и прогони обновления сразу после переименования, до того как сервер получит какую-либо продуктивную роль, — так проще: не нужно останавливать сервисы ради перезагрузки.
Install-Module -Name PSWindowsUpdate -Force
Import-Module PSWindowsUpdate
Get-WindowsUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot
Команда может потребовать несколько циклов перезагрузки — это нормально, крупные накопительные обновления часто тянут за собой ещё один раунд патчей после установки. Запусти команду повторно после каждой перезагрузки, пока Get-WindowsUpdate не покажет пустой список. Заодно стоит настроить расписание автоматических обновлений на будущее — например, через политику отложенной установки в нерабочее время, чтобы обновления не прилетали в разгар рабочего дня и не роняли сервисы неожиданной перезагрузкой.
Настройка брандмауэра Windows
Брандмауэр в Windows Server включён по умолчанию, и это правильно — отключать его «для простоты» не нужно даже в лаборатории, привычка выключать защиту ради удобства почти всегда аукается позже, когда сервер случайно окажется доступен из интернета. Задача администратора — не выключить защиту, а точечно открыть то, что реально требуется. Проверь текущее состояние профилей:
Get-NetFirewallProfile | Select-Object Name, Enabled
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Для удалённого администрирования через RDP и PowerShell Remoting включи соответствующие встроенные правила, но не создавай широких разрешений «на любой IP»:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"
New-NetFirewallRule -DisplayName "RDP from LAN only" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 192.168.10.0/24 -Action Allow
Если сервер будет доступен из других подсетей филиалов, лучше явно перечислить их диапазоны, а не открывать правило на 0.0.0.0/0. Проверить итоговый список активных входящих правил можно командой Get-NetFirewallRule с фильтром по направлению и статусу Enabled — так ты сразу увидишь, не осталось ли лишних разрешений от предыдущих экспериментов.
Установка ролей и компонентов
Роли устанавливаются через диспетчер сервера или PowerShell — второй способ быстрее и легко воспроизводится на других машинах, что важно, если у тебя не один сервер, а десяток однотипных, и ты хочешь получить одинаковый результат на каждом. Посмотри список доступных ролей:
Get-WindowsFeature | Where-Object {$_.InstallState -eq "Available"}
Для будущего контроллера домена нам понадобится роль AD DS, но её мы установим и настроим отдельно в следующей статье, чтобы не смешивать базовую настройку системы с развёртыванием домена — это разные по ответственности этапы, и их полезно держать раздельно даже в документации. Сейчас достаточно поставить базовые инструменты управления:
Install-WindowsFeature -Name RSAT-AD-PowerShell, GPMC -IncludeManagementTools
Если сервер будет файловым (srv-fs01) или сервером виртуализации (srv-hv01), роли ставятся аналогично — просто подставляешь нужное имя фичи, например File-Services или Hyper-V. Про них подробно поговорим в отдельных статьях серии, посвящённых файловому серверу и Hyper-V.
Включение удалённого управления и базовая проверка
Проверь итоговое состояние сервера одной командой — она покажет имя, домен, версию и статус обновлений:
Get-ComputerInfo | Select-Object CsName, WindowsProductName, OsVersion, WindowsBuildLabEx
Также стоит сразу включить удалённый рабочий стол через реестр или графический интерфейс (Свойства системы → Удалённый доступ), если планируешь администрировать сервер не только по PowerShell Remoting. Дополнительно полезно включить сбор минимальных дампов при сбоях и убедиться, что служба Windows Remote Management (WinRM) запущена и настроена на автозапуск:
Enable-PSRemoting -Force
Set-Service -Name WinRM -StartupType Automatic
Get-Service WinRM
Хорошая привычка на этом этапе — сразу настроить отправку событий безопасности и системного журнала в централизованное хранилище, даже если пока это просто увеличенный размер локальных логов. Размер журнала безопасности по умолчанию небольшой, и на активном сервере он переполняется за пару дней:
wevtutil sl Security /ms:1073741824
wevtutil sl System /ms:536870912
Разметка и подготовка дополнительных дисков
Если ты добавил серверу второй виртуальный диск под будущие данные — базу AD, файловые ресурсы или логи — самое время инициализировать его, пока сервер ещё не под нагрузкой. Новый диск в системе появляется в состоянии «не инициализирован», и графический Disk Management тут работает не быстрее PowerShell:
Get-Disk
Initialize-Disk -Number 1 -PartitionStyle GPT
New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter D
Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "Data" -Confirm:$false
Для файлового сервера или контроллера домена размер кластера файловой системы стоит подбирать заранее: для тома под базу NTDS или большие файлы имеет смысл 64 КБ вместо стандартных 4 КБ — это немного экономит на фрагментации и ускоряет последовательное чтение. Указать размер кластера можно параметром -AllocationUnitSize при форматировании. Не забудь также включить теневые копии на новом томе, если он станет файловым хранилищем, — про это подробно поговорим в отдельной статье про файловый сервер.
Базовая локальная политика безопасности
Ещё до присоединения сервера к домену полезно выставить разумную локальную политику паролей и блокировки — впоследствии её заменят доменные групповые политики, но до тех пор сервер должен быть защищён собственными настройками, а не оставаться с политиками по умолчанию:
net accounts /minpwlen:14 /maxpwage:90 /lockoutthreshold:5 /lockoutduration:15
Secedit /export /cfg C:\baseline.inf
Get-Content C:\baseline.inf | Select-String "Password"
Заодно проверь, что Windows Defender включён и получает актуальные сигнатуры — на инфраструктурных серверах его часто отключают «для производительности», но это ошибка: даже базовый realtime-мониторинг ловит значительную часть массовых угроз без ощутимой нагрузки на современном железе:
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Update-MpSignature
Если в организации есть корпоративное антивирусное решение, встроенный Defender можно перевести в пассивный режим, но полностью выключать защиту без замены — плохая идея даже на пару часов настройки.
Проверочный чек-лист перед передачей сервера в эксплуатацию
Прежде чем считать базовую настройку законченной и переходить к следующей статье серии, пройдись по короткому списку — он экономит время на возврат к уже, казалось бы, закрытому этапу:
- Статический IP назначен и совпадает с записью в таблице серверов лаборатории.
- Имя сервера соответствует принятой схеме именования (srv-роль-номер).
- Часовой пояс выставлен верно, время синхронизировано с внешним источником.
- Все доступные обновления установлены, Get-WindowsUpdate возвращает пустой список.
- Брандмауэр включён на всех профилях, лишние правила отсутствуют.
- Дополнительные диски инициализированы и размечены под будущие роли.
- Пароль локального администратора сохранён в менеджере паролей, а не в текстовом файле.
Частые ошибки и как их избежать
- DHCP-адрес на инфраструктурном сервере. Если забыть назначить статический IP, при перезагрузке роутера адрес может смениться, и все зависимые сервисы (DNS, домен, общие папки) станут недоступны по старому адресу. Всегда фиксируй IP вручную или резервированием на DHCP-сервере.
- Пропущенные циклы обновлений. Один запуск Install-WindowsUpdate редко ставит всё сразу — крупные апдейты часто раскрываются только после перезагрузки. Проверяй Get-WindowsUpdate до тех пор, пока список не станет пустым, иначе рискуешь развернуть роль на сервере с известными уязвимостями.
- Отключение брандмауэра целиком вместо точечных правил. Это самая частая причина потом «чинить» безопасность заново. Открывай только нужные порты и, где возможно, ограничивай источник конкретной подсетью, а не всем миром.
- Установка ролей до обновления системы. Роли и компоненты добавляют собственные компоненты в систему, и если ставить их на неполный набор патчей, потом сложнее понять, какие обновления безопасно применять без пересборки роли заново. Обновляй систему в первую очередь, роли — во вторую.
Что дальше
Windows Server редко настраивают одной статьёй — вот темы серии, которые логично изучить следующими: