Виртуальные рабочие столы windows server 2016

Совсем недавно мы объявили о доступности Windows Server 2016 в облаке Azure Pack Infrastructure. Перед релизом в течение 4х месяцев мы и некоторые наши пользователи тестировали стабильность и надежность работы Windows Server 2016 Technical Preview в облаке и остались довольны результатом. Благодаря этому мы смогли предоставить релиз в кратчайшие сроки, позволяя нашим пользователям раньше других получать преимущества от наиболее современных технологий. По-традиции в облаке ОС предоставляется в редакции Datacenter и без дополнительной оплаты.

О первой теме часто спрашивают наши пользователи: как быстро организовать виртуальные рабочие места (VDI). Ранее на Windows Server нужно было настраивать контроллер домена и службы Remote Desktop Services, прежде чем приступить к работе в режиме терминального сервера (конечно был вариант и просто создать много пользователей в ОС, но возможности администрирования рабочих мест во время работы пользователей были очень ограниченными). AD используется далеко не везде, а необходимость быстро начать работу в виртуальном окружении возникает. Часто заказчики не обладают необходимыми знаниями для настройки VDI – хочется иметь простое решение из коробки.

В Windows Server 2016 появилась встроенная служба Multipoint Services, позволяющая удобно использовать виртуальные машины пользователям небольших организаций (а у больших и проблемы с развертыванием не возникает). Изначально Multipoint Services (Multipoint Server в прошлом) создавались для удобного разделения одного компьютера на много пользователей (когда организация не могла позволить себе приобретение отдельного компьютера для каждого), с подключением мониторов, клавиатур и мышек к единому компьютеру. При этом для каждого пользователя создавалось собственное независимое окружение.

Интерфейс управления Multipoint Services прост и понятен даже начинающим пользователям (с ним мы ознакомимся чуть ниже), поэтому мы сделали готовые шаблоны VDI Windows Server 2016 с предустановленными Multipoint Services на английском и русском. Также мы сделали вариант этиx шаблонов с предустановленным Microsoft Office 2016.

Получаем доступ в облако и создаем VDI

Если у вас еще нет доступа к облаку Azure Pack Infrastructure, заполните форму на главной странице https://infoboxcloud.ru указав, что хотите протестировать облако. Укажите желаемый объем ресурсов (количество vCPU, RAM и диска) и кратко опишите вашу задачу. Мы свяжемся с вами и предоставим пробную версию.

О том, как создать виртуальную машину с Windows Server 2016 и доступом в интернет ранее мы рассказывали в этой статье, сделайте все тоже, но выберите шаблон ОС для VDI.

Для вас доступны следующие шаблоны для VDI:

• WS2016 VDI EN — английская версия Windows Server 2016 Datacenter с предустановленными Multipoint Services без дополнительного ПО;
• WS2016 VDI RU — русская версия Windows Server 2016 Datacenter с предустановленными Multipoint Services без дополнительного ПО;
• WS2016 VDI with Office EN — английская версия Windows Server 2016 Datacenter с предустановленными Multipoint Services и предустановленным Microsoft Office 2016, работающим в режиме терминального сервера;
• WS2016 VDI with Office RU — русская версия Windows Server 2016 Datacenter с предустановленными Multipoint Services и предустановленным Microsoft Office 2016, работающим в режиме терминального сервера;

Создайте сервер из подходящего для вас шаблона. В этой статье мы будем использовать WS2016 VDI with Office RU.

Для подключения к серверу используйте RDP–клиент, который входит в состав Windows, устанавливается для macOS из AppStore (beta–версия с новыми функциями доступна тут), для Linux можно использовать Reminna, для Android и iOS также доступен Microsoft Remote Desktop.

Для подключения к русской версии шаблона используйте логин Администратор, к английской – Administrator.

Возможности MultiPoint Services

После подключения к VDI серверу вы можете найти инструменты управления Multipoint Services в меню «Пуск»:

• Multipoint Manager помогает администраторам управлять рабочими местами и заниматься мониторингом;
• Multipoint Dashboard предоставляет функциональность, полезную для ежедневного администрирования.

Multipoint Manager

После запуска Multipoint Manager мы видим общую информацию и нашем сервере.

В настоящий момент на сервер не установлено лицензий клиентского доступа (RDS). Данные лицензии необходимы для каждого пользователя, работающего с виртуальным рабочим местом. Их можно не покупать, а взять в аренду у нас (450 руб/мес), написав тикет нашей команде поддержки из панели управления услугами. После заказа мы поможем установить и активировать лицензии. Первые 119 дней VDI будет работать и без установки лицензий RDS, что позволяет настроить и протестировать сервер до заказа.

Серверов VDI бывает больше одного, из единого интерфейса можно управлять всеми. Нажав «Добавить или удалить серверы Multipoint Server» вы можете добавить и другие серверы из вашей сети (находятся автоматически, но при необходимости возможность удаленного управления можно отключить).

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

Полезная возможность — «Включить защиту диска» для сервера VDI. Это позволяет использовать VDI в режиме киоска и сбрасывать содержимое диска при каждой перезагрузке.

В разделе «Станции» можно провести выход пользователей из рабочих станций, что бывает полезно если сервер используется в режиме киоска — таким образом сбросятся данные сеансов. Если режим киоска не используется — это просто возможность разлогинить пользователей.

Также можно воспользоваться определением станций. Включив этот пункт на каждом из компьютеров пользователей возникнет его идентификационный номер и можно найти нужный. Например пришли в компанию, занимающуюся обучением, вам говорят «Пройдите к компьютеру A».

В разделе «Пользователи» вы видите всех пользователей всех станций и можно просто управлять пользователями и давать нужные права, либо изменять данные для доступа, все из одного места в удобном интерфейсе.

Multipoint Manager может быть полезен и в случае использования сценария гибридного облака, ведь объединив сеть Azure Pack Infrastructure и корпоративную сеть по Site-To-Site VPN из Multipoint Manager можно управлять и рабочими станциями в периметре компании, расширяя возможности за счет виртуальных рабочих мест.

Multipoint Dashboard

Утилита для ежедневного администрирования. Вы видите список всех экранов всех сессий на всех станциях и экраны подключенных рабочих мест.

Что можно делать:

• Блокировать и разблокировать рабочие столы (при необходимости отображая сообщение на экране).
• Устанавливать ограничения на просмотр сайтов — черные и белые списки.
• Запрещать или разрешать USB (полезно если из Multipoint управляются и физические рабочие места).
• Возможность спроецировать свой рабочий стол на нужные сессии (или на все) пользователей и что-то показать.
• Возможность запустить или закрыть программу на выбранных рабочих столах или на всех.
• Возможность переписываться с пользователями.

  

• и конечно Возможность взять управление сессией пользователя и все починить.

В разделе «Системы» можно перезагружать и выключать рабочие станции, на которых работают пользователи.

Настольный Microsoft Office и сервисы Office 365

В шаблонах VDI с предустановленным Microsoft Office уже настроен Microsoft Office 2016, корректно работающий и активирующийся в режиме терминального сервера. Это означает, что как только мы добавим пользователя в Multipoint Manager, он подключится к своей учетной записи — сможет использовать последнюю версию Microsoft Office на нужном языке. При первом входе ПО спросит данные для доступа к подписке Office 365 (нужное количество подписок можно заказать у нас не дороже чем напрямую в Microsoft, но с экспертной поддержкой — настроим все от начала и до конца, подключим или подарим домен, ответим на все вопросы в процессе работы).

Заключение

В нашем облаке вы можете всего за 10 минут создать не только нужное количество VDI на самой современной операционной системе Windows Server 2016, но и получить реально простой и удобный интерфейс управления физическими и виртуальными рабочими местами, а при необходимости и с предустановленным Microsoft Office по подписке. Не тратьте время на настройки, думайте о решении своих задач!

Для получения бесплатной пробной версии пожалуйста заполните форму на infoboxcloud.ru.

Успешной работы!

Установка и настройка удаленных рабочих столов на основе 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:windowssystem32sysprepsysprep.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.

This is the last piece of  the puzzle in our RDS series.  In this part we will discuss why or when to implement this insted of RDS Session Host environment. VDI stands for Virtual Desktop Infrastructure and it is built around the Windows Client OS while RDS is built around the Windows Server OS. When you configure VDI you are creating a pool of VMs and each user will get it’s own VM. This flexibility provides an isolated environment for the user. As each user enjoys a dedicated VM with an OS, they can install or uninstall applications with full or partial administration rights within the VM. When you configure RDS Session Host, all users will share that server and non of them will be able to make changes, install applications, make it personal. All of that is possible with VDI, specially if you have users that need to run heavy applications.

Some of the questions that we need to answer before deploying VDI are:

• Storage
• Servers
• Network
• What type of desktops we want to deploy?

1. Storage – Storage is a KEY item and usually what KILLS VDI. It is the biggest performance bottleneck in a virtual infrastructure. So this needs to be planned carefully especially if you will run persistent VDI.

Local vs Shared Storage

Big question. Do I run it on a local storage or do I run it on some form of shared storage?

Local -> If you’re using local storage, there are two scenarios you want to target, a pooled VDI and RD session host. RD session host is a single server. You can back it up. You can restore it. You can have farms of it. If it’s pooled VDI, the desktops are funds mentally replaceable. Because when the user logs off it reverts. So you can destroy and recreate desktops without having a real significant impact so having local direct attach storage is a viable option for that.

Shared -> Personal VDI, user profile disks, pooled VDI templates. All of these include clustering, CSV or SMB attached storage.

1. Servers – On how many hosts will you run these VMs on? A single one? What if it dies? Everything dies as well. When we are configuring VDIs a Hyper-V cluster is preferred.
2. Network – Another important piece in our deployment. Latency, redundancy, scalability are just some of the parts we need to plan before pulling the trigger on a VDI rollout.
3. Desktop Types – here we need to decide if we are going to implement Persistent-VDI or Non-Persistent VDI.

Persistent VDI – It is a 1:1 mapping which means that if you have 50 users you MUST have 50 VMs running. Every user get it’s own VDI. Each desktop runs from a separate disk image. The user’s settings are saved and appear each time at login. These types of desktops allow more personalization, each desktop may be as unique as you want, but they require more storage and backup. Persistent VDI is basically the same setup we have with our physical laptops. Persistent VDI is popular in static scenarios where individual end users are always the same and use the same workstations. They are coordinated with WSUS and Config manager to avoid patch storms through excessive disk I/O.

Non-Persistent VDI – In this deployment none of the users settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he/she logs in. With this deployment if you know you usually get only 20 users connected at any given time you can have a pool of 20 VMs instead of 50. This means less servers, less storage and so on.

When you are deploying non-persistent VDI’s you are creating a “Master Image” or a “Golden Image”. Since nonpersistent desktops are built from a master image, it’s easier for administrators to patch and update the image, back it up quickly and deploy company-wide applications to all end users. Users can’t alter desktop settings or install their own applications. Requirements are reduced because we have only one image to manage and we have support for user profile disks to persist user changes. When it comes to updating the golden image, if there’s an update that comes in, update the gold, reconstruct, update the gold, reconstruct. You do this as often as you want, and the tools within Windows make this completely transparent to the user because Server Manager
will allow you to roll these things out as people use them.

TIPS! I would recommend that (before you configure VDI deployment) you make sure that you focus on user profiles (you may not necessarily be on this same Windows install over and over again) and follow that by applications and then you can start talking about, okay, we’re going to give you a user session and a desktop, do I do that in a session desktop, do I do that in a personal VDI or a pooled VDI. Those are the first things you need to solve before you configure virtualization layer, storage etc.

Let’s see how we can deploy VDI’s. In a production environment, you will need to have a physical Hyper-V host (Cluster is preferred) that will host RD Virtualization Host role. My Hyper-V host is a VM (with nested virtualization enabled). No need for physical server because this is just a demo. All servers are domain joined.

Infrastructure

DC01 – Domain Controller

RDS-VDI – Connection Broker, Web Access

HV01-VDI – Hyper-V host (RD Virtualization Host) – 20 GB RAM, 10 vCPU

I already created new organizational unit called VDI. This will be the default OU which will host our VDI’s. Next, I have configured DHCP so that VDI’s get correct network settings. Make sure that you have this before you proceed.

Be sure to add all servers that will be part of the deployment to all servers in server manager on connection broker. Lets, start our deployment by starting server manager and clicking on Manage –> Add Roles and Features -> Remote Desktop Services Installation

Select Standard Deployment –> Next

On the Deployment Scenario select Virtual machine-based desktop deployment

Specify Connection Broker, Web Access and RD Virtualization Host servers. When you select RD Virtualization Host you will have the option to create a new virtual switch. Check this if you want to allow the wizard to create a new virtual switch within Hyper-V to be used for our virtual desktops.

And on the confirmation page tick Restart the destination server automatically if required and click on Deploy

First part is done.

Before we proceed and create a golden template and collection let’s jump into server manager and edit our RDS deployment.

You will notice 2 new sections. Active Directory and Export Location. On the Active Directory section we are configuring permissions so that our connection broker can join VDI’s do a domain. Broker will require full control. As I posted before I already created new OU called VDI. When you select your OU you will receive an error.

To fix this you can hit apply. In some cases if you are not using account that has the permissions to configure this you will need to click on generate script and run the script with account that has the permissions. If you use account that has required permissions, when you click on Apply, you will see the message like this.

Next we have Export Location. The export location is a global setting that applies to all collections in the deployment. When you create a managed collection (a collection that is based off of a gold image is a managed collection) , we have to export the gold image to this location and store it using the collection name. This is where your gold image will live for the lifetime of the collection, and it is not updated until you either re-create all desktops or delete that collection and create a new one, where we will export the gold image again (a gold image can only be used for one collection). Once done click OK

Our next step is to create a golden template. I will use Windows 10 Enterprise iso file and create a template with some applications on it. Now when you are done create a checkpoint before running sysprep. Doing this will give you option to revert to point before sysprep.

Once done run sysprep with command

%WINDIR%system32sysprepsysprep.exe /generalize /shutdown /oobe

Now we are ready to create a collection.

On the Before you begin page click Next. On the Collection Name page specify the collection name and click next

On the Collection Type page choose what would you like to create. We already discussed about these options and if you feel unsecure about it please go back to the beginning of this post. I will keep the defaults and click next. (You will notice green checkmark which represent capabilities of the collection. If you click on Personal, those will change)

Now we need to select our Template. I have only one. Click next

On the Virtual Desktop Settings page keep the defaults and click next

Now we need to specify Time Zone, domain and the OU that we would like to use. Once done click next

On the Specify users and groups page you can specify which group will have access to VDIs, how many we would like to create and what prefix we would like to use.

I created a group called VDI_Users and I am going to create 2 VDI’s. Next for naming scheme I chose to use WIN10-1 for the first one.

On virtual desktop allocation page we can specify how many VDI’s will be created on specific host. I have only one Hyper-V host so there is not much to choose but if you have more then 1 you can select how many VDI’s are going to be created on each host

On this page we are deciding where are we going to store VDI’s. In my case that will be on a D: drive on the Hyper-v host. You will notice a checkbox Automatically roll back the virtual desktop when user logs off. We are creating a Pooled VDI collection so this is a good option. Keep it as is and click next

Now on this page I will uncheck User Profile Disks because I don’t care about user settings in my demo. Remember that if you want to save user settings in a pooled VDI collection you will need to have this.

On the Confirmation Page click Create

After a couple of minutes our collection is deployed with our VMs.

If we login to our DC we will see that VDI OU is populated with these 2 VMs and we can see those VMs in Hyper-V manager as well.

and we can see it in RD Web Access

Let’s explore the collection properties. Click on the collection and under Tasks click on Edit Properties.

General Section, Here we can change the Collection Name, we can decide if this collection will appear in Web access and we can enable save delay in minutes.

Enable save delay (in minutes): If you enable this option, when the user logoff the machine will rollback and after x min it will go into the save state.

Virtual Desktops Section, This will give us information about our configuration

User Groups section, here you edit who will be able to access collection.

Client Section, Here we can configure/change settings for clients and decide if they will be able to access drives, clipboard etc.

User Profile Disks –> UPD’s can be configured here

On the Collection main page we have option to configure Remote Apps

and if you scroll down you will see Virtual Desktop Template section. This will tell us which golden image we are using and some additional info. We will discuss more about this when we will be talking about golden image update and re-creation of VDI’s.

Last but not least is the Virtual Desktops section. Here we can see our VDI’s, who is logged on and the connection status. We can see that a user called N is logged on WIN10-2 and that connection is Active. If you click on tasks you will be able to add more desktops, recreate all desktops (later on this one) etc..

If you right click on a VDI you will be able to do things like save and delete.

UPDATE GOLDEN IMAGE AND RECREATE ALL DESKTOPS

