OSzone.net: Виртуализация презентаций с помощью усовершенствованных служб терминалов

Виртуализация – популярный термин в наши дни, хотя большую часть времени пользователи думают, что он относится только к виртуальным компьютерам и виртуализации операционных систем. Однако, службы терминалов абстрагировали уровень представления удаленно выполняемых приложений и настольных компьютеров, начиная с выхода Windows NT 4.0. Службы терминалов прошли большой путь с того времени и Windows Server 2008 предоставляет зрелую, основательную платформу виртуализации презентаций. Я сфокусируюсь на ключевых областях улучшений в службах терминалов.

Что нового в службах терминалов

У служб терминалов в Windows Server 2008 имеется новых компонентов и возможностей:

Terminal Services RemoteApp Одним из больших изменений в Windows Server 2008 является возможность сделать удаленном единственное приложение. В предыдущих версиях служб терминалов, передавался весь удаленный рабочий стол, даже если требовался лишь доступ к единственному приложению. Это часто путало пользователей, поскольку некоторые приложения появлялись на удаленном рабочем столе (через службы терминалов), а некоторые на локальном рабочем столе – и запомнить, на каком рабочем столе находилось какое приложение было непросто. Теперь приложения, доступ к которым производится через службы терминалов, выглядят и ведут себя так, как если бы они работали на локальном компьютере конечного пользователя.

Веб-клиент служб терминаловВсем хочется предоставить конечным пользователям простой способ запускать приложения. Веб-клиент служб терминалов удовлетворяет эту потребность, позволяя администраторам публиковать отдельные приложения на веб-странице. Веб-клиент служб терминалов включает веб-страницу по умолчанию, которую можно развернуть прямо в начальной конфигурации, но также может быть модифицирован и включен в веб-узел SharePoint. Чтобы запустить TS RemoteApp с помощью веб-клиента служб терминалов, пользователь посещает веб-страницу (доступную из Интернета или интрасети), видит список всех доступных приложений и щелкает на то, которое хочет запустить.

В Windows Server 2003, чтобы сделать возможным подключение из обозревателя требовался отдельный элемент управления ActiveX, именуемый Remote Desktop Web Connection (RDWC). Теперь элемент управления был встроен прямо в основной клиент Remote Desktop Connection (RDC), так что ничего не требуется загружать или устанавливать на клиенте. Более того, поддерживается полный набор функций протокола удаленного рабочего стола (Remote Desktop Protocol – RDP), что не делал клиент RDWC.

Шлюз служб терминалов Шлюз служб терминалов – один из наиболее значительных новых компонентов Windows Server 2008. Трафик RDP проходит через порт 3389 и одной из крупных проблем, с которой сталкивались администраторы при развертывании сервера терминалов для пользователей извне брандмауэра была необходимость либо открыть порт в брандмауэре (не рекомендуется), либо использовать отдельное решение VPN (дорого). Благодаря шлюзу служб терминалов, трафик RDP туннелируется через HTTPS (порт 443) для установки зашифрованного соединения между удаленными пользователями в Интернете и сервером терминалов (или удаленным ПК). Что еще лучше, такой сценарий отлично срабатывает даже если пользователь или сервер терминалов расположен за основанным на пересечениях маршрутизатором преобразования сетевых адресов ( NAT).

Шлюз служб терминалов может быть соединен с другим компонентом Windows Server 2008 — защитой доступа к сети (NAP), чтобы помочь в обеспечении работоспособности клиентских компьютеров перед выдачей доступа к ресурсам служб терминалов.

Посредник сеансов служб терминалов Windows Server 2000 представил нам балансировку сетевой нагрузки (NLB), но хотя она действительно хорошо работала для веб-серверов, она не была идеальна для балансировки загрузки служб терминалов. Новый посредник сеансов служб терминалов предоставляет отличную альтернативу, путем расширения возможностей каталога сеанса Windows Server 2003, чтобы сделать возможной балансировку нагрузок на основе сеанса.

