Особенности обслуживания rdsh windows server в режиме drain mode

Принципы работы

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

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

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

Установите роль RD Connection Broker на сервере (это может быть выделенный сервер, или один из членов будущей фермы).
Добавьте все терминальные сервера в локальную группу безопасности «Session Broker Computers» на сервере с ролью RD Connection Broker.
Настройте всех членов фермы на использование сервера RD Connection Broker
Настройте записи DNS для реализация механизма «DNS round robin»

Шаг 1 : Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

Разверните роль Remote Desktop Services.
Нажмите кнопку Add Role Services.
На странице служб роли выберите Remote Desktop Connection Broker и нажмите Next

В моем стенде 2 сервера, настроенных следующим образом:

RDS01

RDS02

Шаг 2 : Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker

Нажмите Start -> Administrative Tools -> Computer Management.
В левой панели разверните узел Local Users and Groups, и выберите Groups.
Найдите локальную группу Session Broker Computers , и выберите пункт Properties.
На вкладке General, нажмите Add.
В окне выбора нажмите кнопку Object Types.
Отметьте пункт Computers, и нажмите OK.
Последовательно укажите и добавьте имена всех серверов, которые будут участвовать в терминальной ферме
Нажмите OK.

На RDS01

На каждом из терминальных серверов RD Session Host выполните следующее:

На сервер RD Session Host откройте консоль Remote Desktop Session Host Configuration (Start ->Administrative Tools->Remote Desktop Services -> Remote Desktop Session Host Configuration).
В разделе Edit settings, щелкните по полю Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажмите кнопку Change Settings.
В окне RD Connection Broker Settings выберите Farm member.
Введите имя сервера с ролью RD Connection Broker.
В окне Farm name, укажите имя создаваемой фермы.
Чтобы активировать балансировку нагрузки в ферме RD Connection Broker отметьте опцию Participate in Connection Broker Load-Balancing.
В случае необходимости можно настроить относительный вес каждого из серверов в ферме (Server weight). Значение по умолчанию — 100. В том случае, если вы зададите вес одного сервера 100, а другого 50, это будет означать, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
По умолчанию используется перенаправление по IP адресу (IP address redirection), также можно использовать перенаправление по токену (Use token redirection).

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02

Task 4 : Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

Откройте оснастку DNS (Start->Administrative Tools-> DNS).
Разверните сервер, и в зонах прямого просмотра (Forward Lookup Zones), разверните ветку с именем вашего домена.
Щелкните по зоне и выберите New Host (A or AAAA).
В поле Name укажите имя фермы (именно фермы, а не конкретного сервера в ней), а в поле IP address укажите ip адрес первого сервера в ферме.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.winitpro.ru)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

Компоненты Remote Desktop Services в Windows Server 2022/2016/2016/2012R2

В состав роли RDS в Windows Server входя следующие компоненты:

Remote Desktop Session Host (RDSH) – узлы сеансов RDS. Основные рабочие лошадки фермы RDS, на которых работают приложения пользователей;
Remote Desktop Connection Broker (RDCB) – посредник RDS подключений. Используется для управления фермой RDS, распределения нагрузки, обеспечивает переподключение пользователей к своим сеансам, хранит коллекции RDS и опубликованные приложения RemoteApps;
Remote Desktop Gateway (RDGW) – обеспечивает безопасный доступ к сервисам RDS из Интернета;
RD Web Access (RDWA) – веб интерфейс для доступа к рабочим столам, программам RemoteApp;
Remote Desktop Licensing (RD Licensing) — служба лицензирования, управляет RDS лицензиями (CAL) пользователей.

В нашем небольшом стенде будут всего три сервера со следующим распределением ролей

— RDSH
– RDSH
– RDSH, RDWA, RDCB, RD License

Предварительные требования, которые нужно выполнить перед созданием RDS фермы:

Установите одинаковую версию Windows Server на все сервера, настроить их, и добавить в один домен AD;
Откройте консоль ADUC (
) и переместите все хосты с ролью RDSH в одну OU в AD. Так будет удобнее применять единые настройки через GPO;
Создайте в домене группу для RDSH серверов (например,
) и добавьте в нее все хосты;
Если вы хотите использовать диски User Profile Disk (UPD) для хранения профилей пользователей RDS (или перемещаемые профили), нужно создать на файловом сервере сетевой каталог, в котором они будут хранится (желательно расположить этот каталог на отказоустойчивом файловом кластере Windows Server). Предоставьте права Full Control на этот сетевой каталог для группы
.

Дополнение 18.06.2019

Так же еще опытным путем было выяснено, что данная проблема можете возникать, из-за:

Старой версии VMware Tools, советую установить самую последнюю
Из-за типа сетевого интерфейса, на сбойной виртуальной машине был выставлен E100E, а не VMXNET3
Так же был удален TDI vShield Endpoint драйвер
Еще разбирая логи системы, я обнаружил, что перед тем, как на сервере начинались проблемы, сыпались ошибки с кодом ID 372, ID 600, ID 601, в таких случаях, это были отголоски старых драйверов, которые были заменены на EasyPrint чисткой спулера через задания, на постоянной основе, так как было много зависших заданий.

На этом у меня все, надеюсь, что ваши RDSH хосты стали нормально работать. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

2 Responses to На терминальном сервере висит выход из системы

Иван спасибо за статью. У нас реальная проблема с этим, ферма из 3 серверов, в пике бывает до 150-200 подключений. Проблема именно с одним хостом, раз в неделю он просто начинает глючить, новые сессии создаются, но в каком то зависшем состоянии,у пользователей висит логон. Помогает только перезагрузка сервера, причем жесткая ( с оснастки кластера), просто так он не перезагружается Куча драйверов установлено, и атоловские тоже. Подскажите пожалуйста с чего начать анализ? Как диагностировать? Или проще новый хост поднять и заменить этот? (Ферма досталась по наследству)

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

Пользователю не удается выполнить вход с помощью смарт-картыUser can’t sign in using a smart card

В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты.This section addresses three common scenarios where a user can’t sign in to a remote desktop using a smart card.

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC.This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. Сервер RDSH размещен в корневом домене.The RDSH server is hosted in the root domain. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности.Users at the branch site belong to a child domain, and use smart cards for authentication. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC.The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему.When users try to sign in to sessions on the RDSH server, they receive messages such as «The attempted logon is invalid. Указано неверное имя пользователя или другие неверные личные данные.»This is either due to a bad username or authentication information.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей.This issue is caused by how the root DC and the RDOC manage user credential encryption. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту.The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают.When a user receives the «invalid» error, that means the two keys don’t match.

Чтобы решить эту проблему, выполните одно из указанных ниже действий:To work around this issue, try one of the following things:

измените топологию контроллера домена, отключив кэширование паролей на RODC, или разверните на сайте филиала контроллер домена с доступом на запись;Change your DC topology by turning off password caching on the RODC or deploy a writeable DC to teh branch site.
переместите сервер RDSH в тот же дочерний домен, где находятся пользователи;Move the RDSH server to the same child domain as the users.
разрешите пользователям выполнять вход без смарт-карты.Allow users to sign in without smart cards.

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности.Be advised that all of these solutions require compromises in either performance or security level.

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B).This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены.When users attempt to sign in using a smart card, they are denied access with messages such as «No valid certificates found. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме».Check that the card is inserted correctly and fits tightly.» В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка:At the same time, the Windows Server computer records the Application event «An error occurred while retrieving a digital certificate from the inserted smart card. неправильная подпись.»Invalid Signature.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.).To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Что такое idrac

У компании Dell idrac или как ее еще можно расшифровать Dell Remote Access Controller, это технология управления сервером, через интерфейсную плату. Интерфейс dell idrac обладает своим процессором, RAM памятью и конечно же сетевым интерфейсом со своим mac адресом, для доступа к системной шине. Основные назначения idrac, это

Управление электропитанием
Получение системной информации о сервере (серийные номера)
Мониторинг физического состояния сервера
Монтирования ISO образов для установки систем
Удаленное включение и перезагрузка сервера Dell
Обновление прошивок BIOS

Все это доступно через дружелюбный веб интерфейс или же командную строку по ssh. С 5 поколения сервера Dell имеют спереди индекс i (integrated), что вас информирует о том, что DRAC интегрирован в аппаратную часть материнской платы сервера.

Настройка dell idrac

Включаем сервер и начинается загрузка, дожидаемся когда вам предложат нажать

Если у вас в данном сегменте локальной сети есть DHCP сервер, то вы должны поймать ip адрес, как на примере ниже.

У вас откроется BIOS подобная утилита idrac Configuration Utility. Выбираем IDRAC LAN, для изменения параметра нажимаем пробел, вы должны поставить в позицию ON.

Теперь идем в пункт LAN Parameters и настраиваем обязательно статический ip адрес, как и у любого сервера, запомните это правило. Так же заполняем шлюз и DNS адреса, жмем пробел для сохранения.

Далее переходим в пункт LAN User Configuration. В LAN User Configuration вам необходимо задать пароль для учетной записи Admin, у которой будет доступ к web интерфейсу, и проверьте что выставлено Account Access > Enable.

Все нажимаем ESC и сохраняем настройки через Save settings and server will reboot. Открываем браузер и вводим, заданный вами ip адрес Dell idrac.

По умолчанию вы попадете на вкладку System Summary, с общей информацией о сервере.

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

Как выглядит Dell Power Edge R740

