Глава 7. Службы удалённых рабочих мест

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

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

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

Мы будем использовать машину Windows Server 2016 для установки своих ролей RDS. Этот сервер уже подключён в домен.

Следующие шаги проведут вас через установку ролей, необходимых для запуска вашего первого простого сервера RDS:

Мы можем последовать этому рецепту чтобы получить наше первое простое окружение RDS поднятым и работающим. Наш сервер теперь будет позволять пользователям присоединяться и получать доступ к виртуальным сеансам, которые размещаются прямо на этом сервере RDS1. Чтобы зарегистрироваться, пользователь может либо запустить инструмент Соединения с удалённым рабочим местом (Remote Desktop Connection) на своём клиентском компьютере и набрать имя нашего сервера RDS1 или открыть веб- браузер и набрать в строке ввода https://rds1/rdweb. В любом случае они приземлятся внутри сеанса рабочего места, который выглядит и ощущается в точности как рабочее место Windows 10. Внутри этого рабочего места, предоставляемого вашим сервером RDS, они способны запускать приложения и сохранять документы, имея всё работающим и сохраняющимся прямо в самом сервере вместо их локального рабочего места компьютера. Из этой простой реализации отдельного сервера RDS мы можем строить и наращивать для их предоставления дополнительные роли RDS на большем числе серверов или для своих целей обработки дополнительных нагрузок пользователей.

Большинство реализаций RDS начинают с отдельного сервера или, по крайней мере, отдельного RDSH. Когда у вас имеются настроенные роли для успешной связи здесь, естественным следующим шагом является прибавление дополнительных серверов RDSH для размещения большего числа пользователей. Или, может быть, вы желаете разделить различные типы пользователей (и их приложения) на различные серверы RDSH. Какой бы ни была причина, существует вероятность, что в определённый момент вы пожелаете прибавить дополнительные серверы в свою среду RDS. Давайте добавим второй сервер к себе с тем, чтобы вы могли увидеть как происходит этот процесс.

У нас имеется отдельный работающий сервер, исполняющийся под Windows Server 2016. Он имеет имя RDS1 и уже выполняет роли Посредника соединения Rd, Хоста сеансов RD, а также Веб- доступа RD. Теперь мы применим имеющийся на RDS1 интерфейс управления чтобы добавить второй сервер RDSH в свою инфраструктуру. Именем нашего второго сервера будет RDS2 и он уже присоединён к нашему домену.

Чтобы добавить новый сервер RDSH в нашу существующую среду RDS следуйте таким инструкциям:

В этом рецепте мы воспользовались консолью управления Служб удалённых рабочих мест (RDS) в нашем первичном сервере RDSH чтобы получить новый сервер, который мы запустили и включили его в сервер RDSH (Remote Desktop Session Host). Этот RDSH теперь является частью нашей инфраструктуры RDS и может управляться прямо из данной централизованной платформы управления. В среде RDS это типичный способ, что новые роли добавляются в сервера, которые были привнесены в данную среду. Применение централизованной консоли управления для выполнения многих задач в RDS имеет прямой смысл, потому что будет гораздо проще когда вы видите большую картину своей инфраструктуры RDS при осуществлении изменений или обновлений.

Как только вы возьмёте Windows Server и превратите его в сервер RDSH, который будет применяться внутри среды RDS, значительно изменяется способ, которым работают приложения на этом сервере. Всякий раз, когда программы и приложения устанавливаются на такой RDSH, они вначале должны быть помещены в особый Install Mode (Режим установки). Помещение сервера в Режим установки перед запуском программы установки важно для получения гарантии того, что приложения собираются устанавливаться способом, который позволит множеству пользователей выполнять их одновременно. Помните, наши серверы RDSH будут размещать множество сеансов пользователей, возможно десятки.

Применение Режима установки настолько важно для надлежащей работы ваших приложений в RDSH, что вам на самом деле не стоит устанавливать никакие программы на сервер до того, как вы превратите их в RDSH. Раз эта роль была прижилась, тогда приложения могут быть безопасно установлены раз вы применяете Режим установки. Программы, установленные до преобразования данного сервера в RDSH могут не работать надлежащим образом и вам может понадобиться их демонтаж с повторной установкой. Существует пара различных способов которым Режим установки может быть запущен в процессе установки программы; давайте рассмотрим их оба.

Нам необходимо установить программу на свой сервер RDSH. Эта коробка работает под управлением Windows Server 2016 и уже является частью среды RDS. Нам также, естественно, необходимы файлы установки приложения которые мы собираемся запускать.

Один вариант надлежащей установки программ на RDSH состоит в использовании Панели управления (Control Panel) для установки данного приложения:

Второй способ поместить RDSH в Режим установки состоит в применении приглашения командной строки:

При установке программ в RDSH он должен быть вначале помещён в особый Режим установки (Install Mode). Выполнение этого повторно отображает определённые части устанавливаемой программы таким образом, что они могут быть запущены и использованы многими пользователями в одно и то же время. Установка ваших приложений путём применения одного из обсуждающихся в данном рецепте методов будет критически важной для успешной работы вашего окружения RDS чтобы оно было в состоянии предоставлять приложения пользователям.

Также имейте в виду, что вам рекомендуется не иметь зарегистрированных в RDSH пользователей в процессе времени установки. Когда вы строите новые серверы, будет проще чтобы вы обычно не позволяли никаким пользователям присоединяться пока всё не будет установлено и настроено. Однако если вам необходимо устанавливать новые программы или обновлять существующие на находящемся в использовании RDSH, вы захотите предпринять шаги чтобы гарантировать что пользователи не зарегистрируются на этом сервере до того как вы поместите его в Режим установки и запустите эти исполнения. Если у вас работает ферма серверов RDS, и вы хотите удалить только один из них для технического обслуживания или установки приложения, убедитесь что вы ознакомились с рецептом Удаление сервера RDSH от использования для сопровождения.

Я упоминаю о помещении вашего RDSH в Режим установки (Install Mode) даже когда просто устанавливаются обновления для существующих приложений. Это важно. Однако не следует помещать некий сервер в Режим установки чтобы устанавливать обычные обновления операционной системы Windows. Они способны корректно устанавливаться даже когда сервер находится в обычном Режиме исполнения (Execute Mode).

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

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

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

Мы зарегистрированы на своём RDSH Server 2016. Этот сервер размещает некоторую чувствительную информацию и мы хотим получить уверенность что пользователи не смогут сохранять документы на свои локальные компьютеры, не смогут печатать документы на локальные принтеры и не смогут выполнять copy/paste внутри своего буфера обмена чтобы перемещать данные из сеанса RDS на свои локальные компьютеры.

Для запрета таких функций перенаправления в нашей коллекции RDSH выполните следующее:

Предоставление пользователям возможности перемещения данных назад и вперёд между их локальными компьютерами и сеансами RDS кажется великолепной функцией, однако зачастую они менее чем желательны. При помощи некоторых простых флаговых пометок мы можем запретить эти возможности оптом чтобы вы могли оставаться верными политикам безопасности и гарантировать что чувствительные данные останутся защищёнными. Когда вы знакомы с местоположением этих настроек, их разрешение и запрет интуитивно понятны и легко выполняются. Что даже ещё лучше, так это то, что эти настройки могут изменяться в любое время; даже нет необходимости принимать какое- либо решение при построении вашей среды RDS. Если в дальнейшем пути вы примете решение переключить некоторые из них во включённое или выключенное состояние, вы сможете сделать это в любой момент времени в своём промышленном RDS.

Представим себе что вам позвонили удалённые пользователи из вашей компании; они в настоящий момент находятся в отеле и решают проблему как открыть некое приложение. Это приложение не установлено на их локальном компьютере, в то же время они являются некими RDS пользователями и они подключаются к виртуальном сеансу на сервере RDSH в вашей сетевой среде всякий раз, когда у них есть необходимость в этом приложении. Вы думаете попросить у них их пароль, так как этот вариант поможет вам просто зарегистрироваться в RDSH под их логином и позаботиться о решении имеющейся проблемы. Однако, увы, запрос пароля является серьёзным нарушением политики безопасности компании. Вместо этого вы скорее всего можете воспользоваться неким видом программного обеспечения организации контакта в реальном времени чтобы совместно использовать экран их ноутбука и попытаться пройти с ними совместно исправление данной проблемы. Однако это означало что они должны были бы выполнить установку такого программного обеспечения организации удалённого контакта и надежду на то, что вам удастся объяснить по телефону как им пользоваться.

Ищите лучшее решение? Воспользуйтесь функциональностью Отслеживания (Shadowing) RDS. Если вы зарегистрируетесь на сервере RDS, на котором эже зарегистрирован нужный вам пользователь, вы можете просто стать тенью их сеанса чтобы видеть то, что видят они. Тогда вы сможете работать совместно над разрешением их проблемы. Вы будете способны брать всё под контроль и исправлять проблему и, быть может, они даже смогут сделать некоторые замечания и научить вас что сделать для них, чтобы они в следующий раз не делали вам звонок.

Этот рецепт включён здесь в особенности из- за того, что Отслеживание RDS было всегда доступно в более ранних версиях Терминального сервера, однако было затем удалено из RDS Server 2012. Однако, хорошие новости! Оно было возвращено назад из- за множества запросов в Server 2012 R2 и продолжает оставаться здесь и в Windows Server 2016!

Наш удалённый пользователь зарегистрировался в нашем сервере RDSH, который называется RDS1. Это машина Server 2016, которая является частью нашей инфраструктуры RDS.

Давайте выручим удалённого пользователя теневым отслеживанием его сеанса RD:

Хотя теневое отслеживание Server 2016 не совсем такое же простое каким оно было ранее в предыдущих версиях Терминального сервера, всё- таки здорово знать, что эта возможность возвращена после замеченного отсутствия в Server 2012. Отслеживание RDS является великолепным инструментом для применения поиска неисправностей и совместной работы, так как оно позволяет вам совместно применять экран другого персонала и помогать ему собственными клавиатурой и мышью в управлении, когда возникает такая необходимость. Наличие двух наборов глаз в одном и том же сеанса может оказаться неоценимым во многих ситуациях; не забудьте попробовать его прямо сейчас!

Когда пользователь подключается к сеансу RD, если его клиент и сервер настроены надлежащим образом, это соединение попытается настроить перенаправление принтера между текущим сеансом RD и его локальным компьютером. В частности, каждый установленный на локальном компьютере принтер будет настроен как отдельный принтер внутри данного RD сеанса пользователя. Это именно то свойство, которое позволяет пользователям быть в состоянии печатать на своих локальных принтерах, даже если расстояние от места доступа до места печати составляет половину земного шара.

Когда RD соединение строит такие виртуальные принтеры, оно пытается применять актуальные драйверы принтера для них. Например, если принтером является HP LaserJet 4100 и ваш сервер RDSH имеет установленный драйвер HP LaserJet 4100, тогда когда такой принтер станет настроенным внутри обсуждаемого сеанса пользователя, он будет использовать уже существующий, официальный драйвер. Если пользователь зарегистрируется в RDSH с принтером, драйвер которого, однако, отсутствует в данном сервере RDSH, по умолчанию такой принтер не будет установлен. Существует некая настройка в той же самой странице настроек, где мы разрешали и запрещали перенаправление принтера в коллекции серверов RDSH, которая может частично помочь с этим. Если вы выберете конкретную опцию в этом экране для Use the Remote Desktop Easy Print print driver first, в случае, когда реальный драйвер принтера не существует для определённого принтера, вы будете применять общий драйвер, который в действительности может работать, а может и не работать с имеющимся принтером. Это может несомненно помочь с мостом над пропастью когда мы сталкиваемся с отсутствием драйверов, но это не всегда решает имеющуюся проблему.

Наилучшим способом гарантировать что ваши пользователи в состоянии печатать надлежащим образом будет установить актуальный драйвер в ваш RDSH. Итак, в чём цель данного рецепта? Кто не знает как правильно устанавливвать драйвер принтера? Я пишу это потому что большинство программных пакетов драйверов принтера в настоящее время являются полнофункциональными приложениями, и нам не нужно и четверти от того, что приходит вместе с ним. Устанавливающие драйвер пакеты потребляют намного больше пространства, чем это необходимо в случае применения с RDS и нам необходимо учитывать что мы устанавливаем реальные приложения, которые могут потенциально показываться внутри сеанса пользователя и вызывать конфликт. Итак, в чем ответ? Извлеките простые файлы драйвера из этих пакетов драйвера и примените только сами эти файлы чтобы установить соответствующий драйвер в Windows. Давайте сделаем это вместе с тем чтобы вы смогли увидеть о чём я говорю.

