Развертывание vdi на windows 2020 r2 server: Дешево и сердито / Хабр

Что такое терминальная ферма RDS

Добрый день! Уважаемые читатели и гости крупного IT блога Pyatilistnik.org. В прошлый раз я вам как увидеть скрытые папки в Windows 10. Сегодня мы поговорим, про одну очень важную вещь в IT инфраструктуре почти любой организации, речь пойдет про общие понятия терминальной фермы RDS (Remote Desktop Services). Мы узнаем из каких компонентов она состоит, какие сценарии развертывания есть у данной технологии, как она помогает улучшить работу сотрудников и уменьшить административную нагрузку на системного администратора или инженера. Это будет вводная статья, перед развертывание высокодоступной RDS фермы на Windows Server 2019.

Желания бизнеса и системного администратора

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

• Есть помещение в котором работают сотрудники, у каждого свой стационарный компьютер и пользователи зачастую жестко привязаны к своему рабочему месту
• За счет не очень производительной сети и небольших дисковых объемов на серверах, пользователи вынуждены хранить все свои рабочие и персональные данные локально на компьютере
• С выходом из строя рабочей станции сотрудника, он начинает бездельничать и системному администратору нужно вытащить его рабочие данные, если они есть и перенести их на другой компьютер, все это отнимает много времени, а если инженер один, то может и еще дольше, все зависит от приоритетов
• В результате простоя работы пользователя бизнес начинает терять деньги

Исходя из этих тезисов, многие компании по разработке оборудования, программ и операционных систем, продолжали разработку модели при которой бизнес бы смог минимизировать время простоя при аварии и тем самым сделать сервисы лучше, надежнее и минимизировать нагрузку на системного инженера. Одним из таких шагов сделала компания Microsoft, выпустив службу «Удаленных рабочих столов (Служба терминалов, Терминальный стол или Remote Desktop Services)». Данная разработка решала ряд важных вещей:

• Все рабочие процессы. такие как 1С, директум, смета, контур, СРМ системы и многое другое, запускались уже не локально на компьютере сотрудника, а выполнялись на удаленном, мощном сервере, раньше это были исключительно железные сервера, но со временем и развитием гипервизоров, например VMware ESXI 6.5, удаленные столы стали выступать в роли виртуальных машин, которые уже не привязывались к конкретным физических хостам, тем самым еще увеличивая надежность сервиса и уменьшения времени простоя.
• За счет централизованного хранения рабочих профилей на одном или нескольких серверов терминальной фермы, системному администратору стало проще создавать резервные копии данных, особенно если это виртуальные машины, их стало легко восстанавливать, например с помощью Veeam Backup
• Если у пользователя ломался компьютер, то он мог легко пересесть на любое другое рабочее место, подключиться к своей терминальной ферме Windos и продолжить свою работу с того же места. Тоже самое можно отметить, что когда сотрудник уходит домой, он легко может подключиться к терминальному серверу по защищенному VPN и так же продолжить свою работу.
• Появилась возможность профили пользователей делать перемещаемые и хранить их на отдельных выделенных дисках. Или можно подключать ISCSI диски и там хранить профили
• Многие сотрудники могут переходить на удаленку, тем самым экономя свое время на дороге на работу, работать из любой точки мира. За счет этого бизнес может экономить деньги на аренде помещения, арендуя меньшее пространство. Экономится расход электроэнергии. Экономия по канцелярским вещам, на оборудовании и многое другое.
• Удобно, что все эти сервера вы можете заказать в облаке, например все в том же vCloud Director
• Системному администратору проще обслуживать ряд серверов, чем сотни компьютеров. Даже с точки зрения безопасности, проще централизовано на серверах установить все обновления, программ, обновлений безопасности Windows, чем делать это на сотне компьютеров. Там конечно то же нужно делать, но это не первоочередная задача
• Удобно на терминальные фермы подключать любые USB ключи, для этого есть специализированное оборудование по типу SEH или DIGI, а так же программные решения, уже не нужно держать у бухгалтера ключик в ее компьютере и бояться, что если компьютер сломается, то всем несдобровать

Компоненты терминальной RDS фермы

Перед тем, как я вам приведу примеры внедрения технологии Remote Desktop Services в реальной жизни, я бы хотел вас познакомить с компонентами, которые входят в состав. Если вы откроете у себя Windows Server 2019 или другую версию по ниже, то в списке ролей вы сможете найти:

• Веб-доступ к удаленным рабочим столам  (RD Web Access (RDWA)) — предоставляет пользователям настраиваемый веб-портал для доступа к рабочим столам на основе сеансов, виртуальным рабочим столам и программам RemoteApp. Для начала пользователь получит доступ к веб-странице RDS, указав URL-адрес, по которому публикуются ресурсы RDS. Благодаря этой технологии пользователи могут работать и запускать программы на удаленном рабочем столе из своего телефона или планшета прямо из браузера.
• Лицензирование удаленных рабочих столов (RD Licensing) — управление клиентскими лицензиями на доступ к службам удаленных рабочих столов, которые требуются для подключения каждого устройства или пользователя к рабочим столам на основе сеансов.
• Посредник подключений к удаленным рабочим столам (RD Connection Broker (RDCB)) — предоставляет пользователям единое, персонализированное и агрегированное представление программ RemoteApp, рабочих столов на основе сеансов и виртуальных рабочих столов. RD Connection Broker поддерживает балансировку нагрузки и повторное подключение к существующим сеансам на виртуальных рабочих столах, рабочих столах на основе сеансов и программах RemoteApp. Без посредника подключений RDCB вы не сможете подключиться к своим коллекциям серверов
• Узел виртуализации удаленных рабочих столов (RD Virtualization Host (RDVH)) — RD Virtualization Host интегрируется с Hyper-V для предоставления виртуальных машин, которые можно использовать в качестве личных виртуальных рабочих столов или пулов виртуальных рабочих столов.
• Узел сеансов удаленных рабочих столов (RD Session Host (RDSH)) — размещает программы на базе Windows или полный рабочий стол Windows для клиентов служб удаленных рабочих столов. Пользователи могут подключаться к серверу узла сеансов удаленных рабочих столов для запуска программ, сохранения файлов и использования сетевых ресурсов на этом сервере. Именно хосты с данной ролью являются конечными целевыми серверами, где работают пользователи, именно на них создается то единое рабочее окружение, которое видит сотрудник.
• Шлюз удаленных рабочих столов (RD Gateway (RDG)) — позволяет совместимым устройствам безопасно подключаться через Интернет к серверам RD Session Host или серверам RD Virtualization Host за корпоративным брандмауэром. RDG должен быть размещен на границе корпоративной сети, чтобы отфильтровать входящие запросы RDS, ссылаясь на критерии, определенные на назначенном сервере политики сети (NPS). Имея сертификат сервера, RDG предлагает безопасный удаленный доступ к инфраструктуре RDS. По сути это альтернативная технология, если у вас в организации не используется VPN сервер для подключения к корпоративной сети.

Типы развертывания RDS фермы в Windows Server

Существует несколько типов установки терминальной фермы на серверах Windows:

• Стандартное развертывание (STANDARD) — Это лучший способ развертывания, и вы должны выбрать этот тип развертывания в производственной среде. 3 основные роли Connection Broker, RDWeb и RDSH будут развернуты на 3 разных серверах или в любой другой комбинации. При выборе Коллекции в стандартном развертывании удаленные приложения и конфигурацию необходимо будет настроить вручную. Вся установка, настройка и управление развертыванием сеанса RDS должны выполняться через посредник подключений.
• Быстрый запуск (QUICK START) — это второй вариант развертывания RDS, аналогичный стандартному, но при выборе быстрого запуска все компоненты будут развернуты на 1 сервере. Быстрый старт — это быстрый путь для запуска RDS за считанные минуты. Коллекция и удаленное приложение будут автоматически настроены. Этот тип развертывания не рекомендуется для использования в производственной среде, но если вы настраиваете RDS для лаборатории или небольшой среды, тогда установка «все в одном» сэкономит ваши аппаратные ресурсы.

•  Служба Multipoint (MULTIPOINT SERVICES) — это новый вариант развертывания в RDS 2016 в Windows Server 2019 уже данного вида развертывания нет. MPS изначально был создан для использования в ​​учебных заведениях. Пользовательские станции могут состоять только из монитора, клавиатуры, мыши (тонкие клиенты) и могут быть подключены к MPS через USB-концентраторы, видеокабели или через локальную сеть. Ттонкие клиенты MPS использует некоторые службы RDS (по умолчанию): узел сеансов удаленных рабочих столов и сервер лицензирования удаленных рабочих столов.

В Windows Server 2019 вы найдете только компонент «Соединитель Multipiont»

Служба Multipoint как вы поняли по лицензии доступна только для учебных и государственных учреждений, ее основная задача с помощью тонких клиентов, это такие компьютеры без оперативной памяти, жесткого диска, чаще всего без вентиляторов, подключить человека к удаленному серверу, ресурсы которого будут использоваться. На рисунке к серверу подключаются напрямую четыре клиента по USB и, к примеру, VGA-порты. Очевидно, что подобный тип подключения подразумевает соответствующие требования к аппаратной конфигурации головной станции и в некоторых сценариях не применим (масштабы, расстояние, мобильность)

А вот еще пример подключения тонких клиентов через USB хаб и через COM-порт.

Сценарии развертывания RDS фермы

Так же есть несколько сценариев развертывания:

• Развертывание рабочих столов на основе виртуальных машин — Это разворачивание Hyper-V и VDI.  VDI расшифровывается как инфраструктура виртуальных рабочих столов и построен на основе клиентской ОС Windows, а RDS — на ОС Windows Server. Когда вы настраиваете VDI, вы создаете пул виртуальных машин, и каждый пользователь получает свою собственную виртуальную машину. Эта гибкость обеспечивает изолированную среду для пользователя. Поскольку у каждого пользователя есть выделенная виртуальная машина с операционной системой, он может устанавливать или удалять приложения с полными или частичными правами администрирования внутри виртуальной машины. При настройке RDS Session Host все пользователи будут использовать этот сервер совместно, и ни один из них не сможет вносить изменения, устанавливать приложения, делать его личным. Все это возможно с VDI, особенно если у вас есть пользователи, которым нужно запускать тяжелые приложения.
• Развертывание рабочих столов на основе сеансов — Это чаще используемый сценарий, так сказать классический, когда при разворачивании Remote Desktop Services вы создаете из серверов коллекции, к которым подключаются пользователи, по сути, это просто удаленная сессия на сервер.
• Персональные рабочие столы сеансов (Personal Session Desktops) — Этот параметр позволяет назначать персональные рабочие столы конечным пользователям на основе Windows Server 2016 в гостевой виртуальной машине вместо клиентской ОС Windows. Мы можем создать новый тип коллекции сеансов, где каждому пользователю назначается собственный персональный узел сеанса с правами администратора. Данный тип сценария подходит хостинг провайдерам или сервис провайдерам, напомню, что в классическом VDI по SPLA недоступно использование Windows 7, 8.1, 10. Чтобы это обойти и срубить деньжат компания Microsoft придумала PSD (Personal Session Desktops). В Windows Server 2016 решили это дело упростить и добавить метод привязки пользователей к конкретным терминальным узлам (в рамках RDS это узлы Remote Desktop Session Host, RDSH). В итоге получаем новый вид RDS-коллекции — Personal Session Desktops (PSD), или частные рабочие столы на базе терминальных сессий. Очевидно, что можно провести аналогию с Personal Virtual Desktops в VDI, предназначенными так же для выделения «изолированной» среды пользователям.

Примеры внедрения:

