proNovell

Есть ZEN4sp1(вероятно это не важно) на NW5.1sp6, есть рабочие станции, все до одной склонированы с одного образа с помощью PartitionMagic, никакие виндовые SID и прочие идентификаторы не правлены - т.е. все на одно лицо. С исходного образа естественно ходили в Novell и естественно станция зарегистрирована в ZEN. Станции регистрируются по типу "ComputerName+ProcessorType".
А теперь собственно вопрос - после клонирования изменяем имя компьютера на новое(например было WS500, стало WS504), входим в сеть - и... машина не импортируется, а на консоли сервера пишется что уже есть такая машина. Удаляем машину образ из ZEN и перегружаемся, и - обе машины импортируются в ZEN. Как это победить?

То, что вы изменили имя компьютера в МС-овском смысле слова еще ничего не меняет для ЗЕНа. При импорте в дерево Workstation Manager пишет в реестр имя объекта для данной рабочей станции, и при ее клонировании ессно этот ключ в реестре сохраняется. Вариант 1 - удалить его непосредственно перед клонированием, чтобы WM потом при старте очередного клона заново ее регистрировал ( хотя не выйдет, т.к. вам же надо сперва поменять имя машины - для чего надо загрузиться, ну разве что без коннекта или при отключенном импорте ).

Вариант 2 - удалять из реестра этот ключ ( HKLM\Novell\Workstation Manager\Identification - удалить со всем содержимым ), переименовывать, перегружаться .. можно пользоваться утилиткой ( wsreg32 или как ее теперь называют в 4-м ЗЕНе .. не помню ), но вручную как-то проще.

Перед начальным созданием образа эталонной системы запустить sysprep от M$, и сделать это обязательно ДО импорта эталонной станции в NDS. А уж потом образ "разносить" можно чем угодно, хоть GHOST'ом

С sysprep'ом - тоже вариант, хотя я как-то к нем равнодушен. А вот еще когда мы пользовались Ghost'ом, то там была утилитка ( ghost walker, если не ошибаюсь, или что-то подобное ), которая как раз меняла имя компьютера сразу после заливки образа ( в нашем случае использовался шаблон - отдел + некое случайное число ). Но после перехода на ЗЕН от этой практики отказались. На днях в ЗЕНовских кулсолюшенах появилась заметка в том числе и об изменении имени компа после заливки образа ( хотя сама статья несколько на другую тему, но ИМХО оттуда можно выцепить нужный кусок ).

http://www.novell.com/coolsolutions/zen ... es_zw.html

Different policies govern what image is sent to a PC when IMG requests an image from the Imaging Proxy Server. The Server Package Image Selection Rule is chosen if the PC has no workstation object in the tree, and hence no workstation object in the Image-Safe Data on the hard disk. The Workstation Package Image Selection Rule is used, if the PC is already registered.

If you are using ENGL's lovely little naming tool (http://www.engl.co.uk/products/zcnclite), add the file ZCNC.EXE to an already existing Base Image (or Add-On Image, and exclude it from all file sets but one.
Then let your Server Package Image Selection Rule use this file set, but let the Workstation Package Imaging Rule use another file set.
Now, when the PC is imaged, the existence of the file depends on whether the PC is unknown (and needs to be named) or not.
Let your script check for the existence of the file before running it - or, if you use SysPrep: add your favorite ZCNC command to the c:\SysPrep\$oem$\i386\Cmdlines.txt - this works on an already sysprepped image! (Remember to put the command in quotation marks.)
Now, a new PC requests to have the name put in at first boot; a re-imaged PC will skip this, and let the Imaging Agent take care of the naming.

Да, она самая. Ага, значит, там новый компьютер именуют таки с помощью sysprep'a.

Андрей Тр. aka RH писал(а):При импорте в дерево Workstation Manager пишет в реестр имя объекта для данной рабочей станции, и при ее клонировании ессно этот ключ в реестре сохраняется. Вариант 1 - удалить его непосредственно перед клонированием, чтобы WM потом при старте очередного клона заново ее регистрировал ( хотя не выйдет, т.к. вам же надо сперва поменять имя машины - для чего надо загрузиться, ну разве что без коннекта или при отключенном импорте ).
Вариант 2 - удалять из реестра этот ключ ( HKLM\Novell\Workstation Manager\Identification - удалить со всем содержимым ),