Мы будем устанавливать данный драйвер принтера в свой сервер RDSH, работающий под управлением Windows Server 2016. Для нашего примера мы будем использовать принтер Brother MFC-J625DW, потому что именно его я только что устанавливал для некоего пользователя. Brother обычно достаточно хорош, представляя простую, небольшую загрузку драйвера, которая содержит только те файлы, которые необходимы для самого драйвера.

Давайте работать вместе над загрузкой и установкой данного драйвера принтера в наш RDSH с тем, чтобы его можно было использовать для переназначения принтера:

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

По мере обретения опыта во всё большем и большем числе установок драйвера вы начнёте понимать как производители предоставляют простые пакеты драйвера для такой цели , а какие не подходят. В конце концов, однако, любое такое программное обеспечение всегда содержит простые файлы драйвера; иногда это просто вариант запуска гигантской программы установки с тем, чтобы она разместила эти файлы куда- то во временное местоположение на вашем жёстком диске. Что я обычно предпринимаю в таких ситуациях, так это запускаю установщик и прохожу его этапы необходимые чтобы обнаружить эти распакованные/ выделенные файлы. Когда они получены, нет необходимости выполнять что- либо ещё в таком мастере для установки программных приложений, так как вы знаете что нужные вам файлы драйвера расположены на вашем жёстком диске где- то на сервере. Вам только нужно найти их. Применение утилиты типа FileMon может помочь идентифицировать местоположение файла, который был только что изменён и достаточно быстрый способ отслеживания таких файлов драйвера которые обычно скрываются прочь в папке temp. Когда вы обнаружите нужные файлы, вы можете скопировать их в более постоянную папку для целей установки драйвера, прервать ваш мастер установки и пройти вместо этого указанные в данном рецепте этапы для установки такого драйвера.

Случается что вам будет необходимо выполнить некоторые сопроводительные работы на ваших серверах RDSH. Будь то установка обновлений, установка новых приложений или его извлечение для некоторых физических работ, это происходит рано или поздно. Если у вас имеется множество серверов RDSH в некотором объединении и вы просто отключите один, нагрузки пользователей со временем отсортируются, так как посредник (broker) RD отошлёт новые соединения для серверов RDSH, которые всё ещё включены, однако вы получите неоправданные ожидания и головную боль для некоторых пользователей, которые были зарегистрированы в тот момент, когда вы осуществили отключение. Намного более дружелюбным будет подать сигнал RDSH выполнять запрет на приём новых пользовательских соединений и позволить существующим прекратить действие по истечению некоторого периода времени. Это вариант подобный истощающей остановке (drain stop, сливной, дренажной) в мире NLB (сетевой балансировки нагрузки).

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

У нас имеется среда RDS настроенная с двумя серверами RDSH. Они имеют имена RDS1 и RDS2, причём у нас есть запрос осуществить некие работы по сопровождению на RDS2. Все наши действия будут осуществляться изнутри консоли управления RD в RDS1.

Чтобы остановить поток новых соединений к RDS2:

Этот простой вариант может оказаться очень полезной утилитой при рассмотрении сопровождения внутри вашей инфраструктуры RDS. Помните, что запрет новых соединений к определённому RDSH не означает что он немедленно станет доступным для технического обслуживания, поскольку существующие пользователи всё ещё будут оставаться подключёнными к нему. Всё что мы сделали, это только то, что никакие новые соединения не будут вливаться в него. Вам понадобится некоторое планируемое время для естественного сброса остающихся соединений которые не должны присутствовать на данном сервере при проведении его технического обслуживания.