1. Сотруднику нужно, чтобы RDCH хост имел интерфейс клиентской Windows 10, раньше ставился компонент Desktop Experience, но он распространялся на всех, а вот PSD, это персонально.
2. Если пользователь имеет административные полномочия на своем привычном ПК и вы хотите перевести его на PSD, то это возможно сделать путем добавления пользователя в группу локальных администраторов (определяется на этапе развертывания PSD, «ручной труд» не требуется)
3. Если пользователь не видит свою дальнейшую жизнь без графических приложений, требующих дополнительных аппаратных ресурсов, то можно предоставить PSD с обновленными возможностями RemoteFX (об этом уже упоминалось выше).

Хочу отметить, что сценарий «Персональные рабочие столы сеансов (Personal Session Desktops)» пока не имеет графического интерфейса настройки и это можно сделать, только через PowerShell

Практические примеры внедрения терминальной фермы

Теперь я хочу вам показать, как можно внедрять RDS фермы в ваше рабочее окружение:

• Самый правильный вариант, это создание Remote Desktop Services Connection Broker HA (Служб удаленных рабочих столов в режиме высокой доступности), тут у вас два посредника подключений в режиме High Availability, один или более серверов RDSH и RD Web, а так же сервер с базой данных в режиме AlwaysOn

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

• Классический вариант, когда RDCH, RD Web, RDCB установлены на одном сервере.
• RD WED HA в рамках Remote Desktop Services Connection Broker HA (Служб удаленных рабочих столов в режиме высокой доступности)
• Remote Desktop Gateway в рамках Remote Desktop Services Connection Broker HA (Служб удаленных рабочих столов в режиме высокой доступности)

Развертывание среды удаленного рабочего стола

• 
  04/10/2017
• Чтение занимает 5 мин
• 
  
  

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016

Выполните следующие действия для развертывания серверов удаленных рабочих столов в своей среде.Use the following steps to deploy the Remote Desktop servers in your environment. Роли сервера можно установить на физические компьютеры или виртуальные машины, в зависимости от того, создаете вы локальную, облачную или гибридную среду.You can install the server roles on physical machines or virtual machines, depending on whether you are creating an on-premises, cloud-based, or hybrid environment.

Если вы используете виртуальные машины для серверов служб удаленных рабочих столов, убедитесь, что вы подготовили эти виртуальные машины.If you are using virtual machines for any of the Remote Desktop Services servers, make sure you have prepared those virtual machines.

1. Добавьте все серверы, которые вы собираетесь использовать для служб удаленных рабочих столов, в диспетчер серверов:Add all the servers you’re going to use for Remote Desktop Services to Server Manager:

   1. Запустите диспетчер сервера, щелкните Управление > Добавление серверов.In Server Manager, click Manage > Add Servers.
   2. Щелкните Find Now(Найти).Click Find Now.
   3. Щелкните каждый сервер в развертывании (например, Contoso-Cb1, Contoso WebGw1 и Contoso Sh2) и нажмите кнопку ОК.Click each server in the deployment (for example, Contoso-Cb1, Contoso-WebGw1, and Contoso-Sh2) and click OK.

2. Создайте развертывание на основе сеансов для развертывания компонентов служб удаленных рабочих столов:Create a session-based deployment to deploy the Remote Desktop Services components:

   1. В диспетчере сервера щелкните ссылку Управление > Добавить роли и компоненты.In Server Manager, click Manage > Add Roles and Features.
   2. Выберите пункты Установка служб удаленных рабочих столов, Стандартное развертывание и Развертывание рабочих столов на основе сеансов.Click Remote Desktop Services installation, Standard Deployment, and Session-based desktop deployment.
   3. Выберите соответствующие серверы: сервер посредника подключений к удаленному рабочему столу, сервер веб-доступа к удаленным рабочим столам и сервер узла сеансов удаленных рабочих столов (например, Contoso-Cb1, Contoso-WebGw1 и Contoso-Sh2 соответственно).Select the appropriate servers for the RD Connection Broker server, RD Web Access server, and RD Session Host server (for example, Contoso-Cb1, Contoso-WebGw1, and Contoso-Sh2, respectively).
   4. Выберите Автоматический перезапуск конечного сервера, если требуется, а затем нажмите кнопку Развернуть.Select Restart the destination server automatically if required, and then click Deploy.
   5. Дождитесь успешного завершения развертывания.Wait for the deployment to complete successfully

3. Добавьте сервер лицензирования удаленных рабочих столов:Add RD License Server:

   1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Обзор > + Лицензирование удаленных рабочих столов.In Server Manager, click Remote Desktop Services > Overview > +RD Licensing.
   2. Выберите виртуальную машину, где будет установлен сервер лицензирования удаленных рабочих столов (например, Contoso-Cb1).Select the virtual machine where the RD license server will be installed (for example, Contoso-Cb1).
   3. Нажмите кнопку Далее, а затем — кнопку Добавить.Click Next, and then click Add.

4. Активируйте сервер лицензирования удаленных рабочих столов и добавьте его в группу серверов лицензирования:Activate the RD License Server and add it to the License Servers group:

   1. В диспетчере серверов щелкните Сервис > Службы терминалов > Диспетчер лицензирования удаленных рабочих столов.In Server Manager, click Tools > Terminal Services > Remote Desktop Licensing Manager.
   2. В диспетчере лицензирования удаленных рабочих столов выберите сервер и нажмите кнопку Действие > Активировать сервер.In RD Licensing Manager, select the server, and then click Action > Activate Server.
   3. Примите значения по умолчанию в мастере активации сервера.Accept the default values in the Activate Server Wizard. Продолжайте принимать значения по умолчанию, пока не появится страница Сведения об организации.Continue accepting default values until you reach the Company information page. Введите сведения о своей организации.Then, enter your company information.
   4. Примите значения по умолчанию на оставшихся страницах вплоть до последней.Accept the defaults for the remaining pages until the final page. Снимите флажок Запустить мастер установки лицензий, а затем нажмите кнопку Готово.Clear Start Install Licenses Wizard now, and then click Finish.
   5. Выберите пункты Действие > Просмотр конфигурации > Добавить в группу > ОК.Click Action > Review Configuration > Add to Group > OK. Введите учетные данные пользователя в группе администраторов контроллера домена AAD и выполните регистрацию в качестве точки подключения службы.Enter credentials for a user in the AAD DC Administrators group, and register as SCP. Этот шаг может не работать, если вы используете доменные службы Azure AD, но вы можете игнорировать предупреждения или ошибки.This step might not work if you are using Azure AD Domain Services, but you can ignore any warnings or errors.

5. Добавьте имя сертификата и сервер диспетчера шлюза удаленных рабочих столов:Add the RD Gateway server and certificate name:

   1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Обзор > + Шлюз удаленных рабочих столов.In Server Manager, click Remote Desktop Services > Overview > + RD Gateway.
   2. В мастере добавления серверов шлюза удаленных рабочих столов выберите виртуальную машину, где вы хотите установить сервер шлюза удаленных рабочих столов (например, Contoso-WebGw1).In the Add RD Gateway Servers wizard, select the virtual machine where you want to install the RD Gateway server (for example, Contoso-WebGw1).
   3. Введите имя сертификата SSL для сервера шлюза удаленных рабочих столов, указав внешнее полное доменное имя.Enter the SSL certificate name for the RD Gateway server using the external fully qualified DNS Name (FQDN) of the RD Gateway server. В Azure это метка DNS-имя, которая использует формат имяслужбы.расположение.cloudapp.azure.com.In Azure, this is the DNS name label and uses the format servicename.location.cloudapp.azure.com. Например, contoso.westus.cloudapp.azure.com.For example, contoso.westus.cloudapp.azure.com.
   4. Нажмите кнопку Далее, а затем — кнопку Добавить.Click Next, and then click Add.

6. Создайте и установите самозаверяющие сертификаты для серверов шлюза удаленных рабочих столов и посредника подключений к удаленному рабочему столу.Create and install self-signed certificates for the RD Gateway and RD Connection Broker servers.

   Примечание

   Если вы предоставляете и устанавливаете сертификаты из доверенного центра сертификации, выполните процедуры с шага h по шаг k для каждой роли.If you are providing and installing certificates from a trusted certificate authority, perform the procedures from step h to step k for each role. Необходимо иметь доступные PFX-файлы для каждого из этих сертификатов.You will need to have the .pfx file available for each of these certificates.

   1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Задачи > Изменить свойства развертывания.In Server Manager, click Remote Desktop Services > Overview > Tasks > Edit Deployment Properties.
   2. Разверните Сертификаты, а затем прокрутите страницу вниз до таблицы.Expand Certificates, and then scroll down to the table. Выберите пункты Шлюз удаленных рабочих столов > Создать сертификат.Click RD Gateway > Create new certificate.
   3. Введите имя сертификата, используя внешнее полное доменное имя сервера шлюза удаленных рабочих столов (например, contoso.westus.cloudapp.azure.com), а затем введите пароль.Enter the certificate name, using the external FQDN of the RD Gateway server (for example, contoso.westus.cloudapp.azure.com) and then enter the password.
   4. Выберите Сохранить этот сертификат и перейдите к общей папке, созданной для сертификатов на предыдущем шаге.Select Store this certificate and then browse to the shared folder you created for certificates in a previous step. (Например, \Contoso Cb1\Certificates.)(For example,\Contoso-Cb1\Certificates.)
   5. Введите имя файла сертификата (например, ContosoRdGwCert), а затем нажмите кнопку Сохранить.Enter a file name for the certificate (for example, ContosoRdGwCert), and then click Save.
   6. Установите флажок Разрешить добавление сертификата в хранилище сертификатов доверенных корневых центров сертификации на конечных компьютерах, а затем нажмите кнопку ОК.Select Allow the certificate to be added to the Trusted Root Certificate Authorities certificate store on the destination computers, and then click OK.
   7. Нажмите кнопку Применитьи дождитесь, когда сертификат будет успешно применен к серверу шлюза удаленных рабочих столов.Click Apply, and then wait for the certificate to be successfully applied to the RD Gateway server.
   8. Выберите пункты Веб-доступ к удаленным рабочим столам > Выбрать существующий сертификат.Click RD Web Access > Select existing certificate.
   9. Откройте сертификат, созданный для сервера шлюза удаленных рабочих столов (например, ContosoRdGwCert), и нажмите кнопку Открыть.Browse to the certificate created for the RD Gateway server (for example, ContosoRdGwCert), and then click Open.
   10. Введите пароль для сертификата, установите флажок Разрешить добавление сертификата в хранилище сертификатов доверенных корневых центров сертификации на конечных компьютерах, а затем нажмите кнопку ОК.Enter the password for the certificate, select Allow the certificate to be added to the Trusted Root Certificate store on the destination computers, and then click OK.
   11. Нажмите кнопку Применить и дождитесь, когда сертификат будет успешно применен к серверу веб-доступа к удаленным рабочим столам.Click Apply, and then wait for the certificate to be successfully applied to the RD Web Access server.
   12. Повторите подшаги 1–11 для посредника подключений к удаленному рабочему столу — включение единого входа и посредника подключений к удаленному рабочему столу — публикация служб, используя внутреннее полное доменное имя сервера посредника подключений к удаленному рабочему столу в качестве имени нового сертификата (например, Contoso-Cb1.Contoso.com).Repeat substeps 1-11 for the RD Connection Broker — Enable Single Sign On and RD Connection Broker — Publishing services, using the internal FQDN of the RD Connection Broker server for the new certificate’s name (for example, Contoso-Cb1.Contoso.com).

