Базы данныхИнтернетКомпьютерыОперационные системыПрограммированиеСетиСвязьРазное
Поиск по сайту:
Подпишись на рассылку:

Назад в раздел

"Гулящие пользователи" или обеспечение свободы передвижения пользователей между различными версиями

eManual.ru - электронная документация "Гулящие пользователи" или обеспечение свободы передвижения пользователей между различными версиями ОС рабочих станций.

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

Novell предлагает специальный продукт Z.E.N. Works, позволяющий, на первый взгляд, очень легко решать эту задачу для рабочих станций Windows 9x/NT. Почему "на первый взгляд"? Потому, что все выглядит оптимистично, пока вы используете, например, только станции NT Workstation 4.0 (English) или только Win95. Если у вас затесается парочка станций NT 4.0 (Russian) или нужно будет обеспечить свободный переход пользователей между Win95 и WinNT, вот тут-то вам и поплохеет. В жизни все не так, как в рекламе.

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

Обеспечение пользователя возможностью регистрироваться на рабочей станции.

Для Win95 эта проблема не актуальна. Здесь может регистрироваться всякий. Для WinNT это важно. Security Account Manager пустит на станцию только того о ком знает. Z.E.N. Works предлагает решить эту проблему с помощью NT Workstation Manager (часть NetWare Client) на рабочей станции и NT User Policy Package в NDS c выбранным режимом Dynamic Lockal User. Вот об этом и поговорим.

При настройке Dynamic Lockal User прежде всего следует выбрать какую учетную запись использовать NetWare или NT. Для "гулящего пользователя" представляется наиболее очевидным выбрать режим Use NetWare credentials и Volatile User (чтобы не мусорить). При этом обеспечивается динамическое создание в базе данных SAM на рабочей станции учетной записи о пользователе после его регистрации в NDS, и затем регистрация на данной рабочей станции. После окончания сеанса учетная запись автоматически удаляется. Казалось бы идеальный вариант, но ...

В этом случае в домашней директории пользователя NetWare создается копия профиля пользователя NT, т.е. содержимого каталога WinNT/Profiles/username со всеми подкаталогами, а именно: Cookies, Desktop, History, Start menu, Favorites, AppData, Personals и т.п. Этот профиль будет подгружаться на рабочую станцию при регистрации пользователя. Так вот в русской версии NT этот самый профиль выглядит иначе, папки называются не так. Например, Desktop = Рабочий стол, Start menu = Главное меню, AppData = Данные и т.п. Как вы думаете, что произойдет, если пользователь начнет пересаживаться между русской и английской версиями NT? Правильно, ничего хорошего.

Для того, чтобы избежать этой проблемы следует выбрать режим использования учетной записи NT. Следует заметить, что для этого придется создать на всех рабочих станциях некоего универсального пользователя, скажем NWUSER (в разных языковых версиях даже стандартные пользователи называются по разному, нельзя воспользоваться стандартной учетной записью Guest, потому что в русской версии она называется Гость). Следует также в Policy Package установить флажок Manage existing NT account, иначе пользователь будет спрошен о пароле для NWUSER, которого он не знает.

Есть и другой способ. Можно "англифицировать" русскую NT для этого необходимо проделать довольно большую работу по переименованию папок "Рабочий стол", "Главное меню" и т.п. в подкаталогах WinNT/ и WinNT/Profiles/ в их английские эквиваленты. Затем необходимо отредактировать реестр, а именно значения ключей в HKEY_USERS/.DEFAULT/Software/Microsoft/Windows/CurrentVersion/Explorer/Shell Folders и User Shell Folders. Опять же необходимо переименовать ссылки на папки. Вероятно необходимо проделать то же самое в HKEY_CURRENT_USER. Лично мне такой путь показался слишком громоздким и я не стал его проделывать. Однако вы можете попытаться сходить таким путем. Теоретически это может избавить вас от части дальнейших проблем, речь о которых пойдет ниже. Возможно, однако, что на этом пути есть какие-то неведомые мне препятствия.

Персонализация программной среды.

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

Прежде всего нам следовало бы обеспечить перемещение за пользователем таких папок, как Favorites, History, AppData и Personal. Это можно сделать создав в дамашнем каталоге пользователя подкаталоги с перечисленными названиями, скопировав в них содержимое соответствующих каталогов из его профиля (с родной рабочей станции), и создав Application Object, назовем его Personalizator, который бы запускался при регистрации пользователя в сети и подправлял в реестре рабочей станции путь к перечисленным каталогам. Вот фрагмент axt файл такого объекта:

AXT_FILE 2.5 [Application Name] Value=Personalizator [Application Caption] Value=Personalizator [Application Path] Value= 47 NULL [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders Name=AppData Value=%Home Directory%AppData [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders Name=Favorites Value=%Home Directory%Favorites [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders Name=History Value=%Home Directory%History [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders Name=Personal Value=%Home Directory%Personal [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders Name=AppData Value=%Home Directory%AppData [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders Name=Favorites Value=%Home Directory%Favorites [Registry Value Create] Type=String Flag=Write Always Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders Name=Personal Value=%Home Directory%Personal [Registry Value Create] Type=String Flag=Write Always Flag=Always Distribute Setting Key=HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders Name=History Value=%Home Directory%History [Application Flags] Flag=Install Only Flag=Always Distribute Application [Application Platform] Flag=Windows 95 Flag=Windows NT

Но это еще не все. Многие приложения используют реестр для хранения персональных настроек. Поэтому вам придется как следует прочесать HKEY_CURRENT_USER/Software для того, чтобы найти там необходимые для вашего "персонализатора" ключи и добавить их установку в Application Object. Алгоритм поиска простой, если вы изначально придерживались простых стандартов. Например если все пользователи NetWare имеют уникальные CN, а адреса электронной почты имеют вид CN@Domen.name,то очень легко выловить индивидуальные настройки для GroupWise или Outlook. Если же вы не придерживаетесь простых стандартов, то боюсь вам придется для каждого пользователя создавать собственный "персонализатор", поскольку использование макросов типа %CN% не пройдет.

Некоторые приложения могут иметь специальные "нехорошие" файлы с персональными настройками и хранить их не там где надо. Например Netscape Communicator имеет такой файл prefs.js и хранит его в %*WINDISK%Program FilesNetscapeUsersNetscape_User_Name. О таких штучках надо знать и также обеспечивать их перетаскивание за пользователем.

Выводы.

Если вы отважитесь проделать этот путь до конца вы получите возможность садиться за любую рабочую станцию с ОС компании Microsoft подключенную к вашей сети NetWare и работать на ней как на своей собственной, невзирая на версию ОС. Однако путь этот многотруден, и, если вы воодушевлены каким-нибудь пресс-релизом Novell о возможностях Z.E.N. Works, еще раз перечитайте мою статью и подумайте, хватит ли у вас сил и терпения со всем этим разобраться.

16 июня 1999 г.
Евгений Соколов

  • Главная
  • Новости
  • Новинки
  • Скрипты
  • Форум
  • Ссылки
  • О сайте




  • Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
     Copyright © 2001-2022
    Реклама на сайте