What if we need to add new applications to our VDI’s in pooled collection? What if we need to change something or what if we need to update our golden template? These are the steps that we need to go through when updating/modifying our golden template.

If you remember I created a checkpoint before running sysprep. I did that to revert back to a normal state before I ran sysprep. So our first step is to revert back to normal state.

If you get a warning message Are you sure you want to apply the selected checkpoint hit YES. Once done start the template VM and install apps, update it or make changes to it. I will install some apps on it and then we need to run sysprep again. Before running sysprep I will create a new checkpoint. When new updates are available I will revert to this point and update the image.

Once done run sysprep with shutdown, oobe and generalize options.

%WINDIR%system32sysprepsysprep.exe /generalize /shutdown /oobe

Our VM is sysprepped and ready to be deployed. Login to Connection Broker and start the server manager. Click on RDMS and click on the collection. Under the Virtual Desktop section click on TASKS and Recreate All Virtual Desktops.

First step is to select the template. Once done, click next

User Logoff Policy section, here we have 2 options. The first option

• When the user logs off from the virtual dsktop: this will re-create all desktops with no user. If there are users that are logged on the re-creation will begin when they log off. We have time frame as well that we can use to force re-creation of the desktops regardless if the user is logged in or not. If there are any users logged in between the dates we choose they will be logged off and re-creation will start.

Second option

Based on a schedule: 

• Recreate virtual desktops now and log off all users -> this will force recreation immediatelly regardless of user activity.
• Recreate virtual desktops now and log off users at a specified time –> here we can choose specific time to start with the re-creation.

I will choose Recreate virtual desktops now and log off all users, once done click next and click CREATE.

Process of exporting the template will begin. Once done all desktops will be re-created. During this period all VMs will be deleted and then recreated.

If we connect to our Hyper-V host we can see the process. I am connected to one of my VM’s as well.

Re-creation will first delete the VM and then re-create it.

Now if I try to connect again we will see that the VM is going through the sysprep process.

Once done the VM’s will first be in a saved state and then they will boot up and users will be able to connect to them.

That’s it. I hope this has been informative for you.

Stay Tuned!

Cheers,

Nedim

Эта большая инструкция посвящена особенностям установки, настройки и эксплуатации фермы терминальных серверов на базе роли Remote Desktop Services (RDS) в Windows Server. Статья поможет вам развернуть службы удаленных столов на Windows Server 2022, 2019 и 2016 в домене Active Directory.

Компоненты Remote Desktop Services в Windows Server 2022/2016/2016/2012R2

В состав роли RDS в Windows Server входя следующие компоненты:

• Remote Desktop Session Host (RDSH) – узлы сеансов RDS. Основные рабочие лошадки фермы RDS, на которых работают приложения пользователей;
• Remote Desktop Connection Broker (RDCB) – посредник RDS подключений. Используется для управления фермой RDS, распределения нагрузки, обеспечивает переподключение пользователей к своим сеансам, хранит коллекции RDS и опубликованные приложения RemoteApps;
• Remote Desktop Gateway (RDGW) – обеспечивает безопасный доступ к сервисам RDS из Интернета;
• RD Web Access (RDWA) – веб интерфейс для доступа к рабочим столам, программам RemoteApp;
• Remote Desktop Licensing (RD Licensing) — служба лицензирования, управляет RDS лицензиями (CAL) пользователей.

В нашем небольшом стенде будут всего три сервера со следующим распределением ролей

• msk-rds1.winitpro.ru
  — RDSH
• msk-rds2.winitpro.ru
  – RDSH
• msk-rdsman.winitpro.ru
  – RDSH, RDWA, RDCB, RD License

Предварительные требования, которые нужно выполнить перед созданием RDS фермы:

1. Установите одинаковую версию Windows Server на все сервера, настроить их, и добавить в один домен AD;
2. Откройте консоль ADUC (
   dsa.msc
   ) и переместите все хосты с ролью RDSH в одну OU в AD. Так будет удобнее применять единые настройки через GPO;
3. Создайте в домене группу для RDSH серверов (например,
   msk-rdsh
   ) и добавьте в нее все хосты;
4. Если вы хотите использовать диски User Profile Disk (UPD) для хранения профилей пользователей RDS (или перемещаемые профили), нужно создать на файловом сервере сетевой каталог, в котором они будут хранится (желательно расположить этот каталог на отказоустойчивом файловом кластере Windows Server). Предоставьте права Full Control на этот сетевой каталог для группы
   msk-rdsh
   .

Создаем новую конфигурацию Remote Desktop Services в Windows Server

Рассмотрим, как создать и настроить RDS конфигурацию с помощью графического интерфейса Server Manager.

Откройте Server Manager и добавьте все планируемые RDS сервера в консоль. Щелкните All Server -> Add servers.

Теперь в меню Server Manager выберите Add Roles and Features -> Remote Desktop Services installation -> Standard deployment –> Session-based deployment.

Режим Quick Start используется для развертывания всех компонентов RDS на одном сервере. В RDS ферме минимум может быть один сервер, который совмещает все роли RDS (RD Session Host, RD Web Access и RD Connection broker). Но такая конфигурация не обеспечивает отказоустойчивость и балансировку нагрузки в службах удаленных рабочей столов Windows Server.

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

• RD Connection Broker –
  msk-rdsman
• RD Web Access —
  msk-rdsman
• RD Session hosts —
  msk-rdsman, msk-rds1, msk-rds2

Вы можете распределить RDS роли по серверам в любой другой конфигурации.

Поставьте галку Restart destination server automatically if required и нажмите кнопку Deploy. Дождитесь установки ролей RDS на всех серверах.

Итак, ваша ферма RDS создана.

