You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SPSUpdate: harmonize Boolean config switches to accept 1/0 - #77
Harmonizes the type handling of every Boolean switch in the configuration so they all behave the same way, after a CA-GIP operator hit Configuration property 'Reboot.Enable' must be a Boolean ($true or $false), not '1'. when setting Reboot.Enable = 1.
Root cause: the Reboot, Remoting and Execution switches enforced a strict -isnot [bool] guard (rejecting 1), while the older flags (Binaries.ProductUpdate, Binaries.ShutdownServices, MountContentDatabase, UpgradeContentDatabase, SideBySideToken.Enable) had no guard and were coerced in Boolean contexts — so 1 worked on those, but so did a typo like 'false' (which evaluates to $true).
Change:
New public helper ConvertTo-SPSConfigBoolean (validate + normalize to [bool]): accepts $true/$false and the integers 1/0; throws a clear, property-named error on any other value (out-of-range integer, string such as '1'/'yes'/'false', $null). Only genuine integer types are accepted for the 1/0 form, so the [bool]'false' = $true footgun is avoided.
Applied to all nine Boolean config switches in Get-SPSUpdateConfiguration, so each one now accepts $true/$false/1/0 and rejects everything else. This also hardens the previously unguarded flags against typos.
Updated the example CONTOSO-PROD.example.psd1 comments to note that 1/0 are accepted.
Validation: PSSA 0 warning/error; Pester 310/0/1 (+11 new helper unit tests). End-to-end check via Get-SPSUpdateConfiguration confirms 1→$true, 0→$false, 2/'yes'→throw.
Added an entry to the change log under the Unreleased section of the
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
Added/updated documentation and descriptions where appropriate?
Add a shared ConvertTo-SPSConfigBoolean helper that validates and normalizes
every Boolean configuration switch to [bool]: it accepts a real Boolean or the
integers 1/0 and throws a clear, property-named error on anything else.
Previously the Reboot/Remoting/Execution switches enforced a strict [bool] and
threw on 1, while the older flags coerced any truthy value (so 1 worked but a
typo like 'false' silently became $true). All nine switches now behave the same.
Co-authored-by: Copilot <[email protected]>
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 08f60cb. Test-SPSUpdateReadiness.ps1 now normalizes both Reboot.Enable and Remoting.AllowFallback through ConvertTo-SPSConfigBoolean, so the pre-flight check shares the runtime contract: 1/0 are accepted (and AllowFallback = 1 enables the fallback probes), while an invalid value is reported as a readiness FAIL with the helper's message.
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 08f60cb. wiki/Configuration.md now carries one shared Boolean switches rule listing all nine switches and stating they accept $true/$false or 1/0, with anything else rejected. The example psd1 comments were already updated to match.
- Test-SPSUpdateReadiness normalizes Reboot.Enable and Remoting.AllowFallback
through ConvertTo-SPSConfigBoolean so the pre-flight check shares the runtime
contract (1/0 accepted; a bad value becomes a readiness FAIL).
- ConvertTo-SPSConfigBoolean accepts every integral type (byte/sbyte/int16/uint16/
int32/uint32/int64/uint64) valued 0/1, not just four, matching its documented API.
- Document the shared 1/0 Boolean rule for all nine switches in wiki/Configuration.md.
Co-authored-by: Copilot <[email protected]>
Reject invalid explicit Reboot.Enable values during readiness checks
src/Test-SPSUpdateReadiness.ps1:349
An invalid explicit Reboot.Enable is silently treated as $false here. The readiness check can therefore exit successfully (and skip the reboot status-store warning), even though Get-SPSUpdateConfiguration will reject the same configuration at runtime. Distinguish an omitted optional value from a present invalid value and record the latter as a readiness failure, as the Remoting.AllowFallback check does below.
🧠 Review effort: Balanced
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
Distinguish an omitted Reboot.Enable (legitimate default $false) from a present
but invalid value: the latter is now recorded as a readiness FAIL (matching the
Remoting.AllowFallback check and the runtime config loader) instead of being
silently treated as disabled.
Co-authored-by: Copilot <[email protected]>
Addressed the remaining 🔵 finding in 50eb144: Test-SPSUpdateReadiness.ps1 now distinguishes an omitted Reboot.Enable (legitimate default $false, no finding) from a present-but-invalid value, which is recorded as a readiness FAIL — matching the Remoting.AllowFallback check and the runtime loader. PSSA 0, Pester 312/0/1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request (PR) description
Harmonizes the type handling of every Boolean switch in the configuration so they all behave the same way, after a CA-GIP operator hit
Configuration property 'Reboot.Enable' must be a Boolean ($true or $false), not '1'.when settingReboot.Enable = 1.Root cause: the
Reboot,RemotingandExecutionswitches enforced a strict-isnot [bool]guard (rejecting1), while the older flags (Binaries.ProductUpdate,Binaries.ShutdownServices,MountContentDatabase,UpgradeContentDatabase,SideBySideToken.Enable) had no guard and were coerced in Boolean contexts — so1worked on those, but so did a typo like'false'(which evaluates to$true).Change:
ConvertTo-SPSConfigBoolean(validate + normalize to[bool]): accepts$true/$falseand the integers1/0; throws a clear, property-named error on any other value (out-of-range integer, string such as'1'/'yes'/'false',$null). Only genuine integer types are accepted for the1/0form, so the[bool]'false' = $truefootgun is avoided.Get-SPSUpdateConfiguration, so each one now accepts$true/$false/1/0and rejects everything else. This also hardens the previously unguarded flags against typos.CONTOSO-PROD.example.psd1comments to note that1/0are accepted.Validation: PSSA 0 warning/error; Pester 310/0/1 (+11 new helper unit tests). End-to-end check via
Get-SPSUpdateConfigurationconfirms1→$true,0→$false,2/'yes'→throw.This Pull Request (PR) fixes the following issues
Task list
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).