Глава 5. Установка приложений и совместимость


Мы рассмотрели, как разрешить роль Terminal Services, создавать и управлять фермой Session Directory, как интегрировать терминальные серверы в среду AD. Все эти факторы жизненно важны для успешной инфраструктуры Terminal Services, но именно пользовательские приложения определяют успех или неуспех развертывания вашего терминального сервера.

После установки Terminal Services вам также необходимо установить пользовательские приложения. Сегодня большинство приложений можно установить на терминальный сервер и они будут работать в многопользовательской среде без модификации. Однако, всегда найдутся важные программы, которые либо старые, либо не следуют спецификациям Microsoft Windows Logo, поэтому важно ознакомиться с особенностями Windows Server 2003, связанных с совместимостью приложений.

В этой главе описывается установка, развертывание и управление приложениями в среде Terminal Services. Вы узнаете, как настроить приложения для параллельной работы пользователей, писать скрипты совместимости и использовать флаги реестра для управления старыми приложениями.

Механизмы совместимости приложений

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

Если приложение имеет логотип Designed for Microsoft Windows XP, оно обычно совместимо с Terminal Services. Программа сертификации Microsoft гарантирует, что приложение в процессе своей инсталляции и в хранении и обработки своих данных и настроек следует определенным правилам и совместимо с особенностями WS2K3. Подробнее о программе сертификации см. http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx.

Скрипты входа

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

При инсталляции Terminal Services, система добавляет вход в ключ реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Appsetup, который запускает скрипт USRLOGON.CMD, находящийся в каталоге System32 . USRLOGON.CMD - это сердце процесса входа Terminal Services, внутри него вызываются дополнительные скрипты.

Все скрипты, предоставляемые Microsoft, написаны на языке комадного интрпретатора, но WS2K3 также может использовать VBScript и JavaScript с помощью Windows Script Host (WSH).

USRLOGON.CMD

Первая часть USRLOGON.CMD вызывает скрипт SETPATHS.CMD

REM USRLOGON.CMD
@Echo Off
Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"
If "%_SETPATHS%" == "FAIL" Goto Done

Скрипт SETPATHS.CMD проверяет, что ключи реестра для пользовательского окружения находятся на месте. Ключи реестра для текущего пользователя находятся в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders, а ключи для всех пользовательских переменных находятся в таком же подключе в HKEY_LOCAL_MACHINE. Если ни одна из этих переменных не определена, появляется предупреждающее сообщение и выполнение USRLOGON.CMD прекращается. В следующей таблице показаны переменные окружения:

Компонент среды

Значение реестра

All Users: Startup

COMMON_STARTUP

All Users: Start Menu

COMMON_START_MENU

All Users: Start Menu\Programs

COMMON_PROGRAMS

Current User: Start Menu

USER_START_MENU

Current User: Startup

USER_STARTUP

Current User: Start Menu\Programs

USER_PROGRAMS

Current User: My Documents

MY_DOCUMENTS

Current User: Templates

TEMPLATES

Current User: Application Data

APP_DATA

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

If Not Exist "%SystemRoot%\System32\Usrlogn1.cmd" Goto cont0
Cd /d "%SystemRoot%\Application Compatibility Scripts\Logon"
Call "%SystemRoot%\System32\Usrlogn1.cmd"
:cont0

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

Следующий раздел скрипта создает ROOTDRIVE. Концепция ROOTDRIVE создана потому, что большинство ключей реестра не могут ссылаться на переменные окружения. Например, MyApplication.EXE может иметь в реестре значение UserTemplates, которое определяет путь для хранения модифицируемых пользователем шаблонов. Лучшей опцией для такого маршрута было бы указание %HOMEDRIVE%%HOMEPATH%\MyTemplates, чтобы каждый пользователь мог быть направлен на свой сетевой домашний каталог (если он есть) или в профиль на терминальном сервере. Поскольку вы не можете использовать переменные окружения в значениях реестра, вам необходимо указать абсолютный маршрут, который можно было бы разрешить для всех пользователей. Поэтому на терминальном сервере вы определяете ROOTDRIVE.

USRLOGON.CMD использует команду SUBST для подключения буквы ROOTDRIVE к пользовательскому каталогу во время входа.

Cd /d %SystemRoot%\"Application Compatibility Scripts"
Call RootDrv.Cmd
If "A%RootDrive%A" == "AA" End.Cmd

Rem
Rem Отобразить домашний каталог пользователя на букву драйва
Rem

Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst

:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"

:AfterSubst

Команда SUBST используется в Windows для назначения буквы драйва абсолютному маршруту - в отличие от NET USE, которая назначает букву драйва для пути в формате UNC. Так, SUBST W: C:\WINNT\FONTS сделает драйв W: ссылкой на каталог шрифтов.

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

Пример 1

Пользователь Joe User имеет домашний каталог, определенный в его учетной записи \\Server01\Home\Joe.User. При входе на терминальный сервер, буква H отображается на \\Server01\Home. В сеансе Джо, переменная %HOMEDRIVE% имеет значение H, а переменная %HOMEPATH% - значение \Joe.User.

Джо использует приложение, которое позволяет ему использовать персональные шаблоны для его документов, и есть ключ реестра, который определяет путь к этим шаблонам. Реестр не может ссылаться на переменные окружения, а только на аболютные маршруты, поэтому мы не можем использовать %HOMEDRIVE%%HOMEPATH%. Если мы попытаемся использовать H для UserTemplates, шаблоны Джо будут создаваться в корне домашней папки, а не в его каталоге.

Если администратор использовал ROOTDRV2.CMD для установки переменной ROOTDRIVE в W, то USRLOGON.CMD использует команду SUBST для отображения W на %HOMEDRIVE%%HOMESHARE% или H:\Joe.User. Теперь путь W:\ является ссылкой на H:\Joe.User, и значения реестра могут ссылаться на W:\, если им необходим доступ к домашнему каталогу Джо. Кроме того, этот путь может использоваться для размещения его файлов шаблонов.

Пример 2

У Jane Doe нет сетевого домашнего каталога, поэтому ее шаблоны должны храниться в ее профиле. В сеансе Джейн, переменная %HOMEDRIVE% указывает на C, а %HOMEPATH% указывает на \WTSRV\Profiles\Jane.Doe. Опять, мы не можем использовать переменные окружения в ключах реестра, поэтому у нас нет легкого способа сылаться на каталог профиля Джейн.

Администратор установил в скрипте ROOTDRIVE=W:, поэтому USRLOGON.CMD подключает W напрямую к каталогу профиля Jane, и мы можеи использовать в реестре W:\.

В примере с Джо пришлось использовать обходной путь, поскольку NT 4.0 не может отображать сетевой драйв на подкаталог папки общего доступа, поэтому

Net Use H: \\Server01\Share\Directory

подключит H к \\Server01\Share. Но WS2K3 может отображать подкаталог, что позволяет использовать домашний каталог в ROOTDRIVE.

Однако, без модификации USRLOGON.CMD всегда сбрасывает текущее значение ROOTDRIVE перед выполнением команды SUBST, поэтому он не получает преимущества от расширенных возможностей переназначения драйвов в WS2K3. Зачем нужны оба драйва, которые указывают на один и тот же каталог? Лучше изменить USRLOGON.CMD так, чтобы он использовал преимущества WS2K3.

Подробнее о ROOTDRIVE см. статью Microsoft “How and why ROOTDRIVE is used on Windows Terminal Server

Допустим, вы используете сетевые домашние каталоги и назначили их на драйв H. Если вы установили ROOTDRIVE тоже на H, то вы можете избежать назначения двух драйвов. Ниже показаны изменения, которые вы можете сделать в USRLOGON.CMD (изменения выделены красным)

Cd /d %SystemRoot%\"Application Compatibility Scripts"
Call RootDrv.Cmd
If "A%RootDrive%A" == "AA" goto done
REM If the user has a network Home Directory already mapped 
REM on the ROOTDRIVE, we do not need to do anything.
if /I "%rootdrive%" == "%homedrive%"        goto NoSubst
:DoSubst
Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst
:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
:AfterSubst 

:NoSubst

Если вы не инсталлируете приложения, требующие скриптов совместимости, то ROOTDRIVE никогда не будет создан, а процесс входа существенно упростится.

После установки ROOTDRIVE, скрипт USRLOGON.CMD вызывает любые установленные скрипты совместимости:

Rem Invoke each Application Script.  Application Scripts are automatically
Rem added to UsrLogn2.Cmd when the Installation script is run.
Rem

If Not Exist %SystemRoot%\System32\UsrLogn2.Cmd Goto Cont1
Cd Logon
Call %SystemRoot%\System32\UsrLogn2.Cmd
:Cont1
:Done

При установке скрипта совместимости, его вызов добавляется в USRLOGN2.CMD, чтобы все скрипты совместимости могли вызываться без модификации USRLOGON.CMD.

Дополнительные административные скрипты

Помимо USRLOGON.CMD и скриптов совместимости, вы можете запускать при входе пользователя дополнительные скрипты. Например, вы можете создать скрипт, котрый отображает дополнительные сетевые драйвы или подключает к принтерам. Если вы находитесь в среде AD, то можете добавить скрипты входа в объект групповой политики User Group Policy Object (GPO).

Если терминальный сервер находится в рабочей группе, вы можете заставить систему выполнить дополнительный скрипт, скопировав файл скрипта в каталог \System32 и изменив значение AppSetup в подключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. По умолчанию в этом ключе находится только USRLOGON.CMD, но вы можете добавить другие скрипты, отделив их друг от друга запятыми.

Подробнее о добавлении скриптов см. статью Microsoft “How to Set Up a Logon Script Only for Terminal Server Users

Вместо редактирования ключа реестра AppSetup, вы можете вызывать дополнительные скрипты из USRLOGON.CMD. Если вы не используете ROOTDRIVE, встаьте вызов после метки :Cont0. Если вы используете ROOTDRIVE, вставьте вызов в конец скрипта.

Инсталляция приложений

Теперь, когда вы поняли процесс создания среды на терминальном сервере, мы можем приступить к рассмотрению процесса инсталляции программ на терминальном сервере. В идеальном случае, все приложения должны следовать спецификациям "Designed for Microsoft Windows XP".

Эта спецификация требует от программистов использовать преимущества некоторых компонентов Windows, которые делают приложение совместимым с WS2K3 и Terminal Services. В следующем списке содержатся некоторые из них, которые представляют интерес для администраторов Terminal Services:

В реальном мире системным адмнистраторам приходиться иметь дело с множеством приложений - как современных, так и устаревших, которые не следуют этим правилам или которые написаны до того, как эти правила были установлены. Для облегчения интеграции таких приложений Terminal Services использует отображение реестра, отображение файлов INI и скрипты совместимости приложений.

Отображение реестра

Реестр Windows разделен на два основных раздела: HKEY_CURRENT_USER и HKEY_LOCAL_MACHINE. HKEY_LOCAL_MACHINE используется для хранения глобальной конфигурационной информации = такой, как сетевые настройки, аппаратная конфигурация, настройки программного обеспечения, одинаковые для всех пользователей. HKEY_CURRENT_USER хранит пользовательские настройки, например, косметические настройки, предпочтения пользователя, пользовательские настройки приложений. Каждый пользователь, зарегистрировавшийся в Windows, имеет свой собственный узел HKEY_CURRENT_USER.

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

Если приложение использует службу Windows Installer, приложение может использовать advertising для создания ключей HKEY_CURRENT_USER. Если такое приложение запускается из меню Start, то запускается служба Windows Installer и делает пользовательскую подстройку приложения. При этом создаются все необходимые ключи и специфические для пользователя файлы, необходимые для приложения.

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

Чтобы гарантировать, что все пользователи получат правильные значения реестра, Terminal Services использует процесс, называемый отображением реестра (registry mapping). При инсталляции приложения, терминальный сервер переводится в режим инсталляции. В этом режиме сервер наблюдает за всеми изменениями, вносимыми программой установки в HKEY_CURRENT_USER. Как показано на следующем рисунке, все ключи, которые записываются в HKEY_CURRENT_USER, автоматически копируются в особое место в HKEY_LOCAL_MACHINE - в подключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software

  .

Отображение реестра работает только в том случае, если программа для записи в реестр использует стандартные вызовы API. Всегда проверяйте реестр после установки приложения и до первого его запуска, чтобы убедиться, что зеркало создано. Если нет, вам следует вручную скопировать ключи.

По завершении установки приложения сервер переводится в режим исполнения. В этом режиме, если приложение пытается прочитать ключ реестра из HKEY_CURRENT_USER, а ключа там нет, система автоматически проверит, есть ли такой ключ в подключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Если он там найден, то система скопирует его в HKEY_CURRENT_USER.

Отображение файлов INI

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

Для компенсации такого поведения, Terminal Services создает копии системных файлов INI и сохраняет их в домашнем каталоге каждого пользователя. Если приложение пытается читать или записать в системный файл INI, Terminal Services переадресуют вызов на пользовательскую копию вместо оригинала.

В режиме инсталляции все изменения, которые программа установки делает в этих файлах INI, она делает в оригинальных копиях в каталоге %SYSTEMROOT%. При входе пользователя, система сверяет пользовательские копии системных файлов INI с теми, что находятся в каталоге WINNT, и если пользовательские файлы старее, система их обновляет. Вы можете запретить такую проверку, изменив значение реестра.

Режимы инсталляции и исполнения

