Субъективное мнение о пользе Server Core

Жалобы и предложения

На протяжении всего моего знакомства с режимом Server Core у Windows Server 2008 R2 меня не покидают ощущения искусственности этого продукта. Явно прослеживается желание Server Core быть как Linux, но при этом постоянно натыкаешься на несвойственные для Linux неприятности.

Приведу небольшое сравнение особенностей Server Core и Linux.

Однако, раньше было еще хуже, со времени первой редакции Server Core в Windows Server 2008 есть значительное развитие:

• стала доступна роль веб-сервера IIS
• появился PowerShell
• встроен скрипт начального конфигурирования

Хотелось бы видеть развитие Server Core в следующих направлениях:

• Увеличение числа поддерживаемых стандартных ролей. Любые стандартные серверные роли, даже исходя из названия, не требуют для своей работы графического интерфейса. Видимо, для оставшихся за бортом ролей Microsoft пока не успели сделать адекватное удалённое управление.
• Поддержка дополнительных серверных приложений от Microsoft и сторонних разработчиков (их участие, конечно, тоже потребуется). Таким продуктам, как SQL Server, Exchange, Kerio WinRoute и MailServer (да и любым другим, нормальным серверным) для работы серверной части не нужна графическая оболочка, всё равно управление осуществляется из отдельных консолей.
• Включение в стандартную поставку диалоговых скриптов для автоматизированного конфигурирования основных параметров. В Linux-е же есть такие, здорово облегчают рутину. Чем Microsoft хуже?

Сценарии для адекватного применения Server Core

Реальное применение Server Core я вижу, например, в следующем сценарии. Для исполнения заранее ограниченного числа встроенных в Windows Server ролей, поддерживаемых Server Core, необходим выделенный сервер. Предполагается однократное конфигурирование перед запуском в среду. Дальнейшие административные вмешательства, диагностика, применение дополнительного ПО и возникновение каких-либо проблем — не предполагаются.

Предполагаю следующие варианты адекватного применения Server Core:

• Active Directory DC/RODC + DNS + DHCP в удалённом офисе
• File Server + Print Server + BranchCache Hosted Cache
• IIS + Media Services
• Hyper-V — просто идеально!
• Network Policy and Access Services (RRAS, NAP) + WSUS + Exchange — было бы шикарно, но пока не возможно.

При совместном применении указанных сочетаний ролей, аппаратного шифрования BitLocker, грамотной, нацеленной на безопасность настойки и качественного оборудования может получается довольно надежное и безопасное решение возложенных функций и практически «черный ящик» для нежелательных внешних воздействий.

Hyper-V Server 2008 R2

Hyper-V Server 2008 R2 представляет собой Windows Server 2008 R2 в режиме Server Core с одной единственной предустановленной ролью — Hyper-V. По способу управления они идентичны: командная строка, PowerShell, WinRM, MMC, RDP.

Как я писал выше, именно роль Hyper-V является идеальной для использования Windows Server 2008 R2 в режиме Server Core, и счастье, что Microsoft тоже это понимает. Но особая радость состоит в том, что Hyper-V Server 2008 R2 абсолютно бесплатен и практически не ограничен по функциональности в рамках роли Hyper-V.

Поддерживается 1 терабайт памяти, 64 логических процессора, 386 виртуальных машин, современные серверные хранилища информации, непосредственно подключаемое и сетевые. Сохранена совместимость виртуальных машин с «обычным» Hyper-V, поддерживаются снапшоты, отказоустойчивая кластеризация, Live Migration, управление через System Center Virtual Machine Manager, работает PowerShell.

Это несомненный Epic Win со стороны Microsoft и «Кузькина Мать» для vmWare.

Боевой опыт работы с Server Core

Из графических средств остались следующие полезные вещи:

• intl.cpl — элемент панели управления для настройки языковых параметров
• timedate.cpl —элемент панели управления для настройки параметров времени
• taskmgr —диспетчер задач
• notepad никуда не делся
• regedit всё тот же
• msinfo32 — вот уж «необходимая» вещь!
• но самое приятное — работает Total Commander (и, возможно, другой незаменимый софт)!

