When 'false' means $true
Recent customer question: "Why does it treat the boolean as 'true' when I explicitly entered 'false'?". This question is normally followed up by something like "This is obviously a bug since when I tell it 'true' works just fine."
Great real world example syntax that will exhibit this behavior would be setting a RecipientFilter to something like this:
Set-DynamicDistributionGroup MyDDG -RecipientFilter { UMEnabled -eq 'false' }
Clearly, the intent of this simple DDG RecipientFilter is to include only recipent objects where the UMEnabled boolean is set to "false". So why, then, after running this command does the RecipientFilter property contain this filter:
Get-DynamicDistributionGroup MyDDG | Format-List RecipientFilter
RecipientFilter : (UMEnabled -eq 'True' -and -not(Name -like 'SystemMailbox{*') -and -not(Name -like 'CAS_{*'))
Ignore the last part (which is just there to be sure we exclude system mailboxes and CAS monitoring/test mailboxes from the DDG automatically). The first part is the interesting bit. I've highlighted the REALLY interesting part in Red.
So why did it set it to 'True' even though you very explicitly told it to be 'False'?
Well, it's because you really told it to be True. It's true. Like most computerized versions of True and False, they're really represented as "False" (0) and "True" (anything not 0). And by telling it to be "False" you were really telling it to be "something not zero". The string representation of "False" is not the same as the Powershell token $false. In fact, based on the "anything not 0" definition just above, the string representation of "False" actually IS THE SAME as the powershell token $true.
Short version: Use $true to represent True and $false to represent False. Using strings "True" or "False" will only work if you're trying to evaluate for "True" (and then, only by coincidence!)
