Развертывание remoteapp windows server 2012 r2

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:

redirectclipboard:i:1
redirectposdevices:i:0
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
span monitors:i:1
use multimon:i:1
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
authentication level:i:2
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:0
gatewaycredentialssource:i:0
full address:s:имя_сервера
alternate shell:s:||1cestart
remoteapplicationprogram:s:||1cestart
gatewayhostname:s:
remoteapplicationname:s:1C Предприятие
remoteapplicationcmdline:s:

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

Реестр

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart]
 "CommandLineSetting"=dword:00000000
 "RequiredCommandLine"="" 
 "Name"="1C Предприятие"
 "Path"="C:Program Files (x86)1cv8common1cestart.exe" 
 "ShortPath"="C:PROGRA~21cv8common1cestart.exe" 
 "ShowInTSWA"=dword:00000001
 "SecurityDescriptor"=""

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

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowList] 
 "LicenseServers"=hex(7):00,00 
 "CertificateIssuedBy"="" 
 "LicensingType"=dword:00000005 
 "fHasCertificate"=dword:00000000 
 "CertificateExpiresOn"="0" 
 "CentralLicensing"=dword:00000000 
 "fDisabledAllowList"=dword:00000000 
 "CertificateIssuedTo"="" 
 "CustomRDPSettings"="authentication level:i:2"

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

Когда недавно делал по своей же инструкции, то получил сообщение, что приложения 1С нет в списке разрешенных.

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

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

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart

Она пустая. При копировании текста с сайта могут неправильно переноситься кавычки, ещё что-то. Поэтому нужно подправить/проверить вручную.

1. Path — для 1С 8.3 будет 1cv8common1cestart.exe, для 1С 8.2 1cv82common1cestart.exe
2. ShortPath то же самое.

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

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

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

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

---

Клиенты

Клиенты MAC

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

• Обновляем встроенный в MAC OS X RDP-клиент от MS на последнюю версию;
• Отключаем проверку подлинности.

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

Клиенты Windows XP

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

• SP3 должен быть установлен;
• Включаем проверку подлинности на уровне сети (NLA). Тут обновляем RDP-клиент, потом включаем NLA. Сначала КB969084, ребут, потом FixIt. Скачать.

Клиенты 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 не панацея

В общем и целом remoteapp решение нищебродское, если уж по честному. Плюсом есть очень толстые минусы как RDP, так и remoteapp:

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

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

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

Зачем 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С. У каждого из этих решений свои плюсы и минусы;
3. Используется СУБД и тонкие/веб клиенты. Тогда ничего не надо, стандартные корпоративные каналы достаточно широкие сейчас чтобы переварить такой трафик. Открыть для 1С TCP 1540, 1541, 1560-1591 на FW и вперёд.

Почему 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-файлике нужно сделать изменения:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart]
 "CommandLineSetting"=dword:00000000
 "RequiredCommandLine"=""  
 "Name"="1C Предприятие" 
 "Path"="C:Program Files1cv8common1cestart.exe" 
 "ShortPath"="C:PROGRA~11cv8common1cestart.exe" 
 "ShowInTSWA"=dword:00000001
 "SecurityDescriptor"=""

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

Ветка 1cestart:

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

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

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

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

14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_RU-RU.ISO 

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

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

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

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

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

После того, как развёртывание служб RDS успешно выполнено (RDS на основе сеансов в Windows Server 2012 R2. Часть 1 — Развёртывание в домене), коллекции сеансов созданы и настроены необходимым образом (RDS на основе сеансов в Windows Server 2012 R2. Часть 2 — Создание и настройка коллекций сеансов) и во всех коллекциях опубликованы и сконфигурированы удалённые рабочие столы или приложения RemoteApp (RDS на основе сеансов в Windows Server 2012 R2. Часть 3 — Публикация и настройка удалённых приложений RemoteApp) перед системным администратором возникает задача распространения или, если угодно, доставки программ RemoteApp или удалённых рабочих столов конечным пользователям.

Простая, на первый взгляд, задача не так уж бесхитростна, как кажется на первый взгляд. Ведь пользователи могут получать доступ к опубликованным приложениям 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 и рабочим столам, которая запустит соответствующий мастер. На первом шаге предлагается выбрать способ подключения: с помощью прямой ссылки либо с помощью электронного адреса. Рассмотрим оба случая.

Вариант первый, указание прямой ссылки для подключения. В этом случае указываем ссылку вида https://servername/rdweb/feed/webfeed.aspx и жмём Далее.

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

Вариант второй, использование электронного адреса. Этот вариант доступен на ОС 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. Не без глюков, конечно, но об этом как-нибудь в другой раз.

В ЭТОЙ СТАТЬЕ БУДУТ РАССМОТРЕНЫ СЛЕДУЮЩИЕ МОМЕНТЫ:

1. Процесс публикации приложений RemoteApp
2. Проверка работоспособности приложений RemoteApp
3. Изменение параметров опубликованных приложений RemoteApp
4. Отмена публикации приложений RemoteApp

ПУБЛИКАЦИЯ ПРИЛОЖЕНИЙ REMOTEAPP

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

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

Публиковать можно как предустановленные приложения так и свои собственные. Попробуем опубликовать одно предустановленное (Калькулятор) и одно собственное приложение (Foxit Reader). Для того, чтобы опубликовать встроенное приложение необходимо отметить его и нажать кнопку Далее.

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

Рис.3 — Указание пути к публикуемому приложению RemoteApp

Как видно на рисунке, указание приложения, в данном случае, происходит на сервере RDSH2.

После того, как все приложения отмечены нажимаем кнопку Далее.

Рис.4 — Выбор публикуемых приложений RemoteApp

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

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

Рис.6 — Отчёт о публикации приложений RemoteApp

ПРОВЕРКА ПУБЛИКАЦИИ ПРОГРАММ REMOTE APP

После успешной публикации удалённых приложений RemoteApp, проверим корректность их работы. Для этого осуществим веб-доступ к RDS с одной из рабочих станций домена. Напомню, что для того чтобы получить веб-доступ к службам удалённых рабочих столов необходимо перейти по специальной ссылке вида https://servername/rdweb. В рассматриваемом случае, это ссылкаhttps://rdwh.domain.local/rdweb.

Рис.7 — Веб-доступ к приложениям RemoteApp

Как мы видим, приложения успешно опубликовались и можно попробовать получить к ним доступ. Запустим Foxit Reader.

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

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

На скриншоте выше отображено осуществлённое подключение. Как видим,  несмотря на то, что путь к программе Foxit Reader мы указывали на сервере RDSH2, подключение было выполнено к серверу узлов сеансов RDSH1.

ИЗМЕНЕНИЕ ПАРАМЕТРОВ ПРИЛОЖЕНИЙ REMOTEAPP

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

На вкладке Общие окна свойств приложения доступны следующие настройки:

1. Имя удалённого приложения RemoteApp. Позволяет задать произвольное имя для опубликованного приложения.
2. Показывать удалённое приложение в службе веб-доступа к удалённым рабочим столам. Если выбрать пункт Нет, то приложение не будет отображаться списке приложений на странице веб-доступа и не будет доступно пользователям, хотя будет установлено на серверах узлов сеансов и будет иметь статус опубликованного.
3. Папка удалённого приложения RemoteApp. Этот параметр позволяет упорядочивать приложения RemoteApp, раскладывая их по папкам.

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

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

Как видим, выбранное приложение Foxit Reader было успешно помещено в папку Офисные приложения.

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

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

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

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

Следует помнить об одном очень важном ограничении — данная опция не работает в случае веб-доступа к приложениям.

ОТМЕНА ПУБЛИКАЦИИ ПРИЛОЖЕНИЙ REMOTEAPP

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

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

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

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

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

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

Время прочтения
11 мин

Просмотры 84K

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

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

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

Comments

• 10 Oct 2013 11:20 AM

  If you configure the default RemoteApp URL group policy for users who get their desktop from a remote desktop deployment published desktop, it doesn’t work and you get a warning in the RemoteApp event log:

  The installation of the default connection has been cancelled. A default connection cannot be used on a system that is part of a Remote Desktop Services deployment.

  What’s going on here? Why should this be the case? Seems to make no sense that I can only use this automated method of distributing RemoteApps to users on regular PC desktops, and not published desktops.

• 1 Jul 2013 1:36 PM

  Microsoft was stupid for removing the MSI method.  Seriously what user wants to go to some other website for their app!! Morons I tell you.  You can’t get easier than clicking an icon on the desktop and that is what users want, that is truly a seamless experience.  

• 11 Apr 2013 11:05 AM

  Nice wiki. This is a bit off-topic but maybe someone can help. I published the remoteapps and can run them on my debian clients (using rdesktop) gracefully, but drive redirection won’t work. Is there any policy restricting redirection turned on by default? If yes, what is it?

• 13 Feb 2013 6:09 AM

  Glad I could help. I kept finding on the web about batch files and I figured there had to be another way. Once I stumbled on it, I had to share!

• 6 Feb 2013 1:32 PM

  Hi Jonathan,

  Thanks, good catch! I’ll update the Wiki with the info you supplied!

• 6 Feb 2013 7:27 AM

  Hi Freek, The local exec restriction in the UI is not present when using Powershell to create the remote app.  So for appc running over UNC  path, creating a new remote app through Powershell is the way to go!

  1- Run Powershell as admin

  2- Execute the following command:

  New-RDRemoteApp -CollectionName [collection_name] -DisplayName [remote_app_display_name] -FilePath «\servershareexecutable.exe»

• 29 Jan 2013 2:58 AM

  Hi Jonathan,

  Yes you are supposed to provide a location on the RD Session Host server itself. What I have seen people do is  create a workaround where .cmd file on the RD Session Host Server that Launches the application on the network share. This will probably not be fully supported, so no guarantees there, but below some info on how to configure this:

  Here you see a Remote App (procmon,exe) running: http://bit.ly/TQuGEf

  Here you see that the Remote App points to a exe on a network share: http://bit.ly/TQuxAy

  This is how the .cmd file is configured: http://bit.ly/TQv5GL

  Kind regards,

  Freek Berson

  themicrosoftplatform.net

• 28 Jan 2013 10:35 AM

  Good documentation, I was wondering how to publish an app hosted on a network drive? I keep receiving the following message when I try to select the executable:

  You must specify a file from the RD Session server

  SVTEST.INFO.COM by using the UNC path; for example

  \SVTEST.INFO.COMc$pathfilename.exe.

  If the problem persists, ensure that the following Windows Firewall

  exceptions are enabled:

  1. File and Printer Sharing (SMB-Out).

  1. File and Printer Sharing (SMB-In).

  Note: I have tried using an UNC path to no avail. I believe the issue is related to the bile not being hosted on the RDP server.

• 20 Nov 2012 1:54 PM

  Good documentation ! It use the mstsc’s client to create the icon the desktop ? and it’s a single sign-on I guess, like on the startup menu for the user ?

• 20 Nov 2012 1:54 PM

  Good documentation ! It use the mstsc’s client to create the icon the desktop ? and it’s a single sign-on I guess, like on the startup menu for the user ?

Для того, чтобы дать возможность клиентам работать с базой данных на сервере, но не давать допуск до полноценного RDP-сеанса на удалённом сервере (Windows Server 2012 R2) мы настроим RemoteApp на примере программы «Microinvest Склад Про». Цель этой технологии – ограничить подключение пользователя до рабочего стола и разрешить ему запуск только определенной программы. RemoteApp реализуется с помощью встроенных средств Windows Server, но с помощью стороннего приложения RemoteApp Tool (http://www.kimknight.net/remoteapptool) это можно сделать гораздо быстрее и проще. Рассмотрим способы:

1. Публикация приложения на сервере

Способ №1 (ручное добавление новой ветки в реестр)

• Перейти в редактор реестра (Win+R, regedit)
• Перейти в реестра к ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications
• Cоздать в ней новый раздел с названием нашей программы.

В созданной нами ветке создать несколько параметров:

Name: "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы
Path: "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы
VPath: "C:Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы
RequiredCommandLine: ""
CommandLineSetting: 0x00000001
IconPath: "C:Program Files (x86)MicroinvestWarehouse ProWarehouse.exe"IconIndex: 0x00000000ShowInTSWA: 0x00000000

Способ №2 (создание файла .reg)

• Создать и запустить файл с расширением .reg со следующим содержимым:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplicationsMicroinvest Warehouse Pro]
"Name" = "Microinvest Warehouse Pro"
"Path" = "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe"
""VPath" = "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe"
""RequiredCommandLine" = ""
""CommandLineSetting"= dword:00000001
""IconPath"="C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe"
""IconIndex"= dword:00000000
""ShowInTSWA"= dword:00000000

Создание ярлыка для подключения к RemoteApp

• Создать текстовый файл с именем «ProgramName.rdp» со следующим содержимым:

allow desktop composition:i:1
allow font smoothing:i:1
alternate full address:s:192.168.0.100:3389
alternate shell:s:rdpinit.exe
devicestoredirect:s:*
disableremoteappcapscheck:i:1
drivestoredirect:s:*
full address:s:192.168.0.100:3389
prompt for credentials on client:i:1
promptcredentialonce:i:0
redirectcomports:i:1
redirectdrives:i:1
remoteapplicationmode:i:1
remoteapplicationname:s:Microinvest Warehouse Pro
remoteapplicationprogram:s:|| Microinvest Warehouse Pro
span monitors:i:1
use multimon:i:1

Использование программы RemoteApp Tool

Создание RemoteApp подключения с помощью этой программы происходит гораздо проще и быстрее.

• После установки и запуска программы в стартовом окне нажимаем на «+» в левом нижнем углу

• В следующем окне указываем путь до исполняемого файла exe файла нужной нам программы и нажимаем «Открыть» в правом нижнем углу.

• После этого в стартовом пространстве появится ярлык выбранного нами файла, выделим его и нажмем «Create Client Connection» для начала создания протокола подключения RemoteApp

• Далее откроется окно создания RDP файла, здесь можно изменить настройки подключения или оставить по умолчанию, далее нажимаем «Create» в правом нижнем углу окна.

• Выберем директорию, где будет сохранен файл и укажем для него название и нажмём «Сохранить» в правом нижнем углу

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

• Запускаем файл и вводим учётные данные пользователя удаленной машины для подключения, нажимаем «Ок»

• после чего запустится указанное приложение, в нашем случае: Microinvest Склад Про

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

So I was recently setting up a demo environment in Azure with two servers.  Our goal was to have Remote Web Access and then publish RemoteApps through that so we could give live demos.  The process to setup Remote Desktop Services is much easier in Server 2012 / 2012 R2 thanks to the Add Remove Features Wizard, but there are still some gotcha’s that I encountered and will cover in this blog post.

The first thing was getting the FQDN of the RD Gateway / Web Access server set to our external domain (since it is different). For example we’ll use adatum.internal and adatum.com.au.  For web access it is simply a matter of having a public DNS record and pointing to your web server but getting it working for the RD Gateway requires some PowerShell.  A script from the TechNet Gallery called Change published FQDN for Server 2012 or 2012 R2 RDS Deployment works a treat for Server 2012 and 2012 R2.  Simply go to the directory you have the script in with a PowerShell admin prompt and enter the following;

Set-RDPublishedName "remote.adatum.com.au"

This should now allow clients to see a connecting to a proper server FQDN instead of something like rds-01.demo.adatum.local.

My next issue was when my demo client when to connect it errored out with 0x607 – An authentication error has occurred.  After having a talk with someone in the office I had found out the Session Host server was hosting some demo web apps that ran using HTTPS.  Now I had imported a proper certificate (that hadn’t expired) but still found this issue.  So I opened up mmc.exe added the Certificates snap-in, browsed the computer certificate store and under personal I could see an EXPIRED certificate.  I deleted this but was still getting the error.  So my other trick was to force Terminal Services to no longer try to use that certificate.  To do this I opened up REGEDIT and went to the following key;

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp

In this key I would scroll down until I found SSLCertificateSHA1Hash and deleted the entry (you could also replace the hash with our good certificate).  Once I had done this, I restarted the server for good measure and was then able to connect up to my Remote Apps using Web Access without an issue.

A step by step guide to build a Windows 2012 R2 Remote Desktop Services deployment.

Part 4 – Publishing RemoteApp programs.

If you missed the previous parts:
Step by Step Windows 2012 R2 Remote Desktop Services – Part 3: Adding Session Hosts and Load Balancing session collections
Step by Step Windows 2012 R2 Remote Desktop Services – Part 2: Deploying an advanced setup
Step by Step Windows 2012 R2 Remote Desktop Services – Part 1: Deploying a single server solution

I’ll be using the setup I demonstrated in Part 2 – Deploying an advanced setup because this setup was still on my Windows 8.1 Hyper-V setup. As a reminder, here’s the setup again:

Everything is up & running, so this guide won’t be focusing on building the Remote Desktop Services deployment itself.

Perparing for publishing a RemoteApps collection
By the end of Step 2 in this series I had a Full Desktop session collection fully functioning. To prepare the lab for RemoteApps I can simply click the Full Desktop session collection and click the “Publish RemoteApp programs” link as shown in this screenshot:

Doing so will convert the Full Desktop session collection to a RemoteApp programs collection, as mentioned in the remark below the link.

Publishing a RemoteApps collection
Click the Publish RemoteApp programs link.

Select RemoteApp programs

Immediately you are presented with a list of available applications. If you have multiple servers in the collection pay attention to the text I highlighted in the screenshot.
If you want to publish programs that are not in this list use the Add button to browse to the program you want to publish. Note that you need to browse to a UNC path, not a local disk on the RD Session Host.
I selected Calculator, Paint and Wordpad.

As you can see, Notepad is missing by default.
Click Add.

Open

Browse to \itwrds04c$windowssystem32 and select notepad.exe there.

If I browse to C:WindowsSystem32 and select notepad.exe:

So browse to Notepad.exe using the UNC path and click Open.

Click Next.

Confirmation

On the Confirmation page you can see the UNC path is no longer visible, but is now shown as the actual path.
Click Publish.
The applications you selected will be published.

Completion

Click Close.

Server Manager

You’ll return to Server Manager and you can see the applications that were just published in the RemoteApp programs sections, including basic properties like Alias and Visible in RD Web Access.

Let’s finish the collection.

Finishing the RemoteApp programs collection
Server Manager

In the properties section for the Full Desktop collection click Tasks and then click Edit Properties.

Session Collection

Rename the collection to something more meaningful than “Full Desktop”. Also notice that “Show the session collection in RD Web Access” is now greyed out since it’s no longer a session collection.
Click Next.

User Profile Disks

Review the settings in User Groups, Session, Security and Load Balancing, and adjust the settings in each section to your likings.
In User Profile Disks I changed the profile disks location to a different folder. Although that’s not really necessary in this setup it’s good practice to give each type of collection its own location for profile disks. Especially so if you’re planning for multiple types of collections in a single deployment. The reason I do this is because profile disks can’t be shared across types of collections. That’s right. You can’t. This means that if you have a deployment that supports Virtual Desktop Infrastructure (VDI), Remote Desktop session collection(s) and RemoteApp programs, you’ll have three different profile disks for each user. In deployments with a large number of users you’ll quickly see the need for a nice little tool like Sidder
Click OK.

Now log in to the RD Web Access:

It works, but we’re not done yet.

Editing a RemoteApp program
When we added Notepad.exe in the Wizard it created a RemoteApp called “notepad”. Let’s use this RemoteApp to demonstrate what we can manage for RemoteApps.

Server Manager

In the RemoteApp programs section, right-click notepad and click Edit Properties.

General

On the General page we can edit several attributes for our notepad RemoteApp.
We can change the RemoteApp program name. This is the name that is displayed in RD Web Access. Change this to “Windows Updates Log”.
We cannot change the RemoteApp’s alias here. You can only change the alias by deleting the RemoteApp and re-creating it using Powershell. More on that later.
We cannot change the RemoteApp’s program location here.
We cannot change the current icon here.
We can select to hide or show the RemoteApp in RD Web Access.
And we can select a Folder for the RemoteApp. If you click the dropdown menu you’ll notice it is empty. Don’t worry, just type in the folder name. Enter “Logfiles” here. This is the way to add new folders. If you have created folders before, you can select them using the dropdown menu.
Click Parameters.

Parameters

If your RemoteApp program needs any parameters to run, this is the place to enter them. Enter “c:windowswindowsupdatelog” for this one.
Click User Assignment.

User Assignment

You can fine-grain user assignment on RemoteApp program level. For example, you can publish the complete collection to Domain Users, but limit this application to Domain Admins or Log Admins. In this case the Logfiles RemoteApp folder will be hidden for Domain Users as well, since this is the only application in this folder.
Review the remark in the bottom of the screenshot.
Click File Type Associations.

File Type Associations

You can set desired File Type Associations for your RemoteApp program here. Take notice of the remark when you scroll down. What this means is that associations will only take effect if the RemoteApp is started through “Connected RemoteApp and Desktop Connections”, and not if you start it using custom RDP files, or through RD Web Access.
Since we just changed this one to publish the Windows Update Log, we don’t need any File Type Associations, I’ll get back to this later.
Click OK.

Review the list of RemoteApp programs and notice the change in RemoteApp Program Name:

Refresh or log in to the RD Web Access and review these changes:

Here’s the folder we entered.

Clicking the folder shows the RemoteApp we just published.
Note: if you want to customize views like these, check out another step by step series I am publishing.
Click Windows Updates Log.

Windows Updates Log

And it works.

Using Powershell to manage RemoteApp programs
Get-RDRemoteApp (http://technet.microsoft.com/en-us/library/jj215454.aspx) is used to list properties for RemoteApps.
Example:

Get-RDRemoteApp -alias "wordpad" | fl

Set-RDRemoteApp (http://technet.microsoft.com/en-us/library/jj215494.aspx) is used to set properties for RemoteApps.
Example:

Set-RDRemoteApp -Alias "wordpad" -DisplayName "WordPad - Renamed"

New-RDRemoteApp (http://technet.microsoft.com/en-us/library/jj215450.aspx) is used to create a new RemoteApp in a certain collection.
Example:

New-RDRemoteApp -CollectionName "RemoteApps" -Alias "regedit" -DisplayName "RegEdit" -FolderName "Admin Tools" -FilePath "C:Windowsregedit.exe"

Remove-RDRemoteApp (http://technet.microsoft.com/en-us/library/jj215493.aspx) is used to remove a RemoteApp.
Example:

Set-RDRemoteApp -CollectionName "RemoteApps" -Alias "wordpad"

Get-RDAvailableApp (http://technet.microsoft.com/en-us/library/jj215457.aspx) is used to list available applications to publish in a collection.
Example:

Get-RDAvailableApp -CollectionName "RemoteApps"

Get-RDFileTypeAssociation (http://technet.microsoft.com/en-us/library/jj215461.aspx) lists the filetype association(s) for a certain application.
Example:

Get-RDFileTypeAssociation -AppAlias "wordpad"

Set-RDFileTypeAssociation (http://technet.microsoft.com/en-us/library/jj215459.aspx) is used to set the filetype association(s) for a certain application.
Example:

Set-RDFileTypeAssociation -CollectionName "RemoteApps" -AppAlias "wordpad" -FileExtension ".txt" -IsPublished $True -IconPath "%ProgramFiles%Windows NTAccessorieswordpad.exe" -IconIndex 0

And that concludes this step by step on publishing RemoteApp programs.

In the next part of this series I will show how to use and configure the “Connected RemoteApp and Desktop Connections” in combination with this setup.

Arjan

I’ll show you how you can set up RemoteApp publishing using a single server in less time than it takes to watch an episode of your favorite drama! Honestly, you should be able to hammer this out in less than an hour if you are at all familiar with the new Windows Server Manager. It’s madness (in a good way!). There two things that you will need in place before you start your stop watch:

1. RDS in Windows Server 2012 requires Active Directory, 2003 or newer.
2. One server running a fresh and updated install of Windows Server 2012 joined to that domain.

Once you’ve got that, break out your stop watch. I’ll race you!   From the new Server Manager, click the Manage menu and select Add Roles and Features.

One of many new features that the new Server Manager offers is the introduction of scenario-based installation. Remote Desktop Services is the only scenario installation type available, and that’s exactly what we want to do.

If you really want to see the power of Scenario-Based deployments you’ll want to set up three servers and then try the Standard Deployment method, but to get this done quickly we’ll just use the Quick Start deployment which will put everything on one server.

The Virtual Desktop Infrastructure (VDI) scenario will be used to allow each user to have their very own virtual machine, but we want to deploy the Session Virtualization scenario which is analogous to what everyone thinks of with Terminal Services; multiple user sessions working independently on one server.

The local server you’re connected to should be added to the Selected list by default. Make sure that’s the server you are going to deploy all of the RDS roles onto and click Next. 

On the Confirmation page you’ll have to check the “Restart” option as the installation of the Session Host role requires a reboot. Then click Deploy. 

After the reboot, log back into the server and the Server Manager should resume to show you the status: Succeeded! Click the link at the bottom of the page to view the list of available RemoteApps.

When connecting to the RDWeb page, you’ll get a certificate warning because the quick deployment uses a self-signed certificate which can be replaced later, so click Continue to this web site for now.

You’ll also be prompted to run an Active-X Control which is the mechanism that allows the web site to launch the Remote Desktop client. You can click Allow here, but a Group Policy can be made to allow this automatically.

Once connected, you’ll see a huge list of applications that are published already. This is a result of using the Quick Start deployment, and we’re not going to want to publish all of these Apps, so let’s take care of that right away.

Return to the Server Manager and click on the new “Remote Desktop Services” page on the left, then click on Collections. “Collections” is a new term that describes a set of services that the RDS deployment offers such as a collection of RemoteApps, Desktop Sessions or Virtual Desktops. 

The Quick Start deployment already created a collection for us, but we’ll want to remove it and start from scratch. Right click the QuickSessionCollection and click “Remove Collection. Then from the Tasks button, select Create Session Collection.

Enter a Collection Name, something clever like RemoteApps works well.

Now select your Session Host server and click the arrow to add it to the Selected list. There should only be the one server available here so it’s pretty straight forward.

The default group of users that are allowed to access the applications in this collection will be Domain Users. You can be more specific if you wish, but you can also be more specific on an individual application bases as you publish them later.

To keep things moving quickly, let’s skip the User Profile Disks for now. This is a very cool new feature of Windows Server 2012 (8 beta) that allows users on the session host to have their “local” data get automatically redirected to a different virtual hard drive instead of getting written to the actual session host server, but you can configure that later.Click Next then Create to finish the Collection wizard.

When it’s done, you can click Close.

Now it’s time to publish the applications you really want to give users access to. From the Remote Desktop Services page, select the new RemoteApps collection you made and then from the Tasks button by RemoteApp Programs, select Publish RemoteApp Programs.

You can select a program from the list or click “Add Another Program” to browse to an executable.

When you’re happy with your selection click Publish, then Close.Now refresh the RDWeb page and you’ll see only the applications that you selected.

Click on one of them to connect to the RemoteApp. This prompt is Internet Explorer warning you that the Web Site is trying to start a program on your computer. It’s using the Active-X Control to launch the local RDP client (mstsc.exe). This warning can be suppressed by Group Policy once the web site certificate is replaced, but for now just click Connect. 

Once connected, the application would look just like any locally installed application, but you’ll notice a new system tray icon that show you are connected to a Remote Work Place.

And there you have it, RDS, Quick and Easy on one server in less than an hour.

Now you can install new applications and publish them to your Collection. Just like Windows 2008 R2, you can deliver these RemoteApps from RDWeb or by subscribing to the RemoteApp RSS feed. If you want to make these applications available outside of your organization, the next step will be to deploy the RD Gateway role, or if you want to go bigger, try doing a Standard Deployment to break the roles out to separate servers and add more Session Hosts, the equivalent to a RDS Farm. N’joy!