7. Экспортируйте открытые самозаверяющие сертификаты и скопируйте их на клиентский компьютер.Export self-signed public certificates and copy them to a client computer. Если вы используете сертификаты из доверенного центра сертификации, этот шаг можно пропустить.If you are using certificates from a trusted certificate authority, you can skip this step.

   1. Запустите оснастку certlm.msc.Launch certlm.msc.
   2. Разверните узел Личный, а затем щелкните Сертификаты.Expand Personal, and then click Certificates.
   3. На панели справа щелкните правой кнопкой мыши сертификат посредника подключений к удаленному рабочему столу, предназначенный для проверки подлинности клиента, например Contoso Cb1.Contoso.com.In the right-hand pane right-click the RD Connection Broker certificate intended for client authentication, for example Contoso-Cb1.Contoso.com.
   4. Выберите Все задачи > Экспортировать.Click All Tasks > Export.
   5. Принимайте значения по умолчанию в мастере экспорта сертификатов, пока не дойдете до страницы Экспортируемый файл.Accept the default options in the Certificate Export Wizard accept defaults until you reach the File to Export page.
   6. Перейдите к общей папке, созданной для сертификатов, например \Contoso-Cb1\Certificates.Browse to the shared folder you created for certificates, for example \Contoso-Cb1\Certificates.
   7. Введите имя файла сертификата (например, ContosoCbClientCert), а затем нажмите кнопку Сохранить.Enter a File name, for example ContosoCbClientCert, and then click Save.
   8. Нажмите кнопку Далее, а затем кнопку Готово.Click Next, and then click Finish.
   9. Повторите подшаги 1–8 для шлюза удаленных рабочих столов и веб-сертификата, (например, contoso.westus.cloudapp.azure.com), указав для экспортированного сертификата соответствующее имя файла, например ContosoWebGwClientCert.Repeat substeps 1-8 for the RD Gateway and Web certificate, (for example contoso.westus.cloudapp.azure.com), giving the exported certificate an appropriate file name, for example ContosoWebGwClientCert.
   10. В проводнике перейдите в папку, где хранятся сертификаты, например \Contoso-Cb1\Certificates.In File Explorer, navigate to the folder where the certificates are stored, for example \Contoso-Cb1\Certificates.
   11. Выберите два экспортированных сертификата клиента, а затем щелкните их правой кнопкой мыши и выберите Копировать.Select the two exported client certificates, then right-click them, and click Copy.
   12. Вставьте сертификаты на локальный клиентский компьютер.Paste the certifcates on the local client computer.

8. Настройте свойства развертывания шлюза удаленных рабочих столов и лицензирования удаленных рабочих столов:Configure the RD Gateway and RD Licensing deployment properties:

   1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Задачи > Изменить свойства развертывания.In Server Manager, click Remote Desktop Services > Overview > Tasks > Edit Deployment Properties.
   2. Разверните Шлюз удаленных рабочих столов и снимите флажок Обходить сервер шлюза удаленных рабочих столов для локальных адресов.Expand RD Gateway and clear the Bypass RD Gateway server for local addresses option.
   3. Разверните раздел Лицензирование удаленных рабочих столов и выберите вариант На пользователяExpand RD licensing and select Per User
   4. Нажмите кнопку ОК.Click OK.

9. Создайте коллекцию сеансов.Create a session collection. Эти шаги создают базовую коллекцию.These steps create a basic collection. См. дополнительные сведения о коллекциях в разделе Создание коллекции служб удаленных рабочих столов для запуска рабочих столов и приложений.Check out Create a Remote Desktop Services collection for desktops and apps to run for more information about collections.

   1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Коллекции > Задачи > Создать коллекцию сеансов.In Server Manager, click Remote Desktop Services > Collections > Tasks > Create Session Collection.
   2. Введите имя коллекции (например, ContosoDesktop).Enter a collection Name (for example, ContosoDesktop).
   3. Выберите сервер узла сеансов удаленных рабочих столов (Contoso-Sh2), примите пользовательские группы по умолчанию (Contoso\пользователи домена) и введите UNC-путь к созданным ранее дискам профилей пользователей (\Contoso-Cb1\UserDisks).Select an RD Session Host Server (Contoso-Sh2), accept the default user groups (Contoso\Domain Users), and enter the Universal Naming Convention (UNC) Path to the user profile disks created above (\Contoso-Cb1\UserDisks).
   4. Задайте максимальный размер и нажмите кнопку Создать.Set a Maximum size, and then click Create.

Так вы создали базовую инфраструктуру служб удаленных рабочих столов.You’ve now created a basic Remote Desktop Services infrastructure. Если вам нужно создать развертывания высокой доступности, можно добавить кластер посредника подключения или второй сервер узла сеансов удаленных рабочих столов.If you need to create a highly-available deployment, you can add a connection broker cluster or a second RD Session Host server.

Microsoft VDI 2012: ­­установка и настройка. Часть 1.

1. Введение

Microsoft давно пытается завоевать рынок виртуализации как десктопной, так и серверной. Не так давно вышла ОС Windows Server 2012 с новым гипервизором Hyper-V 3.0, который теоретически догнал гипервизор от вендора №1 виртуализации – VMware. Но речь пойдет не о серверной виртуализации, а о десктопной. Почему Microsoft? Потому что MS позиционирует свое VDI-решение как наиболее дешевое (и не зря, кстати), что мгновенно сказывается на заинтересованности рынка данным продуктом. Т.к. в VMware уже все понятно (там все хорошо), с Citrix тоже, осталось познать VDI от MS. Итак, каков он, VDI от MS в 2012-м, да и, пожалуй, в 2013-м и может даже 2014м? Да, т.к. большой любитель VMware, поэтому то тут, то там, будут проскакивать сравнения MS vs VMware.

2. Как это работает

На картинке показаны компоненты, необходимые для работы MS VDI (на самом деле если кто хорошо знаком с VMware View, разница невелика):

Прежде всего, нужен клиент – Remote Desktop Client. Да, для клиента сейчас уже лучше всего использовать Windows 8 и Windows 7 SP1, меньше и тем более XP – плохо.

Далее, на картинке показаны следующие компоненты (описание отсюда http://technet.microsoft.com/library/hh831447 и http://technet.microsoft.com/en-us/library/dd560658(v=ws.10).aspx):

· Remote Desktop Web Access (RDWA) — Веб-доступ к удаленным рабочим столам разрешает пользователям доступ к подключению к удаленным рабочим столам и удаленным приложениям RemoteApp через меню Пуск на компьютере, работающем под управлением Windows 8 или Windows 7, либо через веб-браузер. Подключение к удаленным рабочим столам и приложениям RemoteApp предоставляет настраиваемое представление удаленных приложений RemoteApp и рабочих столов на основе сеансов в коллекции сеансов, а также удаленных приложений RemoteApp и виртуальных рабочих столов в коллекции виртуальных рабочих столов. В VMware это собственно View Client, за исключением веб-портала.

· Remote Desktop Gateway (RDG) — Шлюз удаленных рабочих столов (шлюз RD) позволяет авторизованным пользователям подключаться к виртуальным рабочим столам, удаленным приложениям RemoteApp и рабочим столам на основе сеансов во внутренней корпоративной сети с помощью любого устройства, подключенного к Интернету. В VMware некий аналог View Security Server.

· Remote Desktop Session Host (RDSH) — Узел сеансов удаленных рабочих столов позволяет серверу размещать удаленные приложения RemoteApp или рабочие столы на основе сеансов. Пользователи могут подключаться к серверам узла сеансов удаленных рабочих столов в коллекции сеансов, чтобы выполнять программы, сохранять файлы и использовать ресурсы на этих серверах. Проще говоря, это управлялка службами терминалов. У VMware аналогов нет.

· Remote Desktop Virtual Host (RDVH) — Узел виртуализации удаленных рабочих столов объединяется с Hyper-V для развертывания коллекций помещенных в пул или личных виртуальных рабочих столов в организации с помощью подключения к удаленным рабочим столам и приложениям RemoteApp. Проще говоря, машина с ролью гипервизора – на ней должен стоять Hyper-V. В VMware это ESXi.

· Active Directory (AD) – тут все понятно: собственно AD, DNS и DHCP. В данном мануале DHCP сервера нет ввиду технических ограничений сети тестирования – я обошелся статикой, вовремя подменяемой в момент создания пулов машин J

· Licensing Server — Лицензирование удаленных рабочих столов управляет лицензиями, необходимыми для подключения к серверу узла сеансов удаленных рабочих столов или к виртуальному рабочему столу. Лицензирование удаленных рабочих столов можно использовать для установки, выдачи и отслеживания доступности лицензий.

· Remote Desktop Connection Broker (RDCB) – собственно управлялка подключениями. Аналог View Connection Manager.

Для развертывания простого варианта VDI нам потребуется физический сервер с ОС Windows Server 2012 и установленными ролями Hyper-V и RDVH, и две виртуальные машины: на одной будут службы AD, а на второй – роли RDWA и RDCB. Также нужно будет две виртуалки-шаблона с ОС Windows 7 и ОС Windows 8.

Про RemoteFX: протестировать чудеса графики от MS не получится, потому как хоть процессор (Xeon X56xx) и удовлетворяет требованиям RemoteFX, но нет в сервере физической карты GPU.

3. Подготовка инфраструктуры

Для начала подготовим инфраструктуру.

Что нам требуется:

· 1 физический сервер с ОС W2012 и ролями Hyper-V, RDVH: в качестве сервера у меня под рукой оказался Fujitsu PRIMERGY RX300 S6 с двумя Xeon X56xx, 24GB RAM и дисками 6x 300 SAS 15k;

· 1 контроллер домена с ролями ADDS, DNS (2GB, 2 vCPU);

· 1 сервера брокера соединений с ролями RDWA и RDCB (4GB, 2 vCPU;

· Клиент – ноутбук с правленым файлом hosts – в файл добавим инфу о сервере-брокере.

Используемые адреса:

192.168.1.201/24 iRMC управляющий порт сервера

192.168.1.202/24 hvhost01.vdi.local гипервизор, порт 01

192.168.1.203/24 hvhost01.vdi.local гипервизор, порт 02

192.168.1.204/24 msvdi-dc.vdi.local контроллер домена

192.168.1.205/24 msvdi-broker.vdi.local сервер брокера соединений

192.168.1.206/24 win7template шаблон windows 7

192.168.1.207/24 win8template шаблон windows 8

192.168.1.211/24 win7-01 пул windows 7

192.168.1.212/24 win7-02 пул windows 7

192.168.1.213/24 win8-01 пул windows 8

192.168.1.214/24 win8-02 пул windows 8

192.168.1.10/24 gate шлюз

192.168.1.100/24 client ноутбук-клиент

4. Установка Windows Server 2012 и роли Hyper-V. Создание виртуальных машин.

Установка проста – монтируем диск и устанавливаем, затем вводим пароль и делаем базовую настройку – меняем IP на нужный нам (в примере 192.168.1.202 и 203), правим настройки DNS (выставляем адрес будущего сервера DNS 192.168.1.204) , выставляем время, включаем доступ по RDP и переименовываем машину:

Далее, создаем какую-нибудь папку для образов ISO, и копируем в нее образы W2012, W7 и W8 — у меня эта папка C:\ISO. Далее, создадим папку для конфигурационных файлов Hyper—V, образов машин и образов десктопов. У меня это E:\VM\Config, E:\VM\VHD и E:\VM\VDI соответственно.

Далее добавляем роль Hyper—V:

Выбираем установить роли:

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

Тут ничего не выбираем, просто жмем Next:

Выбираем один адаптер – второй сейчас не нужен, т.к. для каждого адаптера Hyper—V создает свой коммутатор:

Сервер у нас один – никаких миграций не планируется:

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

Все, роль гипервизора установлена – можно создавать виртуальные машины. Теперь ребут и идем в консоль Hyper—V Manager для создания виртуальных машин:

Создадим виртуальные машины для контроллера домена и брокера – жмем New в панели Hyper—V Manager:

Обзовем машину запланированным именем и раздаем ресурсы.

Дадим контроллеру домена 2GB, а брокеру – 4GB. Десктопам позднее дадим тоже 2.

Выберем, к какому коммутатору будет подключена виртуальная машина:

Каким будет диск виртуальной машины и где он будет лежать (стоит отметить, что диски создаются в Thin-формате, т.е. место на физическом диске используется по требованию):

Далее указываем ранее скопированные нами ISO-образы ОС:

И создаем машину, но пока ее не стартуем:

Теперь дадим машине 2 vCPU (идем в свойства машины), также включим автостарт (нужен чтобы после ребута хоста машины поднимались автоматически):

Далее запуск, и ждем…

Итак, машины проинсталлены:

Стоит отметить, что шаги по созданию виртуальной машины практически идентичны аналогичным шагам в клиенте VMware vSphere Client. Также по ощущениям, создание 2-х машин на 4-х дисках в RAID-5 было уж очень неповоротливым, ОС Windows Server 2012 ставилась порядка 40 минут (ставилось их всего две параллельно). Может сказывается медлительность NTFS over VHD over NTFS? В аналогичных условиях на VMware VMFS (получаем NTFS over VMDK over VMFS) параллельная установка ОС выполняется быстрее.

Теперь установим роль контроллера домена и включим в домен машину-брокер msvdi— broker и собственно хост hvhost01.

Продолжение следует…

Инфраструктура виртуальных рабочих столов. Часть 1. Все, кроме VDI | Windows IT Pro/RE

.

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

Рабочая среда настольной системы

Наиболее важная сторона использования компьютера — приложения, которые выполняют определенные функции и обрабатывают данные, как локальные, так и хранящиеся на серверах. Операционная система — основной инструмент для исполнения приложений и управления данными. Пользователи часто настраивают свою рабочую среду с помощью специальных фоновых рисунков, экранных заставок, ярлыков и ссылок на избранные веб-страницы. Хотя эти настройки администратору могут показаться не стоящими внимания, пользователи могут часами искать утерянные приложения или данные либо повторно создавать свои ярлыки. Таким образом, поддержка рабочей среды пользователей очень важна.

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

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

Такая тесная связка создает ряд проблем.

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

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

Желание разделить элементы системы для повышения ее гибкости достаточно общее: во многих продуктах используется модульный принцип построения. Мы покупаем комбинированные системы TV/DVD/видео только для того, чтобы проклинать их, когда ломается видео и мы остаемся без TV и DVD, пока устройство находится в ремонте. Но с отдельными компонентами TV, DVD и видео очень легко заменить один компонент без потери функциональности остальных. Того же самого мы хотим для пользовательских систем — чтобы операционная система, приложения и пользовательские настройки были отдельными блоками, которые собираются в единое целое в зависимости от среды зарегистрировавшегося в системе пользователя. Этой средой может быть локальный рабочий стол, операционная система в среде VDI, сессия в службе терминалов или службе удаленных рабочих столов. Поскольку эти компоненты являются отдельными блоками, отсутствует задержка, связанная с ожиданием их установки или настройки. Компоненты расположены слоями друг над другом для создания полнофункциональной среды настольной системы.

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

Пользовательские данные и настройки

Цель состоит в извлечении настроек и данных пользователя из рабочей среды, так чтобы эти настройки и данные были защищены и доступны независимо от точки подключения пользователя к сети — например, его настольный компьютер, настольный компьютер другого сотрудника, удаленная сессия в системе виртуализации представлений, такой как службы терминалов (службы удаленного рабочего стола), система XenDesktop от Citrix или клиентская операционная система в инфраструктуре VDI. В системе Windows уже давно существуют технологии для абстрагирования пользовательских настроек и данных, но в Windows 7 эти технологии развиты до такого уровня, что они не оказывают негативного влияния на среду пользователя и даже повышают доступность настроек и данных.

Вначале рассмотрим настройки пользователя. У каждого пользователя имеется на компьютере профиль, обычно хранящийся в системе Windows Vista и более поздних версиях в папке C:\Users. Этот профиль состоит из файлов и папок, в том числе файла ntuser.dat, который содержит специфичную для пользователя информацию реестра. Хотя этот файл небольшой, он хранит массу настроек, сделанных пользователем. Профиль также содержит ссылки «Избранное» браузера Интернета, документы, результаты поисковых запросов и другие виды информации. Обсудим их чуть ниже.

Для формирования единообразной среды профиль пользователя должен быть доступен независимо от места подключения пользователя к сети. Таким образом, профиль должен храниться в сети. Эта возможность, называемая «перемещаемый профиль», уже давно доступна в Windows.

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

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

У пользователей имеется несколько мест для хранения данных, например папки «Документы» и «Картинки», которые по умолчанию являются подпапками пользовательского профиля. Если используются перемещаемые профили, эти папки и содержащиеся в них данные реплицируются как часть общего процесса репликации профиля, который, как мы установили, не является оптимальным. Перенаправление папок — это альтернативная технология, которая позволяет настроить размещение стандартных папок в сети. Например, когда пользователь открывает папку «Документы», он в действительности открывает сетевой ресурс, хотя пользователь этого даже не замечает. Перенаправление папок настраивается с помощью групповых политик.

Одним их самых больших изменений в Vista по сравнению с Windows XP стала реструктуризация пользовательского профиля для разделения различных типов данных. При этом число папок, для которых можно настроить перенаправление, возросло с 5 в XP до 13 в Vista, что позволило разделить папки «Документы», «Картинки», «Видео» и «Музыка». В XP «Картинки», «Музыка» и «Видео» являются подпапками папки «Документы», поэтому они следуют за данной папкой при перенаправлении. В Vista, если потребуется, вы можете не настраивать перенаправление папок «Музыка» и «Видео». Перенаправление папок теперь позволяет перенаправить все необходимые пользовательские данные, что делает профиль пользователя очень маленьким и позволяет облегчить синхронизацию оставшихся данных (то есть файла ntuser.dat и некоторых других файлов данных).

Функция «Автономные файлы» (также известная как кэширование на стороне клиента) позволяет хранить локальную копию сетевых данных пользователя на специально настроенных компьютерах, для которых требуется доступ к данным даже при отключении от сети (например, ноутбуки). Автономные файлы синхронизируют изменения в данных на уровне изменений в файлах при восстановлении работы сети. Такая дельта-репликация означает, что реплицируются только измененные части файлов, а не файлы целиком.

Приложения

Когда мы настраиваем компьютер, первое действие, которое мы выполняем после установки операционной системы и обновлений к ней, — это установка приложений, таких как Microsoft Office, бизнес-приложения, модули безопасности и другие виды программ. Установка программ обычно занимает достаточно много времени, так как развертывание и настройка требуют обновлений в файловой системе, добавления параметров реестра и регистрации ресурсов. Как правило, только приложения масштаба организации устанавливаются вместе с развертыванием операционной системы. Приложения, специфичные для подразделений и отдельных пользователей, могут быть установлены при первой регистрации в системе, что вносит дополнительные задержки.

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

• Совместимость приложений между собой. Изменения, вносимые в операционную систему приложениями, могут оказаться несовместимыми с другими приложениями и даже с различными версиями тех же самых приложений. Перед развертыванием в производственной среде нового или обновленного приложения необходимо проведение регрессионного тестирования, при этом некоторые комбинации приложений могут оказаться невозможными.
• «Разбухание» операционной системы. При установке каждого нового приложения добавляются новые службы, которые расходуют ресурсы, но не всегда реализуют полезные функции. Вдобавок увеличивается размер реестра, который использует память и приводит к замедлению работы системы. Даже если впоследствии приложения удаляются, их остатки засоряют систему.
• Обновление приложений. Процессы обновления приложений могут сильно отличаться, и это требует значительных усилий при планировании и создании инфраструктуры для развертывания.

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

Одно из решений — это традиционная виртуализация представлений, в которой приложения устанавливаются на терминальных серверах, а затем исполняются на этих серверах, в то время как окно приложения отображается на локальном рабочем столе пользователя. Это решение требует солидной серверной инфраструктуры для размещения исполняемых приложений и не допускает автономного запуска приложений. Кроме того, по-прежнему остается необходимость установки всех приложений на нескольких терминальных серверах. Тем не менее это решение может подойти для некоторых приложений, например таких, которым нужен доступ к большим объемам данных, размещенных в центре обработки данных. Когда такое приложение работает в центре обработки данных в среде виртуализации представления, сетевой трафик при доступе к данным ограничен сетью центра обработки данных, обычно очень быстрой. Запуск того же приложения локально на компьютере пользователя требует передачи всех данных по сети, которая использует значительную часть полосы пропускания и замедляет работу приложения.

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

Вспомним, что при установке приложений вносятся изменения в файловую систему (то есть в папку C:\Program Files помещаются исполняемые файлы приложения и библиотеки DLL, вносятся изменения в реестр, устанавливаются службы). Виртуализация приложений осуществляется путем перехвата всех этих изменений в системе с помощью особого процесса виртуализации, сериализации, (sequencing, термин из Microsoft App-V), осуществляющего преобразование процедуры установки приложения в двоичный поток, который используется при виртуализации приложения. Эти изменения сохраняются на различных виртуальных уровнях, таких как уровень файловой системы, уровень реестра, уровень служб, шрифтов, компонентов OLE и конфигурации, которые затем могут быть загружены в единую виртуальную среду при запуске приложения. Для самого приложения все эти файлы, реестр и службы выглядят как часть локально установленной операционной системы, но в действительности приложение имеет дело с виртуальными уровнями, которые ему предоставляет среда виртуализации приложений. Никаких изменений в локально установленную систему не вносится.

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

App-V — это решение Microsoft по виртуализации приложений. По умолчанию App-V работает как потоковая технология. При первом запуске виртуализованного приложения клиент App-V подключается к потоковому серверу App-V, который посылает клиенту часть двоичного потока приложения, необходимую для начального запуска. Эта часть двоичного потока называется основным функциональным блоком (Feature Block 1) и обычно составляет от 10 до 20% общего двоичного потока. Данная часть доставляется клиенту очень быстро — для Office 2010 интервал между щелчком пользователя по значку приложения и запуском окна приложения составляет около трех секунд.

Процесс виртуализации приложения в App-V определяет, что необходимо поместить в основной функциональный блок, с помощью действительного запуска приложения при его виртуализации на этапе сериализации (sequencing) и мониторинга необходимых частей потока. Все требуемые элементы помещаются в основной функциональный блок, а оставшаяся часть — в дополнительный функциональный блок (Feature Block 2). После запуска приложения дополнительный функциональный блок передается клиенту в фоновом режиме. Двоичный поток кэшируется в локальной клиентской операционной системе, таким образом, если приложение запускается вновь, поток повторно по сети не передается.

Хотя я упомянул, что виртуализация приложения не вносит изменений в локальную операционную систему, очевидно, что она кэширует в системе поток данных. Однако поток кэшируется в одном файле в профиле All Users, и этот единственный кэш-файл разделяется между всеми пользователями и приложениями. Приложения больше ничего не записывают в файловую систему и не вносят никаких изменений в настройки системы или в реестр. Этот кэш также делает виртуализованное приложение доступным, даже если компьютер не в сети. В среде VDI мы можем разместить данный кэш на сетевом ресурсе, чтобы он был общим для всех клиентских виртуальных машин среды VDI. Такой подход избавляет от необходимости иметь для каждого клиента собственный кэш App-V, что позволяет экономить место на диске и ускоряет начальный запуск приложения.

Поток — это способ доставки приложений в технологии App-V (по умолчанию). Однако App-V поддерживает также создание файла MSI, который содержит полный поток для других технологий развертывания, таких как групповые политики и Microsoft System Center Configuration Manager (SCCM) 2007 R2. Для доставки потока App-V можно даже использовать традиционные сетевые общие папки и службы Microsoft IIS. Для различных организационных и инфраструктурных задач доступно множество вариантов.

Заметим, что такие базовые операции, как вырезание и вставка, связывание и внедрение объектов (OLE), по-прежнему работают между виртуализованными приложениями, но для более глубокой интеграции можно создать зависимости между ними. Так называемое формирование динамических пакетов Dynamic Suite Composition позволяет отдельным виртуализованным приложениям взаимодействовать друг с другом.

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

• Приложения могут быть быстро развернуты для каждого пользователя и в реальном времени, что позволяет администраторам распространять приложения на настольные системы так, как требуется.
• Проблемы совместимости между приложениями решены, так как отдельные виртуализованные приложения «не видят» друг друга. Приложения имеют собственные виртуальные файловые системы, реестры и т. д. Такая изоляция также избавляет от необходимости регрессионного тестирования при запуске новых или обновленных приложений.
• Установка обновлений становится очень простой. Виртуализованное приложение обновляется только один раз. App-V передает изменения в поток для всех клиентов, без каких-либо действий со стороны пользователей.
• Операционная система не разбухает, так как приложения не устанавливаются в локальной операционной системе.

Операционная система

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

В Windows 7 реализована технология Windows XP Mode, которая позволяет исполнять приложения, не совместимые с Windows 7, в локальной виртуальной машине с системой XP. Окно приложения отображается на рабочем столе пользователя в Windows 7, незаметно для пользователя. В этом случае в среде Windows 7 исполняется отдельный экземпляр предыдущей версии операционной системы, которым необходимо управлять. Технология виртуализации корпоративных настольных систем Microsoft Enterprise Desktop Virtualization (MED-V) от Microsoft, являющаяся частью пакета оптимизации настольных систем Microsoft Desktop Optimization Pack (MDOP), упрощает этот процесс за счет как распределения и обновления виртуальных машин XP, так и управления ярлыками на рабочих столах и ссылками URL для обозревателя Internet Explorer (IE) 6.0. Такой подход обеспечивает и решение проблемы совместимости обозревателя IE в Windows 7.

Еще один подход к виртуализации клиента — виртуализация всей настольной операционной системы пользователя в центре обработки данных и предоставление локальному клиенту удаленного подключения к клиентским операционным системам, размещенным в центре обработки данных. Этот локальный клиент может быть «тонким» устройством, устаревшим компьютером с Windows Fundamentals (операционной систе­мой на основе Windows, разработанной для тех, кто использует старые компьютеры и операционные системы), а также любым другим устройством или операционной системой, поддерживающей протокол RDP (в случае однородного решения на платформе Microsoft). Достоинство этого подхода заключается в том, что, поскольку рабочая среда пользователя полностью размещена в центре обработки данных, конфиденциальные данные в действительности никогда не покидают пределы центра обработки данных. Кроме того, рабочий стол доступен пользователю независимо от того, откуда он подключается к сети, в том числе при подключении с домашнего компьютера. Эти решения также очень эффективны при планировании восстановления после сбоев.

Собираем все вместе

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

1. Пользователь регистрируется в системе с учетной записью службы каталогов Active Directory (AD).
2. После успешной проверки подлинности создаются те части профиля, которые не абстрагированы с помощью перенаправления папок; этот минимальный объем информации загружается очень быстро. Затем в дополнение к перенаправлению папок производятся настройки пользователя в локальной сессии. Таким образом, пользователю становятся доступны все его данные, избранные ссылки и т. д.
3. Клиент App-V подключается к серверу управления App-V для определения набора приложений, которые применяются к зарегистрировавшемуся в системе пользователю, и создает все ярлыки на рабочем столе и в главном меню, а также настраивает привязку системы к соответствующим типам файлов.
4. Теперь у пользователя имеется полнофункциональная рабочая среда и он может немедленно запускать приложения и использовать данные.

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

Джон Сэвилл ([email protected]) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

Инфраструктура виртуальных рабочих столов. Часть 1. Все, кроме VDI

Поделитесь материалом с коллегами и друзьями

Правильный расчет для VDI (часть 2) / Блог компании Hewlett Packard Enterprise / Хабр

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

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.

Процессоры

Посчитаем количество необходимых процессоров.

Серверы заказчика на 6-ядерных процессорах Intel Xeon, 2 шт на сервер, т.е. 2 x 6 x 7 = 84 пользователя на 1 ESX-сервер с 2-мя процессорами. Кроме этого, архитектура Nehalem и Westmere очень эффективно позволяет задействовать Hyper Threading и получить на 50-80% больше клиентов. Т.е. на практике где-то: 1,52 * 84 = 126-128 пользователей.

Еслу Hyper Threading не может быть использован или дает прирост меньше 50%, или если необходимо сделать просчет с запасом, то рекомендуемое правило: использовать 75% пользователей на сервер от показателя с hyper threading (т.е. в нашем случае: 128 * 75% = 96 пользователей на сервер), но в текущем расчете все показатели были проверены на практике и совпали с расчетными.

Число серверов для первого этапа (700 пользователей) — 6 серверов, с учетом дальнейшего расширения — 8 серверов.

Оперативная память

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

Например, с Windows XP (это наш случай) для базовых операций требуется 400-500 МБ, с кэшированием — не более 700 МБ. Система в обычных условиях начинает использовать файл подкачки, когда остается менее 25% свободного места в оперативной памяти. ОС всегда старается сохранить как минимум 25% свободного места в резерве. Но использование файлов подкачки в виртуальной среде приведет к потере производительности, поэтому вместо создания файла подкачки с объемом в 1,5-2 от оперативной памяти жестко зафиксируем: не более 200-500 МБ на файл подкачки, если это недостаточно, то клиенту необходимо добавить больше оперативной памяти.

Помимо этого, примерно половина всей используемой памяти содержит похожие блоки на всех клиентах (DLL, схожие блоки приложений и пр.). vSphere Memory Management делит всю память на страницы по 4 КБ, а служба TPS сканирует все блоки данных каждые 60 минут и вычисляет хэш. Ядро сохраняет хэш в таблицу и сравнивает с уже записанными ранее значениями, оставляя только одну копию из двух идентичных, высвобождая таким образом свободное пространство. Если необходимо внести изменения в эту страницу, то создается ее копия для записи. Процент RAM, который высвобождается c использованием TPS — относительный показатель, зависящий от многих факторов и может достигать 35%-50%. На Windows 7 этот показатель ниже из-за использования ASLR (Address Space Load Randomisation), но его также можно отключить.

Для запуска Windows XP на ESX-сервере нам необходимо:

1. Если будет занято 60% памяти и половина ее будет разделяться между другими виртуальными машинами (Transparent Page Sharing), то нам нужно 1 ГБ * 60% * 50% = 300 МБ. Плюс, каждая виртуальная машина требует немного оперативной памяти сама по себе – около 5% от общего объема памяти сервера, те около 50 МБ на клиента. Итого 350 МБ. Хост сам по себе требует 4 ГБ RAM. Итого: 4 ГБ (хост) + 350 МБ * 128 (число виртуальных машин на сервер) = 48 ГБ RAM на сервер.
2. Если занято 75% оперативной памяти и только треть будет разделяться, то каждому клиенту необходимо 1 ГБ * 75% * 67% = 512 МБ. Итого: 4 ГБ (хост) + (512МБ + 50 МБ) *128 = 75 ГБ RAM на сервер.
3. Если хост вобще не поддерживает разделение страниц, то нам необходимо: 4 ГБ (хост) + (1024 МБ +50 МБ)* 128 = 139 ГБ RAM.
4. Для клиентов Windows 7 цифры следующие: (2 ГБ + 102МБ) * 50% * 60% = 645МБ на клиент. Итого: 4ГБ + 660МБ *128 = 81 ГБ. Если хост не поддерживает transparent page sharing, то необходимо: 4ГБ + (2ГБ + 102МБ) * 128 = 275 ГБ.

К счастью, в нашем случае Transparent Page Sharing функционировал, гостевой системой была выбрана Windows XP, поэтому расчет делался по «худшему» сценарию из возможных для этого случая — пункт 2, т.е 75 ГБ RAM на сервер.

Диски

Показатель IOPS очень сильно зависит от версии ОС и от тех приложений, которые будут использоваться. Для ОС Windows XP примерный показатель — 8 IOPS на саму систему, для Windows 7 — 10 IOPS на систему. Исходя из этого, на 128 виртуальных машин Windows XP (8 IOPS) необходимо 1024 IOPS в режиме чтение/запись 20/80, т.е. 205 IOPS на чтение и 819 IOPS на запись. Т.е получаем количество дисков в RAID1: 205 / 160 IOPS + 819 / 80 IOPS (см. предыдущий пост, часть по RAID) = 14 дисков, неважно стоят ли они на хосте или на общем хранилище.

В RAID5: 205 / 160 + 819 / 45 = 21 диск.

Исходя из замеров на дисковую подсистему: на каждого обычного пользователя необходимо 20 IOPS дисковой производительности, таким образом: 20 IOPS * 1000 пользователей = 20000 IOPS. Из них 20% на чтение (4000 IOPS) и 80% на запись (16000 IOPS). Рассчитаем число дисков в RAID1: 4000 / 160 + 16000 / 80 = 226 дисков. Если пользователи отличаются по приложениям, то расчет берется по каждой группе пользователей.

Если необходимо посчитать число дисков в RAID5: 4000 / 160 + 16000 / 45 = 381 диск.

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

Так как текущее хранилище (HP EVA) могло быть расширено до требуемых 226 дисков, то необходимости в замене хранилища не было.

Для получения показателей производительности VDI профилей в рамках массива используется команда vscsiStats. C помощью нее подсчитываются: IO size, seek distance, Outstanding IOs, Latency.

У vmWare есть документ, в котором указаны показатели и команды для запуска статистики.

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

Подведем итог в виде таблицы по VDI:

Показатели количества VDI-клиентов на 1 физический диск и числа дисков, необходимых для работы 128 пользователей:

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

• Отключить Memory Ballooning — для VDI файл подкачки не приносит пользы, стараться выставлять жесткие значения, при необходимости — увеличивать RAM, не файл подкачки.
• Использовать single vCPU VMs — большинство приложений пользователей однопоточные, им не нужны multi vCPU.
• Timed Boots — разделить группы пользователей по группам, запускать группы по приоритету.
• Оптимизировать антивирусное сканирование. Антивирусное ПО — «необходимое зло» в IT, но если ПО не настроено грамотно, то это приведет к резкому снижению производительности. Полезно будет выставить сканирование по записи, сканирование только локальных дисков и исключить Pagefile.sys и папку Print Spool.
• Отключить 3D Screen Savers в профилях пользователей – эти заставки потребляют очень много ресурсов CPU.
• Использовать физические контроллеры доменов — да, можно запустить DC в виртуальной среде, но Microsoft все еще рекомендует использовать DC в виде физической машины.
• NIC Teaming (Aggregation) — NICs должны быть объединены для большей пропускной способности.
• Виртуализация приложений — приложения должны быть виртуализованы также, как и ОС. Это упрощает поддержку и сжимает размер «золотых образов». Такие образы легче разворачивать и обновлять.
• Правильно рассчитывать пропускную способность сети — раньше расчет делался, исходя из показателя 20 КБ/с на пользователя, но это не отвечает текущему положению вещей. Актуальным значением сейчас будет около 100 КБ/с на пользователя.
• Грамотно рассчитывать производительность системы хранения — выбор типа дисков и уровня RAID определяет как хорошо ваша система хранения выполняет работу в VDI-окружении. Опыт показывает, что RAID 10 – это разумный выбор для VDI из-за высокой производительности. А SSD и Flash-память серьезно уменьшают время загрузки, но имеют большую стоимость (правда, цена такого решения неуклонно падает).

Интересное чтение:

Windows Server 2012R2 RDS и Azure RemoteApp / Блог компании МУК / Хабр

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

• Построение терминальной службы на базе Windows Server 2012R2.

• Построение и использование системы виртуальных рабочих столов.

• Построение и использование системы виртуальных рабочих столов на базе Azure RemoteApp.

Расшифровка и запись вебинара под катом.

Сегодня с вами мы поговорим о такой штуке, как удаленная работа пользователей. В Windows Server 2012 есть такая технология RDS, о ней мы поговорим сегодня подробно, а также рассмотрим функционал в Azure RemoteApp.

План нашего мероприятия. Мы поговорим о лицензировании, о тех бизнес-задачах, которые можно решить с помощью уделенных сессий, поговорим на какой базе все это строится, как все этим управлять, что такое RemoteApp. Ответим на вопрос чем RDS отличается от VDI и посмотрим в живую на те технологии, о которых мы будем говорит.

Итак, Windows Server 2012 и его серверная роль RDS. Лицензирование — RDS включен в 2 редакции как стандарт так и в датацентр. Как мы знаем Microsoft сделал абсолютно идентичными по функционалу, отличаются они по работе с виртуализацией.

Что нам необходимо для RDS? Прежде всего лицензии Server Standart или Datacenter. Не забываем также, что количество процессоров учитывается, сейчас на каждую лицензию по 2 физических процессора. А также нам нужны лицензии Call для пользователей, а также лицензии RDS, для возможности подключения терминальных сессий к терминальному серверу. Кроме того, я здесь не указал, очень часто получаю вопросы: некоторые люди строят архитектуру терминального сервера, таким образом, что на терминальный сервер ставится одна версия офиса, и администратор считает, что этого достаточно, чтобы подключить всех пользователей организации. На самом деле это не так, это большая ошибка. Да, офис ставится в одном экземпляре, но лицензий нужно купить столько лицензий, столько пользователей или устройств планируется подключать к нашему серверу. RDS – новое поколение терминальных серверов, в старых версиях ОС, технология называлась «терминальный сервер», сейчас это называется RDS – Remote Desktop Services.

Бизнес- задачи. Основная идея – это подготовить платформу, благодаря которой будет предоставляться доступ либо к рабочему столу, либо к приложениям, для всех пользователей нашей организации. Чаще всего как это выглядит. Мне не раз приходилось устанавливать данный сервер в разных организациях – наиболее это популярно в банках и госструктурах, потому что когда мы, например, разворачиваем какой-то филиал, где-то в глубинке, устанавливаем какое-то отделение. То там не идет речь о максимальных мощностях. Речь идет о том, чтобы люди вовремя и качественно выполняли свою задачу. И для этого, как показывает практика, достаточно иметь такое устройство как тонкий клиент. Благодаря чему пользователей подключается к RDS, устанавливаем терминальную сессию, заходит на сервер и работает на его мощностях, выполняет свои бизнес-задачи. Тоже самое касается и госучреждений, где у нас находится отделение, за пределами крупных городов, там тоже речь о высоких мощностях не идет, поэтому данное решение очень распространено.

Что такое RDS? Он позволяет нам централизованно управлять ресурсами, централизованно и контролировано предоставлять приложения и данные для пользователей. Кроме того, технология RDS подразумевает под собой 2 возможных реализации. Мы посмотрим на примере, когда будем ставить, я покажу где ставится эта роль.

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

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

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

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

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

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

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

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

Какие основные роли мы здесь можем выделить?

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

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

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

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

Мы можем ограничить, установить время окончания разъединённого сеанса. Данный параметр указывает время, спустя которое сервер завершит разъединенную сессию. Если пользователь у нас отключился по какой-то причине, чаще всего это применимо в местах, где связь нестабильна. Если в течении указанного времени пользователь подключился обратно, он попадает в свою же сессию, то есть все ресурсы, с которыми он работает, они активны, он подключится и будет работать дальше. Если же время истекло, то сервер удаляет все временные файлы пользователя и аннулирует всю сессию.

Кроме того, мы можем ограничивать активность, длительность сеанса. Зачем это нужно? Сейчас распространена тенденция, когда компании борются с тем, что пользователи работают слишком долго, «работа должна быть на работе» и т.д. Если этот принцип соблюдается, то очень легко это можно установить правилами: мы ставим максимальное время работы пользователя на сервере RDS. Чаще всего это время ставят немного больше.

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

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

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

Виртуальный диск – это новая «фича», которая призвана исключить устаревший сервис удаленных профилей, перемещаемых профилей. Здесь для каждого пользователя есть возможность создать ограниченный VHDD-диск, будет размещен по тому пути, который вы укажете. Этот диск будет подключаться к пользователю, используя свои настройки. Используя перенаправляемый профиль, перенаправление папок, мы можем реализовать для каждого пользователя его собственные настройки, его профиль.

Лично я во всех своих проектах рекомендую при разворачивании системы ИТ-инфраструктуры реализовывать файловый сервер. Это позволяет создать папку Home для всех пользователей, и эту папку мы можем подключать как диск при входе пользователей используя групповые политики. Это как еще один вариант предоставление диска для пользователей.

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

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

Очень часто мне приходилось слышать вопрос: чем RDS отличается VDI?

Вопрос был корректным до того момента, пока у нас не появляется Windows Server 2012 и 2012R2, где VDI включен в RDS. Если мы говорим о разнице подключений на уровне сессий и виртуальных рабочих столов, то в первом случае мы подключаемся устройствами непосредственно к серверу, заходим как удаленный пользователь на удаленный рабочий стол, работаем на сервере просто каждый со своим профилем. Какие могут быть опасности? В случае получения прав администратора пользователем, никто от этого не застрахован, есть возможность заражение сервера, либо принесение вреда всей организации, всем пользователям.

При использовании VDI – каждый пользователь работает на своей виртуальной машине. Следовательно, нанесение любого вреда будет только конкретной виртуальной машине, с помощью технологии VDI, мы сможем быстро поднять «упавшую» виртуальную машину. При этом мы не приносим вреда нашей организации, и все пользователи продолжают работу. RDS – является критичным сервером, поэтому к планированию его использования нужно подходить очень внимательно. Есть много компаний, где это реализовано, компаний, которые могут вам дать совет о его реализации.

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

Рассмотрим как технология RDS реализована сейчас в облачных инфраструктурах. Конечно же, мы поговорим о Microsoft Azure – это облако Microsoft. Одной из его функций является предоставление доступа к удаленным приложениям. Azure – это бизнес-конструктор. Вы кладете депозит на портале, на личный счет, и при использовании той или иной технологии, нужна она вам или нет – решаете вы, и с вашего счета снимаются деньги за использование сервисов. Как вы помните, там есть калькулятор – он покажет стоимость всех использованных ресурсов, и вы можете прикинуть бюджет еще до начала использования.

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

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

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

Как это выглядит?

Тот сервер RDS, с которым мы будем работать, находится в виртуальной инфраструктуре. Это к вопросу о том, можно ли реализовать сервер RDS в виртуальной инфраструктуре? – да можно. Подключимся к серверу RDS. В сервер-менеджере есть очень простое управление.

У меня данный сервер реализован на базе сессий. Здесь все очень просто, я могу посмотреть настройку всех моих ролей: как они реализованы, на базе чего они реализованы, какой сервер отвечает за каждую роль и т.д. Я могу добавить с помощью 1-2 кликов новый сервер, если мне это необходимо. У меня есть коллекции на базе сессий. У меня открыто, опубликовано несколько приложений.

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

Теперь демонстрация(с 24 минуты в записи)

Посмотрим вариант с сессиями. Если я подключись к данной сессии, с помощью разных пользователей, то я могу настраивать этим пользователям их права, то, как они будут видеть сам сервер, настройки самого сервера для них, те приложения, с которыми они будут работать. Я могу настроить безопасность так, как это необходимо мне. Все параметры: приложения по умолчанию, рабочий стол, мы все это сможем сделать. Также мы видим второго пользователя, у которого, например, нет прав даже увидеть меню пуск, если у него, к примеру, есть такое ограничение в правах. Этим я хотел показать, что у администратора есть возможность гибко настроить терминальные сессии под разных пользователей. Сделать это просто и максимально безопасно, чтобы юзер пользовался только тем, что ему нужно для работы.

Посмотрим реализацию RemoteApp. Я ввожу строку для веб-доступа, ее мы можем взять либо по имени, либо по IP адресу. Мы попадаем на портал, выглядит он стандартно для всех. На нем опубликованы те приложения, которые пользователь может запустить на своей локальной рабочей станции. После того, как мы открываем список приложений, установленных на сервере, мы можем выделить те, которые мы хотим опубликовать для пользователя. Таким образом, мы можем публиковать различные группы приложений для разных пользователей, для разных групп пользователей: для разных департаментов, например. И вообще не заморачиваться установкой каких-то локальных приложений. Один раз развернули – и все пользователи получают доступ. Эта практика очень широко применяется особенно в интернациональных компаниях, когда офисы, находящие в разных странах заходят по VPN, получают доступ к главному офису, главному ЦОДу, и работают с нужными программами через терминальные сервера.

Теперь посмотрим на Azure. Заходим на портал azure.microsoft.com. Преимущества использования RemoteApp через Azure. Мы не тратим ресурсы на публикацию, на поддержку работы наших приложений: все реализуется в облаке. Доступ отовсюду, главное чтобы был интернет. При заходе на портал вы видите все службы что есть. Сегодня нам необходима служба RemoteAPР. В левом нижнем углу есть кнопка «создать» и здесь легко и просто создать коллекцию, достаточно ввести имя нашей коллекции и выбрать тип шаблона, который у нас есть. По умолчанию у нас есть 2 типа шаблонов: офис и приложения, которые у нас есть на сервере. Но кроме того, у нас есть возможность загружать сюда свои темплейты, чтобы разворачивать свои собственные приложения — для этого нужно azure подключить к своей сети.

По управлению. У меня развернуто 2 коллекции: офис и windows. Их доступ пользователям можно настроить через соответствующую вкладку, где мне нужно указать просто имя пользователя. Точно так же как и в локальном RDS сервере у нас есть возможность публикации приложений, либо можно убрать ту публикацию, которая есть. Все работает также как и в локальном RDS сервере.

В отношении работы с данным сервисом. Чтобы его использовать нужно установить агент. Он нам позволит подключаться к сервису Azure RemoteApp и использовать те программы, которые мы уже имеем. На портале, напротив каждой из моих коллекций, моих темплейтов, будет находится ссылочка на портал, где мне будет предложено скачать агент, чтобы использовать Azure RemoteApp в своей локальной инфраструктуре.

Azure RemoteApp – это приложение для локального доступа пользователям к приложениям. Я могу установить это приложение сразу все пользователям, которым нужны приложения.

Тот функционал, который нужен большинству компаний для полноценной работы уже реализован в Azure – мы уже можем пользоваться этим бизнес-инструментом.

У нас реализован терминальный сервер в облаке. Для разворачивания нового филиала стоит попробовать этот инструмент. Так как у нас в этом случае:

— нет необходимости выделять свои вычислительные мощности,

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

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

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

Увидев работу Windows Server 2012 и 2012R2 – мы увидели насколько все стало проще, интуитивно понятно и доступно. Сейчас нет никаких сложностей в реализации этого решения – это возможно сделать за один день для одной организации.

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

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

Запись вебинара.

Приглашаем 29 мая на следующий бесплатный вебинар из этой серии, тема: «Office 365. Обзор. Работа пользователей SharepointOnline. Yammer». С 09.30 до 11.00 (по Киеву). Для регистрации просьба отправить заявку на [email protected].

Дистрибуция решений Microsoft
Учебные курсы Microsoft

МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание

Скатерть-самобранка, или как развернуть службы удаленного рабочего стола на Windows Server 2012 R2

Сегодня мы объясним, чем развертывание RDS Session Host на Windows Server 2012 R2 отличается от более ранних версий Windows Server и расскажем о доступных опциях развертывания. Remote Desktop Services на Windows Server значительно усовершенствовались за последнее время, но остается, тем не менее, много непонятного по причине множества вовлеченных в процесс компонентов. RD Session Host-ы выполняют всю грязную работу, обслуживая терминальные сессии пользователей. Однако даже при самом примитивном сценарии обязательно использование RD Connection Broker (посредника подключений к удаленному рабочему столу). Еще до того, как вы запланируете развертывание служб удаленного рабочего стола, стоит ознакомиться с его ролью.

RD Connection Broker

Когда сеанс удаленного рабочего стола отключается, приложения в сеансе пользователя продолжают работать. Для отслеживания сеансов пользователей RD Connection Broker (Посредник подключений удаленного рабочего стола) хранит такую информацию, как название хост-сервера сеансов удаленных рабочих столов, где проходит каждая сессия, состояние сессии и ее идентификатор, а также информация о подключенных пользователях в каждой сессии. Эта информация используется для подключения пользователей к существующим сеансам на серверах RD Session Host (терминальные сервера Windows). При создании новой сессии RD Connection Broker-ы также играют свою роль путем подключения пользователей к серверам RD Session Host по мере загрузки.

Начиная с Windows Server 2012, посредники подключений к удаленному рабочему столу не только хранят данные о пользовательских сессиях, но и информацию о конфигурации. Посредник подключений к удаленным рабочим столам использует внутреннюю базу данных Windows для сохранения сессии и информации о конфигурации, кроме случаев, когда установлен режим высокой доступности (HA), где используется сервер SQL 2008 R2 (или более поздняя версия).

Посредник подключений к удаленному рабочему столу требует домен Active Directory, но не может быть установлен на контроллере домена (DC). Можно развернуть службы удаленного рабочего стола в рабочей группе с помощью установки роли сервера, хотя при этом теряется возможность централизованного управления, пульты управления и функционал удаленных приложений Remoteapp.

Централизованная публикация приложений

В Windows Server 2012 также введен концепт коллекций (collections). В Windows Server 2008 R2 требовалось, чтобы системные администраторы публиковали приложения для каждого RD Session Host в индивидуальном порядке. Теперь посредник подключений к удаленному рабочему столу хранит информацию о конфигурации.

Опции развертывания: быстрая и стандартная

Ключ к пониманию того, как развернуть RDS на Windows Server 2012 R2 в понимании того, что недостаточно установки роли RD Session Host. Диспетчер серверов обеспечивает специальный режим развертывания для установки RDS, таким образом все необходимые компоненты установлены в нужных местах, чтобы делает развертывание простым и быстрым.

Службы удаленного рабочего стола на Windows Server 2012 R2

В мастере добавления ролей и компонентов (Add Roles and Features Wizard) в диспетчере серверов есть специальная опция установки, установка служб удаленных рабочих столов (Remote Desktop Services installation), которую необходимо выбрать при развертывании служб удаленных рабочих столов. Формулировка при этом варианте немного смущает, но опция позволяет устанавливать хосты сеансов удаленных рабочих столов без развертывания полной инфраструктуры виртуальных ПК (virtual desktop infrastructure — VDI).

Стандартное развертывание — это модель развертывания по умолчанию, и если вы действительно хотите установить все необходимые роли на одном сервере, что не является лучшей практикой, то стоит выбрать эту опцию. Быстрая установка (Quick Start) может быть полезна в сценариях тестирования или в небольших филиалах, где есть только один доступный сервер.

Стандартное развертывание позволяет установить RD Connection Broker, RD Session Host и RD Web Access на одном сервере или на нескольких серверах, что является наиболее вероятным сценарием развертывания в производственной среде. Посредник подключений к удаленному рабочему столу включает внутреннюю базу данных Windows, RD Session Host и RD Web Access roles. Все это является обязательным, но RD Gateway играет факультативную роль. RD Web Access предоставляет пользователям доступ к RemoteApps или рабочим столам из меню «Пуск» или с веб-портала. Если вы хотите использовать RDS больше, чем в течение 120-дневного пробного периода, вам потребуется дополнительно устанавливать роль лицензирования удаленных рабочих столов.

Консоли управления

Все необходимые консоли управления можно найти в диспетчере серверов на сервере, где установлен посредник подключений к удаленным рабочим столам, за исключением RD Gateway и RD Licensing.

Установка служб удаленного рабочего стола на Windows Server 2012 R2

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

Стандартное развертывание — это модель развертывания по умолчанию, и даже при том условии, что для демонстрации будут установлены три роли сервера на один сервер, это не лучшее решение. Внутренняя база данных Windows устанавливается как часть процесса для поддержки роли посредника подключений к удаленному рабочему столу, также как и некоторые компоненты IIS для RD Web Access, которые обеспечивают доступ к RemoteApps или рабочим столам из меню «Пуск» или с веб-портала.

Лицензирование

При желании использовать развернутые службы удаленного рабочего стола более чем в течение 120-дневного тестового периода необходимо установить роль RD Licensing, добавить лицензию, зарегистрировать сервер лицензирования с Active Directory, а затем добавить RD Licensing в RDS-инфраструктуру. RD Licensing устанавливается также, как любая другая роль, поэтому нет необходимости использовать специальную опцию развертывания в диспетчере серверов.

Развертывание служб удаленного рабочего стола

Серверы, которые вы планируете использовать в своем RDS-развертывании, должны быть добавлены в Пул Серверов (Server Pool) в диспетчере серверов перед началом процесса. Вам потребуется домен Active Directory domain и аккаунт, у которого есть разрешение на установку ролей сервера на выбранный сервер (серверы). Дополнительно может быть установлена роль посредника подключений к удаленному рабочему столу на контроллер домена.

• Откройте Диспетчер серверов;
• Выберите «Добавить роли и компоненты» в меню управления;
• В Мастере добавления ролей и компонентов нажмите «Далее» на экране «Перед началом установки» (Before You Begin).
• На экране «Выберите тип установки» выберите «Установка служб удаленного рабочего стола» и нажмите «Далее»;
• На экране «Выберите тип развертывания» выберите «Стандартное» и нажмите «Далее».

Стандартное или быстрое развертывание

• На экране «Выберите сценарий развертывания» выберите развертывание серверов сеансов (Session-based desktop deployment) и нажмите «Далее».
• На экране обзора служб ролей (Review role services) отметьте службы ролей для установки и нажмите «Далее».

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

• На экране определения сервера посредника подключений к удаленному рабочему столу кликните дважды на сервер в пуле серверов для того, чтобы добавить его в список выбранных. Это тот сервер, на который будет установлена роль посредника подключений к удаленному рабочему столу. Нажмите «Далее».

Выберите сервер из пула серверов

• На экране определения сервера RD Web Access повторите предыдущий шаг, чтобы добавить сервер в Selected, или поставьте галочку в «Установить службу роли RD Web Access на сервер посредника подключений к удаленному рабочему столу» (Install the RD Web Access role service on the RD Connection Broker server), если вы хотите установить эту роль на тот же сервер, что и посредника подключений к удаленному рабочему столу. Нажмите «Далее». continue.
• На экране определения серверов RD Session Host выберите один или более серверов из пула серверов, кликнув дважды или с помощью выбора мышью и нажатия на стрелку в центре диалогового окна.
• На экране подтверждения нажмите «Перезапустить сервер автоматически, если необходимо» (Restart the destination server automatically if required) и нажмите «Развернуть».
• Когда 3 роли сервера будут установлены, нажмите «Закрыть» на экране хода развертывания (View progress).

Ход развертывания

Теперь необходимо залогиниться на сервере, где установлена роль посредника подключений к удаленному рабочему столу, открыть Диспетчер серверов и нажать «Службы удаленного рабочего стола» (Remote Desktop Services) в списке опций слева, чтобы увидеть информацию по вашему RDS-развертыванию.

Дашборд служб удаленного рабочего стола в Диспетчере серверов

Разверните среду удаленного рабочего стола

• 10.04.2017
• 5 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2019, Windows Server 2016

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

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

1. Добавьте все серверы, которые вы собираетесь использовать для служб удаленных рабочих столов, в диспетчер серверов:

   1. В диспетчере серверов щелкните Управление > Добавить серверы .
   2. Нажмите Найти сейчас .
   3. Щелкните каждый сервер в развертывании (например, Contoso-Cb1, Contoso-WebGw1 и Contoso-Sh2) и щелкните ОК .

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

   1. В диспетчере сервера щелкните Управление > Добавить роли и компоненты .
   2. Щелкните Установка служб удаленных рабочих столов , Стандартное развертывание и Развертывание рабочего стола на основе сеанса .
   3. Выберите соответствующие серверы для сервера посредника подключений к удаленному рабочему столу, сервера веб-доступа к удаленным рабочим столам и сервера узла сеансов удаленных рабочих столов (например, Contoso-Cb1, Contoso-WebGw1 и Contoso-Sh2 соответственно).
   4. Выберите При необходимости автоматически перезагрузить целевой сервер , а затем щелкните Развернуть .
   5. Дождитесь успешного завершения развертывания

3. Добавить сервер лицензий RD:

   1. В диспетчере сервера щелкните Службы удаленных рабочих столов> Обзор> + Лицензирование удаленного рабочего стола .
   2. Выберите виртуальную машину, на которой будет установлен сервер лицензий RD (например, Contoso-Cb1).
   3. Щелкните Далее , а затем щелкните Добавить .

4. Активируйте сервер лицензий удаленных рабочих столов и добавьте его в группу серверов лицензий:

   1. В диспетчере сервера щелкните Инструменты > Службы терминалов> Диспетчер лицензирования удаленных рабочих столов .
   2. В диспетчере лицензирования удаленных рабочих столов выберите сервер, а затем щелкните действие > Активировать сервер .
   3. Примите значения по умолчанию в мастере активации сервера. Продолжайте принимать значения по умолчанию, пока не дойдете до страницы Информация о компании . Затем введите информацию о вашей компании.
   4. Примите значения по умолчанию для оставшихся страниц до последней страницы. Очистите Запустить мастер установки лицензий сейчас , а затем нажмите Готово .
   5. Щелкните Action> Review Configuration> Add to Group> OK . Введите учетные данные для пользователя в группе администраторов AAD DC и зарегистрируйтесь как SCP.Этот шаг может не работать, если вы используете доменные службы Azure AD, но вы можете игнорировать любые предупреждения или ошибки.

5. Добавьте сервер шлюза удаленных рабочих столов и имя сертификата:

   1. В диспетчере сервера щелкните Службы удаленных рабочих столов> Обзор> + Шлюз удаленных рабочих столов .
   2. В мастере добавления серверов шлюза удаленных рабочих столов выберите виртуальную машину, на которой вы хотите установить сервер шлюза удаленных рабочих столов (например, Contoso-WebGw1).
   3. Введите имя сертификата SSL для сервера шлюза удаленных рабочих столов, используя внешнее полное доменное имя (FQDN) сервера шлюза удаленных рабочих столов.В Azure это метка DNS-имени в формате servicename.location.cloudapp.azure.com. Например, contoso.westus.cloudapp.azure.com.
   4. Щелкните Далее , а затем щелкните Добавить .

6. Создайте и установите самозаверяющие сертификаты для серверов шлюза удаленных рабочих столов и посредника подключений к удаленному рабочему столу.

   Примечание

   Если вы предоставляете и устанавливаете сертификаты от доверенного центра сертификации, выполните процедуры с шага h до шага k для каждой роли.Вам потребуется файл .pfx для каждого из этих сертификатов.

   1. В диспетчере сервера щелкните Службы удаленных рабочих столов> Обзор> Задачи> Изменить свойства развертывания .
   2. Разверните Сертификаты , а затем прокрутите вниз до таблицы. Щелкните Шлюз удаленных рабочих столов> Создать новый сертификат .
   3. Введите имя сертификата, используя внешнее полное доменное имя сервера шлюза удаленных рабочих столов (например, contoso.westus.cloudapp.azure.com), а затем введите пароль.
   4. Выберите Сохранить этот сертификат , а затем перейдите к общей папке, которую вы создали для сертификатов на предыдущем шаге. (Например, \ Contoso-Cb1 \ Certificates.)
   5. Введите имя файла для сертификата (например, ContosoRdGwCert), а затем нажмите Сохранить .
   6. Выберите Разрешить добавление сертификата в хранилище сертификатов доверенных корневых центров сертификации на конечных компьютерах , а затем нажмите ОК .
   7. Щелкните Применить и дождитесь успешного применения сертификата к серверу шлюза удаленных рабочих столов.
   8. Щелкните Веб-доступ к удаленным рабочим столам> Выбрать существующий сертификат .
   9. Перейдите к сертификату, созданному для сервера шлюза удаленных рабочих столов (например, ContosoRdGwCert), а затем щелкните Открыть .
   10. Введите пароль для сертификата, выберите Разрешить добавление сертификата в хранилище доверенных корневых сертификатов на конечных компьютерах , а затем нажмите ОК .
   11. Щелкните Применить и дождитесь успешного применения сертификата к серверу веб-доступа к удаленным рабочим столам.
   12. Повторите подшаги 1-11 для посредника подключений к удаленному рабочему столу — Включить единый вход и Посредник подключений к удаленному рабочему столу — Службы публикации , используя внутреннее полное доменное имя сервера посредника подключений к удаленному рабочему столу для имени нового сертификата (например, Contoso-Cb1 .Contoso.com).

7. Экспортируйте самозаверяющие общедоступные сертификаты и скопируйте их на клиентский компьютер.Если вы используете сертификаты от доверенного центра сертификации, вы можете пропустить этот шаг.

   1. Запустить certlm.msc.
   2. Разверните Личный , а затем щелкните Сертификаты .
   3. На правой панели щелкните правой кнопкой мыши сертификат посредника подключений к удаленному рабочему столу, предназначенный для проверки подлинности клиента, например Contoso-Cb1.Contoso.com .
   4. Щелкните Все задачи> Экспорт .
   5. Примите параметры по умолчанию в мастере экспорта сертификатов, принимайте значения по умолчанию, пока не дойдете до страницы File to Export .
   6. Перейдите к общей папке, которую вы создали для сертификатов, например \ Contoso-Cb1 \ Certificates.
   7. Введите имя файла, например ContosoCbClientCert, а затем щелкните Сохранить .
   8. Щелкните Далее , а затем щелкните Готово .
   9. Повторите шаги 1–8 для шлюза удаленных рабочих столов и веб-сертификата (например, contoso.westus.cloudapp.azure.com), присвоив экспортируемому сертификату соответствующее имя файла, например ContosoWebGwClientCert .
   10. В проводнике перейдите в папку, в которой хранятся сертификаты, например \ Contoso-Cb1 \ Certificates.
   11. Выберите два экспортированных клиентских сертификата, затем щелкните их правой кнопкой мыши и выберите Копировать .
   12. Вставьте сертификаты на локальный клиентский компьютер.

8. Настройка свойств развертывания шлюза удаленных рабочих столов и лицензирования удаленных рабочих столов:

   1. В диспетчере сервера щелкните Службы удаленных рабочих столов> Обзор> Задачи> Изменить свойства развертывания .
   2. Разверните Шлюз удаленных рабочих столов и снимите флажок Обход сервера шлюза удаленных рабочих столов для локальных адресов .
   3. Разверните Лицензирование RD и выберите На пользователя
   4. Щелкните ОК .

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

   1. В диспетчере сервера щелкните Службы удаленных рабочих столов> Коллекции> Задачи> Создать коллекцию сеансов .
   2. Введите Имя коллекции (например, ContosoDesktop).
   3. Выберите сервер узла сеанса удаленных рабочих столов (Contoso-Sh2), примите группы пользователей по умолчанию (Contoso \ Domain Users) и введите путь универсального соглашения об именах (UNC) к дискам профиля пользователя, созданным выше (\ Contoso-Cb1 \ UserDisks) .
   4. Задайте максимальный размер и нажмите Создать .

Теперь вы создали базовую инфраструктуру служб удаленных рабочих столов. Если вам нужно создать высокодоступное развертывание, вы можете добавить кластер посредника подключений или второй сервер узла сеансов удаленных рабочих столов.

.

Поддерживаемые гостевые операционные системы Windows для Hyper-V на Windows Server

• 08.01.2019
• 2 минуты на чтение

В этой статье

Применимо к: Windows Server 2016, Windows Server 2019

Hyper-V поддерживает несколько версий дистрибутивов Windows Server, Windows и Linux для работы на виртуальных машинах в качестве гостевых операционных систем.В этой статье рассматриваются поддерживаемые гостевые операционные системы Windows Server и Windows. Для дистрибутивов Linux и FreeBSD см. Раздел Поддерживаемые виртуальные машины Linux и FreeBSD для Hyper-V в Windows.

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

Поддерживаемые гостевые операционные системы Windows Server

Ниже приведены версии Windows Server, которые поддерживаются в качестве гостевых операционных систем для Hyper-V в Windows Server 2016 и Windows Server 2019.

Поддерживаемые гостевые операционные системы клиента Windows

Ниже приведены версии клиента Windows, которые поддерживаются в качестве гостевых операционных систем для Hyper-V в Windows Server 2016 и Windows Server 2019.

Поддержка гостевой операционной системы в других версиях Windows

В следующей таблице приведены ссылки на информацию о гостевых операционных системах, поддерживаемых Hyper-V в других версиях Windows.

Как Microsoft обеспечивает поддержку гостевых операционных систем

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

• Проблемы, обнаруженные в операционных системах Microsoft и службах интеграции, поддерживаются службой поддержки Microsoft.

• Для проблем, обнаруженных в других операционных системах, которые были сертифицированы поставщиком операционной системы для работы на Hyper-V, поставщик предоставляет поддержку.

• В случае проблем, обнаруженных в других операционных системах, корпорация Майкрософт отправляет их в сообщество поддержки различных поставщиков, TSANet.

Дополнительные ссылки

.

Windows Server 2012 R2: развертывание Microsoft VDI — статьи TechNet — США (английский)

Эта работа еще не завершена, поэтому вы можете редактировать эту страницу и добавлять новые элементы или разделы по мере необходимости.

Компоненты, необходимые для среды VDI Windows Server 2012

• Сервер Hyper-V с включенной ролью виртуализации удаленных рабочих столов
• Службы домена Active Directory
• Сервер, на котором размещена роль посредника подключений к удаленному рабочему столу
• Сервер, на котором размещается роль узла сеанса удаленных рабочих столов, работающий в режиме перенаправления
• Сервер размещение роли RD Web Access, если требуется доступ через веб-портал
• Сервер, на котором размещается роль «Шлюз удаленных рабочих столов», если требуется внешний доступ к виртуальным рабочим столам через Интернет
• Персональная или объединенная Windows 7/8.1 виртуальная машина работает на узле виртуализации Hyper-V Server.

Дополнительные компоненты:

• App-V
• Общие размещенные приложения служб удаленных рабочих столов
• System Center Virtual Machine Manager (SCVMM)

<добавить увеличенное изображение, включая SCVMM и App-V>

Лицензирование:

<в работе>

Серверное оборудование:

<в работе>

Сеть:

<в работе>

Склад:

<в работе>

Роль узла виртуализации удаленных рабочих столов:

<в работе>

Узел виртуализации удаленных рабочих столов — это служба роли служб удаленных рабочих столов, включенная в Windows Server 2008 R2.Узел виртуализации удаленных рабочих столов интегрируется с Hyper-V для предоставления виртуальных машин, которые можно использовать в качестве личных виртуальных рабочих столов или пулов виртуальных рабочих столов.

Сервер узла виртуализации удаленных рабочих столов выполняет следующие функции:

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

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

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

Роль посредника подключений RD:

<в работе>

Основная цель этой ролевой службы — установить соединение пользователя с соответствующей конечной точкой. Посредничество при подключении включает:

Определение виртуальной машины для удаленного подключения пользователя.

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

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

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

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

<в работе>

Назначение сервера узла сеансов удаленных рабочих столов в режиме перенаправления — безопасное перенаправление клиентского подключения RDP к виртуальной машине.Сервер узла сеансов удаленных рабочих столов, работающий в режиме перенаправления, не разрешает интерактивные пользовательские сеансы, если пользователь не запрашивает административную
сеанс с помощью переключателя «/ admin».

Когда пользователь запрашивает виртуальную машину, сервер узла сеансов удаленных рабочих столов, работающий в режиме перенаправления, запрашивает сервер посредника подключений к удаленному рабочему столу. Сервер посредника подключений к удаленному рабочему столу, в свою очередь, подготавливает виртуальную машину для пользователя и возвращает ее IP-адрес на запущенный сервер узла сеансов удаленных рабочих столов.
в режиме перенаправления. Сервер узла сеансов удаленных рабочих столов, работающий в режиме перенаправления, затем перенаправит клиента RDP для подключения к виртуальной машине с использованием IP-адреса.

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

Роль веб-доступа к удаленным рабочим столам:

<в работе>

RD Web Access предоставляет пользователю агрегированный обзор удаленных приложений и подключений к рабочему столу через веб-браузер.Используя RD Web Access, пользователь может просматривать все удаленные приложения и виртуальные рабочие столы (личные виртуальные рабочие столы и пулы виртуальных рабочих столов)
опубликовано для этого пользователя. Виртуальные машины VDI также доступны через функцию RADC (меню «Пуск») в клиентах Win7.

См. Сообщение в блоге о настройке веб-доступа к удаленным рабочим столам в развертывании Microsoft VDI.

Роль шлюза удаленных рабочих столов:

<в работе>

RD Gateway — это дополнительная ролевая служба в развертывании Microsoft VDI.Его основная цель — безопасно маршрутизировать RDP-соединения через Интернет через брандмауэр.

Персональные или объединенные рабочие столы VDI:

<в работе>

Интеграция с общими размещенными приложениями служб удаленных рабочих столов:

<в работе>

Приложение-V:

<в работе>

App-V может упростить управление образами виртуальных машин в M

Среда Microsoft VDI.Используя App-V, вы можете динамически загружать и назначать приложения для каждой группы пользователей, сокращать тестирование приложений, уменьшать количество конфликтов приложений и повышать совместимость приложений.

Дополнительные сведения о следующей версии App-V см. В разделе Виртуализация приложений в бета-версии Windows 7 с помощью Microsoft App-V.

SCVMM:

<в работе>

Консоль

SCVMM — это универсальный инструмент для управления виртуальными машинами. Как часть решения Microsoft VDI, он не только предоставляет функциональные возможности пользовательского интерфейса Hyper-V, но и обеспечивает быстрое и простое выделение ресурсов виртуальным машинам, что полезно при крупных развертываниях.

Источник: http://blogs.msdn.com/b/rds/archive/2009/08/19/microsoft-vdi-overview.aspx

Роль узла виртуализации удаленных рабочих столов:

<в работе>

Роль посредника подключений RD:

<в работе>

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

<в работе>

Роль веб-доступа к удаленным рабочим столам:

<в работе>

Роль шлюза удаленных рабочих столов:

<в работе>

Создание пулов ВМ:

<в работе>

Назначить личные виртуальные машины:

<в работе>

Настройка интеграции со службами удаленных рабочих столов Общие размещенные приложения

Приложение-V:

<в работе>

SCVMM

<в работе>

Антивирусное ПО:

<в работе>

Отключить функции / услуги

<в работе>

Отключить графические улучшения:

<в работе>

.