| Новые программы oszone.net |  |
Теперь, когда вы поняли процесс создания среды на терминальном сервере, мы можем приступить к рассмотрению процесса инсталляции программ на терминальном сервере. В идеальном случае, все приложения должны следовать спецификациям "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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware
Отображение реестра работает только в том случае, если программа для записи в реестр использует стандартные вызовы API. Всегда проверяйте реестр после установки приложения и до первого его запуска, чтобы убедиться, что зеркало создано. Если нет, вам следует вручную скопировать ключи. По завершении установки приложения сервер переводится в режим исполнения. В этом режиме, если приложение пытается прочитать ключ реестра из HKEY_CURRENT_USER, а ключа там нет, система автоматически проверит, есть ли такой ключ в подключе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware. Если он там найден, то система скопирует его в 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:WINNTApplication 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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareAdobe с аналогичными в HKEY_CURRENT_USERSoftwareAdobe, чтобы убедиться, что сработало отображение реестра. Когда пользователь первый раз запустит 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. Есть также подробная статья об установке 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=pathTermSrvr.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.
После добавления файлов 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:WINNTAppliation Compatibility ScriptsInstall и запустите NETCOM40.CMD. Скрипт выполняет следующие действия:
При входе пользователя запускается COM40USR.CMD (скрипт входа для Netscape), и выполняет слудующие действия:
Теперь Netscape готов для работы на терминальном сервере. Установка недокументированных приложений Что делать, если вам попалось приложение, которое не содержит документации по работе с Terminal Services? Вам необходимо научиться определять, требует ли приложение настройки после инсталляции и нужны ли ему скрипты совместимости. Этот навык очень важен, хотя многие современные приложения следуют спецификациям Microsoft. Начните с веб-сайта производителя программы, поищите в разделе технической поддержки по ключевым словам “terminal server” или “Citrix” (даже если вы используете только Terminal Services без MetaFrame, вы можете найти много полезной информации, проиндексированной для Citrix, поскольку это давний лидер в области терминальных служб). Если вы ничего не нашли, поспрашивайте в форумах, поищите по ключевым словам, указав имя вашего приложения AND “terminal server” OR “Citrix.” В поиске недокументированных приложений полезны следующие сайты : Собрав любую информацию о вашем приложении, инсталлируйте его на пилотном сервере. Ваш пилотный сервер должен иметь такую же конфигурацию, что и рабочий - с теми же патчами, сервис-паками, скриптами и пр. Никогда не инсталлируйте непроверенные приложения на рабочий сервер!!! Как и в случае с другими приложениями, для установки используйте мастер Add New Programs. Если приложение после установки требует перезагрузки, сделайте это. Перед первым запуском приложения проверьте реестр. Начните с HKEY_LOCAL_MACHINESOFTWARE и найдите подключ для приложения. Проверьте значения, уделяя особое внимание данным, содержащим абсолютные маршруты. Значения типа InstallPath или ApplicationSource нормальные, поскольку они одинаковы для всех пользователей, но значения, относящиеся к пользовательским настройкам, например, UserDictionary или UserHome, могут вызвать проблемы. Запишите эти ключи на бумаге. Затем проверьте в HKEY_CURRENT_USERSoftware, что приложение сконфигурировало ключи реестра. Если так, найдите здесь те же типы значений и запишите то, что вы нашли. Проверьте, создано ли зеркало ключей в улье HKEY_LOCAL_MACHINE. Если нет, создайте файл .REG для ключа приложения HKEY_CURRENT_USERSoftware, выбрав в regedit опцию Export Registry File из меню Registry. Этот файл понадобится позже, если вам понадобится вручную синхронизировать ключи. Сделайте экспорт ключа приложения HKEY_CURRENT_USERSoftware до того, как запустите приложение в первый раз. Вам не следует захватывать настройки, которые сгенерируются при первом запуске. Теперь запустите приложение под той учетной записью, под которой оно установлено. Пройдитесь по всем функциям приложения в поиске потенциальных проблем - сообщений об ошибках, неверного поведения и пр. Затем войдите на терминальный сервер под тестовой учетной записью. Эта учетная запись не должна быть администратором, а должна быть сконфигурирована как обычный пользователь. Запустите приложение и выполните те же тесты. Если ошибок не обнаружено, закройте приложение и проверьте реестр для этого пользователя. Убедитесь, что ключи приложения из HKEY_CURRENT_USER корректно скопировались из ключа Terminal Server в HKEY_LOCAL_MACHINE или были автоматически созданы приложением. Если ключи отсутствуют при сравнении их с теми, что находятся в учетной записи пользователя, установившего приложение, вы должны вручную их синхронизировать. Для этого:
Теперь удалите профиль (локальный и перемещаемый) тестовой учетной записи и зарегистрируйтесь еще раз. Запустите приложение и убедитесь, что отраженные ключи скопировались. Если они там, и вы решили внести для ваших пользователей какие-то изменения в реестре, сделайте их в HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware, и новые настройки будут скопированы, когда ваши пользователи запустят приложение в первый раз. Теперь обратитесь к вашим записям ключей реестра, относящихся к пользовательским настройкам. Если вы обнаружили ссылки на пользовательские файлы, хранящиеся на локальных драйвах терминального сервера, вы должны попробовать скопировать эти файлы в подкаталог вашего драйва ROOTDRIVE, затем изменить значение реестра так, чтобы оно указывало на новое место. Если эти ключи находятся в HKEY_LOCAL_MACHINE, то просто измените их там. Если они находятся в HKEY_CURRENT_USER, измените их там и в подключе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware. Задокументируйте все изменения, которые вы делаете в реестре, чтобы повторить их позже на рабочем терминальном сервере. Запустите приложение и убедитесь, что оно не испытывает проблем с новыми каталогами. Это процесс - метод проб и ошибок, он отличается для каждого устанавливаемого вами приложения. К счастью, его следует применять только для приложений, не сертифицированных для Windows. Пример из реального мира Давайте рассмотрим пример приложения, требующего модификации для использования на терминальном сервере. Допустим, ваша компания использует некую программу, называемую WorkGroup, для управления проектами. Эта программа использует базу данных SQL для хранения описаний проекта, сроков, замечаний членов проекта и пр. Вы хотите инсталлировать WorkGroup на ваш терминальный сервер, чтобы позволить пользователям запускать его через веб-браузеры (используя клиент Remote Desktop Web connection). Вы ничего не нашли на веб-сайте производителя про терминальный сервер, а когда позвонили в службу технической поддержки компании, то услышали, что продавец не поддерживает приложение на терминальном сервере. Вы просмотрели группы новостей, но это редкое приложение и никто его не упоминает. Вам необходимо самим проверить приложение, чтобы убедиться, что оно совместимо с Terminal Services и требует ли оно скрипты совместимости. Начните с мастера Add New Programs для запуска SETUP.EXE для установки WorkGroup. инсталлятор не требует перезагрузки, поэтому немедленно запустите regedit и поищите в HKEY_LOCAL_MACHINESOFTWARE абсолютные маршруты в ключе WorkGroup:
В ключе Paths вы обнаружили размещение базы данных SQL, которая является общей для всех пользователей, поэтому она не будет представлять проблем для Terminal Services. Однако, в SpellCheck вы нашли значение, которое может создать проблемы - DictionaryPath. После внимательного изучения, это значение выглядит как файл словаря, который совместно используется всеми пользователями. На всякий случай запишите на бумаге значение этого ключа. Затем поищите аналогичные значения в HKEY_CURRENT_USERSoftware. Здесь вы находите еще один ключ SpellCheck, который содержит размещение пользовательского словаря - C:Program FilesWorkgroup:
Этот ключ поднимает красный флаг для Terminal Services. Каждый пользователь должен иметь свой файл USER.LEX для WorkGroup, но этот файл по умолчанию хранится на терминальном сервере, а не в пользовательском домашнем каталоге. К счастью, WorkGroup позволяет изменить ключ реестра для размещения файла, поэтому проблему можно легко решить. Затем определите, сработало ли отображение реестра, сравнив этот ключ HKEY_CURRENT_USER с HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal Server, как показано на следующем рисунке.
Как видно, отражение не сработало, поэтому вы должны сделать отражение раздела реестра вручную (если вы решили, что вам нужно предварительно сделать настройки в HKEY_CURRENT_USER для ваших пользователей). В этом случае вы должны создать файл .REG для ключа HKEY_CURRENT_USERSoftwareSoftwareCoWorkGroup. Теперь запустите WorkGroup и убедитесь, что программа работает под учетной записью пользователя, инсталлировавшего ее. Допустим, что все работает. Вы можете подключиться к базе данных, считывать и вводить данные, делать запросы. Теперь сделайте то же самое под обычным тестовым пользователем. Приложение запускается без проблем, но при попытке добавить слово в пользовательский словарь программа выдает ошибку - тестовый пользователь не имеет прав записи в файл USER.LEX, находящийся на диске C. Вам необходимо устранить этот дефект. Сначала проверьте, позволяет ли WorkGroup переместить файл USER.LEX в другое место. Снова зарегистрируйтесь под администратором и скопируйте файл из C:Program FilesWorkGroup в H:WorkGroup, а затем измените значение UserDicPath в HKEY_CURRENT_USER на H:WorkGroup. Теперь запустите WorkGroup и попробуйте добавить слово в словарь. Проверив временные метки, вы можете подтвердить, что слово добавлено в копию на драйве H, поэтому изменения сделаны успешно. Чтобы реплицировать эти изменения для всех пользователей, вам нужно сделать следующее:
Вы могли бы сделать это с помощью отображения реестра, но, как мы выяснили, это отображение придется сделать вручную. Копирование файла потребует скрипта совместимости. Давайте рассмотрим эти задачи по очереди. Для создания отображения реестра, отредактируйте файл .REG, созданный из HKEY_CURRENT_USER, щелкнув на нем правой кнопкой и выбрав Edit. Используйте команду Replace для замены всех вхождений "HKEY_CURRENT_USERSoftware" на "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware". Кроме того, найдите значение UserDicPath и измените его на "H:WorkGroup". Сохраните измененный файл в каталоге C:WINNTApplication Compatibility ScriptsInstall. Для копирования файла вам нужно написать два скрипта совместимости - один для инсталляции, а второй для входа. Для нашего приложения оба скрипта очень просты. Для копирования файла в нужное место вам необходимо определить переменную ROOTDRIVE. Затем инсталляционный скрипт должен импортировать ваш файл .REG и добавить вызов скрипта совместимости для входа в USRLOGN2.CMD. Ручной импорт файла .REG и редактирование USRLOGN2.CMD может быть проще, но использованием инсталляционного скрипта совместимости вы делаете этот процесс легко повторяемым при инсталляции приложения на рабочем сервере. Убедитесь, что вы поддерживаете центральное хранилище для всех скриптов совместимости, которых вы создаете, чтобы вы могли реплицировать их на новых серверах.
Перед запуском инсталляционного скрипта совместимости, вам необходимо создать скрипт совместимости для входа, который будет делать копирование файла для каждого пользователя. Этот скрипт будет вызываться всякий раз при входе пользователя, но он должен копировать файл лишь в том случае, если его не существует на пользовательском ROOTDRIVE. Этот скрипт должен быть сохранен в каталоге C:WINNTApplicaiton Compatibility ScriptsLogon. Ниже показан пример скрипта совместимости для входа:
Теперь, когда все части собраны, запустите инсталляционный скрипт совместимости для 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”
Теги:
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.
