Windows server 2019 виртуальные рабочие столы

Установка и настройка удаленных рабочих столов на основе Microsoft VDI

Опубликовано: 17.12.2022

Рабочие столы на основе DVI позволяют создать для каждого пользователя свое рабочее пространство с изолированными настройками. Подключение будет выполняться как на терминальный сервер, только попадать мы будем в изолированную виртуальную машину.

В данной инструкции будут приведены примеры развертывания и настройки роли удаленных рабочих столов на основе Windows Server 2012 R2.

Подготовка сервера

Для развертывания роли VDI необходимо, чтобы в нашей инфраструктуре были серверы со следующими ролями:

1. Active Directory Domain Services (AD DS).
2. Hyper-V на отдельном сервере от AD DS.

Настройка операционной системы

Подготовим наш сервер к работе. Для этого необходимо:

• Установить обновления.
• Задать статический IP-адрес.
• Переименовать компьютер.
• Указать правильные часовой пояс и время.

AD DS

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

При отсутствии Active Directory необходимо его установить и настроить. Если мы имеем один единственный сервер, то AD DS можно развернуть на отдельной виртуальной машине, а из самого хоста виртуализации сделать VDI.

Как установить соответствующую роль и создать новый лес с доменом подробнее рассказано в статье по ссылке ниже.

OU

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

* в данном примере мы создали организационный юнит VDI Desktops для компьютеров и VDI Users для пользователей.

Hyper-V

Данная роль является центральной для развертывания VDI. Чтобы ее установить, открываем панель управления сервером — в правой верхней части нажимаем Управление — Добавить роли и компоненты:

В открывшемся окне нажимаем Далее — в окне «Выбор типа установки» оставляем Установка ролей и компонентов:

… Далее. В следующем окне выбираем наш сервер — Далее.

Выбираем роль Hyper-V:

… если откроется дополнительное окно, выбрать Добавить компоненты. Далее.

Кликаем несколько раз Далее до окна «Создание виртуальных коммутаторов» — выбираем сеть, которую будем использовать для виртуальных машин:

… Далее. «Миграция виртуальной машины» — Далее.

В окне «Хранилища по умолчанию» оставьте пути как есть или задайте свои значения:

… Далее — в последнем окне Установить.

Перезагружаем сервер.

Создание шаблона виртуальных машин

Для подготовки системы мы будем использовать встроенную в Windows утилиту sysprep. В процессе ее работы текущая система становится больше неработоспособной. Убедитесь, что в качестве будущего эталона выбрана чистая система без важных данных и настроек.

Создаем виртуальную машину и устанавливаем на нее операционную систему Windows. В моем случае использовалась Windows 10 Pro.

Создать виртуальную машину можно с помощью графического интерфейса (Диспетчер Hyper-V) или команд Powershell.

Далее в рамках подготовки шаблона выполняем:

1. Установку операционной системы.

2. Удаление лишних учетных записей и включение встроенной записи администратора. При необходимости, можно создать дополнительных пользователей.

3. Задаем имя компьютера.

4. Вводим компьютер в домен.

5. Готовим эталонный образ: настраиваем систему по желанию и устанавливаем нужные программы.

Когда виртуальная машина будет готова, открываем командную строку в нашем Windows 10 и выполняем команду:

c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /shutdown /mode:vm

После недолгого выполнения шаблон будет готов. Напоследок, отключите примонтированный установочный ISO, если он использовался для установки Windows.

Развертывание терминальных служб

Переходим к установке и настройке служб удаленных рабочих столов.

Установка роли удаленных рабочих столов

Открываем панель управления сервером — в правой верхней части нажимаем Управление — Добавить роли и компоненты:

В открывшемся окне нажимаем Далее — в окне «Выбор типа установки» оставляем Установка служб удаленных рабочих столов:

… Далее. В окне «Выбор типа развертывания» оставляем Стандартное развертывание:

 

… Далее. В окне «Выбор сценария развертывания» оставляем Развертывание рабочих столов на основе виртуальных машин:

… Далее. «Обзор служб ролей» — Далее.

В следующих 3-х окнах нужно выбрать серверы, на которые мы будем развертывать роли «Посредник подключений к удаленному рабочему столу», «Веб-доступ к удаленным рабочим столам», «Узел виртуализации удаленных рабочих столов» — если сервер один, то все данных роли ставим на него.

В окне «Подтверждение выбора» ставим галочку Автоматически перезапускать конечный сервер, если это потребуется и кликаем по Развернуть:

В процессе установки наш сервер перезагрузится. После перезагрузки развертывание продолжится — по окончании процесса закрываем окно:

Настройка свойств развертывания

В панели управления сервером кликаем по Службы удаленных рабочих столов:

В открывшемся окне находим «Обзор развертывания» — кликаем по Задачи — выбираем Изменить свойства развертывания:

В открывшемся окне «Настройка развертывания» переходим в раздел Active Directory — в разделе «Подразделение» выбираем ранее созданный организационный юнит VDI Desktops:

… мы увидим ошибку о том, что наше подразделение неправильно настроено — просто нажимаем Применить — система внесет необходимые настройки и значок ошибки пропадет.

