Андрей Смирнов
Время чтения: ~23 мин.
Просмотров: 87

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

ИнструкцииИТИТ-поддержка

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

  • Процессор: от 4 ядер
  • Оперативная память : 1 ГБ на каждого пользователя + 4 ГБ для работы ОС + 4 ГБ запас
  • Ширина канала для терминального сервера: 250 Кбит/с на пользователя

Первоначальные настройки Windows Server 2016:

  1. Настроить статический IP-адрес сервера
  2. Проверить правильность настройки времени и часового пояса
  3. Установить все обновления системы
  4. Задать понятное имя для сервера и, при необходимости, ввести его в домен
  5. Включить доступ до сервера по удаленному рабочему столу для удаленного администрирования
  6. Настроить запись данных профилей пользователей на второй логический диск
  7. Активировать лицензию Windows Server 2016

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

Начиная с Windows 2012 терминальный сервер должен работать в среде Active Directory.

Если в вашей локальной сети есть контроллер домена, просто присоединяйте к нему сервер терминалов, иначе установите на сервер роль контроллера домена.

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

В панели быстрого запуска открываем Диспетчер серверов:

image14.jpg

Нажимаем Управление — Добавить роли и компоненты:

image7.png

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

image5.png

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

image1.png

Кликаем Далее, пока не появится окно «Выбор служб ролей» и выбираем следующие:

  • Лицензирование удаленных рабочих столов
  • Узел сеансов удаленных рабочих столов

image6.jpg

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

При необходимости, также выставляем остальные галочки:

  • Веб-доступ к удаленным рабочим столам — возможность выбора терминальных приложений в браузере.
  • Посредник подключений к удаленному рабочему столу — для кластера терминальных серверов посредник контролирует нагрузку каждой ноды и распределяет ее.
  • Узел виртуализации удаленных рабочих столов — для виртуализации приложений и запуска их через терминал.
  • Шлюз удаленных рабочих столов — центральный сервер для проверки подлинности подключения и шифрования трафика. Позволяет настроить RDP внутри HTTPS.

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

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

После перезагрузки открываем Диспетчер серверов и нажимаем Управление — Добавить роли и компоненты:

image11.jpg

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

image17.jpg

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

image12.jpg

В «Выбор сценария развертывания» — Развертывание рабочих столов на основе сеансов — Далее:

image16.jpg

Еще раз Далее — при необходимости, ставим галочку «Автоматически перезапускать конечный сервер, если это потребуется» и кликаем по Развернуть.

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

Для корректной работы сервера, необходимо настроить службу лицензирования. Для этого открываем диспетчер серверов и кликаем по Средства — Remote Desktop Services — Диспетчер лицензирования удаленных рабочих столов:

image4.png

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

В открывшемся окне дважды кликаем Далее — заполняем форму — Далее — Далее — Снимаем галочку «Запустить мастер установки лицензий» — Готово.

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

image15.jpg

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

image10.jpg

В открывшемся окне переходим в Лицензирование — Выбираем тип лицензий — прописываем имя сервера лицензирования (в данном случае локальный сервер) и нажимаем Добавить:

image18.png

Применяем настройки, нажав OK.

Добавление лицензий

Открываем диспетчер серверов и кликаем по Средства — Remote Desktop Services — Диспетчер лицензирования удаленных рабочих столов:

image4.png

В открывшемся окне кликаем правой кнопкой мыши по нашему серверу и выбираем Установить лицензии:

В открывшемся окне нажимаем Далее:

Выбираем программу, по которой куплены лицензии, например, Enterprise Agreement:

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

Нажимаем Далее — Готово.

Проверить статус лицензирования можно в диспетчере серверов: Средства — Remote Desktop Services — Средство диагностики лицензирования удаленных рабочих столов.

Мы также готовы оказать помощь в установке и настройке терминального сервера.

Нашим клиентам мы предлагаем реализацию данного проекта и его последующее обслуживание в рамках ИТ-аутсорсинга.

Комментарии для сайта Cackle—> —> Комментарии для сайта Cackle—>

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

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

rds-logo.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Апр 3, 2019 09:00 Задайте вопрос Быстрый доступ

Серверные ОС Windows > Windows Server 2016
  • Вопрос

  • Добрый день.

    Собственно вопрос в заглавии.

    Имеется: лицензионный windows server 2016, 50 терминальных лицензий для девайсов.

    Задача: настроить терминальный сервер для 1С, для работы в локальной сети, домен и AD поднят на старой WS 2003.

    Нужна или пошаговая инструкция или ссылка там где это описано (делал такое давно на 2003, сейчас совсем не похоже), все что в нете нахожу или описание какой RDS в WS2016 классный и сколько там возможностей и 0 полезной информации, как же все таки это сделать.

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

    Заранее большое спасибо.

    • Изменено20 апреля 2017 г. 7:10

    20 апреля 2017 г. 6:46 Ответить | Цитировать

Ответы

  • Сути дела это не поменяет. Через GPO это можно решить несколькими методами — добавлением доменной группы в локальную группу — то что вы уже сделали только через GPO (писал ранее 2 варианта как можно это сделать), или через добавление группыпользователей через политику безопасности — это вариант плохой, так как не очевидный и через год когда понадобится что то поменять будете пол дня голову ломать как это работает.

    Если группасервер у вас одна, то смысла заморачиваться с GPO нет. Чем вашему руководителю не нравится прямое решение?

    The opinion expressed by me is not an official position of Microsoft

    • Предложено в качестве ответа21 апреля 2017 г. 6:29
    • Помечено в качестве ответа21 апреля 2017 г. 6:41

    20 апреля 2017 г. 17:09 Ответить | Цитировать

  • В общем сервер WS2016 поднял, RDS включил но. Под учетной записью администратора домена к серверу RDS подключаюсь нормально, но под учетной записью пользователя, добавленного в группу «Пользователи удаленного рабочего стола» на контроллере домена подключиться не могу — выскакивает ошибка «Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.» Полазил в интернете, что по этому поводу пишут, и все сводиться примерно к одному — надо на сервере RDS так или иначе в локальных политиках этого сервера включить разрешение для группы «Своя группа подключения к рабочему столу» на подключение по RDS и уже в эту группу добавлять пользователей из домена. Так вот я не понимаю, зачем тогда нужна группа «Пользователи удаленного рабочего стола» на контроллере домена, если я с тем же успехом могу сделать любую группу и дать ей таким образом доступ или прописать любого пользователя в качестве локального и разрешить ему подключение, даже не добавляя его в «Пользователи удаленного рабочего стола». Может можно где-то что-то нажать что бы пользователи уже включенные в домене в «Remote Desktop Users» могли подключиться к RDS WS2016, без создания еще одной группы. Объясните мне пожалуйста, где я не прав.

    Что то вы делаете интересное… RD Users на контроллере домена является Build In группой, что значит что эта группа имеет предназначения для использования на КД, а не как не на сторонних серверах.

    На вашем терминальнике вам нужно добавить доменную группу (созданную вами) например «Terminal Users» в группу RD Users…

    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа20 апреля 2017 г. 14:03
    • Снята пометка об ответе20 апреля 2017 г. 14:03
    • Предложено в качестве ответа20 апреля 2017 г. 14:03
    • Помечено в качестве ответа20 апреля 2017 г. 14:03

    20 апреля 2017 г. 10:19 Ответить | Цитировать

