Обзор и управление Server Core в Windows Server 10

Начиная с 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 будет вариантом по-умолчанию:

Screen Shot 2014-12-28 at 18.30.48

После установки, запустим sconfig и зададим базовые настройки:

Screen Shot 2014-12-28 at 18.38.23

 

После этого, посмотрим какие роли и фичи установлены:

Get-WindowsFeature | Where-Object {$_.Installed -eq $True}

Screen Shot 2014-12-28 at 18.40.30

Если на сервере не планируется установка 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

Screen Shot 2014-12-28 at 18.48.25

.. а объем потребляемой оперативной памяти около 0.5Гб:

Get-Counter 'MemoryCommitted Bytes'

Screen Shot 2014-12-28 at 19.40.22

Установка современного сервера подразумевает удаленное администрирование и отсутствие физического доступа (или необходимости такого доступа) с дисплеем, клавиатурой и мышкой.

Администрирование может выполняться как со специального сервера на котором включены необходимые компоненты 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

Screen Shot 2014-12-28 at 19.05.10

.. или “полновесный” 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 выглядит следующим образом:

Screen Shot 2014-12-28 at 19.14.08

После установки “минималистичного” GUI размер диска вырастет на ~3Гб, а портребление оперативной памяти практически не изменится:

Screen Shot 2014-12-28 at 19.19.58

В случае установки “полновесного” GUI размер диска вырастет на те же ~3Гб, а портребление оперативной памяти практически не изменится.

Обратите внимание, после удаления GUI:

Remove-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell

.. размер диска не уменьшится:

Screen Shot 2014-12-28 at 19.26.32

Зато теперь можно устанавливать и удалять GUI без указания исходников:

Screen Shot 2014-12-28 at 19.27.53

Разумеется, исходники для GUI можно удалить:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Remove

.. это уменьшит размер диска:

Screen Shot 2014-12-28 at 19.30.52

Если есть желание еще больше уменьшить дисковое пространство, можно удалить все исходники для ролей и фич которые не установлены:

Get-WindowsFeature | Where-Object installstate -eq “available” | Uninstall-WindowsFeature -Remove

Screen Shot 2014-12-28 at 17.11.22

Это освободит еще немного дискового пространства:

Screen Shot 2014-12-28 at 19.38.58

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

Если Вы используете виртуальные машины, не забудьте выполнить Compact .vhdx-файла.

Если после удаления исходников все-таки потребуется установить роль или фичу нужно будет указывать путь к шаре с исходниками или монтировать диск с дистрибутивом:

Screen Shot 2014-12-28 at 20.00.34

Для упрощения, можно использовать групповую политику:

Screen Shot 2014-12-28 at 19.58.10

Для того чтобы при применении таких политик не пришлось перестраивать структуру OU в соответствии с версиями ОС, можно применить WMI-фильтр:

Screen Shot 2014-12-28 at 19.59.34

 

Теперь о том, как управлять серверами развернутыми в 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 недоступен для удаленного управления в любых сценариях:

Screen Shot 2014-12-28 at 21.08.17

 

А все дело в том, что 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:

Screen Shot 2014-12-29 at 14.21.58

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

Теперь рассмотрим сценарий когда 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

Screen Shot 2014-12-28 at 21.59.02

 

Последний сценарий – когда source находится в рабочей группе, а target в домене аналогичен предыдущему и не требует дополнительных комментариев.

 

Подведем итоги:

Очевидно, что “полновесный” GUI ухудшает метрики SLA сервисов которые развернуты на этом сервере, хоть и частично упрощает управление.

Кроме того, уменьшение утилизируемого дискового пространства важно при размещении серверов в публичных облаках, например Microsoft Azure или Amazon.

“Минималистичный” GUI является хорошим вариантом для bare-metal хостов, а “Core” является рекомендованным вариантом для большинства установок.

Сценарий: “Установить сервер с GUI – Развернуть на сервере сервис – Выключить GUI” является распространенным, но  я рекомендую изначально планировать установку так, чтобы в ее процессе не приходилось ничего включать-выключать.

Что касается управления парком серверов, разумно установить RSAT на ПК администраторов для выполнения ежедневных задач, для редких и ответственных задач, а также на случай аварии использовать высокодоступную виртуальную машину в Azure, и кроме того иметь запасной вариант в виде Power Shell Web Access.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — пишите мне на почту d.kagarlickij@outlook.com

 

Leave a Reply

Your email address will not be published. Required fields are marked *