Время на прочтение8 мин
Количество просмотров24K
Windows Server 2012 позиционируется как система, которой GUI для полноценной работы не нужен. При установке по умолчанию выбран пункт Server Core, добавлена возможность удаления графического интерфейса без переустановки сервера, список ролей, не нуждающихся в GUI в сравнении с 2008 R2 расширен. В своих книгах Microsoft утверждает, что работа с командной строкой естественна и вспоминает начало 90-х годов прошлого века, когда системные администраторы жаловались на бесполезную трату ресурсов графической оболочкой. В дополнение к этому Microsoft предлагает «новый» путь администрирования своих серверных операционных систем, в котором предполагается, что серверную консоль вы будете видеть только один раз – при установке операционной системы, а вся работа и настройка системы будет осуществляться удаленно: через «Диспетчер серверов», MMC-оснастки и PowerShell, который в 2012 сервере уже версии 3.0
Допустим, что первоначальная настройка сервера после установки включает в себя:
- Настройку сетевых интерфейсов
- Установку часового пояса
- Включение удаленного рабочего стола
- Переименование компьютера
- Присоединение к домену
Вопрос в следующем: а можно ли эти задачи выполнить удаленно средствами PowerShell? Ну вот, допустим, есть удаленный сервер где-нибудь в тайге, на который местный умелец поставил 2012 сервер, пошел отметить это дело и потерял ключ от шкафа. Шкаф бронебойный, водо-, звуконепроницаемый и вообще предполагает защиту от несанкционированного доступа медведей. А настроить надо. Допустим, есть VPN или какой-нибудь «прямой провод» (очень часто вижу эту услугу в прайсах провайдеров) и сервер доступен по сети. И только по сети.
В исходных данных письмо от местного умельца:
Привет, поставил венду на сервер. IP – 169.254.23.43. Логин – Администратор. Пароль – qwe123!@#. Пока.
Готовимся
Удаленный сервер в рабочей группе, в свежеустановленном состоянии, RPC не понимает (порты на брандмауэре закрыты), не пингуется, с непроизносимым именем и московским часовым поясом в Сибири. Если бы это был 2008 R2 на этом бы наши приключения и закончились, так как все средства удаленного управления в нем по умолчанию отключены. В 2012 есть способ удаленно управлять из коробки – включенный по умолчанию WinRM, реализация стандарта WS-MAN от Microsoft. С одной стороны вроде дыра в безопасности, с другой – в нормально спроектированной сети, в которой сервера находятся в отдельном VLAN, доступ к которому ограничен для доверенных пользователей, вероятность использования этой дыры незначительна. Но все-таки есть.
Для управления удаленным сервером в рабочей группе с помощью WinRM, мы должны доверять удаленному серверу. Тут мне логика немного непонятна. По идее, удаленный сервер должен доверять нам, мы же им управляем, а не он нами. Возможно, это от неполного понимания принципов работы WS-MAN. Но в любом случае, сказать WinRM, что мы доверяем удаленному серверу нужно. Это реализовано занесением имени или IP-адреса удаленного сервера в список «доверенных хостов» (TrustedHosts)
si WSMan:\localhost\Client\TrustedHosts 169.254.23.43
Теперь как-то нужно выполнить первоначальную настройку удаленного сервера. Я знаю 2 командлета, которые могут помочь с этой задачей: Enter-Pssession и Invoke-Command. Оба используют WinRM. Enter-Pssession дает нам консоль удаленного сервера, Invoke-Command отправляет блок команд на удаленный сервер и возвращает результат их выполнения. Ниже используется Invoke-Command (мы же собрались вообще не видеть удаленную консоль).
Действия будем выполнять по следующему принципу:
- PowerShell
- Если не получается выполнить задачу через PowerShell, подключаем cmd
- Если не в PowerShell, не в cmd нет подходящих инструментов – WMI через PowerShell
- Ну и как последний вариант – ковыряние реестра также через PowerShell
Настройка сетевых интерфейсов
Делать нечего, меняем свой адрес на что-нибудь из APIPA-диапазона, ну например 169.254.0.1 и садимся думать, как удаленно изменить IP-адрес у таёжного сервера. Думать тут нечего:
- Определить на каком адаптере производить изменения
- Отключить DHCP
- Назначить статический адрес для сервера с маской подсети и шлюзом по умолчанию.
- Hазначить DNS-серверы
И все это желательно не отцепляясь от сервера.
В PowerShell 3.0 появилась целая группа Network Adapter Cmdlets, которая позволяет нам делать с сетевыми адаптерами все что угодно.
Получаем объект сетевого адаптера и сохраняем его в переменной $adapter. Ethernet – это новое имя для «Подключение по локальной сети». Это изменение, несмотря на кажущуюся незначительность, очень радует.
$adapter = Get-NetAdapter Ethernet
Отключаем DHCP
$adapter | Set-NetAdapter –Dhcp disabled
Меняем IP-адрес на нормальный с необходимой маской и шлюзом. Для этого существует другая группа Net TCP/IP Cmdlets
$adapter | New-NetIPAddress 192.168.0.5 –PrefixLength 24 –DefaultGateway 192.168.0.1
Добавляем DNS-серверы. Третья группа DNS Client Cmdlets
Set-DnsClientServerAddress Ethernet –addresses (“192.168.0.2”,”192.168.0.3”)
Как все это выполнить на удаленном сервере? Сделать скрипт и с помощью Invoke-Command запустить его на выполнение.
Сохраним этот набор команд где-нибудь с именем скрипта, например, remotechangeip.
Тут есть один момент. Называется политика выполнения скриптов.
По умолчанию в PowerShell разрешается работа только в интерактивном режиме, выполнение любых скриптов запрещено (restricted). Для выполнения скриптов нам нужно либо remotesigned (цифровая подпись требуется для скриптов, загруженных из интернета), либо unrestricted (при выполнении неподписанного скрипта, загруженного из интернета будет выдаваться предупреждение о ненадежности источника). Если на безопасность совсем положить, можно поставить bypass (будет выполняться все без лишних вопросов). Eсли у вас есть собственный сертификат, выданный доверенным издателем, и вы не ленитесь подписывать с его помощью свои скрипты – вам нужен allsigned (в таком случае, вы наверное и сами это знаете). У меня сертификата нет, поэтому политику я устанавливаю remotesigned.
Set-ExecutionPolicy remotesigned
Политика выполнения скриптов устанавливается на локальном компьютере, на удаленном такой необходимости нет, потому что Invoke-Command перед выполнением скрипта на удаленном компьютере преобразовывает файл скрипта в просто набор команд. Соответственно, на удаленном компьютере выполняется не скрипт (файл с расширением .ps1), а набор команд, которым политика выполнения скриптов по барабану.
Отправляем наш скрипт на удаленный сервер.
Invoke-Command 169.254.23.43 C:\scripts\remotechangeip.ps1 –Credential Администратор
Пароль от учетной записи Администратор у нас есть в письме. После выполнения получаем сервер со статическим адресом 192.168.0.5 с маской подсети /24, шлюзом по умолчанию 192.168.0.1 и DNS-серверами 192.168.0.2 и 192.168.0.3
Еще нужно не забыть изменить IP в TrustedHosts, иначе на этом наше удаленное администрирование закончится.
$newvalue = ((ls WSMan:\localhost\Client\TrustedHosts).value).replace("169.254.23.43","192.168.0.5")
si WSMan:\localhost\Client\TrustedHosts $newvalue
Изменение часового пояса
Я очень долго пытался решить эту задачу с помощью PowerShell. Я нашел функцию, меняющую часовой пояс локально. Но если мы попытаемся выполнить эту функцию через Invoke-Command, получим граблями по лбу в виде «Имя Set-Timezone не распознано как имя командлета, функции, файла сценария или выполняемой программы».
Invoke-Command при выполнении естественно не копирует с локальной машины, а выполняет имеющиеся на удаленном сервере командлеты. Это понятно и логично. Задача была ясна — перед выполнением Invoke-Command нужно сбросить функцию на удаленный сервер. Но… тут мне стало лень.
Если заглянуть в код функции, то становится понятно, что она всего лишь проверяет версию ОС и в зависимости от нее выполняет либо timedate.cpl (XP и ниже), либо tzutil (Vista и выше). Проверять версию ОС незачем, мы ее знаем. Поэтому просто изменим часовой пояс с помощью tzutil
Invoke-Command 192.168.0.5 {tzutil /s “North Asia Standard Time”} –Credential Администратор
WMI
Можно попробовать установить часовой пояс, используя WMI. Выглядеть это будет так:
$strComputer = "."
$objWMI = gwmi win32_computersystem" -computername $strComputer
$objWMI.CurrentTimeZone = 207
$objWMI.Put()
Что здесь происходит? Точка (.) говорит, что мы работаем с локальным компьютером. Обращаемся на локальном компьютере к классу win32_computersystem. Присваиваем свойству CurrentTimeZone значение 207, соответствующее “North Asia Standard Time”. И методом Put сохраняем изменение часового пояса.
Также сохранить и передать скрипт на удаленный компьютер с помощью Invoke-Command. По-моему, использовать tzutil проще.
Значения часовых поясов можно взять отсюда или из вывода tzutil /l
Ну и без PowerShell все-таки не обошлось.
Включение удаленного рабочего стола
В PowerShell 3.0 появилось множество командлетов, для работы с RDS. Их группа так и называется Remote Desktop Cmdlets. Но, как я понял, они рассчитаны на работу с RDS-сервером, просто включить удаленный рабочий стол для администратора с их помощью нельзя.
Остается два способа включения рабочего стола. Через WMI-вызовы и
неправильный
через модификацию реестра. Модификация реестра мне никогда не нравилась. Одно неловкое движение пальца и никто не гарантирует, что сервер поднимется после перезагрузки.
Что касается включения удаленного рабочего стола, то модификация ключа HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections, которому нужно присвоить значение 0, чтобы разрешить удаленный рабочий стол:
во-первых, требует перезагрузки, во-вторых
, не добавляет исключение для удаленного рабочего стола в правила брандмауэра.
Поэтому я буду использовать WMI-класс win32_terminalservicesetting и его метод setallowtsconnections, что позволит обойтись без перезагрузки и добавить правила исключения в брандмауэре одной командой.
Invoke-Command 192.168.0.5 {(gwmi win32_terminalservicesetting -namespace root\cimv2\terminalservices).setallowtsconnections(1,1)} –Credential Администратор
Теперь у нас есть доступ к таёжному серверу по RDP! Можно радоваться? Представим, что единственный канал связи с внешним миром у удаленного сервера через спутник с грабительскими тарифами, диалапной скоростью, зашкаливающим пингом и продолжим настраивать сервер удаленно через PowerShell.
Переименование сервера и присоединение его к домену
Тем более, что осталось совсем немного.
По идее, командлет Add-Computer позволяет переименовать компьютер при присоединении его к домену. Но на практике, я сталкивался с тем, что при присоединении к домену и одновременным переименованием с помощью этой команды, компьютер входит в домен под своим старым именем. И понеслась – вывести компьютер из домена, перезагрузиться, удалить учетку в AD, запустить репликацию если контроллеров несколько, подождать, переименовать компьютер, перезагрузиться, ввести в домен, перезагрузиться.
Поэтому я предпочитаю операции переименования компьютера и ввода в домен выполнять отдельно.
Переименование
Invoke-Command 192.168.0.5 {rename-computer taiga -restart} -credential Администратор
Как только нам вернули управление, значит удаленный сервер перезагружается. Проверить результат команды (и готовность сервера) можно так:
Invoke-Command 192.168.0.5 {$env:computername} -credential Администратор
И наконец-то ввод в домен
Invoke-Сommand 192.168.0.5 {add-computer contoso.com -credential contoso.com\domainadmin -restart} -credential Администратор
Заканчиваем
Все поставленные в начале задачи выполнены. Теперь уже можно думать, как дальше жить и где искать этот чертов ключ от шкафа.
И напоследок небольшая шпаргалка по CMD и PowerShell.
| CMD | PowerShell | |
| Изменить сетевые настройки |
|
|
| Изменить часовой пояс |
|
|
| Включить удаленный рабочий стол |
|
|
| Переименовать сервер |
|
|
| Присоединить к домену |
|
|
Объединяет их одно: им всем для удаленной работы нужен RPC, по умолчанию закрытый брандмауэром. Поэтому единственным способом доставить их на удаленный компьютер, является WinRM.
А Enter-Pssession у меня не заработал 
Использован материал из:
MSDN
Technet
Server Core – особый режим установки Windows Server, это среда, в которой отсутствует графический интерфейс и средства управления, а также некоторые серверные роли и компоненты. Управление Windows Server Core предполагается из командной строки, с помощью PowerShell, или же с других серверов/рабочих станций с установленным RSAT (RSAT для Windows 7, RSAT для Windows 10). Впервые Core-режим работы серверной ОС Microsoft появился еще в Windows Server 2008. Основные преимущества Server Core перед полными инсталляциями Windows Server: экономия системных ресурсов, повышенная стабильность и безопасность за счет меньшего количества компонентов, упрощение обслуживания, меньший даунтайм при установке обновлений, сокращение поверхности атаки злоумышленниками.
Одним из главных недостатков в Windows Server 2008 Core являлась невозможность переключение в режим с графической оболочкой (GUI) или в обратную сторону (из GUI в Core режим). В случае возникновения такой необходимости приходилось целиком переустанавливать ОС.
В Windows Server 2012 Microsoft решила убрать это ограничение, кроме того появился еще один вариант работы сервера — минимальный интерфейс сервера (Minimal Server Interface). В этом режиме отсутствуют проводник, Internet Explorer, рабочий стол и начальный экран).
В Windows Server 2012 теперь можно установить и настроить сервер в знакомом администраторам GUI, после чего перевести сервер в Core режим. Этот подход упрощает процедуру настройки сервера, не вынуждая администраторов разбираться в подчас достаточно сложных консольных командах и командлетах PoSh.
Итак, в Windows Server 2012 возможна работа в нескольких режимах, между которыми в процессе эксплуатирования и настройки сервера может переключаться администратор.
- Full Server with GUI – полноценный сервер с GUI
- Server Core with GUI Management (Minimal Server Interface) – минимальная интерфейс сервера с Windows Server 2012, включающий графические утилитаты управления сервером
- Server Core – режим командной строки
Отметим, что в режиме Minimal Server Interface система занимает примерно на 400 мб меньше места, чем полноценная ОС с GUI. В случае с Server Core экономия достигает порядка 4Г дискового пространства.
Далее мы разберем способы переключения между данными режимами работа новой серверной платформы от Microsoft
Переключение из режима Server Core в GUI
В том случае, если сервер был установлен в режиме Windows Server 2012 Core, в установленных компонентах отсутствуют необходимые файлы для установки GUI (концепция минимизации занимаемого места на диске в Core режиме). По умолчанию, если нужные компоненты отсутствуют на диске, система пытается скачать их с сайта Windows Update. Если доступ в интернет у сервера отсутствует, нам придется указать альтернативные источник установки (с помощью команды powershell Install-WindowsFeature с параметром -Source).
Для установки графического интерфейса нам понадобится дистрибутив Windows Server 2012. Допустим, мы вставили (смонтировали iso образа) дистрибутив Windows Server 2012 в устройство, которому назначена буква D:\.
Далее нужно определить индекс установленной версии Windows Server 2012 в установочном wim образе. Для этого наберите команду, отображающую информацию о содержимом установочного образа:
Dism /get-wiminfo /wimfile:D:\sources\install.wim
Т.к. на сервере установлен Windows Server 2012 Datacenter, нас интересует дистрибутив SERVERDATACENTER, индекс которого 4.
Далее нужно установить недостающие компоненты (Server GUI) из wim файла командой:
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Restart -source:wim:d:\sources\install.wim:4
Процедура установки займет порядка 5-10 минут. В том случае если при установке будут наблюдаться проблемы, попробуйте отключить сетевые карты, чтобы Windows не пыталась скачать файлы с сайта Windows Update.
После выполнения команды сервер автоматически перезагрузится и загрузится уже в графическом режиме.
Графические компоненты Windows Server 2012 можно также установить и с помощью DISM, ту же самую операцию выполним с помощью двух команд:
Dism /Online /Enable-Feature /FeatureName:Server-Gui-Mgmt /All /Source:wim:D:\sources\install.wim:4
Dism /Online /Enable-Feature /FeatureName:Server-Gui-Shell /Source:wim:D:\sources\install.wim:4
В том случае, если сервер изначально был установлен в GUI режиме, который затем отключили, его можно вернуть командой:
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Restart
Переключение из GUI режима в Core
Удалить GUI режим в Win Server 2012 в Core можно несколькими способами:
- С помощью Powershell
- Из графического интерфейса консоли Server Manager
Запустите строку PoSh и выполните команду
remove-WindowsFeature Server-Gui-Shell,Server-Gui-Mgmt-Infra -restart
После выполнения команды сервер автоматически перезагрузится и загрузили уже в Core-режиме.
Аналогом командлета remove-WindowsFeature является Uninstall-WindowsFeature команда, и чтобы перейти из режима Server with GUI в режим Server Core воспользуйтесь командами:
Import-Module ServerManager
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –restart
Если вам удобнее пользоваться графическими утилитами, откройте консоль Server Manager:
- Выберите пункт Remove Roles or Features
- Снимите флажки с Graphical Management Tools and Infrastructure и Server Graphical Shell
- После окончания работы мастера перезагрузите сервер
Переключение из Windows Server 2012 GUI в Minimal Server interface
В режиме работы Minimal Server Interface в системе присутствуют все базовые графические инструменты управления сервером (оснастки MMC, консоль Server Manager, элементы панели управления), однако такие компоненты как Windows Explorer, Internet Explorer 10, рабочий стол, начальный экран Start screen отсутствуют.
С помощью Powershell переключиться в режим Minimal Server Interface можно с помощью команды:
remove-WindowsFeature Server-Gui-Shell -restart
Тоже самое в графической консоли Server Manager:
- Откройте консоль Server Manager
- Выберите Remove Roles or Features
- Снимите флажок с элемента Server Graphical Shell
- По окончании работы мастера перезагрузите сервер
Переключение из Core в Minimal Server Interface в Windows 2012
Откройте консоль Powershell и выполните команду:
Install-WindowsFeature Server-Gui-Mgmt-Infra -restart -source:wim:d:\sources\install.wim:4
Seems like Microsoft keeps taking ideas from Linux, which is a good thing as now we can install and remove the Graphical User Interface or add it on a server core installation.
You may want to do this if when you installed your server you installed the Graphical version and now you no longer need it. This will make your server run lighter then it does with the GUI enabled. If you have a server core you can also install the GUI with a simple PowerShell command.
There are two ways to remove the graphical user interface from your Server 2012 or Server 2012 R2 installation. You can do it from both by the shell using Powershell and graphically by using Server Manager
Removing GUI From Server 2012 R2 Using Server Manager
- Open Server Manager
- Select “Manage” (on the top right hand corner)
- Select “Remove Roles and Features”
- Then you will need to select your server and click “Next”
- Then you will be greeted by the Remove Roles page since the GUI is not a Server Role you can just select “Next”
- Now you are on the Remove Features page. Unselect the “User Interfaces and Infrastructure” and hit the “Next” button
- The next page you can select the server to reboot automatically. If you want it to reboot automatically then leave it checked, if you want to reboot your server manually then uncheck the check box.
- Once your server boots up you will be in Windows Server 2012 R2 Core version
Removing GUI From Server 2012 R2 Using PowerShell
- Run PowerShell as administrator
- Run the command Uninstall-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
- Now reboot your server (You can do this from PowerShell by running the command Shutdown –r -t 0)
- Once your server boots up you will be in Windows Server 2012 R2 Core version
Adding GUI In Server 2012 R2 Core Installation
- Run the command powershell that will open powershell in server core
- Run the command Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
- Reboot the Server by running the command Shutdown –r -t 0
- Once your server boots up you will be in the graphical version of Windows Server 2012 R2
Table of Contents
Introduction
Server Core was introduced in Windows Server 2008 but was confusing to many administrators. This was mainly because that you, as an administrator, were restricted to a command line and needed to know the commands for doing your tasks.
One of the main problems with it was that if you installed your server as a Server Core, you would need to reinstall it if you want the graphical user interface (GUI).
This changed in Windows Server 2012. It was now possible to install your server with a GUI and remove the GUI once you’ve set everything up.
It was also possible to install your server as a Server Core and then add the GUI by just entering a simple Powershell command.
In this blog post, I will explain how to install the GUI for a Windows Server Core installation or remove the GUI if you have Windows Server 2012 or Windows Server 2012 R2.
Enter this command into a Powershell prompt, running as Administrator.
Then run:
Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
Once installed, you need to restart the server. Use this command:
If you do not have Internet connectivity, the installation will hang at 68% and, after a while, displays an error message to you:
Install-WindowsFeature: The request to add or remove features on the specified server failed.
This means that the source files for the GUI installation cannot be located.
To solve the error, follow these steps:
Start by creating a mount directory (i.e C:\Mount), by opening a command prompt:
Get the index number of the WIM file for the GUI (if Windows Server 2012 R2 media is on D:). Since all of the Windows Server 2012 R2 installations are stored in the same *.wim, we need to specify what version we want to mount. In this case, we’ll be using the Datacenter version with GUI, which is Index #4
dism /get-wiminfo /wimfile:d:\sources\install.wim
Mount the WIM file:
dism /mount-wim /wimfile: d:\sources\install.wim /Index:3 /mountdir:C:\Mount\ /readonly
Install and specify the source:
Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra -Source C:\Mount\Windows\SXS
Once installed, you need to restart the server. Use this command:
How to remove the GUI from a full installation, using the GUI:
Open Server Manager, open the Manage menu and go to Remove Roles and Features
Press Next until you reach the Features page
There are two different features that you can choose:
- Graphical Management Tools and Infrastructure (server-GUI-mgmt-infra) basically provides Powershell, MMC, and Server Manager.
- Adding the Server Graphical Shell (server-GUI-shell) will add the rest of the GUI experience. This feature is dependent on the first, so you can’t just add this one.
Note that if you remove Graphical Management Tools and Infrastructure, you will also remove Server Graphical Shell.
Once deselecting one of the features, you will get a popup. Here, press Remove Features.
The User Interfaces and Infrastructure feature should now be deselected. Proceed by pressing Next.
The final step is to confirm the removal process. Press Remove and select Restart the destination server automatically if required.
Removing the GUI from a full installation, using Powershell:
Enter this command:
Uninstall-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
References
- Microsoft Docs – What is Server Core?
Related posts
- Install .NET Framework 3.5 using DISM and other methods
- What is Hyper-V Server 2012, and how do I install and administer it?
How to Turn the GUI Off and On in Windows Server 2012
When Server Core originally shipped, a lot of Windows admins avoided it because you could only use the command line, but this changes with Windows Server 2012 which enabled the use of a hybrid mode.
Turning the GUI Off
In Windows Server 8 the GUI has kept with the modular nature of recent Windows Server Operating Systems and in turn has become a “Feature”. This makes removing the GUI very easy. To get started launch Server Manager.
Click on Manage, and then select Remove Roles or Features from the menu.
Click next to skip past the before you begin page, then select your server from the server pool and click next.
Since the GUI is not a Role, we can just click next again to skip past the Roles section.
When you reach the Features page, you need to uncheck the box next to the “User Interfaces and Infrastructure” option, and then click next.
Now tick the “Restart Destination Server” box, then click remove.
The GUI will now be removed.
After the binaries are removed your server will automatically reboot.
Once it comes back up, and you log in, you will only be able to use the command line.
Turning the GUI On
Once the GUI has been turned off, you will want to know how to get it back. To do this we use SConfig, so go ahead and type SConfig into the command line and hit enter.
You can see near the bottom of the screen that we can use “12” to Restore the GUI, so type 12 and hit enter.
You will be warned that enabling the GUI requires a reboot, click the yes button.
That will kick off DISM which will start to add the binaries for the GUI Shell.
When its finished you will be asked if you would like to restart the computer now, type “y” and hit enter to reboot.
GUI Off with PowerShell
You can do the same thing as we did in the GUI much quicker with a PowerShell cmdlet. To do so, open Server Manager, click on Tools and launch PowerShell.
We can use the Remove-WindowsFeature cmdlet to remove the feature:
Remove-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
Since Remove-WindowsFeature is just an alias, you could also use:
Uninstall-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
Not long after you have hit the enter key, the removal will begin.
When it’s done, you will be notified that you need to restart your server to complete the process, which can be easily done from the current PowerShell window by running:
Shutdown –r -t 0
When your machine restarts you will only have the command line to work with .
GUI On with PowerShell
The first thing we need to do is get into PowerShell, so type PowerShell and hit enter.
Now we need to use the Add-WindowsFeature to add the components back:
Add-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
Again this is just an alias for:
Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
When its done, we will need to restart our server by using the Shutdown command:
Shutdown –r -t 0
When your server reboots you will have the GUI back.