Службы терминалов Windows позволяют осуществить полноценную публикацию приложений
Когда речь идет о публикации приложений на основе служб терминалов, обычно подразумевается, что приложение, запущенное в терминальной сессии, выглядит так же, как если бы оно выполнялось локально на клиентском компьютере. При этом в роли оболочки терминальной сессии выступает не стандартный рабочий стол, а само опубликованное приложение. Аутентификация при подключении к терминальному серверу отсутствует, поскольку выполняется автоматически с данными предопределенной учетной записи. Когда пользователь закрывает приложение, завершается и соответствующая терминальная сессия.
Имеется ряд обстоятельств, при которых публикация приложений предпочтительна. Так, неподготовленным пользователям работать с опубликованным приложением проще, чем с удаленным рабочим столом. Отсутствие в пользовательских терминальных сессиях рабочего стола с его многочисленными элементами управления повышает безопасность решений на базе служб терминалов. Более экономно расходуются серверные ресурсы, главным образом оперативная память. И наконец, опубликованные приложения удобно размещать на Web-страницах с доступом к ним из браузера Internet Explorer посредством клиентских компонентов ActiveX службы терминалов.
Службы терминалов Windows и Citrix Metaframe
Службы терминалов Windows, работающие по протоколу RDP (Remote Desktop Protocol), пока уступают по своим возможностям продукту Citrix Metaframe, в основе которого лежит протокол ICA (Independent Computing Architecture). Например, Metaframe поддерживает режим эмуляции локальных окон (seamless windows), а службы терминалов Windows — нет. В случае RDP-соединения приложение всегда запускается в окне терминальной сессии. Размер окна приложения можно изменить, можно развернуть окно приложения на все окно терминальной сессии, но размер окна терминальной сессии остается постоянным. Если в процессе работы будут открыты новые окна приложений, то они также будут находиться в пределах окна терминальной сессии (см. экран 1).
 |
| Экран 1. Несколько окон приложений в одном окне терминальной сессии |
Режим эмуляции локальных окон в Citrix Metaframe позволяет запускать опубликованное приложение в отдельном окне, без видимых отличий от приложения, открытого на клиентском компьютере локально. Преимущество довольно существенное, более того, иногда приходится встречать утверждение, что публикация приложений средствами служб терминалов Windows невозможна.
Единственным фактором, свидетельствующим не в пользу Metaframe, является высокая стоимость продукта и клиентских лицензий. Службы терминалов Windows находятся здесь в лучшем положении, поскольку входят в состав Windows 2000 Server и Windows Server 2003, причем лицензии терминального доступа к Windows 2000 Server предоставляются бесплатно, если в качестве клиентов используются рабочие станции с операционной системой Windows 2000 и выше.
Настройки служб терминалов Windows
Для того чтобы опубликовать приложение с помощью служб терминалов Windows (в дальнейшем — «службы терминалов»), обычно достаточно выполнить следующие настройки: указать полный путь к исполняемому файлу приложения, которое будет запущено вместо удаленного рабочего стола, а также данные учетной записи для автоматической аутентификации. Необходимые настройки могут быть выполнены как на стороне клиента службы терминалов, так и на сервере в консоли Terminal Services Configuration. Также можно изменить параметры учетной записи пользователя, относящиеся к терминальным подключениям.
 |
| Экран 2. Дополнительные объекты Connection в окне Terminal Services Configuration |
Хотя клиентские настройки и позволяют решить задачу публикации приложений, данное решение не отвечает требованиям удобства администрирования и безопасности. Например, если на терминальном сервере опубликованное приложение будет переустановлено в другую папку либо будут изменены реквизиты учетной записи для автоматической аутентификации, соответствующие изменения потребуется внести на всех клиентских рабочих станциях. Определение параметров терминальных сессий на сервере свободно от этих недостатков, поскольку настройки сервера имеют приоритет перед клиентскими настройками. Централизованное управление публикацией приложений повышает защиту служб терминалов, и, кроме того, если опубликованное приложение должно появляться в окне браузера Internet Explorer, то это единственное решение.
К сожалению, здесь возникает новая проблема. Дело в том, что параметры терминальных сессий определяются на сервере в свойствах объекта Connection, доступного в консоли Terminal Services Configuration. Поскольку каждому сетевому интерфейсу можно сопоставить не более одного объекта Connection, это означает, что на терминальном сервере можно опубликовать столько приложений, сколько сетевых адаптеров установлено физически. Помимо этого, для каждого сетевого адаптера потребуется выделить IP-адрес, выполнить его подключение к сетевому оборудованию и т. д. Даже если на терминальном сервере с одним сетевым адаптером опубликовано единственное приложение, становится невозможным использование терминальных служб для других задач, например для удаленного администрирования. Можно ли добавлять объекты Connection как-нибудь иначе, не устанавливая в терминальный сервер новых устройств?
Несуществующие сетевые интерфейсы и служба RRAS
Оказывается, можно, но потребуется применить довольно нестандартную настройку сетевой конфигурации и службы RRAS (Routing and Remote Access Service). Сначала добавим в систему фиктивные «сетевые адаптеры» типа Microsoft Loopback Adapter. Это позволит создать в конфигурации службы терминалов новые объекты Connection и привязать каждый из них к своему «сетевому адаптеру». Затем мы воспользуемся возможностями службы RRAS для маршрутизации обращений из локальной сети к фиктивным «сетевым адаптерам». Рассмотрим данный способ более подробно.
 |