При использовании посредника сеансов служб терминалов, новые сеансы распределяются на наименее загруженный сервер в ферме и пользователям не нужно знать, где был установлен сеанс, чтобы подключиться к существующему сеансу. ИТ-руководители могут использовать эту функцию для сведения IP-адресов каждого из серверов терминалов в единую запись DNS. Такая конфигурация может также предоставлять устойчивость к сбоям; если один из серверов фермы недоступен, пользователи подключатся к следующему наименее загруженному серверу в ферме.

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

Когда пользователь желает распечатать что-то из программы TS RemoteApp или настольного сеанса, ему выводится диалоговое окно полных свойств принтера от локального клиента и он получает доступ ко всем функциям принтеров (таким, как водяные знаки, сортировка и сшивание). Когда пользователь печатает что-то, задача печати визуализируется на сервере с помощью файлового формата Microsoft XPS и отсылается клиенту. Вдобавок, при применении быстрой печати служб терминалов администраторы могут использовать групповую политику для ограничения числа перенаправляемых принтеров принтером по умолчанию, тем самым понижая издержки и улучшая масштабируемость.

Таковы появившиеся в Windows Server 2008 компоненты с «большим именем». Мы вернемся к TS RemoteApp, веб-клиенту служб терминалов, посреднику сеансов служб терминалов и шлюзу служб терминалов ниже в этой статье. Сперва давайте взглянем на некоторые другие компоненты в этом выпуске, из числа отличных, но менее выдающихся.

Функции безопасности

В новом выпуске служб терминалов была усилена безопасность.

Проверка подлинности на сетевом уровне (NLA) и проверка подлинности на серверном уровне (SA) В предыдущих версиях служб терминалов, атаки типа «отказ в обслуживании» и «злоумышленник в середине» могли запускаться против экрана входа в систему на сервере терминалов, поскольку экран входа в систему представлялся пользователям после щелчка «Подключиться» на клиенте RDC. Теперь NLA проверяет пользователя, клиентского компьютера и учетных данных сервера, сравнивая из друг с другом перед началом сеанса служб терминалов на сервере и представления пользователю экрана входа в систему. Проверка подлинности сервера использует протокол TLS, чтобы обеспечить подключение клиентов к правомочному серверу терминалов, а не какому-нибудь компьютеру злоумышленника.

Единый вход Пользователи желают иметь возможность использовать один набор учетных данных (комбинацию пользователь-пароль или комбинацию смарт-карты и ПИН-кода), чтобы однажды удостоверить свою подлинность и не получать повторяющихся запросов на эти учетные данные каждый раз, как они хотят использовать новый ресурс. С этим выпуском ОС, присоединенные к домену компьютеры, работающие на Windows Vista или Windows Server 2008 и подключающиеся к серверу терминалов на основе Windows Server 2008 или шлюзу терминалов могут теперь использовать единую подпись.

Усиление защиты на системном уровне И Windows Vista и Windows Server 2008 обладают новой и усиленной защитой на системном уровне, которая, по сути, разделяет компоненты операционной системы на модули и выполняет их на более низком уровне привилегий. В службах терминалов эта функция была реализована посредством разбиения ядра служб терминалов (termsrv.dll) на два отдельных компонента (lsm.exe, основной диспетчер сеанса и termsrv.dll для удаленных подключений).

Ранее, termsrv.dll работал на более высоком уровне системных привилегий. Теперь лишь треть первоначального кода termsrv.dll работает на этом уровне в новом lsm.exe; оставшиеся две трети работают на гораздо более низком уровне привилегий сетевой службы. Это изменение существенно снижает открытую для атак область, по сравнению с Windows Server 2003.

Функции обслуживания пользователей

Ряд улучшений помогает пользователям:

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

Конечный пользователь имеет возможность устанавливать собственные разрешения экрана (вплоть до 4096 x 2048) или менять пропорции на 16:9 или 16:10, чтобы получить широкоэкранное изображение. Могут поддерживаться все типы новых конфигураций мониторов, включая мониторы с разрешениями 1680 x 1050 или 1920 x 1200. Это большое улучшение по сравнению с Windows Server 2003, которая поддерживала максимальное разрешение 1600 x 1200 и только пропорцию 4:3. Нужное разрешение экрана можно выбрать из клиентского диалогового окна RDC, в файле RDP или из командной строки.