Большинство рецептов в этой главе сосредоточены на полных сеансах рабочих мест, предоставляющихся серверами RDSH, так как это наиболее общий сценарий применения который я нахожу при использовании RDS в практических случаях. Одна дополнительная часть, которую я бы хотел бегло рассмотреть это публикация RemoteApp. Это возможность публиковать индивидуальные приложения для удалённых пользователей из сервера RDSH вместо полного сеанса рабочего места. Это предоставляет бесшовное окно для конкретного приложения, позволяя RemoteApp выглядеть и и ощущаться в точности как любая другая программа на вашем пользовательском компьютере. Давайте настроим простое приложение и проверим его применение с компьютера клиента. Ради простоты демонстрации этой возможности мы просто воспользуемся в качестве нашего приложения WordPad для его публикации и запуска.

Наша работа над публикацией WordPad в качестве RemoteApp будет выполнена из нашего RDSH Server 2016 имеющего имя RDS1. Мы будем также использовать компьютер клиента чтобы проверить доступность этого приложения когда завершим его публикацию.

Для публикации WordPad в качестве RemoteApp выполните следующие шаги:

Если у вас нет необходимости чтобы пользователи получал доступ к полному рабочему месту когда они регистрируются в в вашей среде RDS, у вас имеется возможность вместо этого публиковать отдельные приложения. Это может быть полезным для ограничения тех ресурсов, к которым осуществляют доступ сотрудники, или же, возможно для кого- то, например для производителя или временно назначенного, кому нужен доступ только к определённым программам и данным. Хотя это и было очень простой демонстрацией использующей программой испечённой внутри Windows, вы можете применить тот же самый процесс с другими приложениями, которые вы имеете установленными вами на своих серверах RDSH. {Прим. пер.: более сильное впечатление на вас может произвести некое CAD/CAE приложение или компьютерная игра, которая будучи установленной на сервере, имеющем мощный GPU (например, Nvidia Tesla Pascal P100) сможет отображаться на вашем ноутбуке/ смартфоне/ планшете, не имеющих естественных возможностей исполнять данное приложение. Приведём ссылки на наши переводы с подробностями по Применению RemoteFX и существующих вариантах Аппаратного ускорения графики (пусть последняя ссылка и в изложении для Horizon View, важна содержательная часть предоставляемых возможностей!).}

	Совет
	Убедитесь что вы установили данные приложения {Прим. пер.: и необходимое им оборудование, например, GPU} на всех серверах в вашей коллекции.

Я работал с RDS с тех пор, когда она ещё не называлась RDS, и время- от времени абсолютно все отдельные пользователи спрашивали о возможности сообщать какие пользователи подключены к каким серверам RDSH. В идеале они хотели бы видеть в исторической перспективе перечень зарегистрировавшихся людей, а порой даже также и некоторые данные о том когда пользователи завершают сеанс. Единственная информация, которую я смог обнаружить естественным путём предоставляемую Windows и которая может помочь с получением этих сведений это Журнал событий (Event Logs) Windows Security, однако он чрезвычайно путаный чтобы попытаться в этих сорняках найти то что вы ищите. Несомненно это не стоит потраченного на него времени. Так в чем же правда? Найденный мной простейший способ записывать информацию о регистрации в системе и выходе из неё состоит в построении и применении некоторого сценария, который буде исполняться на протяжении каждой регистрации в системе и при её покидании. Это достаточно просто сделать на каждом из ваших серверов; давайте попытаемся получить их вместе с тем чтобы у вас было понимание того что я обычно делаю, а потом вы можете отрегулировать это базовое решение под свои особые потребности.

Здесь мы собираемся построить пару сценариев на своём сервере RDS1, который является Хостом сеансов Удалённых рабочих мест. Всё что мы будем делать происходит прямо в этой коробке Windows Server 2016.

Чтобы начать записывать информацию о регистрациях пользователей на ваших серверах RDSH, выполните следующие шаги:

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

Мы можем применять очень простые сценарии регистрации в системе и выхода из неё в серверах RDSH чтобы создавать отчётную информацию о том кто регистрировался, где они регистрировались и сколько раз они входили в систему и покидали её. Включите эти сценарии отчётов в каждый из своих серверов и последующее получение их отчётов централизованном месте {Прим. пер.: например, при помощи Zabbix} может значительно улучшить ваши возможности создания информации об учётных записях пользователях. Это достаточно распространённый вопрос среди применяющих RDS и, к счастью, вы можете получать эту информацию и строить поверх неё дальнейшие какие- либо ещё важные для вашей организации информационные накопления.