Разница между установкой msi с помощью "Invoke-WmiMethod"(через файл cmd) и установкой непосредственно на сервер
Работал на сервере, чтобы установить MSI; Журналы событий были чистыми и все успехи; но файл ключа в каталоге bin все еще старый. Позже попытался установить его напрямую, дважды щелкнув по RDP на сервере; установка прошла успешно, и файлы bin обновлены.
-> Перезагрузки не требовались и не были задействованы в обоих случаях. -> почему это происходит? и где я могу найти больше журналов? -> Сервер Windows 2008 R2
1 ответ
Наиболее вероятной причиной этого является то, что вы запускали MSI без вывода сообщений через WMI и в интерактивном режиме при входе в систему на сервере (за исключением случаев, когда установка вообще не запускалась). Это то, что вы на самом деле сделали? Есть и другие причины, которые могут вызвать ту же проблему. Нам нужно увидеть содержимое файла update.cmd, чтобы быть уверенным.
Для решения первой проблемы: "Бесшумный и интерактивный": внутри каждого MSI-файла есть разные последовательности установки, и наиболее важными из них являются:
- UserInterfaceSequence - показывает пользовательский интерфейс для MSI, вы можете вводить данные и перемещаться между экранами, а также прерывать настройку.
- InstallExecuteSequence - это фактическая последовательность установки, которая запускается при нажатии последней кнопки в последовательности пользовательского интерфейса.
Что происходит во время установки без вывода сообщений, так это то, что вся UserInterfaceSequence пропускается. Обычно это нормально и не должно вызывать проблем в правильно написанном пакете MSI. Однако иногда или фактически довольно часто в наши дни разработчик установки не вставляет все пользовательские действия или сценарии, которые необходимо запустить во время установки, в последовательность установки без вывода сообщений, что приводит к неполной установке при запуске в режиме без вывода сообщений. Хотя указанный вами признак (файл не обновлен) не является наиболее типичным для этой проблемы установки без вывода сообщений, он все же является вероятной причиной. Другие причины могут включать неправильную командную строку или помехи от WMI, о которых я не знаю. Я никогда не использую WMI для установки файлов MSI, так как есть много других способов запуска файлов MSI. Вот еще один поток, посвященный альтернативам развертываниям msiexec.exe (под капотом, я полагаю, все эти разные способы вызывают API-интерфейс Windows 32 в стиле C).
Надлежащая поддержка установки без вывода сообщений является абсолютным требованием для MSI - он должен иметь возможность работать без вывода сообщений, или он не создан должным образом по определению. Но всегда есть способы сделать что-то не так, и есть еще много пакетов, которые не соответствуют. Для корпоративного использования автоматическая установка обычно является единственной функцией MSI, которая всегда используется. Это одно из ключевых преимуществ файлов MSI.
На уровне профессионального упаковщика приложений мы находим способы справиться с этим в каждом конкретном случае. Часто прибегают к значительным изменениям файла MSI, чтобы гарантировать, что все работает, что должно работать. При установке сервера это часто не стоит усилий, так как проще запустить установку в интерактивном режиме. Однако в настоящее время корпорации используют все больше тонких клиентов и, следовательно, имеют больше выделенных серверов для работы в сети, и в этих случаях установка без вывода сообщений также важна. Лучшее решение - отправить весь MSI обратно его поставщику и заставить его это исправить. Посмотрите мой довольно частый список распространенных проблем проектирования с файлами MSI производителя. Вам не нужно слишком много этих ошибок, прежде чем MSI должен быть отправлен обратно.