Rdp клиент для windows server 2012

В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки сервера терминалов в Windows Server 2008 R2, однако есть ряд значимых отличий. Итак:

Оглавление

1. Что понадобится
2. Установка службы удаленных рабочих столов
3. Определение сервера лицензирования для службы удаленных рабочих столов
4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов
5. Подключение к серверу терминалов

1. Что понадобится

1. Компьютер (сервер) с установленной на нем  Windows Server 2012 (об установки этой ОС, я писал здесь) и права администратора на данном сервере.
2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования. (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера:  6565792, 5296992, 3325596, 4965437, 4526017.)
3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

2. Установка службы удаленных рабочих столов

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть» (Open) написать имя команды и нажать «ОК» ).

В меню, в верхнем правом углу, выбираем «Управление» (Manage) — «Добавить роли и компоненты» (Add Roles and Features) .

Запустится «Мастер добавления ролей и компонентов» (Add Roles and Features Wizard). Нажимаем «Далее» (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов» (Role-based or features-based installation) и снова жмем «Далее» (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее» (Next) .

Отмечаем роль «Службы удаленных рабочих столов» (Remote Desktop Services) в списке ролей и жмем «Далее» (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее» (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее» (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов» (Remote Desktop Licensing) (также соглашаемся на установку дополнительных компонент нажав  на «Добавить компоненты» (Add Features) в появившемся мастере)

и «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» (Add Features) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее» (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется» (Restart the destination server automatically if required) , подтвердим выбор нажав «Да» (Yes) в появившемся окне и нажмем «Установить» (Install) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» (Close) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства» (Tools) — «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

• «Конфигурация компьютера» (Computer Configuration)
  • «Административные шаблоны» (Administrative Templates)
    • «Компоненты Windows» (Windows Components)
      • «Службы удаленных рабочих столов» (Remote Desktop Services)
        • «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host)
          • «Лицензирование» (Licensing)

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов» (Use the specified Remote Desktop license servers) , кликнув  2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено» (Enabled) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК» .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов» (Set the Remote licensing mode) . Также устанавливаем переключатель в «Включено» (Enabled) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

• «На пользователя» (Per User)
• «На устройство» (Per Device)

Для того, чтобы разобраться чем отличаются эти режимы, рассмотрим простой пример. Предположим, у Вас есть 5 лицензий. При режиме «На устройство» вы можете создать неограниченное число пользователей на сервере, которые смогут подключаться через удаленный рабочий стол только с 5 компьютеров, на которых установлены эти лицензии. Если выбрать режим «На пользователя», то зайти на сервер смогут только 5 выбранных пользователей, независимо с какого устройства они подключаются.

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК» .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов» (RD Licensing Manager) . Найти его можно в диспетчере серверов, вкладка «Средства» (Tools) — «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов» (Remote Desktop Licensing Manager) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован» (Not Activated) . Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер» (Activate Server) .

Запустится Мастер активации сервера. Жмем «Далее» (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто» (Automatic connection) по умолчанию) и жмем «Далее» (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее» (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее» (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее» (Next) оставив включенным флаг «Запустить мастер установки лицензий» .

4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов

Нажимаем «Далее» (Next) на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement«» . Жмем «Далее» (Next) .

Вводим номер соглашения и нажимаем «Далее» (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее» (Next) .

Ну и дожидаемся завершения работы мастера установки лицензий с сообщением о том, что запрошенные лицензии успешно установлены.

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».

Ищете лучший менеджер RDP подключений к удаленному рабочему столу? Тогда эта статья для вас.

Обслуживание компьютеров и серверов требует от системного администратора ежедневно устанавливать, как минимум, несколько RDP-соединений. Также сисадмин может выполнять другие ежедневные подключения, такие как SSH или telnet, для устранения неполадок и управления сетевым оборудованием. Ежедневная установка всех этих соединений вручную, снова и снова, отнимает много времени.

Использование менеджера подключений к удаленному рабочему столу намного эффективнее и экономит время. Особенно когда у вас может быть более 50 подключений в день.

Лучшие бесплатные менеджеры удаленных подключений (RDP) для администраторов серверов, системных инженеров, разработчиков и других IT-специалистов для доступа к удаленным системам с различными протоколами.

1.   mRemoteNG

mRemoteNG (форк mRemote) — это многопротокольный менеджер удаленных подключений с открытым исходным кодом для Windows.

Как и RDCman, это централизованный инструмент, который управляет подключениями к удаленным системам. mRemoteNG имеет много функций, которых нет у RDCman, например, возможность управлять различными типами подключения.

Помимо RDP, он поддерживает протоколы VNC, ICA, SSH, Telnet, RAW, Rlogin и Http/S.

Функция вкладок удобна, когда вы открываете несколько сеансов и вам нужно переключаться между ними.

Дополнительные функции включают простоту организации и ведения списка подключений, хранение учетных данных для автоматического входа в систему, импорт из Active Directory, полноэкранный режим, возможность группировки и вложения папок и многое другое.

mRemoteNG прост в использовании и имеет понятный интерфейс. Позволяет сгруппировать все подключения к серверу и создать отдельные группы для всех других типов подключений, таких как SSH.

Поддерживаемые протоколы:

• RDP (Remote Desktop Protocol)
• VNC (Virtual Network Computing)
• SSH (Secure Shell)
• Telnet (TELecommunication NETwork)
• HTTP/HTTPS (Hypertext Transfer Protocol)
• rlogin (Remote Login)
• Raw Socket Connections
• Powershell remoting

mRemoteNG Open Source проект под лицензией GPLv2.

Сайт: https://mremoteng.org

2.       RoyalTS

RoyalTS — это диспетчер соединений, который поддерживает различные типы соединений, такие как RDP, VNC, SSH, S/FTP и веб-интерфейсы. Правами доступа можно управлять и работать с ними в команде. Списком соединений также можно поделиться, не раскрывая личных данных.

 Программа RoyalTS доступна на Windows, OS X, Android и iOS, что сразу ставит её немного выше большинства аналогов. Включает в себя встроенный диспетчер учетных данных, параметры совместного доступа к команде, поэтому вы можете поделиться списком подключений, не раскрывая личные данные. Передавать файлы с использованием FTP, SFTP и SCP, подключаться к сеансам TeamViewer, управлять экземплярами Hyper-V и VMWare. Также Royal TSX анализирует события Windows, запускает, устанавливает и перезапускает службы, мониторит запущенные процессы. И позволяет автоматизировать такие задачи, как последовательность команд, и оптимизировать рабочие процессы.

Royal TS условно бесплатный. Бесплатно можно сделать максимум 10 подключений. 

Сайт: https://www.royalapps.com/ts/win/features

3. Devolutions Remote Desktop Manager

Devolutions — это еще один централизованный диспетчер соединений, который может обрабатывать различные протоколы и централизовать учетные данные.

Этот продукт включает функции двухфакторной аутентификации. Это обеспечит выполнение двух последовательных шагов аутентификации для предоставления доступа к источнику данных.

Он также имеет возможность управлять рабочими столами и серверами с помощью мобильного приложения. В Devolutions Remote Desktop Managerесть есть все что только можно пожелать. Быстрый поиск сервера (по тегу, имени, описанию). Автозаполнение форм на web-консолях. Свой модуль PowerShell. Вы даже можете интегрировать существующие менеджеры паролей, такие как keepass и lastpass.

Devolutions поставляется в бесплатной и платной версиях. Бесплатная версия хороша для отдельных пользователей, корпоративная — для команд.

Сайт: https://devolutions.net/remote-desktop-manager/compare

4. DameWare Mini Remote Control

SolarWinds DameWare Mini Remote Control — применяется в основном для поиска и устранения неисправностей в IT-инфраструктуре, а также для установки ПО. Это инструмент, который в основном используется сотрудниками службы поддержки и техническими специалистами для простого установления соединений с устройствами конечных пользователей.

Основное различие между этим и диспетчером соединений RDP заключается в том, что он позволяет совместно использовать экран. С RDP удаленная система выйдет из системы, поэтому вы не сможете поделиться экраном с конечным пользователем. Вот почему менеджеры RDP лучше всего подходят для серверов.

Damware поддерживается на нескольких платформах и позволяет удаленно управлять компьютерами Windows, Linux и Max.

Основные возможности:

• Многоплатформенный общий доступ к рабочему столу и удаленное управление
• Удаленный доступ к компьютерам в спящем режиме и при отключенном питании
• Многофакторная аутентификация
• Гибкая система управления доступом пользователя
• Настраиваемое и автоматическое развертывание средств удаленного управления
• Инструменты и утилиты для сеансов удаленного доступа
• Отсутствие абонентской платы, подключение неограниченного количества конечных устройств
• Сообщение чата для общения с удаленными пользователями

• Встроенный инструмент для скриншотов
• Безопасная передача файлов
• Блокировка клавиатур конечных пользователей
• Удаленное пробуждение по локальной сети
• Удаленное редактирование настроек BIOS
• Интеграция с Active Directory и многое другое

Программа платная.

Скачать пробную версию (на 14 дней): https://www.solarwinds.com/dameware-mini-remote-control/registration

5. Terminals

Terminals — это менеджер удаленного рабочего стола с несколькими вкладками, который поддерживает несколько протоколов, таких как RDP, VNC, SSH, Telnet, Citrix, HTTP и HTTPS.

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

Terminals также включают в себя набор сетевых инструментов, таких как ping, tracert, wak on lan, DNS Tool, сканер портов и другое. Это может пригодиться для устранения основных неполадок.

Terminals — это проект с открытым исходным кодом, который в настоящее время не находится в стадии разработки.

Скачать можно тут: https://github.com/Terminals-Origin/Terminals 

Бонус:

Dameware remote everywhere — это облачное решение для удаленной поддержки, которое позволяет ИТ-специалистам получить доступ практически к любой платформе (Windows, Mac, Linux, iOS и Android).

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

Ключевая особенность:

• Запись сеанса
• Скрыть обои и гашение экрана
• Совместное использование экрана и поддержка нескольких мониторов
• Организация и управление соединениями
• Живой чат и видеоконференции
• Встроенные инструменты устранения неполадок
• Удаленно перезапускать и выключать устройства
• и многое другое.

Нажмите здесь, чтобы начать БЕСПЛАТНУЮ пробную версию на 14 дней. 

Заключение

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

Надеемся, что этот список помог найти подходящий диспетчер удаленных подключений, Вам и Вашей команде.

Термины и упоминания используемые в статье

Remote Desktop (удаленный рабочий стол) — это термин, которым обозначается режим управления, когда один компьютер получает права администратора по отношению к другому, удаленному. Связь между устройствами происходит в реальном времени посредством Интернет или локальной сети.

RDP (Remote Desktop Protocol) — протокол удаленного рабочего стола от Microsoft. Предназначен для подключения и работы пользователя с удаленным сервером. RDP позволяет удаленно подключаться к компьютерам под управлением Windows и доступен любому пользователю Windows, если у него не версия Home, где есть только клиент RDP, но не хост.

По умолчанию во всех операционных системах Windows для подключения по протоколу RDP (Remote Desktop Protocol / Удаленный рабочий стол) использует порт TCP 3389. После того, как вы включили RDP доступ в Windows, служба TermService (Remote Desktop Services) начинает слушать на порту 3389.

Коротко об RDCMan

RDCMan (Remote Desktop Connection Manager) —менеджер RDP соединений, позволяющий управлять в одном окне большим количеством RDP подключений, создавать древовидные структуры с удаленными Windows серверами и рабочими станциями.

Компания Microsoft прекратила разработку RDCMan (Remote Desktop Connection Manager) после обнаружения в нем уязвимости.

Утилита RDCMan была разработана командой Windows Live Experience для внутреннего использования. Приобрела большую популярность у системных администраторов в конце 2000-х и начале 2010-х годов, а Microsoft выпускала обновления для него вплоть до 2014 года (последняя доступная версия RDCMan 2.7 ).

После релиза встроенного в Windows MSTSC, а также официального приложения Remote Desktop, Майкрософт заявила, что поддержка RDCMan в скором времени будет прекращена, и компания рекомендовала переходить на использование указанных решений.

В марте 2020 Microsoft заявила, что в RDCMan была обнаружена уязвимость CVE-2020-0765, которая позволяла злоумышленникам похищать данные с компьютеров пользователей  и полностью удала страницу загрузки RDCMan.

В июне 2021 года Марк Русинович заявил, что утилита RDCMan переходит в состав инструментов Sysinternals и продолжит развитие. Новая версия Remote Desktop Connection Manager (RDCman) является бесплатной и доступна к загрузке на сайте Microsoft. Актуальная версия доступна по ссылке https://docs.microsoft.com/en-us/sysinternals/downloads/rdcman

Утилита является бесплатной и доступна к загрузке на сайте Microsoft. Актуальная версия 2.81

Понравилась статья? Поделись!

Описание задачи: Настраиваем терминальный сервер Windows 2012 R2 для возможности предоставления вычислительных ресурсов пользователям.

Шаг 1 — Настройка роли терминального сервера на windows 2012 R2

Авторизуйтесь в ОС под локальной учетной записью администратора и запустите Диспетчер серверов (Server Manager).

Запускаем мастер добавления ролей и компонентов, где выбираем тип установки «Установка ролей или компонентов»:

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В нашем случае это локальный сервер. Нажимаем «Далее».

Отмечаем роль «Службы удаленных рабочих столов» в списке ролей и жмем «Далее».

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее».

Теперь необходимо выбрать устанавливаемые службы ролей. Выбираем «Лицензирование удаленных рабочих столов» и также соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» в появившемся мастере.

Также устанавливаем «Узел сеансов удаленных рабочих столов». Отметив необходимы службы ролей, нажимаем «Далее».

Все параметры установки роли определены. Жмем «Далее».

На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется, нажимаем «Да» в появившемся окне и нажимаем «Установить» для запуска установки службы.

Если все прошло хорошо, после перезагрузки увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» для завершения работы мастера.

Шаг 2 — Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов». Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства»— «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов».

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду «gpedit.msc» в пункте меню Пуск — Выполнить.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:
«Конфигурация компьютера» — «Административные шаблоны» — «Компоненты Windows» — «Службы удаленных рабочих столов» — «Узел сеансов удаленных рабочих столов» — «Лицензирование»
Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов», кликнув 2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено». Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В нашем случае сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК».

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов». Также устанавливаем переключатель в «Включено» и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта — «На пользователя» или «На устройство».

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК».

Изменив вышеперечисленные политики, закрываем редактор.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов». Найти его можно в диспетчере серверов, вкладка «Средства»— «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов».

Здесь найдем наш сервер лицензирования, со статусом «Не активирован». Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер».

Запустится Мастер активации сервера. Жмем «Далее» на первой странице мастера. Затем выбираем метод подключения «Авто» и жмем «Далее».

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее»
Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее»
Сервер лицензирования активирован.

Шаг 3 — Установка лицензий на сервер лицензирования службы удаленных рабочих столов

Теперь произведем установку лицензии на сервер лицензирования службы удаленных рабочих столов. Для этого нажимаем в окне «Лицензирования удаленных рабочих столов» на активированный сервер лицензирования и выбираем пункт «Установить лицензии».

Нажимаем «Далее» на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement». Жмем «Далее».

Вводим номер соглашения и нажимаем «Далее».

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее».

Ждем завершения работы мастера установки лицензий с сообщением о том, что запрошенные лицензии успешно установлены. Жмем «Готово».

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

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

На этом настройка сервера терминалов в Windows Server 2012 завершена.

Шаг 4 — Подключение к серверу терминалов

Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».

Есть вопросы? Можете написать в чат для связи с нашим специалистом.

remoteapp в 2012 R2 без домена — начну с главного: всё нормально и быстро настраивается. Опубликовать remoteapp в 2012 R2 без домена не получится, но это и не нужно.

При обновлении 2008 R2 до 2012 R2 на этапе проверки совместимости, установка попросила удалить роль Удаленных рабочих столов. Удивился. Ладно.. После обновления стало понятно, Microsoft в очередной раз перехитрила саму себя: теперь нормально работать с RDP можно лишь в составе домена.

Зачем.. Если у меня сервер 1С на 5 бухгалтеров, зачем мне роль AD DS? Думаю я не одинок в этом вопросе. Почитал в интернете, решение есть! Кто-то ставил роль контроллера домена, в виртуалке поднимал ещё один сервер, вводил в домен и на нём уже удаленные рабочие столы. Всё проще. Солюшенов несколько, решил собрать воедино.

---

Сервер

Установка роли

Службы удаленных рабочих столов (Remote Desktop Services), Далее, отмечаем чекбоксы: Лицензирование удаленных рабочих столов (Remote Desktop Licensing), Узел сеансов удаленных рабочих столов (Remote Desktop Session Host), со всем соглашаемся, установка, перезагрузка.

В Диспетчере серверов, в пункте меню Средства, появилась закладка Terminal Services (или Remote Desktop Services для 2016).

Настройка параметров RDP

Настройка всех параметров RDP теперь в групповых политиках. Отдельной графической оснастки, как было раньше, нет:

• Win+R - gpedit.msc - Конфигурация компьютера (Computer Configuration);
• Административные шаблоны (Administrative Templates) -
Компоненты Windows (Windows Components);
• Службы удаленных рабочих столов (Remote Desktop Services) -
Узел сеансов удаленных рабочих столов (Remote Desktop Session Host) - Лицензирование (Licensing).

Редактируем два параметра:

• Использовать указанные серверы лицензирования удаленных рабочих столов (Use the specified Remote Desktop license servers) — включено — указываем имя сервера;
• Задать режим лицензирования удаленных рабочих столов (Set the Remote licensing mode) — включено — на пользователя.

В соседних ветках настраиваются все параметры подключения клиентов.

Далее: Диспетчер серверов - Службы удалённых рабочих столов (Terminal Services) - правой кнопкой на сервере - Диспетчер лицензирования удаленных рабочих столов (Remote Desktop Licensing Manager) - Активировать сервер. Сведения об организации: обязательно нужно заполнить первую страницу, вторую можно оставить пустой.

После активации запускается Мастер установки лицензий:

• Выбираем Enterprise Agreement — Далее (бессмысленный набор цифр ищем в интернете, ищется легко, буквально вторая/третья ссылка) — вводим номер — Далее — выбираем число лицензий и тип на пользователя. Заходим Диспетчер серверов - Все серверы - правой кнопкой на сервере - Средство диагностики лицензирования удалённых рабочих столов, проверяем, что нет ошибок.

Создаем файл RDP

На примере 1С предприятия: открываем блокнот и помещаем туда следующую информацию, заменяя имя_сервера на действительное имя сервера или IP:

redirectclipboard:i:1
redirectposdevices:i:0
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
span monitors:i:1
use multimon:i:1
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:1
authentication level:i:2
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:0
gatewaycredentialssource:i:0
full address:s:имя_сервера
alternate shell:s:||1cestart
remoteapplicationprogram:s:||1cestart
gatewayhostname:s:
remoteapplicationname:s:1C Предприятие
remoteapplicationcmdline:s:

Сохраняем файл, меняем расширение на .rdp, раздаём пользователям.

Реестр

Главный шаг, от которого будет зависеть заработает или нет. Правим реестр на сервере через блокнот:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart]
 "CommandLineSetting"=dword:00000000
 "RequiredCommandLine"="" 
 "Name"="1C Предприятие"
 "Path"="C:Program Files (x86)1cv8common1cestart.exe" 
 "ShortPath"="C:PROGRA~21cv8common1cestart.exe" 
 "ShowInTSWA"=dword:00000001
 "SecurityDescriptor"=""

Проверяем правильность путей, сохраняем с раcширением .reg, закидываем в реестр. Проверяем. Если не работает, смотрим ветку 1cestart. Значения из reg-файла должны перенестись. И на всякий пожарный ветку TSAppAllowList там же, у меня это:

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowList] 
 "LicenseServers"=hex(7):00,00 
 "CertificateIssuedBy"="" 
 "LicensingType"=dword:00000005 
 "fHasCertificate"=dword:00000000 
 "CertificateExpiresOn"="0" 
 "CentralLicensing"=dword:00000000 
 "fDisabledAllowList"=dword:00000000 
 "CertificateIssuedTo"="" 
 "CustomRDPSettings"="authentication level:i:2"

Возможные проблемы

Когда недавно делал по своей же инструкции, то получил сообщение, что приложения 1С нет в списке разрешенных.

Или вот такое ещё может быть:

Посмотрел на сервере ветку 1cestart:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart

Она пустая. При копировании текста с сайта могут неправильно переноситься кавычки, ещё что-то. Поэтому нужно подправить/проверить вручную.

1. Path — для 1С 8.3 будет 1cv8common1cestart.exe, для 1С 8.2 1cv82common1cestart.exe
2. ShortPath то же самое.

Подключение через интернет

В файлике rdp вместо имя_сервера, можно использовать IP-адрес (или даже IP-адрес с портом через двоеточие, или же указать порт в соответствующей строке). Это позволяет подключать клиентов через интернет и NAT:

• Пробросить на роутере рандомный внешний порт на внутренний 3389 сервера;
• Вбить в файлик внешний реальник офиса с портом.

Конструкцию с RD Gateway считаю излишней. Тем более если делается с пробросом 443 порта на внутренний ресурс, тем более что RD Gateway требует установки роли Web Server, то есть потребляет ресурсы. Чем проще, тем надежнее. После настройки роли RDP и проверки работоспособности смело можно удалить даже фичи для администрирования RDP, они больше не нужны.

---

Клиенты

Клиенты MAC

Добавляем клиентов MAC OS X:

• Обновляем встроенный в MAC OS X RDP-клиент от MS на последнюю версию;
• Отключаем проверку подлинности.

Если режим remoteapp не нужен, то на этом всё. Если нужен, берём файл rdp, созданный по описанию выше для Windows, меняем имя_сервера на IP-адрес, закидываем на мак и всё работает.

Клиенты Windows XP

Добавляем клиентов Windows XP:

• SP3 должен быть установлен;
• Включаем проверку подлинности на уровне сети (NLA). Тут обновляем RDP-клиент, потом включаем NLA. Сначала КB969084, ребут, потом FixIt. Скачать.

Клиенты Android

Наверное последнее, что нужно сказать по этой теме, для Андроида тоже есть RD Client от MS. Функционирует он штатно и нормально. Приложение бесплатное, загружается через Play Market. Как и для Mac’а файл rdp, закинутый на Андроид, запустится с помощью этого приложения, но логин и пароль при этом сохранить невозможно, а нужно вводить каждый раз.

Связана такая ситуация, с тем, что в новых версиях RDP учетные данные не сохраняются в самом файле rdp, а хранятся в отдельной базе данных. На компьютере эти данные можно посмотреть в Панель управленияУчетные записи пользователейДиспетчер учетных данных, либо Выполнить: control userpasswords2, что тоже самое.

Где искать в Андроиде? Не знаю, да и не очень интересно, так как remoteapp для телефонов и планшетов больше блажь, чем реальная потребность. Обычная RDP-сессия работает? — Работает. Этого достаточно.

Три способа повысить защиту RDP

1. Уровень безопасности SSL;
2. Уровень шифрования FIPS-совместимый;
3. Подключения принимаются только от клиентов с NLA.

---

Траблшутинг

Залипания

Если возникают на 1 клиентском компьютере, нужно проверить сам компьютер и такие вещи как драйвера на видеокарту, количество свободных ресурсов, потому как залипание может происходить в моменты, когда жесткий диск свопит изо всех сил и даже мышку. Была курьёзная ситуация (несвязанная с данной проблемой), что при нажатии на кнопку мыши щелчок есть, а фактически нажатия нет, поменяли мышку, всё работает.

Если же залипание массовое и с ресурсами сервера всё в порядке, то проблема 90% сетевая. В 2012 R2 для RDP используется как TCP, так и UDP или только TCP. Нужно проверить, что UDP используется. Статья в помощь. Сайт MS. Таже нужно просмотреть политики.

---

Область применения

Статейка написана давно, более чем 2 года назад, тогда Windows Server 2012 R2 был ещё относительно свежим и хотелось разобраться как же это всё настроить. Был накидан рабочий черновик, вот эта заметка и ни на какую полноту она не претендует. С тех пор поднято несколько серверов в данном режиме, которые работают так по сей день.

Тема исчерпана, но вопросы идут и некоторые люди не понимают нишу использования remoteapp, зачем такой режим, почему именно для 1C, какой тут смысл и в чём заключается выигрыш. Вещи-то очевидные, но раз так, то надо сказать пару слов.

remoteapp не панацея

В общем и целом remoteapp решение нищебродское, если уж по честному. Плюсом есть очень толстые минусы как RDP, так и remoteapp:

1. Каждый раз когда пользователь хочет сохранить файл, ему открываются диски удалённой машины. Есть варианты, но это неудобно в работе;
2. Далеко не все пользователи продвинутые и с компьютером «на ты», многие очень тяжело воспринимают remoteapp, они путаются где какой диск, сложно и затратно по времени растолковать им данный режим работы;
3. Для запуска remoteapp нужно время, так как на сервере должен загрузиться пользовательский сеанс;
4. При закрытии приложения сеанс отключается и нужно ждать его завершения (минимум 1 минута), если в сеансе открыт конкретный фал, он будет блокирован на запись. Можно разрешить множественные сеансы для пользователя или можно убрать ограничения для отключенного сеанса, тогда возникают другие проблемы;
5. В зависимости от версии Windows Server могут возникать различные глюки, связанные с временными задержками (не помню точно в какой версии сервера, но загружается сеанс и его нельзя завершить ~30 секунд сразу после загрузки, было такое);
6. Каждое запущенное приложение — отдельный сеанс и отдельная нагрузка на сервер;
7. Сам сервер и лицензии для RDP стоят приличных денег, этот вопрос всплывёт рано или поздно.

Может что-то даже упустил из виду, хотя и так немало. Поэтому использовать remoteapp нужно тогда, когда это действительно необходимо.

Примечание. Очень хороший пример когда не нужно использовать remoteapp — Word и Excel. 

Зачем 1С remoteapp?

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

1. Если чистый файловый вариант базы и как раз 5-6 человек, потому как больше такая схема не потянет, тогда весь обсчёт на клиентах — для того чтобы перенести обсчёт с клиентов на сервер. Это позволяет увеличить число клиентов и одновременно значительно повысить скорость работы без внедрения СУБД;
2. Удаленная работа через медленные либо лимитные каналы связи как в файловом варианте, так и в клиент-серверном — передавать изображение намного выгоднее по объёму трафика, чем трафик 1С.

remoteapp vs классический RDP

Обычно в случае 1С база на сервере, а вот документы для работы на локальном компьютере. Всё время сворачивать и разворачивать окно RDP неудобно, remoteapp тут гораздо комфортнее.

Исключения

1. Если все клиентские машины достаточно мощные (Core i3 и выше), баз мало (1-2-3), базы файловые, сеть локальная гигабитная, пользователей не больше, скажем, 5 и работа с базой не слишком интенсивная, тут даже сервер не нужен. Подойдёт любой компьютер с гигабитной сетевой картой и быстрым диском. Важный момент, что все машины мощные, так как 1 слабый компьютер станет узким местом и скорость работы будет равняться по нему;
2. При удалённой работе есть альтернатива remoteapp — веб публикация 1С. У каждого из этих решений свои плюсы и минусы;
3. Используется СУБД и тонкие/веб клиенты. Тогда ничего не надо, стандартные корпоративные каналы достаточно широкие сейчас чтобы переварить такой трафик. Открыть для 1С TCP 1540, 1541, 1560-1591 на FW и вперёд.

Почему 2012 R2

C чистой 2012 без R2 встретиться в работе не удалось и ничего про неё не скажу. Но если сравнивать 2008 R2 и 2012 R2, то последняя имеет значительно перелопаченный код, как следствие быстрее работает на том же самом железе, а сетевой стек до 30% быстрее.

Поддержка самого железа, особенно различных RAID-контроллеров, тоже лучше. И если на 2008 R2 драйвер при установке нужно подпихивать, то в 2012 R2 он скорее всего уже встроен, сталкивался несколько раз. Поддержка RDP 8.1.

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

---

Windows 2016

Эта статья получила довольно таки широкое распространение. Чего там говорить, вот да.. И как-то однажды, давно, где-то там на форуме, уже не вспомню каком, читал человек пишет: ставил по этой статье с этого сайта (с моего, отсюда) и на 2016 не работает. Дальше обсуждение на n-страниц. Как всегда. Ну не работает и не работает, мож даже и к лучшему. 🙂 Но тут меня недавно (22.04.2021) спросили конкретно здесь, в комментариях: почему не работает с 2016?

Что делать.. заставляете тряхнуть стариной. Уже не ставил этих серверных виндовс пару лет, 1С ещё дольше. Почти всё подзабыл, так что сильно не ругайте, если что-то не то скажу. Итак, нашёл образ, установил в виртуальную машину VMware, поставил все обновы:

Получилось так:

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

Какие тут были ещё замечания

Первое. Служба Сервера 1C Предприятие не хотела стартовать от текущего пользователя при установке дистрибутива. Пришлось выбрать Создать нового пользователя и всё успешно запустилось. Второе. Сам дистрибутив 1С 8.3.17.1549 и он чисто x64. То есть ставится в папку C:Program Files, а не в папку C:Program Files (x86). Соответственно в reg-файлике нужно сделать изменения:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart]
 "CommandLineSetting"=dword:00000000
 "RequiredCommandLine"=""  
 "Name"="1C Предприятие" 
 "Path"="C:Program Files1cv8common1cestart.exe" 
 "ShortPath"="C:PROGRA~11cv8common1cestart.exe" 
 "ShowInTSWA"=dword:00000001
 "SecurityDescriptor"=""

И как уже говорил нужно контролировать что там добавилось в реестр. И добавилось ли вообще. Ветка TSAppAllowList:

Ветка 1cestart:

В rdp-файлике прописывал не имя сервера, а IP. Потому что мой компьютер не знает какое там имя у виртуальной машины. Прописывать в файл hosts мне было лень.

Запускаю файлик с домашнего компа и вуа-ля:

Другой дистрибутив

Может образ какой-то не тот? Хорошо, скачиваю оценочный образ с Microsoft.

14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_RU-RU.ISO 

Опять мега долго ставлю обновления.

Версия после обновлений та же самая, что логично.

Скачиваю платформу 1С, версия 8.3.17.1549, но уже x86+x64. Сначала ставлю x86. Проверяю, не работает. Ищу где ошибка. При экспорте reg-файла не создаются ключи Path и ShortPath. Вообще никак. Добавляю руками (смотри картинку выше). Работает.

Теперь x64. Прям в реестре правлю параметры Path и ShortPath. Накатываю дистрибутив прям поверх x86. Проверяю, работает.

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

Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP.

В качестве аппаратной платформы для тонкого клиента мы будем использовать устройства HP t610, хотя в рамках нашей задачи эти устройства имеют более чем избыточную конфигурацию. По сути минимальные системные требования для тонкого клиента с Thinstation – любой «аппаратный хлам» начиная с уровня Pentium-II с 128MB RAM и выше. Мы будем использовать бездисковую конфигурацию тонких клиентов, то есть загрузка системы будет выполняться по сети с использованием PXE (приоритетно) или с локальных загрузочных USB-накопителей (для клиентов без поддержки PXE и в отдалённых участках со слабым каналом передачи данных).

Когда я изучал доступные в открытых источниках статьи на тему подобного развёртывания, то среди множества материалов выделил для себя статью Пети Хинчли «Use Thinstation to build a network-bootable RDP-enabled thin client image», от наработок которой я и буду отталкиваться. Также в качестве полезного источника информации стоит отметить такие русскоязычные ресурсы, как Thinstation по русски и Thinstation Доработка тонкого клиента.

В рассматриваемом примере имеется несколько исходных условий, от которых нам придётся отталкиваться:

• Все тонкие клиенты должны быть изолированы в рамках одной сети и должны маршрутизироваться только до своего RDS-сервера.
• RDS-сервер, помимо предоставления сессий удалённых рабочих столов, по совместительству должен выполнять все функции управления тонкими клиентами (раздача IP адресов, раздача загрузочных образов ОС, раздача настроек каждого конечного клиента и т.д.).
• Загрузка конечной рабочей среды тонкого клиента должна происходить автоматически без участия пользователя/оператора (авто-логон RDP-сессии и запуск необходимой оболочки – конечного бизнес-приложения)
• Цикличная работа тонких клиентов должна быть автоматизирована, то есть клиенты должны автоматически включаться по расписанию утром каждого рабочего дня и выключаться в конце рабочего дня.    

Начнём процедуру настройки с выделенного сервера, который в нашем случае является виртуальной машиной Hyper-V с предварительно установленной гостевой ОС Windows Server 2012 R2 Standard. Развернём и настроим на этом сервере службы DHCP и WDS.

Настройка сервера DHCP

Для автоматического назначения IP-адресации нашим тонким клиентам установим и настроим службу DHCP на нашем сервере управления.

Устанавливаем роль DHCP Server через оснастку Server Manager или через PowerShell:

Install-WindowsFeature -Name DHCP -IncludeManagementTools

После установки роли откроем оснастку Server Manager и запустим мастер Post-Deployment Configuration, после завершения которого роль сервера DHCP может считаться развёрнутой.

В нашем примере сервер DHCP разворачивается на компьютере, не являющемся членом домена, поэтому с авторизацией (активацией) службы DHCP не возникнет проблем – сразу после развёртывания сервер будет готов к работе. Создадим для тонких клиентов область с пулом выдаваемых IP адресов и активируем её:

В случае если DHCP сервер разворачивается на доменной системе, то дополнительно может потребоваться его авторизация. Если прав Администратора домена нет, то провести авторизацию сервера можно путём небольшой правки реестра: Как авторизовать DHCP сервер не имея прав Администратора домена.

В оснастке управления правилами Windows Firewall проверяем правила относящиеся к серверу DHCP (как минимум нужно разрешить входящие подключения по протоколу UDP на порты 67/68)

Настройка сервера Windows Deployment Services

Роли Windows Deployment Services и Web Server понадобятся нам для возможности раздачи по сети (PXE) загружаемых образов Thinstation тонким клиентам по протоколам TFTP/HTTP. Устанавливаем роли:

Install-WindowsFeature -Name "Web-Server","WDS" -IncludeManagementTools

К настройке веб-сервера IIS мы обратимся позже, а сейчас рассмотрим то, как настроить WDS сервер на поддержку загрузчика SYSLINUX.

Откроем консоль WDS и первым делом вызовем мастер конфигурирования сервера Configure Server

На первом шаге мастер ознакомит нас с требованиями необходимыми для работы WDS.

• Первым пунктом идёт информация о том, что сервер может быть сконфигурирован как с поддержкой доменной инфраструктуры, так и в изолированном варианте (как раз наш случай).
• Службу сервера DHCP мы уже развернули. В процессе конфигурации WDS будет включена специальная опция DHCP сервера для поддержки PXE-клиентов.
• Среди требований присутствует наличие DNS-сервера в сети, хотя в нашем конкретном случае в этом нет реальной необходимости. DNS это конечно хорошо и правильно, но мой практический опыт работы с Thinstation показал, что полностью избавится от применения IP-адресов вместо FQDN-имён не получится, и поэтому я решил вообще не заморачиваться с использованием службы DNS.
• Отдельный NTFS-раздел для хранения загрузочных образов сделан на нашем WDS-сервере (далее в примерах будет фигурировать как диск D:)

На шаге выбора типа развёртывания WDS, согласно исходных условий нашего примера, выбираем режим изолированного сервере Standalone server

На шаге размещения каталога для файлов WDS и загрузочных образов по умолчанию предлагается каталог C:RemoteInstall. В нашем примере путь изменён на диск D:

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

На шаге настроек PXE по условиям нашей задачи разрешаем WDS серверу отвечать на запросы всех PXE-клиентов

По завершению работы мастера служба WDS будет запущена. В консоли WDS откроем свойства сервера и на закладке Boot отключим включенное по умолчанию требование нажатия F12 на стороне PXE-клиента для возможности загрузки по сети, выбрав опцию Always continue the PXE boot.

Заглянем в оснастку управления сервером DHCP и проверим, что в DHCP-опциях на уровне сервера появилась опция PXE

***

Теперь сделаем ряд действий по добавлению нашему WDS серверу поддержи SYSLINUX.

Скачаем архив актуальной версии загрузчика syslinux-6.03 по ссылке:

https://www.kernel.org/pub/linux/utils/boot/syslinux/

Распакуем архив syslinux-6.03.zip и выполним следующие действия:

• Скопируем в каталог D:RemoteInstallBootx64 на сервере WDS следующие файлы:
  syslinux-6.03bioscorepxelinux.0 (переименовать в pxelinux.com)
  syslinux-6.03bioscom32menuvesamenu.c32
  syslinux-6.03bioscom32elflinkldlinuxldlinux.c32
  syslinux-6.03bioscom32chainchain.c32
  syslinux-6.03biosmemdiskmemdisk
• Скопируем файл D:RemoteInstallBootx64abortpxe.com в файл abortpxe.0.
• Скопируем файл D:RemoteInstallBootx64pxeboot.n12 в файл pxeboot.0.

Повторим действия, проделанные для каталога D:RemoteInstallBootx64 применительно к каталогу D:RemoteInstallBootx86

***

Создадим каталог D:RemoteInstallBootpxelinux.cfg (не файл, а именно каталог). В этом каталоге будут хранится конфигурационный файлы PXE, которые будет отдавать WDS-сервер PXE-клиентам.

Создадим конфигурационный файл PXE «по умолчанию» с именем default в каталоге D:RemoteInstallBootpxelinux.cfg и добавим в него следующий контент:

DEFAULT RDP
PROMPT 0
NOESCAPE 1
ALLOWOPTIONS 0
LABEL RDP
MENU DEFAULT
KERNEL /Linux/vmlinuz
APPEND initrd=/Linux/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3

***

В командной строке с правами Администратора перейдём в каталог D:RemoteInstallBootx64 и создадим символическую ссылку (junction) на каталог D:RemoteInstallBootpxelinux.cfg:

cd /d D:RemoteInstallBootx64
mklink /J pxelinux.cfg D:RemoteInstallBootpxelinux.cfg

Повторим тоже самое для каталога D:RemoteInstallBootx86:

cd /d D:RemoteInstallBootx86
mklink /J pxelinux.cfg D:RemoteInstallBootpxelinux.cfg

 
***

Создадим каталог D:RemoteInstallImagesLinux. В этом каталоге мы будем размещать загружаемые образы ОС тонких клиентов.

В командной строке с правами Администратора перейдём в каталог D:RemoteInstallBootx64 и создадим символическую ссылку (junction) на каталог D:RemoteInstallImagesLinux:

cd /d D:RemoteInstallBootx64
mklink /J Linux D:RemoteInstallImagesLinux

Повторим тоже самое для каталога D:RemoteInstallBootx86:

cd /d D:RemoteInstallBootx86
mklink /J Linux D:RemoteInstallImagesLinux

***

Для того, чтобы настроить WDS на использование добавленных нами загрузочных программ SYSLINUX (замена стандартного для WDS загрузчика pxeboot на pxelinux), выполним ряд команд с правами Администратора на сервере WDS:

wdsutil /set-server /bootprogram:bootx86pxelinux.com /architecture:x86
wdsutil /set-server /N12bootprogram:bootx86pxelinux.com /architecture:x86
wdsutil /set-server /bootprogram:bootx64pxelinux.com /architecture:x64
wdsutil /set-server /N12bootprogram:bootx64pxelinux.com /architecture:x64

Примечание: Если в дальнейшем по какой-то причине потребуется восстановить загрузочные программы (pxeboot), используемые в WDS по умолчанию, сделать это можно командами:

wdsutil /set-server /bootprogram:bootx86pxeboot.com /architecture:x86
wdsutil /set-server /N12bootprogram:bootx86pxeboot.n12 /architecture:x86
wdsutil /set-server /bootprogram:bootx64pxeboot.com /architecture:x64
wdsutil /set-server /N12bootprogram:bootx64pxeboot.n12 /architecture:x64

***

В оснастке управления правилами Windows Firewall проверяем правила относящиеся к серверу WDS (как минимум нужно разрешить входящие подключения по протоколу UDP к исполняемому файлу службы).

А также включаем правило, разрешающее входящий трафик к веб-серверу IIS

Кстати, к настройке веб-сервера IIS мы ещё вернёмся позже.

Развёртывание сборочной среды DevStation

Для сборки собственных загрузочных образов проект Thinstation, в качестве одного из вариантов, предлагает использовать специальную загружаемую среду DevStation. Используя загрузочный дистрибутив DevStation, мы развернём выделенную Linux-систему, с помощью которой в дальнейшем будем собирать загрузочные образы Thinstation для конечных тонких клиентов. Прежде всего в DevStation будет сгенерирован специальный загрузочный образ Thinstation, с которого, в свою очередь, нужно будет загрузиться на всех используемых типах аппаратных конфигураций наших клиентов и сгенерировать профиль оборудования. На базе полученных профилей оборудования на нашем сервере DevStation будут скомпилированы конечные загрузочные сборки Thinstation под каждую аппаратную конфигурацию. Такой подход позволит свести к разумному минимуму размер загружаемого по сети образа Thinstation для каждой конкретной партии «железок».  

Под задачу развёртывания DevStation можно использовать виртуальную машину. В сети можно найти примеры использования для этих целей виртуальных машин на базе VMWare и VirtualBox. В моём случае используются среды виртуализации Microsoft Hyper-V и oVirt. Попытки развернуть DevStation 5.5 на виртуальную машину Hyper-V 2012 R2 результата не дали, так как происходило зависание процесса установки на стадии разметки диска, хотя с определением диска проблемы не возникало. В конечном итоге виртуальная машина была создана в среде виртуализации oVirt с настройками согласно документа DevStation setup.

Созданная виртуальная машина имеет 2vCPU , 3GB ОЗУ, vHD 25GB (при меньшем размере диска, чем 20GB, DevStation может не установиться). В качестве интерфейса диска вместо используемого по умолчанию в oVirt 4.0.6 значения VirtIO я выбрал IDE, так как развёртывание DevStation заработало корректно только на этом интерфейсе.

***

Загружаем последнюю версию DevStation по ссылке: Thinstation Latest Download

В нашем случае это файл TS-5.5.1-Installer-0627.iso размером 212MB

Загружаемся в подготовленную виртуальную машину с ISO-образа и выбираем пункт установки – Installer for DevStation

В память загрузится Live-система, будет выполнен авто-вход в графическую оболочку, где с рабочего стола запустим ярлык Install to HD. В открывшейся форме нам поведают о том, что на самом деле можно прожить и без выделенной инсталляции DevStation, залив git-клон проекта Thinstation на любой другой сборочной Linux-системе.   

Утвердительно «кивнём гривой», после чего будет запущена процедура проверки Интернет-соединения.

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

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

После того, как Интернет-соединение будет успешно проверено, нам сообщат о том, на какой диск будет установлена система DevStation.

Затем укажем предпочитаемое разрешение экрана. У нас ВМ и выбор здесь небольшой.

Затем из представленных списков выберем свою временную зону и раскладку клавиатуры:

Перед началом процесса установки DevStation нас предупредят о том, что все данные на диски будут уничтожены (инсталлятор по своему усмотрению выполнит разметку диска)

Будет запущена программа развёртывания DevStation, в ходе которой будет выполнена разметка диска, загрузка и установка всех необходимых пакетов из онлайн-репозитория проекта Thinstation размером примерно около 2GB.

Процедура может занять от 20 минут и более, в зависимости от пропускной способности вашего Интернет-канала и проворности диска виртуальной машины. Когда процесс будет завершён, мы получим несколько уведомительных сообщений о том, как собрать собственный загрузочный образ тонкого клиента…

…о том, что наша система DevStation способна выступать в качестве PXE-сервера…

…и о том, что загрузочный образ ISO, с которого мы выполняли установку теперь нам больше не нужен, как, впрочем, и прямое подключение к Интернет, и после перезагрузки мы уже можем использовать установленную систему…

На это этапе можно извлечь загрузочный ISO образ из привода виртуальной машины и нажать OK

Отправляем виртуальную машину в перезагрузку.

Сборка служебного образа Thinstation

Подключаемся к консоли только что развёрнутой сборочной среды DevStation. Учётные данные при этом вводить не требуется, так как в системе настроен авто-вход. Пароль пользователя root на нашей виртуальной машине DevStation — pleasechangeme. По умолчанию в DevStation включен Telnet-сервер и с этими учётными данными без проблем можно удалённо подключиться к системе. И как я понял, простого и вменяемого способа изменить такое поведение нет. Лишь в ветке обсуждения Thinstation Installer Disc Server — ssh access я нашёл пример того, как вместо Telnet можно включить SSH и сменить root-пароль, который подразумевает пересборку самого образа DevStation. Что скорее всего, как следствие, вызовет необходимость его переустановки. Как бы там ни было, включённая система DevStation нам нужна только на этапе сборки конечных образов тонких клиентов, а всё остальное время можно держать её выключенной.

Итак, с рабочего стола графической среды DevStation запускаем ярлык Terminal Chroot

В открывшейся консоли автоматически откроется файл справки README. Нажмём Q чтобы закрыть справочный файл и перейти в консоль.

Сменим текущий каталог на /build. Здесь мы и будем выполнять практически всю работу – настройку конфигурации под наших клиентов и сборку образов для их загрузки. В первую очередь нас интересуют два основных файла build.conf и thinstation.conf.buildtime. Первый файл определяет порядок сборки образов Thinstation, то есть то, какие в образ будут включены драйверы для поддержки оборудования (например поддержка определённых видео-адаптеров), какие будут добавлены пакеты приложений сервисного уровня (например поддержка NFS, NTP и т.п.) и прикладного уровня (например наличие веб-браузера, RDP-клиента и т.д.) и ряд других параметров сборки. Второй файл добавляется в собираемый образ и в основном служит для передачи неких параметров/переменных, которые могут определять тот или иной порядок работы тонкого клиента и включённых в него приложений.

На данном этапе перед нами стоит задача сборки служебного загрузочного образа Thinstation, который будет содержать в себе все драйверы, поддерживаемые средой Thinstation и с минимальными изменениями в файле build.conf. Этот служебный образ потребуется нам для того, чтобы на следующем этапе, загрузившись с него уже на конечных устройствах – тонких клиентах, выполнить процедуру генерации файлов профиля оборудования, которые в свою очередь будут использоваться для сборки конечных результативных образов тонких клиентов.

Удалим имеющуюся символическую ссылку на конфигурационный файл build.conf и создадим новый файл на базе шаблона build.conf.example

# rm build.conf  
# cp build.conf.example build.conf

Обратите внимание на то, что все команды здесь мы будем выполнять в chroot-окружении, которое ссылается на каталог /thinstation/ относительно корневой системы DevStation.

С помощью текстового редактора внесём минимальные корректировки в файл build.conf.
В частности, нужно убрать комментарий (#) в строке содержащей запись package extensions-x (этот пакет содержит инструменты создания профилей оборудования, в том числе и скрипт hwlister.sh, который нам потребуется в дальнейшем)

В целом этого достаточно, однако на практике я столкнулся с багом squashfs and firmware.list generation #192, который, как я понимаю, на данный момент не исправлен. Баг приводит к тому, что в процессе генерации профиля оборудования, который мы будем делать на следующем этапе, не создаётся файл firmware.list, что может привести к отсутствию корректной поддержки необходимых аппаратных компонент тонкого клиента. В качестве обходного решения этой проблемы на данный момент является замена параметра initrdcmd (Compression Mode) в файле build.conf c «squashfs«…

… на «gzip -9«

Сохраним отредактированный файл build.conf и выполним команду сборки образа, включающего в себя все драйверы, которые поддерживает Thinstation

# ./build --allmodules

В процессе сборки будет задан вопрос о добавлении Firefox в собираемый образ. Если он Вам не нужен, вполне можно от него отказаться. То же самое касается включённых в конфигурации по умолчанию гостевых компонент VBox.

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

В конечном итоге на данный момент нас интересуют 2 файла, появившихся после компиляции — initrd (Initial RAM Disk) и vmlinuz (Linux Kernel). Файл vmlinuz служит для первичной загрузки и инициализации оборудования тонкого клиента, после чего начинается загрузка initrd. 

После завершения процесса компиляции оба эти файла можно найти в каталоге /thinstation/build/boot-images/pxe/boot/ (в консоли «Terminal Chroot» это каталог /build/boot-images/pxe/boot/). Нужно скопировать эти два файла на наш WDS-сервер в каталог D:RemoteInstallImagesLinux

Создадим временную сетевую папку на нашем Windows-сервере и предоставим доступ на запись к этой папке для своей учётной записи. На DevStation-машине создадим новый каталог и смонтируем в него сетевую папку с Windows-сервера WDS, после чего скопируем в смонтированную папку все нужные нам файлы:

# mkdir /mnt/WDSTempShare
# mount.cifs //KOM-APP20/TempShare /mnt/WDSTempShare -o user=volodya
# cp /build/boot-images/pxe/boot/initrd /mnt/WDSTempShare/
# cp /build/boot-images/pxe/boot/vmlinuz /mnt/WDSTempShare/
# umount /mnt/WDSTempShare

На WDS-сервере из папки /TempShare перенесём файлы initrd и vmlinuz в каталог, из которого PXE-сервер будет отдавать PXE-клиентам файлы для загрузки D:RemoteInstallImagesLinux

Получение файлов профиля оборудования для Thinstation

Задача получения профиля оборудования заключается в том, чтобы загрузить эталонный компьютер (тонкий клиент с типичным для партии набором аппаратных компонент) с образа Thinstation собранного с опцией —allmodules и выполнить в этой системе скрипт /bin/hwlister.sh. Данный скрипт сгенерирует файлы профиля оборудования и попытается передать их на PXE-сервер, встроенный в DevStation.

Обратите внимание на то, что на данном этапе PXE-загрузку эталонного клиента (для генерации файлов профиля оборудования) мы можем произвести как с нашего WDS-сервера (ведь мы уже скопировали на него загрузочные файлы образа initrd и vmlinuz), так и с встроенного в DevStation PXE-сервера. Однако стоит учитывать то, что скрипт hwlister.sh будет пытаться передать получившиеся файлы профиля оборудования именно на тот PXE-сервер, с которого он был загружен. Поэтому для генерации профиля оборудования будет проще всего загружаться именно с PXE-сервера встроенного в DevStation.

При этом на сервере DevStation для загрузки будут использоваться именно те файлы initrd и vmlinuz, которые расположены в каталоге /thinstation/build/boot-images/pxe/boot/, так как этот каталог является корневым для встроенного в DevStation PXE-сервера. Именно поэтому важно, чтобы при попытке загрузки эталонной машины c PXE-сервера DevStation, на этом сервере в каталоге /thinstation/build/boot-images/pxe/boot/ находились файлы образа собранного с опцией —allmodules, который мы собрали в на предыдущем этапе. Это предотвратит потенциальные проблемы с распознаванием оборудования и полноценной загрузкой Thinstation.

***

Теперь на нашем Windows-сервере потребуется на время внести некоторые изменения:

• В оснастке управления сервером DHCP создадим резервирование IP для эталонной машины
• В оснастке управления сервером WDS отключим опцию интеграции с DHCP

Чтобы заставить нашу эталонную машину тонкого клиента загружать образ по сети не с WDS сервера, а с машины DevStation, создадим на DHCP-сервере резервирование IP адреса для эталонной машины с опциями 66 и 67:

66 = <IP-адрес DevStation>

67 = boot/pxelinux/pxelinux.0

Кстати, в значении 67 опции по замечанию из статьи Thinstation OS можно указать путь к другому файлу, чтобы изменить загрузку с TFTP на HTTP (это может несколько ускорить процесс загрузки образа). Для этого значение boot/pxelinux/pxelinux.0 нужно заменить на на boot/lpxelinux/lpxelinux.0. Однако, как я понял, загрузка по HTTP поддерживается не всеми сетевыми картами и поэтому в большинстве случаев всё же будет использоваться TFTP.

Так, как мы планируем использовать PXE сервер с DevStation, то в нашей конфигурации потребуется на время отключить PXE сервер, встроенный в WDS, чтобы из опций DHCP-сервера исчезла опция 060 = PXEClient. Если этого не сделать, то WDS может передавать PXE-клиенту не тот адрес PXE-сервера, который нас интересует.

***

Переходим на DevStation и разрешаем запись всем пользователям в корневой каталог встроенного TFTP сервера. Для этого можно либо выполнить консольную команду:

# chmod 777 /thinstation/build/boot-images/pxe

Либо в графической оболочке вызвать через пункт меню Start > DevStation > Toggle PXE Read/Write:

После вызова этого пункта меню мы увидим сообщение о том, что запись для PXE-сервера включена:

***

Включаем эталонный компьютер. При старте клиент получит с DHCP зарезервированный нами IP-адрес с опциями указывающими на PXE-сервер DevStation и начнёт оттуда загружать образ.

На загруженном эталонном клиенте в графической оболочке открываем меню Applications > Utilities и выбираем Terminal Emulator

В окне терминала запускаем генерацию профиля оборудования с передачей на машину DevStation командой:

# /bin/hwlister.sh

Заглянем в каталог /thinstation/build/boot-images/pxe на DevStation машине. Здесь появятся файлы переданные с клиента (в зависимости от «железа» клиента): module.list, package.list, firmware.list

Итак, аппаратный профиль эталонного клиента получен и передан на DevStation. Теперь можем выключить эталонный компьютер. Он нам больше не нужен.

На DevStation создаём новый подкаталог для профиля клиента в каталоге /thinstation/build/machine/ (/build/machine/ в chroot-окружении) и переносим туда только что полученные с эталонного клиента list-файлы

# mkdir /build/machine/HPt610  
# cd /build/machine/HPt610  
# mv /build/boot-images/pxe/*.list . 

Далее созданный профиль под названием HPt610 мы будем использовать при сборке конечного рабочего образа (будем указывать имя этого каталог в build.conf).

Туже самую процедуру создания нового профиля из list-файлов, попавших в каталог /thinstation/build/boot-images/pxe, можно сделать и с помощью графической оболочки DevStation. Для этого будет достаточно вызвать пункт меню  Start > DevStation > Make Machine Profile и указать имя нового профиля

***

Отключаем право на запись в PXE-сервере DevStation через ранее упомянутый пункт меню Start > DevStation > Toggle PXE Read/Write или командой в терминале:

# chmod 755 /thinstation/build/boot-images/pxe

***

Возвращаемся на наш Windows-сервер и в консоли WDS не забываем обратно включить опцию поддержки интеграции PXE с DHCP (вторую галочку)

А в консоли управления DHCP-сервером удаляем созданное ранее резервирование, которое мы делали под эталонного клиента.

Сборка рабочего образа Thinstation

На данном этапе можно считать, что у нас всё готово для сборки конечного рабочего образа Thinstation, который будет использоваться для наших тонких клиентов определённой аппаратной конфигурации. Процедура сборки аналогична той, что мы рассмотрели ранее, когда делали служебный образ Thinstation с главным отличием в том, что сборка выполняется без ключа —allmodules. При этом в собираемый образ Thinstation будут добавлены только те модули поддержки оборудования, которые перечислены в незакомментированных строчках перечисляющих профили оборудования (machine …) в файле build.conf.

Базовую информацию о структуре конфигурационного файла build.conf можно получить из документа Thinstation Wiki — build.conf. Логика простая – включаем только те модули и пакеты, которые нужны для работы наших тонких клиентов, всё что не нужно – отключаем (комментируем), так как каждый лишний модуль/пакет увеличивает размер образа который получится в результате компиляции. При этом лучше не отключать те вещи, значение которых вам непонятно, если не хотите потерять время на отладке, которой можно было и не заниматься. 

Далее рассмотрим правки, которые нужно внести в build.conf исходя из условий нашей задачи.

В секции #!Hardware добавим запись о ранее созданном профиле machine HPt610

В секции #!!File System Support оставим модули usb-storage, isofs, udf, vfat. Остальные модули закомментируем. Эти модули нам потребуются на случай необходимости загрузки не по сети а с накопителей, типа USB-флэш диск.

В секции #!!Miscellaneous (я обнаружил в файле 2 таких секции) в списке пакетов закомментируем ранее включённый пакет extentions-x, так как на рабочем образе тонкого клиента в нём нет необходимости. Для возможности нормальной автоматической конфигурации сети в процессе загрузки тонкого клиента включим пакет ts-classic, выключим networkmanager и добавим autonet.

В секции #!!X закомментируем пакеты xorg7-vmware и, при необходимости, раскомментируем прочие (например в нашем случае нужен пакет xorg7-ati). В любом случае рекомендуется оставлять пакет xorg7-vesa, так как он будет использован, если родной пакет драйвера не обнаружен или по какой-то причине не заработал.

В секции #!!Locale закомментируем все языковые пакеты за исключением тех. которые могут нам быть полезны: locale-en_US и locale-ru_RU.

В секции #!Applications закомментируем пакеты все ненужные нам пакеты, например firefox, open-vm-tools и vboxguest. В нашем случае в этой секции остаться только пакет freerdp.

В секции #!!Window Managers комментируем все пакеты оконных менеджеров, так как в нашей ситуации в них нет необходимости.

В секции #!!Other services комментируем пакеты cups (печать в нашем случае не нужна) и samba-client (нам не требуется, чтобы тонкий клиент мог куда-то попасть по SMB).

В секции #!!Basic раскомментируем параметр fastboot, чтобы использовать механизм быстрой загрузки образа (HTTP вместо TFTP). Зададим значение пароля в параметре rootpasswd. Закомментируем параметры xorgvncpasswd, storagepasswd, dualupasswd, sambapasswd, так как в них нет нужды. Так, как мы собрались использовать быструю загрузку HTTP, зададим параметр baseurl, в котором укажем URL-адрес веб-сервера и параметр basepath, в котором укажем имя папки на веб-сервере, в которой нужно искать файлы для загрузки. Параметр initrdcmd вернём в исходное значение «squashfs».

В конечном счёте (без учёта закомментированных строк) конфигурационный файл build.conf в нашем случае примет следующий вид:

#!Hardware
machine HP-t610
#!!Filesystem Support
module usb-storage
module isofs
module udf
module vfat
#!!Miscellaneous
package overlayfs
package ts-classic
package autonet
package udisks
package ntp
package cpufreq
#!!X related
package xorg7-vesa
package xorg7-ati
#!!Locale
package locale-en_US
package locale-ru_RU
#!Applications
package freerdp
#!!Miscellaneous
package fonts-TTF-BH
package fonts-TTF-vera
package fonts-TTF-liberation
#!!Basic
param fastboot       true
param rootpasswd     Str0nGpWd
param bootlogo       true
param boottheme    default
param splash       silent
param fbmtrr         0
param fbnocrtc       true
param fbsm           ywrap
param bootresolution 1280x768-32
param desktop file:./backgrounds/Hive_Lite.jpg
param defaultconfig  thinstation.conf.buildtime
param basename       thinstation
param basepath       ThinClients
param baseurl        http://10.1.4.10
param haltonerror    false
param hardlinkfs     true
param sametimestmp   true
param initrdcmd    "squashfs"
param bootverbosity   3
#!!Advanced
param downloads       /downloads
param bootimages      "iso syslinux pxe"
param syslinuxtheme   "default"
package alltimezone
param allres    true
param allfirmware   true
param blacklist snd-pcsp.ko

***

Следующим правим конфигурационный файл thinstation.conf.buildtime, предварительно сделав копию оригинального файла на всякий случай:

# cp thinstation.conf.buildtime thinstation.conf.buildtime.original

Базовую информацию об этом файле можно получить в документе Thinstation Wiki — thinstation.conf, а узнать о возможных параметрах и их описании можно в файле thinstation.conf.sample.

Основную массу имеющихся в файле thinstation.conf.buildtime параметров можно оставить без изменений. Изменим и добавим лишь те параметры которые относятся к специфике нашей задачи:

NET_FILE_ENABLED=On
NET_FILE_METHOD=wget
...
SESSION_0_TYPE=freerdp
SESSION_0_TITLE="RDP"
SESSION_0_AUTOSTART=on
...
NET_USE=LAN
NET_USE_DHCP=ON
NET_DHCP_DELAY=30
NET_DHCP_TIMEOUT=30
NET_LINKWAIT=30
...

Добавленными параметрами NET_FILE_* мы укажем на необходимость загрузки конфигурационных файлов Thinstation по сети по протоколу HTTP. Это позволит нам разместить на веб-сервере конфигурационные файлы thinstation.conf-<MAC>, настраивающие конкретных тонких клиентов, не меняя при этом настройки внутри раздаваемого образа. Далее мы рассмотрим пример такого файла.

В параметрах SESSION_0_* вместо используемого по умолчанию графического оконного менеджера xfwm4 мы сразу будем вызывать RDP-клиента freerdp. А общие для всех наших  клиентов параметры подключения RDP-клиента к RDS-серверу (имя сервера, опции RDP-сессии) мы также вынесем в дальнейшем на веб-сервер в файл thinstation.conf.network. Его пример мы также рассмотрим далее.

В перечисленных параметрах NET_* мы зададим те опции тонкого клиента, которые могут повлиять на корректность инициализации сети в загружаемой системе и успешность загрузки по сети, как таковую. Например первая опция NET_USE=LAN задаёт приоритет использования проводных сетевых адаптеров перед беспроводными (может быть полезно, если тонкий клиент имеет и беспроводной и проводной адаптеры и один мешает загрузке другого). Опции задержки и таймаутов нужны для ожидания инициализации драйвера сетевого адаптера. На практике столкнулся с тем, что неуспевающий пройти инициализацию сетевой адаптер ломал загрузку по сети через HTTP.

***

Так как по условиям нашей задачи требуется авто-вход в RDP-сессию, удалим пару файлов, которые предотвращают авто-вход для freerdp

# rm /thinstation/build/packages/freerdp/etc/cmd/freerdp.getuser
# rm /thinstation/build/packages/freerdp/etc/cmd/freerdp.getpass

Это позволит нам передавать учётные данные для подключения к RDS-серверу клиенту freerdp в виде параметров. Эти параметры мы будем хранить в файлах thinstation.conf-<MAC>, которые тонкие клиенты будут получать с веб-сервера в процессе загрузки. В целом, с точки зрения безопасности, такое решение может быть неверным, однако учитывая условия нашей задачи (изоляцию сегмента сети тонких клиентов и одинаковый ограниченный набор возможностей конечных пользователей работающих на всех тонких клиентах) такая конфигурация вполне имеет право на жизнь.

***

Теперь на DevStation всё готово для сборки рабочего образа. Запускаем сборку из chroot-окружения:

# ./build

Так, как в конфигурационном файле build.conf мы включили поддержку fastboot, то при сборке вместо одного «тяжёлого» файла initrd мы получим «легковесный» initrd и дополнительный squash-файл, который и будет в себе содержать бОльшую долю загружаемых данных.  

Таким образом, подразумевается что первая часть (файл initrd) будет загружаться на PXE-клиенте по протоколу TFTP (с сервера WDS), а вторая часть (файл lib.squash) по протоколу HTTP (с веб-сервера IIS).

Получившиеся в процессе компиляции файлы initrd и vmlinuz мы скопируем на WDS сервер в ранее созданный нами каталог D:RemoteInstallImagesLinux (перезаписав возможно ранее размещённые там файлы от служебного образа Thinstation), а о файле lib.squash мы поговорим чуть позже, после настройки веб-сервера IIS.

Настройка веб-сервера IIS для поддержки Fast Boot

Так как на этапе сборки рабочего образа Thinstation мы включили опцию поддержки fastboot в build.conf, а в thinstation.conf.buildtime указали расположение веб-сервера Fast Boot, то теперь нам нужно разместить получившийся ранее Squash-файл на этом веб-сервере, чтобы в процессе загрузки основной «тяжёлой» части образа использовался не протокол TFTP а протокол HTTP. Это позволит ускорить время загрузки ОС тонкого клиента.

В нашем случае в качестве веб-сервера выступает IIS, который мы уже развернули ранее вместе с WDS, поэтому выполним его настройку, например через IIS Manager. Нам нужно сделать две вещи. Включить поддержку нового MIME-типа .squash и убедиться в том, что к сайту разрешён анонимный доступ.

В оснастке IIS Manager выберем сайт, в нашем случае это Default Web Site.

В настройках сайта выберем пункт MIME Types и используя в меню Actions ссылку Add добавим новый MIME-тип: filename extension = .squash , MIME type = application/octet-stream

Если не выполнить данную настройку, то наш веб-сервер IIS приходящим к нему PXE-клиентам попросту не будет отдавать squash-файл, а будет возвращать ошибку доступа.

Перейдём к разделу настроек сайта Authentication и убедимся в том, что включена анонимная аутентификация

Опять же, это нужно для того, чтобы приходящие PXE-клиенты без проблем могли скачать нужные им файлы.

***

Скопируем с DevStation появившийся после компиляции файл /thinstation/build/boot-images/pxe/boot/lib.squash в подкаталог ThinClients каталога, в котором размещена корневая папка сайта IIS (по умолчанию C:Inetpubwwwroot). Вспомним, что именно этот подкаталог веб-сервера мы указывали в параметре basepath в файле build.conf перед компиляцией рабочего образа Thinstation.

Использование разных сборок и конфигураций Thinstation

Есть разные походы к тому, каким образом можно настроить разный порядок загрузки «разношёрстных» тонких клиентов и выбор того или иного подхода зачастую зависит от исходных условий среды реализации. Исключительно оптимальных подходов, на мой взгляд здесь не существует, так как каждое решение имеет свои преимущества и недостатки. По имеющимся исходным условиям я выбрал вариант с выдачей PXE-клиентам загрузочных образов Thinstation (и конфигурационных файлов) в зависимости от их конкретных MAC-адресов. Поговорим о том, как реализовать подобную схему.

Мы помним, что для размещения файлов образа Thinstation initrd и vmlinuz на WDS мы использовали каталог D:RemoteInstallImagesLinux. В процессе загрузки PXE клиенты сначала скачивают файл D:RemoteInstallBootpxelinux.cfgdefault (на него ведут сим.линки из D:RemoteInstallBootx64pxelinux.cfg и D:RemoteInstallBootx86pxelinux.cfg), в котором указан путь к файлам initrd и vmlinuz. Этот файл мы создавали ранее на этапе настройки WDS.

Мы можем заставить отдельно-взятого тонкого клиента Thinstation вместо настроек, указанных в файле default использовать какие-то другие настройки порядка загрузки, например указав путь к другим файлам initrd и vmlinuz. Для этого в каталоге PXE-сервера D:RemoteInstallBootpxelinux.cfg можно создать файл, с содержанием аналогичным файлу default, но с именем в формате 01-<MAC>. Например, для клиента с MAC-адресом 00-15-5d-00-40-36 файл должен иметь имя 01-00-15-5d-00-40-36.

Содержимое файла может иметь следующие настройки:

DEFAULT RDP
PROMPT 0
NOESCAPE 1
ALLOWOPTIONS 0
LABEL RDP
MENU DEFAULT
KERNEL /Linux/HP-t610/vmlinuz
APPEND initrd=/Linux/HP-t610/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

Как видно, в качестве пути к файлам initrd и vmlinuz, которые загружаются с нашего PXE-сервера по протоколу TFTP, здесь уже указаны пути отличные от тех, что могут быть указаны в файле D:RemoteInstallBootpxelinux.cfgdefault. То есть в каталоге, из которого PXE-сервер отдаёт клиентам загрузочные образы мы создали подкаталог /Linux/HP-t610/ (физический путь D:RemoteInstallImagesLinuxHP-t610) с файлами определённой сборки образа нашего клиента Thinstation.

Также можно обратить внимание на то, что строку инициализации initrd здесь мы дополняем параметром FASTBOOT_URL, который ссылается на веб-сервер, где у нас расположен squash-файл ассоциированный с initrd-файлом. Нетрудно догадаться, что на веб-сервере в каталоге /ThinClients/ у нас также создан подкаталог под конкретную сборку образа — /ThinClients/HP-t610/. 

Таким образом мы организовали возможность раздачи файлов загружаемого образа Thinstation в зависимости от MAC-адреса PXE-клиента.

***

Теперь вспомним, что по условиям нашей задачи требуется, чтобы каждый загруженный экземпляр Thinstation автоматически создавал RDP-сессию на RDS-сервере, где автоматически должно запускаться определённое бизнес-приложение. А подключение к RDS-серверу подразумевает передачу каких-то учётных данных, используемых на этом сервере. При этом, как мы понимаем, каждый тонкий клиент должен передавать уникальные учётные данные, чтобы иметь выделенную RDP-сессию на сервере. Получается, что у нас добавляется необходимость дополнительной уникальной для каждого клиента настройки ПО freerdp, запускаемого в среде Thinstation.

Реализовать это можно с помощью дополнительно загружаемых с веб-сервера файлов вида thinstation.conf.network и thinstation.conf-<MAC>. И не забываем про то, что в процессе сборки рабочего образа Thinstation мы настаивали файл thinstation.conf.buildtime, который попал в этот образ. Thinstation обрабатывает все эти thinstation.conf* файлы в следующем порядке (процитирую источник):

Первым применяется thinstation.conf.buildtime при начальной загрузке образа, затем происходит получение файла thinstation.conf.network, и далее индивидуальные файлы конфигурации.

Если значение переменной SESSION_0_TYPE=rdesktop в файле thinstation.conf.network, а в thinstation.conf-ИМЯ_КОМЬЮТЕРА уже SESSION_0_TYPE=freerdp, то в результате загрузится freerdp.

Получить общую информацию о том, какими вообще методами могут загружаться конфигурационные файлы Thinstation можно из документа Thinstation Wiki – Configuration. Как я уже сказал, мы будем использовать загрузку дополнительных конфигурационных файлов тонких Thinstation по протоколу HTP с веб-сервера IIS. Поэтому сначала создадим на нашем веб-сервере файл групповых настроек, затем файл персональных настроек тонкого клиента.

***

На веб-сервере (вспомним параметр baseurl из build.conf) в каталоге, где уже размещаются squash-файлы (вспомним параметр basepath из build.conf) создадим общий для всех клиентов конфигурационный файл thinstation.conf.network:

SESSION_0_AUTOSTART=ON
SESSION_0_TYPE=freerdp
SESSION_0_TITLE="RDP"
SESSION_0_FREERDP_SERVER="10.1.4.10"
RECONNECT_PROMPT=FORCE
NET_TIME_SERVER="10.1.4.10"
TIME_ZONE="Europe/Moscow"
CRON_JOB1="30 18 * * * /sbin/poweroff"

Этот файл будет содержать общие для всех клиентов параметры работы ОС Thinstation (запуск оболочки в опциях SESSION_0_*) и адрес RDS-сервера (SESSION_0_FREERDP_SERVER). Опция RECONNECT_PROMPT=FORCE, позволит автоматически выполнять переподключение к RDS-серверу в случае попыток завершения сессии и/или проблем с временной недоступностью сервера. Присутствующие здесь опции, связанные со временем и планировщиков задач рассмотрим далее. 

***

Теперь в этом же каталоге веб-сервера создадим файл индивидуальных настроек тонкого клиента с именем формата thinstation.conf-<MAC>. В нашем примере файл получится с именем thinstation.conf-00155D004036. В этом файле будут указаны опции подключения freerdp, касающиеся только этого конкретного тонкого клиента:

SESSION_0_FREERDP_OPTIONS="/u:'thinusr-00155d004036' /p:'rdpClPwd00155d004036' /bpp:32 /cert-ignore /sec:nla +fonts +aero"

Разумеется на RDS-сервере мы параллельно должны создать соответствующую учётную запись пользователя с указанным именем и паролем. Эта учётная запись будет ассоциироваться с данным тонким клиентом.

Кстати, информацию о допустимых опциях freerdp можно найти в документе: FreeRDP Wiki – CommandLineInterface.

В конечном итоге на веб-сервере мы получим примерно следующую картину:

***

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

Образ Thinstation должен быть собран со следующими параметрами:

• В файле thinstation.conf.buildtime должны присутствовать директивы NET_FILE_ENABLED=On
  и NET_FILE_METHOD=wget
• В файле build.conf должен быть указан пусть каталоге на веб-сервере, где искать файлы конфигурации в параметрах baseurl и basepath

Кроме этого, не стоит забывать про ограничения MIME-типов которые накладывает IIS. То есть нужно решить вопрос возможности загрузки файлов с именами формата thinstation.conf*

Для этого ранее описанным способом на веб-сервере IIS добавим MIME-типы .network и .conf-<MAC-клиента> (для всех допустимых MAC-адресов) с типом text/plain:

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

• http://10.1.4.10/ThinClients/thinstation.conf.network
• http://10.1.4.10/ThinClients/thinstation.conf-00155D004036

Если заниматься настройкой MIME-типов в IIS под каждый MAC-адрес не очень хочется, то можно разрешить загрузку файлов с любым расширением для определённого каталога веб-сервера. Для того, чтобы это сделать воспользуемся рекомендацией из статьи KB326965 — IIS 6.0 does not serve unknown MIME types и добавим для соответствующего каталога IIS универсальную запись: * = application/octet-stream 

***

Теперь можно считать, что наш веб-сервер готов к раздаче PXE-клиентам разных сборок и конфигураций Thinstation.

Тестируем запуск тонкого клиента

Перед тем, как выполнять проверочный запуск тонкого клиента, ещё раз вспомним о том, какие файлы мы имеем для его автоматической загрузки и настройки, и где эти файлы расположены на нашем Windows-сервере управления:

• После компиляции рабочего образа Thinstation мы имеем три файла, которые распределены на сервере следующим образом:
• D:RemoteInstallImagesLinuxHP-t610vmlinuz
• D:RemoteInstallImagesLinuxHP-t610initrd
• C:inetpubwwwrootThinClientsHP-t610lib.squash
• Файл настроек загрузки PXE-клиента:
• D:RemoteInstallBootpxelinux.cfg1-00-15-5d-00-40-36
• Конфигурационные файлы Thinstation:
• C:inetpubwwwrootThinClientsthinstation.conf.network
• C:inetpubwwwrootThinClientsthinstation.conf-00155D004036

При запуске клиент с PXE-сервера получит по TFTP файлы vmlinuz и initrd, указанные в pxelinux.cfg1-00-15-5d-00-40-36 и загрузит их в память тонкого клиента… 

…на следующем этапе (опять же согласно настроек pxelinux.cfg1-00-15-5d-00-40-36) с веб-сервера будет загружен файл lib.squash и произведено применение конфигурационных файлов thinstation.conf.network и thinstation.conf-00155D004036

На последней стадии загрузки, согласно условий нашей задачи, будет запущен RDP-клиент freerdp с автоматическим подключением к серверу RDS.

Если что-то «пошло не так», перепроверим все конфигурационные файлы и заглянем в раздел Поиск решений проблем (далее).

Загрузка с USB накопителя

В некоторых случаях может получиться так, что загрузка образа тонкого клиента по сети не самый лучший вариант, например, из-за слабеньких и неустойчивых каналов передачи данных между конечным тонким клиентом и PXE-сервером. В таком случае, в качестве исключения, можно воспользоваться загрузкой Thinstation с локального USB-накопителя, подключённого в порт тонкого клиента.

При каждой процедуре компиляции рабочего образа Thinstation, которую мы рассматривали ранее, помимо уже знакомых нам файлов initrd/vmlinuz/lib.squash, генерируется файл загрузочного ISO-образа:

/build/boot-images/iso/thinstation.iso

Однако, как я понял, если образ Thinstation был скомпилирован с параметром fastboot в build.conf, то он для локальной загрузки не подойдёт. Поэтому, для того, чтобы получить отдельно загружаемый (без проблем) с локального накопителя образ, нам потребуется скомпилировать его с выключенной опцией fastboot.

В некоторых источниках можно встретить рекомендации по специальной настройке thinstation.conf.buildtime в процессе подготовки к компиляции локально загружаемого образа. Однако я таких настроек не выполнял, и у меня загрузка тонкого клиента с локального USB-накопителя успешно прошла из образа по сути аналогичного, тому что я собирал для сетевой загрузки с единственным упомянутым исключением — выключенным fastboot.

Структура расположения файлов внутри получающегося при компиляции ISO-образа такова:

g:>tree /f

Структура папок тома THINSTATION
Серийный номер тома: 65F3-6981
G:.
│   syslinux.cfg
│
└───boot
    │   image.md5
    │   initrd
    │   vmlinuz
    │
    └───syslinux
            boot.cat
            isolinux.bin
            isolinux.cfg
            ldlinux.c32
            product.txt<pre>

То есть, мы видим, что нужные для загрузки системы файлы vmlinuz и initrd имеются в каталоге boot (lib.squash при этом не используется, так как образ собирался с выключенным fastboot). При этом конфигурационные файлы thinstation.conf.network и thinstation.conf-00155D004036, как и при сетевой загрузке с веб-сервера, что по прежнему нам даёт преимущества управления некоторыми параметрами конфигурации клиентов в централизованном месте.

Для записи загрузочного ISO-образа на USB-накопитель можно использовать, например, свободно распространяемую утилиту Rufus:

Работа тонких клиентов по расписанию

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

• Синхронизация времени на тонких клиентах
• Включение клиентов по расписанию
• Выключение клиентов по расписанию

***

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

Учитывая изолированность наших тонких клиентов, единственным источником, с которым они могут синхронизировать время, является наш выделенный Windows-сервер. Давайте настроим службу времени на этом сервере.

Так как наш Windows-сервер является виртуальной машиной Hyper-V, то в первую очередь в свойствах этой виртуальной машины отключим функцию синхронизацию времени с хостом:

Для настройки службы времени «Windows Time» (w32time) будем использовать входящую в состав Windows Server утилиту w32tm, которая будет управлять значениями ключа реестра HKLMSystemCurrentControlSetServicesW32Time

Конфигурируем службу времени на синхронизацию с внешним NTP-сервером командой:

net stop w32time
w32tm /config /manualpeerlist:"10.10.0.2 10.11.0.3" /syncfromflags:MANUAL
net start w32time

Проверяем статус синхронизации командой:

w32tm /query /status

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer]
"Enabled"=dword:00000001

После правки реестра отправляем службе NTP информацию об обновлении конфигурации (последняя команда покажет текущий статус конфигурации):

w32tm /config /update
w32tm /query /configuration

Учитывая то обстоятельство, что в в нашем случае Windows-сервер не является членом домена, у нас может возникнуть проблема с автоматическим запуском службы времени в процессе загрузки системы. Проблема эта известна давно и описана в статье KB2385818 — Windows Time service doesn’t start automatically on a workgroup computer that’s running Windows 7 or Windows Server 2008 R2. Суть проблемы в том, что служба времени имеет триггер, который выполняет запуск службы только в том случае если система является членом домена. Проверить это можно командой:

sc qtriggerinfo w32time

Для решения проблемы воспользуемся рекомендациями из вышеуказанной статьи и выберем один из предложенных методов – подмена триггера. Заменим для службы времени триггер проверки членства в домене на триггер проверки наличия сетевого подключения:

sc triggerinfo w32time start/networkon stop/networkoff

После перезапустим сервер и убедимся в том, что служба запускается автоматически без проблем.

Убедимся в том, что в системе висит UDP-прослушиватель на 123 порту:

C:>netstat -na | findstr 123

  UDP    0.0.0.0:123            *:*
  UDP    [::]:123               *:*

Создадим правило в Windows Firewall, разрешающее входящие подключения на порт NTP-сервера:

New-NetFirewallRule -DisplayName "NTP Server (UDP-In)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "123"

***

Теперь посмотрим на протокол NTP с точки зрения нашего тонкого клиента. Первое, о чём стоит заметить, это то, что для поддержки возможности синхронизации времени, образ Thinstation должен быть собран с включённым пакетом package ntp в build.conf (в приведённом ранее примере build.conf этот пакет включен).

Информацию о NTP-сервере, как источнике синхронизации времени можно указать в любом из thinstation.conf* файлов. Мне показалось более удобным указать эти опции в файле thinstation.conf.network, который лежит на веб-сервере и централизовано раздаётся всем тонким клиентам. Как минимум можно указать параметры (в приведённом ранее примере thinstation.conf.network эти параметры имеются):

NET_TIME_SERVER="10.1.4.10"
TIME_ZONE="Europe/Moscow"

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

ts_00155D004036:~# ntpdate 10.1.4.10
 9 Feb 16:52:23 ntpdate[4762]: step time server 10.1.4.10 offset 1.681994 sec

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

***

Теперь поговорим об автоматизации выключения тонких клиентов по расписанию. Thinstation, как Linux-система, имеет на борту работающий планировщик cron. Конфигурационные файлы thinstation.conf* позволяют нам добавлять до 9 заданий в этот планировщик с помощью параметров CRON_JOB[1-9]. Пример добавления задачи на отключение тонкого клиента по расписанию — каждый день в 19:30:

CRON_JOB1 = "30 19 * * * /sbin/poweroff"

Опять же отмечу, что в приведённом ранее примере thinstation.conf.network эта задача cron была упомянута. В случае необходимости мы можем разным тонким клиентам аналогичным образом задавать уникальные параметры отключения, например, через файлы thinstation.conf-<MAC>.

Добавленное через конфигурационные файлы Thinstation задание cron в загруженном клиенте попадёт в файл /tmp/crontab

Кстати, здесь же можем увидеть и задания синхронизации времени (первое и второе задание). 

***

Задача автоматизации включения тонких клиентов по расписанию, как и прочие задачи, может иметь разные варианты реализации. Учитывая то, что в нашем случае все клиенты находятся в рамках одного физического сегмента сети, мы можем использовать функционал пробуждения клиентов по сети (Wake On Lan) по MAC-адресам.

Для этой цели я воспользовался ещё одной бесплатной утилитой командной строки для Windows: Wake On Lan Command Line

Синтаксис использования утилиты прост:

wolcmd [MAC-адрес] 255.255.255.255 255.255.255.255 7

То есть с помощью этой утилиты мы посылаем в сеть широковещательный запрос с указанием MAC-адреса интересующего нас клиента.

При этом замечено, что клиент будет реагировать на WoL-запрос, только в том случае, если в прошлый раз система была выключена штатно. Если же выключение произведено жёстко (например нажата кнопка питания с удержанием), то для последующего успешного запуска потребуется обесточить клиента (извлечь/вставить шнур питания).

В общем всё, что здесь остаётся сделать, это создать на нашем Windows-сервере управления командный файл с вызовом wolcmd и добавить его в планировщик заданий Windows на выполнение в нужное время, например, в 07:50 утра каждого рабочего дня недели. 

Поиск решений проблем

Если в процессе загрузки по сети возникают проблемы, например, когда останавливается и «замерзает» индикатор загрузки на сплэш-заставке, то может потребоваться получить доступ к расширенной информации о ходе загрузки. Для этого нужно изменить параметры вызова initrd в конфигурационном файле PXE-сервера. Например так выглядит ранее приведённый пример вызова initrd в штатной ситуации:

...
APPEND initrd=/Linux/HP-t610/initrd splash=silent,theme:default load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=3 console=tty1 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

Чтобы отключить отображение сплэш-заставки, уберём параметр splash=silent,theme:default. Чтобы перенаправить вывод процесса загрузки на основную консоль, заменим console=tty1 на tty0. Дополнительно можно увеличить уровень логирования, например loglevel=32. В тоге получится примерно так: 

...
APPEND initrd=/Linux/HP-t610/initrd load_ramdisk=1 ramdisk_blocksize=4096 root=/dev/ram0 ramdisk_size=786432 loglevel=32 console=tty0 vt.global_cursor_default=0 LM=3 FASTBOOT_URL=http://10.1.4.10/ThinClients/HP-t610/

<

p align=»center»>***

Я на практике столкнулся с тем, что в загружаемой системе Thinstation сеть не успевает пройти полную инициализацию до того момента, как система пытается получить по HTTP squash-файл или файлы конфигурации. В итоге возникают ошибки типа «No lease, forking to background«, «Network is unreachable»  и т.п.

В таких случаях на этапе сборки образа можно покрутить параметры в thinstation.conf.buildtime, связанные с сетью (NET_*). А получить по ним информацию можно из файла thinstation.conf.sample. Например можно для начала задать увеличенные значения интервалов ожидания и таймаутов, как было показано на выше.

NET_DHCP_DELAY=60
NET_DHCP_TIMEOUT=60
NET_LINKWAIT=60

Можно попробовать использовать эти параметры как по отдельности так и комбинировать их вместе.

***

Если сразу строить описанный стенд от начала и до конца, то допустив где-нибудь по пути ошибку, можно потратить немало времени на излишний «разбор полётов». Поэтому лучше действовать поступательно, то есть, например, сначала добиться загрузки по сети без использования fastboot, а потом уже, если всё работает как следует, переходить к усложнению конфигурации. Дополнительно в поиске решений проблем может оказаться полезной статья Thinstation Wiki — Debugging 

Дополнительные источники информации:

• Thinstation / maintained by Donald A. Cupp Jr.
• Thinstation Wiki
• Peter Hinchley — Use Thinstation to Build a Network-Bootable RDP-Enabled Thin Client Image
• Блог QUADED — Сборка Thinstation образа
• ITSave — Thinstation 5.x
• Thinstation по русски
• Thinstation Доработка тонкого клиента
• PXE загрузка Thinstation в зависимости от железа тонкого клиента
• Загрузка PXE для разных платформ тонких клиентов