Следующий этап установка и настройка сервера лицензирования RDS. Вы можете установить роль RD Licensing на один из серверов в вашей ферме или использовать существующий в домене сервер лицензирования RDS. Подробная инструкция по установке, настройке и активации роли RD Licensing доступа по ссылке.

Для управления вашим развертыванием RDS нужно перейти в раздел Server Manager -> Remote Desktop Services. На вкладке Overview показана текущая конфигурация RDS фермы.

Чтобы изменить настройки RDS фермы выберите Tasks -> Edit Deployment Properties в разделе Deployment Overview.

Здесь можно изменить:

• Параметры RD Gateway;
• Адрес сервер сервера лицензирования и тип пользовательских лицензий RDS CAL (per user/per device);
• Посмотреть URL адреса RD Web Access;
• Добавить SSL сертификаты для служб RDS (в инструкции мы пропустим этот пункт).

Для построения отказоустойчивой фермы Remote Desktop Services нужно обеспечить высокую доступность роли RD Connection Broker. Это достигается за счет запуска нескольких экземпляров RDCB (Active/Active) на разных серверах с общей базой данных SQL, в которой хранится конфигурация брокера подключений. Для обеспечения высокой доступности SQL базы RDCB ее можно размесить в группе высокой доступности SQL Server Always On. Ранее мы публиковали подробный гайд по настройке RDS Connection Broker с высокой доступностью.

Создаем коллекции Remote Desktop Services в Windows Server

Следующий этап настройки – создание коллекций сеансов RDS. Коллекции Remote Desktop позволяют разделить хосты в ферме RDSH на отдельные группы или создать разный набор настроек и доступных приложений Remote App для разных групп пользователей.

Перейдите в раздел Collections, выберите Edit -> Create Session Collection.

Здесь нужно задать:

1. Имя коллекции RDS:
   rds-Msk-Managers
2. Выберите какие хосты RDSH будут обслуживать пользователей коллекции (один RDSH хост может находиться в одной коллекций; не рекомендуется объединять в одну коллекцию сервера с разными версиями Windows Server);
3. На вкладке User Groups указываются группы пользователей, которым разрешено подключаться к коллекции. Уберите из групп Domain users и добавьте вашу группу (msk-Managers);
4. На вкладке User Profile Disk нужно указать, хотите ли вы использовать формат UPD для хранения профилей пользователей (Enable user profile disks). В поле Location of user profile disks укажите UNC путь к сетевому каталогу(например,
   \msk-fs01mskrds_upd
   ), в котором будут хранится профили пользователей в форматер UPD виртуальных дисков (в этом случае при входе на любой сервер коллекции RDS, пользователь будет всегда загружать свой профиль) и максимальный размер диска (20 Гб по умолчанию);
5. Нажмите Create чтобы создать новую RDS коллекцию;
6. Убедитесь, что в указанном каталоге создался UPD файл с шаблоном профиля пользователя UVHD-template.vhdx.

Чтобы задать параметры коллекции RDS, выберите ее и нажмите Tasks -> Edit Properties.

Здесь можно изменить базовые параметры коллекции (имя, описание, группы доступа) и ряд других важных настроек.

В разделе Session можно задать параметры переподключения/ автоматического отключения простаивающих RDP сессий (подробнее рассматривалось в статье Настройка таймаутов для RDP сессий).

На вкладке Security можно выбрать настройки безопасности (Negotiate, RDP Security level или SSL/TLS) и шифрования (Low, High, Client compatible или FIPS compliant) для сессий RDP. Здесь также можно включить/отключить Network Level Authentication для RDP.

В секции Load Balancing можно изменить веса (
Relative Weight
) RDSH хостов в вашей ферме. Если характеристики серверов (RAM, CPU) в коллекции сильно отличаются, нужно задать меньший вес для менее производительных серверов. В этом случае RDCB будет распределять сессии пользователей по серверам в зависимости от их веса.

На вкладке Client Settings можно указать, какие устройства пользователям разрешено пробрасывать в RDP сессию. Например, вы можете разрешить/запретить пробрасывать с локального компьютера пользователя в RDS сеанс принтера, сетевые диски, аудио устройства, буфер обмена.

В разделе User Profile Disks можно более тонко настроить параметры UPD профилей пользователей. Можно исключить из синхронизации определенные папки или файлы. Это позволит уменьшить размер профиля UPD в сетевом каталоге и увеличить скорость загрузки профиля (не забывайте, что он загружается по сети из сетевой папки при входе пользователя).

Настройка и эксплуатация UPD обычно гораздо проще, чем использование перемещаемых профилей или folder redirection. Один UPD профиль не может использоваться в разных коллекциях RDS.

Для уменьшения размера UPD диска пользователя можно использовать стандартный PowerShell командлет
Resize-VHD
, используемый для изменения размеров виртуальных VHDX дисков Hyper-V.

В секции HOST SERVERS коллекции RDS можно перевести любой сервер фермы в режим обслуживания RDSH (Drain Mode). Для этого щелкните по нему и выберите Do not allow new connection. В результате Connection Broker не будет отправлять новые подключения пользователей на этот сервер. В таком режиме вы можете спокойно установить обновления Windows или обновлять на сервере приложения, не затрагивая пользователей.

Здесь же можно добавить/удалить RDS Host из коллекции.

Если RDSH хост вышел из строя и не доступен, его можно корректно удалить из фермы Remote Desktop Services по этой инструкции.

Публикация RemoteApp в Remote Desktop Services

RemoteApps – это опубликованные для пользователей приложения на RDS серверах. Благодаря RemoteApp можно использовать приложения, установленные на терминальном RDSH сервере так, как будто оно запущено непосредственно на компьютере пользователя. Пользователь не видит всего рабочего стола Windows Server RDS и работает только с теми программами, которые опубликовал для него администратор. На компьютере пользователя будет отображаться только окно запущенной на RDS программы.

