Руководство по установке Windows Server Windows Server Installation Guide

Подсистема Windows для Linux доступна для установки на Windows Server 2019 (версия 1709) и более поздних версий. The Windows Subsystem for Linux is available for installation on Windows Server 2019 (version 1709) and later. В этом руководстве рассматриваются действия по включению WSL на компьютере. This guide will walk through the steps of enabling WSL on your machine.

Включение подсистемы Windows для Linux Enable the Windows Subsystem for Linux

Перед запуском дистрибутивов Linux в Windows необходимо включить дополнительный компонент «Подсистема Windows для Linux» и перезагрузить компьютер. Before you can run Linux distros on Windows, you must enable the «Windows Subsystem for Linux» optional feature and reboot.

Запустите PowerShell с правами администратора и выполните следующую команду. Open PowerShell as Administrator and run:

Скачивание дистрибутива Linux Download a Linux distribution

Выполните эти инструкции, чтобы скачать избранный дистрибутив Linux. Follow these instructions to download your favorite Linux distribution.

Извлечение и установка дистрибутива Linux Extract and install a Linux distribution

После загрузки дистрибутива Linux для извлечения его содержимого и установки вручную выполните следующие действия. Now that you’ve downloaded a Linux distribution, in order to extract its contents and manually install, follow these steps:

Извлеките содержимое пакета .appx , с помощью PowerShell: Extract the .appx package’s contents, using PowerShell:

Запустите средство запуска приложения дистрибутива в целевой папке. Run the distribution launcher application in the target folder. Средство запуска обычно называется .exe (например, ubuntu.exe ). The launcher is typically named .exe (for example, ubuntu.exe ).

Сбой установки с ошибкой 0x8007007e. При возникновении этой ошибки система не поддерживает WSL. Installation failed with error 0x8007007e: If you receive this error, then your system doesn’t support WSL. Убедитесь, что вы используете сборку Windows 16215 или более позднюю версию. Ensure that you’re running Windows build 16215 or later. Проверьте используемую сборку. Check your build. Также убедитесь, что WSL включен и ваш компьютер перезагружен после включения этой функции. Also check to confirm that WSL is enabled and your computer was restarted after the feature was enabled.

3. Добавьте путь дистрибутива в путь среды Windows (в этом примере: C:\Users\Administrator\Ubuntu ), с помощью PowerShell: 3.Add your distro path to the Windows environment PATH ( C:\Users\Administrator\Ubuntu in this example), using PowerShell:

Теперь вы можете запустить дистрибутив из любого пути, введя .exe . You can now launch your distribution from any path by typing .exe . Например: ubuntu.exe . For example: ubuntu.exe .

После установки необходимо инициализировать новый экземпляр дистрибутива, прежде чем его можно будет использовать. Now that it is installed, you must initialize your new distribution instance before using it.

Как запустить Linux на Windows Server 2019 с WSL

Вопросы: Как включить функцию Windows Subsystem for Linux (WSL) на Windows Server 2019?

Как использовать Linux на Windows Server 2019?

В этом руководстве показано, как включить функцию Windows Subsystem for Linux (WSL) на сервере Windows 2019 и запустить сервер Linux, например Ubuntu, внутри Windows Server.

В нашей последней статье мы рассмотрели запуск контейнеров Docker на Windows Server.

Подсистема Windows для Linux позволяет вам запускать среду GNU / Linux, которая включает большинство инструментов, утилит и утилит командной строки Linux непосредственно в вашей системе Windows без каких-либо изменений или издержек в хост-системе.

Одна предварительная версия уже установлена Windows Server 2019.

Достаточно повезло,что у нас есть руководство по установке Windows Server 2019.

Шаг 1. Включите функцию Windows Subsystem для Linux (WSL) в Windows

Прежде чем вы сможете установить любой дистрибутив Linux для WSL, вы должны убедиться, что включена функция «Windows Subsystem for Linux»:

Откройте PowerShell от имени администратора и выполните следующую команду, чтобы включить функцию Windows Subsystem for Linux (WSL) в Windows.

Согласитесь и перезагрузите компьютер при появлении соответствующего запроса.

