Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
CheckBootSpeed - это диагностический пакет на основе скриптов PowerShell, создающий отчет о скорости загрузки Windows 7 ...
Вы когда-нибудь хотели создать установочный диск Windows, который бы автоматически установил систему, не задавая вопросо...
Если после установки Windows XP у вас перестала загружаться Windows Vista или Windows 7, вам необходимо восстановить заг...
Программа подготовки документов и ведения учетных и отчетных данных по командировкам. Используются формы, утвержденные п...
Red Button – это мощная утилита для оптимизации и очистки всех актуальных клиентских версий операционной системы Windows...

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

Текущий рейтинг: 3.85 (проголосовало 13)
 Посетителей: 6541 | Просмотров: 8215 (сегодня 0)  Шрифт: - +
Перед тем, как мы погрузимся в процесс инсталляции приложений, давайте рассмотрим механизмы, которые позволяют запускать приложения, изначально не рассчитанные для работы в терминальной среде. Эти механизмы включают скрипты входа, скрипты совместимости, режимы установки и исполнения, отображение реестра и отображение файлов 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_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonAppsetup, который запускает скрипт 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 ScriptsSetPaths.Cmd" If "%_SETPATHS%" == "FAIL" Goto Done

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

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

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

All Users: Startup

COMMON_STARTUP

All Users: Start Menu

COMMON_START_MENU

All Users: Start MenuPrograms

COMMON_PROGRAMS

Current User: Start Menu

USER_START_MENU

Current User: Startup

USER_STARTUP

Current User: Start MenuPrograms

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%System32Usrlogn1.cmd" Goto cont0 Cd /d "%SystemRoot%Application Compatibility ScriptsLogon" Call "%SystemRoot%System32Usrlogn1.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:WINNTFONTS сделает драйв W: ссылкой на каталог шрифтов.

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

Пример 1

Пользователь Joe User имеет домашний каталог, определенный в его учетной записи \Server01HomeJoe.User. При входе на терминальный сервер, буква H отображается на \Server01Home. В сеансе Джо, переменная %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% указывает на WTSRVProfilesJane.Doe. Опять, мы не можем использовать переменные окружения в ключах реестра, поэтому у нас нет легкого способа ссылаться на каталог профиля Джейн.

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

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

Net Use H: \Server01ShareDirectory

подключит H к \Server01Share. Но 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%System32UsrLogn2.Cmd Goto Cont1 Cd Logon Call %SystemRoot%System32UsrLogn2.Cmd :Cont1 :Done

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

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

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

Если терминальный сервер находится в рабочей группе, вы можете заставить систему выполнить дополнительный скрипт, скопировав файл скрипта в каталог System32 и изменив значение AppSetup в подключе реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon. По умолчанию в этом ключе находится только USRLOGON.CMD, но вы можете добавить другие скрипты, отделив их друг от друга запятыми.

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

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

Опубликована: 17.01.2005
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER
Теги:  


Оценить статью:
Вверх
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.