Чтобы установить собственное разрешение экрана в файле RDP, откройте файл RDP в текстовом редакторе и добавьте либо изменить следующие параметры (отметьте, что <value> - это разрешение, такое как 1680 или 1050):

desktopwidth:i:<value>
desktopheight:i:<value>

Чтобы установить нужное разрешение экрана из командной строки, используйте команду mstsc.exe со следующим синтаксисом (отметьте, что <width> и <height> - это разрешение, такое как 1680 или 1050):

mstsc.exe /w:<width> /h:<height>

Распределение изображения на несколько мониторов Сеансы удаленного рабочего стола теперь могут быть распределены на несколько мониторов. Для правильной работы этой функции необходимо выполнить несколько требований:

Все мониторы должны использовать одно разрешение. Например, изображение можно разделить на два монитора, использующих 1024 х 768. Но не на один монитор с разрешением 1024 x 768 и другой 800 x 600.
Все мониторы должны быть выстроены горизонтально (то есть, бок о бок). В настоящий момент вертикальное распределение изображения на несколько мониторов клиентской системы не поддерживается.
Общее разрешение всех мониторов не может превышать максимального разрешения 4096 x 2048.

Чтобы включить распределение на несколько мониторов в файле RDP, откройте файл RDP в текстовом редакторе и добавьте, либо измените следующие параметры: если <value>=0, распределение на несколько мониторов отключено, если <value>=1, оно включено):

Span:i:<value>

Чтобы установить распределение на несколько мониторов из командной строки, используйте команду mstsc.exe со следующим синтаксисом:

mstsc.exe /span

Desktop Experience Desktop Experience делает рабочий стол служб терминалов намного более похожим на рабочий стол Windows Vista. Эта функция добавляет ряд компонентов в удаленный рабочий стол, включая Windows Media Player 11, темы рабочего стола и управление фотографиями. Desktop Experience можно включить следующим образом:

Откройте диспетчер серверов. Нажмите кнопку «Пуск», выберите пункт «Администрирование» и щелкните Диспетчер серверов.
В сводке компонентов щелкните «Добавить компоненты».
На странице выбора компонентов установите флажок Desktop Experience и щелкните «Далее».
На странице подтверждения выбора установок, подтвердите, что компонент Desktop Experience будет установлен и щелкните «Установить».
На странице результатов установки будет дан запрос перезапустить сервер для завершения процесса установки. Выберите «Закрыть» и щелкните «Да», чтобы перезапустить сервер.

После перезапуска сервера, нужно подтвердить, что компонент Desktop Experience установлен.

Сглаживание шрифтовСглаживанием шрифтов именуется поддержка ClearType в службах терминалов, помогающая отображать компьютерные шрифты более твердо, особенно на жидкокристаллическом мониторе. Сглаживание шрифтов включено по умолчанию в Windows Server 2008 и может быть включено, когда клиентский компьютер подключается через флажок в подключении удаленного рабочего стола, как показано на рис. 1.

Рис. 1 Включение сглаживания шрифтов

Следует отметить, что сглаживание шрифтов повышает пропускную способность (в 4-10 раз, в зависимости от ситуации), используемую между клиентским компьютером и сервером терминалов. Это повышение пропускной способности происходит потому, что шрифты ClearType выносятся как точечные рисунки, а не как глифы и RDP обрабатывает их намного более эффективно.

Управление приоритетами отображаемых данных В случае Windows Server 2003, распечатка большой задачи могла повредить работе на экране. Управление приоритетами отображаемых данных автоматически контролирует трафик виртуальных каналов, так что данным монитора, клавиатуры и мыши дается более высокий приоритет чем другому трафику, скажем печати или передачи файлов. Это управление приоритетами разработано, чтобы обеспечить отсутствие влияния на работу экрана, мыши и клавиатуры задач с большим потреблением пропускной способности, таких, как большие задачи печати.

По умолчанию, этот параметр установлен на 70:30. Данным отображения и ввода выделяется 70% пропускной способности, а всему остальному трафику, такому как передача данных или задачи печати – 30%.

Параметры можно скорректировать, внося изменения в реестр сервера терминалов. Чтобы сделать это, измените значение следующих записей у подключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD:

FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression

Если эти записи не появятся, их можно добавить, щелкнув правой кнопкой мыши на TermDD, указав на «Создать» и затем щелкнув значение DWORD (32-битного).

Приоритетность данных отображения можно отключить, установив значение FlowControlDisable=1. В случае отключения приоритетности данных отображения, все запросы обрабатываются по принципу «первый вошел – первый вышел». Значение по умолчанию для FlowControlDisable=0.

Относительную степень приоритетности для отображения (и данных ввода) можно установить, устанавливая значение FlowControlDisplayBandwidth. Значение по умолчанию – 70, максимальное допустимое – 255. Аналогично, относительную приоритетность выделения пропускной способности можно установить для других виртуальных каналов (таких как буфер обмена, передачи файлов или работы печати), устанавливая значение FlowControlChannelBandwidth. Значение по умолчанию – 30, максимальное допустимое – 255.

Соотношение пропускной способности для управления приоритетами данных отображения основано на значениях FlowControlDisplayBandwidth и FlowControlChannelBandwidth. Например, если FlowControlDisplayBandwidth установлен на 150, а FlowControlChannelBandwidth на 50, то соотношение равно 150:50. Вследствие этого, данным отображения и ввода будет выделено 75% пропускной способности.

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

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

Перенаправление устройств Plug and Play В службах терминалов Windows Server 2008, перенаправление устройств было усовершенствовано и расширено. Теперь можно перенаправлять переносные устройства Windows, а конкретнее проигрыватели мультимедиа, основанные на протоколе MTP и цифровые камеры, основанные на протоколе PTP.

Эти функции можно включить с помощью кнопки «Параметры» в подключении удаленного рабочего стола. При их включении, появится список поддерживаемых устройств Plug and Play, которые сейчас подсоединены. Неподдерживаемые устройства не появятся. Можно также выбрать вариант перенаправления устройств, которые еще не подсоединены. Рис. 2 показывает, как включить их с клиента RDC.

Рис. 2. Включение устройств, которые еще не подсоединены

При запуске сеанса на удаленном компьютере, перенаправляемое устройство Plug and Play должно быть автоматически установлено на удаленном компьютере – уведомления Plug and Play появятся в панели задач. После установки перенаправленного устройства Plug and Play, оно доступно для использования в сеансе удаленного компьютера. Для примера, при перенаправлении переносного устройства Windows, такого как цифровая камера, к нему возможен доступ напрямую из приложения, вроде мастера сканнеров и камер, на удаленном компьютере.

Перенаправление устройств Plug and Play можно контролировать, используя любой из следующих параметров групповой политики:

Не позволять перенаправление поддерживаемых устройств Plug and Play, расположенное в «Конфигурация компьютера»\«Шаблоны администрирования»\«Компоненты Windows»\«Службы терминалов»\«Сервер терминалов»\«Перенаправление устройств и ресурсов».
Параметры групповой политики находятся в разделе «Конфигурация компьютера»\«Административные шаблоны»\«Классические административные шаблоны (ADM)»\«Система»\«Установка устройств»\«Ограничения на установку устройств».

Перенаправление устройств Plug and Play можно также контролировать на вкладке параметров клиента в средстве конфигурации служб терминалов (tsconfig.msc), используя флажок «Поддерживаемые устройства Plug and Play».

Упрощенный удаленный доступ

Я уже упоминал, что TS RemoteApp позволяет пользователям сделать удаленным отдельное приложение, а веб-клиент служб терминалов позволяет легкий доступ к приложениям с веб-страницы; давайте теперь рассмотрим эти функции и некоторые из их подробностей конфигурации, чуть ближе.

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

Создать файл протокола удаленного рабочего стола.
Создать значок программы на рабочем столе или в меню «Пуск» через ранее распространенный пакет установщика Windows (MSI).
Исполнить файл, где расширение имени файла связано в программой RemoteApp. Это может настроить администратор, с помощью пакета установщика Windows.

