Начиная с Windows Server 2008 стал доступен режим Server Core, преимуществами которого являются снижение времени простоя сервиса (например, по причине установки Windows Updates и последующей перезагрузки) а также снижение площади потенциальных атак (львиная доля которых приходится на Explorer и т.п.).
Идея задравая — зачем на сервере Internet Explorer, Windows Media Player и т.п. понять было сложно.
Кроме того, все это счастье потребляет дисковое пространство — размер ОС, обслуживающей сервис мог на порядок превосходить размер сервиса (например AD DS, AD CS, RRAS, etc). Это приводило не только к перерасходам на закупке накопителей, но и увеличивало время простоя при миграциях виртуальных машин, восстановлении из резервных копий и т.п.
С растущей популярностью IaaS провайдеров которые взывают плату за объем и производительность дисковой системы, уменьшение утилизируемого места становится все более актуальным.
В Windows Server 2008 в режиме Server Core было доступно совсем немного ролей: AD DS, AD LDS, DNS, DHCP, File Server, Print Server, IIS, Hyper-V.
Основной проблемой являлось отсутствие .NET, а значит установка Exchange, SharePoint, Dynamics и пр. на «core» сервера была невозможной.
И вот, в Windows Server 2012 Core mode был значительно улучшен и теперь является рекомендованным режимом эксплуатации.
В этой статье я расскажу о Server Core в Windows Server 10, но материал применим и к WindowsServer 2012R2.
При установке нового сервера Server Core Installation будет вариантом по-умолчанию:
После установки, запустим sconfig и зададим базовые настройки:
После этого, посмотрим какие роли и фичи установлены:
Get-WindowsFeature | Where-Object {$_.Installed -eq $True}
Если на сервере не планируется установка 32-х битного ПО, разумно удалить фичу WoW64 Support:
Remove-WindowsFeature WoW64-Support
Удаление этой фичи положительно сказывается на безопасности (зловредное ПО как правило 32х битное) и производительности сервера.
Но если на сервере будет установлен GUI (даже минимальный, который Graphical Management Tools and Infrastructure), WoW64-Support будет нужна.
Теперь, давайте убедимся что сервер занимает около 7Гб дискового пространства:
Get-WmiObject Win32_logicaldisk | ft DeviceId, Size, FreeSpace
.. а объем потребляемой оперативной памяти около 0.5Гб:
Get-Counter 'MemoryCommitted Bytes'
Установка современного сервера подразумевает удаленное администрирование и отсутствие физического доступа (или необходимости такого доступа) с дисплеем, клавиатурой и мышкой.
Администрирование может выполняться как со специального сервера на котором включены необходимые компоненты RSAT, так и с ПК под управлением Windows, на которую RSAT установлены. Но об этом ниже.
Но в ряде случаев необходимо обеспечить возможность непосредственного администрирования не только с помощью PowerShell, но и с помощью Server Manager (Graphical Management Tools and Infrastructure) или даже «полновесного» GUI (Graphical Management Tools and Infrastructure + Server Graphical Shell).
Пример зачем может быть нужен GUI — на bare-metal сервере Device Manager может быть использован для специфичных настроек оборудования, а доступен он только после установки Graphical Management Tools and Infrastructure.
Чтобы включить GUI нужны будут исходники, которые находятся на установочном дистрибутиве, для этого придется подмонтировать дистрибутив к серверу. В большинстве случаев присоединить образ к серверу отсутствует, поэтому можно скопировать папку sources в виде файловой шары на соответствующем сервере.
Установим «минималистичный» GUI:
Install-WindowsFeature Server-Gui-Mgmt-Infra -Source wim:%path%install.wim:4
.. или «полновесный» GUI с Internet Explorer и прочим:
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source wim:%path%install.wim:4
Обратите внимание, суффикс :4 обозначает что в исходниках находятся файлы для всех 4х редакций:
- :1 — Standard Edition Server Core
- :2 — Standard Edition
- :3 — Datacenter Edition Server Core
- :4 — Datacenter Edition
«Минималистичный» GUI выглядит следующим образом:
После установки «минималистичного» GUI размер диска вырастет на ~3Гб, а портребление оперативной памяти практически не изменится:
В случае установки «полновесного» GUI размер диска вырастет на те же ~3Гб, а портребление оперативной памяти практически не изменится.
Обратите внимание, после удаления GUI:
Remove-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell
.. размер диска не уменьшится:
Зато теперь можно устанавливать и удалять GUI без указания исходников:
Разумеется, исходники для GUI можно удалить:
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Remove
.. это уменьшит размер диска:
Если есть желание еще больше уменьшить дисковое пространство, можно удалить все исходники для ролей и фич которые не установлены:
Get-WindowsFeature | Where-Object installstate -eq «available» | Uninstall-WindowsFeature -Remove
Это освободит еще немного дискового пространства:
Разумеется, делать это нужно после установки ролей и фич под которые сервер вводится в эксплуатацию.
Если Вы используете виртуальные машины, не забудьте выполнить Compact .vhdx-файла.
Если после удаления исходников все-таки потребуется установить роль или фичу нужно будет указывать путь к шаре с исходниками или монтировать диск с дистрибутивом:
Для упрощения, можно использовать групповую политику:
Для того чтобы при применении таких политик не пришлось перестраивать структуру OU в соответствии с версиями ОС, можно применить WMI-фильтр:
Теперь о том, как управлять серверами развернутыми в core. Сервер, с которого будет выполнятся администрирование будем называть source, а сервер который будем администрировать — target.
Target и source могут входить как в домен, так и в рабочую группу. Source может быть рабочим ПК администратора и работать под управлением Windows 7/8/8.1/10 с установленным пакетом RSAT соответствующей версии.
Рабочий ПК администратора не должен быть единственным местом откуда инфраструктурой можно управлять, его можно дополнить высокодоступным сервером размещенным в Microsoft Azure или Amazon.
Кроме RSAT, управлять серверами можно с помощью PowerShellWebAccess, но это скорее дополнительная возможность на случай недоступность RSAT. О настройке PSWA Вы можете почитать в моей статье «Настройка PowerShell Web Access«.
Перейдем непостредственно к настройке удаленного управления.
Чтобы посмотреть текущее значение удаленного управления на целевом сервере можно выполнить:
Configure-SMRemoting.exe -get
Для удаленногоу правления на целевом сервере должен быть настроен winRM, его текущую конфигурацию можно запросить так:
winrm get winrm/config
Обратите внимание, Device Manager недоступен для удаленного управления в любых сценариях:
А все дело в том, что Microsoft «выпилила» удаленный доступ к PnP из соображений безопасности — http://support.microsoft.com/kb/2781106/en-us
Вместо этого, предлагается использовать PowerShell — http://blogs.technet.com/b/wincat/archive/2012/09/06/device-management-powershell-cmdlets-sample-an-introduction.aspx
Если Вам все-таки нужнен полноценный Device manager, вам придется установить хотя бы minimal GUI (о том, как это сделать написано выше).
Создадим и распространим на source и на target групповую политику, которой включим правила Firewall Remote Event Log Management, Remote Service Management, Windows Firewall Remote Management, Remote Volume Management:
В кажом правиле можно указать с каких сетей разрешен этот трафик, на каких профилях и т.д. Этот вопрос важен и требует индивидуального планирования чтобы с одной стороны минимизировать возможности атак, а с другой стороны имет возможность администрирования из нескольких мест в случае аварии.
Теперь рассмотрим сценарий когда source находится в домене, а target в рабочей группе. В начале нужно убедится что source и target корректно разрешают fqdn и netbios имена друг друга, если нет — нужно поправить это в DNS. Как и в большинстве случаев, предпочтительно использование айвт имен.
После этого, на source нужно добавить имя target в TrustedHosts:
Set-Item WSMan:localhostClientTrustedHosts -Value %target fqdn% -Concatenate -Force
После этого, можно будет использовать PowerShell remote sessions.
Вы можете посмотреть содержимое TrustedHosts:
Get-Item -Path WSMan:localhostClientTrustedHosts | fl Name, Value
.. и очистить его содержимое при необходимости:
Clear-Item -Path WSMan:localhostClientTrustedHosts
Теперь доступ к target есть по PowerShell, bus воспользуемся им чтобы включить на target таке правила firewall:
netsh advfirewall firewall set rule group=»Windows Remote Management» new enable=yes
netsh advfirewall firewall set rule group=»Remote Event Log Management» new enable=yes
netsh advfirewall firewall set rule group=»Remote Service Management» new enable=yes
netsh advfirewall firewall set rule group=»Windows Firewall Remote Management» new enable=yes
netsh advfirewall firewall set rule group=»Remote Volume Management» new enable=yes
Чтобы снять ограничения которые накладывает UAC на target нужно выполнить:
New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem -propertyType DWord -value 1
Теперь можно добавить target в ServerManager на source и, а затем нужно выбрать опцию «Manage As..» и ввести учетные данные администратора target
Последний сценарий — когда source находится в рабочей группе, а target в домене аналогичен предыдущему и не требует дополнительных комментариев.
Подведем итоги:
Очевидно, что «полновесный» GUI ухудшает метрики SLA сервисов которые развернуты на этом сервере, хоть и частично упрощает управление.
Кроме того, уменьшение утилизируемого дискового пространства важно при размещении серверов в публичных облаках, например Microsoft Azure или Amazon.
«Минималистичный» GUI является хорошим вариантом для bare-metal хостов, а «Core» является рекомендованным вариантом для большинства установок.
Сценарий: «Установить сервер с GUI — Развернуть на сервере сервис — Выключить GUI» является распространенным, но я рекомендую изначально планировать установку так, чтобы в ее процессе не приходилось ничего включать-выключать.
Что касается управления парком серверов, разумно установить RSAT на ПК администраторов для выполнения ежедневных задач, для редких и ответственных задач, а также на случай аварии использовать высокодоступную виртуальную машину в Azure, и кроме того иметь запасной вариант в виде Power Shell Web Access.
Надеюсь озвученная информация будет полезной, а если нужна будет помощь — пишите мне на почту d.kagarlickij@outlook.com