Все ответы

  • Возьмите инструкцию от 2012Р2, там все должно быть похоже

    The opinion expressed by me is not an official position of Microsoft

    20 апреля 2017 г. 7:09 Ответить | Цитировать

    • Изменено20 апреля 2017 г. 7:15

    20 апреля 2017 г. 7:13 Ответить | Цитировать

  • А чем он Вам мешает??  Он полезен для правильности ярлыков. А еще почитайте недавнюю дискуссию ЭТУ. Я считаю там много интересного для себя почерпнете. 20 апреля 2017 г. 7:22 Ответить | Цитировать
  • ЕМНИП можно обойтись и без веб но тогда эта схема вам не подойдет (он так же нужен для брокера если не ошибаюсь), по ссылке выше рассмотрен вариант фермы терминалов.

    Если у вас сервер будет один вы можете включить роль РДС включить галку разрешать удаленно подключаться (в 2003 включалась возможность точно так же только настройки производились чутка иначе), указать группу которой можно подключаться через политики настроить лицензирование и усе…

    Дополнительные настройки (сервера лицензирования, сертификаты и пр, можно произвести через политики)

    The opinion expressed by me is not an official position of Microsoft

    • Изменено20 апреля 2017 г. 7:33

    20 апреля 2017 г. 7:28 Ответить | Цитировать

  • Он мне лишний, а раз лишний, значит мешает. Тем более зачем мне лишняя дырка в локальную сеть из вне, безопасность превыше всего. Так что вопрос прежний без ВЭБ никак?20 апреля 2017 г. 7:29 Ответить | Цитировать
  • Он мне лишний, а раз лишний, значит мешает. Тем более зачем мне лишняя дырка в локальную сеть из вне, безопасность превыше всего. Так что вопрос прежний без ВЭБ никак?

    Выше я вам на этот вопрос ответил

    The opinion expressed by me is not an official position of Microsoft

    20 апреля 2017 г. 7:43 Ответить | Цитировать

  • Он мне лишний, а раз лишний, значит мешает. Тем более зачем мне лишняя дырка в локальную сеть из вне, безопасность превыше всего. Так что вопрос прежний без ВЭБ никак?

    Выше я вам на этот вопрос ответил

    The opinion expressed by me is not an official position of Microsoft

    Да это я не Вам писал, просто пока писал, Вы успели ответить. просто цитировать не вышло. Еще вопрос, в 2003 там был Terminal Services Manager, в 2016 если я правильно понял эту роль выполняет Remote Desktop Services?20 апреля 2017 г. 7:55 Ответить | Цитировать

  • Менеджера начиная с 2012 сервера нет, настройки производятся либо через сервер менеджер, но вам тогда придется ставить веб либо через политики.

    The opinion expressed by me is not an official position of Microsoft

    20 апреля 2017 г. 8:23 Ответить | Цитировать

  • В общем сервер WS2016 поднял, RDS включил но. Под учетной записью администратора домена к серверу RDS подключаюсь нормально, но под учетной записью пользователя, добавленного в группу «Пользователи удаленного рабочего стола» на контроллере домена подключиться не могу — выскакивает ошибка «Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.» Полазил в интернете, что по этому поводу пишут, и все сводиться примерно к одному — надо на сервере RDS так или иначе в локальных политиках этого сервера включить разрешение для группы «Своя группа подключения к рабочему столу» на подключение по RDS и уже в эту группу добавлять пользователей из домена. Так вот я не понимаю, зачем тогда нужна группа «Пользователи удаленного рабочего стола» на контроллере домена, если я с тем же успехом могу сделать любую группу и дать ей таким образом доступ или прописать любого пользователя в качестве локального и разрешить ему подключение, даже не добавляя его в «Пользователи удаленного рабочего стола». Может можно где-то что-то нажать что бы пользователи уже включенные в домене в «Remote Desktop Users» могли подключиться к RDS WS2016, без создания еще одной группы. Объясните мне пожалуйста, где я не прав.20 апреля 2017 г. 9:44 Ответить | Цитировать
  • В общем сервер WS2016 поднял, RDS включил но. Под учетной записью администратора домена к серверу RDS подключаюсь нормально, но под учетной записью пользователя, добавленного в группу «Пользователи удаленного рабочего стола» на контроллере домена подключиться не могу — выскакивает ошибка «Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.» Полазил в интернете, что по этому поводу пишут, и все сводиться примерно к одному — надо на сервере RDS так или иначе в локальных политиках этого сервера включить разрешение для группы «Своя группа подключения к рабочему столу» на подключение по RDS и уже в эту группу добавлять пользователей из домена. Так вот я не понимаю, зачем тогда нужна группа «Пользователи удаленного рабочего стола» на контроллере домена, если я с тем же успехом могу сделать любую группу и дать ей таким образом доступ или прописать любого пользователя в качестве локального и разрешить ему подключение, даже не добавляя его в «Пользователи удаленного рабочего стола». Может можно где-то что-то нажать что бы пользователи уже включенные в домене в «Remote Desktop Users» могли подключиться к RDS WS2016, без создания еще одной группы. Объясните мне пожалуйста, где я не прав.

    Что то вы делаете интересное… RD Users на контроллере домена является Build In группой, что значит что эта группа имеет предназначения для использования на КД, а не как не на сторонних серверах.

    На вашем терминальнике вам нужно добавить доменную группу (созданную вами) например «Terminal Users» в группу RD Users…

    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа20 апреля 2017 г. 14:03
    • Снята пометка об ответе20 апреля 2017 г. 14:03
    • Предложено в качестве ответа20 апреля 2017 г. 14:03
    • Помечено в качестве ответа20 апреля 2017 г. 14:03

    20 апреля 2017 г. 10:19 Ответить | Цитировать

  • Что то вы делаете интересное… RD Users на контроллере домена является Build In группой, что значит что эта группа имеет предназначения для использования на КД, а не как не на сторонних серверах.

    На вашем терминальнике вам нужно добавить доменную группу (созданную вами) например «Terminal Users» в группу RD Users…

    The opinion expressed by me is not an official position of Microsoft

    Но ведь WS2016 у меня включен в домен и на него насколько я понимаю распространяются политики КД.

    20 апреля 2017 г. 10:46 Ответить | Цитировать

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

    2 Группы и политики это слегка разные понятья

    3 Локальные группы и доменные группы это совсем разные группы. Remote Desktop Users на контроллере домена это локальная группа которая была конвертирована когда сервер стал КД. Если вам нужно оперировать с группами используйте собственные доменные группы, которые можно распространять через restricted groups (GPO), или через preferences (GPO)

    4 Выше я дал ответ касательно решения проблемы. Проверяйте локальную группу Remote Desktop Users на терминальном сервере.

    The opinion expressed by me is not an official position of Microsoft

    • Изменено20 апреля 2017 г. 11:18

    20 апреля 2017 г. 11:17 Ответить | Цитировать

  • 4 Выше я дал ответ касательно решения проблемы. Проверяйте локальную группу Remote Desktop Users на терминальном сервере.

    The opinion expressed by me is not an official position of Microsoft

    Не сочтите за наглость, а можно прямую ссылку где что нажать, а то голова уже совсем не работает, а сделать надо. Хотел картинку вставить как у меня на 2003 и спросить как сделать так же на 2016, но нет прав, попробую ссылку http://s019.radikal.ru/i644/1704/69/75f16693518e.png20 апреля 2017 г. 13:45 Ответить | Цитировать

  • 1 заходим в оснастку Users and computers на КД и создаем группу, пример названия группы я привел выше, но вы можете придумать другое уникальное название

    2 В группу добавляете тестового пользователя

    3 Заходите на терминальник (новый сервер про который выше шла речь) от имени админа (локального или доменного значения не имеет)

    4 Правой кнопкой мыши жмакаете на кнопку пуск и выбираете Computer management

    5 В Computer management выбираете Local Users and Groups

    6 В Groups находите Remote Desktop Users и добавляете доменную группу из п.1

    7 Пробуете заходить тестовым пользователем из п.2

    The opinion expressed by me is not an official position of Microsoft

    • Предложено в качестве ответа21 апреля 2017 г. 6:29

    20 апреля 2017 г. 14:03 Ответить | Цитировать

    • Изменено20 апреля 2017 г. 14:48

    20 апреля 2017 г. 14:46 Ответить | Цитировать

  • Сути дела это не поменяет. Через GPO это можно решить несколькими методами — добавлением доменной группы в локальную группу — то что вы уже сделали только через GPO (писал ранее 2 варианта как можно это сделать), или через добавление группыпользователей через политику безопасности — это вариант плохой, так как не очевидный и через год когда понадобится что то поменять будете пол дня голову ломать как это работает.

    Если группасервер у вас одна, то смысла заморачиваться с GPO нет. Чем вашему руководителю не нравится прямое решение?

    The opinion expressed by me is not an official position of Microsoft

    • Предложено в качестве ответа21 апреля 2017 г. 6:29
    • Помечено в качестве ответа21 апреля 2017 г. 6:41

    20 апреля 2017 г. 17:09 Ответить | Цитировать

Используемые источники:

  • https://efsol.ru/manuals/terminal.html
  • http://pyatilistnik.org/what-is-rds-terminal-farm/
  • https://social.technet.microsoft.com/forums/ru-ru/b8dbcd6a-64ea-41df-8587-d820ed9ef99d/105310721089109010881086108110821072-rds-1074-windows-server-2016

Рейтинг автора
5
Подборку подготовил
Максим Уваров
Наш эксперт
Написано статей
171
Ссылка на основную публикацию
Похожие публикации