И так, вот так вот выглядит данный, двух юнитовый сервер.

Как я и писал выше сервер 14-го поколения, дисковая полка в нем защищается вот такой решеткой в виде сот улия. Есть возможность закрыть замок.

В комплекте идет ключ в голубой вставке, который вы можете повесить хоть на стойку, либо же убрать в сейф.

Ключ имеет фирменную запись Dell.

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

Выдвинув ее вы найдете сервисные теги.

Диски в комплекте идут в формате 2,5 дюйма. С правой стороны будут:

VGA порт, что удобно для подключения монитора
Два USB порта, под флешку или клавиатуру с мышкой
Мини USB для сброса и настройки IDRAC или прошивки BIOS
Кнопка включения

Что такое VDI и как это работает?

Инфраструктура виртуальных рабочих столов (VDI) – это стандартный метод виртуализации рабочего стола. VDI – это разновидность виртуализации рабочего стола по модели клиент – сервер, которая предлагает удаленный доступ к виртуальному рабочему месту на централизованном сервере. Такая модель гарантирует, что все пользователи имеют доступ к одинаковому программному обеспечению, предоставленному администратором.

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

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

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

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

VDI обеспечивает пользователям бесперебойную работу на нескольких устройствах и повышает производительность. Этот подход хорошо зарекомендовал себя и будет работать еще много лет. VMWare и Citrix – лидеры отрасли в этой области.

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

Высокие накладные расходы связаны с дополнительными аппаратными ресурсами, лицензиями на несколько сервисов продуктов VDI и операционными системами Windows на устройство, а также ежегодным доступом к виртуальному рабочему столу (VDA).

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

210

Blog of Khlebalin Dmitriy

Terminal Server на Windows 2016. RemoteApp (часть 4).

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

Но настроить RemoteApp пришлось не просто так. У нас на сервере крутятся 2 платформы: 1с83 и 1с82. В 1с83 проблем нет, а вот в 1с82, люди жалуются на невозможность изменения масштаба в 1с и мелкий шрифт в ней же. Именно по этому было принято решение прокинуть 1с через RemoteApp.

Еще раз коротко о ролях терминального сервера:

1. Посредник подключения к удаленному рабочему столу. Он занимается подключением клиентского устройства к удаленным приложениям «RemoteApp», а также рабочим столам на базе сеансов, либо к виртуальным рабочим столам, зависит от того на базе какой технологии мы RDS построили.

2. Роль, которая обеспечивает веб-доступ к удаленным рабочим столам. Ее задача – предоставление ресурсов через веб-браузер.

3. Узел сеансов удаленных рабочих столов – данная роль позволяет размещать на сервере удаленные приложения, или основанные на сеансах рабочие столы.

4. Узел виртуализации удаленных рабочих столов. На данном узле, это у нас сервер Hyper-V, на котором у нас разворачиваются все виртуальные машины, доступ к которым получат все пользователи, что использую технологию VDI.

5. Шлюз удаленных рабочих столов, это посредник между клиентами из внешней сети и коллекции сеансов во внутренней сети и приложений. Шлюз – это безопасность, сервис у нас абсолютно безопасный. И благодаря тому, что RDS в 2012/2016 и 2012R2/201 становится более гибким, проработаны абсолютно все недочеты, которые были раньше. Сейчас этот сервис легко реализуем для огромных, масштабных проектов, для больших корпораций. Раньше возникали некоторые вопросы.

Преимущества «RemoteApp» над обычным «Сервером терминалов» :

Пользователь не путается между удаленным рабочим столом и своим локальным.
Программа 1С запускается сразу при клике по ярлыку, и выглядит как локально установленная.
Пользователь не видит всего рабочего стола и работает лишь с теми программами, которые назначил администратор.
Безопасность выше, чем на обычном сервере терминалов.
Скорость передачи изображения с сервера, выше, чем в сравнении с обычным сервером терминалов. (Оптимизация за счет, передачи не всей картинки, а лишь нужной программы).

Для начала необходимо создать коллекции, ранее мы их уже создали, я об этом уже писал, поэтому здесь пропущу.

Далее публикуем сами приложения RemoteApp (Публикация удаленных приложений).

Выбираем необходимое нам приложение (в моем случае это соответственно 1С):

Вроде благополучно все опубликовалось.

Теперь со своего компьютера набираю в браузере: https://your_server_ip/RDWeb/Pages/ru-RU/login.aspx (ругнется на сертификат, так как его нет, но это не страшно)

Далее предлагается локально скачать файлик:

Здесь сразу запускается 1С.

Все достаточно быстро и без проблем. Но, к сожалению, нашу текущую проблему с масштабированием 1С82 RemoteApp не решает. Но все работает.

На этом настройка закончена.

Всем хорошей работы.

P.S.

