Rds на основе сеансов в windows server 2012 r2 часть

В прошлой статье (Службы удалённых рабочих столов на основе сеансов. Часть 1 — Развёртывание в домене) довольно детально был рассмотрен процесс развертывания служб RDS на серверы предприятия. Теперь настал черед ознакомиться с определением коллекций сеансов и рассмотреть процесс их создания.

Согласно официальной справке Microsoft, существует такое определение коллекции сеансов:

Коллекция сеансов — это группа серверов узлов сеансов удаленных рабочих столов для конкретного сеанса. Коллекция сеансов используется для публикации рабочих столов на основе сеансов либо удалённых приложений RemoteApp

(TechNet)

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

Какие же преимущества приносит использование коллекций сеансов?

1. Простое развёртывание. Коллекции сеансов достаточно легко устанавливать и настраивать с помощью соответствующих мастеров.
2. Простое управление. Серверами в коллекции можно управлять из одной унифицированной консоли.
3. Корректное распределение ресурсов. Серверы, которые находятся в одной коллекции умеют корректно распределять такие ресурсы как ЦП, диски и сеть, что предотвращает конфликты между сессиями пользователей.

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

Перед тем как приступить к развёртыванию коллекции сеансов предлагаю ознакомиться с существующей схемой сети. Ферма серверов RDS состоит из четырёх серверов, выполняющих различные роли служб удалённых рабочих столов. Сервер RDCB исполняет роль посредника подключений, сервер RDWH — это узел веб-доступа к удалённым рабочим столам и приложениям RemoteApp, а на серверы RDSH1 и RDSH2 установлена роль узлов сеансов. Кроме роли посредника подключений, сервер RDCB, так же является узлом лицензирования. Помимо фермы серверов RDS в сети присутствует сервер DC1 являющийся контролером домена и рабочие станции пользователей сети — WS101, WS102 и WS103.

Все функции управления коллекциями сеансов в Windows Server 2012 R2 находятся на вкладке Службы удалённых рабочих столов (Remote Desktop Services Manager, RDSM). Добраться до неё можно открыв Диспетчер серверов и выбрав пункт Службы удалённых рабочих столов в панели слева. Для того, чтобы создать новую коллекцию сеансов необходимо выбрать соответствующий пункт в меню Задачи на панели Коллекции.

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

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

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

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

На следующем шаге, мастер предлагает использовать функцию использования дисков профилей пользователей. Это одно из нововведений появившихся в Windows Server 2012. Если вкратце, то диски профилей пользователей представляют собой виртуальные жёсткие диски в формате vhd и призваны заменить перемещаемые профили пользователей. Более подробно эта функция будет описана в одной из последующих статей. Если мы хотим использовать диски профилей пользователей, то ставим соответствующую галочку, указываем общую папку и максимальный размер, который может занимать один vhd файл. При указании папки, нужно убедиться в том, что серверы узлов сеансов и текущий пользователь имеют права на чтение и запись данных в указываемую папку. Если же использовать данную функцию мы не хотим, то просто снимаем галочку с пункта Включить диски профилей пользователей и жмём Далее.

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

Затем начнётся непосредственно сам процесс формирования коллекции. После его окончания, если не возникло ошибок, закрываем окно мастера.

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

Конфигурирование коллекции сеансов

Все параметры относящиеся к какой-либо конкретной коллекции, находятся на странице с её названием. В данном конкретном случае переходим на страницу Коллекция сеансов RDS. Здесь мы видим краткие сведения о самой коллекции, список установленных приложений RemoteApp или предложение их опубликовать, список серверов узлов сеансов, обслуживающих эту коллекцию и перечень подключений к ней.

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

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

Настройка параметров сеансов

Одними из основных настроек, находящимися в пределах данного окна, являются настройки времени взаимодействия узла сеансов непосредственно с самими сеансами. Среди этих настроек:

• Окончание разъединённого сеанса — это время, спустя которое сервер завершит разъединенную сессию пользователя. Говоря иными словами, это количество времени, которое сервер будет хранить временные файлы пользователя. Если пользователь в течение выбранного интервала подключится к службам RDS, то он увидит своё рабочее окружение в том состоянии, что и до разъединения. При этом счётчик времени сбрасывается. Эта опция бывает полезна в случае когда у пользователя нестабильная линия связи с сервером или вы хотите подстраховаться и дать пользователям возможность вернуться к своему сеансу в случае его случайного или же не случайного разъединения.
• Ограничение активного сеанса — это время в течение которого пользователю позволено непрерывно находиться на сервере. Эта настройка позволяет экономить ресурсы сервера в случае, когда пользователь открыл сеанс и находится в нём достаточно продолжительное время. Эту опцию можно задать немногим большую чем длина рабочего дня.
• Ограничение бездействующего сеанса — это время в течение которого пользователь может оставаться в сеансе и при этом не производить никаких действий. Эта настройка, как и предыдущая, позволяет экономить ресурсы сервера, однако при её использовании нужно быть осторожным, поскольку пользователям обычно не нравится, когда их сеанс закрывается слишком часто.

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

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

Настройка параметров безопасности

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

• Уровень безопасности RDP. Выбор этой опции означает, что будет использоваться стандартный уровень шифрования, определённый протоколом RDP. В этом случае, сервер узла подключений не устанавливает подлинность клиента пытающегося к нему подключиться. Это наименее безопасный уровень подключения.
• SSL (TLS 1.0). Этот вариант означает, что будет использоваться шифрование соответствующими протоколами и проверка подлинности клиентов с помощью цифрового сертификата. Эта опция определяет самый высокий уровень безопасности, однако, не везде можно применить такой уровень безопасности.
• Согласование. В этом случае осуществляется попытка применения шифрования уровня TLS, а если клиент его не поддерживает, то будет использовано шифрование протокола RDP.

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

• Низкий. Шифруется только данные от клиента к серверу. Для этого используется 56-разрядное шифрование.
• Высокий. Шифруются данные от клиента к серверу и наоборот. Используется 128-разрядное шифрование.
• FIPS-совместимый. Так же как и в случае с высоким уровнем шифрования шифруются данные и от клиента к серверу и от сервера к клиенту, однако при этом используется алгоритм шифрования FIPS 140-1.
• Совместимый с клиентом. В этом случае будет использоваться максимально возможный уровень шифрования, который будет поддерживать клиент.

Так же можно включить поддержку проверки клиентов на уровне сети. Если включить эту опцию, то авторизация клиента будет происходить до создания сессии. Это позволяет серьезно повысить уровень безопасности RDS. Однако следует помнить, проверка на уровне сети может быть осуществлена только для клиентов использующих RDC 6.0 и выше и ОС Windows XP SP3 и выше. Следовательно пользователи, чьи рабочие станции не будут удовлетворять данным требованиям не смогут подключиться к службам удаленных рабочих столов. Как включить проверку на уровне сети для Windows XP SP3 доступно описано у Карманова. Там вообще можно много хорошего про безопасность протокола RDP почитать.

Настройка балансировки нагрузки

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

• Относительный вес определяет значимость выделенного сервера относительно других. Чем больше число в этом поле, тем большее количество подключений будет принимать сервер. Значение можно задать в диапазоне от 1 до 10000.
• Ограничение сеансов задает количество пользователей, которые могут одновременно быть подключенными к серверу. Значение может находиться в диапазоне от 1 до 999999.

Настройка параметров клиентов удалённого доступа

Переопределить некоторые параметры пользовательского клиента подключений (Remote Desktop Client, RDC) можно на вкладке Настройка параметров клиента.

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

Настройка дисков профилей пользователей

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

После внесения всех требуемых изменений в настройки коллекции нажимаем ОК. На этом настройка коллекции средствами RDMS завершена.

Проверка работоспособности коллекции

Для того, чтобы убедиться что созданная коллекция сеансов работоспособна и может принимать подключения, на одной из рабочих станций домена попробуем получить доступ к ресурсам RDS посредством веб-доступа. Для этого достаточно открыть браузер и перейти по ссылке для веб-доступа (https://rdwh.domain.local).

Так как в коллекцию не добавлено ни одного приложения RemoteApp, доступ будет предоставлен ко всему удалённому рабочему столу. Для инициации нового сеанса достаточно кликнуть на иконку с именем коллекции сеансов (в данном случае Коллекция сеансов RDS).

В следующей статье, посвященной теме RDS, будет рассмотрен процесс добавления и настройки приложений RemoteApp.

БЫСТРОЕ РАЗВЁРТЫВАНИЕ В ДОМЕНЕ

Перед тем, как начать установку RDS на сервер необходимо ознакомиться с существующей инфраструктурой сети. В данном случае, это тестовая сеть, состоящая из контроллера домена DC1 со статическим адресом 172.16.7.1/24, сервера на который будут установлены службы  RDS — RAPP, с адресом 172.16.7.2/24 и рабочих станций WS101, WS102, WS103, получающих IP-адреса по DHCP. Все компьютеры сети подключены к домену domain.local

На сервере RAPP необходимо открыть Диспетчер серверов. Для этого можно нажать на соответствующую иконку на панели задач или выполнить команду servermanager.exe В окне диспетчера выбираем Управление —Добавить роли и компоненты, после чего откроется окно мастера добавления ролей и компонентов. В первом его окне предлагается ознакомиться с основными требованиями к серверам, на которые будут устанавливаться роли. Также здесь можно установить галочку, которая позволит пропускать эту информацию при добавлении новых компонентов и ролей. При частой установке бывает полезно её установить. Прочитав информацию нажимаем Далее.

В следующем окне предлагается выбрать тип установки. Отмечаем пунктУстановка служб удалённых рабочих столов.

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

Далее выбираем сценарий развертывания RDS. Нас интересует создание среды удалённых рабочих столов на основе сеансов. Поэтому выбираем соответствующую опцию и жмём Далее.

В следующем окне мастера предлагается выбрать сервер, на котором будут развернуты службы RDS. В нашем случае это сервер RAPP.domain.local. После того, как выбор сделан, жмём Далее.

После выбора сервера мы увидим окно с подтверждением выбранных служб и именем сервера, на который будут установлены эти службы. Тут же необходимо согласиться с тем, что сервер будет перезагружен, поставив соответствующую галочку и нажать кнопку Развернуть, после чего откроется окно в котором будет отображен процесс развёртывания ролей RDS. В процессе выполнения установки сервер будет перезагружен. После перезагрузки сервера, необходимо зайти под той же учётной записью, под которой был начат процесс установки (в данном случае это domaindcadmin) и спустя некоторое время откроется окно мастера и развёртывание возобновится автоматически.

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

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

Так же мы видим, что кроме этих служб была установлена коллекция QuickSessionCollection в которую входят несколько стандартных приложений RemoteApp, а именно Paint, WordPad и Калькулятор.

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

Проверим работу веб-доступа к удалённым приложениям. Для этого перейдем по ссылке, которую мы получили в процессе работы мастера установки ролей и компонентов —  https://rapp.domain.local/rdweb

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

Следует помнить, что в доменной среде пользователей не обязательно добавлять в группу «Пользователи удалённого рабочего стола» т.к. при развёртывании RDS в эту группу автоматически добавляется группа «Пользователи домена».

Стандартное развёртывание

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

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

• RDCB — сервер, выступающий в роли посредника подключений. Имеет адрес 172.16.7.2/24
• RDWH — сервер, выступающий в роли узла веб-доступа к службе удалённых рабочих столов. Его адрес — 172.16.7.3/24
• RDSH1, RDSH2 — серверы, выступающие в роли узлов сеансов. Имеют адреса, соответственно 172.16.7.4/24 и 172.16.7.5/24

Компьютеры WS101, WS102, WS103 — это рабочие станции, с которых осуществляется доступ к ресурсам серверов RDS. Их сетевые интерфейсы конфигурируются с помощью протокола DHCP.

Прежде чем приступать непосредственно к развёртыванию служб RDS, необходимо выполнить некоторый минимум подготовительный действий. А именно, на сервере, с которого будем проводить установку, откроем Диспетчер серверов и добавим в него все необходимые нам сервера. В данном случае в диспетчер серверов на RDCB добавим сервера RDWH, RDSH1 и RDSH2. Сделать это можно зайдя в пункт Управление и выбрав там опцию Добавление серверов.

После того, как все необходимые для развёртывания серверы добавлены, можно приступить непосредственно к установке служб удалённых рабочих столов. Следует отметить, что сама процедура во многом схожа с процедурой рассмотренной ранее, поэтому некоторые шаги мастера добавления ролей и компонентов будут повторяться. Итак, запустим сам мастер. Это можно сделать, выбрав пункт Управление — Добавить роли и компоненты. На первом шаге мастера предлагается выбрать тип установки. Нам необходимо развернуть службы

RDS, поэтому отмечаем Установка служб удалённых рабочих столов и жмём Далее.
Далее мастер предложит варианты развёртывания RDS. Нас интересуетстандартное развёртывание. Выбираем соответствующий пункт и жмём Далее.

В следующем окне мастера выбираем пункт Развёртывание рабочих столов на основе сеансов.

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

На трёх последующих вкладках следует указать серверы, на которые будут установлены соответствующие роли. В нашем случае роль посредника подключений установим на сервер RDCB, роль узла веб-доступа — на сервер с именем RDWH, роли узлов сеансов — на серверы RDSH1 и RDSH2.

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

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

Проверить работоспособность развёрнутой конфигурации можно зайдя на страницу веб-доступа (https://rdwh.domain.local/rdweb) с одной из рабочих станций.

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

СЕРВЕР ЛИЦЕНЗИРОВАНИЯ

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

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

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

После того, как выбор сделан, необходимо подтвердить его правильность, нажав на кнопку Добавить

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

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

К этим же свойствам можно получить доступ и после завершения установки. Для этого нужно на панели Обзор развёртывания выбрать пункт Свойства, а затем Изменить развёртывание.

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

Далее мы можем развернуть удаленные приложения RemoteApp на этом RDS

Join @AdmNtsRu on Telegram

Сегодня мы объясним, чем развертывание 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-развертыванию

.

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

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

Если вкратце, то рассмотрены следующие ключевые моменты:

1. Использование веб-доступа
2. Использование средств Панели инструментов в Windows 7/8/8.1
3. Использование приложения Удалённый рабочий стол на Windows RT
4. Использование средств групповой политики для доставки приложений RemoteApp клиентам с Windows 8/8.1 и Windows 7
5. Доступ к приложениям RemoteApp из Windows XP

ИСПОЛЬЗОВАНИЕ ВЕБ-ДОСТУПА

Наиболее простым и очевидном способом доступа к приложениям RemoteApp является использование веб-доступа. Для того чтобы получить доступ к приложениям RemoteApp необходимо в строке браузера набрать адрес видаhttps://servername/rdweb и пройти процедуру аутентификации. В общем случае страница веб-доступа будет выглядеть примерно так как изображено на рисунке ниже.

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

НАСТРОЙКА ВНЕШНЕГО ВИДА СТРАНИЦЫ ВЕБ-ДОСТУПА

Изменение имени рабочей области. Первым делом хотелось бы поменять надпись Work Resouces на что-то другое, например, на Удалённые приложения RemoteApp. Эта надпись обозначает имя рабочей области (Workspace) и  управлять ею можно средствами PowerShell.

На любом сервере фермы RDS запустим PowerShell от имени администратора. Я эту операцию выполняю на сервере посредника подключений —rdcb.domain.local. итак, для того, чтобы посмотреть идентификатор рабочей области и её имя используем командлет Get-RDWorkspace (синтаксис). Как видно на скриншоте ниже, имя текущей рабочей области Work Resources. Изменим его на Удалённые приложения RemoteApp с помощью командлета Set-RDWorkspace(синтаксис) и проверим результат, выполнив командлет Get-RDWorkspace.

Настройка элементов страницы веб-доступа. Значок, который расположен рядом с именем рабочей области, так же можно поменять на, скажем, логотип компании. Сделать это можно подредактировав файл Site.xsl, который находится на сервере веб-доступа в папке %WINDIR%WebRDWebPages. Открыв этот файл с помощью любого текстового редактора в разделе Replaceable Company Logo Image указываем путь к файлу, содержащему логотип.

В этом же файле можно изменить и баннер, который является фоном для названия рабочей области и логотипа. Путь к фалу баннера можно изменить в разделеCustomizable banner and Text row.  Фон страницы веб-доступа можно изменить в файле, содержащем таблицы стилей — tswa.css. Он расположен на сервере веб-доступа в папке %WINDIR%WebRDWebPagesru-RU. Если будет установлена локализация отличная от русской, то папка ru-RU будет называться согласно языку системы. Я строку с указанием файла изображения закомментирую. Это приведет к тому, что фон страницы установится в цвет определенный свойством background-color.

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

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

ДОБАВЛЕНИЕ СЕРТИФИКАТА ПОДЛИННОСТИ СЕРВЕРА

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

Для того, чтобы устранить эту проблему нужно создать для развёртывания RDS доверенный сертификат и установить его для службы веб-доступа к удалённым рабочим столам. Сделать это можно двумя способами. Первый — это получить сертификат от доверенного локального или доменного центра сертификации (более предпочтительный вариант) либо использовать самоподписанный сертификат. Поскольку создание и использование центра сертификации выходит за рамки этой статьи, рассмотрим создание наименее безопасного варианта сертификата — самоподписанного сертификата подлинности.

Сначала заходим в Диспетчер серверов, и последовательно переходим по вкладкам Службы удалённых рабочих столов и Коллекции. На панелиКоллекции из меню Задачи выбираем пункт Изменить свойства развёртывания и в открывшемся диалоговом окне Настройка развёртыванияпереходим на вкладку Сертификаты.

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

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

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

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

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

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

Затем проверяем путь расположения файла сертификата и жмём Далее.

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

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

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

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

ИСПОЛЬЗОВАНИЕ СРЕДСТВ ПАНЕЛИ ИНСТРУМЕНТОВ WINDOWS 7 И WINDOWS 8/8.1 ДЛЯ ДОСТАВКИ ПРИЛОЖЕНИЙ REMOTEAPP

Альтернативой использованию веб-страницы для доступа к приложениям RemoteApp и удалённым рабочим столам является использование средства доступа к удалённым приложениям RemoteApp и удалённым рабочим столам. Возможность его использования появилась еще в Windows 7 и получила логическое развитие в Windows 8/8.1. В пользу использования такого метода доступа к приложениям RemoteApp говорит тот факт, что пользователю нет необходимости заходить на специальную веб-страницу, а достаточно выбрать приложение на стартовом экране или в меню Пуск. Ещё одним достоинством такого способа доставки приложений является возможность ассоциировать определённые типы файлов с приложениями RemoteApp.

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

Для того, чтобы получить доступ к средству подключения приложений RemoteApp необходимо на локальной рабочей станции зайти в Панель управления и там выбрать пункт Подключения к удалённым рабочим столам и приложениям RemoteApp. Так же можно, воспользовавшись каноническим именем этого элемента, выполнить команду control /name Microsoft.RemoteAppAndDesktopConnections

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

Далее откроется окно подтверждения правильности введённой ссылки. Если всё верно приступаем к созданию подключения нажав кнопку Далее.

Вариант второй, использование электронного адреса. Этот вариант доступен на ОС Windows 8/8.1. Тут следует дать небольшое разъяснение. На самом деле вводить настоящий электронный адрес вовсе необязательно, т.к. по факту используется только лишь имя домена. Когда имя домена определено, на сервере DNS производится поиск текстовой записи _msradc, которая содержит ссылку для подключения приложений RemoteApp. Поэтому, прежде чем вводить в строку адреса какой-либо e-mail, следует создать в DNS новую текстовую запись с именем _msradc. Сделать это можно в диспетчере DNS, выбрав в меню Действие пунктДругие новые записи.

В окне выбора типа записи отмечаем Текст (TXT) и нажимаем Создать запись

В окне свойств создаваемой текстовой записи в поле Имя записи запишем _msradc, в поле Текст ссылку на страницу веб-доступаhttps://rdwh.domain.local/rdweb/feed Поле Полное доменное имя (FQDN) должно заполниться автоматически.

Как видим, запись успешно создана и она присутствует в перечне всех записей. Кроме графического представления, эту запись можно проверить с помощью контекста SET TYPE=TXT утилиты NSLOOKUP.

После того, как подготовительный этап закончен, можно в поле адреса подключения ввести электронный адрес пользователя. Так как вводить настоящий адрес вовсе не обязательно, то перед @domain.local укажем абсолютно произвольные символы.

В окне подтверждения правильности ввода данных, в этом случае, будет отображаться электронный адрес, который был введён на предыдущем шаге, а в качестве URL-адреса подключения — адрес, который был использован при создании текстовой записи в DNS.

В случае успешной установки будет отображено окно с информацией о созданном подключении. Здесь можно ознакомиться с именем подключения (именем рабочей области), URL-адресом подключения и числом доступных приложений RemoteApp либо удалённых рабочих столов.

Если подключение осуществлялось на клиентской ОС Windows 8/8.1 приложения можно найти на стартовом экране.

Если подключение осуществлялось на рабочей станции с ОС Windows 7, то приложения можно найти в меню Пуск.

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

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

Если нажать на ссылку Просмотр ресурсов, то мы увидим ярлыки, которые ссылаются на непосредственно RDP файлы, которые используются для подключения к программам RemoteApp. В общем случае найти эти файлы можно в папке %APPDATA%RoamingMicrosoftWorkspaces{GUID}Resource. А в соседней папке %APPDATA%RoamingMicrosoftWorkspaces{GUID}Icons можно найти иконки приложений RemoteApp.

ИСПОЛЬЗОВАНИЕ ПРИЛОЖЕНИЯ УДАЛЁННЫЙ РАБОЧИЙ СТОЛ НА WINDOWS RT

На Windows RT так же можно использовать удалённые приложения RemoteApp способом отличным от веб-доступа. Для этого из магазина Windows Storeнеобходимо установить приложение Удалённый рабочий стол (Remote Desktop).

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

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

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

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

После процедуры добавления, программы RemoteApp доступны как со стартового экрана так непосредственно из приложения Удалённый рабочий стол.

ИСПОЛЬЗОВАНИЕ СРЕДСТВ ГРУППОВОЙ ПОЛИТИКИ

Удобнейшим способом доставки приложений RemoteApp и удалённых рабочих столов является использование групповых политик. Однако, штатная распространяется политика только на клиентские системы с Windows 8/8.1.

Найти нужную политику можно в узле Конфигурация пользователя Политики Административные шаблоны Компоненты Windows Службы удалённых рабочих столов Подключения к удалённым рабочим столам и приложениям RemoteApp. Параметр называется Указать URL-адрес подключения по умолчанию. Включаем его и в качестве параметра URL-адрес подключения по умолчанию задаем адрес доступа к приложениям. В общем случае он выглядит так https://servername/rdweb/feed/webfeed.aspx.

В случае с клиентскими ОС Windows 7, дело обстоит несколько сложнее, но распространять приложения средствами GPO все же можно. Для этого понадобится скачать PowerShell скрипт  Install-RADCConnection.ps1 с TechNet. Кроме самого скрипта понадобится создать файл для передачи скрипту параметров подключения и сохранить его в той же директории, что и сам скрипт. Имя файла с параметрами может быть произвольным, но расширение должно быть WCX.

Содержание файла параметров должно быть примерно таким:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
<workspace name=”Удалённые приложения RemoteApp”
xmlns=”http://schemas.microsoft.com/ts/2008/09/tswcx”
xmlns:xs=”http://www.w3.org/2001/XMLSchema”>
<defaultFeed url=”https://rdwh.domain.local/RDWeb/Feed/webfeed.aspx”/>
</workspace>

Оранжевым цветом подсвечены параметры имени рабочей области и ссылки для веб-доступа к приложениям.

После того, как файл скрипта сохранён и файл параметров настроен, перейдём к созданию групповой политики. Для этого перейдём в узел Конфигурация пользователя Политики Конфигурация Windows Сценарии Вход в систему и в окне добавления скрипта перейдём на вкладку Сценарии PowerShell.

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

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

ДОСТУП К ПРИЛОЖЕНИЯМ REMOTEAPP ИЗ WINDOWS XP

Тем клиентам, у которых до сих пор установлена Windows XP, штатно доставлять приложения предлагается только средствами веб-доступа. Однако же, никто не запрещает самому создавать RDP-файлы и распространять их. Сразу же возникает вполне резонный вопрос — где же их взять?

Ну во-первых, можно забрать с любого компьютера с Windows 7/8/8.1 из папки %APPDATA%RoamingMicrosoftWorkspaces{GUID}Resource. Во-вторых, в том случае, если позаимствовать файлы неоткуда, то можно скачать их со страницы веб-доступа используя для этого браузер отличный от IE или же в самом IE отключив использование всех элементов ActiveX.

Для того, чтобы Windows XP могла взаимодействовать с фермой RDS необходимо обновить клиент RDC до седьмой версии, включить поддержку NLA и установить .NET Framework 3.5 SP1, если необходимо использовать технологию EasyPrint. Если у вас развёрнут только один сервер RDS, то обновлять клиент RDC не обязательно.

Напомню, что для того чтобы включить поддержку NLA на клиентской машине с Windows XP SP3  можно использовать Microsoft Fix it 50588 либо внести необходимые изменения в реестр вручную, как описано тут.

***

Как мы видим, использовать удалённые приложения RemoteApp можно на всех современных клиентских платформах Windows. Конечно, на более современных Windows 7, Windows 8/8.1 и Windows RT  развёртывание таких приложений значительно менее трудоёмкий процесс, но и на устаревшей Windows XP всё ещё возможно запускать приложения RemoteApp. Не без глюков, конечно, но об этом как-нибудь в другой раз.

Источник: https://beardedsysadmin.wordpress.com/2014/02/10/rds-delivery-remoteapps/

http://wininfo.org.ua/windows-8/nastroyka-sistemy-8/3624-nastroyka-i-ispolzovanie-remoteapp-2012-r2.html

Службы удаленных рабочих столов Microsoft [RDS] позволяют пользователям получать удаленный доступ к централизованным приложениям и рабочим станциям в центре обработки данных. Microsoft RDS – это новый расширенный и переименованный в Microsoft Terminal Services. В этом посте я задокументирую реализацию RDS в моей домашней лаборатории с использованием конфигурации «все в одном».

Серия блогов vBoring:

1. Настройка служб удаленных рабочих столов в Windows Server 2012 R2
2. Настройка роли лицензирования удаленных рабочих столов в Windows Server 2012 R2
3. Настройка шлюза удаленных рабочих столов Роль в Windows Server 2012 R2

Роли сервера в RDS:

Есть три основные роли для настройки RDS и следующие:

• Узел сеанса удаленного рабочего стола [RDSH]: Приложения устанавливаются и публикуются с серверов узла сеанса.
• Посредник подключений к удаленному рабочему столу [RDCB]: Эта роль обрабатывает пользовательские сеансы путем балансировки нагрузки между серверами узла сеансов удаленных рабочих столов. Также позволяет отключенным пользователям повторно подключаться к своим существующим сеансам без запуска нового.
• Веб-доступ к удаленному рабочему столу [RDWA]: Эта роль предоставляет веб-портал для доступа среда RDS. Также позволяет подключаться к рабочим столам Windows 7 и 8 с помощью RemoteApp и подключения к рабочему столу.

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

• Шлюз удаленного рабочего стола [RDG]: Эта роль позволяет удаленным пользователям использовать протокол удаленного рабочего стола (RDP) через HTTPS. Он размещается на краю вашей сети и действует как точка входа в вашу среду RDS извне.
• Узел виртуализации удаленного рабочего стола [RDVH]: Это позволяет RDS интеграция с гипервизором Hyper-V для управления виртуальными рабочими столами.
• Лицензирование : RDS поставляется с 120-дневным пробным периодом. Когда пробный период закончится, RDS больше не будет принимать соединения. Роль RDS License обрабатывает лицензирование для RDS.

Дополнительные сведения о ролях для RDS см. В обзоре Microsoft RDS

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

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

Для моей документации я использовал один сервер, называемый настройкой Quick Start .. Чтобы запустить, откройте Диспетчер серверов , затем нажмите Диспетчер -> Добавить роли и компоненты

Нажмите

Измените выбор на Установка служб удаленного рабочего стола , затем нажмите Далее

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

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

Мы настраиваем публикацию приложений. Измените выбор на Рабочий стол на основе сеанса развертывание и нажмите

Поскольку мы выбрали Быстрый запуск, роли брокера подключений, веб-доступа и узла сеанса будут установлены на одном сервере. Нажмите

Установите флажок Автоматически перезагружать целевой сервер, если требуется , затем нажмите

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

По завершении нажмите Закрыть. Службы удаленного рабочего стола теперь установлены!

Приложения для публикации: –

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

Если вы прошли быструю настройку RDS, он будет создайте коллекцию под названием « QuickCollection », которая содержит приложения Wordpad, MS Paint и Calculator.

Чтобы добавить приложения в коллекцию, нажмите Задачи -> Опубликовать программы RemoteApp

Он просканирует ваш RDSH на наличие установленных приложений и отобразит их в список. У меня установлен vSphere Client, выберите ваше приложение и нажмите

Подтвердите выбранные вами приложения и нажмите

Нажмите Закрыть , чтобы завершить процесс публикации

Глобальные разрешения RemoteApp:

По умолчанию QuickSessionCollection предоставляет всем пользователям домена доступ к программам удаленного приложения. Чтобы изменить это, нажмите Задачи -> Изменить свойства

Щелкните Группы пользователей. Если вы хотите добавить или удалить пользователей, щелкните Добавить и выполните поиск.

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

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

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

Разрешения программы RemoteApp:

Если вы хотите изменить внутренние разрешения RemoteApp, выберите приложение -> щелкните правой кнопкой мыши и выберите Изменить свойства

Щелкните Назначение пользователя -> затем измените значение параметра на Только указанные пользователи и группы . Теперь вы можете Добавить и Удалить разрешения, унаследованные от коллекции. В моем примере я хотел, чтобы только моя группа AD VMware Admins имела разрешение на vSphere Client. Нажмите Применить и Ok , чтобы сохранить изменения.

Доступ к программам RemoteApp через веб-доступ:

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

https://FQDN-or-IP-Address-of-RDWA-server/RDweb

После входа в систему вы будете просматривать приложения, к которым у вас есть доступ. Если вы прошли быструю настройку RDS, будет создана «Коллекция», содержащая калькулятор, MS Paint и Wordpad. Щелкните приложение, чтобы запустить его. Если вы получили сообщение об ошибке сертификата, нажмите Продолжить .

Приложение должно запуститься! Если вы перейдете в Help -> About, вы увидите Server 2012 вместо локальной ОС. Приложение запущено на сервере RDSH и просматривает его только через RDS.

Продолжить чтение – Часть 2: Настройка роли лицензирования удаленных рабочих столов в Windows Server 2012 R2

По теме

---

красивое описание

Ответ

---

Допустимо ли иметь шлюз также выполняет роль лицензирования?

Ответ

---

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

Ответьте

---

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

Ответ

---

Можете ли вы добавить сервер/серверы W2k16 RDS в ферму W2k12 R2 RDS ?

Ответить

---

---

Настройка терминального сервера в Windows server 2012 r2

Установка терминального сервера Windows server 2012 r2

Хотите купить Windows Server 2012 r2? Тогда вам сюда! Сразу скажу, что решение от Microsoft сильно удивило меня своей продуманной стратегией, которая отражена на картинке ниже. Похожесть на решение от Citrix бросается в глаза, но почему бы не тянуться за лидером… Итак, начну с того, что теперь вся эта концепция тоже называется виртуализация рабочих мест. По идее разработчиков, на рабочем месте сотрудника находиться как можно меньше корпоративной информации, запускаться как можно меньше программ. В идеале вместо системного блока с обратной стороны монитора крепится тонкий клиент , который на экране передается изображение с серверов. В таком случае вероятность потери данных или поломки чего-либо на рабочем месте сводится к минимуму.

Куда подключаться пользователю?

Существуют два способа подключения к виртуальному рабочему столу, которые мы сейчас с вами и рассмотрим. Первый сценарий RD Virtualization host – его принцип заключается в том, что подключение к виртуальной машине для каждого пользователя выполняется по протоколу RDP 7.1 или выше. Сама виртуальная машина при этом запускается на гипервизоре Hyper V, установленном на сервере. Использование технологии RemoteFX от Microsoft позволяет повысить быстродействие работы данной машины. Технология RD Virtualization Host встроена в операционные системы Windows 7 и 8, а значит, у вас нет необходимости приобретать лицензию на RDP.. Для использования данного метода подключения к машине необходимо на каждого пользователя приобретать подписку за 110 $ в год.

О следующей сцене как раз-таки и пойдет речь в данной статье. Он называется RD Session host , и при выполнении данного сценария, все процессы, которые пользователи видят на своем мониторе, на самом деле существует на сервере хост удаленного рабочего стола. При этом у пользователя на выбор есть два способа удаленного запуска приложений: либо через браузер, либо через ярлыки на рабочем столе. При этом вы сможете использовать самое стандартное подключение к удаленному рабочему столу сервера. При этой работе с Windows server 2012 r2 будет интуитивно понятна, как по интерфейсу он в целом похож на Windows 8.

Установка

Для установки используется свежеустановленная Windows server 2012 Beta и статья- руководство на технет. Как обычно, все идет не так как написано в мануале. 1 .. Входим в Server Manager. Справа вверху выбираем Управление -> Добавить роли и функции. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Установка служб удаленных рабочих столов

2 .. Для одного сервера, выбираем Quick Start. Мастер обещает установку сервиса удаленных рабочих столов, настройку программ Collection и RemoteApp.

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

4 .. По сценарию на наш сервер будут добавлены следующие серверные роли: Посредник подключений к удаленному рабочему столу – контроль подключенных пользователей, укажите для какого пользователя на каком сервере будет открыта сессия или запущено приложение Web Access – доступ к приложениям через веб-браузер RD session Хост-сервер, на котором могут быть опубликованы приложения, смог подключиться через удаленный рабочий стол. Если инфраструктура у вас большая или вам нужна отказоустойчивость, то необходимо дублировать серверы с данными ролями, изначально создавалось как кластерное решение.

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

6 .. Чтобы завершить установку в ручную, выбираем в Server Manager вкладку управления ролью Службы удаленного рабочего стола

7 .. Там видим еще одно графическое представление системы установки. Первые два пункта у нас выполнены.

8 .. Кликаем по третьему пункту, Создать коллекцию сессий. Запускается мастер создания.

9 .. Придумываем название для Session Collection

10 .. Выбираем наш сервер, в качестве хоста сеанса RD

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

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

13 .. Вот теперь установка закончилась удачно.

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

15 .. Находим раздел ПРОГРАММЫ REMOTEAPP и выбираем Публикуем программы RemoteApp.

16 .. Появляется выпадающий список программ, которые доступны на сервере. Среди них нет Internet Explorer, но его можно добавить здесь же в ручном режиме, если нажать на Add. Выбираем понравившиеся приложения галочками.

17 .. Подтверждаем, что не ошиблись в выборе.

18 .. Дальше сам Windows server 2012 r2 подсказок не дает. Как бы понятно, что нужно подключиться, но что для этого нужно сделать… обращаемся к статье на TechNet.

19 .. Открываем браузер на компьютере пользователя, и заходим по адресу, в моем случае, https://rdp2012.azon.local/RDweb вводим данные пользователя, который входит в группу Пользователи домена.

20 .. После авторизации попадаем на страницу с опубликованными приложениями.

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

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

23 .. Для проверки плавности хода курсора рисую мышкой круг, очень хорошо. Вообще, протокол RDP 7.1 избавлен от проблем прошлых версий. Я, например, подключаюсь по нему к своей рабочей машине. Браузер с flash, почта, редакторы работают шустро.

На этой первой части статьи, можно считать законченной. Во второй части будем настраивать Сценарий Хост виртуализации удаленных рабочих столов.

Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
— Среда исполнения
— Подготавливаем виртуальные сервера
— Создаём кластер NLB
— Подготавливаем SQL Server
— Устанавливаем роли Remote Desktop Services
— Создаём высоко-доступный RD Connection Broker
— Добавляем сервера в высоко-доступный RD Connection Broker
— Добавляем на сервера роль RD Web Access
— Создаём коллекцию сеансов – Session Collection
— Настраиваем цифровые сертификаты
— Настраиваем веб-узлы RD Web Access
— Настраиваем Roaming User Profiles и Folder Redirection
— Публикуем приложения RemoteApp
— Устанавливаем языковой пакет
— Настраиваем перенаправление печати

Среда исполнения

В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN.

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

Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25

Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB.

База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL 

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

Подготавливаем виртуальные сервера

Итак, у каждого виртуального сервера создадим по 2 сетевых адаптера. Назовём их условно на каждом сервере таким образом, чтобы было понятно за что отвечает этот интерфейс — NIC1 (Management) и NIC2 (NLB Cluster).

При создании второго сетевого адаптера NIC2, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)

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

Имя сервера	Настройки IP NIC1	Настройки IP NIC2 (NLB Cluster)
KOM-AD01-RDS21	IP 10.160.0.151/24	IP 10.160.0.141/24
KOM-AD01-RDS22	IP 10.160.0.152/24	IP 10.160.0.142/24
KOM-AD01-RDS23	IP 10.160.0.153/24	IP 10.160.0.143/24
KOM-AD01-RDS24	IP 10.160.0.154/24	IP 10.160.0.144/24
KOM-AD01-RDS25	IP 10.160.0.155/24	IP 10.160.0.145/24

На всех интерфейсах используются одинаковые настройки адреса шлюза по умолчанию -10.160.0.254 и адресов DNS — 10.160.0.253, 10.160.1.253. Причина использования именно такой сетевой конфигурации для построения NLB на базе Windows Server 2012 была ранее изложена в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности

Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-RDS21

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

NIC1 должен иметь приоритет над NIC2.

В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:

В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advanced откроем окно дополнительных настроек

В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS:

Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks

После того как описанным способом настроены сетевые интерфейсы на всех серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell 

Дополнительно сразу же создаём статическую А-запись для будущего NLB кластера.

RD Connection Broker использует для хранения БД сессий общий экземпляр SQL Server, поэтому все сервера RDCB должны иметь «на борту» клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер, где планируется развертывание RD Connection Broker, свежую версию пакета Microsoft SQL Server 2012 Native Client (в нашем случае установка нужна на всех пяти виртуальных серверах). Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл sqlncli.msi)

После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения серверов RDCB к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:windowssystem32cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN

Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLMSOFTWAREMicrosoftMSSQLServerClientConnectTo

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.

***

Далее, с помощью PowerShell установим на каждый сервер исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

Создаём кластер NLB

На первом виртуальном сервере (KOM-AD01-RDS21) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 443 – для подключения клиентов к RD Web Access;
TCP/UDP 3389 – для подключения клиентов к RD Connection Broker/Session Host;

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

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго и последующих серверов в кластер.

В конечном итоге после добавления (по аналогии с первым узлом) всех серверов мы получим работоспособный Windows NLB кластер

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

Подготавливаем SQL Server

Создадим в AD группу безопасности, например KOM-AD01-RDS-Connection-Broker-Computers, и включим в нее учетные записи наших виртуальных серверов.

После этого подключимся к экземпляру SQL Server на котором будет размещаться БД RDCB (в нашем случае это отдельный кластер SQL Server из двух серверов), создадим новый SQL Login с привязкой к указанной доменной группе. При создании SQL-логина ему будет присвоена серверная роль SQL Server – public, которая даст право подключаться к экземпляру SQL Server. Включим ещё одну серверную роль – dbcreator. Эта роль понадобится нам лишь на время первоначальной инициализации БД RDCB для того, чтобы учетная запись сервера, на котором мы будем запускать процесс создания отказоустойчивого RDCB, смогла выполнить операцию создания новой БД.

Дополнительно на SQL сервере создадим каталог для файлов базы данных RDCB. В нашем случае это будет каталог U:SQLData_SQL01_RDCB на кластерном диске SQL сервера.

Устанавливаем роли Remote Desktop Services

Так как консоль Server Manager в Windows Server 2012 поддерживает групповую настройку сразу нескольких серверов, перед тем как разворачивать на наши виртуальные сервера роли RDS, объединим их в логическую группу. На любом из виртуальных серверов, например на KOM-AD01-RDS21, откроем консоль Server Manager и выберем пункт меню Manage > Create Server Group

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

После этого выберем пункт меню Manage > Add Roles and Features Wizard

В открывшемся мастере добавления ролей выберем режим установки служб RDS — Remote Desktop Services installation

 

  Тип развёртывания — Standard deployment

Сценарий развертывания выбираем Session-based desktop deployment, так как планируется развертывание серверов сеансов, а не серверов инфраструктуры VDI 

На этапе выбора ролей RDS нас предупредят о том, что будет выполняться развертывание сразу трёх ролей —  RD Connection Broker, RD Session Host, RD Web Access, не оставляя при этом нам никакого выбора…

На этапе выбора серверов для роли RD Connection Broker выбираем один сервер, ибо мастер не даст нам выбрать более одного сервера. Так как всю первоначальную настройку мы выполняем на сервере KOM-AD01-RDS21, то соответственно и выберем его для этой роли…

На этапе выбора серверов для роли RD Web Access включим опцию Install the RD Web Access role on the RD Connection Broker server для того чтобы эта роль была установлена на тот же сервер, который был выбран для роли RDCB. Выбирать какой-то другой сервер в нашей ситуации особого смысла нет, да и потом мастер опять таки не даст нам выбрать для установки этой роли более чем один сервер…

На этапе выбора серверов для роли RD Session Host мы сможем выбрать все сервера…

 
На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Включим опцию автоматической перезагрузки серверов — Restart the destination server automatically if required и запустим процесс развёртывания..

В процессе установки ролей первым будет автоматически перезагружен сервер, с которого мы запустили весь этот процесс, поэтому мы отвалимся от его консоли. Пугаться не надо… После того, как система поднимется из перезагрузки, снова залогинимся и запустим консоль Server Manager, где через несколько секунд автоматически запустится мастер развертывания ролей RDS и мы сможем убедиться в том, что процесс развертывания успешно прошёл до конца на всех серверах.

В нашем примере мастер сообщил о том, что на двух серверах из пяти не удалось установить службу RDSH, хотя последующая проверка этих серверов свидетельствовала об обратном. В системном журнале Applications and Services Logs > Microsoft > Windows > ServerManager-DeploymentProvider > Operational было зарегистрировано событие говорящее об успешной установке компонент…

Ну и соответственно PS-запрос состояния компонент RDS показывал что роль RDSH установлена..

В любом случае если Server Manager упорно будет говорить вам о том, что роль RD Session Host не установлена на каких-то серверах, то для того чтобы заставить её «прокашляться», можно повторить процедуру установки через мастер добавления ролей RDS на вкладке управления службами Remote Desktop Services > Overview

Создаём высоко-доступный RD Connection Broker

После окончания процесса установки ролей в консоли Server Manager и перейдём на вкладку управления службами Remote Desktop Services > Overview, чтобы приступить к созданию отказоустойчивой конфигурации RD Connection Broker.

На схеме инфраструктуры RDS выберем изображение роли RD Connection Broker и правой кнопкой мыши вызовем меню, в котором выберем пункт Configure High Availability.

Запустится мастер создания высоко-доступного экземпляра RDCB, где нас предупредят о необходимых условиях, которые мы уже предварительно выполнили, за исключением последнего пункта, который предполагает создание в DNS A-записей c одинаковым FQDN именем RDCB и IP адресами всех серверов (для работы механизма Round Robin). Откажемся от концепции использования DNS Round Robin для получения клиентами имени точки подключения к ферме RDCB. Вместо этого мы будем использовать имя созданного ранее NLB кластера.

На следующем шаге мастера Configure High Availability заполняем значения трёх полей:

Database connection string – строка подключения к БД SQL Server. Значение должно иметь вид: DRIVER=SQL Server Native Client 11.0 (10.50 для SQL Server 2008 R2);SERVER=<FQDN-Имя или SQL-Alias сервера SQL Server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<Имя БД>

В нашем случае это значение будет иметь следующий вид:

DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker

Folder to store database files — путь ранее подготовленного каталога U:SQLData_SQL01_RDCB на кластерном диске SQL сервера. В этом каталоге будут размещены файл данных и лога транзакций SQL Server при создании БД RDCB.

DNS round robin name – имя точки подключения клиентов. Как я уже сказал, здесь предполагается ввод значения FQDN-имени созданного в DNS с несколькими A-записями. В нашем примере, в качестве такого имени, мы будем использовать имя созданного ранее NLB кластера – KOM-AD01-RDSNLB.holding.com

Далее мы получим предупреждение о том, что указанное нами имя DNS RR имеет отличный IP адрес от того, для которого выполняется установка HA RDCB. Мы идём на этот шаг намеренно и поэтому соглашаемся…

Дожидаемся успешного окончания процесса конфигурирования высокой доступности.

В ходе этого процесса на SQL-сервере будет создана БД высоко-доступного экземпляра RDCB.

***

Переключимся на наш SQL Server с только что созданной БД и выполним пару настроек…

В обязательном порядке для SQL-логина, который мы создавали на подготовительном этапе (KOM-AD01-RDS-Connection-Broker-Computers), нужно дать роль db_owner для созданной базы RDS_ConnectionBroker

Помимо этого, для данного SQL-логина можно отключить добавленную ранее серверную роль dbcreator, так как БД уже создана и больше данная привилегия этому SQL-логину не потребуется.

Если резервное копирование баз данных SQL Server выполняется такими инструментами как например SC 2012 DPM, то при желании мы можем поменять модель восстановления созданной БД (Recovery Model) c Full на Simple.

***

Вернёмся на наш сервер KOM-AD01-RDS21 и обратим внимание на то, что в консоли Server Manager в схеме инфраструктуры RDS статус роли RDCB поменялся на High Availability Mode

Теперь для того чтобы задуманная нами связка NLB + RDCB работала так как нужно, нам необходимо до-установить роль RD Connection Broker на оставшиеся четыре сервера.

Добавляем сервера в высоко-доступный RD Connection Broker

Добавление серверов к высоко-доступной конфигурации RDCB делается через то же самое контекстное меню в схеме развертывания RDS на странице Overview.

В открывшемся мастере добавляем следующий сервер (мастер также не даст добавить более одного сервера)

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

Аналогичным образом мы по одному серверу должны добавить роль HA RDCB на все оставшиеся сервера, те. KOM-AD01-RDS23, KOM-AD01-RDS24 и KOM-AD01-RDS25.

Добавляем на сервера роль RD Web Access

Так как мы хотим иметь отказоустойчивую конфигурацию роли RD Web Access, нам нужно до-установить эту роль на оставшиеся четыре сервера (на KOM-AD01-RDS21 эта роль уже установлена). Делаем это в уже знакомом нам месте через мастер добавления ролей

Здесь уже мы сможем выбрать сразу все серверы и выполнить установку роли RDWA оптом…

Создаём коллекцию сеансов – Session Collection

Все наши сервера с ролью RD Session Host мы должны объединить в логическую единицу – коллекцию сеансов (Session Collection). Делаем это в оснастке Server Manager на вкладке Remote Desktop Services > Collections выбрав задачу Create Session Collection в таблице перечисления коллекций.

В открывшемся мастере создания коллекции зададим имя коллекции и при желании описание

Затем выбираем все сервера, которые хотим сделать членами коллекции…

Далее мы должны определить доменную группу безопасности которой будет разрешено подключаться к коллекции сеансов. Убираем выбранную по умолчанию группу доступа Domain Users и добавляем специально созданную группу доступа, в нашем случае KOM-AD01-RDS-AllUsers, ограничив тем самым круг пользователей которые смогут подключаться к серверам коллекции.

На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей — Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке.

А пока не будут разрешены имеющиеся на данный момент проблемы с UPD будем использовать связку технологий Roaming User Profiles и Folder Redirection, настройка которых рассматривалась ранее в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки 

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

Настраиваем цифровые сертификаты

При попытке подключения к ферме RD Connection Broker по FQDN-имени кластера NLB клиенты могут получать предупреждение безопасности, говорящее о том, что нет доверия сертификату того сервера сеансов, на который он был перенаправлен. Если открыть свойства этого сертификата, мы увидим, что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным. Чтобы избежать таких предупреждений нам нужно создать для развёртывания RDS сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС. Этот сертификат после создания мы развернём на всех серверах фермы.

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

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

Хотя в нашей ситуации альтернативные имена в сертификате Subject Alternative Name (SAN) иметь вовсе необязательно, я всё-таки рассмотрю вариант создания именно такого сертификата, то есть чтобы помимо имени NLB кластера в сертификате содержались имена отдельных серверов.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. О том как это сделать можно прочитать в заметке Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-RDSNLB.holding.com" ; 
Exportable = TRUE; Private key is exportable 
KeyLength = 2048 
KeySpec = 1; Key Exchange – Required for encryption 
KeyUsage = 0xA0; Digital Signature, Key Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication 
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-RDSNLB.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS21.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS22.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS23.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS24.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS25.holding.com&" 
_continue_ = "dns=KOM-AD01-RDSNLB&" 
_continue_ = "dns=KOM-AD01-RDS21&" 
_continue_ = "dns=KOM-AD01-RDS22&" 
_continue_ = "dns=KOM-AD01-RDS23&" 
_continue_ = "dns=KOM-AD01-RDS24&" 
_continue_ = "dns=KOM-AD01-RDS25&"

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

cd /d C:Temp
CertReq –New RequestPolicy.inf RequestFile.req

Выполнять эту команду надо локально на сервере RDS. В нашем случае команда выполняется на сервере KOM-AD01-RDS21. После выполнения команды откроем консоль управления локальными сертификатами (mmc.exe > Add/Remove snap-in > Certificates > Add > Computer account) для хранилища Local Computer и убедимся в появлении ожидающего запроса в разделе Certificate Enrollment Request

Полученный файл запроса RequestFile.req добавляем в локальный центр сертификации через консоль управления Certification Authority (certsrv.msc) (All Tasks > Submit new request)

Затем в этой же консоли в разделе Pending Requests проверяем наш добавленный запрос и разрешаем выдачу сертификата по нему (Выбираем запрос > All Tasks > Issue )

Переходим в раздел выданных сертификатов — Issued Certificates, находим сертификат, открываем его свойства и на закладке Details вызываем мастер экспорта сертификата (Copy to File)

В открывшемся мастере выбираем формат экспорта DER X.509 и сохраняем файл например с именем NLBCert.cer

Скопируем полученный файл NLBCert.cer на сервер RDS, где мы создавали запрос на сертификат (KOM-AD01-RDS21) и вернёмся в консоль управления локальными сертификатами этого сервера. Выберем хранилище Personal > Certificates и вызовем мастер импорта сертификатов (All Tasks > Import)

В мастере импорта автоматически будет выбрано хранилище Local Machine

Далее выберем импортируемый файл сертификата NLBCert.cer и укажем раздел хранилища PersonalRegistry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.

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

Далее выбираем установленный сертификат и вызываем мастер экспорта (All Task > Export). В мастере экспорта выбираем опцию экспорта закрытого ключа при экспорте сертификата – Yes, export the private key

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

Далее задаем пароль (он потребуется нам в дальнейшем для назначения этого сертификата в развёртывании RDS)

После того как сертификат экспортирован, переходим в консоль Server ManagerRemote Desktop ServicesOverview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (TASKS > Edit Deployment Properties)

На вкладке Certificates используем кнопку Select existing cerificates для того чтобы назначить сделанный нами сертификат для той или иной роли RDS…

В окне выбора сертификата определяем, что мы хотим использовать файл PFX полученный нами ранее и задаём пароль с которым этот сертификат был экспортирован. Хотя опция Allow the certificate to be added to the Trusted Root CA нам по сути не нужна, так как созданный нами сертификат сделан в ЦС, которому предположительно все наши сервера уже доверяют, её всё таки придётся отметить, так как если она не отмечена, кнопка OK недоступна…

После закрытия этого окна по ОК, мы увидим что в таблице статус сертификата изменился на Ready to apply..Нажмём кнопку Apply и через несколько секунд наш сертификат будет назначен роли соответствующей RDS. Описанным методом мы выполним привязку сертификатов ко всем развёрнутым у нас ролям и в конечном итоге получим примерно следующий вид:

Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.

Настраиваем веб-узлы RD Web Access

По умолчанию при обращении в стартовой веб-странице RDWA от пользователя в явном виде требуется ввод учетной записи и пароля. Если мы используем RDWA для доменных пользователей внутри локальной сети, то для удобства нам нужно будет задействовать механизм прозрачного входа Single sign-on (SSO) при обращении к веб-узлу RDWA. Для этого на каждом сервере с установленной ролью RDWA в оснастке IIS Manager откроем свойства веб-приложения RDWeb > Pages выберем в разделе настроек пункт Authentication…выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication:

***

После входа на веб-страницу RDWA можно обнаружить уже знакомый нам по предыдущей версии опцию I am using a private computer that complies with my organization’s security policy (в русском варианте — Я использую личный компьютер, соответствующий политике безопасности моей организации).

Ранее, в заметке RDS Web Access – Опция «Я использую личный компьютер…», я писал о том, как выставить эту опцию во включенное состояние по умолчанию, чтобы избежать повторного запроса аутентификации при подключении к опубликованным приложениям RemoteApp в Windows Server 2008 R2. Это рецепт работает и для Windows Server 2012.

***

Верхняя часть страниц RDWA по умолчанию оформлена в виде заголовочной надписи Work Resources и изображения размером 48*48 пикселей.

Для того чтобы заменить заголовочную надпись можно использовать командлет PowerShell (один раз для всей коллекции серверов):

Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com

 

Для того чтобы заменить имеющееся изображение на другое, например с корпоративной символикой, можно внести корректировки в файл %windir%WebRDWebPagesSite.xsl – найти секцию с комментарием «Replaceable Company Logo Image«…

… и заменить ссылку на файл изображения, указав собственный файл размещённый в соответствующем подкаталоге %windir%WebRDWebPagesimages

В результате мы получим примерно следующий вид верхней части страниц RDWA:

Настраиваем Roaming User Profiles и Folder Redirection

Так как пользователи нашей фермы RDS от сеанса к сеансу могут попадать на разные сервера, нам необходимо обеспечить идентичность пользовательской среды на всех этих серверах. Для этого мы будем использовать механизмы перемещаемых профилей (Roaming User Profiles ) и перенаправления папок (Folder Redirection). Для настройки этих механизмов настраиваем групповую политику применяемую к серверам нашей фермы RDS. Здесь мы не будем рассматривать эту процедуру, так как она уже была ранее описана мной в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки

Публикуем приложения RemoteApp

Чтобы опубликовать в ферме RDS приложения RemoteApp переходим в консоль Server Manager в раздел Remote Desktop Services > Collections > выбираем нашу коллекцию KOM-AD01-RDSH-COLL и публикуем необходимые приложения в окне REMOTEAPP PROGRAMS. В меню задач выбираем пункт публикации TASKS > Publish RemoteApp Programs

Для примера опубликуем два простых приложения Calculator и WordPad

 
Опубликованные приложения доступны клиентам нашей фермы RDS двумя основными способами – через веб-интерфейс RD Web Access и через непосредственную доставку ярлыков запуска на клиентские компьютеры. С первым способом, полагаю, всё итак понятно, рассмотрим второй. Для того чтобы ярлыки опубликованных приложений RemoteApp стали доступны на клиенте с Windows 7/8, нужно выполнить подписку на узел RDWA в Панели управления (апплет Подключения к удаленным рабочим столам и приложениям RemoteApp). Щелкнув по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам мы вызовем мастер подключения, где в адресной строке укажем URL RDWA в формате http://KOM-AD01-RDSNLB.holding.com/RDWeb/Feed/WebFeed.aspx

В примерах описанных в окне подключения можно заметить вариант с указанием адреса, похожего на адрес электронной почты —  alexeyo@contoso.com. На самом деле такой метод указания адреса не столько имеет отношение к электронной почте, сколько относится к методу автоматического обнаружения сервера публикации RemoteApp с помощью специальных записей в зоне прямого просмотра DNS. То есть мастеру подключения важно лишь то, что указано после символа @ – имя зоны DNS. До символа @ можно написать любую ерунду. Например, в нашем примере в DNS используется зона holding.com и в качестве адреса мы можем указать например blablabla@holding.com

В зоне DNS соответственно при использовании такого метода должна быть создана специальная запись формата TXT c именем _msradc и текстовым значением в формате https://rds.domain.com/rdweb/feed 
Соответственно в нашем примере запись будет иметь следующий вид:

После того как запись создана, проверим то, что DNS сервер возвращает нам значение этой записи с помощью утилиты nslookup в режиме set querytype=TXT и если всё в порядке, то теперь в качестве адреса подключения можем указать соответствующее значение

При этом из DNS будет возвращён URL-адрес подключения…

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

При этом в меню “Пуск” для Windows 7 и в стартовом экране для Windows 8 в отдельной группе появятся ярлыки на запуск приложений RemoteApp

Если вам потребуется каким-то альтернативным способом распространять ярлыки на приложения RemoteApp, то их можно будет найти на клиентской машине подключённой вышеописанным способом к точке публикации RDWA в каталоге
%APPDATA%MicrosoftWorkspaces{GUID}Resource

Нововведением Windows 8 стал ещё один способ подключения клиентов к точке публикации – с помощью групповых политик (GPO). За это отвечает параметр
Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections. Для настройки клиентов нужно включить этот параметр и указать значение URL-адреса подключения в формате:
https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx

Как я уже сказал, этот параметр поможет нам настроить только клиентов Windows 8, но если у вас есть сильное желание раздать через GPO настройку и для клиентов Windows 7 – читайте статью Concurrency Blog — How to deliver RemoteApps from Windows Server 2012 RDS. Метод заключается в применении на клиентских машинах PowerShell скрипта Configure RemoteApp and Desktop Connection on Windows 7 Clients с передачей ему в виде параметра файла настроек в следующем формате:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<workspace name="Enterprise Remote Access" xmlns="http://schemas.microsoft.com/ts/2008/09/tswcx" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<defaultFeed url="https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx" />
</workspace>

Устанавливаем языковой пакет

Так как в нашем примере на серверах фермы RDS используется англоязычная система, нам потребуется установка языкового пакета для локализации интерфейса пользователя. Чтобы получить файлы русского языкового пакета распаковываем образ содержащий все языковые пакеты для Windows Server 2012 RTM SW_DVD5_NTRL_Win_Svr_Language_Pack_2012_64Bit_MultiLang_FPP_VL_OEM_X18-27741.ISO

Извлекаем файл langpacksru-rulp.cab из состава образа и вызываем на сервере RDS мастер установки языковых пакетов командой lpksetup

Помимо этого установку языкового пакета можно выполнить командой:

Dism /online /Add-Package /PackagePath:"C:DistributivesWS2012RTMLanguagePacklp.cab"

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

Далее открываем апплет панели управления Control Panel > Region (intl.cpl) , проверяем и при необходимости настраиваем параметры на родной язык на закладках Formats и Locations , а затем на закладке Administrative нажимаем Copy settings, чтобы скопировать языковые предпочтения текущего пользователя для всех пользователей которые будут первый раз входить в эту систему.

Убедимся что у текущего пользователя установлены такие настройки, которые мы хотим иметь у всех пользователей сервера RDS и включим галочку New user accounts

Не рекомендую использовать опцию копирования русских настроек в системный профиль (галка Welcome screen and system accounts), так как это в перспективе может привести к невменяемой работе некоторых “буржуйских” программ, проблемы в которых возникают чаще всего из-за знака разделителя целой и дробной части.

Настраиваем перенаправление печати

Для того чтобы пользователи служб удалённых рабочих столов смогли выполнять печать на перенаправленные с их клиентских мест устройств печати, выполним ряд нехитрых манипуляций.
Установим на сервера RDS консоль управления службой печати – Print Management, например с помощью PowerShell:

Add-WindowsFeature RSAT-Print-Services

Если есть сильное желание управлять службой печати на всех серверах например с рабочей станции Администратора, то для того, чтобы можно было удалённо подключаться к службе печати, на серверах необходимо включить параметр групповой политики Allow Print Spooler to accept client connections в разделе Computer ConfigurationPoliciesAdministrative TemplatesPrinters. После применения политики на серверах нужно перезапустить службу очереди печати — Print Spooler.
На мой взгляд использовать локально установленную на серверах консоль – более предпочтительно.

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

К слову об использовании именно локальной консоли…эти две опции недоступны для изменения (попросту не видны) если вы подключаетесь консолью удалённо.

На закладке Drivers добавляем драйвера принтеров, которые используются для печати на клиентских компьютерах. Драйвера принтеров нужно добавлять исходя из принципа разумного минимума. Например вместо того чтобы для принтеров Hewlett-Packard добавлять несколько драйверов для конкретных моделей лучше добавить один универсальный драйвер HP Universal Print Driver (UPD), в случае если принтеры поддерживают работу на данном драйвере. В нашем примере используется текущая версия (на момент написания этой заметки) UPD совместимая с Windows Server 2012 — 5.6.5.15717. Разумеется добавлять драйвера производителей оборудования вообще имеет резон только в том случае если тесты показывают, что принтер не выполняет поставленные задачи печати на драйвере Remote Desktop Easy Print.

В конфигурации по умолчанию для принтеров перенаправляемых с пользовательских компьютеров система будет использовать драйвер Remote Desktop Easy Print. Если мы загружаем на сервера RDS драйвера производителей принтеров, как например тот же HP UPD, то возможно нам стоит переопределить такое поведение, то есть, чтобы приоритетным для использования считался драйвер вендора железки, а уж если его не удалось найти – использовать RD Easy Print. Задаётся это параметром групповой политики Use Remote Desktop Easy Print printer driver first = Disabled в разделе Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostPrinter Redirection

После применения GPO в пользовательской терминальной сессии проверяем какой драйвер был назначен для перенаправленного принтера…

На этом, в целом, можно считать, что мы выполнили основные этапы создания и настройки отказоустойчивой фермы RD Connection Broker на базе Windows Server 2012. В отдельной следующей заметке мы рассмотрим пример настройки пользовательского интерфейса на сервера RD Session Host.

Полезные ссылки по теме:

Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012
VirtualizationAdmin.com — Taking a closer look at RD Connection Broker High Availability in Windows Server 2012
TechNet Articles  —  RD Connection Broker HA – SQL Permissions
Freek Berson Blog — RD Connection Broker HA and the RDP properties on the client
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 1)
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 2)

08-Windows Server 2012 R2 сеанс удаленный рабочий стол — стандартное развертывание — использование PowerShell для развертывания 2-1

Ма Бофенг

PowerShell всегда был важной частью продуктов Microsoft Windows Server. Вы можете использовать PowerShell для завершения всех конфигураций сервера и даже некоторых вещей, которые нельзя сделать в графическом интерфейсе. С каждой новой версией продуктов или услуг Microsoft вы можете видеть, что PowerShell тесно интегрирован с этими продуктами и услугами. По сравнению с исходной PowerShell в Windows Server 2012 R2 PowerShell 4.0 более мощный и может поддерживать более 2400 Команда командлета PowerShell, это огромное количество.Администраторам также очень сложно запомнить так много команд командлета PowerShell, но большинство команд командлета PowerShell — обычные компьютерные слова, даже если память не так уж и велика. Вы можете использовать клавишу Tab для завершения ввода во время процесса ввода.Если вы столкнетесь с синтаксисом, который вы не будете использовать, вы можете получить подробную справку после параметра home-help.

One, PowerShell и Server Core

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

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

псевдоним сервера	операционная система	Настройки IP	Характеристики
AD-DC.mabofeng.com	Windows Server 2012 R2	192.168.1.100	Контроллер домена
BD-RDS.mabofeng.com	Windows Server 2012 R2 Server core	192.168.1.110	Агент подключения к удаленному рабочему столу

Поскольку Windows Server 2012 R2 использует режим установки ядра сервера, команды PowerShell должны использоваться для управления и контроля во время всех операций. У режима установки ядра сервера есть много преимуществ:

1. Снижение затрат на обслуживание: поскольку в версии Server Core пользователи устанавливают только основные роли сервера, такие как DHCP, файлы, DNS и Active Directory, что сокращает время и усилия, необходимые для обслуживания системы, по сравнению с установкой полного сервера. .

2. Уменьшение поверхности атаки: поскольку Server Core выполняет минимальное действие по установке, оно гарантирует, что на сервере работает меньше приложений, что практически снижает вероятность атаки сервера.

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

4. Снижение требований к оборудованию: для установки Server Core требуется всего около 800 МБ на жестком диске, а для быстрой установки требуется менее 500 МБ.

Режим Server Core дает много преимуществ, но эти Server Core имеют преимущества и недостатки одновременно.То есть, если вы используете серверы в режиме Server Core, из-за отсутствия графического интерфейса технический уровень администраторов Windows высок. Как правило, новички в Windows не привыкли использовать PowerShell для управления. Менеджеры, привыкшие к графическим операциям, могут по-прежнему использовать режим Server Core для развертывания серверов и использовать Server Manager для удаленного управления, чтобы они могли управлять всеми функциями Windows Server в режиме Server Core.

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

2. Используйте powershell для быстрого развертывания (RemoteApp)

Перед установкой Сервера удаленного рабочего стола с помощью PowerShell сначала давайте импортируем новый модуль RemoteDestop в Windows Server 2012R2, используя команду:

PS C:Usersadministrator.MABOFENG> import-module RemoteDesktop

Когда мы импортировали командлет RemoteDestop специально для служб удаленного рабочего стола. Следующим шагом будет использование команды powershell для развертывания сервера удаленного рабочего стола на основе сеанса. Существует два способа развертывания в службах удаленных рабочих столов в Windows Server 2012 R2. Первый — быстрое развертывание и установка на основе ролей, все роли и функции устанавливаются на одном хосте, а второй — стандартное развертывание, при котором роли в RemoteDestop развертываются на разных хостах. В графическом интерфейсе мы Мастер установки будет использоваться для установки всех необходимых ролей вместо ручной установки и настройки всех отдельных ролей.

Во-первых, давайте установим быстрое развертывание рабочего стола на основе сеанса.В этом примере мы будем моделировать среду быстрого развертывания, а также установить и развернуть все роли (узел сеанса удаленных рабочих столов, посредник подключений к удаленному рабочему столу и веб-доступ к удаленным рабочим столам) на одном сервере. При быстром развертывании рабочего стола сеанса мы в основном используем команду New-SessionDeployment. Вы можете просмотреть синтаксис этой команды через New-SessionDeployment -help.

Синтаксис: New-SessionDeployment [-ConnectionBroker] <String> [-SessionHost] <String []> [[-WebAccessServer] <String>] [<CommonParameters>]

Командлет New-RDSessionDeployment установит необходимую инфраструктуру виртуальных рабочих столов (VDI) для создания служб удаленных рабочих столов (RDS), которые являются службой ролей для развертывания удаленных рабочих столов на основе сеансов. Развертывание на основе сеансов позволяет пользователям подключаться к набору сеансов, который включает опубликованные программы RemoteApp для Windows Server 2012 R2 и рабочие столы на основе сеансов.

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

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

New-SessionDeployment -ConnectionBroker RDS.mabofeng.com -WebAccessServer RDS.mabofeng.com -SessionHost RDS.mabofeng.com

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

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

Затем система установит прокси-сервер подключения к удаленному рабочему столу.

Затем система установит сервер веб-доступа к удаленным рабочим столам.

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

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

После завершения установки PowerShell мы можем открыть консоль Server Manager на целевой машине и увидеть вкладку Remote Desktop Services, где фактически установлены три роли.

Если роль установлена ​​на одном и том же хосте в одно и то же время, в начале установки появляется сообщение об ошибке, и в PowerShell отображается, что локальный сервер не может быть перезапущен. Когда эта проблема возникает, это происходит не из-за недостаточных полномочий администратора, а из-за того, что вы находитесь в Команда развертывания powershell выполняется на целевом сервере. Сервер роли сеанса удаленных рабочих столов необходимо перезапустить во время процесса установки. Следовательно, PowerShell не может быть выключен или остановлен в процессе установки. Чтобы решить эту проблему, вам необходимо выполнить эти команды на удаленном сервере. Целевой сервер можно перезапустить.

Три, используйтеpowershellВыполнить стандартное развертывание (RemoteApp)

В дополнение к этому простому развертыванию вы также можете использовать powershell для стандартного развертывания.Стандартное развертывание может развертывать роли RDS на разных хостах, включая развертывание нескольких серверов узлов сеансов удаленных рабочих столов, но все они используют New-RDSessionDeployment.

Например, 1. Чтобы установить службу роли RDS на разных хостах, используйте команду:

PS C:> New-RDSessionDeployment -ConnectionBroker «RDCB.mabofeng.com» -WebAccessServer «RDWA.mabofeng.com» -SessionHost «RDSH01.mabofeng.com»

Эта команда установит службу роли удаленного рабочего стола на указанный сервер. Эта команда установит службу роли посредника подключений к удаленному рабочему столу на сервере с именем RDCB. Установите службу роли веб-доступа к удаленным рабочим столам на сервере с именем RDWA.mabofeng.com. Установите службу роли узла сеансов удаленных рабочих столов на сервере с именем RDSH01.

Например, 2. Установите службу роли RDS на разных хостах, включая несколько серверов Узлов сеансов удаленных рабочих столов. Используемая команда: PS C: > New-RDSessionDeployment -ConnectionBroker «RDCB.mabofeng.com» -WebAccessServer «RDWA.mabofeng.com» -SessionHost @ («RDSH01.mabofeng.com», «RDSH02.mabofeng.com»)

Эта команда установит службу роли удаленного рабочего стола на указанный сервер. Эта команда установит службу роли посредника подключений к удаленному рабочему столу на сервере с именем RDCB. Установите службу роли веб-доступа к удаленным рабочим столам на сервере с именем RDWA. Эта команда устанавливает службу роли узла сеансов удаленных рабочих столов на двух серверах с именами RDSH01.mabofeng.com и RDSH02.mabofeng.com.

В-четвертых, используйте powershell для быстрого развертывания (VDI)