А вообще же режим Server Core рассчитан на однократную настройку из консоли, а все дальнейшее управление предполагается удаленно по сети, из различных MMC консолей, WinRM и прочих радостей. Полный набор для удаленного управления Windows Server 2008 R2 (не только Server Core) можно установить на Windows 7. Однако, ограниченно работают и наборы удаленного администрирования серверных ОС и для Windows Vista, и для Windows XP.

С версии R2 появилась так недостающая ранее утилита автоматизированной первоначальной настройки sconfig. Она позволяет:

• задать имя компьютера, включить его в домен
• добавить локального администратора
• настроить сетевые параметры
• включить удаленное управление через WinRM, MMC, RDP

Энтузиастами была разработана более продвинутая графическая утилита для конфигурирования Server Core — Core Configurator, настоятельно рекомендую опробовать.

Несмотря на богатый набор встроенных в стандартную поставку Server Core драйверов для сетевых карт, может понадобиться установить эти драйвера вручную. За работу с драйверами устройств в Server Core отвечает утилита pnputil. Например, для установки драйвера для сетевой карты нужно выполнить следующую команду

pnputil -i -a drivername.inf

Меньше всего проблем с управлением свежеустановленным Server Core возникает, если его ввести в домен. По умолчанию в брандмауэре включится профиль Domain, будет работать прозрачная аутентификация в консолях MMC и WinRM. Ну и, конечно, групповые политики будут применены ко всему, что найдут.

Если ли же вы хотите управлять Server Core без использования доменной аутентификации, озаботьтесь созданием на управляющей и на управляемой машинах административных учетных записей с одинаковыми именами и паролями. Это здорово облегчит подключение по WinRM и сделает возможным в принципе управление по MMC.

Как уже упоминалось выше, возможности удаленного управления активируются с помощью программы sconfig, советую включить их все, затем настроить брандмауэр, используя консол Windows Firewall with Advanced Security в режиме удаленного подключения (как — написано дальше).

Как настроить WinRM на клиенте и подключиться им к вашему серверу, читайте в моей статье «Выполнение консольных команд на удаленных компьютерах по сети».

Для управления Server Core с помощью консоли Server Manager, нужно открыть его на локальной машине, правый клик на корне Server Manager → Connect To… Будут доступны:

• Task Scheduler
• Event Viewer
• Shared Folders
• Services
• Disk Management (если сначала запустить службу Virtual Disk)

Для доступа к следующим управляющим возможностям нужно запустить MMC, выбрать File → Add Snap-in… и указать в качестве цели адрес управляемого компьютера:

• Group Policy Object Editor
• Windows Firewall with Advanced Security

Чтобы включить Device Manager (да и то только в режим чтения), в консоли Group Policy Object Editor идём в Computer Configuration → Administrative Templates → System → Device Installation и включаем Allow remote access to the PnP interface. Для вступления изменений в силу нужно перезагрузить компьютер. Для этого можно выполнить команду

winrs -r:servername shutdown /r /t 0

…если у вас все в порядке с учетными записями, в противном случае можно воспользоваться ключами -u:user -p:pass.

Полезные ссылки

• Официальный блог Server Core — самый лучший источник мудрости на начальном этапе
• Server Core Installation Option Getting Started Guide
• Remote Management with Server Manager
• Таблица поддерживаемых ролей Windows Server 2008 R2 в режиме Server Core
• Таблица поддерживаемых ролей Windows Server 2008 R2 в полной версии
• Официальная Страница Hyper-V Server 2008 R2
• FAQ по Hyper-V Server 2008 R2
• Бесплатная загрузка Hyper-V Server 2008 R2
• Средства удаленного администрирования сервера для Windows 7

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

Программа работает по клиент-серверному принципу: на локальной машине выполняется клиент, который посылает команды серверу на удаленном компьютере. Особенностью этой программы является то, что серверная часть устанавливается автоматически непосредственно перед выполнением команды, а затем удаляется. Таким образом для выполнения команд на удаленных машинах достаточно иметь на них административные права.

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

• Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:
  psexec @group.txt gpupdate /force
• Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:
  psexec \\computer -s wuauclt /detectnow
• Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:
  psexec \\computer -c -s klist.exe purge

Трудно переоценить пользу этой программы, если использовать скрипты и возможности консольных команд, встроенных в Windows.

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

Будет предложено автоматически запускать службу WinRM и разрешить уделенные подключения, соглашайтесь ;)

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts="servername"}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser="X"}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns