Устранение неполадок при оценке приложений в SCCM2012

Хорошо, это будет длинный пост, но здесь есть хорошие вещи.

Во-первых, GUID для установленного программного обеспечения находятся в следующих местах ...

Для 32-битной Windows и 64-битного программного обеспечения в 64-битной Windows:
HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Удалить

Для 32-битного программного обеспечения в 64-битной Windows:
HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ Windows \ CurrentVersion \ Удалить

Проблема, с которой вы столкнулись, заключается в том, что строка GUID неверна. MSI, который вы загрузили из Adobe, является версией для американского английского языка, поэтому 1033 в третьей части строки GUID (1033 - это кодовая страница ANSI для клавиатур США).

Однако установщик EXE - это версия MUI с GUID {AC76BA86-7AD7-FFFF-7B44-AB0000000001} - обратите внимание на FFFF вместо 1033, что означает, что он многоязычный.

В методе обнаружения необходимо добавить предложение OR, чтобы он распознавал любой GUID как допустимую установку.

Вы также должны знать о двух подводных камнях:

1) Вы должны указать номер версии в вашем методе обнаружения. Все версии Reader 11 имеют одинаковый GUID (т.е. 11.0.1 совпадает с 11.0.7), поэтому ваш метод обнаружения будет возвращать ложное срабатывание, если пользователи используют более старую версию.

2) Если вас интересуют исправления безопасности для Reader, то вы должны знать, что Adobe выпускает свои исправления только для версии MUI. Вы не можете "обновить", скажем, с 11.0.1 до 11.0.7 с их MSI, не выполняя деинсталляцию / переустановку всего продукта. Если вы попытаетесь, он просто скажет вам, что продукт уже установлен (потому что GUID тот же).

Здесь верный способ управления Adobe Reader с помощью SCCM: вам нужно два типа развертывания в вашем приложении.

1) Настройте MSI 11.0.0 так же, как у вас уже есть (убедитесь, что для метода обнаружения указан номер версии 11.0.00 - не используйте просто GUID), сохраните и закройте его.

2) Вернитесь и добавьте еще один тип развертывания. На этот раз выберите Script Installer в качестве типа (SCCM не обрабатывает файлы MSP изначально). Укажите его на свой файл MSP и используйте msiexec / update (вместо обычного msiexec / i) в качестве командной строки. Для метода обнаружения используйте тот же GUID, но 11.0.07 (или любой другой) в качестве версии. Укажите первый тип развертывания в качестве зависимости. Затем убедитесь, что патч имеет более высокий приоритет в списке. Теперь сохраните и снова закройте.

Теперь, когда клиент, у которого не установлен считыватель, запрашивает приложение, оба будут установлены. Если у человека уже установлена ​​версия EXE, она будет исправлена. Если он уже исправлен, он будет отображаться как уже установленный.

Итак, после небольшого исследования и осознания того, что именно Adobe Flash player меня заводит, я сформулировал возможную гипотезу. Насколько я могу судить, SCCM смотрит в следующее расположение WMI:

Namespace: root\CCM\CIModels
Class: CCM_MSIProduct

Судя по тому немногому, что я знаю о WMI, он создается клиентом SCCM, что имеет странный смысл, когда вы думаете о том, как работает SCCM.

Я получил это местоположение из «средства мониторинга развертывания», которое вы можете получить в Набор средств System Center 2012 Configuration Manager. Если вы посмотрите в область развертываний и вкладку «Применение», вы можете посмотреть на DiscoverySourceXML, чтобы увидеть, что вернуло обнаружение.

Я узнал об этом только сегодня, поэтому еще не смог полностью протестировать. Это место может быть просто хранилищем результатов для процесса обнаружения приложений. Пока этого достаточно, чтобы сообщить мне, какие коды продуктов работают с процессом оценки приложения SCCM.

Мне действительно нужен SCCM-разработчик, чтобы это увидеть и исправить.

Дополнительные вещи

Скрипт Powershell для вывода списка объектов WMI:

Get-WmiObject -Namespace root\ccm\CIModels -Class CCM_MSIProduct | Sort-Object ProductName |Format-Table ProductName,ProductCode,ProductVersion

Где я могу увидеть, что запрашивает метод обнаружения и что он возвращает?

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

Что бы я сделал, так это найти тестовый компьютер (или, желательно, виртуальную машину, чтобы вы могли использовать моментальные снимки), который находится в состоянии, нарушающем вашу логику обнаружения, запустите ProcMon, запустите цикл оценки развертывания приложений и посмотрите, что вы найдете.

Где система ищет этот GUID при выполнении обнаружения «установщик Windows»?

Если мое чтение MSDN правильный MSI регистрирует ProductCode в HKLM\Software\Classes\Installer\Products. Разумным предположением является то, что обнаружение приложений проверяет это местоположение, вы снова можете подтвердить это с помощью ProcMon.

Что касается вашей проблемы, когда исполняемый установщик Adobe Reader нарушает вашу логику обнаружения, я провел небольшое тестирование в своей «лаборатории» (т. Е. На моей рабочей станции) и смог воспроизвести вашу проблему.

