Назад | Перейти на главную страницу

Разница между вызовом msi с помощью «Invoke-WmiMethod» (через cmd-файл) и установкой непосредственно на сервере

Запустите сервер, чтобы установить msi; журналы событий были чистыми, и все прошло успешно; но ключевой файл в каталоге bin все еще старый. Позже попытался установить его, сделав двойной щелчок по RDP на сервере; установка прошла успешно, и файлы bin обновлены.

-> Перезагрузка не требовалась и не использовалась в обоих случаях. -> почему это происходит? а где я могу найти больше логов? -> Сервер Windows 2008 R2

В наиболее вероятная причина в том, что вы запустили MSI тихо через WMI и интерактивно при входе на сервер (за исключением того, что установка вообще не запускалась). Это то, что вы на самом деле сделали? Есть и другие причины, которые могут вызвать ту же проблему. Нам нужно будет увидеть содержимое update.cmd файл, чтобы быть уверенным.

Чтобы сначала разобраться с тихой и интерактивной проблемой: есть разные последовательность установки внутри каждого файла MSI, и два наиболее важных из них:

  • UserInterfaceSequence - показывает пользовательский интерфейс для MSI, вы можете вводить данные и перемещаться между экранами, а также прерывать настройку.
  • InstallExecuteSequence - это фактическая последовательность установки, которая запускается при нажатии последней кнопки в последовательности пользовательского интерфейса.

Что происходит во время автоматической установки, так это то, что вся UserInterfaceSequence пропускается. Обычно это нормально и не должно вызывать проблем в правильно созданном пакете MSI. Однако иногда или на самом деле довольно часто в наши дни разработчик установки не вставляет все настраиваемые действия или сценарии, которые необходимо запустить во время установки, в последовательность автоматической установки, что приводит к неполной установке при автоматическом запуске. Хотя симптом, о котором вы сообщаете (файл не обновляется), не наиболее типичная для этой проблемы автоматической установки, она все еще является вероятной причиной. Другие причины могут включать неправильную командную строку или вмешательство WMI, о котором я не знаю. Я никогда не использую WMI для установки файлов MSI, так как есть многие другие способы запуска файлов MSI. Вот это другой поток, имеющий дело с альтернативами msiexec.exe развертывания (под капотом, я думаю, все эти разные способы называют Windows 32 API в стиле C).

Надлежащая поддержка тихая установка является абсолютное требование для MSI - он должен работать без вывода сообщений, иначе он не создан должным образом по определению. Но всегда есть способы сделать что-то неправильно, и все еще есть много пакетов, которые не соответствуют требованиям. Для корпоративное использование, тихая установка, как правило, единственная функция MSI, которая всегда используется. Это один из ключевые преимущества файлов MSI.

На профессиональном упаковщик приложений уровень мы находим способы справиться с этим в каждом конкретном случае. Часто прибегают к серьезному изменению файла MSI, чтобы убедиться, что все, что должно работать, работает. Для установки сервера часто это не стоит усилий, поскольку проще запустить установку в интерактивном режиме. Однако в настоящее время корпорации используют все больше и больше тонких клиентов и, следовательно, имеют больше выделенных серверов для работы в сети, и в этих случаях автоматическая установка не менее важна. Лучшее решение - отправить весь MSI обратно поставщику и доставить их почини это. Проверьте мой довольно специальный список общие проблемы дизайна с файлами MSI поставщика. Вам не нужно слишком много из этих ошибок, прежде чем MSI нужно будет отправить обратно.