Развертывание SCCM MSI завершается неудачно с 0x87D00324

У меня есть MSI, созданный WIX, который можно запускать локально от имени администратора без ошибок. Но при развертывании через SCCM в качестве развертывания приложения, импортированного из MSI, отображается в центре программного обеспечения как сбойный код. 0x87D00324. В любом случае фактическая установка завершается успешно (файлы и записи реестра создаются должным образом, а приложение загружается).

Ошибка SCCM предполагает, что продукт не определяется после установки. При установке вручную с использованием той же командной строки, что и SCCM, настроен для использования (msiexec /i [msi goes here] /qn), Центр программного обеспечения показывает приложение как установленное, указывая на правильность правил обнаружения - обнаружение настроено на поиск установленного кода продукта. AppEnforce.log Следы предполагают, что происходит следующее:

• SCCM устанавливает MSI без ошибок
• После установки пытается обнаружить MSI
• Не удается обнаружить, помечает развертывание как сбой

MSI настроен для установки для всех пользователей (ALLUSERS=1 как свойство MSI, а не в командной строке) и требует повышения прав для запуска. Задание SCCM настроено как «Установить для системы» и «Только когда ни один пользователь не вошел в систему» ​​и нацелен на определенные машины, а не на пользователей.

При включенном ведении журнала MSI на уровне машины есть некоторые различия в выводе журнала, которые, как я полагаю, могут способствовать:

• Установка, выпущенная SCCM, имеет запись в журнале: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1' хотя неясно, что вызывает это
  • Это происходит, даже если ALLUSERS = 1 предоставляется в качестве аргумента командной строки для msiexec - как «Добавление АЛЛЮЗЕРОВ ...», затем «Удаление АЛЛЮЗЕРОВ ...» несколькими строками позже.
• В ProductPublish запись шага / журнала имеет Assignment значение 0 при установке через SCCM (эквивалентно Per User, согласно документации), но 1 при установке вручную (эквивалентно Per Machine)
• При установке SCCM создаются три журнала MSI, а не один журнал, как в случае вручную
  • Один показывает, что MSI вызывается с ADVERTISE действие
  • Тот, который, кажется, не звонит msiexec вообще, но это, возможно, оставшаяся часть ADVERTISE запись действия в другой файл по какой-то причине
  • MSI вызвал с пустым действием (которое в журнале отображается как действие INSTALL)

После установки, Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct имеет разные результаты для двух методов установки:

• Установлено через SCCM, нет записи для нового приложения - я предполагаю, поэтому SCCM считает, что приложение не установлено
• Установленное вручную новое приложение появляется с правильными данными

Оба метода показывают приложение как установленное при запросе через wmic product get.

Клиент: Windows 10 Enterprise, клиент SCCM 5.0.0.8577.1115

Сервер: SCCM 1710 (5.0.0.8577.1115)

Обновление от 12 апреля 2018 г., дополнительная информация:

• Работа SCCM работает над некоторые машины, но между ними нет очевидной общности
• Задание SCCM можно навсегда зафиксировать на данном компьютере с помощью pstools для запуска MSI как СИСТЕМЫ - если это сделано один раз, удаление MSI вручную, а затем переустановка через SCCM работает и обнаруживает правильно (это, очевидно, бессмысленно, но интересный результат)
• Ведение журнала на отказавших машинах указывает на то, что действия выполняются в контексте пользователя, а не в контексте каждой машины.
  • Using cached product context: User assigned for product: 6176BC215761514458869E9B9ABB08BC
• При регистрации на неисправных машинах отображается количество, кратное приведенной выше строке, в то время как при регистрации на рабочих машинах, похоже, встречается множество кодов продуктов, все в контексте машины.
• После установки через SCCM в неисправном состоянии единственное очевидное отличие реестра - против HKLM\Software\Classes\Installer\Products\[[Product Code]]\AdvertiseFlags, который 0x180 в неисправном состоянии и 0x184 в проходящем состоянии
• Наша команда разработчиков предполагает, что сбои начались, когда для задания была включена замена, хотя я не могу подтвердить, верно ли это для всех сбоев.

Что может вызвать разницу в поведении задания SCCM и ручной установки? Что может привести к запуску задания SCCM в контексте пользователя, даже если оно выглядит как СИСТЕМА и настроено на установку для системы?