Windows Server Core: Remote management

management128-brightВ предыдущей статье я рассказал про установку Windows Server Core, теперь о том, как управлять серверами развернутыми в core. Сервера, с которых будет выполнятся администрирование будем называть source, а сервера которые будем администрировать – target.

Target и source могут входить как в домен, так и в рабочую группу. Source может быть рабочим ПК администратора и работать под управлением Windows 7/8/8.1/10 с установленным пакетом RSAT соответствующей версии.

Рабочий ПК администратора не должен быть единственным местом откуда инфраструктурой можно управлять, его можно дополнить высокодоступным сервером размещенным в Microsoft Azure или Amazon, но их точкой отказа будет Интернет-канал.

Кроме RSAT, управлять серверами можно с помощью PowerShellWebAccess, но это скорее дополнительная возможность на случай недоступность RSAT. О настройке PSWA Вы можете почитать в моей статье “Настройка PowerShell Web Access“.

Перейдем непостредственно к настройке удаленного управления.

Чтобы посмотреть текущее значение удаленного управления на target можно выполнить:

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

Обратите внимание, 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

В кажом правиле можно указать с каких сетей (лучше выделить админов в отдельную сеть, чем указывать список IP админских машин) разрешен этот трафик, на каких профилях и т.д. Хорошим вариантом будет использование IPSec.

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

Если вас интересует управление Windows Firewall с помощью PowerShell рекомендую эту статью.

Теперь рассмотрим сценарий когда source находится в домене, а target в рабочей группе. В начале нужно убедится что source и target корректно разрешают fqdn и netbios имена друг друга, если нет – нужно поправить это в DNS. Как и в большинстве случаев, предпочтительно использование fqdn имен.

После этого, на source  нужно добавить имя target в TrustedHosts:

После этого, можно будет использовать PowerShell remote sessions.

Вы можете посмотреть содержимое TrustedHosts:

.. и очистить его содержимое при необходимости:

Теперь доступ к target есть по PowerShell, bus воспользуемся им чтобы включить на target таке правила firewall:

Чтобы снять ограничения которые накладывает UAC на target нужно выполнить:

Теперь можно добавить target в ServerManager на source и, а затем нужно выбрать опцию “Manage As..” и ввести учетные данные администратора target

Screen-Shot-2014-12-28-at-21.59.02

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

Если вам нужно управлять старыми версиями Windows Server, это сделать можно, 2012R2 и 2012 добавляются без проблем, а вот на 2008R2 и 2008 нужно будет поставить WMF 3.0 +  Hotfix + выполнить:

После этого (само собой нужно включить правила firewall, о которых выше) серверами 2008 и 2008R2 можно будет ограниченно управлять, но нельзя, например, устанавливать роли и фичи.

Вообще, запускать скрипты без цифровой подписи в рабочей инфраструктуре не очень хорошо, поэтому есть смысл поставить политику AllSigned:

Если серверов больше чем несколько, есть смысл сделать это через групповую политику (Administrative Templates\Windows Components\Windows PowerShell):

Screen Shot 2015-07-01 at 14.43.27

Вот еще наглядный пример, почему большинство задач желательно выполнять через Remote Access:

Screen Shot 2015-07-01 at 14.47.17

Screen Shot 2015-07-01 at 14.53.32

Для подписи скриптов я буду использовать Comodo Code Signing certificate:

Screen Shot 2015-07-01 at 15.16.29

Для подписывания используется командлет Set-AuthenticodeSignature :

Screen Shot 2015-07-01 at 15.17.27

Подписанный скрипт будет выглядеть следующим образом:

Screen Shot 2015-07-01 at 15.19.19

При запуске необходимо будет принять решение по издателю, я обычно использую Run once – работая с большим количеством скриптов от коллег это становится необходимостью.

Screen Shot 2015-07-01 at 15.26.16

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

Добавление Windows Sever 2003 я не описываю т.к. во-первых в нем потолок PS 2.0, во-вторых его поддержка заканчивается в обозримом будущем, а в-третьих за годы его эксплуатации процессы управления наверняка налажены и менять их нецелесообразно.

Screen Shot 2014-12-30 at 11.33.23

Новый Server Manager сделал большой шаг перед на пути к выполнению массовых операций, но на практике PowerShell более функционален.

Команду на удаленном компьютере можно выполнить указав в Invoke-Command -ComputerName (по-умолчанию Invoke-Command добавляется ко всем командлетам выполняемым локально):

Screen Shot 2015-07-01 at 11.58.03

Если команду нужно выполнить на нескольких сервера, откроем на них сессии и выполним операции на каждом параллельно:

Screen Shot 2015-07-02 at 20.56.14

Можете посмотреть разницу в скорости выполнения командлетов:

Screen Shot 2015-07-02 at 21.04.21

Подробнее про управление:

http://technet.microsoft.com/en-us/library/hh831456.aspx

… старыми версиями –

http://blogs.technet.com/b/servermanager/archive/2012/09/10/managing-downlevel-windows-based-servers-from-server-manager-in-windows-server-2012.aspx

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