Создание коллекции

Открываем консоль управления сервером, переходим к роли удаленных рабочих столов и кликаем по Коллекции:

Справа нажимаем Задачи и выбираем Создать коллекцию виртуальных рабочих столов:

На странице приветствия просто нажимаем далее:

Вводим имя коллекции (в моем случае, VDI):

На следующей странице у нас есть возможность выбрать тип коллекции — это будет общий пул виртуальных машин или у каждого пользователя своя индивидуальная ВМ. Оставляем по умолчанию:

Выбираем ранее созданный шаблон, на основе которого будут выделяться виртуальные машины:

На следующем этапе мы можем указать файл ответов sysprep для более детальной настройки машины при старте. Мы же оставляем все как есть:

На данном этапе мы выбираем часовой пояс, который нам подходит, а также имя подразделения, куда будут помещаться создаваемые виртуальные машины — в нашем примере это VDI Desktops:

Указываем группу безопасности, пользователям которой будет разрешено подключение по RDS к виртуальным машинам (в моем случае, достаточно Domain Users), также мы можем задать максимальное количество виртуальных машин, которые могут быть созданы на Hyper-V для данной коллекции. Еще мы можем задать свой префикс, который будет использоваться в качестве имени компьютера виртуальной машины:

На следующей странице можно оставить настройки по умолчанию или указать другое количество виртуальных машин, которые будут созданы заранее:

Укажем, где будут храниться виртуальные машины — в выбранной папке будет создан каталог с именем коллекции, а в нем будут создаваться файлы виртуальных машин и дисков:

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

На последнем шаге мастера мы подтверждаем наши настройки:

Начнется процесс настройки и создания виртуальных машин. В зависимости от их количества, процедура может занять много времени. Ждем — в итоге мы должны увидеть сообщение об успешном создании коллекции:

Я столкнулся с ошибкой:

Не удалось получить подробные сведения о шаблоне виртуального рабочего стола.

В моем случае, проблема была из-за использующегося снапшота для шаблона виртуальной машины. После его удаления проблема исчезла.

Наш сервер готов.

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

Файл для подключения доступен на веб-интерфейсе терминального сервера. Его можно получить, перейдя в браузере по адресу https://<имя сервера RDS>/RDWeb/, введя доменные логин и пароль и выбрав подключение к нашей коллекции:

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

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

Если мы хотим подключаться к нашему серверу через Remote Desktop Gateway, то откроем файл подключения к коллекции текстовым редактором и добавим строки:

…
gatewayhostname:s:rdg.dmosk.local
gatewayusagemethod:i:1
…

* где rdg.dmosk.local — адрес шлюза удаленных рабочих столов.
** эти опции могут уже присутствовать в файле, тогда нужно их проверить и при необходимости, отредактировать.

Читайте также

Другие полезные инструкции, которые дополнят данное руководство:

1. Как установить роль контроллера домена на Windows Server.

2. Установка и настройка терминального сервера на Windows Server.

3. Установка и использование Remote Desktop Gateway.

Время на прочтение
13 мин

Количество просмотров 14K

Все переходим на «удалёнку»! Это стало главной задачей примерно 2 месяца назад, когда мир изменился. Компаниям, которые мы обслуживаем как архитекторы облачных решений, в дополнение к настройке VPN к своей инфраструктуре понадобились удалённые рабочие столы. Удалённые рабочие столы для компаний нельзя назвать новой потребностью, которая ранее не была закрыта в компаниях вообще – у многих были и есть крупные локальные фермы VDI и терминальные сервера. Из-за массовости и скорости необходимого перехода на первый план у заказчиков, в разной степени, появились следующие проблемы:

• Инфраструктура: скорость развёртывания удалённого доступа, в том числе необходимые для этого мощности
• VPN: безопасный доступ к корпоративной инфраструктуре в реалиях сложности предоставления доступа с домашних устройств, количество сессий VPN которое могут выдержать роутеры и т.д.
• Доступ к рабочим станциям: удалённый доступ к ноутбукам, которые у некоторых заказчиков по политикам безопасности должны находиться локально в компании и т.д

Многим нужно было решить эту задачу «по щелчку». Да, в корпоративном ИТ «по щелчку» редко что происходит, потому требуется заказать оборудование, лицензии, выделить сотрудников для проведения работ. Но с облачным Windows Virtual Desktop «щёлкать» будет проще и быстрее.

В этой статье мы расскажем о том, как планировать архитектуру при развёртывании Windows Virtual Desktop. Также обратим ваше внимание на несколько партнёрских решений, которые смогут качественно дополнить внедряемое.

Примечание: вы можете попробовать этот сценарий в Azure самостоятельно.

Предоставление сервиса удалённых рабочих мест (VDI) и терминальных серверов в масштабах компании, даже небольшой, требует существенного объёма работы от администраторов. Большая часть времени уходит на настройку и интеграцию множества компонентов, из которых состоит эти сервис. Microsoft предлагает посмотреть на эту задачу по новому с Windows Virtual Desktop (WVD). WVD это облачный сервис по виртуализации десктопов и приложения на базе Microsoft Azure. Главные преимущества WVD включают:

• Интеграцию и управление компонентами, отвечающими за предоставление удалённых десктопов и приложения. Их обеспечивает Microsoft, предоставляя бесплатно как сервис с SLA.  
• Лицензии на использование ОС и доступа к ней. Они уже включены во многие популярные пакеты Microsoft и не требуют дополнительных затрат, минимизируя стоимость решения в целом.
• Сервис предоставляет возможность использования Windows 10 в формате терминального сервера, минимизируя стоимость сессии.

WVD Fall 2019 Release (GA) и Spring 2020 Update (Preview)

30 апреля в WVD стал доступен новый функционал, который сгруппирован под названием Spring 2020 Update. Этот функционал сейчас доступен в Public Preview и на него не распространяется SLA. На GA функционал, предоставляемый в рамках предыдущей версии — Fall 2019 Update, предоставляется с SLA 99.9%. ВМ, на базе которых предоставляются пулы для пользовательских сессий, покрываются своим SLA 99.95%. Функционал, связанный с Spring 2020 Update, планируется к переводу в GA в течение 2020 года. Так же будут подготовлены инструменты миграции экземпляров, построенных на базе Fall 2019 release, в новую версию.

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

• This content applies to the Fall 2019 release that doesn’t support Azure Resource Manager Windows Virtual Desktop objects.
• This content applies to the Spring 2020 update with Azure Resource Manager Windows Virtual Desktop objects.

Главными изменениями сервиса в Spring 2020 Update являются:

• Управление жизненным циклом объектов сервиса через Azure Portal без необходимости развёртывания дополнительного веб приложения и использования отдельного набора PowerShell команд.
• Возможность назначения приложений на группы пользователей
• Использование Azure RBAC для управления ролями, необходимыми для использования сервиса, а не выделенными ролями.
• Встроенная возможность масштабирования, без необходимости использования внешнего приложения на основе Logic Apps

Если вам необходим гарантированный SLA и запуск в прод, то сейчас лучше выбрать Fall 2019 release. Если же вы только пробуете и хоте испытать новые возможности WVD, то начните с Spring 2020 Release.

Оценка стоимости

Бюджетную оценку по использованию сервиса, можно произвести на базе Azure Pricing Calculator. Для этого из списка сервисов необходимо выбрать Windows Virtual Desktop. Калькулятор подразумевает наличие необходимых лицензий на Windows Client или Windows Server OS (детали здесь):

На странице Windows Desktop Pricing в разделе Personal Desktop и Multi-session Desktop example scenarios приведены ссылки на расчёты в калькуляторе, которые компонуют необходимые дополнительные ресурсы, такие как облачное хранилище для контейнеров профилей, сетевой трафик и т.д. с точки зрения стоимости преимущества использования WVD максимально проявляет себя при использовании Windows 10 Enterprise multisession в сценарии использования совместного пула. При интеграции с локальным ЦОД в расчёт стоит дополнительно включать стоимость Azure VPN Gateway и исходящего трафика.

Архитектура Microsoft Windows Virtual Desktop

Понимание архитектуры WVD позволит вам принять правильные решения при планировании и развёртывания сервиса, а также выстроить корректные ожидания от его производительности.

Для обсуждения, давайте разобьём архитектуру на блоки:

1. Клиенты
2. Windows Virtual Desktop
3. Ресурсы в подписке заказчика
4. Корпоративная сеть (aka on-prem, он-прем)

Клиенты

Конечный пользователь может подключаться к сервису как с использованием тонкого клиента через веб браузер, так и через толстый клиент на Windows, Mac, iOS, Android (все клиенты здесь). После авторизации пользователь видит иконки для подключения к удалённым десктопам или приложениям RemoteApp. Доступ к удалённым десктопам происходит по протоколу RDP поверх HTTPS. Дополнительным преимуществом использования толстого клиента на Windows является то, что опубликованные приложения синхронизируются в меню Старт.

Доступ происходит к единой публичной отказоустойчивой (SLA 99.5%) точке сервиса по адресу https://rdweb.wvd.microsoft.com/. Кастомизировать URL возможно с использованием сервиса Azure Front Door как описано здесь.

При логине в сервис используется учётная запись в Azure Active Directory (aka Azure AD), который вам необходимо иметь или создать. В облачной Azure AD необходимо создать учётные записи для пользователей или настроить синхронизацию УЗ через Azure AD Connect из вашей локальной сети. Для повышения безопасности доступа при аутентификации пользователя можно настроить использование Azure MFA, а так же создать другие дополнительные политики аутентификации с использованием Conditional Access (как описано здесь)

Для усиления безопасности функции клиента можно ограничить через кастомные настройки RDP, такие как отключение работы буфера обмена (clipboard), проброса локальных дисков внутрь удалённой сессии и т.д. Настройка производится как описано здесь, полный список свойств, которые можно использовать, можно посмотреть здесь.

Windows Virtual Desktop

Это управляемая Microsoft-ом часть сервиса Windows Virtual Desktop, отвечающая за авторизацию пользователей, безопасный доступ к пулам десктопов, логгирование событий сервиса. Подключение к ВМ происходит с использованием подхода «reverse connect» – авторизации/аутентификации подключения по WebSocket по 443-порту с инициацией со стороны ВМ. Таким образом из Интернет не предоставляется прямой доступ к ВМ и нет открытых в Интернет портов. Процесс открытия сессии выглядит следующим образом:

1. Пользователь, через клиент Remote Desktop (RD), запрашивает токен в Azure AD. Он получает его после аутентификации и проверки в том числе с использованием MFA, Conditional Access и Intelligent Security Graph.
2. Клиент предоставляет токен в Web Access и через Broker происходит обращение в СУБД Azure SQL DB для получения списка ресурсов (приложений и десктопов), к которым может подключаться пользователь.
3. После выбора ресурса клиент RD подключается к Gateway.
4. Брокер оркеструет подключение от Агента WVD к Gateway-ю.
5. Трафик ходит от агента RD десктопа к ВМ хоста через WebSocket

Облачная часть

При создании экземпляра сервиса WVD, в Azure AD создаётся конфигурационная запись WVD tenant (тенанта). В Azure SQL DB управляемой части сервиса хранятся т.н. метаданные, относящиеся к ресурсам этого тенанта: соответствие десктопов и приложений пользователям, конфигурация пулов, список опубликованных приложений и так далее. В Fall 2019 Release эти данные хранятся в ЦОДах в США (см здесь). По мере развития сервиса Spring 2020 Release появится возможность хранить метаданные в других регионах, в том числе в West Europe.

Сессионные ВМ, на базе которых предоставляются десктопы и приложения, а так же профили пользователей хранятся в регионе Azure (ЦОДе), который вы выберите при развёртывании этих компонентов. Для максимальной производительности все компоненты сервиса стоит располагать в едином регионе.

Свой ближайший ЦОД вы сможете выбрать с использованием инструмента Windows Virtual Desktop Experience Estimator, который измерит задержку (RTT – round trip time) от вашего рабочего места до ЦОДа и обратно. По опыту работы для большинства пользователей из России ближайшим является регион West Europe.

Конечные пользователи и их техническая поддержка смогут в процессе работы мониторить производительность удалённого подключения с использованием Connection Experience Indicator for RDS & WVD.

Необходимым условием развёртывания экземпляра сервиса является присоединение виртуальных машин пула к AD DS. AD может быть как облачной на базе Azure AD (AAD DS), так и на базе локального AD. При настройке WVD для большинства сценариев подходит использование Azure AD DS, он достаточно быстро и просто настраивается. AAD DS также поддерживает работу с групповыми политиками.

Если вам необходима интеграция с локальным AD, тогда необходимо настроить VPN из Azure в локальную инфраструктуру. Об этом подробнее расскажем в разделе «локальная часть». Для развёртывания AAD DS в виртуальной сети в Azure необходимо создать выделенную подсеть. При развёртывании AAD DS будет необходимо указать УЗ, которую можно будет использовать для введения ВМ в домен. Для данной УЗ будет необходимо произвести процедуру сброса пароля для синхронизации хэша пароля в формате, который использует сервис по процессу, описанному здесь. После развёртывания AAD DS, необходимо в настройках сервиса указать его как источник DNS записей для вашей виртуальной сети.

При создании пула сессионных ВМ вы можете воспользоваться предложенным размером ВМ – D4s_v3 (4 vCPU, 16GB памяти) или указать более подходящий вам. Критичным может оказаться выбор размера ВМ в пуле. Одним из подходов к определению размера ВМ является разделение пользователей по типам: Light, Medium, Heavy и Power, которым будут соответствовать конфигурации как описано здесь.

Это подход может помочь при бюджетной оценке решения и первом подходе, но реальность внесёт свои коррективы. Для эмпирической оценки мощностей необходимых для обеспечения работы ваших пользователей можно использовать бесплатную версию SysTrack Windows Virtual Desktop Assessment.

Ресурсы в пулах представляются в двух вариантах – pooled и dedicated – совместные и выделенные ВМ. При использовании «совместного» пула несколько пользователей могут подключаться на одну ВМ в формате терминального сервера, в «выделенном» — ВМ закрепляется за конкретным пользователем. При начале работы с WVD можно начинать рассмотрение с ВМ серии:

• Ds_v3 – сбалансированное соотношение vCPU и памяти
• Fs_v2 – высокое соотношение vCPU к памяти
• NVs_v3 – специализированные ВМ с GPU для работы с 3D графикой

При выборе типа виртуальной машины стоит обратить внимание на её максимальную производительность, представленную в таблицах как в примере ниже. Все размеры виртуальных машин можно посмотреть здесь.

Рекомендуемым типом диска для ВМ в пулах WVD является SSD диск типа «Premium». Диск для данного типа в стандартных образах ОС имеет размер 128GB (P10) и соответствующей этому размеру производительность – 500 IOPS (кратковременная пиковая до 3.5K IOPS), 100 MiB/sec. Производительность локального диска можно поднять, увеличив его размер до 2TB (P40).

По умолчанию профили пользователей размещаются на локальных дисках виртуальных машин в пуле. Ограничение такого подхода, является как сравнительно небольшая максимальная производительность локальных дисков, так и доступность профиля при выходе ВМ из строя при сбое или апгрейде. Вторым вариантом является размещение профиля на сетевом диске. Существует несколько технологий удалённого хранения профиля пользователей — Roaming user profiles (RUP), User profile disks (UPD), Enterprise state roaming (ESR). Каждый из этих подходов имеет свои ограничения при обеспечении работы подробно описанные здесь.

В 2018 году Microsoft приобрёл технологию FSLogix, которая решает многие вызовы при работе с профилями. При подключении к удалённому десктопу или запуске удалённого приложения, через сервис WVD, FSLogix динамически подключается к сетевому ресурсу и с него подключает контейнер c профилем пользователя. FSLogix так же интегрируется с облачным решением Azure Files (SLA 99.9%) и AD – как облачным так и локальным. Ввиду высокой скорости работы и соотношения цена/функционал связка FSLogix/Azure Files/Azure AD является отличным вариантом для использования совместно с WVD.

Для высокой масштабируемости и производительности Azure Files (до 100K IOPS, 5GBps пропускной способности при задержке в 3ms) рекомендуется использовать редакцию Premium. При использовании редакции Premium производительность папки завязана на её размер, и как результат на стоимость. Более подробно о расчёте производительности и цены для редакцию Premium смотрите здесь. Стоит обратить внимание на возможности в Premium редакции накапливать «кредиты» и использовать их для кратковременного ускорения при пиковых нагрузках.

Ввиду необходимости подключения контейнера FSLogix к ВМ с ACL соответствующими пользователю необходимо интегрировать сервис с AD – облачным или локальным. Интеграция Azure Files c Azure AD доступна в GA, тогда как интеграции с локальным AD сейчас находится в Preview. Подключение ВМ к Azure Files так же возможна с применением Private Endpoint, которые предоставляют доступ к сервису с использованием приватной адресации в Azure.

Сценарии и преимущества других вариантов хранения профилей с использованием FSLogix таких как Azure NetApp Files или Storage Spaces Direct описаны здесь. При использовании контейнеров FSLogix необходимо обратить внимание на их размер по умолчанию (30GB) и ознакомиться с возможными инструментами для управления ими.

Для оценки производительности ВМ в пуле, можно воспользоваться встроенным средством Azure Monitor.

Также вы можете рассмотреть бесплатное комплексное решение для мониторинга, включающее в себя метрики сервиса VWD — Azure Monitor for RDS and Windows Virtual Desktop от компании Sepago. Для полного функционирования решения необходимо развернуть агенты Sepago внутри ВМ вашего пула. Для сбора и хранения метрик используется Azure Log Analytics, который тарифицируется отдельно (см Log Analytics -> Pay as you Go).

При развёртывании WVD необходимо заранее запланировать распределение подсетей внутри виртуальной сети Azure. В зависимости от конфигурации, которую вы развёртываете, вам могут потребоваться:

• одна или несколько подсетей для пулов WVD
• подсеть для AAD DS или доступ к ней через пиринг виртуальных сетей
• подсеть для Azure VPN GW или Network Virtual Appliance для организации доступа в локальную сеть

Поддерживаемыми ОС для ВМ в пулах являются Windows 7, 10 Enterprise, Windows Server 2012 R2, 2016, 2019. WVD предоставляет возможность использовать Windows 10 Enterprise в режиме одновременного подключения нескольких пользователей (multisession), без ограничения их количества и необходимости использования лицензии RDS CAL. По сути вы получаете функционал терминального сервера, ранее доступный только на Windows Server, на базе Windows 10, поддерживающий современные приложения. Такую версию Windows 10, по лицензионному соглашению, можно запустить только в Azure.

При необходимости включения в образ дополнительного ПО это можно сделать несколькими способами:

1. Развернуть ВМ в Azure, кастомизировать, сделать образ и использовать его при развёртывании пула (детали процесса здесь)
2. Взять образ локальной ВМ и загрузить его в Azure (детали процесса здесь)
3. Рассмотреть применимость технологии MSIX app attach, которая позволяет подключать приложения без их установки

По опыту: заказчики устанавливали SAP и 1C клиенты, архиваторы, PDF просмотрщики, language pack. Настроить использование часового пояса можно вне процесса кастомизации образа через его редирекцию с использованием GPO.

Локальная часть

Интеграция с корпоративными приложениями и ресурсами «локального» ЦОД может осуществляться через site-to-site VPN, построенный на базе Azure VPN Gateway или Network Virtual Appliance (NVA). При развёртывании Azure VPN Gateway необходимо создать отдельную подсеть с зарезервированным названием GatewaySubnet с минимальным размером в /27. NVA развёртываются на базе ВМ, без определённых требований к наименованию подсети. В случае использования NVA, направить трафик на него возможно с помощью User Defined Routes.

