Comments 25
начиная с WS2008, все необходимое для этого имеется прямо в Windows, без применения дополнительного оборудования и программ
дальше можно не читать.
дальше можно не читать.
Я понимаю ваш скептицизм. Но все ж таки прошу потерпеть, особенно если тема вам интересна. В данный момент времени (21:49) на моем сервисе (ну, бывшем моем, так как он уже передан в другую группу для обслуживания) находится 1700 пользователей, в день обслуживается около 50000 соединений, и все это с uptime 100% в течение как минимум 4-х месяцев. При этом не использовано ни одной сторонней технологии.
Впрочем, я вас не заставляю читать, и смысла в подобных вашему комментариях не вижу — вы уж извините.
Впрочем, я вас не заставляю читать, и смысла в подобных вашему комментариях не вижу — вы уж извините.
«Базовое мониторирование» сильно режет ухо.
А почитать хотелось бы, особенно про RemoteApp.
А почитать хотелось бы, особенно про RemoteApp.
Полностью согласен, спасибо. К сожалению, сейчас уже голова не варит, так что если есть какие-то идеи — предлагайте, я с удовольствием приму. Я очень заинтересован в том, чтобы терминология была полностью русской, но понятной и не вызызывающей рези в ушах :)
Если предложений нет, ничего страшного, может я завтра придумаю что-то получше.
А по поводу RemoteApp — все зависит от сообщества. Захотите — расскажу, что знаю. По-моему, самая интересная тема это интеграция TS Web Access (то, что хостит RemoteApp) и TS Gateway.
Если предложений нет, ничего страшного, может я завтра придумаю что-то получше.
А по поводу RemoteApp — все зависит от сообщества. Захотите — расскажу, что знаю. По-моему, самая интересная тема это интеграция TS Web Access (то, что хостит RemoteApp) и TS Gateway.
RemoteApp — это не как ssh -Y server program, т.е. когда на сервере запускается только одна программа — нужная, и только она отрисовывается в обычном окошке на локальном рабочем столе?
Да, совершенно верно, очень похоже. Просто RemoteApp глубже интрегрирован с клиентским рабочим столом (перенаправление удаленной области уведомлений aka «трей», в Windows 7 — Workspaces (не знаю, как называется в локализованной винде)). Плюс RemoteApp автоматически публикуется на сайте TS Web Access, плюс цифровые подписи чтобы не подсоединиться к фишинговому серверу… Впрочем, RemoteApp имеет и несколько недостатков — об этом я тоже напишу.
Очень интересно. Просто в необходимости такого решения приходится использовать Citrix, с ним зачастую неудобно обращаться.
И еще одно — RemoteApp сам по себе не работает через SSL. Это старый добрый RDP (TCP 3389). Для того, чтобы это работало через SSL, нужен TS Gateway и соответствующая настройка (очень простая) самих RemoteApp.
Кстати, я так и не понял из вашего краткого описания, что это за TS Gateway. Как я сейчас понял, это такой «полезный Man-In-The-Middle», с сервером устанавливает обычный RDP-канал, с клиентом RDP завёрнутый в SSL. Т.е. нужна клиентская поддержка RDP в SSL?
Да, точно. Ну, за исключением того что MITM (Man In The Middle) обычно прохой парень :) Естественно, нужна поддержка со стороны терминального клиента, mstsc.exe. Работает это начиная с версии 6.0.
Если коротко, вот справочка:
OS -> версия out-of-the-box
XP SP2 -> 5.2, есть обновления до 6.0 и 6.1 на MS downloads.
XP SP3 -> 6.1 (или 6.0? не помню точно, но кажется все-таки 6.1). Вроде, будет обновление до 7.0 с урезанным немного функционалом (так как не весь возможный поддерживается самой XP)
Vista RTM -> 6.0, апгрейд невозможен
Vista SP1 -> 6.1, будет апгрейд до 7.0 с возможно, урезанным функционалом
Win7 -> 7.0
Если коротко, вот справочка:
OS -> версия out-of-the-box
XP SP2 -> 5.2, есть обновления до 6.0 и 6.1 на MS downloads.
XP SP3 -> 6.1 (или 6.0? не помню точно, но кажется все-таки 6.1). Вроде, будет обновление до 7.0 с урезанным немного функционалом (так как не весь возможный поддерживается самой XP)
Vista RTM -> 6.0, апгрейд невозможен
Vista SP1 -> 6.1, будет апгрейд до 7.0 с возможно, урезанным функционалом
Win7 -> 7.0
Как вы наверное могли догадаться, меня лично ещё волнует поддержка его в rdesktop. Правда, это видимо не к вам ;)
Если можно расскажите поподробнее про цифровые подписи для TS. в плане как их сделать? настраивать и…
зы заранее спасибо
зы заранее спасибо
Обязательно.
Пока, если кратко — то очень просто. RDP-файлы можно подписывать не только code-signing сертификатами, но и обычными SSL. То есть, у вас есть SSL сертификат, которым вы пользуетесь на вашем TSWA/TSGateway сервера (не важно, самоподписанный или выданный каким-то сертификационным центром. Важно, чтобы сертификату доверяли пользователи. Да, и самоподписанный сертификат небезопасен). Теперь просто установите этот сертификат на Terminal Server, запустите RemoteApp manager и выберите программу для которой хотите создать подписанный RDP-файл. Все.
На самом деле тема обширна, и мы ее затронем. Просто может вам поможет краткий ответ, зачем ждать? :)
Пока, если кратко — то очень просто. RDP-файлы можно подписывать не только code-signing сертификатами, но и обычными SSL. То есть, у вас есть SSL сертификат, которым вы пользуетесь на вашем TSWA/TSGateway сервера (не важно, самоподписанный или выданный каким-то сертификационным центром. Важно, чтобы сертификату доверяли пользователи. Да, и самоподписанный сертификат небезопасен). Теперь просто установите этот сертификат на Terminal Server, запустите RemoteApp manager и выберите программу для которой хотите создать подписанный RDP-файл. Все.
На самом деле тема обширна, и мы ее затронем. Просто может вам поможет краткий ответ, зачем ждать? :)
Хотелось бы поменьше официальности и побольше своих советов, вобщем практики
Не забудьте упомянуть про Windows System Resource Manager, который неплохо работает именно на терминальных серверах.
начиная с WS2008, все необходимое для этого имеется прямо в WindowsА разве в W2003 не было всего «из коробки»? Отказоустойчивую ферму можно легко собрать на NLB, Session Broker и базовом TS и эти технологии встроены в W2003.
RemoteApp не было
Да, о WSRM будет в разделе «Установка». Будет, кстати, и о том, что в R2 есть два рекомендуемых режима WSRM. Но спасибо за напоминание.
По поводу «из коробки» в WS2003 — вы частично правы (Session Broker не существовал, был Session Directory). Частично, так как Session Directory в WS2003 был с такими проблемами:
1. Существовал только в Server Enterprise, что делало развертывание дорогим. Session Broker (WS2008) есть в любом варианте поставки.
2. NLB далеко не решает проблем с балансировкой сессий, а Session Directory не умеет балансировать. Session Broker тоже не идеал, но он нормально работает, плюс есть интерфейс плагинов.
3. Проблемы с обслуживанием ферм с Session Directory. Режим drainstop, также как и опция /admin сильно упрощают эту задачу.
Дополнительно: в WS2003 достаточно легко можно было провести DDos на ферму TS (что, естественно, не улучшало отказоустойчивости). NLA или TS Gateway делают эту задачу (к сожалению, несовместимые друг с другом в большинстве сценариев), мягко говоря, трудновыполнимой.
По поводу «из коробки» в WS2003 — вы частично правы (Session Broker не существовал, был Session Directory). Частично, так как Session Directory в WS2003 был с такими проблемами:
1. Существовал только в Server Enterprise, что делало развертывание дорогим. Session Broker (WS2008) есть в любом варианте поставки.
2. NLB далеко не решает проблем с балансировкой сессий, а Session Directory не умеет балансировать. Session Broker тоже не идеал, но он нормально работает, плюс есть интерфейс плагинов.
3. Проблемы с обслуживанием ферм с Session Directory. Режим drainstop, также как и опция /admin сильно упрощают эту задачу.
Дополнительно: в WS2003 достаточно легко можно было провести DDos на ферму TS (что, естественно, не улучшало отказоустойчивости). NLA или TS Gateway делают эту задачу (к сожалению, несовместимые друг с другом в большинстве сценариев), мягко говоря, трудновыполнимой.
Да, по первый пунктам вопросов нет, но вот
С удовольствием почитаю про Session Broker, его возможности и интерфейс плагинов в будущих статьях.
Проблемы с обслуживанием ферм с Session Directory.Тут не соглашусь. Ферму 2003 серверов немного проще обслуживать в плане подключения к конкретной машине, поскольку если указывать конкретный IP или имя, то ты гарантированно попадаешь туда. Когда мы подняли ферму 2008, то оказало, что такой фокус уже не проходит и тебя насильно перекидывают на сервер, где запущена сессия. По началу это вызвало много путаницы. Выход с /admin в mstsc был позже найден, но он не очевиден. С другой стороны такой подход более правильный и безопасный.
С удовольствием почитаю про Session Broker, его возможности и интерфейс плагинов в будущих статьях.
А дальше? вот уже три месяца почти прошло, а где же обещанное продолжение? ;)
Больше года… и ни ответа, ни привета…
Sign up to leave a comment.
Terminal Services: Windows Server 2008 (R2)