Для работы переназначения реестра и файлов INI, система во время инсталляции приложения и во время его работы должна находиться в соотвествтующем режиме. Для переключения сервера в режим инсталляции просто запустите мастер Add New Programs в апплете панели управления Add/Remove Programs. Для переключения обратно в режим исполнения закройте мастер. Если вы попытаетесь запустить программу SETUP.EXE за пределами панели управления, терминальный сервер выдаст сообщение об ошибке:

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

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

CHANGE USER /INSTALL

CHANGE USER /EXECUTE

Эти команды полезны, если вы хотите заскриптовать процесс инсталляции приложения.

Скрипты совместимости приложений

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

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

Тот факт, что многие современные приложения следуют спецификации Windows Logo, заметен по уменьшению количества скриптов совместимости, включенных в Windows. Вы можете найти эти скрипты в C:\WINNT\Application Compatibility Scripts. Скрипты разбиты на три группы:

Как видно, Microsoft включает лишь скрипты для Eudora 4, Visual Studio 6 и Outlook 98. Если вы используете старые приложения (например, Office 97, Project 95 и т.п.), вы можете скопировать скрипты с терминального сервера Win2K.

При инсталляции приложения, требующего скрипта совместимости, вы запускаете инсталляционный скрипт после установки приложения. Этот инсталляционный скрипт делает все необходимые системные изменения и указывает USRLOGN2.CMD выполнить скрипт входа при регистрации пользователя.

Если вы устанавливаете приложение, не удовлетворяющее спецификациям Microsoft и не имеющее скрипта совместимости, см. раздел "Установка недокументированных приложений".

Примеры инсталляции приложений на терминальном сервере

Давайте рассморим процесс инсталляции трех разных приложений. Одно не имеет проблем с Terminal Services, другое требует специального метода установки для Terminal Services, а третье требует скрипта совместимости. Это "старые" приложения - Acrobat Reader 5, Netscape Navigator 4 и Office 2000 - но многие организации до сих пор их используют.

Простая инсталляция

Adobe Acrobat Reader - это бесплатная утилита для чтения файлов PDF. Она без проблем работает на терминальном сервере. Для ее установки просто используйте мастре Add New Programs в апплете Add/Remove Programs панели управления, как показано на рисунке. Мастер автоматически переводит сервер в режим инсталляции.

По заврешении инсталляции щелкните кнопку Finish. Сервер вернется в режим исполнения и Acrobat Reader готов для ваших терминальных пользователей. В качестве упражнения откройте редактор реестра и сравните значения в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Adobe с аналогичными в HKEY_CURRENT_USER\Software\Adobe, чтобы убедиться, что сработало отображение реестра. Когда пользователь первый раз запустит Acrobat, система скопирует ключи в пользовательский узел HKEY_CURRENT_USER.

Уже вышел Acrobat Reader 6. Эта версия упакована в MSI и также не требует особых шагов для установки на терминальном сервере.

Заказная инсталляция

Некоторые производители ПО учитывают Terminal Services при написании программ и предоставляют инструкции по установке их на терминальном сервере. В качестве примера рассмотрим процесс установки приложения, которое проектировалось с учетом Terminal Services - Microsoft Office 2000. Office 2000 в чистом виде имеет ряд проблем при работе на терминальном сервере.

Эти проблемы решаются применением трансформы для Office 2000 - файла TermSrvr.mst. Трансформа - это специальный файл, который предписывает Windows Installer настроить Office для Terminal Services и исключить пролематичные возможности Office 2000.

Трансформы для Terminal Services можно найти в Office Resource Kit, который вы можете загрузить по ссылке http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm#orktools. Есть также подробная статья об установке Office на терминальном сервере: http://www.microsoft.com/office/ork/2000/two/30t3_2.htm.

Раздобыв файл MST, вы готовы к установке Office 2000. Откройте в панели управления апплет Add/Remove Programs, выберите Add New Programs. Щелкните CD or Floppy, найлите файлы Office и выберите SETUP.EXE. Теперь вы должны указать инсталлятору использовать трансформу. Для этого добавьте к команде

TRANSFORMS=path\TermSrvr.mst

По завершении установки щелкните Finish для перевода Terminal Services обратно в режим исполнения. Я рекомендую устанавливать последний релиз Office, поскольку в них исправлены некоторые ошибки, затрагивающие пользователей Terminal Services.

Теперь следует добавить кое-какие настройки для ваших пользователей. Вы можете это сделать с помощью Office Profile Wizard или файлов ADM для Office 2000 совместно с редактором локальных или доменных групповых политик. Если вы хотите использовать Office Profile Wizard, следуйте документации, которую предлагает Microsoft. Если вы находитесь в домене AD или используете групповые политики для управления пользовательскими настройками, см. Главу 4. Для использования локальной политики, найдите файлы ADM, входящие в состав Resource Kit, затем запустите редактор политик:

