Есть такая технология, как распространение ПО через ActiveDirectory (msi пакеты). Как узнать логи применения этой политики в домене? Вот политика есть, а результат применения её совсем не очевиден (Может для установки места не хватило или версия инсталлятора не устраивает или чего-то не хватает, типа dotNet старый и пр.). Отчитывается ли рабочая станция перед контроллером домена за результат применения политики (про запись логов в системном журнале я знаю)? Или политика распространения ПО это только половина какого-то инструмента (типа SMS), который нужно отдельно покупать?
P.S.
Пока пишу скрипты установки js->WScript.Run(«msiexec -i *.msi /passive /norestart», 0, true), прописываю их в автозагрузку компьютеров, затем, после установки, программно проверяю через реестр (RegRead или WMI) или по наличию определённых файлов в определённом path, а результаты проверки записываю в текстовый файл логов в сетевую шару. Такой метод позволяет «распространять» не только msi, но и InstallShield, innosetup и пр. инсталляторы (но не всех программ, а только тех, которые поддерживают режим тихой установки без запусков посторонних окон или программ). В этом случае процесс установки ограничен по времени — скрипты отрабатывают утром, поэтому к обеду имею 80% результат. Но приходится заранее подготовиться: сегодня пишу и отлаживаю скрипты, перед уходом с работы прописываю в автозагрузку, завтра они с утра запускаются.
Эти события мне знакомы. Как-то писал их перехват через wmi. Но мне кажется логичным подход к установке в таком виде:
1. Попытка установки (с учётом небольшого набора данных об окружающей среде, например, знать версию windows, чтобы случайно не запустить заведомо неудачную установку windows installer 3.5 для ХЗ XP на windows server 2003).
2. Получение результата установки (определение версии того же windows installer после установки).
3. Если результат не достигнут, то даже знания о событиях вряд-ли стоит рассматривать для автоматической корректировки алгоритма установки. Думаю, что в любом случае надо разбираться с неудачной установкой вручную.
Использование SCCM (в прошлом SMS) под вопросом, опять же из-за способов поддержки в типах установщиков. Вы не знаете, он кроме *.msi что-то поддерживает?
(Готовить пакет изменений в системе после установки любого приложения не есть хорошо, потому что такие пакеты могут быть разными в зависимости от версии windows)
Производственный путь - стандартизация ПО по наборам рабочих мест, затем средствами ADT или SCCM создание кастомизированных образов установки.
Дает следующие преимущества:
-проверка ПО на совместимость,
-ускорение развертывания,
-простота восстановления.
Простой
Простой
Средний
Простой
