Каким образом организовать работу пользователей в связке WS2012r2 + zero-клиенты?
Что было прежде:
Два сервера ws2k3 с поднятыми службами терминалов, ~60 бездисковых ноу-нейм тонких клиентов под управлением thinstation 2.1. В зависимости от vlan'а, в котором обитает тонкий клиент, dhcp раздавал разный конфиг thinstation (в зависимости от vlan'а пользователь логинился либо на первый, либо на второй сервер, которые отличались заведенными пользователями, правами доступа и приложениями). AD в офисе тогда еще не было.
Что сейчас:
AD заведено. Старые железки померли. Привезли одну новую, потенциально справляющуюся со всем зоопарком приложений и пользователей. WS2k3 ставиться на нее отказался, зато поставился WS2012r2. С целым зоопарком нововведений в службах удаленных рабочих столов разобраться мне так и не удалось.
Что хочется:
1) Обойтись без закупки новых тонких клиентов и/или ПО. Лицензия на WS2012r2 + CAL + MS Office уже влетает в слишком большие деньги.
2) Иметь возможность настроить со стороны сервера два раздельных "пула" с настройками, ярлыками, закладками браузера и прочим. Грубо говоря, чтобы юзер Вася из отдела продаж не мог видеть файлов или пользоваться специфическим софтом юзера Пети из отдела рекламы. В идеале -- чтобы для конечного пользователя вообще казалось, что они на разных компьютерах.
3) Сохранить возможность загрузки ТК по сети и обеспечить максимальную прозрачность всего процесса. Ранее это выглядело так: пользователь нажимает кнопку включения на тонком клиенте, наблюдает черные буковки на экране во время загрузки, [после установки соединения rdp] вбивает данные своей учетки и работает (или наблюдает ошибку доступа, если, например, пытается залогиниться с тонкого клиента не своего отдела).
4) Иметь возможность пробрасывать в свой удаленный рабочий стол usb-флешки.
Решения навскидку:
1. "Классический" терминальный сервер. Thinstation или аналог грузится по сети на терминальный сервер. На терминальном сервере стоит абсолютно все ПО и лежат абсолютно все файлы обоих "пулов". Групповыми политиками спускаются настройки, ярлыки, закладки браузера И настраиваются access-листы для закрытия доступа к файлам "чужого" отдела. Проблема: да я понятия не имею, как поднять этот классический терминальный сервер. Session-based RDS тянет с собой еще кучу непонятных сервисов типа session broker host, rds getaway и веб-интерфейс, на котором через файлик, по задумке Microsoft, должны коннектиться терминальные пользователи. Проблема в том, что тонкий клиент не умеет делать такое, а при попытке соединения с сервером напрямую (по ip или хостнейму, например) пользователь получает ошибку типа "необходимо быть в группе пользователей удаленного рабочего стола". Вариант вроде загрузки супер-легкого linux'а со старт-ап скриптом, открывающим браузер на нужной страничке на весь экран для конечного пользователя слишком сложен: а) ввести логин/пароль, б) тыкнуть в определенный ярлык на страничке, в) дождаться соединения и снова ввести логин/пароль -- сразу начнутся крики "верните как было". Плюс я не могу ручаться, что линукс нормально откроет этот rdp-файл (а не скачает его, например, как это делает тот же chrome под windows, или не выдаст ошибку). Где-то видел возможность прямого перенаправления соединения с session broker host до терминального сервера (то есть то же самое, что делает этот файлик, по сути), но это требует изменения реестра, а на терминальном сервере его менять что-то не хочется.
2. VDI. Вот здесь с серверной стороны все просто и понятно: создается два пула виртуальных машин, каждый из которых использует свой собственный пред-настроенный образ ОС со своим специфическим софтом и прочими прелестями. Проблема: насколько я понял, пробросить usb в виртуальную машину невозможно без дополнительных телодвижений вроде usb-over-ip. Изменение реестра на session broker host, как указано в прошлом пункте, убьет возможность создания двух разных типов виртуальных машин, т.к. session broker host будет без вопросов редиректить все соединения на какую-то одну коллекцию виртуалок. То есть все плюсы решения убиваются.
Подводных камней может быть и больше, и меньше -- я очень плохо разбираюсь во всех нововведениях по части терминальных сервисов. Буду очень признателен, если кто-нибудь подскажет мне, как лучше всего организовать подобную инфраструктуру. Ну или хотя бы подтолкнуть в нужном направлении, а то от обилия различных программных решений в сфере терминальных/виртуальных рабочих столов глаза разбегаются.
@desperadik Извиняюсь, моя вина, я плохо разбираюсь в терминальных службах, поэтому могу плохо формулировать мысль или еще хуже оперировать терминологией.
Я хочу грузиться с ТК от юзера на ws2012 по RDP и работать в обычном рабочем столе. Я хочу иметь возможность разбить пользователей на две группы, у которых будут различаться настройки (принтеры по умолчанию, закладки браузера, ярлыки рабочего стола, доступ к приложениям, дискам и т.п.). То есть так, словно они работают на абсолютно разных серверах.
Насколько я понял, такое возможно в session-based remote desktop services путем создания коллекций либо с помощью virtual machine based remote desktop services (во второй, насколько я понял, это реализуется через два шаблонных образа гостевой ос в виртуальных машинах и привязкой пользователей к одному из шаблонов).
В первом случае (session-based) я не совсем понимаю, как заставить тонкий клиент грузиться в эти коллекции, а не напрямую в сервер.
Во втором случае (vdi) я не понимаю, как заставить бездисковые клиенты с ним работать. В описании процесса соединения с vdi от Microsoft фигурируют скачивания RDP-файла с RDS Web Host и прочие телодвижения, слишком сложные для конечного пользователя. А решение должно быть из разряда "включил -- залогинился -- работаешь". В каком-то видео был способ реализовать такое для VMware View или Citrix XenApp, но 1) я не знаю эти продукты и, следовательно, не хочу с ними работать; 2) хотелось бы использовать как можно меньше проприетарного софта, т.к. в таком случае стоимость лицензий просто зашкалит.
P. S. На данный момент лицензии еще не куплены, так что в качестве серверной ОС вполне может рассматриваться и WS2k8r2, если для решения данной задачи он подходит лучше (не могу привести, правда, ни одного аргумента в пользу более старой операционки. ws2k8, если не ошибаюсь, работает по точно такой же схеме в роли терминального сервера).
Спустя полгода сам отвечаю на собственный вопрос: создаем обычный сервер RDS (для единственного сервера можно тыкнуть "quick deploy" и получить рабочее решение, для двух и более серверов -- вынесение ролей RDS Gateway и Connection Broker на отдельные сервера, RDCB High Availability и DNS Round Robin. По этому поводу хорошо написано здесь: blog.it-kb.ru/2014/08/24/windows-server-2012-r2-re... и на technet'е)
На session host ставится базовый набор ПО (то, что используют оба отдела в моем случае), для "специфического" ПО использовать ферму (или единичный сервер) RemoteApp и разграничивать права доступа на уровне групп безопасности Active Directory.
В качестве ПО для тонких клиентов использовать Thinstation 5.X с пакетом freerdp или готовое ПО типа PoniX (www.t-sol.ru/about )
Есть вариант поставить Hyper-V, а на нем поднять WS2k3. Но я бы вам посоветовал разобраться в новых возможностях терминальных серверов Win 2012 R2. Подключение не работает потому-что Вы не добавили пользователей в группу Пользователей рабочего стола. Это можно сделать 2 способами - или локально на сервере или при создании коллекции через оснастку RDS
Средний