Если вы не создаете RemoteApp, пользователи будут работать непосредственно на собственных рабочих столах на Windows Server. Поэтому не забудьте скопировать все необходимые пользователю ярлыки приложений в папку C:UsersPublicDesktop. Файлы из этой папки будут отображаться на рабочем столе всех пользователей. Если вы устанавливаете на RDSH пакет MS Office 365, обратите внимание что Office нужно разворачивать в режиме SharedComputerLicensing.

RemoteApp приложения создаются в настройках коллекций RDS. Выберите пункт Tasks -> Publish RemoteApp Programs в секции REMOTEAPP PROGRAMS.

Windows отобразит все приложения, установленные на текущем сервере. Можете выбрать одно из них. Если вашего приложения нет в списке, но оно установлено на других хостах RDS, нажмите кнопку Add и укажите полный путь к исполняемому файлу приложения (exe, bat, cmd и т.д.).

Опубликуйте приложение RemoteApp.

Затем в настройках RemoteApp можно указать дополнительные параметры приложения.

• Нужно ли показывать опубликованное RemoteApp приложение в веб интерфейсе RD Web Access;
• Задать параметры запуска (аргументы) приложения (Command-line Parameters -> Always use the following command-line parameters);
• На вкладке User Assignment можно дополнительно ограничить каким группам пользователей разрешено запускать приложение.

Если вы хотите изменить иконку опубликованного RemoteApp, нужно открыть следующую папку на сервере с ролью RDS Connection Broker:

C:WindowsRemotePackagesCPubFarmsrds-Msk-ManagersCPubRemoteApps

Замените иконку приложения другим ico файлом.

Теперь пользователь может запустить RemoteApp приложение из RD Web Access (
https://msk-rdsman.wintpro.ru/RDWeb
) или с помощью специального RDP файла.

Для запуска опубликованного приложения RemoteApp, нужно добавить в RDP файл такие строки:

remoteapplicationmode:i:1
remoteapplicationname:s:putty
remoteapplicationprogram:s:"C:Toolsputty.exe"
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe

Несколько полезных мелочей для удобной эксплуатации фермы RDS:

• Для роли RDWeb можно настроить поддержку HTML5, это позволит пользователям подключаться к RDS серверам из любого браузера и ОС даже без клиента RDP;
• На веб сервере RD Web Access можно опубликовать ссылку на смену истекшего пароля пользователя (по умолчанию при включенном NLA вы не сможете аутентифицироваться на RDSH с истекшим паролем пользователя Active Directory);
• Инструкция для пользователей по смене пароля в RDP сессии;
• Администратор может использовать теневые подключения RD Session Shadow для подключения/просмотра рабочего стола сеанса пользователя на сервере RDS;
• Чтобы быстро найти, на каких RDS серверах есть сессии определенного пользователя, можно использовать PowerShell:
  Import-Module RemoteDesktop
Get-RDUserSession -ConnectionBroker msk-rdsman.winitpro.ru | where {$_.UserName -eq "a.ivanov"} | Select HostServer
• Вы можете использовать PowerShell скрипты для просмотра и анализа логов RDP подключений пользователей к серверам RDS;
• Для дополнительной защиты можно настроить двухфакторную аутентификацию (2FA) пользователей на RDS серверах Windows с помощью сторонних средств.

Настройка фермы Remote Desktop services с помощью PowerShell

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

Следующие PowerShell команды для создания RDS фермы лучше запускать с другого на другом сервера, т.к. управляемые RDS хосты придется перезагружать.

Задайте имена серверов в вашей ферме RDS. В этом примере я установлю роли RDCB и RDS Licensing на отдельный сервер (в дальнейшем рекомендуется настроить отказоустойчивую конфигурацию RDCB).

$RDSH1 = "msk-rds1.winitpro.ru"
$RDSH2 = "msk-rds2.winitpro.ru"
$RDSCB = "msk-rdcb.winitpro.ru"
$RDSGW = "msk-rdsgw.winitpro.ru"
Import-Module RemoteDesktop

Установите RDS роли на сервера:

Add-WindowsFeature –ComputerName $RDSH1, $RDSH2 -Name RDS-RD-Server –IncludeManagementTools
Add-WindowsFeature –ComputerName $RDSCB -Name RDS-Connection-Broker -IncludeManagementTools
Add-WindowsFeature –ComputerName $RDSGW -Name RDS-Web-Access, RDS-Gateway –IncludeManagementTools

Перезагрузите все хосты:

Restart-Computer -ComputerName $RDSH1,$RDSH2,$RDSCB,$RDSGW

Создайте новый инстанс RDSessionDeployment:

New-RDSessionDeployment -ConnectionBroker $RDSCB -SessionHost $RDSH1,$RDSH2 –Verbose

Добавить в ферму сервера RDWA и RDGW:

Add-RDServer -Server $RDSGW -Role RDS-WEB-ACCESS -ConnectionBroker $RDSCB
Add-RDServer -Server $RDSGW -Role RDS-GATEWAY -ConnectionBroker $RDSCB -GatewayExternalFqdn "rds.winitpro.ru"

Текущее распределение RDS ролей по серверам фермы можно вывести так:

Get-RDServer -ConnectionBroker $RDSGW

Установка роли лицензирования RDS:

Add-WindowsFeature –ComputerName $RDSCB -Name RDS-Licensing, RDS-Licensing-UI

Задайте режим лицензирования PerUser:

Invoke-Command -ComputerName $RDSCB -ScriptBlock {Set-RDLicenseConfiguration -Mode PerUser -LicenseServer $RDSCB -ConnectionBroker $RDSCB}

Add-RDServer -Server $RDSCB -Role RDS-LICENSING -ConnectionBroker $RDSCB

