Rd web access настройка

jameszero.net

Непокорный Web Access

В продолжение публикаций материалов из цикла «Записки системного администратора» или «Случай из практики» мой коллега из Белоруссии volk123 поделился опытом настройки RD Gateway и RD Web Access в сети без домена.

В один прекрасный летний день мне понадобилось настроить удаленный доступ к программам из филиалов в головной офис клиента. Сначала я склонялся к варианту с использованием VPN-подключения, однако мне показалось интересным поработать с технологиями RD Gateway и RD Web Access. Аргументы для использования такого способа доступа – не надо устанавливать ПО для VPN, кроме того подключение через VPN требует открытого порта, что в условиях турецких и белорусских гостевых WiFi становится проблемой, а доступ к программам хотелось бы иметь везде.

Так как RemoteApp у меня уже был настроен и работал, осталось только настроить RD Gateway и RD Web Access.Я не буду утомлять вас подробностями установки- в интернете есть множество инструкций с картинками.

Остановлюсь только на вопросах, которые у меня возникли.

Сразу хочу предупредить, что в организации, о которой идет речь, нет домена, используется простая рабочая группа, правда все узлы имеют DNS суффикс вида company.net. Мне пришлось пробросить 443 порт с роутера на сервер терминалов, где у меня установлены все роли RD. Можно было конечно установить RD Gateway и RD Web Access прямо на роутер, но я решил не усложнять(кроме того роутера на самом деле два, они подключены последовательно, и установка ролей RD на второй роутер ничего бы не решила).

После проброса порта я создал правила RD CAP и RD RAP. Остальные настройки делаются в оснастке RemoteApp Manager. Сразу после настройки я решил подключиться к удаленному рабочему столу. Здесь все оказалось довольно просто, в качестве имени сервера к которому подключаешься надо указать внутреннее имя [1] сервера RDSH, а вот в качестве сервера RD Gateway придется указать внешний IP-адрес [3], поскольку внутренняя сеть без домена и к внешним DNS- именам никакого отношения не имеет.

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

Проблема возникла при попытке использовать RD Web Access. Я сразу опишу ее причину:

Так как Internet Explorer более тщательно относиться к проверке сертификатов, то при моей схеме подключения к RD WebAccess возникает конфликт: в качестве адреса я указываю

Rd web access настройка

Роль RD Gateway не является обязательной ролью, однако, для использования возможности подключения из внешней сети, настройка этой роли необходима. Комплексное описание роли RD Gateway можно найти на technet:

Шлюз удаленных рабочих столов (шлюз RD) позволяет авторизованным пользователям подключаться к виртуальным рабочим столам, удаленным приложениям RemoteApp и рабочим столам на основе сеансов во внутренней корпоративной сети с помощью любого устройства, подключенного к Интернету.

Шлюз удаленных рабочих столов использует протокол удаленного рабочего стола (RDP) поверх протокола HTTPS, что позволяет обеспечить безопасное соединение с шифрованием между удаленными пользователями Интернета и ресурсами внутренней сети, необходимыми для работы пользовательских приложений.

Роль RD Gateway можно использовать как на отдельном сервере, так и совместно с другими ролями службы удаленных рабочих столов. В данном случае роль RD Gateway будет совмещена с ролями Connection Broker + Web Access. Для этого надо установить эту роль на Серверы RDCB1 и RDCB2.

Установка роли Шлюза, довольно проста. Из диспетчера серверов запустить мастер установки кликнув на символ «+«.

Далее выбрать серверы на которых будет установлена роль Шлюза. Добавляем RDCB1 и RDCB2.

Далее потребуется указать CN имя сертификата, который будет использоваться шлюзом для шифрования соединений. Мастер установки автоматически создаст самоподписанный сертификат. Впоследствии его можно будет заменить, но в любом случае укажем то имя, к которому будет происходить обращение пользователей (rd.alekssh.com).

Далее подтверждение выбранной конфигурации и установка. Роль сервера шлюзов установлена.

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

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

Далее необходимо зарегистрировать оба сервера с ролью шлюзов в Active Directory через NPS консоль. Запустить консоль можно «Win+Q — набрать «nps» — выбрать «сервер сетевых политик«. В контекстном меню NPS (Локально) выбрать пункт Зарегистрировать сервер в AD. Далее 2 раза нажать OK. Повторить это на всех серверах с ролью RD Gateway, в данном случае RDCB1 и RDCB2.