Думали опубликовать еще 1с82 через IIS WEB, но с платформой 1с82 это оказалось достаточно проблематично.

По публикации платформы 1с83 почитать можно здесь:

Обновление от 01.10.2020.

Ранее никогда не сталкивался с развертыванием терминального сервера без домена. И тут столкнулся, оказалось, что поставить его можно, а вот управлять через GUI не получится, только через PS.

Или вариант управлять через GUI с другого компа, описан здесь.

#2 – Сброс сессии пользователя и завершение зависших процессов в RDS сессии

Сначала попробуем найти и принудительно сбросить сессию пользователя, который не может зайти на RDS сервер. В диспетчере задач, на вкладке Users найдите нужного пользователя и через контекстное меню кликаем “Log off”. В большинстве случаев, этого достаточно, но иногда в диспетчере задач вы можете обнаружить множество зависших сессий с именем “(4)” вместо имени пользователя. Как правило в зависшей сессии будет присутствовать 4 процесса:

Client Server Runtime Process (csrss.exe)
Desktop Windows Manager (dwm.exe)
Windows Logon Application (winlogon.exe)
Windows Logon User Interface

В первую очередь попробуйте завершить все зависшие сессии с (4) через диспетчер задач, как описано выше. Если это не поможет, то лучше всего перезагрузить сервер, но зачастую такой возможности нет, поэтому пробуем решить проблему без перезагрузки:

Запустите командную строку с правами администратора и введите: Она покажет всех пользователей и их сессии на терминальном сервере. В выводе команды есть 3 интересующих нас столбца: SESSIONNAME, USERNAME и ID. Найдите пользователя (4) и соответствующий ему ID, в данном примере ID 2. Нам нужно завершить процесс csrss.exe который работает под этой сессией, сначала найдем его.
В командной строке введите: Команда выведет все процессы, которые запущены в этой сессии. Нам нужно найти процесс csrss.exe и соответствующий ему PID. В моём случае PID будет 5140. Нам нужно завершить этот процесс.
Сверимся по диспетчеру задач. Откройте диспетчер задач, перейдите на вкладку Details и найдите нужный вам PID и процесс.Если нужный вам PID соответствует процессу csrss.exe, то завершите процесс через контекстное меню и End task, либо через командную строку:

Это нужно проделать с каждым пользователем “(4)”, если их несколько.

Проблемы лицензирования

В условиях использования свободнораспространяемого ПО (такого, как X Window System) проблема лицензирования не возникает. Для ПО, предусматривающего в лицензионном соглашении ограничение на количество копий/пользователей, возникают затруднения.

В условиях терминального сервера могут использоваться следующие модели лицензирования:

Per seat (per device — на рабочее место) — для каждого устройства (тонкого клиента или рабочей станции) требуется отдельная лицензия, вне зависимости от количества пользователей

Подобная схема используется при лицензировании Terminal Services в составе Windows Server.
Per user (на пользователя) — для каждого пользователя (вне зависимости от числа одновременно работающих пользователей) требуется отдельная лицензия.
Per connection (конкурентная лицензия) — для каждого соединения требуется отдельная лицензия, при этом количество пользователей/рабочих мест не играет роли — важно количество одновременно обслуживаемых пользователей. Такую систему лицензирования использует Citrix Metaframe. В этом случае существует пул лицензий, каждое новое соединение забирает одну лицензию из пула

Лицензия возвращается в пул при окончании соединения.

В этом случае существует пул лицензий, каждое новое соединение забирает одну лицензию из пула. Лицензия возвращается в пул при окончании соединения.

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

Виды терминальных серверов

Microsoft Windows Terminal Server (поставляется в Microsoft Windows Server)
Citrix Metaframe
X Window System
NX NoMachine
FreeNX
RX@Etersoft

См. также

Сервер приложений
Бездисковая станция
Тонкий клиент
Терминальный доступ
Терминальный режим работы
PXE
BOOTP
TFTP
Remote Installation Services (RIS)
RDP
SSH
Терминальная ферма

Управление Drain Mode с помощью PowerShell

Вы можете управлять настройками режима слива для коллекции хостов RDS или на отдельном сервере с помощью PowerShell:

При изменении режима работы Слив изменяются значения следующих параметров в регистре:

WinStationDisabled в HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon\
TSServerDrainMode HKLM \ System \ CurrentControlSet \ Control \ Terminal Server\

Например, в режиме слива они устанавливаются

Вы также можете проверить текущий режим слива на узле с помощью следующего сценария PowerShell:

Режим слива включается в PowerShell следующим образом (аналог

Чтобы перевести сервер в нормальный режим (

), запустите:

Источник изображения: winitpro.ru.sessionbrokerdrainmode){0 {«Enabled»}1 {«DrainUntilRestart»}2 {«Drain»}default {«error»}}}}