Share via

Configuration Item PowerShell Script Returns Boolean False but Always Evaluates as Compliant in MECM

Dan Kingsbury 20 Reputation points
2026-01-22T03:11:33.1366667+00:00

Hi everyone,

I’m running into a Configuration Manager (MECM) compliance issue that I can’t seem to resolve despite extensive testing, and I’m hoping someone can spot what I’m missing.

Scenario

I have a Configuration Item that uses a PowerShell discovery script to evaluate compliance based on the number of local user profiles on a device.

  • ≤ 5 profiles → Compliant

> 5 profiles → Non-compliant (should trigger remediation)

The logic is simple and works correctly when run manually.

$profileThreshold = 5

$excludedProfiles = @('Default','Default User','Public','Administrator','WDAGUtilityAccount')

# --- Get all local user profiles (non-special, non-loaded) safely into a single array ---

$profiles = @( Get-CimInstance Win32_UserProfile |

Where-Object {

-not $_.Special -and

-not $_.Loaded -and

($excludedProfiles -notcontains $_.LocalPath.Split('\')[-1])

} )

# --- Determine compliance ---

if ($profiles.Count -le $profileThreshold) {

# 5 or fewer profiles → compliant

$true

} else {

# More than 5 profiles → non-compliant

$false

}

When I run the script manually I confirm that the detection script evaluates to a false boolean:

PS C:\windows\system32> $output = & ".\Profile_Discovery_v2.ps1"

PS C:\windows\system32>

PS C:\windows\system32> $output

False

PS C:\windows\system32> $output.GetType().Name

Boolean

PS C:\windows\system32>

So the script is returning exactly one Boolean value, and False is correct for this device (it has more than 5 profiles).

CI Configuration

  • Setting type: Script
  • Data type: Boolean
  • Compliance rule:
    • Rule type: Value
    • Operator: Equals
    • Expected value: True
  • “Remediate noncompliant rules when supported” is enabled
  • CI is deployed to a test device collection
  • Machine Policy Retrieval and Compliance Evaluation cycles have been forced multiple times

Problem

Despite the script returning False (Boolean):

  • The device always reports Compliant
  • Remediation never runs
  • Changing the compliance rule (True vs False) has no effect

Logs Checked

  • CIAgent.log (shows CI evaluation but still resolves to Compliant) log attached. CIAgent.txt
  • DCMAgent.log Shows messages regarding co-management not allowing baselines. However, I've determined that I'm not comanaged, but MDM coexistence. I was also checked the option on the baseline to apply even for co-managed clients.

No script execution errors are reported.

Is there a known issue or nuance with Boolean-returning discovery scripts in Configuration Items that could cause MECM to always evaluate them as compliant, even when the script returns False?

Are there additional client-side logs or specific CI settings I should be checking to understand why the Boolean result is being interpreted incorrectly?

Any insight would be greatly appreciated — this one has me completely stuck.

Thanks in advance.
Moderator note: Moved from System Center Service Manager

Microsoft Security | Intune | Configuration Manager | Other
0 comments No comments
{count} votes

Answer accepted by question author
  1. Sherry Kissinger 5,626 Reputation points
    2026-01-23T20:00:13.2233333+00:00

    <fyi, I do not work for Microsoft, I'm just another admin like you>

    Years and years ago, I defaulted to having my powershell scripts within CIs to evaluate for compliant or non-compliant based on a string. like...

    Write-host "Complaint"

    and the string 'Compliant' means it is compliant, vs. $true or $false.

    This is because although I personally never experienced it, on a different team, they found that based on some weird combination of Operations System and possibly what Powershell was installed, what they found was that SOMETIMES (not always, but sometimes), if they asked for a $true $false, what was actually submitted was a 1 or 0 (as a string, not boolean); so of course it was "non-compliant' and would trigger the remediation script.

    That was YEARS ago, but since that knowledge, I've always used a string in a CI for compliant/non-compliant, not $true/$false.

    For fun, recreate your CI using string, and have it spit out a write-host "whatever means compliant", and test for that.

    Bonus: with some 'complicated SQL", I also love doing strings...because of the box spits out anything other than 'Compliant', I can (with complicated sql) see what that non-compliant reason was. In your case, you could spit out...

    # More than 5 profiles → non-compliant

    write-host [string]$profiles.Count

    }

    =================

    OPTIONALLY

    Based on that specific script you have, instead of Boolean, make it be Integer, and the "what means compliant" is Less than 5

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.