| Экран 3. Правила перенаправления IP-пакетов в протоколе NAT |
Используя мастер установки оборудования, следует добавить в систему одно или несколько «устройств» типа Microsoft Loopback Adapter (по числу приложений, планируемых для публикации). В процессе установки необходимо указать, что устройство будет выбрано вручную, далее в списке классов устройств нужно выбрать Network Adapters, а в списке производителей — Microsoft. Для установки следующего «устройства» процедуру требуется повторить. По окончании установки обязательна перезагрузка сервера, хотя прямого указания на это нет.
Теперь, если открыть папку Network and Dial-up Connections, то кроме основного подключения можно увидеть одно или несколько дополнительных, созданных на основе фиктивных сетевых адаптеров. Их следует настроить: в свойствах каждого подключения на закладке General нужно сбросить все флажки, относящиеся к сетевым клиентам, протоколам и службам, за исключением Internet Protocol (TCP/IP). В свойствах протокола TCP/IP необходимо указать IP-адрес и маску подсети из диапазона не используемых в организации локальных IP-подсетей. При этом IP-адреса и маски подсети, назначаемые для каждого подключения, должны образовывать неперекрывающиеся подсети. В приведенном ниже примере фиктивным сетевым адаптерам были назначены адреса 192.168.2.1 и 192.168.2.5 с масками подсетей 255.255.255.252.
Основное подключение по локальной сети также требует настройки. Следует выделить из числа адресов локальной IP-подсети, к которой подключен терминальный сервер, дополнительные IP-адреса по числу добавленных фиктивных сетевых адаптеров. Затем нужно открыть окно свойств протокола TCP/IP, нажать кнопку Advanced и добавить IP-адреса на закладке IP Settings.
Теперь в конфигурацию служб терминалов можно добавить новые объекты Connection. Необходимо запустить консоль Terminal Services Configuration, открыть свойства существующего подключения RDP-Tcp, перейти на закладку Network Adapter и вместо режима по умолчанию — All network adapters configured with this protocol — выбрать из списка физически установленный на сервере сетевой адаптер. Далее, используя мастер Terminal Services Connection Wizard, нужно добавить один или несколько новых объектов Connection, выбирая для каждого из них свой «сетевой адаптер» Microsoft Loopback Adapter. В результате должна получиться конфигурация, подобная показанной на экране 2. Настройку параметров терминальных сессий можно выполнить сразу или позднее.
Осталось настроить службу RRAS для перенаправления пакетов, приходящих на дополнительные IP-адреса сетевого интерфейса, во внутреннюю сеть терминального сервера. Для этого требуется открыть консоль Routing and Remote Access, и, если служба RRAS не была сконфигурирована ранее, выбрать локальный сервер, в меню Action запустить Configure and Enable Routing and Remote Access и при выборе конфигурации указать Network Router. Нам предстоит добавить и сконфигурировать службу NAT, так как именно она обеспечит видимость внутренних «сетевых адаптеров» из «внешней» локальной сети. Для этого в разделе IP Routing нужно выделить General и в меню Action выбрать New Routing Protocol... — Network Addtess Translation (NAT). При настройке следует указать, какие подключения являются внешними, а какие — внутренними. Необходимо добавить все подключения на основе Microsoft Loopback Adapter как внутренние (Private interface connected to private network), а подключение сетевого адаптера к локальной сети — как внешнее (Public interface connected to the Internet). Следует открыть свойства внешнего подключения, перейти на закладку Address Pool и в списке адресов указать основной и все дополнительные IP-адреса локальной сети, назначенные сетевому адаптеру терминального сервера. При добавлении в список единичных адресов (не подсетей) требуется в полях Start Address и End Address указать один и тот же адрес, а поле Mask не заполнять. Далее на закладке Special Ports нужно настроить правила перенаправления пакетов, по аналогии с примером на экране 3.
 |