Вот это то что нужно, а sysprep наверняка ничего не знает о ZEN, да и без сети MS он не так актуален. Клонирование станций с помощью ZEN еще впереди, так что вопросы еще будут

PavelKHTW писал(а):sysprep наверняка ничего не знает о ZEN

Это-то так, но в данном случае речь о чем - подразумевая, что образ станции был сохранен без инфы в реестре ( она была удалена вручную, unreg'ом или еще как ) о том, под каким именем он был зарегистрирован в NDS ( при этом пусть даже в дереве и остался соответствующий объект - неважно ), то при восстановлении этого образа на очередном клоне хорошо бы иметь некую прогу, которая бы могла при запуске с загрузочной дискеты, скажем, прописать у клона новое имя компьютера ( перед первой загрузкой ) - и все. Имя компа действительно актуально только для МС-сетей, но в этом случае вы собираетесь использовать его в ЗЕНе как некий уникальный идентификатор. Мы, к примеру, в качестве такого используем МАС-адрес станции ( Computer_name+MAC, где имя компа далеко не всегда уникально ). Так что если sysprep умеет менять имя компьютера - вводимое как параметр командной строки, с клавиатуры - то можно и его для этого использовать, наверное.

после отработки sysprep'а комп выключается, а при следующем запуске начинает работать мини-мастер установки, как будто ставится софт с нуля, только работает минут 5 всего и при этом естественно можно указать имя компа, сетевые параметры (короче как при обыкновенной установке w2k)

Антон Савельев писал(а):после отработки sysprep'а комп выключается, а при следующем запуске начинает работать мини-мастер установки, как будто ставится софт с нуля, только работает минут 5 всего и при этом естественно можно указать имя компа, сетевые параметры (короче как при обыкновенной установке w2k)

Не поверите, без sysrep-а настройка машины происходит быстрее, минуты 2 , особенно когда железо одинаково и NT, с XP дело несколько сложнее, но решаемо.

Естественно быстрее, потому что если просто заливать образ, то все будет одинаковое. Но и работать будет по-нормальному, только если железо один к одному. Мы у себя иногда используем при прокачке образов NT4, с W2K все сложнее - она вся из себя p'n'p, потому если есть штатная процедура опознания устройств, то лучше ей воспользоваться.

Антон Савельев писал(а)::wink:
Естественно быстрее, потому что если просто заливать образ, то все будет одинаковое. Но и работать будет по-нормальному, только если железо один к одному. Мы у себя иногда используем при прокачке образов NT4, с W2K все сложнее - она вся из себя p'n'p, потому если есть штатная процедура опознания устройств, то лучше ей воспользоваться.

Для NT4 все очень просто, даже если железо разное. У нас с одного образа клонируются машины с P1 по P4 - единственная "сложность" сетевые карты, с Video на много проще, особенно если карты NVideo.
С XP все решаемо, должна совпадать версия ACPI и тогда не будет зависа с agp440.sys.

У нас XP Pro клонируется с одного образа на порядка 5 различных базовых конфигураций, без особых проблем ( т.е. даже никаких кнопок вручную при этом нажимать не надо ). Единственное, чего пока не удалось добиться - избежать нажимать Continue anyway при установке принтеров, возникающей при использовании якобы unsigned драйверов в NDPS ( известная проблема ). Все политики вроде установлены в ignore, чтобы автоматом ставить драйверы, не подписанные М$, но все равно вылазит ..

Андрей Тр. aka RH писал(а):Единственное, чего пока не удалось добиться - избежать нажимать Continue anyway при установке принтеров, возникающей при использовании якобы unsigned драйверов в NDPS ( известная проблема ). Все политики вроде установлены в ignore, чтобы автоматом ставить драйверы, не подписанные М$, но все равно вылазит ..

С NDPS проблема вылечилась установкой SP1 к XP. А политики на установку не подписанных дров действуют корректно только в Win2003

PavelKHTW писал(а):С NDPS проблема вылечилась установкой SP1 к XP. А политики на установку не подписанных дров действуют корректно только в Win2003

Так ХР без SP1 у меня просто не используется. Проблема, как я понял из ТИДов, в том, что при загрузке драйверов в их хранилище (RMS) происходит нечто типа их пересборки, в результате чего "подпись" не сохраняется ( даже у подписанных ). Что-то в этом роде ( принтеры, кстати, iPrint, но в данном случае это неважно ). Интересно, я на М$-овском саппорте ничего такого про неработающие политики в ХР не нашел - откуда информация ?