Опрос по массовой установке клиентской части DIRECTUM
Для массового распространения клиентской части системы DIRECTUM предлагался один способ установки через групповые политики Active Directory. Однако у этого механизма есть свои ограничения и как показывает практика многие клиенты используют другие средства распространения ПО. Хотелось бы определить, какие средства более популярны.
Предлагаем Вам ответить на небольшой опрос.
Результаты опроса будут доступны только для внутреннего использования и не будут разглашаться.
Самая боль не при установке новому пользователю. Самая боль приходит при переходе на новую версию. По этой причине переходы делаем редко.
Поэтому, голосуем
а мы через SCCM раскидываем всем образ
принудительно при загрузке ОС ставим всем критичным пользователям (канцелярия+руководство), далее массовые сообщения пользователям о необходимости самостоятельно обновить клиент системы, спустя пару недель проверяем где не был установлен новый клиент и на принудительную установку при первой же загрузке
последний переход был довольно гладким, самые большие заморочки были только с удаленными представительствами
Дан, я правильно понял, что описываемый вами сценарий требует наличия Active Directory в организации?
Цитата с одной Wiki
System Center Configuration Manager – достаточно жесткий и привлекательный для администратора инструмент в том смысле, что реализует большинство действий вне зависимости от желания пользователя компьютера. Последнее, естественно, предполагает наличие инфраструктуры Active Directory и административных прав на соответствующие рабочие станции и серверы.
Дан, насколько я понимаю у ваших пользователей есть права администратора на своих компьютерах, что они могут самостоятельно обновлять клиент? Или же это сделано через "Центр программного обеспечения" в SCCM?
В целом мне так же больше импонирует идея предложенная Михаилом, пользователь подключается к серверу, проходит проверку версии и в случае чего получает с сервера обновление.
да, SCCM использует данные Active Directory
а вот права администратора пользователю не нужны. SCCM разворачивает пакет самостоятельно под правами системной учетки
пользователь в любое время также может зайти в центр программного обеспечения и установить/переустановить клиент системы оттуда (крайне полезно, когда что-нить слетает в настройках пользователя, реестре и т.п.)
у Михаила интересная идея, только вопрос в том, как это будет работать в организациях с различной ИТ структурой, политиками распространения ПО, различными правами пользователей ПК и т.д.
в этом плане в чем фишка установочного пакета реализованного в SCCM - это возможность сперва удалить ненужные компоненты с ПК пользователя, затем установить необходимые в заданной последовательности, а также создать необходимые ярлыки, установить необходимые значения в реестре, задать необходимые настройки, скопировать конфигурационные файлы, еще и делать всё это в зависимости от конфигурации ПК (ну как минимум разрядность ОС, например)
p.s. меня, как администратора системы, это устраивает на все 100%, но вот более подробно на тему работы и сопровождения SCCM и AD рассказать наверное не смогу, т.к. этим полностью занимается смежный отдел
Согласен, если в организации уже куплен SCCM и имеются администраторы умеющие с ним работать, то это удобно. Но мне кажется довольно странным для обновления СЭД использовать другой платный продукт, для использования которого необходимо пройти обучение опять же за деньги. + По нашему предприятию периодически и с SCCM возникают проблемы, нет клиента SCCM на ПК нет и обновления СЭД.
в случае крупной организации SCCM решает вопросы распространения и обновления всего стандартного ПО на предприятии
а отсутствие клиента SCCM у нас решается следующим образом - на все ПК, которые будут работать в сети предприятия, ОС устанавливается из стандартного образа (в нашем случае их несколько), куда входит весь набор обязательных программ и утилит
права администраторов на ПК имеет очень ограниченный круг людей, поэтому удаление каких либо обязательных компонентов маловероятно
Мы в банке установку проводим через групповые политики в 3 этапа:
1. Заранее раскладываем на рабочие станции Client.msi и OIntegration.msi определяя машины путем контроля присутствия папки Directum на ПК;
2. День обновления (как правило выходной), начинаем обновлять сервер, с которого мы заблаговременно сняли все резервные копии и снапшоты. Если обновление сервера не удастся, дальше продолжать никакого смысла нет - откатим и забудем. Но если все успешно - переходим на следующий пункт;
3. Запускаем политики по (1) Удалению раннего клиента и интеграции, (2) Запуска установки, (3) снятие логов каждого этапа для архива и определения ошибок.
В среднем, с таким подходом, мы за одни сутки обрабатываем до 400 ПК из 500 заявленных. Как показывает практика, оставшиеся 100 состоят из 60 выключенных машин и 40 специализированных, которые не берут групповые политики - там только ручками.
Другие способы нам не понравились.
>> (3) снятие логов каждого этапа для архива и определения ошибок...
1. Тарас, можете детальнее пояснить о каких именно логах речь? И каким образом в последующем их анализируете (вручную, используются автоматизированные системы и т.д.)?
2. Правильно ли я понимаю, что оставшиеся 60 выключенных ПК, при включении обновляются автоматом и проблем с установкой нет?
3. Есть реальные цифры по рабочим станциям, на которых что-то пошло не так? Интересно их количество (без учета 40 специализированных)?
Алексей Зубин, отвечаю по порядку:
1. В отдельную сетевую папку у нас складываются файлы без расширения с именем ПК, внутри этих файлов в текстовом формате, записан полны процесс работы политики от удаления, до установки. Нам это удобно даже просто визуально - файл должен быть около 61 Кб, а сели он 1-30 Кб то значит удаление прошло с ошибками и процесс остановился. Если около 30-45 - значит удаление прошло успешно, а вот установка оборвалась по какой-то причине. Спецтачки могут сорить логами в 1 Мб. Но в целом таких не очень много. В них по сути даже заглядывать не надо
Основная проблема установки клиента - битый файл Установщика, который мы обновляем удаленно и провоцируем политику на внеочередное срабатывание (gpupdate /force).
2. Верно, но политики идут в 3 этапа, каждый из которых накатывается 1 раз в час, поэтому несознательные пользователи, отключившие ПК на выходные не взирая на рассылку - первые 3 часа сидят без системы.
3. Последние данные по обновлениям:
3.1 Об установке ОИ логи прислали 612 ПК, средний лог файл 31 Кб.
3.2 Об установке Клиента логи прислали 633 ПК из которых:
Тут надо понимать, что изначально 607 было нифига не 607, а скорее 588, но из-за замены клиента - число выравнивается. Оставшиеся 4 - были отработаны без политик, поэтому логи и не обновились. А так же надо учесть ошибку политики, так как цифры от ОИ и Клиента - разошлись. Но эти единицы, мы уже вручную пробегаем.
Состав лога с ошибкой (10 Кб):
Тарас, идея отслеживать размер лога и далее делать выводы об успешном выполнении установки - достаточно оригинальная.
Тут боюсь могут быть нюансы:
Но в целом идея хорошая!
Алексей Зубин, У нас ситуация с (WinXP до Win10) простая - у нас 99% парка на WIN8, а WinXP мы политикой специально обходим, так как она уже не поддерживает ОИ.
А про парк машин в 10-20 раз больше - наверно требует участия не 2 людей (Админ СЭД и админ AD), а немного больше помощников....
А есть у кого опыт с Ansible, Chef, Puppet?
Спасибо всем за ответы. Опрос закрыт.
Авторизуйтесь, чтобы написать комментарий