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

🕛 13.04.2009, 19:20

Что делать, если вам попалось приложение, которое не содержит документации по работе с 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, поэтому изменения сделаны успешно.
Чтобы реплицировать эти изменения для всех пользователей, вам нужно сделать следующее:
- Изменить значение UserDicPath для каждого пользователя
- Копировать файл USER.LEX на ROOTDRIVE всякий раз при входе пользователя.
Вы могли бы сделать это с помощью отображения реестра, но, как мы выяснили, это отображение придется сделать вручную. Копирование файла потребует скрипта совместимости. Давайте рассмотрим эти задачи по очереди.
Для создания отображения реестра, отредактируйте файл .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, запустив ее одновременно несколькими пользователями. Если вы удовлетворены производительностью, вы готовы повторить инсталляцию на рабочем сервере.