При поддержке компании Mobatime Systems: лидера в разработке, производстве и продаже приборов и систем времени. Подробнее...
Сайт · Форум · Инструменты WindowsFAQ.ru - Сайт о Windows, компьютерах, системном администрировании, локальных сетях

Поиск

Друзья

Клуб любителей ASPLinux
Kerio Winroute Firewall инструкции настройки

Шаблоны

New_WindowsFAQ
Удаленные приложения RemoteApp служб терминалов Windows Server 2008 Версия для печати
Рейтинг: / 41
ХужеЛучше 
Автор Сергей Вальковский   

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

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

Функционал сервера терминалов Windows Server 2008 расширен появлением новых служб - RemoteApp и TS Web Access. RemoteApp (Удаленные приложения служб терминалов) предоставляют доступ к приложениям, размещённым на сервере терминалов. Причём, для пользователя они выглядят так, как если бы они исполнялись в его системе - то есть ему показывается не рабочий стол удалённой системы с запущенными на ней приложениями, а приложения интегрируются в рабочий стол системы пользователя (с масштабированием окна и собственным значком приложения в панели задач). TS Web Access (веб-доступ к службам терминалов) позволяет использовать RemoteApp с помощью интернет-подключения. Помимо того, что с точки зрения пользователя, удалённые приложения имеют более привычный для него вид, это выглядит и более безопасным в использовании. Когда пользователю доставляется не рабочий стол системы, а отдельное приложение, администраторам уже не приходится продумывать вопросы наподобие таких - "сможет ли пользователь с помощью клавиатурных комбинаций запустить менеджер задач?" или "как запретить исполнение команды Выполнить?". Взглянем на эти новые службы поближе.

Простой пример TS Web Access

Для начала мы продемонстрируем работу служб TS Web Access в минимальном наборе и без излишней функциональности. В этом примере нам потребуется лишь Windows Server 2008 и клиент с версией RDC не ниже 6.1 (6.0.6001.x).

Для взаимодействия со службами удаленных приложений RemoteApp, развёрнутых на сервере терминалов Windows Server 2008, должен использоваться клиент RDC (Remote Desktop Connection, подключение к удаленному рабочему столу) версии 6.0 (6.0.6000.x) или более поздней. Клиент RDC с необходимой версией входит в состав ОС Windows Vista. Для Windows Server 2003 и Windows XP он доступен для скачивания и установки по адресу KB925876.

Однако для использования веб-доступа к службам терминалов TS Web Access потребуется версия клиента RDC не ниже 6.1 (6.0.6001.x), входящего в состав ОС Windows Server 2008, Windows Vista SP1 и Windows XP SP3. Причём, если для Windows Server 2008 и Vista SP1 этого вполне достаточно, то в случае использования Windows XP SP3 дополнительно потребуется разрешить использование элемента управления ActiveX при помощи правки реестра. Для этого в ключе

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings

необходимо удалить (или, например, просто переименовать) следующие два подключа:

{4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2}
{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}

Перезагрузки для вступления в силу изменений не потребуется. Использование веб-доступа к службам терминалов TS Web Access возможно лишь с использованием браузера Internet Explorer. При первом подключении в панели информации обозревателя Internet Explorer появится предупреждение, что активное содержимое веб-страницы было заблокировано. Необходимо щелкнуть панель информации, выбрать пункт Разрешить заблокированное содержимое и затем нажать кнопку Запустить элемент ActiveX.

Подготовка сервера включает в себя установку ролей сервера терминалов и веб-сервера IIS с последующей публикацией необходимых приложений. Отметим, что служба веб-доступа к серверу терминалов может быть размещена на отдельном физическом сервере, к которому будут подключаться интернет-пользователи (да и самих физических серверов терминалов может быть и несколько), но в данном примере мы объединим их "в одном флаконе".

Запускаем диспетчер сервера, щелкаем в левой панели строку Роли, затем переходим в правую панель и щёлкаем ссылку Добавить роли

Добавление ролей сервера
Увеличить изображение

На первой странице нажимаем кнопку Далее, на странице Выбор ролей сервера устанавливаем флажок Службы терминалов

Добавление роли служб терминалов

и нажимаем кнопку Далее. Читаем дополнительные сведения, нажимаем кнопку Далее ещё раз. Теперь необходимо указать службы роли. Устанавливаем флажки Сервер терминалов и Веб-доступ к службам терминалов:

Добавление служб роли

Для функционирования веб-доступа необходимо, чтобы на сервере были установлены компоненты веб-сервера IIS и служб активации процессов Windows. Если ранее они не были установлены, появится предложение добавить их в список устанавливаемых ролей.

Добавление требуемых служб
Увеличить изображение

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

На странице Метод проверки подлинности необходимо указать, каким образом будет проверяться клиент перед установлением подключения. Если все клиенты будут использовать операционные системы, поддерживающие протокол CredSSP (например, Windows 7 или Windows Vista), желательно установить требование проверки на уровне сети. Если необходимо обеспечить подключение клиентов и с Windows XP, то необходимо выбрать параметр Не требовать проверку подлинности на уровне сети.

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

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

Добавление удаленных пользователей
Увеличить изображение

В списке уже находится встроенная группа "Администраторы", вы можете добавить необходимые группы, воспользовавшись кнопкой Добавить. После завершения редактирования нажимаем Далее три раза, оставляя предложенные настройки ролей IIS как есть, и переходим к странице подтверждения со списком всего сформированного процесса установок. Если всё верно, нажимаем кнопку Установить, после чего начнётся сам процесс установки ролей сервера.

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

Как уже отмечалось, во избежание конфликтов, установку приложений следует производить после установки самого сервера терминалов. Если установка приложения осуществляется с помощью пакета установщика Windows msi, то никаких дополнительных действий не требуется. Для остальных случаев сервер терминалов должен быть переведён в режим установки приложений. Для этого необходимо устанавливать приложения с помощью средства Установка приложений на сервер терминалов, находящегося в панели управления, или вручную, переведя сервер в режим установки командой change user /install . В ручном режиме по окончании установки приложений на сервер выполните команду change user /execute.

Добавление приложений достаточно просто. Откройте Диспетчер удалённых приложений (Пуск - Администрирование - Службы терминалов или Диспетчер сервера - Роли - Службы терминалов), в окне Диспетчера щёлкните правой кнопкой мыши над списком Удалённые приложения RemoteApp (или выберите команду Добавление удалённых приложений в панели Действия).

Добавление удалённых приложений
Увеличить изображение

Запустится мастер удалённых приложений. Нажмите кнопку Далее и установите флажки у необходимых приложений.

Добавление в список удалённых приложений
Увеличить изображение

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

Настройка приложений
Увеличить изображение

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

Немного изменим параметры сервера терминалов. В окне Действия выберем команду Параметры шлюза служб терминалов и в окне диалога установим переключатель в положение Не использовать сервер шлюза служб терминалов - поскольку никакого шлюза у нас пока нет. Собственно, всё готово для начала тестирования работы TS Web Access. Запускаем на клиенте Internet Explorer, в адресной строке вводим: http://имя_сервера/ts. Чтобы выяснить, как именно происходит соединение, запустим на клиенте утилиту TCPView. При подключении к веб-порталу сервера терминалов появляется запрос на авторизацию. Отмечаем, что пока установлено обычное http-соединение (80-й порт TCP).

Подключение к TS Web Access
Увеличить изображение

Указываем данные, необходимые для входа, (если заходим в первый раз, не забываем установить и запустить ActiveX, щёлкнув по появившейся панели информации в браузере) и попадаем на саму страницу веб-доступа:

Веб-доступ к службам терминалов
Увеличить изображение

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

Запущенное приложение RemoteApp
Увеличить изображение

Заметим, что выглядит оно практически так же, как и локально запущенное, а связь с ним теперь осуществляется при помощи 3389 порта TCP (Управление удаленным рабочим столом). Причём, независимо от числа открытых приложений, все данные будут пересылаться по этому каналу.

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

Использование шлюза TS Gateway

Согласно народной примете, далеко не всякий пакет с 3389-го порта TCP может достичь системы, предназначенной для публичного использования в интернете. Устройства и программы, отвечающие за безопасность внутренних сетей, как правило, конфигурируются так, чтобы через них пропускался лишь трафик HTTP и/или HTTPS (порты 80 и 443 протокола TCP), блокируя потоки данных, пересылаемых по другим портам.

С помощью средств Windows Server 2008 можно создать шлюз служб терминалов - TS Gateway. Его роль заключается в инкапсулировании протокола RDP с последующей передачей пакетов по обычным HTTP-каналам, защищая их средствами SSL/TLS. Такая технология позволяет реализовывать безопасные подключения без использования VPN и изменения настроек файерволлов, снижающих уровень защиты сети.

Новая роль служб, появившаяся в Windows Server 2008 - TS Gateway - подобна прокси-серверу, с которым взаимодействуют серверы терминалов. TS Gateway имеет встроенные средства контроля входящих подключений и доступа к ресурсам внутренней сети. Только те пользователи, которым будет разрешён доступ к шлюзу, смогут подключиться к нему. Эти пользователи смогут использовать только разрешённые для них ресурсы. Для подключения пользователя может использоваться любой компьютер, который может выступать в роли клиента шлюза и поддерживает RDP.