Вы можете сделать то же самое из Диспетчер серверов графического интерфейса Server Manager>Add roles and features>Select features

Шаг 2: Установите свой Linux

Существуют различные способы установки дистрибутивов WSL Linux через Microsoft Store.

В этом руководстве мы будем использовать скачать и установить один из командной строки.

Запустите PowerShell и загрузите дистрибутив с помощью командлета Invoke-WebRequest или curl.exe. Вот пример инструкции по загрузке Ubuntu 18.04.

После загрузки распакуйте и установите дистрибутив Linux.

Измените свой рабочий каталог на ubuntu1804 и запустите программу установки, чтобы завершить установку дистрибутива.

Программа установки предложит вам указать имя пользователя и пароль для создаваемого пользователя UNIX.

Команда sudo может использоваться для привилегированных операций.

Добавьте свой путь к дистрибутиву в среду PATH среды Windows, используя Powershell:

Это позволит вам запустить ваш дистрибутив с любого пути, набрав .exe загрузчик

Например, используя ubuntu1804.exe.

Обратите внимание, что для этого потребуется закрыть и перезапустить PowerShell.

Наслаждайтесь использованием дистрибутива Linux на вашем Windows Server. Другие дистрибутивы Linux, которые вы можете запустить:

Windows Deployment Services и DHCP-сервер на Linux + пара особенностей

Будучи начинающим администратором, я стремлюсь познать все новое и как губка впитывать информацию. Так же ценю порядок в IT-инфраструктуре предприятия, логичность, доступность и универсальность. Стремясь добиться последнего, (использовать для Active Directory nix-овый DNS — BIND) не так давно потерпел фиаско, но не останавливаюсь на достигнутом. Я хотел бы поделиться с вами информацией, касающейся роли Windows Deployment Services в Windows Server 2012 и настройкой ее для работы со сторонним DHCP-сервером на Ubuntu Server.

Часть 1. Настройка DHCP-сервера

Вся сеть в нашей организации построена на UNIX-системах, а для, пусть и скромного по меркам IT, парка машин в 50 шт. все же хочется использовать все современные блага и удобства администрирования. Встал вопрос: как разворачивать Windows на ПК пользователей по сети, когда TFTP-сервер будет находиться отдельно от DHCP? Задача, хоть и простая, но заставила меня бегло изучить работу и настройку DHCP-сервера на Ubuntu. Нам же важна универсальность. 🙂 Не поднимать же ради этого «виндовый» DHCP.

Всего-то требовалось, при описании сети, указать командой next-server, что TFTP-сервер находится на другом хосте. Приведу фрагмент конфига DHCP на примере сети 192.168.1.0/24:

Вот, собственно, и все. /etc/init.d/isc-dhcp-server restart. Переходим к настройке WDS.

Часть 2. Настройка роли Windows Deployment Services

Об установке роли вряд ли можно что-то сказать. Она проста, не требует перезагрузку и просит указать, какие компоненты нужно ставить. Нам нужны оба компонента: Сервер развертывания и Транспортный сервер.

После установки роли, ее консоль будет доступна в списке Администрирование Панели управления Windows Server и носит название Службы развертывания Windows.

Первоначально сервер нужно настроить. ПКМ по серверу слева и выбираем «Настроить сервер». Настройка не представляет собой ничего сложного, я расскажу лишь о важных, на мой взгляд моментах:

Если в вашей сети используются доменные службы Active Directory, то при настройке сервера можете указать, будет ли сервер изолирован или завести его в AD. Куда важнее будет позже отметить, что DHCP-сервер находится в другом месте и не нужно слушать подключения на портах нашего WDS-сервера.

• Вам потребуется указать, интегрировать ли сервер в AD
• Указать место хранения образов установки
• Выбрать политику ответов клиентам. Здесь немного подробнее.

Если ограничиться только установкой системы, то можно выбрать пункт «Отвечать всем. » т.к., установка Windows потребует пары логин/пароль от сервера, с которого происходит загрузка. Несанкционированная установка «винды по сетке» не прокатит.