Далее поскольку используется балансировка нагрузки DNS Round Robin, необходимо создать дополнительную Политику Авторизации Ресурсов (Resource Auth Policy, RAP). Для этого нужно запустить «Диспетчер шлюза удаленных рабочих столов«. Сделать это можно через «Диспетчер серверов | Средства | Terminal Services | Диспетчер шлюза удаленных рабочих столов».

Создать для каждого из серверов с ролью RD Gateway, дополнительную политику.

Далее в мастере создания новой политики указать имя политики. В моем случае я назвал её «RDCB HA«.

На закладке «Группы пользователей» выбрать группу, которая будет иметь доступ к удаленным приложениям, в моем случае я указываю «Domain Users».

Далее указать группу сетевых ресурсов, в данном случае её нет, надо будет создать. Выбираем пункт «Обзор».

Далее в мастере создания новой группы указываем название, в моем случае «RD GW«.

На закладке «Сетевые ресурсы«, надо указать адрес ресурса, исходя из того что используется балансировка DNS RR, необходимо указать общий адрес балансировки, в данном случае это rd.alekssh.com.

Далее остается только применить эту политику нажав OK.

Важно! Не забыть убедиться что политика доступа создана на обоих серверах RD Gateway

Теперь настройка Шлюза удаленных рабочих столов Завершена.

Информация, используемая при написании статьи.

Виртуализация: Развертывание VDI, основанной на сеансах

Подход, используемый при создании инфраструктуры виртуальных рабочих столов Microsoft (VDI), основанной на сеансах, развертыванием Quick Start, — установка трех служб ролей Remote Desktop Services (RDS) на один сервер — отлично подходит для целей тестирования. Однако в реальной среде необходимо проектировать инфраструктуру, принимая во внимание доступность и возможное будущее расширение.

Значит, следует устанавливать службы ролей RDS (RD Session Host, RD Connection Broker и RD Web Access) на несколько серверов. Чтобы получить доступную инфраструктуру, допускающую расширение, можно взять за основу среду рабочих столов, основанную на сеансах, которая развернута в режиме VDI Standard. При развертывании инфраструктуры рабочих столов, основанной на сеансах, в режиме VDI Standard, выполняются следующие действия:

• Устанавливается служба серверной роли RD Session Host на одном (или нескольких) серверах.
• На один сервер устанавливается служба роли RD Connection Broker.
• На один сервер устанавливается служба роли RD Web Access.
• Обеспечивается взаимодействие между всеми службами ролей RDS, в результате чего создается рабочая среда.

Чтобы начать процесс, добавьте все серверы, участвующие в развертывании, в Server Manager сервера, с которого выполняется развертывание. Откройте Server Manager на этом сервере и щелкните в Dashboard ссылку Add other servers to manage. В окне Add Servers щелкните Find Now, затем нажмите клавишу Control и щелкните каждый сервер-адресат, который нужно выбрать. Затем щелкните кнопку со стрелкой в центре экрана, чтобы переместить эти серверы в панель справа, и, наконец, щелкните OK (рис. 1).

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

Запустите мастер развертывания, щелкнув ссылку Add Roles and Features в Server Manager Dashboard. Щелкните Next в окне Before You Begin. В следующем окне (рис. 2) выберите Remote Desktop Services installation. Затем щелкните Next.

Рис. 2. Чтобы создать инфраструктуру, основанную на сеансах, выберите RDS installation

В следующем окне выберите Standard deployment и щелкните Next. Затем выберите сценарий развертывания Session-based desktop deployment и снова щелкните Next (рис. 3). В следующем окне вы увидите службы ролей, которые будут установлены при развертывании. Если вас все устраивает, щелкните Next.

Рис. 3. Выберите сценарий развертывания в мастере Add Roles and Features

Итак, вы определили, какие серверы будут использоваться, и тип развертывания. Чтобы приступить собственно к развертыванию, начните с RD Connection Broker. Выберите один сервер из пула серверов, на который будет устанавливаться служба роли RD Connection Broker, выделив этот сервер в панели слева, и щелкните стрелку, чтобы переместить его в панель справа. Затем щелкните Next.

Мастер «предполагает», что вы можете установить RD Connection Broker более чем на один сервер, но это не так. Установка не выполнится, если вы выберете для этой роли более одного сервера. Так что выберите один сервер для RD Connection Broker (рис. 3).