GPEDIT.MSC

Щелкните правой кнопкой на Administrative Templates, выберите Add/Remove Templates. Добавьте файлы ADM для программ, которые вы инсталлировали. В следующей таблице перечислены файлы ADM, ассоциированные с программами Office.

Компонент Office

Файл ADM

Общие настройки Office

OFFICE9.ADM

Word 2000

WORD9.ADM

Excel 2000

EXCEL9.ADM

PowerPoint 2000

PPOINT9.ADM

Outlook 2000

OUTLK.ADM

FrontPage 2000

FRONTPG4.ADM

Access 2000

ACCESS9.ADM

Publisher 2000

PUB9.ADM

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

Вы должны проверить все значения и настроить Office для ваших пользователей. Вам следует запретить любые особенности, использующие звуки и анимацию. Удалите из всех продуктов команду Detect and Repair. Вы можете также запретить проверку правописания и грамматики при вводе (Check Spelling as you Type и Check Grammar as you Type), поскольку эти операции сильно загружают процессор.

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

С выпуском Windows XP, Microsoft включила необходимые модификации для терминальных серверов внутрь инсталляционного пакета MSI. При инсталляции Office XP на терминальном сервере, Windows Installer обнаруживает наличие терминального сервера и автоматически применяет необходимые изменения. Трансформы больше не нужны.

Даже с этими новыми улучшениями в установке Office XP все равно необходимо сделать пост-инсталляционную настроку, используя файлы ADM для Office XP. Подробнее см. http://www.microsoft.com/office/ork/xp/one/deph02.htm.

Инсталляция с использованием скриптов совместимости

Некоторые приложения требуют модификации после инсталляции или внесения изменений "на лету" во время входа пользователя. Эти изменения осуществляются скриптами совместимости. В качестве примера мы рассмотрим установку Netscape Communicator 4.5.

Как и для других приложений, мы начнем с мастера Add New Programs. Сделайте инсталляцию Netscape как обычно, затем щелкните Finish для закрытия мастера. Теперь надо установить скрипт совместимости. Перед этим давайте разберемся, почему он необходим для Navigator 4.5:

Для запуска скрипта откройте каталог C:\WINNT\Appliation Compatibility Scripts\Install и запустите NETCOM40.CMD. Скрипт выполняет следующие действия:

При входе пользователя запускается COM40USR.CMD (скрипт входа для Netscape), и выполняет слудющие действия:

Теперь Netscape готов для работы на терминальном сервере.

Установка недокументированных приложений

Что делать, если вам попалось приложение, которое не содержит документации по работе с Terminal Services? Вам небходимо научиться определять, требует ли приложение настройки после инсталляции и нужны ли ему скрипты совместимости. Этот навык очень важен, хотя многие современные приложения следуют спецификациям Microsoft.

Начните с веб-сайта производителя программы, поищите в разделе технической поддержки по ключеым словам “terminal server” или “Citrix” (даже если вы используете только Terminal Services без MetaFrame, вы можете найти много полезной информации, проиндексированной для Citrix, поскольку это давний лидер в области терминальных служб). Если вы ничего не нашли, поспрашивайте в форумах, поищите по ключевым словам, указав имя вашего приложения AND “terminal server” OR “Citrix.”

В поиске недокументированных приложений полезны следующие сайты :

http://www.thethin.net

http://www.thinplanet.com

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

Никогда не инсталлируйте непроверенные приложения на рабочий сервер!!!

Как и в случае с другими приложениями, для установки используйте мастер Add New Programs. Если приложение после установки требует перезагрузки, сделайте это. Перед первым запуском приложения проверьте реестр. Начните с HKEY_LOCAL_MACHINE\SOFTWARE и найдите подключ для приложения. Проверьте значения, уделяя особое внимание данным, соежржащим абсолютные маршруты. Значения типа InstallPath или ApplicationSource нормальные, поскольку они одинаковы для всех пользователей, но значения, относящиеся к пользовательским настройкам, например, UserDictionary или UserHome, могут вызвать проблемы. Запишите эти ключи на бумаге.

Затем проверьте в HKEY_CURRENT_USER\Software, что приложение сконфигурировало ключи реестра. Если так, найдите здесь те же типы значений и запишите то, что вы нашли. Проверьте, создано ли зеркало ключей в улее HKEY_LOCAL_MACHINE. Если нет, создайте файл .REG для ключа приложения HKEY_CURRENT_USER\Software, выбрав в regedit опцию Export Registry File из меню Registry. Этот файл понадобится позже, если вам понадобится вручную синхронизировать ключи.

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

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