NVA может как передавать весь трафик для фильтрации в локальном ЦОД, так и фильтровать его в облаке. При использовании Azure VPN GW установить ограничения трафика на L4 можно с помощью Network Security Group (NSG), которую необходимо применять на подсеть с ВМ, входящими в пул. При фильтрации трафика, стоит принять ко вниманию, что для корректного функционирования WVD пулу ВМ необходим доступ к списку URL. NSG позволяют предоставлять доступ к сервисам на базе Service Tags (коллекции IP адресов, которые относятся к каждому сервису). Фильтровать трафика в Azure на базе URL можно через NVA (в облаке или локальном ЦОДе) или через Azure Firewall. Для минимизации задержек рекомендуется использовать решение для фильтрации, расположенное в Azure.

При развёртывании VPN-решения стоит обратить внимание на его пропускную способность. При использовании NVA производительность определяется лицензией и сетевой картой выбранной вами ВМ. Для развёртывания Azure VPN GW используется SKU соответствующей производительности. Необходимо обратить внимание, что в дополнение к почасовой стоимости Azure VPN GW или ВМ для NVA также оплачивается исходящий из облака трафик.

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

Light: 75Kbps
Medium: 150Kbps
Heavy: 500Kbps
Power: 1000Kbps

Для точной оценки объёма используемого трафика его следует замерить на сетевом оборудовании или ПО, таком как бесплатная версия SysTrack Windows Virtual Desktop Assessment

Заключение

Удалённая работа стала реальностью почти для всех нас и вероятно может остаться такой на достаточно длительное время. Microsoft понимает это и делает создание и поддержание инфраструктуры для предоставления удалённых рабочих мест и приложений максимально простым и экономически доступным. Используя WVD для обеспечения удалённой работы вы сможете достигать большего быстрее.

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

Попробуй Azure бесплатно
Развертывание и масштабирование виртуализированных рабочих столов и приложений Windows в Azure

Об авторе

Роман Лазарев – Старший Архитектор Облачных Решений. Последние 4 года работаю в Microsoft в роли выделенного архитектора и доверенного советника  для крупнейших Российских компаний использующих облако Microsoft Azure. Linked In

Установим роли терминального сервера на Windows Server 2019 и лицензируем. Маленькая тонкость — сервер не в домене.

Подготовка Windows Server 2019

Для начала установим сам сервер. Всё необходимое вынесено в отдельную статью:

Установка Windows Server 2019 на виртуальную машину VMware

Не забываем про настройку:

Первоначальная настройка Windows Server 2019

Итак, операционная система установлена и настроена. Сервер в рабочей группе WORKGROUP.

Установка роли терминального сервера

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

Роль Remote Desktop Licensing

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation, но нам не удастся его использовать, поскольку сервер не в домене. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Services. Next.

Попадаем в раздел Features. Здесь ничего дополнительно не выбираем. Next.

Попадаем в раздел Remote Desktop Services. Ненужное нам окошко. Next.

Попадаем в раздел Role Services. Первая роль, которую нам нужно установить, это Remote Desktop Licensing. Выделяем галкой.

Нам предлагают установить дополнительные фичи, которые требуются для данной роли. Соглашаемся, Add Features.

Remote Desktop Licensing выделено галкой, Next.

Попадаем в раздел Confirmation. Install.

Начинается установка роли.

Роль Remote Desktop Licensing успешно установлена. Примечательно, что перезагрузка не требуется.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Manager.

Выбираем наш сервер, правой кнопкой — активировать.

Открывается окно активации. Next.

Выбираем метод соединения Web Browser. Next.

Получаем код продукта который нам понадобится для активации (Product ID). Копируем.

В браузере открываем сайт https://activate.microsoft.com/

Выбираем «Activate a license server». Next.

Вводим Product ID полученный ранее, организацию и любую страну или регион. Next. Next.

Если все сделано правильно, то мы получим необходимый код сервера лицензирования. Копируем его. На вопрос «Do you wish to install client access licenses now on the license server with this product ID?» отвечаем «Yes» и пока возвращаемся к терминальному серверу, к текущему окну ещё вернёмся.

Вводим код в открытом мастере, жмём Next.

Устанавливаем галку «Start Install Licenses Wizard now». Next.

Открывается мастер установки лицензий. Next.

Нас просят ввести license key pack ID. Возвращаемся к браузеру.

Вставляем License Server ID, в качестве программы лицензирования, по идее он уже должен сюда переместиться из предыдущего окна. License Program выбираем Enterprise agreement. Указываем компанию и страну. Next.

Выбираем тип продукта: Windows Server 2019 Remote Desktop Services Per Device client access license. Указываем количество лицензий. Обязательно соглашение Enterprise agreement, или ищем в интернете который подойдет…

Настройка и лицензирование терминального сервера Windows Server 2016

Не стоит выбирать лицензии Per User, иначе потом вы получите такую ошибку:

Next.

Ну вот мы и получили нужные нам клиентские лицензии. Копируем.

Вводим ключ в мастер. Next.

Finish.

Возвращаемся к Remote Desktop Licensing Manager. Сервер активирован. Лицензии получены. Кстати, они начнут тратиться после окончания триального периода.

Роль Remote Desktop Session Host

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Session Host.

Нам предлагают установить дополнительные фичи, соглашаемся. Add Features.