В следующем окне выберите в пуле серверов сервер для RD Web Access. Переместите его в панель справа, затем щелкните Next. Затем выберите в пуле серверов (теперь можно выбрать более одного сервера) серверы, на которые вы установите службу роли RD Session Host. Переместите эти серверы в панель справа и щелкните Next (рис. 4).

Рис. 4. Укажите, на каких серверах будут выполняться ваши службы

В следующем окне предлагается подтвердить ваш выбор, а также сообщается, какие серверы потребуется перезагрузить после установки. Щелкните флажок Restart the destination server automatically if required и щелкните Deploy. Начнется процесс развертывания, и вы увидите ход его выполнения на каждом сервере. Если все пройдет успешно, вы увидите окно с сообщением об успешном выполнении развертывания.

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

1. Создать набор сеансов, чтобы определить группу серверов RD Session Host, которые будут действовать как единое целое.
2. Добавить группу (или группы) пользователей, которым разрешен доступ к набору сеансов.
3. Опубликовать RemoteApp или полнофункциональные рабочие столы (full desktop sessions).

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

Если вы откроете Remote Desktop Management Service (RDMS), то не увидите ни одного набора сеансов в Deployment Overview под значком RD Session Host или в разделе Collections. Поэтому необходимо создать такой набор.

В Windows Server 2012 можно публиковать RemoteApp или рабочие столы только для набора сеансов. Убедитесь, что у вас имеется хотя бы один сервер RD Session Host и что вы уже создали учетные записи пользователей домена (и группы пользователей), которым будете предоставлять приложения. Чтобы создать набор сеансов, откройте Server Manager на сервере, с которого вы выполняете развертывание. Щелкните категорию Remote Desktop Services в столбце слева, затем щелкните Collections. В области Collections щелкните раскрывающийся список Tasks и выберите Create Session Collection.

Можно также щелкнуть значок RD Session Host в окне Deployment Overview (рис. 5) и выбрать Create Session Collection. «Прощелкайте» окно Before you begin, чтобы вспомнить обязательные требования. Затем введите имя и описание набора сеансов в окне Name the Collection и щелкните Next. В окне Specify RD Session Host Servers выберите серверы RD Session Host, которые хотите добавить в набор, на панели Server Pool. Добавьте их в панель Selected, щелкнув кнопку со стрелкой, затем щелкните Next.

Рис. 5. Окно Deployment Overview дает общее представление о среде и позволяет выполнить ее настройку

Предоставьте доступ пользователям и группам

Итак, вы создали набор сеансов, теперь надо выбрать пользователей или группы пользователей домена, которым вы предоставите доступ. Группа Domain Users уже добавлена по умолчанию. Можно удалить эту группу, щелкнув ее и выбрав Remove. Щелкните кнопку Add, чтобы открыть диалоговое окно Select Users or Groups. Выберите соответствующих пользователей или группы и щелкните OK.

В следующем окне вам предоставляется возможность настроить User Profile Disks (диски профилей пользователей, UPDs). UPD — новая технология централизованного хранения параметров и данных профилей пользователей. Пока что снимите флажок «Enable user profile disks».

В окне подтверждения вы увидите сводку параметров, заданных вами в мастере. Просмотрите сводку и выберите Create. Когда в окне View Progress будет показано, что мастер завершил настройку, убедитесь, что у обеих операций статус Succeeded и щелкните Close.

Вы можете посмотреть только что созданный набор сеансов в RDMS в разделе Collections. Выберите набор сеансов в панели слева, чтобы посмотреть сведения о нем.

Чтобы протестировать развертывание полнофункциональных рабочих столов, откройте Internet Explorer и перейдите на URL развернутого сервера RD Web Access. Войдите под удостоверениями пользователя, которому разрешен доступ к этой инфраструктуре. Вы увидите значок полнофункционального соединения Remote Desktop. Щелкните значок, затем щелкните кнопку Connect в открывшемся окне, чтобы установить соединение Remote Desktop.

Публикация RemoteApp и рабочих столов

В RDMS в разделе Session Collection Properties в поле Resources по умолчанию указан ресурс Remote Desktop (Удаленный рабочий стол). При публикации RemoteApp «Remote Desktop» в этом поле заменяется на «RemoteApps». В Windows Server 2012 нельзя предоставить доступ и к RemoteApp, и к рабочим столам для одного и того же набора сеансов.

Чтобы опубликовать набор RemoteApp, щелкните ссылку Publish RemoteApp programs в центре раздела RemoteApp Programs. Можно также щелкнуть раскрывающееся меню Tasks и выбрать Publish RemoteApp Programs.