| Экран 4. Seamless Client Publisher — средство публикации приложений |
Здесь 192.168.2.1 и 192.168.2.5 — это IP-адреса «устройств» типа Microsoft Loopback Adapter, 10.0.2.11 и 10.0.2.12 — дополнительные адреса локальной сети, привязанные к сетевому адаптеру, а порт 3389 — стандартный порт служб терминалов Windows. Иными словами, все подключения от клиентов служб терминалов по дополнительным IP-адресам перенаправляются на соответствующие фиктивные сетевые адаптеры. Правила перенаправления допустимо настраивать только для дополнительных IP-адресов, иначе перестанет функционировать объект Connection, связанный с основным физическим сетевым адаптером.
Таким образом, клиентские запросы на подключения, приходящие на разные IP-адреса, будут обрабатываться разными объектами Connection, каждый из которых обладает собственным набором параметров терминальных сессий. Приведенный пример показывает, что некоторые ограничения служб терминалов могут успешно преодолеваться за счет средств конфигурации, предоставляемых прочими службами Windows.
Другие параметры терминальных сессий
Из других параметров терминальных сессий важными для публикации приложений являются те, что определяют поведение сессии при простое и разрыве соединения. Так как пользователь получает опубликованное приложение в окне терминальной сессии, по окончании работы с приложением можно сделать следующее: закрыть приложение (как следствие, будет завершена терминальная сессия) либо закрыть окно терминальной сессии (или окно Internet Explorer, если приложение опубликовано на Web-странице). Практика показывает, что пользователи обычно выбирают второе. В этом случае терминальная сессия переходит в отключенное состояние, но не завершается, а приложение в отключенной сессии продолжает выполняться. Параметры тайм-аута, определяемые на сервере, должны устанавливать минимально возможное время завершения сессии при разрыве соединения. Кроме того, имеет смысл задать достаточно большое, но конечное значение, ограничивающее время бездействия в сессии.
Терминальные службы и эмуляция локальных окон
И все же, оставаясь в рамках протокола RDP, можно ли получить опубликованное приложение как оно есть, без фона в виде окна терминальной сессии? Стандартные средства служб терминалов не позволяют этого сделать. Но в действительности эмуляция локальных окон является в большей степени функцией клиента, а не сервера и протокола. Вот один из возможных методов.
Из общего потока данных RDP клиент служб терминалов выделяет лишь содержимое открытых окон в терминальной сессии, все остальные данные игнорируются (см. рис. 1).
 |
| Рисунок 1. Публикация приложений средствами клиента служб терминалов |
Клиент формирует на локальном рабочем столе окно или окна, размеры и расположение которых в точности совпадают с открытыми окнами в терминальной сессии. Это геометрическое соответствие непрерывно поддерживается в процессе перемещения окон, изменения их размеров и т. п. Информация, находящаяся в области открытых окон в терминальной сессии, один к одному отображается в подготовленные окна на рабочем столе клиентского компьютера. В результате у пользователя создается ощущение локальной работы с опубликованным приложением.
Очевидно, что представленное решение требует перестройки исключительно клиента служб терминалов. Ни сервер, ни протокол в каких-либо модификациях не нуждаются. В чистом виде такой подход реализован в программе AppliDis Seamless Client французской компании InfoStance. Программа замечательна еще и тем, что при ограничении не более пяти одновременных подключений официально разрешено пользоваться ею бесплатно. Рассмотрим возможности программы более подробно.
Программа AppliDis Seamless Client устанавливается на терминальном сервере Windows 2000 Server или Windows Server 2003. В процессе установки появляется компоновщик Seamless Client Publisher (см. экран 4), который позволяет настраивать предназначенные для публикации приложения. Для каждого приложения можно определить путь к исполняемому файлу, параметры командной строки, домен или локальный сервер, производящий аутентификацию, а также параметры цветовой палитры и перенаправления внешних устройств. После добавления записи в список опубликованных приложений создается компактный (не более 300 Кбайт) исполняемый файл, помещаемый в общий каталог ClientsSeamless. Программный код, содержащийся в файле, осуществляет подключение и запуск заданного приложения в терминальной сессии, но не содержит никаких средств настройки, поэтому в случае изменения параметров опубликованного приложения компоновщик пересоздает файл. Такие файлы можно запускать из общей папки, переносить на рабочие станции, помещать на Web-сервер и т. п.
Опубликованное приложение запускается на клиентском компьютере в отдельном окне без видимых атрибутов терминальной сессии. Если приложение порождает новую задачу, она запускается в своем собственном окне, но в той же самой терминальной сессии. Для подключения к опубликованному приложению необходимо ввести имя пользователя и пароль для аутентификации на терминальном сервере. Имеется режим, позволяющий сохранить введенные реквизиты на рабочей станции в профиле пользователя. В качестве клиентов поддерживаются версии Windows 9x/Me/NT/2K/XP.
Для своей работы программа требует наличия ActiveX-компонента msrdp.ocx версии не ниже 5.2 на всех клиентах и по возможности на сервере. Распространять данный компонент можно различными способами. Например, установить на Web-сервер IIS в локальной сети программное дополнение Remote Desktop Web Connection, последнюю версию которого можно найти на сайте Microsoft. Тогда для установки ActiveX-компонента на клиентских компьютерах достаточно запустить Internet Explorer, обратиться по адресу: http:///tsweb (где вместо следует подставить имя или адрес сервера IIS) и подтвердить загрузку компонента.
Загрузить программу AppliDis Seamless Client можно по адресу. Описанное решение наглядно отражает ситуацию на конкурентном рынке программных продуктов, где качественный сервис предлагается за большую цену, а менее дорогие решения, хотя и справляются с поставленной задачей, но с теми или иными ограничениями. В то же время, как видно из рассмотренного примера, протокол RDP и службы терминалов Windows не имеют принципиальных ограничений по осуществлению полноценной публикации приложений.
Олег Ржевский (osr@trust.ru) — руководитель проекта в Инвестиционном банке ТРАСТ, к.ф-м.н. Имеет сертификат MCSE.