Добавить сервер лицензирования в доменную группу с помощью Add-ADGroupMember:

Add-ADGroupMember "Terminal Server License Servers" -Members "msk-rdcb$"

Если у вас есть сертификат для RDS можно его добавить в конфигурацию фермы (можно использовать бесплатный SSL сертификат Let’s Encrypt для вашего RDS хоста):

Path = "C:psRDSCert.pfx"
$Password = ConvertTo-SecureString -String "CertPAssddr0w11-" -AsPlainText -Force
Set-RDCertificate -Role RDGateway -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDWebAccess -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDPublishing -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDRedirector -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force

Информацию об установленных SSL сертификатах можно получить так:

Get-RDCertificate

Теперь можно создать коллекции RDS:

$CollectionName = "DEVdept"
New-RDSessionCollection –CollectionName $CollectionName –SessionHost $RDSH1,$RDSH2 –ConnectionBroker $RDSCB –CollectionDescription “Develovers”

Разрешить доступ к RDS серверам для групп:

$UserGroup [email protected]("WINITPROmsk-developers","WINITPROmsk_devops")
Set-RDSessionCollectionConfiguration -CollectionName $CollectionName -UserGroup $UserGroup

Опубликовать приложение RemoteAPP:

New-RDRemoteapp -Alias GoogleChrome -DisplayName GoogleChrome -FilePath "C:Program Files (x86)GoogleChromeApplicationchrome.exe" -ShowInWebAccess 1 -CollectionName $CollectionName -ConnectionBroker $RDSCB

В статье мы рассмотрели, как установить и настроить ферму Remote Desktop Services на базе Windows Server 2019/2022 с помощью графического интерфейса Server Manager и с помощью PowerShell. За рамками статьи осталось более подробное описание ролей RD Web Access и RD Gateway. Мы рассмотрим настройку этих ролей отдельно в следующих статьях.

Установим роли терминального сервера на Windows Server 2016 и лицензируем.

1. Подготовка Windows Server 2016.
2. Установка роли терминального сервера.
3. Лицензирование терминального сервера.

Ссылки

ESXi 6.7 — установка Windows Server 2016 на виртуальную машину

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

Сервер разворачиваю на базе виртуальной машины VMware. Устанавливаем ОС:

Ссылка на инструкцию по установке ОС приведена выше. ОС установлена.

Не забываем установить VMware Tools.

Тип сетевухи E1000E нежелателен.

Меняем его на VMXNET 3.

Активируем Windows Server 2016.

Устанавливаем обновления.

Моя конфигурация:

• 8 Гб ОЗУ
• 2 CPU

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

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

Before You Begin пропускаем. Next.

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

Deployment Type. Для одного сервера, выбираем Quick Start. Next.

Deployment Scenario. Наши пользователи будут подключаться к серверу (собственным сессиям на сервере), а не к собственным виртуальным машинам. Выбираем Session-based desktop deployment. Next.

Server Selection. Выбираем текущий сервер. Next.

На наш сервер будут добавлены следующие серверные роли:

• RD Connection Broker — контроль подключений пользователей, определяет для какого пользователя на каком сервере будет открыта сессия или запущено приложение.
• Web Access — доступ к приложениям через веб браузер.
• RD session Host — сервер, на котором будут опубликованы приложения и на который пользователи смогут подключаться через удаленный рабочий стол.

Позже мы добавим на сервер ещё одну роль:

• RD Licensing — сервер лицензий.

Установим галку, чтобы сервер при необходимости перезагружался. Deploy.

Начинается автоматическая установка ролей. Сервер перезагружается.

Даже какие-то обновления подтянулись.

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

Первые три роли установлены. Close.

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

По умолчанию в группе все доменные пользователи.

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

Перезагружаемся и переходим к лицензированию.

Лицензирование терминального сервера

Устанавливаем RD Licensing сервис, нажав на зелёный плюсик.

Следуем инструкциям, сложностей не должно быть.

Выбираем текущий сервер, Next.

Add.

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

Установка роли RD Licensing успешно завершена. На всякий случай перезагружаю сервер.

Запускаем Диспетчер лицензирования удалённых рабочих столов (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 2016 Remote Desktop Services Per User client access license. Указываем количество лицензий. Обязательно соглашение Enterprise agreement, один из данных номеров ищем в Интернете… Next.

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

Копируем ключ и вводим его в мастер. Next.

Finish.

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

Сервер не является членом группы терминальных серверов в Active Directory. Нажмём Add to Grоup.

Continue.

Сервер добавлен в группу терминальных серверов в Active Directory.

OK.

Сервер лицензий позеленел, на первый взгляд всё в порядке.

Запускаем 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.

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

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

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

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

Перезагружаем сервер. Запускаем Remote Desktop Licensing Diagnoser.

Ошибок нет.

Признаюсь, уже давно хотел написать статью о RemoteApp для 1С, да все, как и всегда времени «в обрез», а на почту по прежнему приходят письма, с которых можно сделать один вывод,  что о RemoteApp, знают по прежнему не многие, а те, что знают, знают мало.

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Собственно так я и решил поступить!

================
И так, что такое это «RemoteApp» (удаленное приложение) ?

Кусок из статьи на сайте Microsoft (Для объективности):

RemoteApp позволяет представлять приложения, доступ к которым может быть получен удаленно через Службы удаленных рабочих столов (RDS), как если бы они были запущены на локальном компьютере пользователя. Эти приложения называются программы RemoteApp. Вместо представления на рабочем столе сервера. Узел сеансов удаленных рабочих столов программа RemoteApp интегрируется с рабочим столом клиента и программа RemoteApp запускается в собственном окне, размеры которого можно менять, может перемещаться между несколькими мониторами, а также имеет собственный значок на панели задач. Если пользователь запускает несколько программ RemoteApp на одном сервере Узел сеансов удаленных рабочих столов, эти программы RemoteApp совместно используют один сеанс Службы удаленных рабочих столов (RDS).

А простыми словами пользователь работает в 1С, так словно 1с-ка выполняется на его ПК.

Если подробно, то на самом деле1С  работает удаленно на нашем сервере, и он (наш сервер) передает пользователю лишь  картинку происходящего у него. При этом передается картинка только самого приложения, ничего лишнего! И  с этой картинкой пользователь взаимодействует думая, что это программа.

Одним словом «Дым и зеркала» )

Отсюда и такое впечатление у пользователя, как будто бы 1С Предприятие действительно работает у него на ПК.

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

«RemoteApp» слово не новое, еще на windows server 2008 R2 можно было публиковать удаленные приложения, но тогда все было «сыровато», и лишь с выходом windows server 2012  «RemoteApp»  можно использовать для работы в 1С.

О старом добром «сервере терминалов» знают многие, официальное название «Terminal Services» или «TS».

Но на смену этой технологии пришла новая  — RDS  (Remote Desktop Services) именно эту технологию сейчас активно продвигает компания  Microsoft и на ней мы будем публиковать наши «RemoteApp».

Конечно, ели разворачивать «RemoteApp» на основе сеансов, тогда здесь многое будет вам знакомо, так как все  базируется на старом протоколе RDP,для подключения клиента используется уже давно известный нам клиент mstsc, и как и прежде все работает в сеансах которые как и на «Сервере терминалов» создают и работают пользователи.

Администрирование происходит аналогично, как и на «TS», да и лицензируется аналогично, вот только лицензии уже называются не «Windows Terminal Services» а «Windows Remote Desktop Services CAL».

Многих пользователей сбивают, столку эти нововведения, (особенно «старая школа») собственно попытаюсь в этой статье рассказать подробно, как и о RDS, так и о RemoteApp, на котором это работает, постараюсь  все разложить, как говорится «по полочкам».

Что же такое RDS?

RDS позволяет нам централизованно управлять ресурсами, контролировано предоставлять приложения и данные для пользователей.

В RDS есть две возможных реализации.

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

2  – технология на базе виртуальных рабочих столов, то есть по технологии VDI.

Собственно (Удаленные приложения) «RemoteApp»  мы будем разворачивать на основе сеансов, по первому типу. Его реализовать проще, и подходит он большинству.

Также стоит отметить, что реализация второго типа на базе VDI имеет свои преимущества.

При использовании VDI – каждый пользователь работает на своей виртуальной машине.

И если, например, случилась какая-то беда у пользователя на его вирт. машине то пострадает лишь его виртуальное пространство. А если это случится на сервере «на основе сеансов»  по первому типу, тогда могут пострадать все пользователи, чьи сеансы там находятся, да и все программы, данные на этом сервере.

Из чего состоит RDS

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

Основные роли RDS

1.       Посредник подключения к удаленному рабочему столу. Он занимается подключением клиентского устройства к удаленным приложениям «RemoteApp», а также рабочим столам на базе сеансов, либо к виртуальным рабочим столам, зависит от того на базе какой технологии мы RDS построили.

2.       Роль, которая обеспечивает веб-доступ к удаленным рабочим столам. Ее задача – предоставление ресурсов через веб-браузер.

3.       Узел сеансов удаленных рабочих столов – данная роль позволяет размещать на сервере удаленные приложения, или основанные на сеансах рабочие столы.

4.       Узел виртуализации удаленных рабочих столов. На данном узле, это у нас сервер Hyper-V, на котором у нас разворачиваются все виртуальные машины, доступ к которым получат все пользователи, что использую технологию VDI.

5.       Шлюз удаленных рабочих столов, это посредник между клиентами из внешней сети и коллекции сеансов во внутренней сети и приложений. Шлюз – это безопасность, сервис у нас абсолютно безопасный. И благодаря тому, что RDS в 2012 и 2012R2 становится более гибким, проработаны абсолютно все недочеты, которые были раньше. Сейчас этот сервис легко реализуем для огромных, масштабных проектов, для больших корпораций. Раньше возникали некоторые вопросы.

Так что же нового ?

Обновленная работа с технологией RomoteFX, то есть в RDS сервере 2012, 2012R2, 2016 обновлена работа с графикой. У нас оптимизирована потоковая передача данных, кроме того осуществляется поддержка DirectX 11. Кому этот аспект важен — это все уже работает. Как мы знаем именно эти вещи были негативными отзывами по предыдущим версиям системы.

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

Как мы знаем, Windows сервер 2012, 2012R2, 2016 прекрасно работает с протоколом SMB 3.0. RDS сервера точно так же это коснулось, и мы можем осуществлять хранение дисков для хранения данных пользователей на протоколах SMB и RGCDSun. Кроме того, так как эта технология реализована в server 2012, 2012R2, 2016 данный сервис легко управляем. То есть в менеджере у нас есть закладка, мы с вами рассматривали когда-то, благодаря которой, управление сервером RDS становится интуитивно понятным, впрочем, как и все инструменты, реализованные в Windows Server 2012-2016.

Что нужно для реализации RDS?

1.       Windows server 2012 – 2016 Standard или Datacenter.

2.       Лицензии Call для пользователей, + лицензии RDS + лицензия Windows serv.

3.       Статический IP + внешний статический, если требуется удаленный доступ.

4.       Обязательно Active Directory.

Из необязательного:

5.       SSL сертификат.

6.       Доменное имя  2-3 уровня.

7.       CA — Certification authority.

Преимущества «RemoteApp» над обычным «Сервером терминалов» :

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>