Мастер просканирует сервер и возвратит набор стандартных программ, размещенных на серверах RD Session Host. При публикации RemoteApp на ферме мастер будет сканировать программы для построения списка только на одном сервере. Модель RDS предполагает, что все серверы RD Session Host в наборе настроены одинаковы и на них установлены одни и те же приложения.

Щелкните флажки одной или нескольких программ, которые вы хотите опубликовать как RemoteApp, затем щелкните Next. Кроме того, можно добавить приложения, которых нет в стандартном списке, щелкая Add и выбирая программы, которые нужно опубликовать. Затем мастер покажет диалоговое окно подтверждения, содержащее выбранные вами RemoteApp. Щелкните Publish. Затем убедитесь, что все RemoteApp, показанные в окне Completion, имеют статус Published, и щелкните Close.

В основном экране RDMS для набора сеансов в разделе Properties в поле Resources будет указано RemoteApp Programs. В разделе RemoteApp Programs будут перечислены опубликованные RemoteApp. Тестирование RemoteApp во многом аналогично тестированию опубликованных рабочих столов. Откройте RD Web Access, чтобы начать работу с инфраструктурой. Затем войдите и щелкните один из значков RemoteApp. Щелкните Connect в открывшемся окне (рис. 6). Если приложение откроется, значит, оно успешно опубликовано.

Рис. 6. Если RemoteApp опубликовано, его можно запустить

Горизонтальное масштабирование

Результат развертывания Standard может показаться таким же, как и результат развертывания Quick Start. В обоих случаях становятся доступными рабочие столы или RemoteApp. Однако только при развертывании VDI Standard инфраструктура, основанная на сеансах, предоставляет возможность создать высокодоступную среду. Она позволяет с самого начала развернуть службы ролей RDS на нескольких серверах.

Чтобы расширить инфраструктуру, можно добавить дополнительные серверы RD Web Access и RD Session Host. Щелкните значок в панели RDMS Deployment Overview и выберите Add RD Web Access Servers или Add RD Session Host Servers. Выберите в Server Pool серверы, которые вы хотели бы добавить, переместите их в панель Selected и щелкните Next. В окне Confirmation щелкните Add. Если вы добавили сервер RD Session Host, потребуется перезагрузка, поэтому убедитесь, что на странице подтверждения установлен флажок Restart the Computer as Needed.

После завершения установки можно добавить только что созданные серверы RD Session Host в набор сеансов. Выберите набор сеансов в RDMS в разделе Collections. В разделе Host Servers откройте меню Tasks и выберите Add RD Session Host Servers. Выберите сервер в Server Pool, добавьте его в панель Selected, щелкнув кнопку со стрелкой, расположенную в центре, затем щелкните Add.

Теперь вы знаете, как развернуть VDI, основанную на сеансах, в режиме Standard и как опубликовать соединения с рабочими столами или с RemoteApp для этой инфраструктуры. В следующий раз мы расскажем о том, как осуществлять дальнейшую настройку и управление инфраструктурой, основанной на сеансах, с помощью RDMS.

Rd web access настройка

Remote Desktop Connection Broker

Пусть имя нашего домена – domain . local . Для доступа к терминальным службам снаружи будет использоваться доменное имя domain . ru . Таким образом, в нашем DNS домена domain . local нам необходимо будет создать дополнительную зону с именем domain . ru , где мы потом создадим запись RDS . domain . ru , которая будет ссылаться на IP адрес терминальной фермы.

1. Установка терминальных служб на сервер RDS 1.

1.1 Добавляем роли «Службы удаленных рабочих столов» ( Remote Desktop Services ) и «Службы политики сети и доступа» ( Network Policy and Access Services ). Выбираем для установки следующие службы ролей:

— Узел сеансов удаленных рабочих столов ( Remote Desktop Session Host )

— Шлюз удаленных рабочих столов ( Remote Desktop Gateway )

— Веб-доступ к удаленным рабочим столам ( Remote Desktop Web Access )

— Сервер политики сети ( NPS )

При установке служб ставим галочку « Require NLA », остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.

1.2 Создадим в ДНС нашего домена запись RDFarm . domain . local , которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB .

1.3 Создадим в ДНС зоне domain . ru нашего домена запись RDS . domain . ru , которой присвоим тот же IP адрес, что и адрес кластера — 192.168.0.80. Это будет внешний адрес нашей фермы, через который будут заходить удаленные пользователи.

1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:

На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации ( CA ). На сервере RDS 1 запустите mmc и добавьте оснастку Certificates ( computer account ):

После получения сертификата экспортируйте его в pfx -файл – он нам понадобится для настройки второго сервера.

Теперь на закладке Digital Signature мы можем указать наш сертификат:

1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.

Нажмем кнопку « Properties » и добавим в список пользователей, которые смогут запускать наш Калькулятор, группу rd _ users .

1.6 Заходим в оснастку Remote Desktop Services – RD Gateway Manager и настраиваем свойства RDS 1 ( Local ). Но перед этим необходимо запросить еще один сертификат (см. пункт 1.4), но на сей раз с Common Name внешнего адреса – RDS . domain . ru .

На закладке Private Key не забудьте указать, что ключ может быть экспортирован.

После получения сертификата экспортируйте его в pfx -файл – он нам понадобится для настройки второго сервера.

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

Переходим на закладку Server Farm , где добавим наш сервер RDS 1 в ферму шлюзов:

Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».

1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS 1 ( Local ) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:

Добавим в список авторизованных для подключения пользователей группу rdg _ users , куда включим всех тех, кому надо получить доступ к терминальным сервисам.

1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):

1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом :

Нажимаем на кнопку « Select » и указываем сертификат с Common Name нашей фермы – RDFarm . domain . local (он уже был установлен на сервер в пункте 1.4).

Остальные параметры не настраиваем.

Здесь же, в RD Session Host Configuration , настраиваем параметры лицензирования.

1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес https://localhost/RDWeb

2. Установка терминальных служб на сервер RDS 2.

2.1 Добавляем роли «Службы удаленных рабочих столов» ( Remote Desktop Services ) и «Службы политики сети и доступа» ( Network Policy and Access Services ). Выбираем для установки следующие службы ролей:

— Узел сеансов удаленных рабочих столов ( Remote Desktop Session Host )

— Шлюз удаленных рабочих столов ( Remote Desktop Gateway )

— Веб-доступ к удаленным рабочим столам ( Remote Desktop Web Access )

— Сервер политики сети ( NPS )

При установке служб ставим галочку « Require NLA », остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.

2.2 Настраиваем второй сервер RDS 2 точно таким же образом, как и настроен наш первый сервер за исключением того, что сертификаты уже запрашивать не нужно – их надо импортировать с сервера RDS 1. Для импортирования сертификатов запустите mmc и добавьте оснастку Certificates ( computer account ):

Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS 2.

3. Создание и конфигурирование терминальной фермы.

3.1 Устанавливаем роль RD Connection Broker на сервер BROKER .

3.2 Добавляем сервера RDS 1 и RDS 2 в локальную группу Session Broker Computers на сервере BROKER .

3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS 1 и RDS 2

3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access ( Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).

3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:

3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS 1 и RDS 2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name :

3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:

Добавляем все наши возможные ресурсы RemoteApp : RDFarm . domain . local , RDS 1. domain . local , RDS 2. domain . local и RDS . domain . ru .

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

3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS 1 и RDS 2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS 1 и создаем кластер:

Включаем в балансировку только 443 и 3389 TCP порты.

3.8.2 Добавляем второй компьютер ( RDS 2) в NLB кластер

3.9 Удостоверяемся, что на серверах RDS 1 и RDS 2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:

3.10 На серверах RDS 1 и RDS 2 заходим в оснастку IIS Manager , далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings , где присваиваем параметру DefaultTSGateway значение RDS . domain . ru :

4. Публикация фермы RemoteApp приложений на ISA Server .

Вначале необходимо установить наш сертификат с Common Name « RDS . domain . ru » на ISA сервер (сделать это можно так же, как в случае с сервером RDS 2, когда мы переносили на него сертификат с RDS 1).

Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB -прослушивателя:

Варианты работы через Интернет

Работа групп пользователей, территориально находящихся в разных местах, над одной моделью в Business Studio может быть организована через Интернет. Для этого необходимо обеспечить взаимодействие 1) различных компонентов Business Studio друг с другом (Рис. 1).

Необходимо использовать клиент-серверный вариант установки Business Studio. Обязательными частями являются сервер баз данных и сервер лицензий Business Studio:

Сервер баз данных — компьютер, на котором установлен MS SQL Server и развернуты базы данных;

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

Внимание!

С рабочей станции, на которой установлена клиентская часть Business Studio, необходимо обеспечить доступ к серверу баз данных со скоростью 100 Мбит/с для комфортной работы и доступ к серверу лицензий со скоростью не менее 128 Кбит/с.