Убедитесь, что ключи приложения из HKEY_CURRENT_USER корректно скопировались из ключа Terminal Server в HKEY_LOCAL_MACHINE или были автоматически созданы приложением. Если ключи отсуствуют при сравнении их с теми, что находятся в учетной записи пользователя, установившего приложение, вы должны вручную их синхронизировать. Для этого:

  1. Откройте в Notepad файл .REG, созданный ранее, и выберите Replace из меню Edit для замены всех вхождений HKEY_CURRENT_USER\Software на HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software.
  2. Импортируйте файл .REG в реестр

Теперь удалите профиль (локальный и перемещаемый) тестовой учетной записи и зарегистрируйтесь еще раз. Запустите приложение и убедитесь, что отраженные ключи скопировались. Если они там, и вы решили внести для ваших пользователей какие-то изменения в реестре, сделайте их в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software, и новые настройки будут скопированы, когда ваши пользователи запустят приложение в первый раз.

Теперь обратитесь к вашим записям ключей реестра, относящихся к пользовательским настройкам. Если вы обнаружили ссылки на пользовательские файлы, хранящиеся на локальных драйвах терминального сервера, вы должны попробовать скопировать эти файлы в подкаталог вашего драйва ROOTDRIVE, затем изменить значение реестра так, чтобы оно указывало на новое место. Если эти ключи находятся в HKEY_LOCAL_MACHINE, то просто измените их там. Если они находятся в HKEY_CURRENT_USER, измените их там и в подключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Задокументируйте все изменения, которые вы делаете в реестре, чтобы повторить их позже на рабочем терминальном сервере. Запустите приложение и убедитесь, что оно не испытывает проблем с новыми каталогами.

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

Пример из реального мира

Давайте рассмотрим пример приложения, требующего модификации для использования на терминальном сервере. Допустим, ваша компания использует некую программу, называемую WorkGroup, для управления проектами. Эта программа использует базу данных SQL для хранения описаний проекта, сроков, замечаний членов проекта и пр. Вы хотите инсталлировать WorkGroup на ваш терминальный сервер, чтобы позволить пользователям запускать его через веб-браузеры (используя клиент Remote Desktop Web connection).

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

Начните с мастера Add New Programs для запуска SETUP.EXE для установки WorkGroup. инсталлятор не требует перезагрузки, поэтому немедленно запустите regedit и поищите в HKEY_LOCAL_MACHINE\SOFTWARE абсолютные маршруты в ключе WorkGroup:

В ключе Paths вы обнаружили размещение базы данных SQL, которая является общей для всех пользователей, поэтому она не будет представлять проблем для Terminal Services. Однако, в SpellCheck вы нашли значение, которое может создать проблемы - DictionaryPath. После внимательного изучения, это значение выглядит как файл словаря, который совместно используется всеми пользователями. На всякий случай запишите на бумаге значение этого ключа.

Затем поищите аналогичные значения в HKEY_CURRENT_USER\Software. Здесь вы находите еще один ключ SpellCheck, который содержит размещение пользовательского словаря - C:\Program Files\Workgroup:

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

Затем определите, сработало ли отображение реестра, сравнив этот ключ HKEY_CURRENT_USER с HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server, как показано на следующем рисунке.

Как видно, отражение не сработало, поэтому вы должны сделать отражение раздела реестра вручную (если вы решили, что вам нужно предварительно сделать настройки в HKEY_CURRENT_USER для ваших пользователей). В этом случае вы должны создать файл .REG для ключа HKEY_CURRENT_USER\Software\SoftwareCo\WorkGroup.

Теперь запустите WorkGroup и убедитесь, что программа работает под учетной записью пользователя, инсталлировавшего ее. Допустим, что все работает. Вы можете подключиться к базе данных, считывать и вводить данные, делать запросы. Теперь сделайте то же самое под обычным тестовым пользователем. Приложение запускается без проблем, но при попытке добавить слово в пользовательский словарь программа выдает ошибку - тестовый пользователь не имеет прав записи в файл USER.LEX, находящийся на диске C. Вам необходимо устранить этот дефект.

Сначала проверьте, позволяет ли WorkGroup переместить файл USER.LEX в другое место. Снова зарегистрируйтесь под администратором и скопируйте файл из C:\Program Files\WorkGroup в H:\WorkGroup, а затем измените значение UserDicPath в HKEY_CURRENT_USER на H:\WorkGroup. Теперь запустите WorkGroup и попробуйте добавить слово в словарь. Проверив временные метки, вы можете подтвердить, что слово добавлено в копию на драйве H, поэтому изменения сделаны успешно.

Чтобы реплицировать эти изменения для всех пользователей, вам нужно сделать следующее:

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

Для создания отображения реестра, отредактируйте файл .REG, созданный из HKEY_CURRENT_USER, щелкнув на нем правой кнопкой и выбрав Edit. Используйте команду Replace для замены всех вхождений "HKEY_CURRENT_USER\Software" на "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software".

Кроме того, найдите значение UserDicPath и измените его на "H:\WorkGroup". Сохраните измененный файл в каталоге C:\WINNT\Application Compatibility Scripts\Install.

Для копирования файла вам нужно написать два скрипта совместимости - один для инсталляции, а второй для входа. Для нашего приложения оба скрипта очень просты. Для копирования файла в нужное место вам необходимо определить переменную ROOTDRIVE. Затем инсталляционный скрипт должен импортировать ваш файл .REG и добавить вызов скрипта совместимости для входа в USRLOGN2.CMD.

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

Перед запуском инсталляционного скрипта совместимости, вам необходимо создать скрипт совместимости для входа, который будет делать копирование файла для каждого пользователя. Этот скрипт будет вызываться всякий раз при входе пользователя, но он должен копировать файл лишь в том случае, если его не существует на пользовательском ROOTDRIVE. Этот скрипт должен быть сохранен в каталоге C:\WINNT\Applicaiton Compatibility Scripts\Logon. Ниже показан пример скрипта совместимости для входа:

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

После входа в первую очередь поищите в домашнем каталоге файл USER.LEX, созданный в подкаталоге WorkGroup. Если файла нет, вернитесь назад и убедитесь, что ваш скрипты совместимости для инсталляции правильно добавил вызов команды в USRLOGN2.CMD, а затем проверьте скрипт совместимости для входа.

Теперь запустите WorkGroup и убедитесь, что все ключи реестра, особенно измененное значение UserDicPath, скопировались в HKEY_CURRENT_USER для тестового пользователя. Добавьте слово в пользовательский словарь тестового пользователя и убедитесь, что это слово добавлено в словарь, находящийся в домашнем каталоге.

Завершив этот процесс, вы должны проверить WorkGroup, запустив ее одновременно несколькими пользователями. Если вы удовлетворены производительностью, вы готовы повторить инсталляцию на рабочем сервере.

Флаги совместимости Terminal Services

При установке приложения, Terminal Services создает в реестре ключ для флагов совместимости, которые сообщают терминальному серверу тип приложения (MS-DOS, 16-bit, 32-bit). Если вы инсталлируете старое приложение, которое не будет работать на терминальном сервере, вы можете изменить этот флаг так, чтобы терминальный сервер сделал определенные настройки при запуске этого приложения.

Эти флаги затрагивают выделение памяти, отображение реестра и файлов INI. Их также можно использовать, чтобы Terminal Services возвращал значение %USERNAME%, если приложение запрашивает %COMPUTERNAME%. Эта особенность полезна, если приложение использует имя машины в качестве уникального идентификатора.

Если ваша программа не хочет работать под Terminal Services, прочтите статью Microsoft “Terminal Server Registry Settings for Applications

Инсталляция приложений с помощью групповых политик

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

Чтобы использовать групповые политики, приложения должны быть в формате MSI. Групповые политики также поддерживают скрипты в формате ZAP, которые могут запускать инсталляторы, отличные от MSI. Однако, использование этого формата на терминальных серверах не рекомендуется, поскольку такие приложения не поддерживают advertising, и ваши пользователи не получат необходимые ключи реестра HKEY_CURRENT_USER.

Вы можете переупаковать приложение в MSI используя сторонние утилиты, например, Wise for Windows Installer. Обязательно проверьте приложение на терминальном сервере до и после перепаковки, чтобы выяснить, нужны ли какие-то модификации для обеспечения совместимости с Terminal Services.

Основные шаги, требуемые для инсталляции программ с помощью групповых политик, таковы:

Создание папки общего доступа

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

Убедитесь, учетные записи машин ваших терминальных серверов имеют право чтения и выполнения в этой папке. Группы Authenticated Users и Everyone включают машинные учетные записи.

Создание административных инсталляций

Пакеты MSI обычно включают в себя все требуемые файлы, упакованные в файлы CAB. Для оптимизации установки программ, заблаговременно распакуйте эти файлы, создав административную инсталляцию.