Схема работы шлюза TS Gateway
Увеличить изображение

Рассмотрим по порядку, как удалённый клиент, используя RDP-подключение, получает доступ к ресурсам сети.

  • Пользователь запускает RDP-файл (в его роли может выступать сохранённый RDP-файл или ссылка с портала TS Web Access), указывающий на определённый ресурс во внутренней сети
  • RDP-файл создаёт подключение к шлюзу, используя SSL-туннель
  • Шлюз, в соответствии с политикой авторизации подключений (TS CAP), аутентифицирует клиента и проверяет его полномочия на возможность создания подключения
  • В случае успешного завершения проверки клиента, он отправляет запрос на необходимый ресурс - удалённое приложение или подключение к удалённому рабочему столу компьютера, расположенного во внутренней сети
  • Шлюз выполняет проверку запроса на соответствие политике авторизации ресурсов (TS RAP)
  • Если проверка выполнена успешно, шлюз устанавливает внутреннее RDP-подключение к затребованному клиентом ресурсу. Весь дальнейший поток данных проходит через шлюз, который выполняет его преобразование, отправляя пакеты внутри сети по порту 3389, а в сторону клиента - инкапсулируя в SSL и отправляя их с 443 порта

Работу шлюза мы продемонстрируем на примере сети следующей конфигурации:

Конфигурация тестовой сети
Увеличить изображение

Здесь клиент RC1, расположенный на рисунке "за облаком", будет имитировать подключение из интернета к шлюзу TG1 (запись о адресе TG1 мы для простоты внесём в файл hosts клиента RC1). Моделировать устройства NAT или файерволлы в этом примере не будем, важно, что клиент RC1 и сервер терминалов TS1 расположены в разных сетях. TS1 и TG1 работают под управлением Windows Server 2008, клиент RC1 - Windows XP SP3 с RDP 6.1. Контроллер домена (в примере домен будет называться tstest.local) DC1 управляется Windows 2003 SP2, на нём, помимо DNS, работает центр сертификации предприятия tstestcertcenter (в принципе, ЦС для нашего тестирования необязателен, если использовать самозаверяющий сертификат), который является доверенным корневым центром сертификации для шлюза TG1.

Начнём с сервера терминалов TS1. На нём необходимо будет добавить роль сервера терминалов, установить и настроить приложения и сконфигурировать шлюз. Открываем Диспетчер сервера, переходим в левом окне в раздел Роли, в правом окне щёлкаем ссылку Добавить роли, нажимаем кнопку Далее. Отмечаем флажок Службы терминалов, два раза нажимаем кнопки Далее. Устанавливаем флажок Сервер терминалов (процесс лицензирования сервера терминалов, как и в первом примере, рассматривать не будем), нажимаем Далее два раза. Устанавливаем необходимый режим проверки подлинности на уровне сети (я поставил переключатель в положение Не требовать проверку подлинности), нажимаем Далее. Указываем тип лицензирования - Настроить позже, нажимаем Далее. Указываем, кто сможет подключаться к серверу терминалов (Пользователи домена), нажимаем Далее и Установить. Ждём, когда работа мастера будет закончена, перезагружаем сервер, и дожидаемся окончания процесса конфигурирования.

Теперь перейдём к серверу, который будет использоваться в качестве шлюза. Для него также добавим роль служб терминалов, но в качестве служб роли (и ведь ничего не поделаешь с этой тавтологией - официальная терминология Майкрософт...) укажем Шлюз служб терминалов и Веб-доступ к службам терминалов. Соглашаемся с автоматическим добавлением установки дополнительных служб для указанных ролей и нажимаем кнопку Далее. Откроется страница выбора сертификата для SSL-шифрования. Пока установим переключатель в положение Выбрать сертификат позднее - мы сделаем это при конфигурировании шлюза.

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

Установим сертификат, который будет использоваться веб-службами для установления SSL-подключений. В оснастке Администрирование выберите Диспетчер служб IIS. В левой панели щёлкните строку с именем шлюза, затем в центральном окне дважды щёлкните значок Сертификаты сервера, расположенный в группе IIS. Если в сети существует внутренний центр сертификации, можно использовать выданный им сертификат, или указать сертификат, выданный одним из доверенных общедоступных центров сертификации (для тестирования сети вполне подойдёт и вариант с созданием самозаверяющего сертификата). Мы установим сертификат, выданный центром сертификации предприятия, который расположен на DC1. Для этого в панели Действия выбираем команду Создать сертификат домена.

Создание сертификата для SSL-подключений
Увеличить изображение

Указываем на первой странице мастера необходимые данные (в строке Полное имя укажите DNS-имя шлюза сервера терминалов, в нашем примере это tg1.tstest.local) и нажимаем Далее. Указываем расположение ЦС (для рассматриваемой сети это tstestcertcenter\dc1.tstest.local), вводим имя для сертификата, нажимаем Готово. Сертификат должен появиться в списке веб-сервера.

Установка сертификата сервера IIS
Увеличить изображение

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

Настройка сертификата SSL
Увеличить изображение

В открывшемся окне на вкладке Сертификат SSL нажимаем кнопку Обзор сертификатов, выбираем сертификат, полученный на предыдущем шаге для веб-сервера и нажимаем кнопку Установить. Центральное окно диспетчера должно стать таким:

Конфигурирование шлюза служб терминалов
Увеличить изображение

Настроим политики авторизации, отмеченные желтыми предупреждающими значками. Для этого нажимаем расположенные рядом ссылки (или переходим в соответствующий раздел в дереве, расположенном в левом окне диспетчера; затем в панели действий выбираем ссылку Создать новую политику и щелкаем на команде Мастер). Указываем понятное имя политики TS CAP, метод проверки пользователя (пароль/смарт-карта), выбираем группы пользователей, которые смогут подключаться к шлюзу (а если необходимо - и группы компьютеров), задаём, если необходимо, как будет функционировать перенаправление клиентских устройств.

Похожие действия выполняем и для политики TS RAP, указывая группы пользователей, к которым она будет применяться, и задав ресурсы, к которым они смогут получить доступ (для доступа ко всем сетевым ресурсам выберите Разрешить подключение к любому сетевому ресурсу). Разрешённым для удалённых подключений внутри сети оставим 3389 TCP-порт.

Если мы сейчас зайдем с помощью браузера на веб-портал шлюза терминалов, мы увидим, что он работает, но абсолютно пуст. Вернёмся к серверу терминалов TS1. Установим на него необходимые приложения и добавим их в группу удалённых приложений RemoteApp - так же, как в первом примере. В Диспетчере удалённых приложений в панели Действия щёлкнем ссылку Параметры сервера терминалов, чтобы завершить его настройку. На вкладке Сервер терминалов проверим, что флажок Требовать проверку подлинности сервера установлен, а в поле Имя сервера укажем полное DNS-имя TS1 - ts1.tstest.local.

Настройка параметров сервера терминалов
Увеличить изображение

На вкладке Шлюз служб терминалов переводим переключатель в положение Использовать следующие параметры... и указываем имя шлюза и метод входа:

Настройка шлюза для сервера терминалов
Увеличить изображение

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

Предупреждение о пустой группе веб-доступа

Открываем оснастку Управление компьютером, переходим в раздел Локальные пользователи и группы, и выбираем Группы. Найдите и двойным щелчком откройте группу Компьютеры веб-клиента сервера терминалов (TS Web Access Computers).

TS Web Access Computers
Увеличить изображение

Нажмите кнопку Добавить, установите тип объектов Компьютеры, и добавьте компьютер, который является шлюзом сервера терминалов (в нашем примере это TG1).

Компьютеры веб-клиента сервера терминалов
Увеличить изображение

Теперь, при нажатии ссылки Обновить в списке Распределение через веб-доступ к службам терминалов диспетчера удалённых приложений RemoteApp предупреждение должно смениться на сообщение о том, что группа компьютеров веб-доступа сформирована. Нам осталось зайти на веб-портал шлюза http://tg1.tstest.local/ts с учётной записью, принадлежащей к группе администраторов, перейти на вкладку Конфигурация и указать в зоне редактора имя сервера терминалов ts1.tstest.local, откуда веб-сервер шлюза будет получать список приложений, доступных удалённым веб-пользователям:

Настройка сервера терминалов для веб-доступа
Увеличить изображение

Ну что ж, теперь попробуем подключиться браузером с клиента RC1 к шлюзу TG1, указав в строке адреса http://tg1.tstest.local/ts. На запрос указываем учётные данные для подключения

Подключение к веб-серверу шлюза

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

Отказ в удалённом подключении
Увеличить изображение

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

Чтобы клиент имел в своём распоряжении такой сертификат, на шлюзе TG1 запустите консоль MMC, добавьте оснастку Сертификаты, укажите, что она будет управлять учётной записью компьютера, компьютер - локальный. В разделе Доверенные корневые центры сертификации щёлкните Сертификаты и выберите сертификат выданный tstestcertcenter, щелкните его правой кнопкой мыши, выберите команду Все задачи, затем Экспорт.

