ZENworks 3.2 - WS import, policy package и imaging

[Андрей Тр. aka RH]

Александр Попов

Простите, но до логина пользователя мы вообще не можем говорить о какой либо политике . Я не прав?

Неправы, конечно. Чтобы импортировать WS в Дерево вовсе необязательно доходить до логина. Импортируются они при старте системы ( System scheduler startup ), при этом правила наименования объектов workstation, целевой контейнер и пр. определяются политикой WS Import Policy из Server Package ( названия сейчас пишу по памяти, поэтому за 100%-ю точность не ручаюсь ). В нем, к примеру, также определяется политика Imaging для еще незарегистрированных в Дереве WS.

ИМХО Вы по ходу дела смешиваете Workstation Policy Package ( в известном смысле аналог User Policy Package ) и Workstation Import Policy ( часть Server Package ). Для первой все, что Вы рассказали про Search Policy и пр., действительно верно !

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

По делу у кого-нить еще мысли будут ?

[Константин Ошмян]

Замечание по делу: после импорта раб. станции её объект в дереве переименовать можно. При следующей регистрации она это заметит и обновит свою запись в реестре. Проверял, работает.

[Андрей Тр. aka RH]

Замечание по делу: после импорта раб. станции её объект в дереве переименовать можно. При следующей регистрации она это заметит и обновит свою запись в реестре. Проверял, работает.

Ok, спасибо. После чтения документации у меня такое впечатление и сложилось - что при переименовании или перемещении объекта workstation эти изменения должны автоимпортом отследиться и новый объект создан не будет. Я пробовал, и все работает, вроде бы, но вот с Remote Control какие-то проблемы ( не захотел соединяться со станцией после ее переименования ). Впрочем, это уже мелочи - разберусь.

-------------

Разобрался - можно переименовывать и перемещать, однако для завершения обновления объекта нужно, как я понял, "повторно импортировать" WS - чтобы служба zenwsimp ассоциировала "новый" объект с данной WS. В log-файле при этом появится запись Found workstation такая-то ( вместо Created .. ). После этого и Remote Control нормально работает ( уже с переименованным объектом ).

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

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

[Александр Попов]

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

Вот что пишет Novell по поводу импортирования рабочих станций:

Использование сервиса импорта
Сервис импорта используется только при возникновении следующих ситуаций:

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

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

Во всех других случаях, когда рабочая станция зарегистрирована (login) в сети, для ее регистрации (register) и обновления объекта "Рабочая станция" используется программа регистрации рабочей станции клиента (Workstation Registration). Сервис импорта для выполнения данных операций не вызывается.

Регистрация импортированных рабочих станций
После импорта рабочей станции она должна быть зарегистрирована (register) при каждой регистрации (login) в дереве. Программа регистрации обновляет объект "Рабочая станция" при возникновении одной из следующих ситуаций:

1. Запуск программы менеджера рабочей станции.
2. Регистрация пользователя в дереве.
3. Разрегистрация пользователя Windows* 2000 или Windows NT.

Как только рабочая станция была импортирована, программа регистрации клиента хранит и постоянно обновляет сетевой адрес и время регистрации рабочей станции.

Информация объекта "Рабочая станция", которая обновляется при регистрации рабочей станции, включает информацию о времени регистрации рабочей станции, сетевом адресе, последнем сервере и последнем пользователе.

Разобрался - можно переименовывать и перемещать, однако для завершения обновления объекта нужно, как я понял, "повторно импортировать" WS - чтобы служба zenwsimp ассоциировала "новый" объект с данной WS.

Абсолютно верно, программа регистрации запросит сервис импорта для синхронизации рабочей станции с ее объектом рабочая станция.

[Андрей Тр. aka RH]

Александр Попов
Интересно было почитать для разнообразия на русском. Честно говоря, русский вариант мне понравился чуть меньше. Приведу оригинал, позволив себе выделить наиболее интересные места.

Understanding Workstation Import and Registration

After you have installed Automatic Workstation Import, importing workstations is a one-step process. The Workstation Registration program in the Novell Client accesses the Automatic Workstation Import service, which creates the Workstation object and registers the workstation.

Using the Import Service

The Automatic Workstation Import service creates network traffic;
however, the import service is used only when one of the following occurs:

A workstation is logged in to the tree and a corresponding Workstation object does not exist.

This would normally be the first time the workstation is registered. The Automatic Workstation Import service initially creates the Workstation object in the tree, populates the object with default values, and updates the properties with the current registration information.

The Workstation Import policy is used to determine where the Workstation object is created and how it is named.

A workstation is logged in to the tree and its Workstation object was either moved or renamed.

The registration program calls the import service to synchronize the workstation with its Workstation object.

At all other times when a workstation is logged in to the network, the Workstation Registration program in the client registers the workstation and updates the Workstation object. The import service is not contacted for these operations, so network traffic to and from the Workstation Import service is not an issue. (Workstations that authenticate and update Workstation objects will still generate some network traffic.)

Registering Imported Workstations

After a workstation has been imported, it only needs to be registered each time it logs in to the tree. The registration program updates the Workstation object when one of the following occurs:

The Workstation Manager program starts
A user logs in to the tree
A Windows* 2000 or Windows NT* user logs out

After the workstation has been imported, the client's registration program updates the workstation's registration time, network address, last server, and last user information.

На мой взгляд, русский вариант читается тяжелее - к примеру, там "регистрация" используется в различных контекстах, иногда даже в одном предложении. К тому же есть мелкие несовпадения типа "After the workstation has been imported," - "Как только рабочая станция была импортирована ..", "the first time the workstation is registered .." - "при первой регистрации ..". Впрочем, это уже на любителя.

Только я не очень понял, о чем спор-то. Где-то написано, что "Для определения местоположения созданного объекта "Рабочая станция" и его имени одновременно может применяться более одной политики импорта рабочих станций" ?

[Александр Попов]

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

Я не вижу существенных отличий между русской и английской версиями

Только я не очень понял, о чем спор-то. Где-то написано, что "Для определения местоположения созданного объекта "Рабочая станция" и его имени одновременно может применяться более одной политики импорта рабочих станций" ?

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

[Андрей Тр. aka RH]

Так мне неинтересно о процессе импорта рабочих станций Я все перечитываю Ваш совет, и пытаюсь представить себе последовательность действий по его выполнению :

Настройте для разных контейнеров где находятся нужные вам пользователи (например, для контейнера бухгалтеров, назовем его BUH, будет действовать свой server package - BUH_server Package ) свои server package. Затем создайте container package (BUH_container package), где определите границу поиска политик по своему усмотрению -1,0,+1.

Если у меня есть "нужные мне пользователи", то просто целевой контейнер нужно указать относительно пользователя - и все. Тогда по Вашему методу они в конце концов ( когда все залогинятся ) окажутся рассортированными по BUH и прочим отделам ( при желании можно и WS.BUH создать ).

А так я для себя ничего не решил Если действительно можно рабочие станции каким-то образом одновременно разложить по OU, да еще и под разными именами ( в соответствии с различными WS Import Policy ), то я был бы только рад. Я даже уже почти согласен импортировать их по логину, а не по старту WS Manager.

Почему вы думаете, что один процесс com.novell.application.zenworks.autowsmanagement.wsimport.Im не сможет обрабатывать некоторое количество container package (политику импорта, которая включает в себя правила наименования и размещения).

Да потому, что этот один процесс с политикой не ассоциируется, и даже пользователи, которые мне "нужны", тоже. А ассоциируется с ней сервер ( ну или как Вы дотошно подметили server container; на мой взгляд, дело это не меняет - сервер-то у нас такой один, поэтому и контейнер тоже один ), на котором сей процесс запущен. И более одной такой политики одновременно ( из Server Package ) c ним ассоциировано быть не может ? Или Вы что ли считаете, что поиск политики импорта начнется с контекста объекта "нужный пользователь" ??

Могу сказать, что конкретно не понимаю - "некоторое количество container package (политику импорта, которая включает в себя правила наименования и размещения)". Какая в данном случае связь между Container Package, содержащим Search Policy, и той самой политикой импорта ?

В общем, не в порядке спора, а в порядке здоровой полемики .. еще раз для глухих можно ?

[Урал]

Господа, а где вы взяли русскую документацию?