Для создания административной инсталляции, запустите Windows Installer Service с опцией “/a” и укажите путь к пакету MSI, который вы хотите распаковать.:

msiexec /a d:\proplus.msi

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

По завершении административной инсталляции, скопируйте новые исходные файлы в общую папку.

Добавление пакетов в GPO

В главе 4 мы создали OU для терминальных серверов и прикрепили к ней три объекта групповых политик. Один из них - это Terminal Server Machine Policy. Этот объект содержит машинную конфигурацию ваших терминальных серверов, поэтому он уже готов для применения к терминальным серверам. Вы можете добавить программные пакеты к этому GPO, и они будут проинсталлированы на всех компьютерах, входящих в OU "TerminalServers".

Для добавления пакета в GPO, откройте редактор политик, раскройте Computer Configuration, Software Settings. Щелкните правой кнопкой на Software installation, и выберите New, Package:

Укажите имя пакета MSI, который вы хотите добавить. Затем у вас спросят, хотите ли вы назначить пакет или открыть интерфейс расширенных настроек. В большинстве случаев вы можете выбрать Assign и принять опции по умолчанию. Однако, если вам необходимо указать трансформу, выберите Advanced.

Транформа (файл MST) определяет опции или вносит изменения в значения по умолчанию файла пакета Windows Installer (файла MSI). Вы можете создать трансформы используя Microsoft Office Custom Installation Wizard или другую утилиту.

Фильтрация приложений

Вы можете использовать единый GPO, который применяется ко всем серверам, но отфильтровать приложения, которые будут установлены на каждый сервер, используя фильтры безопасности на пакетах в GPO. Следующий рисунок показывает GPO, содержащий три пакета - Adobe Acrobat Reader 6, Office XP и Microsoft Group Policy Management Console.

Допустим, что вы хотите инсталлировать Acrobat Reader и Office XP на всех терминальных серверах, к которым применяется GPO, а консоль - только на тех серверах, которые используются администраторами. По умолчанию пакеты наследуют настройки безопасности из GPO, поэтому все компьютеры, которые имеют право чтения на этот GPO будут также иметь право чтения пакета, и как следствие, установят приложение при загрузке.

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

Чтобы этот фильтр безопасности мог работать, вы должны создать группу Domain Security - например, Admin Terminal Servers, - и поместить в нее те серверы, на которых хотите установить консоль.

Для изменения разрешений к пакету, вы должны отключить наследование разрешений GPO. Для этого щелкните Advanced и уберите флажок Allow inheritable permissions. Вы можете затем выбрать копирование существующих разрешений и использовать их в качестве отправной точки для модификаций.

Перезагрузка терминальных серверов

Основной недостаток инсталляции при помощи групповых политик состоит в том, что они обрабатываются только во время загрузки. Если вы добавляете новый пакет, то для его инсталляции вы должны перезагрузить сервер. Преимуществ инсталляции с помощью GPO состоит в том, что новые серверы, помещенные в OU "Terminal Servers", автоматически проинсталлируют необходимые пакеты, экономя ваше время и усилия.

Вы можете использовать GPO и для деинсталляции программ. Подробнее см. книгу Darren MarElia’s The Definitive Guide to Windows 2000 Group Policy (http://www.realtimepublishers.com)

Существуют также системы управления программным обеспечением, позволяющие устанавливать программы по расписанию и не требующие перезагрузки. К ним относятся Microsoft Systems Management Server и компонент Installation Manager в Citrix MetaFrame XPe.

Развертывание приложений для конечных пользователей

Если вы используете Terminal Services для замены рабочих столов, развертывание приложений для ваших пользователей состоит просто в добавлении иконки программ в All Users в меню Start на терминальном сервере. Если же вы хотите развернуть единственное приложение в модели Application Service Provider (ASP), тип развертывания будет зависеть от типа используемого клиента.

Если пользователи подключаются к приложениям на терминальном сервере с помощью локального клиента Remote Desktop Connection, вам необходимо создать файл RDP, который содержит имя сервера и начальное приложение, а затем раздать этот файл пользователям.

Если вы хотите предоставлять доступ к приложениям через клиент Remote Desktop Web Connection, чтобы пользователи запускали программы по ссылке URL, вы должны обратиться к документации, которую предлагает Microsoft вместе с клиентом, чтобы создать веб-страницы для хостинга приложений. Клиент Web Connection Client очень мощный и настраиваемый, поэтому при небольшом знании HTML и ActiveX вы можете создать мощный портал для ваших приложений

Глава 4
Администрирование терминального сервера

Содержание Глава 6
Безопасность и защита от вирусов