Я работал с определенным .msi (AppleApplicationSupport.msi). Я установил его двумя разными способами, которые, как я думал, будут эквивалентными. Однако результаты различаются следующим образом.
Установка с помощью psexec -i -s cmd командная строка и запуск msiexec /i AppleApplicationSupport.msi приводит к желаемому результату:
Создание типа развертывания MSI и его установка с помощью клиента SCCM дает следующие результаты:
gwmi -Class Win32_Productоднако, бегущий $app.Uninstall() не удаляет его.Я думал, что установленный для системы тип развертывания MSI эквивалентен запуску msiexec из psexec -i -s cmd командная строка. Очевидно, это не одно и то же.
Что именно делает клиент SCCM при установке типа развертывания MSI Technology для системы? Могу ли я воспроизвести эту операцию без участия SCCM?
Выполняет ли клиент SCCM установщик типа развертывания Script Installer действительно эквивалентно вызову msiexec из psexec -i -s cmd? Другими словами, для типов развертывания установщика скриптов следует ожидать паритета между msiexec запускается клиентом SCCM и msiexec бежать от psexec -i -s cmd?
Добавлено после ответа kce:
- Что именно делает клиент SCCM при установке типа развертывания MSI Technology для системы? Могу ли я воспроизвести эту операцию без участия SCCM?
Насколько мне известно, клиент SCCM запускает любую строку установки, указанную в типе развертывания, тем не мение он выполняет его в контексте NT AUTHORITY \ SYSTEM. Вы можете приблизить, но не дублировать установку, выполнив ту же строку установки из учетной записи, которая является членом BUILTIN \ Administrators. MSIEXEC может быть запущен как 32-битный или 64-битный процесс в зависимости от того, установлен ли вы флажок «Запускать установку и удалить программу как 32-битный процесс на 64-битных клиентах».
- Действительно ли выполнение клиентом SCCM установщика типа развертывания Script Installer эквивалентно вызову msiexec из psexec -i -s cmd? Другими словами, для типов развертывания установщика сценариев следует ожидать паритета между msiexec, запущенным клиентом SCCM, и msiexec, запущенным из psexec -i -s cmd?
Хммм. Хороший вопрос. Клиент должен просто запустить строку установки, но для меня не было бы ужасно удивительно, если бы она произвела более глубокую и темную магию. Единственное, что я могу придумать в вашей ситуации, которая может вызвать разницу, - это разрядность процесса, в котором вы запускаете установщик. Я думаю, что клиент SCCM почти всегда использует 64-разрядную версию, но cmd.exe 32-разрядный, верно?
Взгляни на мой ответь здесь для других общих советов по решению проблем с установкой программного обеспечения.
Удачи.
В дополнение к этому произведению искусства, ответ от @kce, единственные скудные, упрощенные вещи, которые я должен добавить, это
В общем, я избегаю «приложений», если я не вынужден иметь с ними дело, что обычно происходит при создании развертывания App-V. В противном случае я придерживаюсь пакетов, они не доставляют головной боли, как вы видели или увидите.
В SCCM я создал пакет для своих файлов .msi так же, как и для любого другого установщика. например, kce сказал, что он устанавливается под системной учетной записью, однако, когда я создаю пакет, а не использую его обработчик msi по умолчанию, у меня есть более тонкий контроль над строкой установки, которую он запускает, например msiexec /i "my.msi" /qb /v по сравнению с любым значением по умолчанию. Мои приложения, по сути, всегда появлялись в разделе «Добавить / удалить», где они бы появились, если бы я установил их вручную. Теоретически да, тип развертывания приложения SCCM для .msi должен работать фантастически, но на практике использование чего-то другого может дать лучшие результаты. Поскольку приложения являются новыми для этой версии SCCM, вероятно, есть некоторые проблемы, которые необходимо решить.
Если вы действительно хотите узнать, связано ли это с учетной записью установки, используйте переключатель psexec для запуска команды под системной учетной записью.