Дополнительные сведения о том, как пользователи могут получить доступ к программам RemoteApp, можно найти в "How Should I Deploy RemoteApp Programs?" («Как следует развертывать программы RemoteApp») в пошаговом руководстве для RemoteApp служб терминалов Windows Server 2008 по адресу go.microsoft.com/fwlink/?LinkID=84895.

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

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

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

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

Теперь давайте глянем а обслуживание пользователя в стандартной конфигурации. Первая вкладка в веб-клиенте служб терминалов показывает значки всех опубликованных приложений рис. 3); вторая вкладка позволяет пользователю подключиться к рабочему столу, используя компьютер с веб-интерфейсом. Как упоминалось ранее, этот веб-интерфейс полностью настраиваем и "TS Web Access Step-by-Step Guide: Customizing TS Web Access by Using Windows SharePoint Services",(«Пошаговое руководство для веб-клиента служб терминалов: настройка веб-клиента служб терминалов с помощью служб Windows SharePoint») доступное на go.microsoft.com/fwlink/?LinkID=111241, является отличным ресурсов по настройке с помощью SharePoint Services.

Рис. 3. Просмотр программ RemoteApp в веб-клиенте служб терминалов

Другие методы развертывания Помимо использования веб-клиента служб терминалов, программы RemoteApp можно развертывать с помощью файлов RDP или пакетов установщика Windows. Эти пакеты можно распространять через общий доступ к файлам или через распространение программного обеспечения Microsoft Systems Center Operations Manage либо Active Directory. Следующий раздел проходит по ключевым этапам создания правильных пакетов для распространения приложений.

Чтобы приготовить программы RemoteApp для распределения через общий файловый ресурс или какой-либо еще механизм распределения, необходимо установить службы терминалов и приложения, которые предполагается опубликовать, после чего проверить параметры удаленного подключения. Мастер TS RemoteApp поможет добавить программы RemoteApp и установить параметры глобального развертывания. Затем можно будет создавать файлы RDP или пакеты установщика Windows.

Давайте быстро пройдемся по мастеру RemoteApp. На этапе 1 мы настраиваем сервер терминалов, шлюз служб терминалов и параметры сертификата для файлов RDP (см. рис. 4).

Рис 4. Ввод параметров для файлов RDP

На этапе 2 пользователь указывает, где на рабочем столе или в меню «Пуск» появятся значки ярлыков и/или расширения связанных клиентских файлов, так что локальные файлы запустятся с помощью RemoteApp (см. рис. 5).

Рис. 5. Установка параметров для программного пакета

На завершающем этапе, мастер RemoteApp открывает папку упакованных программ, позволяя без труда развернуть эти упакованные приложения на клиентские компьютеры с помощью любых программ распространения по выбору (см. рис. 6).

Рис. 6. Программы упакованные для развертывания

Шлюз служб терминалов

Теперь я намерен изучить то, как шлюз служб терминалов может помочь удаленным пользователям получить доступ к приложениям, данным или рабочим столам за пределами брандмауэра. Рис. 7 показывает типичную ситуацию развертывания шлюза служб терминалов для предоставления доступа пользователям через Интернет на очень высоком уровне.

Рис. 7. Работник, подключающийся к корпоративной сети с переносного компьютера у себя дома

По сути, этот шлюз служб терминалов находится в периметре сети и туннелирует трафик RDP через HTTPS. Как вариант, в периметр сети можно поместить прерыватель SSL (такой как Microsoft Internet Security and Acceleration Server – ISA) и перенаправлять входящий трафик RDP шлюзу служб терминалов на другой стороне.

Вот действия, проиллюстрированные на рис. 6:

Пользователь на домашнем переносном компьютере может подключиться через Интернет, щелкнув на файл RDP, либо на значок программы RemoteApp расположенный на рабочем столе, на значок TS RemoteApp, опубликованный через веб-клиент служб терминалов, либо путем открытия клиента подключения к удаленному рабочему столу.
Между переносным компьютером дома и серверами терминалов, использующими сертификат SSL сервера шлюз служб терминалов, устанавливается туннель SSL. Перед установкой подключения, подлинность пользователя должна быть проверена и он должен быть авторизован согласно политикам авторизации подключения служб терминалов (TS CAP) и политикам авторизации ресурсов служб терминалов (TS RAP). После того, как выполнение политик TS RAP и TS CAP (обсуждаемое ниже) обеспечено, пользователь может открыть сессию.
Домашний переносной компьютер обменивается зашифрованными пакетами RDP, заключенными внутри SSL со шлюзом служб терминалов через порт TS 443. Шлюз служб терминалов перенаправляет пакеты RDP серверу терминалов через порт 3389.

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

