Основные понятия среды терминального сервера

Опубликовано: 24 Апреля, 2023


Введение


Что обычно заставляет администраторов полагать, что среды терминального сервера настолько сложны и трудны в управлении? В основном эти соображения основаны на историях, в которых среда терминального сервера нестабильна из-за того, что реализованы приложения и принтеры, не подходящие для среды терминального сервера. Это может привести к сбою приложений, службы очереди печати или даже печально известному синему экрану смерти (BSOD).


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


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


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


Почему серверы должны быть на 100% идентичными? Если я куплю новый сервер, почти невозможно купить точно такой же сервер. Когда мы говорим о том, что серверы должны быть одинаковыми, мы говорим не об оборудовании, а об установке и настройке всех программных компонентов на этих серверах.


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


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


Если вы используете Citrix Presentation Server (или другой продукт SBC), эту часть также следует установить в автоматическом режиме. Я буду обсуждать автоматическую установку Citrix в другой статье на этом веб-сайте позже.


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


Хронология установки приложения


Для этой статьи важен только один момент, касающийся приложений (управления), который необходимо описать, чтобы понять следующее правило.


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


Поэтому, если вы устанавливаете новое приложение на существующий сервер терминалов, более чем вероятно, что эта установка перезапишет некоторые файлы, которые также используются одним (или несколькими) существующими приложениями. Это может привести к тому, что некоторые существующие приложения больше не будут работать или будут некоторые изменения в поведении. Давайте сосредоточимся на этих изменениях поведения. Если мы устанавливаем приложения в разном порядке на нескольких машинах, поведение приложений может быть (и часто бывает) разным. Это объясняет, почему многие проблемы не воспроизводимы. Они существуют только на одной машине, потому что порядок установки вызывает другое поведение. Чтобы предотвратить это различное поведение, все приложения должны быть установлены в точно таком же порядке установки на всех машинах. Этот порядок установки следует протестировать, чтобы вы могли убедиться, что приложения работают правильно, и гарантировать, что все приложения работают одинаково на всех серверах. В терминах SBC это называется «хронологией установки приложения». Как упоминалось ранее, лучший способ добиться этого — использовать пакеты автоматической установки для этих приложений.


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


Разделение установки и настройки


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


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


Разделение пользователя и машины


Еще более важным является разделение пользователя и машинной части. Каждое приложение состоит из машинной части и пользовательской части. Машинная часть обычно устанавливается на один из локальных дисков в настройках сервера и реестра в ключах HKEY_LOCAL_MACHINE и/или Classes Root. К машинной части применяются следующие свойства: данные статичны, ошибки имеют большое влияние, 20% всех изменений применимы к машинной части, резервное копирование не требуется. Машинной частью можно управлять с помощью машинных политик, автоматической установки и сценариев конфигурации (например, сценария запуска и завершения работы).


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


Теневой ключ


Если приложения установлены на терминале, это обычно делается с помощью «Установка/удаление программ» или с помощью команды смены пользователя /install. Это переводит сервер терминалов в режим установки. Когда приложение в этом режиме установки записывает ключи реестра в HKEY_CURRENT_USER, Microsoft также записывает этот ключ в HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware. Значения этого ключа, называемого теневым ключом, применяются к пользователю, когда он входит в систему на сервере терминалов, если в его профиле не найдены ключи (или более старые ключи) на основе метки времени. Поскольку метка времени проверяется, вы можете столкнуться со странным поведением, если в вашу инфраструктуру будет добавлен новый сервер. Это происходит из-за того, что значения в разделе Shadow имеют отметку времени, когда они были установлены. Пользователи могут иметь другие настройки в своем профиле, но с более старой отметкой времени. Когда эти пользователи входят на новый сервер, настройки теневого ключа записываются в их профиль, поскольку дата новее, чем настройка в профиле пользователя, что логически нежелательно. Корпорация Майкрософт признает такое поведение в статье 297379 базы знаний. В этой статье предлагаются три решения.



  1. Используйте Sysprep и создайте образ новых серверов. Это гарантирует, что новые серверы наследуют метки времени реестра от исходной сборки.
  2. Запись в HKEY_CURRENT_USERSoftware в режиме установки с системными часами, установленными в прошлом.
  3. Удалите теневые ключи, которые потенциально могут перезаписать пользовательские настройки.

Первое решение нежелательно, потому что изменениями в вашей среде трудно управлять/упорядочивать, когда приложения доступны в образе. Решение два и три работают отлично. При использовании второго решения ваши автоматические сценарии должны иметь некоторую логику для изменения метки даты новых значений, созданных приложением в теневом ключе. Предпочтительно удалить все ключи в теневом ключе при использовании третьего решения. Эти значения следует отслеживать во время упаковки приложения, а затем добавлять в сценарии входа пользователя (или что-то подобное). Мое личное мнение, что решение номер три — лучшее решение, потому что вы можете управлять значениями самым простым и лучшим способом.


Используйте среду DTAP


DTAP расшифровывается как «Разработка, тестирование, принятие и производство». Поскольку наша главная цель — гарантировать, что все серверы будут на 100% идентичны при каждой новой настройке, установленное приложение должно быть тщательно протестировано. Для этого необходимо несколько сред. Иногда среды разработки и тестирования могут быть объединены для терминальных серверов. В зависимости от вашей полной инфраструктуры некоторые серверные инфраструктуры (такие как файлы, обмен и некоторые функции базы данных) также могут быть объединены, но постарайтесь разделить эти функции как минимум на две части. Один для разработки/тестирования и один для принятия/производства.


Профили и драйверы принтеров


Последние два правила для основ сервера терминалов заключаются в ограничении использования профилей и драйверов принтеров. На MSTerminalServices.org уже опубликовано несколько статей по этим двум темам: «Сервер терминалов и проблема с профилем» и «Может ли стороннее программное обеспечение решить ваши проблемы с печатью на сервере терминалов?» поэтому нет необходимости вдаваться в подробности об этих двух в этой статье.


Вывод


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