proNovell

Уважаемые коллеги, прошу совет
Задача - автоматизировать обновление клиентов (порядка 250) на "новую" версию (скажем 4.9SP2) но главная цель - поголовная замена IPX на IP. Соответствующий unattend для ACU подготовлен, нужные файлы выложены. Но вот проблемка - это должно делаться медленно и печально, дабы не сорвать работу (лично наблюдал косяки автообновлений). Поэтому - здравая мысль - использовать для этого небоевой сервак в другом дереве, но с копиями бюджетов пользователей, куда натравливать этих самых клиентов кучками, контролируя и корректируя ситуацию по ходу, тем более что он в будущем и будет их обслуживать. На этом серваке помимо IP для этих целей поднят IPX (по фрейму E_II). Но вот чисто IPX-ные клиенты отказываются его видеть т.к. они исторически работают с фреймом 802.2. Попытка замены фрейма на этом сервере на их "родной" приводит к взаимному узнаванию серверов и нудному требованию IPXRTR сменить номер сети. Можно конечно выделить в старом дереве специальный контекст с механизмом автообновления и запускать туда пользователей под одним логином, например, но это как то не очень, на крайний случай. Можно еще попробовать задать для нового сервера тот же номер IPX сети во фрейме 802.2, но не уверен в последствиях данного действа. Есть у кого мысли? Заранее спасибо всем кто ответит.

ИМНО.
У меня примерно такая же ситуация по числу пользователей. По зрелому размышлению мы отказались от автоматизации в этом вопросе: в логин-скрипте прописали копирование архива с новым клиентом на все машины, а затем с напарником постепенно, по мере победы над ленью, наведываемся к пользователям и руками выполняем смену протокола и накат нового клиента.

C переходом на IP больше ничего менять не приходится? Дерево то же? Система почты, печати, настройки клиентов (всякие кэши), микрософтовский клиент, шАры? У меня подобная ситуация, с переходом на новое железо поменялся и сам Новелл (с 4.20 на 6.0), и транспорт (теперь IP), и дерево и все остальное. Походе никуда от этого не деться.

Зачем "просто так" менять IPX на IP? Что-то не работает?

1. сокращение сетевого трафика (конечно IPX на клиентах это не NetBeui, но все же броадкастят изрядно, особенно если броадкастовый домен на 1024 хоста)
2. кластер, который хочется собрать на новом железе, не умеет работать с IPX
3. траблешутинг IP как то ближе и роднее.

Хочу добавить оптимизма.
Я как-то обновлял с помощью ACU несколько сотен клиентов, и как раз с переводом на чистый IP, и нормально сработало.
Что помогло:
1. большинсто операционок пользователей заливались со стандартного образа
2. пользователи имели права админов на локальных машинах - с Win9x понятно, а на Win2000 временно дал такие права на локальных машинах (централизованно понятно дело)
3. основательно потренировался на тестовых машинках

Теперь бы наверное использовал ZENworks, можно не зависеть от локальных прав пользователя на Win2000.

Перед переходом на чистый IP надо обязательно навести порядок с SLP и DNS.
Микрософтовский клиент для Netware и GSNW должны умереть, поскольку работают по IPX. Для всяких там MS SQL, которые любят пользоваться шарами из-под GSNW, при необходимости надо настроить CIFS.
А что значит "небоевой сервак в другом дереве, но ... он в будущем и будет их обслуживать". Ты что, мигрируешь по ходу дела в другое дерево?
Медленно и печально можно сделать включая строку ACU в контейнерные скрипты. Ставить для этого отдельный сервер в отдельном дереве - это слишком.

а еще можно - потренировавшись на "кошечках" (своих АСУ-шниках) взять какой-нибудь дружественный отдел (у меня один отдел - одна группа в дереве) вставить в контейнерный скрипт IF MEMBER OF ла-ла-ла - побыть одно утро в этом отделе, посмотреть, учесть возникшие неприятные моменты и так потихоньку - или по группам или по контекстам обновить

перед этим разослать всем письмо с описанием что будет происходить, что делать.

глаза боятся, руки делают

Совершенно в точку, по ходу дела переезжаем с 5.1 на 6.5 и на чистый IP, поэтому и держу два дерева, в юнности наигрался с миграцией 4.11 - 5.1, хватит сильных эмоций, а насчет боязливых глаз - так кто у нас главный враг админа - правильно - шаловливые ручки, не люблю авось, люблю гарантии. А насчет поконтекстного перевода отделов - не наш случай - все 250 объектов исторически в одном контексте, так что будем прорабатывать организационные мероприятия.

Отправил ответ, потом дошло насчет групп- дельный совет - завести группу в старом дереве со скриптом ACU и последовательно включать в нее тех или иных пользователей, предварительно делая им рассылку по почте и возможно присутствуя лично в этом отделе во время их перерегистраций (с утра как правило). Спасибо Андрей!

VladislavM писал(а):Отправил ответ, потом дошло насчет групп- дельный совет - завести группу в старом дереве со скриптом ACU и последовательно включать в нее тех или иных пользователей, предварительно делая им рассылку по почте и возможно присутствуя лично в этом отделе во время их перерегистраций (с утра как правило). Спасибо Андрей!

Группу? А как можно группе скрипт назначить? Может Profile имеется в виду?

ну да, конечно, скрипт ACU будет в контейнере, а переход на него - по условию членства в группе. Можно конечно и через профиль, там свой логин скрипт

А-а-а... Через IF MEMBER OF планируете? Ну тоже вариант.

VladislavM писал(а):в юнности наигрался с миграцией 4.11 - 5.1, хватит сильных эмоций

Тут тоже хочу добавить оптимизма.
Нынешний Migration Wizard - сильная вещь!
Требуется только внимательно прочитать документацию и потренироваться на тестовых серверах.
Я так и мигрировал с NW 5.1 на 6.0, и при этом с железки на новую железку.
Страшно было - жуть! Но ведь работает

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

у меня контексты поделены по географическому признаку или по предприятию (есть отпочковавшиеся пока еще родственные структуры) а так, на каждый отдел своя группа, ну еще несколько по ролям-задачам. И права раздаю почти только группам, и логин-скрипт контейнерный у меня почти только из IF MEMBER OF состоит, если у вас не так - рекомендую упорядочить - очень пригодится при переносе на новый сервак и т.д.