Внимание!

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

В случае работы с локальной базой данных (например, ноутбук, на котором установлена персональная лицензия Business Studio без активации) необходимо обеспечить доступ только к серверу лицензий со скоростью не менее 128 Кбит/с.

Для работы с Business Studio Portal (см. Business Studio Portal) или HTML -публикацией (см. HTML-публикация) особых скоростных характеристик от канала связи не требуется.

Терминальный доступ

Возможно также организовать работу с использованием терминального доступа (подключение к удалённому рабочему столу). Для этого необходимо обеспечить доступ терминал-сервера к серверу баз данных со скоростью не менее 100 Мбит/с и к серверу лицензий Business Studio со скоростью не менее 128 Кбит/с. На терминал-сервере устанавливается клиентская часть Business Studio и всё необходимое для её работы программное обеспечение. Терминал-сервер должен быть достаточно мощным для комфортной одновременной работы требуемого количества пользователей. Терминал-клиент осуществляет доступ к терминал-серверу с помощью соответствующего программного обеспечения. Рекомендуемая скорость подключения клиента — 2 Мбит/с.

Работа через веб-браузер

Business Studio не имеет собственного веб-интерфейса, однако с помощью Microsoft Remote Desktop Services, развернутого на терминал-сервере, можно организовать работу через веб-браузер и/или по протоколу HTTPS любого приложения, в том числе Business Studio, по тому же принципу, как работает удаленный рабочий стол (или RemoteApp) 3) . Ниже приведено краткое описание данного функционала со ссылками на документацию Microsoft.

Состав Remote Desktop Services (RDS):
1. RD Session Host — это сам терминальный сервер с сессиями или опубликованными приложениями RemoteApp.
2. RD Connection Broker — посредник соединений. Он перенаправляет соединения, осуществляет балансировку сессий между хостами (терминальными серверами) и прочее.
3. RD Gateway — шлюз, для подключения пользователей за пределами периметра.
4. RD Web Access — веб интерфейс пользователя для служб удаленных рабочих столов.
4.1 Remote Desktop web client (также он называется Web-based) — дополнительный компонент к роли RD Web Access, он позволяет подключаться к сессиям и RemoteApp через браузер без клиента RDP (mstsc), подробнее о нем см. https://docs.microsoft.com/ru-ru/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin
5. RD Licensing — служба лицензирования. Раздает лицензии на терминальные подключения и прочее.

На текущий момент возможно 2 варианта реализации:

1. Реализация шлюза удаленного рабочего стола без какого-либо локального клиента RDP.

Возможность реализации такого решения появилось в Windows server 2016. На сервер устанавливаются необходимые роли и он становится шлюзом удаленных рабочих столов RDP (RD Gateway). Происходит подключение по HTTPS к странице Remote desktop access, в результате возможна дальнейшая работа в браузере без какого либо локального клиента RDP через Remote Desktop web client.

2. Реализация шлюза удаленного рабочего стола RD Web Access с локальным клиентом RDP (mstsc).

Начиная с Windows Server 2008R2 есть реализация шлюза удаленного рабочего стола RD Web Access, но с локальным клиентом RDP (mstsc), этот вариант существует достаточно давно. Подключение осуществляется клиентом mstsc к шлюзу удаленных рабочих столов (RD Gateway) по https. Метод позволяет получать как отдельное приложение с терминального сервера в «бесшовном» виде, так, как будто оно запущено локально, так и рабочий стол целиком.

Оба варианта реализации (с Remote Desktop web client и c локальным RDP-клиентом mstsc) с точки зрения пользователя выглядят так: пользователь вводит url (например rds.domain.ru) и его перенаправляет на страницу Remote desktop access шлюза удаленных рабочих столов (RD Gateway). После ввода учетных данных пользователь получает список доступных приложений и рабочих столов.

Использование виртуальных машин

Как клиентская, так и серверная части Business Studio могут быть установлены на компьютерах, созданных с применением любого программного обеспечения, эмулирующего компьютер (виртуальные машины). Активация на виртуальных машинах производится с помощью онлайн-лицензий. Онлайн-лицензия — лицензия, возможность использования которой контролируется через сеть «Интернет». Онлайн-лицензия предназначена для использования только на одном экземпляре виртуальной машины. При обнаружении одновременного использования онлайн-лицензии Группа компаний «Современные технологии управления» вправе приостановить её действие.