When transitioning from SCCM 2007 to SCCM 2012 SP1, many administrators encounter the wbemErrTypeMismatch (0x80041005) error when attempting to use WQL queries in Global Conditions for application requirements. This typically occurs when trying to validate software installations like Firefox before deploying dependent applications (e.g., Adobe Flash Player).

The fundamental difference lies in how Global Conditions process WQL queries compared to Collection queries:

// Collection query (works)
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 "%Firefox%"

// Global Condition query (fails with 0x80041005)
SELECT ProductName FROM SMS_InstalledSoftware

Here's the proper way to implement this in SCCM 2012+:

1. Create a Global Condition:
   • Type: WQL Query
   • Namespace: root\cimv2\sms
   • Class: SMS_InstalledSoftware
   • Property: ProductName
   • WHERE clause: Leave blank

In your Application Deployment Type:

1. Add Requirement
2. Category: Custom
3. Condition: Select your Global Condition
4. Rule type: Value
5. Operator: Like
6. Value: *Firefox*

If you still encounter issues, consider these alternatives:

Registry Check Method:

HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox

File System Check:

File exists: C:\Program Files (x86)\Mozilla Firefox\firefox.exe

• Use WBEMTest to verify your query returns expected results
• Check %windir%\System32\wbem\Logs for detailed WMI errors
• Ensure the SMS Provider has proper permissions to access root\cimv2\sms

When deploying at scale:

• Limit wildcard searches (*Firefox*) when possible
• Consider using exact product versions for more precise targeting
• Combine multiple requirements with AND/OR logic for complex scenarios

In modern SCCM application deployment models, we frequently encounter type mismatch errors when transitioning from collection-based targeting to Global Conditions. The wbemErrTypeMismatch error (0x80041005) occurs when the data type returned by the WQL query doesn't match what SCCM expects to evaluate in the Requirement rule.

The key issue lies in how we structure our WQL query for the Global Condition. Unlike collection queries, Global Conditions need to return specific value types that can be evaluated by Requirements. Here's the correct approach:

SELECT ProductName FROM SMS_InstalledSoftware 
WHERE ProductName LIKE '%Firefox%'

Notice we specifically select only the ProductName field rather than using SELECT *. This ensures the query returns a string value that can be properly evaluated.

When creating the Global Condition in SCCM:

1. Set the Data Type to "String"
2. Use the namespace: root\cimv2\sms
3. Class name: SMS_InstalledSoftware
4. Property name: ProductName
5. Leave the WHERE clause empty in the Global Condition itself

In your Application Deployment Type's Requirements, create a rule that evaluates the Global Condition:

1. Select "Value" as the condition type
2. Choose your Global Condition
3. Set operator to "Like"
4. Enter "%Firefox%" as the value

Several factors can cause the type mismatch error:

1. Namespace issues: Ensure you're querying root\cimv2\sms, not just root\cimv2
2. Property selection: Only return the specific property you need to evaluate
3. Data type mismatch: Verify the Global Condition's data type matches the WQL query result

For more complex scenarios like version verification, use this structure:

-- Global Condition WQL:
SELECT ProductVersion FROM SMS_InstalledSoftware 
WHERE ProductName LIKE '%Firefox%'

-- Requirement Rule:
Value of [YourGlobalCondition] greater than or equal to "23.0.1"

These WQL queries execute during policy evaluation, so:

1. Avoid overly broad LIKE patterns
2. Consider creating hardware inventory classes for frequently checked software
3. Test query execution time using WBEMTest before implementing