Выбор сертификата для экспорта
Увеличить изображение

Запустится мастер экспорта сертификатов. Указываем, что закрытый ключ экспортироваться не должен, нажимаем два раза кнопку Далее и указываем имя сертификата и место, где он будет сохранён. Нажимаем Далее, затем Готово. Теперь необходимо передать любым образом этот файл сертификата клиенту RC1. На клиенте достаточно щёлкнуть этот файл правой кнопкой мыши и выбрать команду Установить сертификат.

Установка сертификата

Система автоматически поместит этот сертификат в необходимое хранилище, достаточно будет пару раз нажать кнопку Далее. При последующем подключении соединение должно быть установлено. Осталось проверить, какие порты задействованы в подключении. Вот порты, которые использует удалённый клиент после установления подключения:

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

А вот что происходит в это же время на шлюзе:

Порты, используемые шлюзом
Увеличить изображение

Как видим, шлюз соединён с клиентом с помощью 443 порта TCP, а для связи шлюза с сервером терминалов используется порт 3389. Поскольку в примере использовался доступ к приложениям через веб-портал, начальное соединение клиента со шлюзом будет происходить по HTTP (TCP, 80-й порт). Если необходимо "закрыть" на шлюзе TCP-80 порт, то обеспечить публикацию приложений на клиентах можно с помощью создания RDP-файлов или пакетов msi установщика Windows.

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

Sans
создано: 28-12-2011 17:14
Гость
Есть Деньги Юзайте Citrix
Crazy user
создано: 28-12-2011 17:55

Цитата (автор "Гость"):
GUI откровенно тормозит

Игрушки запускаешь? У меня не тормозит.


Цитата (автор "Гость"):
на самой быстрой локалке и компьютерах

Быстрым должен быть сервер.


Цитата (автор "Гость"):
неудобство в индикатором "плавающим" клавиатуры под Win XP

Русский язык учить говорить не пробовал?
Гость
создано: 29-12-2011 03:11
> русский язык учить
Для владеющего русским в достаточной мере очевидно, что это опечатка. Тебе не очевидно, как я вижу.

> игрушки
Какие, к чертовой матери, игрушки? Мы говорим о RemoteApp, а не о RemoteFX.
Тормозит всё: менюшки, передвижение окна приложения по экрану. Незначительно, но по сравнению с открытыми рядом "настоящими" окнами очень заметно, и поэтому раздражает. В моём эксперименте все три компоненты - сервер, клиент и сеть были экстремально быстрыми; создается впечатление, что это не тормозня в чистом виде, а искусственное ограничение технологии, возможно, чтобы снизить нагрузку на канал.

Посему, вопросы. Можно ли что-то где-то подкрутить, чтоб GUI плавнее заработало? Есть ли альтернативные терминальные технологии под Win, реализующие запуск приложений подобным образом и работающие... плавнее?
Crazy user
создано: 29-12-2011 10:13

Цитата (автор "Гость"):
это опечатка

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

Цитата (автор "Гость"):
Незначительно, но по сравнению с открытыми рядом "настоящими" окнами очень заметно

By design. Передача и обработка информации с другого компьютера не может происходить мгновенно.

Цитата (автор "Гость"):
и поэтому раздражает.

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

Цитата (автор "Гость"):
Посему, вопросы.

Заведи отдельную тему в соответствующем разделе, эта предназначена исключительно для обсуждения статьи.
123
создано: 16-03-2012 14:21
аффтор спасиб!
гость удачи ;)
Гость
создано: 01-04-2013 11:04
Вопрос к автору. создал все без проблем, в локалке все работает, а вот синету не пускает. http://webfile.ru/6455841 вот такая фигня и пишет ошибку "не удалось найти удаленный компьютер"
Crazy user
создано: 01-04-2013 16:40
Для доступа через Инет служит не RD Web Access, а RD Gateway.
Никнейм:


BB-коды, смайлы
Тема на форуме
Опции
 
 
< Предыдущая статья   Следующая статья >

Сервер NTP


Доступ к серверу NTP первого стратума
Подробнее

На форуме

Лента RSS

Mobatime - Автору - Рекламодателю - Веб-мастеру - Контакт - История - Наверх
© Владислав Семёнов aka SavageNoName 2003-2014
При любом использовании материалов ссылка на WindowsFAQ.ru обязательна
Сайту 10 лет, 3 месяца и 24 дня. Форуму 13 лет, 8 месяцев и 6 дней.