Роль Remote Desktop Session Host выделена. Next.

Попадаем в раздел Features, ничего не выделяем. Next.

Попадаем в раздел Confirmation. Ставим галку Restart the destination server automatically if required. Отображается предупреждение, что сервер может быть перезагружен. Yes.

Install.

Начинается процесс установки роли.

Сервер перезагружается.

В процессе устанавливаются компоненты.

После перезагрузки автоматически продолжается установка роли. Триальный период работы терминального сервера — 119 дней.

Роль Remote Desktop Session Host успешно установлена. Close.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Diagnoser.

Видим ошибку.

The licensing mode for Remote Desktop Session Host server is not configured.

Выполняем gpedit.msc.

gpedit.msc

Откроется Local Group Policy Editor.

Раскрываем Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing.

Редактируем Use the specified Remote Desktop license servers.

Включаем — Enabled. В поле «License server to use» прописываем сервер, с которого получать лицензии, в моём случае «localhost». OK.

Редактируем Set the Remote Desktop licensing mode.

Включаем — Enabled. В поле «Specify the licensing mode for the RD Session Host server» устанавливаем значение Per Device. OK.

Снова запускаем оснастку Remote Desktop Licensing Diagnoser. Теперь всё зелёное, ошибок нет.

Практические испытания

Поскольку мы с вами системные администраторы 99 уровня, то нам нужно провести практические испытания терминального сервера.

На терминальном сервере создаём трёх локальных пользователей: user1, user2, user3.

Включаем их в группу Remote Desktop Users.

Коннектимся под этими пользователями к терминальному серверу по RDP.

Есть три активных сеанса.

Заключение

Мы с вами успешно создали терминальный сервер Windows Server 2019 в рабочей группе WORKGROUP без домена. 120 дней терминальный сервер будет работать в триальном режиме, затем начнёт использовать лицензии Per Device. Для подключения к терминальному серверу требуется создать локальную учётную запись и включить её в группу Remote Desktop Users.

Windows Server 2019 предоставляет возможность создания и настройки терминального сервера, который позволяет пользователям удаленно подключаться к серверу и работать на нем. Терминальный сервер является важным инструментом для организаций, позволяющим эффективно управлять и распределять ресурсы, а также обеспечивать удаленный доступ для сотрудников.

Установка и настройка терминального сервера в Windows Server 2019 является достаточно простым процессом. Вам потребуется установочный диск с операционной системой или образ ISO, а также лицензионный ключ. После запуска установочного процесса необходимо выбрать режим установки «Только роли терминальных серверов» и следовать инструкциям мастера установки.

После завершения установки необходимо настроить терминальный сервер. Для этого вам потребуется перейти в «Управление сервером» и выбрать «Установка роли терминального сервера». Затем необходимо настроить доступ для пользователей, выбрать режим лицензирования и настроить другие параметры по желанию.

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

Что такое терминальный сервер Windows Server 2019

Терминальный сервер Windows Server 2019 – это роль сервера, которая позволяет пользователям подключаться к серверу и работать с ним удалённо. Он предоставляет виртуальные рабочие столы пользователям и позволяет им выполнять приложения и доступ к ресурсам сервера из любого устройства, обеспечивая гибкость и эффективность работы.

Терминальный сервер Windows Server 2019 поддерживает несколько режимов работы:

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

С помощью терминального сервера Windows Server 2019 можно создать гибкий и защищенный рабочий стол, который будет доступен из любого места и с любого устройства. Он позволяет организовать централизованное управление приложениями и данными, обеспечивая высокую производительность и безопасность.

Установка

Здесь будет описание шагов по установке терминального сервера Windows Server 2019:

1. Загрузите образ Windows Server 2019 с официального веб-сайта Microsoft.
2. Создайте загрузочную флешку или записывайте образ на DVD.
3. Вставьте загрузочный носитель в компьютер, на который будет устанавливаться сервер.
4. Запустите компьютер с загрузочного носителя.
5. На экране выбора языка и региональных настроек выберите нужные параметры и нажмите «Далее».
6. Нажмите кнопку «Установить сейчас».
7. Принимайте условия лицензионного соглашения и нажмите «Далее».
8. Выберите опцию «Пользовательская установка», чтобы выбрать тип установки.
9. Выберите жесткий диск, на котором будет установлен сервер, и нажмите «Далее».
10. Дождитесь завершения установки операционной системы на сервер.

После завершения установки операционной системы можно будет приступить к настройке и установке роли терминального сервера на Windows Server 2019.

Требования к аппаратному обеспечению

Для установки и настройки терминального сервера Windows Server 2019 необходимо обеспечить соответствие системы следующим требованиям к аппаратному обеспечению:

• Процессор: двухъядерный процессор с тактовой частотой 1,4 ГГц или больше
• Оперативная память: 4 ГБ или больше
• Свободное место на жестком диске: 32 ГБ или больше
• Видеокарта: с поддержкой DirectX 9 или выше
• Монитор: разрешение экрана от 1024×768 пикселей или выше
• Сетевой адаптер: Gigabit Ethernet с поддержкой IPv4 или IPv6