• В конце будет предложено добавить первый образ

Хочу обратить ваше внимание на вкладку «Протокол DHCP» свойств сервера.

Здесь как раз и требуется снять птичек, если вы используете сторонний DHCP-сервер. А на вкладке «Клиент» можно указать, заводить ли новых пользователей в домен.

Часть 3. Интересности

Как известно, образы Windows добавляются на WDS-сервер в два этапа: добавления загрузочного образа (boot.wim) и образа установки (install.wim). Вот тут я и заметил маленькую и интересную особенность. В нашей компании используются ОС Windows, начиная с Windows 7, Server 2008R2 и заканчивая Windows 8.1 и Server 2012. Как известно, содержимое boot.wim — это то, что мы видим, запустив установку Windows с диска. И если при установке с диска важны только драйверы на контроллер HDD, то для сетевой установки важны еще драйвера на сетевой адаптер. В этой статье хорошо описан способ внедрения драйверов в дистрибутив с помощью WAIK. Но когда я добавил образ загрузки из дистрибутива Windows 8.1 и проверил его, то заметил, что база драйверов на сетевые адаптеры расширена. Но главная особенность не в этом. 🙂 Используя один, самый последний образ загрузки Windows (пусть даже собранный вами лично с помощью WAIK), можно устанавливать любые редакции Windows, начиная с Windows Vista, заканчивая Windows Server 2012R2. Вам не нужно добавлять кучу образов для загрузки — выберет один, универсальный и современный. Можно добавлять только образы установки (install.wim), выбирая, какие редакции Windows вам нужны.

Вы можете создать в консоли управления WDS группы образов…

… и в результате получите при установке список всех ОС, из групп Desktop и Servers, выберете нужную и проинсталлируете. Не забывайте, для установки требуется ввести логин/пароль администратора сервера.

Содержимое каталога, где хранятся образы установки, будет выглядеть следующим образом:

Несмотря на банальность происходящего, это не помешает вам установить любую Windows из добавленных вами на сервер.

Вот, собственно, и все, чем я хотел с вами поделиться. Если хотите расширить возможности WDS, на хабре есть статья «Добавляем WDS универсальности», где еще больший любитель этой самой «универсальности», рассказывает, как заставить WDS использовать GRUB2, а отсюда и установка Linux и утилиты реанимации… В общем, все для того, чтобы современный админ не таскал с собой флешку.

Я за совместное использование Windows и Linux. Спасибо за внимание!

Перекрестное опыление: управляем Linux из-под Windows, и наоборот

В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.

Microsoft Loves Linux

Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.

Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).

Это позволяет настроить удаленное управление с помощью единого инструмента ― PowerShell. Помимо подключения к консоли компьютера, можно запускать отдельные команды, в том числе и на нескольких серверах одновременно. Довольно удобно для автоматизации задач администрирования, таких как массовое изменение настроек, инвентаризация, сбор логов.

Порой удобно совмещать традиционные консольные команды со вставками PowerShell:

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.

PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.

Магомед не идет к горе

Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.

Для начала установим на Centos свежий PowerShell:

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:

Работаем в консоли PowerShell на CentOS.

Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:

• OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
• PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:

После настройки можно проверить работу OMI из консоли Windows:

Подключаемся к CentOS из cmd.

Теперь проверим работу обратным подключением ― из Linux к Windows:

… а затем с CentOS подключаемся к Windows.

После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:

С Windows на Linux.

Аналогичным образом можно провести и обратное подключение.

Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.

Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.

Гора идет к Магомету

На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.

После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.

PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.

В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:

Теперь генерируем ключи:

В тестовой среде мы будем использовать парольную аутентификацию, поэтому стоит убедиться что она включена в файле sshd_config:

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:

Остается только настроить и запустить службы:

После установки уже можно наслаждаться подключением к серверу Windows по ssh.

C Windows через Putty на Linux, с Linux обратно на Windows по SSH.

На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.

Работаем из PowerShell с Linux-сервером.

Теперь подключимся из Linux к Windows:

Работаем из PowerShell с Windows-сервером.

В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.

В хозяйстве пригодится

С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.

В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.