Без GUI — что это? (Windows 10, msconfig)
Без GUI — опция загрузки операционной системы, активация которой отключает отображение экрана приветствия.
Вообще GUI расшифровывается как Graphical User Interface, означает пользовательский графический интерфейс (оболочка) программы или некого процессора, в нашем случае — приветствия.
Собственно данную галку можно установить, это позволит немного сократить время запуска ОС. Кстати быстрый способ запустить окно Конфигурация системы: зажмите клавиши Win + R > вставьте команду msconfig > нажмите ОК, появится окно, где можно получить доступ к рассматриваемой вкладке Загрузка. 
Данное приветствие (анимация) будет отключено при установке галочки Без GUI.
Windows Server 2012 — жизнь без GUI
Windows Server 2012 позиционируется как система, которой GUI для полноценной работы не нужен. При установке по умолчанию выбран пункт Server Core, добавлена возможность удаления графического интерфейса без переустановки сервера, список ролей, не нуждающихся в GUI в сравнении с 2008 R2 расширен. В своих книгах Microsoft утверждает, что работа с командной строкой естественна и вспоминает начало 90-х годов прошлого века, когда системные администраторы жаловались на бесполезную трату ресурсов графической оболочкой. В дополнение к этому Microsoft предлагает «новый» путь администрирования своих серверных операционных систем, в котором предполагается, что серверную консоль вы будете видеть только один раз – при установке операционной системы, а вся работа и настройка системы будет осуществляться удаленно: через «Диспетчер серверов», MMC-оснастки и PowerShell, который в 2012 сервере уже версии 3.0
Допустим, что первоначальная настройка сервера после установки включает в себя:
- Настройку сетевых интерфейсов
- Установку часового пояса
- Включение удаленного рабочего стола
- Переименование компьютера
- Присоединение к домену
В исходных данных письмо от местного умельца:
Привет, поставил венду на сервер. IP – 169.254.23.43. Логин – Администратор. Пароль – qwe123!@#. Пока.
Готовимся
Удаленный сервер в рабочей группе, в свежеустановленном состоянии, RPC не понимает (порты на брандмауэре закрыты), не пингуется, с непроизносимым именем и московским часовым поясом в Сибири. Если бы это был 2008 R2 на этом бы наши приключения и закончились, так как все средства удаленного управления в нем по умолчанию отключены. В 2012 есть способ удаленно управлять из коробки – включенный по умолчанию WinRM , реализация стандарта WS-MAN от Microsoft. С одной стороны вроде дыра в безопасности, с другой – в нормально спроектированной сети, в которой сервера находятся в отдельном VLAN, доступ к которому ограничен для доверенных пользователей, вероятность использования этой дыры незначительна. Но все-таки есть.
Для управления удаленным сервером в рабочей группе с помощью WinRM, мы должны доверять удаленному серверу. Тут мне логика немного непонятна. По идее, удаленный сервер должен доверять нам, мы же им управляем, а не он нами. Возможно, это от неполного понимания принципов работы WS-MAN. Но в любом случае, сказать WinRM, что мы доверяем удаленному серверу нужно. Это реализовано занесением имени или IP-адреса удаленного сервера в список «доверенных хостов» (TrustedHosts)
Теперь как-то нужно выполнить первоначальную настройку удаленного сервера. Я знаю 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 – это новое имя для «Подключение по локальной сети». Это изменение, несмотря на кажущуюся незначительность, очень радует.
Меняем IP-адрес на нормальный с необходимой маской и шлюзом. Для этого существует другая группа Net TCP/IP Cmdlets
Добавляем DNS-серверы. Третья группа DNS Client Cmdlets
Как все это выполнить на удаленном сервере? Сделать скрипт и с помощью Invoke-Command запустить его на выполнение.
Сохраним этот набор команд где-нибудь с именем скрипта, например, remotechangeip.
По умолчанию в PowerShell разрешается работа только в интерактивном режиме, выполнение любых скриптов запрещено (restricted). Для выполнения скриптов нам нужно либо remotesigned (цифровая подпись требуется для скриптов, загруженных из интернета), либо unrestricted (при выполнении неподписанного скрипта, загруженного из интернета будет выдаваться предупреждение о ненадежности источника). Если на безопасность совсем положить, можно поставить bypass (будет выполняться все без лишних вопросов). Eсли у вас есть собственный сертификат, выданный доверенным издателем, и вы не ленитесь подписывать с его помощью свои скрипты – вам нужен allsigned (в таком случае, вы наверное и сами это знаете). У меня сертификата нет, поэтому политику я устанавливаю remotesigned.
Политика выполнения скриптов устанавливается на локальном компьютере, на удаленном такой необходимости нет, потому что Invoke-Command перед выполнением скрипта на удаленном компьютере преобразовывает файл скрипта в просто набор команд. Соответственно, на удаленном компьютере выполняется не скрипт (файл с расширением .ps1), а набор команд, которым политика выполнения скриптов по барабану.
Отправляем наш скрипт на удаленный сервер.
Пароль от учетной записи Администратор у нас есть в письме. После выполнения получаем сервер со статическим адресом 192.168.0.5 с маской подсети /24, шлюзом по умолчанию 192.168.0.1 и DNS-серверами 192.168.0.2 и 192.168.0.3
Еще нужно не забыть изменить IP в TrustedHosts, иначе на этом наше удаленное администрирование закончится.
Изменение часового пояса
Я очень долго пытался решить эту задачу с помощью PowerShell. Я нашел функцию, меняющую часовой пояс локально. Но если мы попытаемся выполнить эту функцию через Invoke-Command, получим граблями по лбу в виде «Имя Set-Timezone не распознано как имя командлета, функции, файла сценария или выполняемой программы».
Invoke-Command при выполнении естественно не копирует с локальной машины, а выполняет имеющиеся на удаленном сервере командлеты. Это понятно и логично. Задача была ясна — перед выполнением Invoke-Command нужно сбросить функцию на удаленный сервер. Но… тут мне стало лень.
Если заглянуть в код функции, то становится понятно, что она всего лишь проверяет версию ОС и в зависимости от нее выполняет либо timedate.cpl (XP и ниже), либо tzutil (Vista и выше). Проверять версию ОС незачем, мы ее знаем. Поэтому просто изменим часовой пояс с помощью tzutil
Можно попробовать установить часовой пояс, используя WMI. Выглядеть это будет так:
Что здесь происходит? Точка (.) говорит, что мы работаем с локальным компьютером. Обращаемся на локальном компьютере к классу 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, что позволит обойтись без перезагрузки и добавить правила исключения в брандмауэре одной командой.
Теперь у нас есть доступ к таёжному серверу по RDP! Можно радоваться? Представим, что единственный канал связи с внешним миром у удаленного сервера через спутник с грабительскими тарифами, диалапной скоростью, зашкаливающим пингом и продолжим настраивать сервер удаленно через PowerShell.
Переименование сервера и присоединение его к домену
Тем более, что осталось совсем немного.
По идее, командлет Add-Computer позволяет переименовать компьютер при присоединении его к домену. Но на практике, я сталкивался с тем, что при присоединении к домену и одновременным переименованием с помощью этой команды, компьютер входит в домен под своим старым именем. И понеслась – вывести компьютер из домена, перезагрузиться, удалить учетку в AD, запустить репликацию если контроллеров несколько, подождать, переименовать компьютер, перезагрузиться, ввести в домен, перезагрузиться.
Поэтому я предпочитаю операции переименования компьютера и ввода в домен выполнять отдельно.
Как только нам вернули управление, значит удаленный сервер перезагружается. Проверить результат команды (и готовность сервера) можно так:
И наконец-то ввод в домен
Заканчиваем
Все поставленные в начале задачи выполнены. Теперь уже можно думать, как дальше жить и где искать этот чертов ключ от шкафа.
Быстрый запуск Windows в 2 клика
Я Вам уже несколько раз рассказывал как ускорить запуск Windows , но все мои советы сводились к оптимизации автозагрузки программ при старте операционной системы.
Сегодня хочу рассекретить ещё один способ разгона этого процесса. Кстати, ничего устанавливать не надо при этом — быстрый запуск Windows обеспечим с помощью встроенной в систему утилиты.
Описание ускорения старта системы будет совсем коротким, потому что ничего сложного в этой процедуре нет.
Немного теории. У 99% пользователей сегодня в компьютере установлены многоядерные процессоры.
Но по какой-то непонятной причине «глупая» операционная система Windows не знает об этом. Она при своём старте не использует все эти ядра!
Ускоряем запуск Windows
Давайте принудительно заставим Windows задействовать в процессе своего запуска все ядра процессора. Это разобьёт его на несколько потоков и чуть-чуть ускорит.
Итак, тыкаем по кнопке «Пуск» в панели задач, переходим в «Все программы» — «Стандартные» — «Выполнить» и вписываем в поле…
(можно скопировать отсюда и вставить)
Читайте также на сайте:
А можно ещё проще запустить данную утилиту…
…вписать (или вставить предварительно скопированное название утилиты) сразу в поиск Windows…
Кликаем на появившейся результат поиска и попадаем в программу…
Переходим во вкладку «Загрузка» и тыкаем на «Дополнительные параметры…» …
Теперь осталось поставить галочку на «Число процессоров:» и указать максимальное значение.
Хоть и указал на скриншоте «Максимум памяти:», но НЕ СОВЕТУЮ трогать это значение вообще — было много проблем у пользователей из-за его изменения (жаловались в комментариях).
Сколько в Вашем процессоре ядер, столько и покажет в «Число процессоров:» . Например, на моём слабеньком ноуте, как видите, всего два ядра показало, а в компе моей жены — 4. Про супер-компьютер сына вообще молчу — все 8 штук ядер выскочило.
Теперь жмём «Ок» и попадаем в предыдущее окно, где осталось кликнуть на «Применить» . Соглашаемся с предупреждением и перезапускаем компьютер.
Если заметили, я поставил ещё галочку на «Без GUI» и изменил таймаут с 30 на 3 секунды (меньше не даёт). Галка на «Без GUI» означает отключение всей анимации при загрузке Windows.
Не будут мелькать при старте системы всякие надписи — будет просто чёрный экран. Это тоже слегка ускоряет процесс запуска, но есть обратная сторона медали.
Если при старте запустится сканирование и исправление ошибок (например, после резкого отключения питания компьютера) то Вы не поймёте, что происходит, почему система не запускается в течении нескольких минут.
Начнёте паниковать, тыкать на кнопки перезапуска и питания… потом истерика, инфаркт… и во всём этом обвините меня. ��
Если Вы не уверены, что являетесь отважным хакером — оставляйте снятой галку на «Без GUI» .
Ещё капелька ускорения запуска системы
Ещё можно капельку ускорить запуск Windows пройдя по пути: кнопка «Пуск» на панели задач — «Панель управления» — «Система» — «Дополнительные параметры системы» — «Загрузка и восстановление» (Параметры)…
…и снять галку с «Отображать список операционных систем:» …
Такой быстрый запуск Windows в 2 клика. До новых полезных компьютерных программ и интересных приложений для Андроид.
Особенности GUI загрузки в Windows 7
В погоне за оптимизацией своей операционной системы Windows 7, я перерыл немало недр интернета, находя при этом как полезные статьи, так и вредительские советы.
Сегодня хочу остановиться на весьма спорном совете, который часто можно услышать от аматоров оптимизации: включения опции «Без GUI» в Конфигурации системы (она же msconfig, раздел Загрузка).
Что будет если выбрать «Без GUI»?
Существует такое мнение, что на быстрых машинах загрузка Windows 7 будет еще быстрее, если отключить анимационную заставку в загрузчике. Обосновывают это обычно тем, что анимационная заставка НЕ прерывается, а должна проиграться до конца. Т.е. если ОС успела загрузить все драйвера, службы и пр. до окончания анимации, то потом ОС будет просто ждать, пока закончится анимация. А это мол неоправданно замедляет загрузку.
В этом суждении доля рациональности конечно есть. Например, почему не советуют ставить свои, особенно длинные звуки на системные события Windows? Особенно, это будет касаться выхода из сеанса и завершения работы. ОС так настроена, что не завершит сеанс или работу, пока звук не закончит воспроизведение 😉 С одной стороны это логично, но если вы поставите на эти действия целые песни по 3 минуты, простая перезагрузка или смена пользователя будет крайне раздражающим событием. Кстати поэтому все системные звуки в Windows 7 такие короткие 😉
Почему этого делать не нужно 😉
Но вернемся к нашей опции «Без GUI». Если мы установим эту галочку, то никакой анимации при загрузке Windows 7 вы не увидите. У вас будет просто черный экран,а потом появится приглашение Windows. Вроде хорошо, никаких тебе притормаживаний при загрузке.
Однако это одна сторона медали. Есть еще и другая, о которой все почему то забывают написать 😉 Дело в том, что такие функции как chkdsk выполняются именно в этом же GUI, что и загрузка ОС. А это значит, что если например у вас запустится проверка диска или дефрагментация реестра, вы… ничего не увидите на экране!
Благо, что я это знаю и уже кстати сегодня снял галочку Без GUI. А вот другого пользователя может насторожить черный экран, который долго весит при загрузке (а в это время например идет проверка диска на ошибки, БОЛЬШОГО диска). Скорее всего последует нажатие кнопки Reset, но после перезагрузки все снова повториться 😉 И вот вам — совершенно не нужная переустановка ОС.
А о том, как правильно оптимизировать загрузку ОС, читайте в следующем посте.