Также для эффективной работы терминального сервера рекомендуется следующее оборудование:

• Процессор: четырехъядерный процессор или выше
• Оперативная память: 8 ГБ или больше
• Свободное место на жестком диске: 64 ГБ или больше
• Видеокарта: с поддержкой DirectX 11 или выше
• Монитор: разрешение экрана от 1280×1024 пикселей или выше
• Сетевой адаптер: 10 Gigabit Ethernet с поддержкой IPv4 и IPv6

Учитывая требования к аппаратному обеспечению позволит гарантировать стабильную и производительную работу терминального сервера Windows Server 2019.

Установка операционной системы

Перед установкой операционной системы на терминальный сервер Windows Server 2019 необходимо проверить системные требования:

• Процессор: 1.4 ГГц 64-разрядный процессор
• Оперативная память: минимум 512 МБ (рекомендуется 2 ГБ)
• Свободное место на жестком диске: минимум 32 ГБ
• Графический адаптер: поддержка DirectX 9 или новее с драйвером WDDM 1.0

После проверки системных требований можно приступить к установке операционной системы:

1. Вставьте диск с установочным образом Windows Server 2019 в CD/DVD привод или подключите USB-накопитель с установочным образом.
2. Перезагрузите компьютер и настройте загрузку с CD/DVD привода или USB-накопителя.
3. На экране инсталлятора выберите язык установки, часовой пояс и раскладку клавиатуры.
4. Нажмите кнопку «Установить сейчас».
5. Примите лицензионное соглашение и нажмите кнопку «Далее».
6. Выберите тип установки: «Пользовательская: установка Windows только на определенные разделы» и выберите раздел для установки.
7. Нажмите кнопку «Далее» и дождитесь завершения процесса установки.
8. Настройте региональные и сетевые параметры операционной системы.
9. При необходимости, создайте учетную запись администратора.
10. После завершения установки системы может потребоваться перезагрузка компьютера.

После установки операционной системы можно приступить к установке и настройке терминального сервера Windows Server 2019.

Настройка

Когда вы установили терминальный сервер Windows Server 2019, вам необходимо выполнить определенные настройки, чтобы обеспечить его правильное функционирование. В этом разделе мы рассмотрим основные шаги по настройке терминального сервера.

1. Установка лицензий для доступа пользователей

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

1. Запустите центр администрирования удаленных служб (RD Licensing Manager).
2. Выберите тип лицензий, которые вы хотите установить (устройство или пользователь).
3. Введите информацию о лицензии и ключ лицензии.
4. Завершите процедуру установки лицензий.

2. Настройка групп пользователей

Чтобы управлять доступом пользователей к терминальному серверу, вы можете создать различные группы пользователей. Для настройки групп пользователей выполните следующие шаги:

1. Запустите центр администрирования удаленных служб (Remote Desktop Services Manager).
2. Выберите «Группы сеанса» в левой панели навигации.
3. Щелкните правой кнопкой мыши на пустом месте и выберите «Создать группу сеанса».
4. Введите название группы и добавьте нужных пользователей в эту группу.

3. Настройка прав доступа

Чтобы определить, какие действия пользователи могут выполнять на терминальном сервере, вы можете настроить права доступа. Для этого выполните следующие шаги:

1. Запустите центр администрирования удаленных служб (Group Policy Management).
2. Выберите групповую политику, которую вы хотите настроить.
3. Раскройте дерево настроек групповой политики и найдите раздел «Конфигурация компьютера» или «Конфигурация пользователя».
4. Выберите действие, которое вы хотите настроить (например, запретить доступ к определенным программам).
5. Установите нужные параметры и сохраните настройки.

С помощью этих основных шагов вы можете настроить терминальный сервер на Windows Server 2019 и подготовить его к использованию.

Настройка службы терминальных серверов

Служба терминальных серверов (Terminal Services) позволяет пользователям подключаться к удаленному рабочему столу на сервере и работать с ним так, как будто они находятся рядом с ним. В Windows Server 2019 настройка службы терминальных серверов выполняется следующим образом:

1. Установите роль «Службы терминальных серверов» на сервере Windows Server 2019. Для этого откройте «Управление сервером» и выберите «Добавить роли и компоненты». Пошаговый мастер установки поможет вам выполнить установку роли.
2. Настройте лицензирование терминальных серверов. Вы можете использовать лицензии RDS (Remote Desktop Services), чтобы управлять доступом пользователей к службе терминальных серверов. На сервере с установленной ролью «Службы терминальных серверов» выполните «Центр администрирования RDS» и выберите «Лицензирование RDS». Следуйте инструкциям для настройки необходимых лицензий.
3. Настройте параметры подключения к терминальным службам. Откройте «Центр администрирования RDS» и выберите «Определение ролей RDS». Настройте настройки сеансов и подключений в соответствии с требованиями вашей организации.
4. Настройте безопасность терминальных служб. Установите права доступа и настройте политики безопасности для пользователей, подключающихся к удаленному рабочему столу.
5. Настройте установленные приложения и ресурсы. Добавьте необходимые приложения и ресурсы, которые пользователи смогут использовать во время удаленного подключения к серверу.

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