When working with PowerShell providers, it’s common to pass Boolean values — for example, enabling a simple debug flag. Unfortunately, this isn’t as straightforward as it should be.
The Problem
In practice, PowerShell probe and write action modules always cast input parameters as strings, regardless of whether the configuration element is defined as Boolean or String.
This means that values like true, false, 1, or 0 are all treated as strings. When you attempt to handle them as Booleans in your script, they will always evaluate to true.
The result? Unexpected behavior that looks like a bug in your management pack.
The Workaround
Until this is fixed in the product, the safest approach is to avoid typing the script parameter directly. Instead, convert it explicitly to Boolean after the param block:
param($debugFlag)
$debugFlag = [System.Convert]::ToBoolean($debugFlag)This approach ensures:
- Boolean values (
true/false) are handled correctly in the script. - Operators see the proper default values in the console.
- Overrides present a meaningful True/False selector in the interface.
Update (09/02/2015): This issue applies not only to Booleans, but also to Integer and Double values.
Digging Deeper
Curious about why this happens, I looked into the Windows Library. The answer lies in the schema definition.
PowerShell probe modules use the NamedParametersType element from Microsoft.Windows.PowerShellSchema. Here’s the relevant snippet:
<SchemaType ID="Microsoft.Windows.PowerShellSchema" Accessibility="Public">
<xsd:complexType name="NamedParametersType">
<xsd:sequence>
<xsd:element name="Parameter" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="xsd:ID" />
<xsd:element name="Value" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</SchemaType>Notice that the Value element is defined as xsd:string. This design forces every parameter value — Boolean, Integer, Double — to be cast as a string.
The Real Fix
The long-term solution is for Microsoft to update the schema to allow multiple value types. By supporting type choices, developers could properly cast parameters without relying on workarounds.
Since this schema lives in the Microsoft Windows Library, the responsibility for fixing it lies with Microsoft