Concordancia de tipo de consulta WQL de condición global SCCM (wbemErrTypeMismatch - 0x80041005)

Hemos estado manejando toda nuestra lógica de orientación para Paquetes (y ahora Aplicaciones) con Colecciones. Ahora que hemos pasado de SCCM 2007 a SCCM 2012 SP1, se recomendó que traslademos esa lógica al modelo del Programa de aplicación y la implementemos utilizando las Condiciones y requisitos globales. Esto tiene una serie de beneficios positivos: las colecciones se utilizan exclusivamente para la agrupación jerárquica o lógica, obtenemos una implementación de aplicaciones más fluida cuando se utiliza Supercedence y una lógica de detección mejorada.

Usaré el complemento Adobe Flash Player como ejemplo. Solo queremos implementar Adobe Flash Player Plugin en estaciones de trabajo que tengan instalado Firefox. Usando el modelo de Paquete-Programa SCCM 2007, crearíamos una Colección basada en una consulta WQL que contenía todas las estaciones de trabajo con Firefox instalado:

select *  from  SMS_R_System inner join SMS_G_System_SoftwareProduct
on SMS_G_System_SoftwareProduct.ResourceId = SMS_R_System.ResourceId
where SMS_G_System_SoftwareProduct.ProductName like "Mozilla Firefox"

Una vez que hayamos creado la Colección, implementaremos nuestro Paquete-Programa en su contra. Estoy tratando de replicar la misma lógica usando la lógica de Condiciones y requisitos globales del programa de aplicación. Todos mis intentos de construir mi condición global basada en consultas WQL resultan en un error wbemErrTypeMismatch ( 2147749893 (0x80041005)).

Ahora que las mejores prácticas recomiendan que mantengamos nuestra lógica de orientación incluida en la Aplicación, lo que debemos hacer es crear una Condición Global de consulta WQL apropiada y luego podemos evaluarla usando los Requisitos de la Aplicación.

Comencemos con la consulta WQL. Usé Scriptomatic para volcar todo en la SMS_InstalledSoftwareclase WMI que es parte del root\cimv2\smsespacio de nombres. Estoy razonablemente seguro de que SMS_InstalledSoftware es el mejor lugar para ejecutar consultas al intentar evaluar si algo está instalado o no, ya que Win32_Product es solo para el software instalado de Windows Installer.

Encuentro el siguiente objeto relacionado con Firefox:

ARPDisplayName: Mozilla Firefox 23.0.1 (x86 en-US)
ChannelCode: 
ChannelID: 
CM_DSLID: 
EvidenceSource: CPXCCCCCCXCXCXCXXXXXCXXXXX

InstallDirectoryValidation: 4
InstalledLocation: C:\Program Files (x86)\Mozilla Firefox
InstallSource: 
InstallType: 0
Language: 0
LocalPackage: 
MPC: 
OsComponent: 0
PackageCode: 
ProductID: 
ProductName: Mozilla Firefox 23.0.1 (x86 en-US)
ProductVersion: 23.0.1
Publisher: Mozilla
RegisteredUser: 
ServicePack: 
SoftwareCode: mozilla firefox 23.0.1 (x86 en-us)
SoftwarePropertiesHash: 63896ed23146ec91dbc763b45c127ba31216e2f9d657a87953440d30b7f306bc
SoftwarePropertiesHashEx: 67c2ecc42f0e0b9da6ee55bc0dea67a4d90b9e8452c9fdb25db57d4891698f25
UninstallString: "C:\Program Files (x86)\Mozilla Firefox\uninstall\helper.exe"
UpgradeCode: 
VersionMajor: 2147483647
VersionMinor: 2147483647

Ejecutar el WQL contra la propiedad ProductName parece ser una buena manera de hacerlo. Si me encuentro SELECT * FROM SMS_InstalledSoftware WHERE ProductName like '%Firefox%'con wbemtestel root\cimv2\smsespacio de nombres, obtengo lo siguiente:

Intentemos construir la Condición Global en SCCM a continuación:

Esto es completamente intuitivo, pero creo que lo entiendo correctamente. Las Condiciones globales solo configuran la parte condicional de toda la lógica del Programa de aplicación, no ninguna de la lógica evaluativa del Programa de aplicación. Por esa razón, no estoy haciendo nada en la cláusula WHERE. Esta Condición Global debe buscar en el root\cimv2\smsespacio de nombres la SMS_InstalledSoftwareclase y "devolver" la propiedad ProductName. Ahora debería poder evaluar los valores de esa propiedad con el requisito de tipo de implementación de mis aplicaciones, ¿verdad?

Una vez más, no entiendo cómo toda la lógica de Condición / Requisitos globales se mantiene unida o simplemente es poco intuitivo, pero el Requisito anterior debería poder ver todas las Cadenas devueltas de la ProductNamepropiedad, evaluar si alguna de ellas contiene 'Firefox "y si es así, implemente Adobe Flash Player Plugin.

Lamentablemente no funciona. Casi todas las máquinas en la implementación devuelven el siguiente error:

2147749893 (0x80041005) Type Mismatch

Supongo que esto significa que Global Condition está devolviendo un tipo de variable diferente de la que estoy evaluando en mi Requisito, pero no tengo idea de cómo solucionarlo desde aquí. Intenté establecer el tipo de mi Condición global en booleano y establecer la cláusula WHERE ( Name like '%Firefox%'), pero esto produce el mismo error.

¿Cómo puedo replicar mi colección basada en consultas WQL utilizando la lógica de orientación de condición / requisitos globales del programa de aplicación? ¿Qué me estoy perdiendo aquí (aparte de apt-get)?

El cuadro de diálogo Condición global es probablemente la parte menos intuitiva de SCCM que he visto hasta ahora.

Prueba esto:

1. vuelva a crear su condición global de Firefox 2 de la misma manera, pero esta vez en el campo WQL Query Where Clause en la parte inferior, ponga: ProductName like "%Firefox%"

2. En la pestaña Requisitos del Tipo de implementación de su aplicación, use la Condición global de Firefox 2, pero cambie el Tipo de regla a Existencial

Esto es una conjetura calificada, ya que no tengo forma de probar esto, de manera práctica

Como WQL no tiene un operador de contención nativo, creo que el Containsoperador se trata como en PowerShell:

$referenceCollection -Contains $testValue

Si esta teoría es correcta, su lógica de requisito subyacente se ampliará a esto:

"Microsoft Firefox 23 (en-us)" -Contains "firefox"

Si el operando izquierdo de -Containsno es una colección, sino una sola instancia del mismo tipo que el valor de prueba (como en su ejemplo, dos cadenas), -Containsse trata exactamente como -eq.

Por lo tanto, "Microsoft Firefox 23 (en-us)" -Contains "firefox"siempre devolverá falso.

Yo personalmente usaría un script de PowerShell para esto en lugar de una consulta WQL. Mi powershell prácticamente haría exactamente lo mismo que el WQL que está haciendo (incluso consultando la misma clase WMI) pero funcionaría usando un booleean, por ejemplo

$Firefox = Get-WmiObject -namespace root\cimv2\sms -class SMS_InstalledSoftware -filter "ARPDisplayName LIKE '%Firefox%'"
if($Firefox){return $true}else{return $false}

Básicamente, esto devolverá verdadero si la consulta WMI devuelve un resultado y falso si no. Básicamente, puede usar la condición global en su aplicación en la línea de: Firefox 2 debe ser igual a verdadero. He hecho esto mucho ahora usando este método principalmente para elementos de configuración y métodos de detección de aplicaciones donde un MSI si no se usa.

Si quisieras seguir haciendo las cosas como están actualmente, entonces tendría que estar de acuerdo con @ 1.618 comentarios.