Я думаю, что все исполняемые файлы Adobe Reader распаковывают и запускают установщик MSI.

Если вы посмотрите на содержимое setup.ini вы можете видеть, что все, что делает исполняемый файл, - это запускает установщик MSI:

[Startup]
RequireOS=Windows 2000
RequireMSI=3.0
RequireIE=6.0.2600.0

[Product]
msi=AcroRead.msi

В любом случае, установщик правильно зарегистрировал ProductCode, поэтому, если это все, что вы используете для логики обнаружения, нет заметной разницы между двумя методами установки. Однако, если вы сравните ключи реестра для исполняемого установщика и установщика MSI, вы увидите некоторые различия:

Из исполняемого установщика:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010]
"ProductName"="Adobe Reader XI (11.0.06)"
"PackageCode"="08610D4D4ABC0E74BB0257B5EDD58107"

Из установщика MSI:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA7DA73301B744BA0000000010]
"ProductName"="Adobe Reader XI (11.0.06)"
"PackageCode"="26A6583616073E04583DBCA6F0289EEB"

В PackageCode отличается. Источники установки тоже должны быть разными.

Из загруженного пользователем исполняемого установщика:

C:\ProgramData\Adobe\Setup\{AC76BA86-7AD7-1033-7B44-AB0000000001}\

Из установщика MSI, развернутого в SCCM:

C:\Windows\ccmcache\6f\

Обратите внимание, что развернутая версия SCCM была получена из локального кэша CCM.

Вы можете добавить их в свою логику обнаружения или требования, чтобы исправить это условие.

В этом есть смысл, sccm не будет определять, когда приложения устанавливаются вне его. Он использует таблицу wmi для отслеживания, поэтому, если кто-либо когда-либо удалит репозиторий wmi для «лечения» коррупции, он переустановит все пакеты sms, которые требуются для этой рабочей станции / пользователя. В 2007 году таблица wmi называлась SMS_InstalledSoftware, хотя я не могу найти ее название для '12.

Я не занимаюсь установкой установщика Windows, но знаю, что есть таблица wmi под названием Win32_Product который содержит руководства по установке, которые вы найдете в разделе «Установка и удаление программ», я предполагаю, что он выглядит там, хотя я могу ошибаться. Недостатком является то, что если они установят другую версию msi (то есть другой guid), возможно, это не будет отображаться в вашем обнаружении.

Иногда я провожу инвентаризацию программного обеспечения в .exe, чтобы узнать, установлен ли он уже у кого-то, и если да, то какой версии. Я не могу обойти людей, которые берут на себя установку приложений за пределами sccm, но это политика, и на самом деле sccm не для этого.

Я знаю его старую, но не смог удержаться от добавления своей статьи, особенно о Win32_Product, так как это может иметь негативные последствия!

Я не могу комментировать ответ @Dotknuckle выше, поэтому мне пришлось написать совершенно новый ответ. Win32_Product - плохая идея и требует больше времени, потому что он повторно регистрирует каждый прочитанный MSI-файл. http://www.itninja.com/link/why-win32-product-is-bad-news

Что касается SMS_InstalledSoftware, он также существует в SCCM 2012 и находится в пространстве имен root \ cimv2 \ sms, он немного безопаснее, чем Win32_Product, а также быстрее.

То же самое, вероятно, относится к классу CCM_MSIProduct в отношении того, почему он быстрее. Я использую SMS_InstalledSoftware, так как он возвращает больше информации.

Я использовал свои собственные сценарии обнаружения в PowerShell, которые в основном делают что-то вроде этого.

$SPSS22 = Get-WmiObject -namespace Root\cimv2\sms -class SMS_InstalledSoftware -filter "ARPDisplayName LIKE '%SPSS Statistics%' AND ProductVersion='22.0.0.0'"
If($SPSS22){return $true}

Иногда я получаю приложение не обнаружено; даже журналы говорят, что он установлен без проблем. Но затем он говорит, что не обнаружен прямо внизу, где он говорит, что вернулся код ошибки 0; успех.

Перейдите в раздел «Установка и удаление программ» или выполните Windows-R и введите appwiz.cpl и посмотрите, установлено ли приложение. Если он отображается, запишите точное имя, которое отображается в программах добавления / удаления. Убери это. Если он быстро удаляется, возникают более серьезные проблемы. Что вам нужно сделать дальше, это открыть редактор реестра и нажать F3, чтобы выполнить поиск. Введите имя приложения, как оно было указано в добавлении / удалении. Как только вы начнете находить его в реестре, вам будут удалены ключи или значения с зависимостями. Вы удаляете ключи, если они есть в реестре где-то вроде «Удалить», «Установить», «Продукт», «Функция». Излишне говорить, что будьте очень осторожны с тем, что вы удаляете, вы можете сломать свой компьютер. После этого просто выполните еще один поиск, чтобы убедиться, что вы все удалили. Теперь попробуйте установить снова через системный центр, если он установится, то УРА! Если это не так, то есть еще некоторые основные ключи или значения реестра, которые необходимо удалить.