Настройка remoteapp без домена windows server 2012

Обновлено: 05.07.2024

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

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

  • Развернуть систему на железо
  • Ввести систему в домен
  • Развернуть терминальный сервер

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

Win + X → Command Prompt (Admin) →

C:\Windows\system32>netdom join %computername% /domain:polygon.local /userd:polygon.local\aollo /passwordd:*

Type the password associated with the domain user:

The computer needs to be restarted in order to complete the operation.

The command completed successfully.

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

C:\Windows\system32>shutdown /r /t 3

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

Чтобы удаленные пользователи могли использовать терминальный сервер для них на домен контроллере будет правильнее создать группу к примеру: TS_RemoteServer и добавить в ней доменных пользователей, а после данную доменную группу на сервере добавить в группу Remote Desktop Users

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

Авторизуюсь на терминальном сервере уже под своей доменной административной учетной записью.

Т.к. все службы Remote Desktop Services у меня развернуты на одном сервере (т.е текущем), то в следующем окне мастер задействую выбор Quick Start (Быстрый запуск), Next

Далее выбираю сценарий развертывания Remote Desktop Services, т. е. Создание среды удаленных рабочих столов на основе RDP-сеансов: → Session-based desktop deployment, Next

Далее указываю текущий сервер (srv-serv.polygon.local 10.7.8.173), Next

После чего на текущем сервере будут развернуты необходимые роли для организации RemoteAPP, а именно:

  • RD Connection Broker
  • RD Web Access
  • RD Session Host

отмечаю галочкой пункт: Restart the destination server automatically if required и нажимаю Deploy, ожидаю

Устанавливаются необходимые сервисы для работы с RemoteAPP

Когда все бегунки пройдут будет сформирована URL-ссылка на доступ к опубликованным приложениям, вот к примеру у меня:

Теперь можно смело нажать кнопку Close

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

Визуализированное отображение текущей роли терминального сервера

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

Чтобы зайти в рабочее окружение, нужно авторизоваться:

  • Domain\user name: polygon.local\aollo
  • Password: 712mbddr@
  • This is a public or shared computer (Отмечаем)

и нажать на кнопку Sign in

Авторизуюсь в рабочей области терминального сервера

В случае правильного указания своего пароля получаем доступ к коллекции с опубликованными приложениями:

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

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

  • Диски (Отмечаю галочкой)
  • Другие поддерживаемые самонастраиваемые возможности (Снимаю галочку)
  • Буфер обмена (Отмечаю галочкой)
  • Принтеры (Отмечаю галочкой)
  • Запись звука (Снимаю галочку)

А после просто нажимаю кнопку «Подключить» следом появиться окно авторизации на терминальном сервере: (нужно указать)

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

Запускается удаленное приложение "Calculator" с Терминального сервера

И вот когда профиль подключившегося на терминальный сервер сформировался запуститься окно Калькулятора:

Профиль подключения к терминальному серверу сформирован и запустился "Калькулятор"

На заметку: так же из рабочей области можно создать RDP соединение с любой Windows системой на которую у Вас есть доступ, для этого нужно перейти на элемент Connect to a remote PC заполнить поля подключения и нажать Connect, а до этого где были видны все программы коллекции элемент назывался RemoteApp and Desktops.

Но согласитесь для пользователя вводить по нескольку раз свой логин и пароль несколько не правильно, почему бы не использовать также как и на терминальном сервере под управлением Server 2008 R2 (Ent), опубликовать приложение, сохранить его как rdp & msi пакет и просто раскидать по всем пользователя которым необходимо работать на сервере, настроить прозрачную аутентификация до TS и больше пользователю не нужно вводить никакие идентификационные данные для работы, к примеру с программой 1С, запустил и работай.

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


Remoteapp в 2012 R2 без домена — начну с главного: всё нормально и быстро настраивается. Опубликовать remoteapp в 2012 R2 без домена не получится, но это и не нужно.

При обновлении 2008 R2 до 2012 R2 на этапе проверки совместимости, установка попросила удалить роль Удаленных рабочих столов. Удивился. Ладно.. После обновления стало понятно, Microsoft в очередной раз перехитрила саму себя: теперь нормально работать с RDP можно лишь в составе домена.

Зачем.. Если у меня сервер 1С на 5 бухгалтеров, зачем мне роль AD DS? Думаю я не одинок в этом вопросе. Почитал в интернете, решение есть! Кто-то ставил роль контроллера домена, в виртуалке поднимал ещё один сервер, вводил в домен и на нём уже удаленные рабочие столы. Всё проще. Солюшенов несколько, решил собрать воедино.

Сервер

Установка роли

Службы удаленных рабочих столов (Remote Desktop Services), Далее, отмечаем чекбоксы: Лицензирование удаленных рабочих столов (Remote Desktop Licensing), Узел сеансов удаленных рабочих столов (Remote Desktop Session Host), со всем соглашаемся, установка, перезагрузка.

В Диспетчере серверов, в пункте меню Средства, появилась закладка Terminal Services (или Remote Desktop Services для 2016).

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

Настройка всех параметров RDP теперь в групповых политиках. Отдельной графической оснастки, как было раньше, нет:

  • Win+R - gpedit.msc - Конфигурация компьютера (Computer Configuration);
  • Административные шаблоны (Administrative Templates) -
    Компоненты Windows (Windows Components);
  • Службы удаленных рабочих столов (Remote Desktop Services) -
    Узел сеансов удаленных рабочих столов (Remote Desktop Session Host) - Лицензирование (Licensing).

Редактируем два параметра:

  • Использовать указанные серверы лицензирования удаленных рабочих столов (Use the specified Remote Desktop license servers) - включено - указываем имя сервера;
  • Задать режим лицензирования удаленных рабочих столов (Set the Remote licensing mode) - включено - на пользователя.

В соседних ветках настраиваются все параметры подключения клиентов.

Далее: Диспетчер серверов - Службы удалённых рабочих столов (Terminal Services) - правой кнопкой на сервере - Диспетчер лицензирования удаленных рабочих столов (Remote Desktop Licensing Manager) - Активировать сервер. Сведения об организации: обязательно нужно заполнить первую страницу, вторую можно оставить пустой.

После активации запускается Мастер установки лицензий:

  • Выбираем Enterprise Agreement - Далее (бессмысленный набор цифр ищем в интернете, ищется легко, буквально вторая/третья ссылка) - вводим номер - Далее - выбираем число лицензий и тип На пользователя. Заходим Диспетчер серверов - Все серверы - правой кнопкой на сервере - Средство диагностики лицензирования удалённых рабочих столов, проверяем, что нет ошибок.
Создаем файл RDP

На примере 1С предприятия: открываем блокнот и помещаем туда следующую информацию, заменяя имя_сервера на действительное имя сервера или IP:

Сохраняем файл, меняем расширение на rdp, раздаём пользователям.

Реестр

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

Проверяем правильность путей, сохраняем с раcширением reg, закидываем в реестр. Проверяем. Если не работает, смотрим ветку TSAppAllowList, у меня это:

И ветку 1cestart там же. Значения из reg-файла должны перенестись.

Возможные проблемы


Или вот такое ещё может быть:


Посмотрел на сервере ветку 1cestart:

Подключение через интернет

В файлике rdp вместо имя_сервера, можно использовать IP-адрес (или даже IP-адрес с портом через двоеточие, или же указать порт в соответствующей строке). Это позволяет подключать клиентов через интернет и NAT:

  • Пробросить на роутере рандомный внешний порт на внутренний 3389 сервера;
  • Вбить в файлик внешний реальник офиса с портом.

Конструкцию с RD Gateway считаю излишней, тем более если делается с пробросом 443 порта на внутренний ресурс, тем более что RD Gateway требует установки роли Web Server, то есть потребляет ресурсы — чем проще, тем надежнее. После настройки роли RDP и проверки работоспособности смело можно удалить даже фичи для администрирования RDP, они больше не нужны.

Клиенты

Клиенты MAC

Добавляем клиентов MAC OS X:

Если режим RemoteApp не нужен, то на этом всё. Если нужен, берём файл rdp, созданный по описанию выше для Windows, меняем имя_сервера на IP-адрес, закидываем на мак и всё работает.

Клиенты Windows XP

Добавляем клиентов Windows XP:

Клиенты Android

Наверное последнее, что нужно сказать по этой теме, для Андроида тоже есть RD Client от MS — функционирует он штатно и нормально. Приложение бесплатное, загружается через Play Market. Как и для Mac'а файл rdp, закинутый на Андроид, запустится с помощью этого приложения, но логин и пароль при этом сохранить невозможно, а нужно вводить каждый раз.

Связана такая ситуация, с тем, что в новых версиях RDP учетные данные не сохраняются в самом файле rdp, а хранятся в отдельной базе данных. На компьютере эти данные можно посмотреть в Панель управления\Учетные записи пользователей\Диспетчер учетных данных, либо Выполнить: control userpasswords2, что тоже самое. Где искать в Андроиде? Не знаю, да и не очень интересно, так как remoteapp для телефонов и планшетов больше блажь, чем реальная потребность. Обычная RDP-сессия работает? — Работает. Этого достаточно.

Три способа повысить защиту RDP
  1. Уровень безопасности SSL;
  2. Уровень шифрования FIPS-совместимый;
  3. Подключения принимаются только от клиентов с NLA.

Траблшутинг

Залипания

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

Если же залипание массовое и с ресурсами сервера всё в порядке, то проблема 90% сетевая. В 2012 R2 для RDP используется как TCP, так и UDP или только TCP. Нужно проверить, что UDP используется. Статья в помощь. Сайт MS. Таже нужно просмотреть политики.

Область применения

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

Тема исчерпана, но вопросы идут и некоторые люди не понимают нишу использования remoteapp, зачем такой режим, почему именно для 1C, какой тут смысл и в чём заключается выигрыш. Вещи-то очевидные, но раз так, то надо сказать пару слов.

Remoteapp не панацея

А именно есть очень толстые минусы как RDP в целом, так и remoteapp в частности:

  1. Каждый раз когда пользователь хочет сохранить файл, ему открываются диски удалённой машины. Есть варианты, но это неудобно в работе;
  2. Далеко не все пользователи продвинутые и с компьютером "на ты", многие очень тяжело воспринимают remoteapp, они путаются где какой диск, сложно и затратно по времени растолковать им данный режим работы;
  3. Для запуска remoteapp нужно время, так как на сервере должен загрузиться пользовательский сеанс;
  4. При закрытии приложения сеанс отключается и нужно ждать его завершения (минимум 1 минута), если в сеансе открыт конкретный фал, он будет блокирован на запись. Можно разрешить множественные сеансы для пользователя или можно убрать ограничения для отключенного сеанса, тогда возникают другие проблемы;
  5. В зависимости от версии Windows Server могут возникать различные глюки, связанные с временными задержками (не помню точно в какой версии сервера, но загружается сеанс и его нельзя завершить

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

Примечание. Очень хороший пример когда не нужно использовать remoteapp — Word и Exel.

Зачем 1С Remoteapp?

Схема применения 1С может варьироваться в очень широких пределах от локальной однопользовательской базы до сотен пользователей и кластера серверов. Возьмем классический вариант: многопользовательская база на 5-15 пользователей. Работа с такой базой, даже на 5 человек, генерирует большой сетевой трафик и сама база требует серьёзной вычислительной мощности. Вот отсюда и два варианта применения remoteapp для 1С:

  1. Если чистый файловый вариант базы и как раз 5-6 человек, потому как больше такая схема не потянет, тогда весь обсчёт на клиентах — для того чтобы перенести обсчёт с клиентов на сервер. Это позволяет увеличить число клиентов и одновременно значительно повысить скорость работы без внедрения СУБД;
  2. Удаленная работа через медленные либо лимитные каналы связи как в файловом варианте, так и в клиент-серверном – передавать изображение намного выгоднее по объёму трафика, чем трафик 1С.
Remoteapp vs классический RDP

Обычно в случае 1С база на сервере, а вот документы для работы на локальном компьютере. Всё время сворачивать и разворачивать окно RDP неудобно, remoteapp тут гораздо комфортнее.

Исключения
  1. Если все клиентские машины достаточно мощные (Core i3 и выше), баз мало (1-2-3), базы файловые, сеть локальная гигабитная, пользователей не больше, скажем, 5 и работа с базой не слишком интенсивная, тут даже сервер не нужен, подойдёт любой компьютер с гигабитной сетевой картой и быстрым диском. Важный момент, что все машины мощные, так как 1 слабый компьютер станет узким местом и скорость работы будет равняться по нему;
  2. При удалённой работе есть альтернатива remoteapp — веб публикация 1С. У каждого из этих решений свои плюсы и минусы.
Почему 2012 R2

C чистой 2012 без R2 встретиться в работе не удалось и ничего про неё не скажу. Но если сравнивать 2008 R2 и 2012 R2, то последняя имеет значительно перелопаченный код, как следствие быстрее работает на том же самом железе, а сетевой стек до 30% быстрее. Поддержка самого железа, особенно различных RAID-контроллеров, тоже лучше. И если на 2008 R2 драйвер при установке нужно подпихивать, то в 2012 R2 он скорее всего уже встроен, сталкивался несколько раз. Поддержка RDP 8.1.

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

Windows 2016

Эта статья получила довольно таки широкое распространение. Чего там говорить, вот да.. И как-то однажды, давно, где-то там на форуме, уже не вспомню каком, читал человек пишет: ставил по этой статье с этого сайта (с моего, отсюда) и на 2016 не работает. Дальше обсуждение на n-страниц. Как всегда. Ну не работает и не работает, мож даже и к лучшему. 🙂 Но тут меня недавно (22.04.2021) спросили конкретно здесь, в комментариях: почему не работает с 2016?

Что делать.. заставляете тряхнуть стариной. Уже не ставил этих серверных виндовс пару лет, 1С ещё дольше. Почти всё подзабыл, так что сильно не ругайте, если что-то не то скажу. Итак, нашёл образ, установил в виртуальную машину VMware, поставил все обновы:



Дальше стал проверять по тексту. И всё в общем-то то же самое. Один в один. Если есть какие-то изменения, то минимум. Почему же не работает? Не знаю, должно работать. И кроме этого всё должно настроится точно по тексту без каких-либо ошибок.

Какие тут были ещё замечания

Первое. Служба Сервера 1C Предприятие не хотела стартовать от текущего пользователя при установке дистрибутива. Пришлось выбрать Создать нового пользователя и всё успешно запустилось. Второе. Сам дистрибутив 1С 8.3.17.1549 и он чисто x64. То есть ставится в папку C:\Program Files, а не в папку C:\Program Files (x86). Соответственно в reg-файлике нужно сделать изменения:

И как уже говорил нужно контролировать что там добавилось в реестр. И добавилось ли вообще. Ветка TSAppAllowList:



В rdp-файлике прописывал не имя сервера, а IP. Потому что мой компьютер не знает какое там имя у виртуальной машины. Прописывать в файл hosts мне было лень.

Запускаю файлик с домашнего компа и вуа-ля:


Другой дистрибутив

Может образ какой-то не тот? Хорошо, скачиваю оценочный образ с Microsoft.

Опять мега долго ставлю обновления.


Версия после обновлений та же самая, что логично.


Скачиваю платформу 1С, версия 8.3.17.1549, но уже x86+x64. Сначала ставлю x86. Проверяю, не работает. Ищу где ошибка. При экспорте reg-файла не создаются ключи Path и ShortPath. Вообще никак. Добавляю руками (смотри картинку выше). Работает.

Теперь x64. Прям в реестре правлю параметры Path и ShortPath. Накатываю дистрибутив прям поверх x86. Проверяю, работает.

Так что в случае проблем припоминай не было ли каких-то варнингов, ошибок, проверяй всё по второму кругу. Должно работать.

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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


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


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

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


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

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


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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

Итак, предположим у нас развернуты AD DS и AD CS. В продуктивной среде, есть смысл подписать сервис коммерческим сертификатом.

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


Я использовал Quick Deploy, а затем доустановил RDS-Licensing. RDS-Gateway я не использую, т.к. у меня единственный сервер обеспечивает работу сервиса.



Этот сертификат я разумеется установил на IIS, и теперь, используя mmc Certificates экспортирую его в .pfx:




Для того, чтобы заменить FQDN на то имя, которое нам надо, воспользуемся известно чем. Убедимся в корректности действия заглянув в .rdp:



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


Сервис будет работать аналогично:


На этом все, в следующий раз расскажу о том, как опубликовать несколько сервисов (Exchange, SharePoint, RemoteApp, PSWA и пр.) на одном IP адресе с помощью Application Proxy.

Читайте также: