Remoteapp windows server 2012 r2 лицензирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Join @AdmNtsRu on Telegram

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. Проверяю, работает.

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

У нас есть новенький активированный Windows Server 2012 R2. Статья будет состоять из двух частей:

1. Установка роли терминального сервера.
2. Лицензирование терминального сервера.

Активация Windows Server 2012 R2 Standard по телефону — для тех кто пропустил этот момент.

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

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

Входим в Server Manager. Справа вверху выбираем Manage -> Add Roles and Features. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation.

Для одного сервера, выбираем Quick Start. Мастер обещает установку сервиса удаленных рабочих столов, настройку Collection и RemoteApp programs. (Я выбирал Standard deployment — процедура немного отличалось от этой.)

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

По сценарию на наш сервер будут добавлены следующие серверные роли:

• RD Connection Broker – контроль подключений пользователей, определяет для какого пользователя на каком сервере будет открыта сессия или запущено приложение.
• Web Access – доступ к приложениям через веб браузер.
• RD session Host – сервер, на котором будут опубликованы приложения и на который пользователи смогут подключаться через удаленный рабочий стол.

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

Позже, во второй части статьи, мы добавим ещё одну роль:

• RD Licensing — сервер лицензий.

После чего начинается «автоматическая» настройка ролей, которая кончается ошибкой настройки Session collection и отменой установки RemoteApp programs. У меня все процедуры закончились «succeeded», здесь скриншот корявый.

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

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

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

Кликаем по третьему пункту, Create session collection. Запускается мастер создания.

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

Выбираем наш сервер, в качестве RD session Host.

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

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

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

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

Перезагружаемся и переходим к второй части.

Лицензирование терминального сервера

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

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

Запускаем Диспетчер лицензирования удалённых рабочих столов (RD Licensing Manager). Выбираем наш сервер, правой кнопкой — активировать.

Открывается окно активации. Жмем Next на первой странице мастера.

Выбираем метод соединения Web Browser.

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

Далее переходим на узел лицензирования удаленных рабочих столов: https://activate.microsoft.com/

Выбираем «Активизация сервера лицензий» и жмем далее.

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

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

Вводим код в открытом мастере, жмём Next.После ввода кода сервера лицензирования появится окно, нужно поставить галку напротив «Запустить мастер установки лицензий».

Переходим на уже знакомый нам узел лицензирования Microsoft, где на этот раз выбираем Установить клиентские лицензии доступа и нажимаем далее. Снова заполнить поля, помеченные (*) теми же данными, что и первый раз. Вставляем License Server ID, в качестве программы лицензирования (License Program) выбираем Enterprise agreement (иначе не получите лицензии).

Выбираем нужные нам лицензии и их количество (можно большое количество). Нужный сервер 2003/2008/2012 лицензии на клиента или на компьютер и т.д.

Обязательно соглашение Enterprise agreement, один из данных номеров 6565792, 5296992, 3325596, 4965437, 4526017 или ищем в интернете который подойдет…

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

Жмём next.

Тут у меня возникла проблема — лицензии не принимались и новые на сайте не генерировались. Нажал Cancel, запустился сервер лицензий. Нажал правой кнопкой и выбрал Install Licenses. Со второго раза всё прошло нормально.

Finish.

Лицензии получились. Но сервер светится желтым:

Ну нажмём Add to grоup, посмотрим что получится.

Continue.

Картинка стала приятнее.

Если теперь посмотреть на RD Licensing Diagnoser, то увидим:

Выполняем gpedit.msc.

gpedit.msc

Откроется окно:

Раскрываем Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing

Редактируем Set the Remote Desktop licensing mode. В поле Specify the licensing mode for the RD Session Host server устанавливаем значение Per Device или Per User в зависимости от установленных вами лицензий.

Сохраняемся, перезагружаемся, проверяем:

Всё зелёненькое, доступные лицензии есть.

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

На основе технического вебинара сделан обзор решений 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

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

В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки сервера терминалов в Windows Server 2008 R2, однако есть ряд значимых отличий. Итак:

Оглавление

1. Что понадобится
2. Установка службы удаленных рабочих столов
3. Определение сервера лицензирования для службы удаленных рабочих столов
4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов
5. Подключение к серверу терминалов

1. Что понадобится

1. Компьютер (сервер) с установленной на нем  Windows Server 2012 (об установки этой ОС, я писал здесь) и права администратора на данном сервере.
2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования. (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера:  6565792, 5296992, 3325596, 4965437, 4526017.)
3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

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

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть» (Open) написать имя команды и нажать «ОК» ).

В меню, в верхнем правом углу, выбираем «Управление» (Manage) — «Добавить роли и компоненты» (Add Roles and Features) .

Запустится «Мастер добавления ролей и компонентов» (Add Roles and Features Wizard). Нажимаем «Далее» (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов» (Role-based or features-based installation) и снова жмем «Далее» (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее» (Next) .

Отмечаем роль «Службы удаленных рабочих столов» (Remote Desktop Services) в списке ролей и жмем «Далее» (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее» (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее» (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов» (Remote Desktop Licensing) (также соглашаемся на установку дополнительных компонент нажав  на «Добавить компоненты» (Add Features) в появившемся мастере)

и «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» (Add Features) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее» (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется» (Restart the destination server automatically if required) , подтвердим выбор нажав «Да» (Yes) в появившемся окне и нажмем «Установить» (Install) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» (Close) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства» (Tools) — «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

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

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов» (Use the specified Remote Desktop license servers) , кликнув  2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено» (Enabled) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК» .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов» (Set the Remote licensing mode) . Также устанавливаем переключатель в «Включено» (Enabled) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

• «На пользователя» (Per User)
• «На устройство» (Per Device)

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

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК» .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов» (RD Licensing Manager) . Найти его можно в диспетчере серверов, вкладка «Средства» (Tools) — «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов» (Remote Desktop Licensing Manager) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован» (Not Activated) . Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер» (Activate Server) .

Запустится Мастер активации сервера. Жмем «Далее» (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто» (Automatic connection) по умолчанию) и жмем «Далее» (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее» (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее» (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее» (Next) оставив включенным флаг «Запустить мастер установки лицензий» .

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

Нажимаем «Далее» (Next) на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement«» . Жмем «Далее» (Next) .

Вводим номер соглашения и нажимаем «Далее» (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее» (Next) .

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

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

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

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

RD Connection Broker

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

хост-сервера

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

Broker-ы

также играют свою роль путем подключения пользователей к серверам RD Session Host по мере загрузки.

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

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

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

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

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

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

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

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

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

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

веб-портала

. Если вы хотите использовать RDS больше, чем в течение

120-дневного

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

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

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

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

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

веб-портала

.

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

При желании использовать развернутые службы удаленного рабочего стола более чем в течение

120-дневного

тестового периода необходимо установить роль RD Licensing, добавить лицензию, зарегистрировать сервер лицензирования с Active Directory, а затем добавить RD Licensing в 

RDS-инфраструктуру

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

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

Серверы, которые вы планируете использовать в своем

RDS-развертывании

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

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

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

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

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

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

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

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

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

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

RDS-развертыванию

.

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