Skip to content
Here is the first step in deploying Hyper-V VDI within Windows Server 2019. I’m hoping I can continue to do the setup with you guys. Next video, should be about configuring the gateway server in Windows Server 2019 to access the Hyper-V VDI environment.
#Microsoft #RemoteAccess #BTNHD
Don’t forget guys, if you like this video please “Like”, “Favorite”, and “Share” it with your friends to show your support – it really helps us out! If there’s something you’d like to see on the channel, tweet us about it! See you next time 🙂
********************************************************
The Music I Use: https://btnhd.com/BTNHDMUSIC
Stock Images & Video I use: https://btnhd.com/BNTHDVIDEONPHOTOS
BTNHD GitHub Repo – https://btnhd.com/BTNHDGitHub
Join Newsletter – https://btnhd.com/JoinBTNHDNewsLetter
Follow Me at Twitter: http://twitter.com/bjtechnews
Hang Out: https://www.periscope.tv/bjtechnews
Tech Site: http://bjtechnews.org
Twitch.tv: http://www.twitch.tv/t3chz3ro
Instagram: http://instagram.com/bjtechnews#
Facebook: http://facebook.com/bjtechnews
source
windows server
Alice AUSTIN
Alice AUSTIN is studying Cisco Systems Engineering. He has passion with both hardware and software and writes articles and reviews for many IT websites.
Установка и настройка удаленных рабочих столов на основе Microsoft VDI
Опубликовано:
Рабочие столы на основе DVI позволяют создать для каждого пользователя свое рабочее пространство с изолированными настройками. Подключение будет выполняться как на терминальный сервер, только попадать мы будем в изолированную виртуальную машину.
В данной инструкции будут приведены примеры развертывания и настройки роли удаленных рабочих столов на основе Windows Server 2012 R2.
Предварительная настройка инфраструктуры
Выполнение системных настроек
Настройка Active Directory
Подготовка организационных юнитов
Установка роли Hyper-V
Подготовка шаблона виртуальных машин
Развертывание и настройка роли удаленных рабочих столов на основе ВМ
Установка роли
Настройка развертывания
Создание коллекции
Проверка подключения с компьютера клиента
Дополнительная информация
Подготовка сервера
Для развертывания роли VDI необходимо, чтобы в нашей инфраструктуре были серверы со следующими ролями:
- Active Directory Domain Services (AD DS).
- 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.
Содержание
- Виртуализация: Развертывание VDI, основанной на сеансах
- Создание набора сеансов
- Предоставьте доступ пользователям и группам
- Публикация RemoteApp и рабочих столов
- Горизонтальное масштабирование
- Установка и настройка Free Windows Hyper-V Server 2019 (2016)
- Что нового в Hyper-V Server 2019?
- Установка Hyper-V Server 2019 / 2016
- Утилита Sconfig: базованя настройка Hyper-V Server 2019/2016
- Удаленное управление Hyper-V Server 2019/2016
- Использование PowerShell для настройки Hyper-V Server 2019
- Настройка параметров сети Hyper-V Server 2019 из PowerShell
- Настройка правил Advanced Firewall для управления Hyper-V Server 2019
- Создание дискового хранилища для виртуальных машин
- Настройка параметров хоста в Hyper-V Server 2016/2019
- Создание виртуального коммутатора Hyper-V
- Установка Windows Server 2016 Standart
- Где скачать?
- Подготовка к установке.
- Установка Windows Server 2016.
Виртуализация: Развертывание VDI, основанной на сеансах
Подход, используемый при создании инфраструктуры виртуальных рабочих столов Microsoft (VDI), основанной на сеансах, развертыванием Quick Start, — установка трех служб ролей Remote Desktop Services (RDS) на один сервер — отлично подходит для целей тестирования. Однако в реальной среде необходимо проектировать инфраструктуру, принимая во внимание доступность и возможное будущее расширение.
Значит, следует устанавливать службы ролей RDS (RD Session Host, RD Connection Broker и RD Web Access) на несколько серверов. Чтобы получить доступную инфраструктуру, допускающую расширение, можно взять за основу среду рабочих столов, основанную на сеансах, которая развернута в режиме VDI Standard. При развертывании инфраструктуры рабочих столов, основанной на сеансах, в режиме VDI Standard, выполняются следующие действия:
Чтобы начать процесс, добавьте все серверы, участвующие в развертывании, в Server Manager сервера, с которого выполняется развертывание. Откройте Server Manager на этом сервере и щелкните в Dashboard ссылку Add other servers to manage. В окне Add Servers щелкните Find Now, затем нажмите клавишу Control и щелкните каждый сервер-адресат, который нужно выбрать. Затем щелкните кнопку со стрелкой в центре экрана, чтобы переместить эти серверы в панель справа, и, наконец, щелкните OK (рис. 1).
.jpg)
Рис. 1. Выберите серверы, на которых будут выполняться службы, необходимые для работы вашей инфраструктуры
Запустите мастер развертывания, щелкнув ссылку Add Roles and Features в Server Manager Dashboard. Щелкните Next в окне Before You Begin. В следующем окне (рис. 2) выберите Remote Desktop Services installation. Затем щелкните Next.
.jpg)
Рис. 2. Чтобы создать инфраструктуру, основанную на сеансах, выберите RDS installation
В следующем окне выберите Standard deployment и щелкните Next. Затем выберите сценарий развертывания Session-based desktop deployment и снова щелкните Next (рис. 3). В следующем окне вы увидите службы ролей, которые будут установлены при развертывании. Если вас все устраивает, щелкните Next.
.jpg)
Рис. 3. Выберите сценарий развертывания в мастере Add Roles and Features
Итак, вы определили, какие серверы будут использоваться, и тип развертывания. Чтобы приступить собственно к развертыванию, начните с RD Connection Broker. Выберите один сервер из пула серверов, на который будет устанавливаться служба роли RD Connection Broker, выделив этот сервер в панели слева, и щелкните стрелку, чтобы переместить его в панель справа. Затем щелкните Next.
Мастер «предполагает», что вы можете установить RD Connection Broker более чем на один сервер, но это не так. Установка не выполнится, если вы выберете для этой роли более одного сервера. Так что выберите один сервер для RD Connection Broker (рис. 3).
В следующем окне выберите в пуле серверов сервер для RD Web Access. Переместите его в панель справа, затем щелкните Next. Затем выберите в пуле серверов (теперь можно выбрать более одного сервера) серверы, на которые вы установите службу роли RD Session Host. Переместите эти серверы в панель справа и щелкните Next (рис. 4).
.jpg)
Рис. 4. Укажите, на каких серверах будут выполняться ваши службы
В следующем окне предлагается подтвердить ваш выбор, а также сообщается, какие серверы потребуется перезагрузить после установки. Щелкните флажок Restart the destination server automatically if required и щелкните Deploy. Начнется процесс развертывания, и вы увидите ход его выполнения на каждом сервере. Если все пройдет успешно, вы увидите окно с сообщением об успешном выполнении развертывания.
Однако это еще не все. Службы ролей установлены, но после развертывания Standard потребуется еще несколько действий, необходимых для создания работоспособной среды:
Создание набора сеансов
Если вы откроете Remote Desktop Management Service (RDMS), то не увидите ни одного набора сеансов в Deployment Overview под значком RD Session Host или в разделе Collections. Поэтому необходимо создать такой набор.
В Windows Server 2012 можно публиковать RemoteApp или рабочие столы только для набора сеансов. Убедитесь, что у вас имеется хотя бы один сервер RD Session Host и что вы уже создали учетные записи пользователей домена (и группы пользователей), которым будете предоставлять приложения. Чтобы создать набор сеансов, откройте Server Manager на сервере, с которого вы выполняете развертывание. Щелкните категорию Remote Desktop Services в столбце слева, затем щелкните Collections. В области Collections щелкните раскрывающийся список Tasks и выберите Create Session Collection.
Можно также щелкнуть значок RD Session Host в окне Deployment Overview (рис. 5) и выбрать Create Session Collection. «Прощелкайте» окно Before you begin, чтобы вспомнить обязательные требования. Затем введите имя и описание набора сеансов в окне Name the Collection и щелкните Next. В окне Specify RD Session Host Servers выберите серверы RD Session Host, которые хотите добавить в набор, на панели Server Pool. Добавьте их в панель Selected, щелкнув кнопку со стрелкой, затем щелкните Next.
.jpg)
Рис. 5. Окно Deployment Overview дает общее представление о среде и позволяет выполнить ее настройку
Предоставьте доступ пользователям и группам
Итак, вы создали набор сеансов, теперь надо выбрать пользователей или группы пользователей домена, которым вы предоставите доступ. Группа Domain Users уже добавлена по умолчанию. Можно удалить эту группу, щелкнув ее и выбрав Remove. Щелкните кнопку Add, чтобы открыть диалоговое окно Select Users or Groups. Выберите соответствующих пользователей или группы и щелкните OK.
В следующем окне вам предоставляется возможность настроить User Profile Disks (диски профилей пользователей, UPDs). UPD — новая технология централизованного хранения параметров и данных профилей пользователей. Пока что снимите флажок «Enable user profile disks».
В окне подтверждения вы увидите сводку параметров, заданных вами в мастере. Просмотрите сводку и выберите Create. Когда в окне View Progress будет показано, что мастер завершил настройку, убедитесь, что у обеих операций статус Succeeded и щелкните Close.
Вы можете посмотреть только что созданный набор сеансов в RDMS в разделе Collections. Выберите набор сеансов в панели слева, чтобы посмотреть сведения о нем.
Чтобы протестировать развертывание полнофункциональных рабочих столов, откройте Internet Explorer и перейдите на URL развернутого сервера RD Web Access. Войдите под удостоверениями пользователя, которому разрешен доступ к этой инфраструктуре. Вы увидите значок полнофункционального соединения Remote Desktop. Щелкните значок, затем щелкните кнопку Connect в открывшемся окне, чтобы установить соединение Remote Desktop.
Публикация RemoteApp и рабочих столов
В RDMS в разделе Session Collection Properties в поле Resources по умолчанию указан ресурс Remote Desktop (Удаленный рабочий стол). При публикации RemoteApp «Remote Desktop» в этом поле заменяется на «RemoteApps». В Windows Server 2012 нельзя предоставить доступ и к RemoteApp, и к рабочим столам для одного и того же набора сеансов.
Чтобы опубликовать набор RemoteApp, щелкните ссылку Publish RemoteApp programs в центре раздела RemoteApp Programs. Можно также щелкнуть раскрывающееся меню Tasks и выбрать Publish RemoteApp Programs.
Мастер просканирует сервер и возвратит набор стандартных программ, размещенных на серверах RD Session Host. При публикации RemoteApp на ферме мастер будет сканировать программы для построения списка только на одном сервере. Модель RDS предполагает, что все серверы RD Session Host в наборе настроены одинаковы и на них установлены одни и те же приложения.
Щелкните флажки одной или нескольких программ, которые вы хотите опубликовать как RemoteApp, затем щелкните Next. Кроме того, можно добавить приложения, которых нет в стандартном списке, щелкая Add и выбирая программы, которые нужно опубликовать. Затем мастер покажет диалоговое окно подтверждения, содержащее выбранные вами RemoteApp. Щелкните Publish. Затем убедитесь, что все RemoteApp, показанные в окне Completion, имеют статус Published, и щелкните Close.
В основном экране RDMS для набора сеансов в разделе Properties в поле Resources будет указано RemoteApp Programs. В разделе RemoteApp Programs будут перечислены опубликованные RemoteApp. Тестирование RemoteApp во многом аналогично тестированию опубликованных рабочих столов. Откройте RD Web Access, чтобы начать работу с инфраструктурой. Затем войдите и щелкните один из значков RemoteApp. Щелкните Connect в открывшемся окне (рис. 6). Если приложение откроется, значит, оно успешно опубликовано.
.jpg)
Рис. 6. Если RemoteApp опубликовано, его можно запустить
Горизонтальное масштабирование
Результат развертывания Standard может показаться таким же, как и результат развертывания Quick Start. В обоих случаях становятся доступными рабочие столы или RemoteApp. Однако только при развертывании VDI Standard инфраструктура, основанная на сеансах, предоставляет возможность создать высокодоступную среду. Она позволяет с самого начала развернуть службы ролей RDS на нескольких серверах.
Чтобы расширить инфраструктуру, можно добавить дополнительные серверы RD Web Access и RD Session Host. Щелкните значок в панели RDMS Deployment Overview и выберите Add RD Web Access Servers или Add RD Session Host Servers. Выберите в Server Pool серверы, которые вы хотели бы добавить, переместите их в панель Selected и щелкните Next. В окне Confirmation щелкните Add. Если вы добавили сервер RD Session Host, потребуется перезагрузка, поэтому убедитесь, что на странице подтверждения установлен флажок Restart the Computer as Needed.
После завершения установки можно добавить только что созданные серверы RD Session Host в набор сеансов. Выберите набор сеансов в RDMS в разделе Collections. В разделе Host Servers откройте меню Tasks и выберите Add RD Session Host Servers. Выберите сервер в Server Pool, добавьте его в панель Selected, щелкнув кнопку со стрелкой, расположенную в центре, затем щелкните Add.
Теперь вы знаете, как развернуть VDI, основанную на сеансах, в режиме Standard и как опубликовать соединения с рабочими столами или с RemoteApp для этой инфраструктуры. В следующий раз мы расскажем о том, как осуществлять дальнейшую настройку и управление инфраструктурой, основанной на сеансах, с помощью RDMS.
Источник
Установка и настройка Free Windows Hyper-V Server 2019 (2016)
Windows Hyper-V Server — это бесплатная серверная версия гипервизора от Microsoft, которую можно использовать для запуска виртуальных машин. В этой статье мы рассмотрим, как установить и настроить актуальную версию Windows Hyper-V Server 2019, релиз которой состоялся летом 2019 года (инструкция также применима и к Windows Hyper-V Server 2016).
Hyper-V Server 2019 — подходит специально для тех, кто не хочет платить за систему аппаратной виртуализации. Никаких ограничений на процедуры и при этом он абсолютно бесплатный. К преимуществам Windows Hyper-V Server относятся:
Также нужно отметить, что использование бесплатного гипервизора не освобождает вас от обязанности лицензировать виртуальные машин. Вы можете запустить неограниченное количество ВМ с opensource ОС, типа Linux, но виртуальные машины с Windows придется лицензировать. Десктопные редакции Windows лицензируются с помощью ключа продукта, а вот если вы используете Windows Server в качестве гостевой ОС, его нужно лицензировать по физическим ядрам вашего хоста. Подробнее о лицензировании Windows Server при запуске в среде виртуализации смотрите здесь.
Что нового в Hyper-V Server 2019?
Вкратце пробежимся по объявленным новшествам в Hyper-V Server 2019:
Установка Hyper-V Server 2019 / 2016
Установка Microsoft Hyper-V Server стандартна и интуитивна. Все как в Windows 10. Просто загружаетесь ваш сервер (компьюер) с ISO образа и следуйте инструкциям мастера установки ОС.
Утилита Sconfig: базованя настройка Hyper-V Server 2019/2016
После установки система требует сменить пароль администратора. Меняете пароль и попадаете в консоль гипервизора.
Обратите внимание, что у Hyper-V Server нет привычного графического интерфейса Windows. Большинство настроек сервера придется выполнять через командную строку.
На рабочем столе два окна – стандартная командная строка и окно скрипта sconfig.cmd. С помощью данного скрипта можно выполнить первоначальную настройку сервера Hyper-V. В строку “Enter number to select an option:” введите номер пункта меню, с которым будете работать.
Дату, время и часовой пояс можно также настроить с помощью команды:
При этом открываются стандартные консоли.
Удаленное управление Hyper-V Server 2019/2016
Для удобного управления Free Hyper-V Server 2019 из графического интерфейса вы можете использовать:
Для работы с Hyper-V Server 2016/2019 вам потребуется ПК с операционной системой Windows 10 версий Pro или Enteprise х64.
Сервер Hyper-V должен быть доступен по своему сетевому имени, в доменной сети ему должна соответствовать A-запись на DNS-сервере. В одноранговой сети такую запись потребуется создать вручную на локальном DNS, либо добавить нужную запись в файл hosts клиентской машины, в нашем случае она выглядит следующим образом:
Если учетная запись, под которой вы работаете на клиентском ПК, отличается от учетных данных администратора Hyper-V, а так и должно быть, то следует явно сохранить учетные данные для соединений с сервером командой:
cmdkey /add: NAME-SERVERHV /user:Administrator /pass:MyPa$$word
Мы указали сетевой узел и учетные данные для подключения к нему. Если у вас не один сервер, то необходимо выполнить данное действие для каждого из них.
Теперь запустите консоль PowerShell от имени администратора и выполните следующую команду:
winrm quickconfig
Утвердительно отвечаете на все вопросы, при этом будет настроен автоматический запуск службы WinRM и созданы разрешающие правила в брандмауэре.
Добавьте Hyper-V сервер в доверенные узлы:
Если серверов несколько — добавьте в доверенные каждый из них.
Теперь попробуем подключиться к удаленному серверу. Запустите оснастку Управление компьютером и щелкнув правой кнопкой на верхнем уровне выберите Connect to another computer.
Теперь вы можете управлять планировщиком, дисками, службами, просматривать журнал событий, используя обычные mmc консоли.
Установите в Windows 10 Диспетчер Hyper-V. Откройте оснастку Programs and Features и перейдите в Turn Windows Features on or off. В открывшемся окне найдите пункт Hyper-V и отметьте для установки Hyper-V Management Tools.
Оснастка Hyper-V Manager будет установлена, запускаете ее и подключаетесь к вашему серверу.
Использование консоли Hyper-V Manager для управления гипервизором обычно не вызывает вопросов. Далее я рассмотрю некоторые способы управления Hyper-V Server сервером из PowerShell
Использование PowerShell для настройки Hyper-V Server 2019
Для настройки сервера рекомендую использовать PowerShell. В модуле ModuleHyper-V доступно более 1641 командлетов для управления сервером Hyper-V.
Get-Command –ModuleHyper-V | Measure-Object
Настройте автоматический запуск консоли PowerShell при входе в систему.
Теперь при входе в сеанс будет запускаться окно PowerShell.
Настройка параметров сети Hyper-V Server 2019 из PowerShell
Если вы не настраивали сетевые параметры в окне sconfig.cmd, то настройте их через PowerShell. С помощью командлета Get-NetIPConfiguration можно увидеть текущую конфигурацию IP сетевых интерфейсов.
Назначьте статический IP адрес, маску сети, шлюз по умолчанию и адреса DNS серверов. Индекс (InterfaceIndex) сетевого адаптера берем из вывода предыдущего командлета.
Для настройки IPV6 смотрим имя интерфейса командлетом Get-NetAdapter из PowerShell модуля управления сетью NetTCPIP:
Проверьте текущую настройку IPV6 следующей командой:
Отключить IPV6 можно так:
Настройка правил Advanced Firewall для управления Hyper-V Server 2019
Просмотреть список командлетов для управления файерволом Windows можно с помощью Get-Command.
Для полноценного удаленного управления сервером выполните последовательно следующие команды для включения разрешающих правил Windows Firewall из PoSh:
Создание дискового хранилища для виртуальных машин
Для хранения данных (файлов виртуальных машин и дистрибутивов) будем использовать отдельный раздел на физическом диске. Просмотрите список физических дисков на сервере.
Создайте новый раздел на диске максимально возможного размера и назначьте ему букву D. Используйте DiskNumber из Get-Disk.
После этого отформатируйте раздел в NTFS и укажите его метку.
Создайте каталог, где будете хранить настройки и файлы дисков виртуальных машин. Командлет New-Item позволяет создавать вложенные пути:
Создайте папку D:\Distrib для хранения дистрибутивов ОС:
Для создания шары используйте командлет New-SmbShare, с помощью которого дайте полный доступ по сети для группы локальных администраторов сервера:
Настройка параметров хоста в Hyper-V Server 2016/2019
Откроем параметры сервера командой:
Пути виртуальных машин и виртуальных дисков находятся на одном разделе с операционной системой, что неправильно. Пропишите путь к созданным ранее папкам с помощью команды:
Создание виртуального коммутатора Hyper-V
Создайте External Switch, который привязывается к сетевой карте Hyper-V Server и организует взаимодействие ВМ с физической сетью.
Проверьте поддержку SR-IOV (Single-Root Input/Output (I/O) Virtualization):
Получите список подсоединенных сетевых адаптеров:
Привяжите виртуальный свитч к сетевому адаптеру и при наличии SR-IOV включите его поддержку.
Проверить настройки виртуального коммутатора можно с помощью командлетов:
На этом первоначальная настройка Hyper-V Server 2016/2019 закончена. Можно переходить к созданию и настройке виртуальных машин.
Источник
Установка Windows Server 2016 Standart
В этой статье мы подробно рассмотрим установку Windows Server 2016 Standart с возможностями рабочего стола и без. Приступим!
Потраченное время: 20мин.
Где скачать?
Скачать Windows Server 2016 Standart Evalution можно по ссылке ниже.
Заполняем анкету, Ставим галочку в чекбоксе «Yes»(Условия конфиденциальности), и жмём «Continue». Никаких подтверждений требоваться не будет, так что это занимает очень мало времени.(Рис.2)
Выбираем свой язык, и жмём «Download».(Рис.3)
В результате скачается iso-образ, примерно с таким названием:
14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_RU-RU.iso
Объёмом: 6,52 Гб.
Подготовка к установке.
И так у нас скачан Windows Server 2016 в виде iso-образа.
Делаем загрузочную флешку средствами Rufus. Процесс создания загрузочной флешки, на примере Windows 10, можете посмотреть в этой статье: https://itdeer.ru/rufus/
Установка Windows Server 2016.
Подготовка запуска установщика.(Рис.4)
Выбираем язык, раскладку клавиатуры, формат времени и денежных единиц. У меня, по умолчанию, все для России. Жмём «Далее».(Рис.5)
Жмём «Установить»(Рис.6) и снова ждём. процесс «Начало установки«.
Так как версия у нас пробная, то окна «Активация Windows» у нас не было.(Рис.7) Но мы рассматриваем вариант того, что вы где-то в другом месте могли взять образ Windows Server 2016.
Тогда у вас будет два варианта:
Перед нами встал вопрос о выборе нужной нам операционной системы.
Мы посмотрим два варианта установки:
Теперь если скриншот один, значит это действие одинаковое для обоих версий.
Windows Server 2016 Standart
Windows Server 2016 Standart
(возможности рабочего стола)
Читаем, вникаем и принимаем условие лицензии, установив галочку в чекбоксе. Жмем «Далее».(Рис.10)
Предлагается выбрать один из двух типов установки(Рис.11):
Лично я всегда использую второй вариант, что и вам советую, потому что не верю, что система после обновления может хорошо работать и не тормозить. А если вам и нужны потом будут файлы, то позаботьтесь об этом заранее, сделав их резервную копию. (Скопировав на флешку, скинув их в облако и т.п.)
Выскакивает предупреждение о том, что для корректной работы, Windows может создать дополнительные разделы для системных файлов.(Рис.14) Жмем «Ок».
Вот и появились два раздела(Рис.15):
Пошёл процесс установки системы Windows, ждём пока пройдут все пункты(Рис.16)и компьютер перезагрузится. Все проходит без вмешательства пользователя.
Перезагрузка.(Рис.17) Если вы устанавливаете систему с загрузочной флешки и у вас в BIOS/UEFI выставлен приоритет загрузки этой флешки в первую очередь, то не забудьте вытащить ее во время перезагрузки, чтобы лишний раз не загрузиться с флешки.
Всё Ура! Это финиш. После ввода пароля нас приветствует рабочий стол Windows Server 2016 Standart.(Рис.25)
Зайдём в сведения о системе видим что написано:
Пробная версия у нас сама активировалась.
Что устанавливали, то и получили.
Источник
| Windows Server 2016 Standart | Windows Server 2016 Standart (возможности рабочего стола) |
Now It is possible to deploy Windows and Linux virtual desktops on Windows Server 2019 (Hyper-V) using UDS Enterprise. The developers of the VDI connection broker have been working since Microsoft launched the new version of its hypervisor to provide UDS with compatibility with this technology.
At the moment, UDS Enterprise supports Hyper-V 2019 in Standalone mode. This development allows IT admins who manage desktop virtualization platforms with this VDI broker to leverage the new features incorporated in the latest release of Windows Server, such as improvements in shielded virtual machines, persistent memory support for virtual machines and more efficient interoperability with hyperconvergence systems.
Hyper-V 2019 support will be one of the many new features that will be incorporated in the next release of UDS Enterprise , 3.0 . The development team has made an extra effort so that subscribers can now implement Hyper-V 2019 in their VDI infrastructures with UDS Enterprise 2.2.1. Only customers with an active VDI broker subscription can request it sending an email to [email protected]
Hyper-V support has been a constant since the first versions of UDS Enterprise. Until now, the VDI broker was compatible with Hyper-V 2012 and 2016, in both cases in Standalone mode.
The incorporation of support for Hyper-V 2019 is a further evidence of the commitment of the UDS Enterprise team to be at the forefront of the latest and leading technologies. Compatibility with the latest versions of the different virtualization platforms is one of the stable points in the roadmap of the VDI and vApp broker.
In addition to Microsoft Hyper-V, UDS Enterprise supports Citrix Hypervisor / XCP-ng, Nutanix AHV, RHEV / oVirt KVM, VMware vSphere, Microsoft Azure, VMware vCloud, OpenNebula / NodeWeaver, OpenStack and Microsoft RDS.
For more information on the management and deployment of VDI with UDS Enterprise on Microsoft Hyper-V see the following links:
-
UDS Enterprise & Microsoft Hyper-V Quick Steps Guide
-
Video: UDS Enterprise & Microsoft Hyper-V VDI
-
UDS Enterprise 2.2.1 Installation, Administration and User Guide (Page 28, 99)
Все переходим на «удалёнку»! Это стало главной задачей примерно 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 позволит вам принять правильные решения при планировании и развёртывания сервиса, а также выстроить корректные ожидания от его производительности.
Для обсуждения, давайте разобьём архитектуру на блоки:
- Клиенты
- Windows Virtual Desktop
- Ресурсы в подписке заказчика
- Корпоративная сеть (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-порту с инициацией со стороны ВМ. Таким образом из Интернет не предоставляется прямой доступ к ВМ и нет открытых в Интернет портов. Процесс открытия сессии выглядит следующим образом:
- Пользователь, через клиент Remote Desktop (RD), запрашивает токен в Azure AD. Он получает его после аутентификации и проверки в том числе с использованием MFA, Conditional Access и Intelligent Security Graph.
- Клиент предоставляет токен в Web Access и через Broker происходит обращение в СУБД Azure SQL DB для получения списка ресурсов (приложений и десктопов), к которым может подключаться пользователь.
- После выбора ресурса клиент RD подключается к Gateway.
- Брокер оркеструет подключение от Агента WVD к Gateway-ю.
- Трафик ходит от агента 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.
При необходимости включения в образ дополнительного ПО это можно сделать несколькими способами:
- Развернуть ВМ в Azure, кастомизировать, сделать образ и использовать его при развёртывании пула (детали процесса здесь)
- Взять образ локальной ВМ и загрузить его в Azure (детали процесса здесь)
- Рассмотреть применимость технологии 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