Теперь давайте кратко рассмотрим, как развертывать эти функции. В двух словах, необходимо получить и настроить сертификат для сервера шлюза служб терминалов и создать два типа политик авторизации, упомянутых мною ранее: TS CAP и TS RAP.

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

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

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

TS RAP, с другой стороны, определяют к каким внутренним ресурсам пользователи могут получить доступ через шлюз служб терминалов. Например, можно создать группу компьютеров (такую как ферму серверов терминалов) и связать ее с TS RAP.

Чтобы дать удаленным пользователям доступ к внутренним ресурсам необходимо создать как TS CAP так и TS RAP, поскольку для получения доступа пользователь должен соответствовать условиям минимум одного TS CAP и одного TS RAP. Администраторы могут создавать оба типа через диспетчер шлюза служб терминалов, как показано на рис. 8 и рис. 9.

Рис 8. Создание политики авторизации подключения служб терминалов (TS CAP)

Рис 9. Создание политики авторизации ресурса служб терминалов (TS RAP)

Вместе, политики TS CAP и TS RAP предоставляют два различных типа авторизации, позволяющие более тонко настроить уровень управления доступом к компьютерам во внутренней сети. Более подробную информацию можно найти в "Terminal Services Gateway Step-by-Step Guide" («Пошаговое руководство для шлюза служб терминалов» go.microsoft.com/fwlink/?LinkID=85872.

Посредник сеансов служб терминалов

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

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

Предположим, что пользователь запускает клиент RDC, указывая ферму серверов терминалов, именуемую Farm1. Клиент связывается с сервером DNS, чтобы разрешить имя Farm1 в IP-адрес и сервер DNS, настроенный на использование циклического разрешения для балансировки нагрузок первоначальных запросов на подключение, возвращает список IP-адресов, зарегистрированных для Farm1.

Клиент оправляет запрос на подключение к первому IP-адресу в списке, возвращаемом сервером DNS. Сервер терминалов с этим адресом служит перенаправителем, запрашивая сервер посредника сеансов служб терминалов, чтобы определить на какой сервер терминалов следует зайти клиенту. Сервер посредника сеансов служб терминалов проверяет свою базу данных и если у пользователя имеется существующий сеанс, то посредник сеансов возвращает IP-адрес этого сервера терминалов. Если у пользователя нет существующего сеанса, посредник сеансов определяет, какой сервер терминалов в ферме имеет наименьшую нагрузку (основываясь на числе сеансов и значении относительного веса сервера), после чего возвращает IP-адрес этого конкретного сервера.

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

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

Развертывание балансировки сетевой нагрузки посредника сеансов с помощью решения балансировки нагрузок на сетевом уровне, такое как NLB или аппаратного балансировщика нагрузок, избегает ограничений DNS, в то же время продолжая пользоваться функциями посредника сеансов. Функция балансировки нагрузки посредника сеансов служб терминалов позволяет назначить значение относительного веса каждому серверу, что позволяет распределять нагрузку между менее мощными и более мощными серверами в ферме. Например, если имеется сервер, способный обработать вдвое больше сеансов, чем другой сервер в ферме, этому серверу дается относительный вес 200, а другому – 100.

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

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

Более подробную информацию можно найти в документе "TS Session Broker Load Balancing Step-by-Step Guide" («Пошаговое руководство по балансировке нагрузки посредника сеансов служб терминалов» go.microsoft.com/fwlink/?LinkID=92670. Ограниченный размер статьи не позволяет мне рассказывать подробнее о новых функциях служб терминалов Windows Server 2008. Однако, на веб-узле служб терминалов имеется гораздо больше содержимого, включая подробные трансляции. Чтобы узнать больше, следует посетить technet.microsoft.com/ts.

Ссылка: http://www.oszone.net/8213/