Помимо использования команды powershell для развертывания службы RemoteApp на основе узла сеанса, вы также можете развернуть удаленный рабочий стол на основе виртуальной машины. Команда для создания развертывания на основе виртуальной машины — New-RDVirtualDesktopDeployment. Во-первых, давайте посмотрим на синтаксис этой команды:

Синтаксис: New-RDVirtualDesktopDeployment [-ConnectionBroker] <String> [-WebAccessServer] <String> [-VirtualizationHost] <String []> `-CreateVirtualSwitch` [<CommonParameters>]

Команда New-RDVirtualDesktopDeployment предназначена для установки виртуального рабочего стола на основе виртуальной машины (VDI). Для виртуального рабочего стола на основе виртуальной машины требуется отдельная виртуальная машина, что означает, что роль Hyper-V должна быть установлена ​​в Windows Server 2012 R2. Вы можете указать параметры создания нового виртуального коммутатора для создания общей коллекции виртуальных рабочих столов, за исключением установленных служб ролей. Перед установкой Сервера удаленного рабочего стола с помощью PowerShell сначала давайте импортируем новый модуль RemoteDestop в Windows Server 2012R2, используя команду:

PS C:Usersadministrator.MABOFENG> import-module RemoteDesktop

Укажите службу роли посредника подключений к удаленному рабочему столу (посредник подключений к удаленному рабочему столу), службу роли веб-доступа к удаленному рабочему столу (веб-доступ к удаленным рабочим столам) и один или несколько экземпляров сервера службы роли узла виртуализации удаленных рабочих столов (узел виртуализации удаленных рабочих столов). Доменное имя (FQDN).

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

New-RDVirtualDesktopDeployment -ConnectionBroker «rds.mabofeng.com» -WebAccessServer «rds.mabofeng.com» -VirtualizationHost «rds.mabofeng.com» -CreateVirtualSwitch

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

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

Следующим шагом является установка подключения к агенту удаленного рабочего стола.

Затем система установит сервер веб-доступа к удаленным рабочим столам.

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

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

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

Последний шаг — настроить хост виртуализации.

После завершения программы установки owerShell мы можем открыть консоль Server Manager на целевом компьютере, увидеть вкладку «Службы удаленных рабочих столов» и фактически установить три роли.

На узле виртуализации будет установлена ​​роль Hyper-V и будет установлен коммутатор по умолчанию. Внешний коммутатор RDS Virtual использует метод внешнего подключения.

Если роль установлена ​​на том же хосте в одно и то же время, в начале установки появляется сообщение об ошибке, и в PowerShell отображается, что локальный сервер не может быть перезапущен.Поскольку сервер роли сеанса удаленных рабочих столов необходимо перезапустить в процессе установки, поэтому во время процесса установки Невозможно закрыть и остановить работу powershell.Чтобы решить эту проблему, вам необходимо запустить эти команды на удаленном сервере, чтобы можно было перезапустить целевой сервер.

В-пятых, используйте powershell для стандартного развертывания (VDI)

Если вы устанавливаете функции роли инфраструктуры виртуальных рабочих столов (VDI) на разных серверах, вы можете использовать команду:

PS C:> New-RDVirtualDesktopDeployment -ConnectionBroker «rdcb.mabofeng.com» -WebAccessServer «rdwa.mabofeng.com» -VirtualizationHost «rdhv.mabofeng.com» –CreateVirtualSwitch

Если вы устанавливаете функции роли инфраструктуры виртуальных рабочих столов (VDI) на разных серверах и создаете виртуализированный пул хостов, вы можете использовать команду:

PS C:> New-RDVirtualDesktopDeployment -ConnectionBroker «rdcb.mabofeng.com» -WebAccessServer «rdwa.mabofeng.com» -VirtualizationHost @(«rdhv-1.mabofeng.com»,»rdhv-2.mabofeng.com»)

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

08-Windows Server 2012 R2 сеанс удаленный рабочий стол — стандартное развертывание — использование PowerShell для развертывания 2-1

Ма Бофенг

PowerShell всегда был важной частью продуктов Microsoft Windows Server. Вы можете использовать PowerShell для завершения всех конфигураций сервера и даже некоторых вещей, которые нельзя сделать в графическом интерфейсе. С каждой новой версией продуктов или услуг Microsoft вы можете видеть, что PowerShell тесно интегрирован с этими продуктами и услугами. По сравнению с исходной PowerShell в Windows Server 2012 R2 PowerShell 4.0 более мощный и может поддерживать более 2400 Команда командлета PowerShell, это огромное количество.Администраторам также очень сложно запомнить так много команд командлета PowerShell, но большинство команд командлета PowerShell — обычные компьютерные слова, даже если память не так уж и велика. Вы можете использовать клавишу Tab для завершения ввода во время процесса ввода.Если вы столкнетесь с синтаксисом, который вы не будете использовать, вы можете получить подробную справку после параметра home-help.

One, PowerShell и Server Core

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

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

псевдоним сервера	операционная система	Настройки IP	Характеристики
AD-DC.mabofeng.com	Windows Server 2012 R2	192.168.1.100	Контроллер домена
BD-RDS.mabofeng.com	Windows Server 2012 R2 Server core	192.168.1.110	Агент подключения к удаленному рабочему столу

Поскольку Windows Server 2012 R2 использует режим установки ядра сервера, команды PowerShell должны использоваться для управления и контроля во время всех операций. У режима установки ядра сервера есть много преимуществ:

1. Снижение затрат на обслуживание: поскольку в версии Server Core пользователи устанавливают только основные роли сервера, такие как DHCP, файлы, DNS и Active Directory, что сокращает время и усилия, необходимые для обслуживания системы, по сравнению с установкой полного сервера. .

2. Уменьшение поверхности атаки: поскольку Server Core выполняет минимальное действие по установке, оно гарантирует, что на сервере работает меньше приложений, что практически снижает вероятность атаки сервера.

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

4. Снижение требований к оборудованию: для установки Server Core требуется всего около 800 МБ на жестком диске, а для быстрой установки требуется менее 500 МБ.

Режим Server Core дает много преимуществ, но эти Server Core имеют преимущества и недостатки одновременно.То есть, если вы используете серверы в режиме Server Core, из-за отсутствия графического интерфейса технический уровень администраторов Windows высок. Как правило, новички в Windows не привыкли использовать PowerShell для управления. Менеджеры, привыкшие к графическим операциям, могут по-прежнему использовать режим Server Core для развертывания серверов и использовать Server Manager для удаленного управления, чтобы они могли управлять всеми функциями Windows Server в режиме Server Core.

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

2. Используйте powershell для быстрого развертывания (RemoteApp)

Перед установкой Сервера удаленного рабочего стола с помощью PowerShell сначала давайте импортируем новый модуль RemoteDestop в Windows Server 2012R2, используя команду:

PS C:Usersadministrator.MABOFENG> import-module RemoteDesktop

Когда мы импортировали командлет RemoteDestop специально для служб удаленного рабочего стола. Следующим шагом будет использование команды powershell для развертывания сервера удаленного рабочего стола на основе сеанса. Существует два способа развертывания в службах удаленных рабочих столов в Windows Server 2012 R2. Первый — быстрое развертывание и установка на основе ролей, все роли и функции устанавливаются на одном хосте, а второй — стандартное развертывание, при котором роли в RemoteDestop развертываются на разных хостах. В графическом интерфейсе мы Мастер установки будет использоваться для установки всех необходимых ролей вместо ручной установки и настройки всех отдельных ролей.

Во-первых, давайте установим быстрое развертывание рабочего стола на основе сеанса.В этом примере мы будем моделировать среду быстрого развертывания, а также установить и развернуть все роли (узел сеанса удаленных рабочих столов, посредник подключений к удаленному рабочему столу и веб-доступ к удаленным рабочим столам) на одном сервере. При быстром развертывании рабочего стола сеанса мы в основном используем команду New-SessionDeployment. Вы можете просмотреть синтаксис этой команды через New-SessionDeployment -help.

Синтаксис: New-SessionDeployment [-ConnectionBroker] <String> [-SessionHost] <String []> [[-WebAccessServer] <String>] [<CommonParameters>]

Командлет New-RDSessionDeployment установит необходимую инфраструктуру виртуальных рабочих столов (VDI) для создания служб удаленных рабочих столов (RDS), которые являются службой ролей для развертывания удаленных рабочих столов на основе сеансов. Развертывание на основе сеансов позволяет пользователям подключаться к набору сеансов, который включает опубликованные программы RemoteApp для Windows Server 2012 R2 и рабочие столы на основе сеансов.

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

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

New-SessionDeployment -ConnectionBroker RDS.mabofeng.com -WebAccessServer RDS.mabofeng.com -SessionHost RDS.mabofeng.com

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

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

Затем система установит прокси-сервер подключения к удаленному рабочему столу.

Затем система установит сервер веб-доступа к удаленным рабочим столам.

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

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

После завершения установки PowerShell мы можем открыть консоль Server Manager на целевой машине и увидеть вкладку Remote Desktop Services, где фактически установлены три роли.

Если роль установлена ​​на одном и том же хосте в одно и то же время, в начале установки появляется сообщение об ошибке, и в PowerShell отображается, что локальный сервер не может быть перезапущен. Когда эта проблема возникает, это происходит не из-за недостаточных полномочий администратора, а из-за того, что вы находитесь в Команда развертывания powershell выполняется на целевом сервере. Сервер роли сеанса удаленных рабочих столов необходимо перезапустить во время процесса установки. Следовательно, PowerShell не может быть выключен или остановлен в процессе установки. Чтобы решить эту проблему, вам необходимо выполнить эти команды на удаленном сервере. Целевой сервер можно перезапустить.

Три, используйтеpowershellВыполнить стандартное развертывание (RemoteApp)

В дополнение к этому простому развертыванию вы также можете использовать powershell для стандартного развертывания.Стандартное развертывание может развертывать роли RDS на разных хостах, включая развертывание нескольких серверов узлов сеансов удаленных рабочих столов, но все они используют New-RDSessionDeployment.

Например, 1. Чтобы установить службу роли RDS на разных хостах, используйте команду:

PS C:> New-RDSessionDeployment -ConnectionBroker «RDCB.mabofeng.com» -WebAccessServer «RDWA.mabofeng.com» -SessionHost «RDSH01.mabofeng.com»

Эта команда установит службу роли удаленного рабочего стола на указанный сервер. Эта команда установит службу роли посредника подключений к удаленному рабочему столу на сервере с именем RDCB. Установите службу роли веб-доступа к удаленным рабочим столам на сервере с именем RDWA.mabofeng.com. Установите службу роли узла сеансов удаленных рабочих столов на сервере с именем RDSH01.

Например, 2. Установите службу роли RDS на разных хостах, включая несколько серверов Узлов сеансов удаленных рабочих столов. Используемая команда: PS C: > New-RDSessionDeployment -ConnectionBroker «RDCB.mabofeng.com» -WebAccessServer «RDWA.mabofeng.com» -SessionHost @ («RDSH01.mabofeng.com», «RDSH02.mabofeng.com»)

Эта команда установит службу роли удаленного рабочего стола на указанный сервер. Эта команда установит службу роли посредника подключений к удаленному рабочему столу на сервере с именем RDCB. Установите службу роли веб-доступа к удаленным рабочим столам на сервере с именем RDWA. Эта команда устанавливает службу роли узла сеансов удаленных рабочих столов на двух серверах с именами RDSH01.mabofeng.com и RDSH02.mabofeng.com.

В-четвертых, используйте powershell для быстрого развертывания (VDI)

Помимо использования команды powershell для развертывания службы RemoteApp на основе узла сеанса, вы также можете развернуть удаленный рабочий стол на основе виртуальной машины. Команда для создания развертывания на основе виртуальной машины — New-RDVirtualDesktopDeployment. Во-первых, давайте посмотрим на синтаксис этой команды:

Синтаксис: New-RDVirtualDesktopDeployment [-ConnectionBroker] <String> [-WebAccessServer] <String> [-VirtualizationHost] <String []> `-CreateVirtualSwitch` [<CommonParameters>]

Команда New-RDVirtualDesktopDeployment предназначена для установки виртуального рабочего стола на основе виртуальной машины (VDI). Для виртуального рабочего стола на основе виртуальной машины требуется отдельная виртуальная машина, что означает, что роль Hyper-V должна быть установлена ​​в Windows Server 2012 R2. Вы можете указать параметры создания нового виртуального коммутатора для создания общей коллекции виртуальных рабочих столов, за исключением установленных служб ролей. Перед установкой Сервера удаленного рабочего стола с помощью PowerShell сначала давайте импортируем новый модуль RemoteDestop в Windows Server 2012R2, используя команду:

PS C:Usersadministrator.MABOFENG> import-module RemoteDesktop

Укажите службу роли посредника подключений к удаленному рабочему столу (посредник подключений к удаленному рабочему столу), службу роли веб-доступа к удаленному рабочему столу (веб-доступ к удаленным рабочим столам) и один или несколько экземпляров сервера службы роли узла виртуализации удаленных рабочих столов (узел виртуализации удаленных рабочих столов). Доменное имя (FQDN).

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

New-RDVirtualDesktopDeployment -ConnectionBroker «rds.mabofeng.com» -WebAccessServer «rds.mabofeng.com» -VirtualizationHost «rds.mabofeng.com» -CreateVirtualSwitch

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

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

Следующим шагом является установка подключения к агенту удаленного рабочего стола.

Затем система установит сервер веб-доступа к удаленным рабочим столам.

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

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

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

Последний шаг — настроить хост виртуализации.

После завершения программы установки owerShell мы можем открыть консоль Server Manager на целевом компьютере, увидеть вкладку «Службы удаленных рабочих столов» и фактически установить три роли.

На узле виртуализации будет установлена ​​роль Hyper-V и будет установлен коммутатор по умолчанию. Внешний коммутатор RDS Virtual использует метод внешнего подключения.

Если роль установлена ​​на том же хосте в одно и то же время, в начале установки появляется сообщение об ошибке, и в PowerShell отображается, что локальный сервер не может быть перезапущен.Поскольку сервер роли сеанса удаленных рабочих столов необходимо перезапустить в процессе установки, поэтому во время процесса установки Невозможно закрыть и остановить работу powershell.Чтобы решить эту проблему, вам необходимо запустить эти команды на удаленном сервере, чтобы можно было перезапустить целевой сервер.

В-пятых, используйте powershell для стандартного развертывания (VDI)

Если вы устанавливаете функции роли инфраструктуры виртуальных рабочих столов (VDI) на разных серверах, вы можете использовать команду:

PS C:> New-RDVirtualDesktopDeployment -ConnectionBroker «rdcb.mabofeng.com» -WebAccessServer «rdwa.mabofeng.com» -VirtualizationHost «rdhv.mabofeng.com» –CreateVirtualSwitch

Если вы устанавливаете функции роли инфраструктуры виртуальных рабочих столов (VDI) на разных серверах и создаете виртуализированный пул хостов, вы можете использовать команду:

PS C:> New-RDVirtualDesktopDeployment -ConnectionBroker «rdcb.mabofeng.com» -WebAccessServer «rdwa.mabofeng.com» -VirtualizationHost @(«rdhv-1.mabofeng.com»,»rdhv-2.mabofeng.com»)

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

Эта статья воспроизводится с mabofengБлог 51CTO, исходная ссылка: http://blog.51cto.com/mabofeng/1343871 , Пожалуйста, свяжитесь с первоначальным автором, если вам нужно перепечатать

---

Note

Management (how to) changes for RDS in Windows Server 2012 and 2012R2 This wiki article main purpose is to provide administrators familiar with Windows Server 2008 R2 Remote Desktop Services a quick overview of management changes in Windows Server 2012.It covers settings locations only and does not provide information about the technology used in each component Windows Server 2012 introduced the Remote Desktop Management Service (RDMS) effectively removing the standard MMC consoles used to manage a Windows Server 2008 R2 Remote Desktop Services server. The RDMS is responsible for adding, removing and updating configuration for all of the servers comprising a Remote Desktop Services deployment. All of the configuration is now stored in the Connection Broker database.

Intro and lab configuration

In order to provide the best possible guidance in this article, two virtual machine based labs are being used to generate screenshots.

The first lab consists of a pure Windows Server 2008 R2 installation, the virtual machines used are the following:

• SRV2008DC / Windows Server 2008 R2 Domain Controller, DNS and DHCP
• SRV2008RDS1 / Windows Server 2008 R2 Remote Desktop Session Host
• SRV2008Web1 / Windows Server 2008 R2 Remote Desktop Services Web and Gateway Services

The second lab is a pure Windows Server 2012 R2 installation, the virtual machines used are the following:

• SRV2012DC /Windows Server 2012 R2 Domain Controller, DNS and DHCP
• SRV2012CB1 /Windows Server 2012 R2 Remote Desktop Services Connection Broker
• SRV2012RDS1 /Windows Server 2012 R2 Remote Desktop Services Session Host
• SRV2012Web1 /Windows Server 2012 R2 Remote Desktop Services Web and Gateway Services

A quick overview of consoles

In order to gain a better understanding of the administration in the previous release of Windows Server, I will quickly go through the MMC consoles used in order to configure the deployment options. The consoles used to manage the settings are the following:

Remote Desktop Session Host Configuration

The Remote Desktop Session Host configuration is used on a server running Remote Desktop Session Host to configure

Remote Desktop Services Manager

RemoteAPP Manager

The RemoteAPP manager is used to publish and configure all of the remote application settings. Essentially this console provides the RDP Settings in each .rdp file.

Remote Desktops

The Remote Desktops MMC is used to host connection information on a single pane providing administrators with quick access to Remote Desktop Servers instead of the Remote Desktop Services Client functionality. This console is no longer used in Windows Server
2012 and Windows Server 2012 R2. An administrator can still use the Remote Desktop Client in order to connect to a Remote Desktop Server.

Remote Desktop Gateway Manager

Remote Desktop Licensing Manager

Remote Desktop Web Access Configuration

Finally the Remote Desktop Web Access Configuration is a web page with which we can configure the sources a Remote Desktop Services Web Access server can connect and provide Remote Desktop services to users. These settings are automatically configured by
the Server Manager in Windows Server 2012 and Windows Server 2012 R2.

A brief description of Server Manager

Server Manager hosts the Remote Desktop Services administration page for most of the settings an administrator need to configure. Some of the options in the previous release consoles are moved to either PowerShell or Group Policy.

This management change effectively pushes all of the configuration changes to the servers providing Remote Desktop functionality and eases the administrative burden of having to move through different consoles. It also provides an easy way to add or remove
servers as needed empowering administrators with true scale out options.

Only Licensing and Gateway server consoles are available due to the fact that these roles can exist on different servers. For example a single Licensing server can provide licenses to both Windows Server 2008 R2 and Server 2012 R2 deployments and a Gateway
server can reside on a DMZ.

Basic RDS Configuration

As installation completes on Windows Server 2008 R2 for the Remote Desktop Session Host, a number of settings would be revised by an administrator to provide users with optimal experience. This configuration was done through the Remote Desktop Session Host
Configuration.

General Tab

The first tab is the General Tab which is used to configure security settings and Certificate Settings on the RDP-Tcp Listener

The same functionality is provided by the Server Manager by navigating to the Collection, selecting Tasks->Edit Properties and then the Security Tab

The certificate settings can be globally configured by navigating to Overview and selecting Edit Deployment Properties from the Tasks Button. On the deployment properties we can find the Certificates tab with which we can configure the certificates on all
of the deployment.

Log on settings

The Log on Settings Tab is deprecated in Windows Server 2012 and Windows Server 2012 R2.

Although the Always prompt for password option is available in Group Policy. The setting can be found in Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host Security.

Sessions

Environment

Remote Control

The Remote Control feature used in Windows 2008 R2 was added again in Windows Server 2012 R2.

The settings are now  found in the users Remote Control tab in the Active Directory Users and Computers console.

Client Settings

The Client Settings tab configures the options for the monitor redirection, maximum color depth and redirection settings.

These settings can be found at the Server Manager by editing the properties of the collection and navigating to Client Settings. Maximum color depth can be adjusted per RemoteApp by editing the custom rdp property  “Session BPP” .

Network Adapter

The Network Adapter tab is does no longer exist in Windows Server 2012 and Windows Server 2012 R2.

Security

The Security Tab on Windows Server 2008 R2 controls the access control lists

The same functionality is found on the Collection properties Users Group Tab and by editing each RemoteApp individually.

Remote Desktop Session Host General

On the general properties an administrator can configure the following tabs.

General

The General tab with which we can configure the temporary files behavior, the single session limit enforcement and the Remote Desktop Session Host drain mode.

The temporary files settings can be configured by navigating to the session collection properties and selecting the Session Tab.

The single session restriction can be enforced through Group Policy. The settings exists in Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections

The Drain mode is much simpler. By right clicking a Remote Desktop Session Host in the specified collection , you can select Do not allow new connections.

Licensing

The Licensing tab allows you to configure a License server as well as the licensing mode. Either Per User or Per Device.

The same functionality can be found by editing the deployment properties from the Overview tab in Server Manager.

Connection Broker

The Connection Broker options allow you to configure the server role in a farm , the connection broker responsible for the redirections, the farm name and the redirection mode.

Since Windows Server 2012 and 2012 R2 Remote Desktop Service rely on a Connection Broker, the role is configured automatically for each Session Host. However the DNS farm name in Windows Server 2012 and 2012 R2 needs to be configured when you prepare high
availability mode as in the screenshot below. If you need to change that name later you can use the PowerShell cmd-let Set-RDClientAccessName [[-ConnectionBroker] <String> ] [-ClientAccessName] <String> [ <CommonParameters>]

RD IP Virtualization

The RD IP Virtualization tab is used when we need to provide a virtual IP address per session or program. This is a requirement for some applications to work correctly.

These settings can now be configured through Group Policy. Navigate to Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Application Compatibility->Turn on Remote Desktop IP Virtualization.

Remote Desktop Services Manager

The Remote Desktop Services Manager allowed an administrator to act on user sessions like log off and disconnect by simply selecting a user session and right click upon it.

This Session administration is now moved to Server Manager. By navigating to a collection you can manage the user sessions on the right side of Server Manager in a widget-like tab named Connections.

The management scope extends to all collections by navigating to the Collection tab in Server Manager. Again on the right side you can manage the connections but this time collectively for all sessions on all of the available collections.

RemoteApp Manager

The RemoteAPP manager is used to publish and configure all of the remote application settings. Essentially this console provides the RDP Settings in each .rdp file.

RD Session Host Server

The first tab is the RD Session Host Server. On this tab you can configure the Server name , the rdp port as well as general access settings. Since Windows Server 2012 and Windows Server 2012 R2 use a Connection broker the Server name and port is no longer
needed.

However the Access to unlisted programs can be found in Group Policy. Navigate to Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Connections->Allow remote start of unlisted programs, in order to select the
appropriate setting.

RD Gateway

The same principle applies to the RD Gateway tab. Once a gateway server is configured through the Server Manager in Server 2012 and Server 2012 R2 it will automatically apply to all RemoteApp programs.

Digital Signature

The digital signature will derive from the certificate settings in the deployment properties.

Common / Custom RDP Settings

The Common RDP Settings and the Custom RDP Settings can be configured per Collection by using the powershell cmdlet Set-RDSessionCollectionConfiguration.

RemoteApp Settings

The RemoteApp settings control the Name, visibility and command line arguments as well as the User Assignment.

These settings also exist on Windows Server 2012 and Windows Server 2012 R2. Simply navigate to the collection and on the middle of the page select the RemoteApp you want to change the settings for, right click and choose the appropriate settings.

---