Repository navigation
fix(repair): Repair-IntuneScript takes -Context, -Architecture and -EnforceSignatureCheck - #16
Conversation
…nforceSignatureCheck Repair-IntuneScript ran its analysis with Test-IntuneScript's defaults for the context, the architecture and the signature check, because it had no parameter to pass on for any of them. A script deployed to the 64-bit host in system context was repaired as the inferred 32-bit user-or-system script, so its findings, its fixes and the Remaining count could disagree with Test-IntuneScript run for the deployment. The command takes the three parameters now, with the same values and defaults as Test-IntuneScript, and hands them to both analyses: the one that finds the fixes and the one that counts what is left after the write. Help and README updated; MAML rebuilt.
fadwen
left a comment
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| $testSplat = @{ | ||
| Path = $file; ScriptType = $ScriptType; Context = $Context; Architecture = $Architecture | ||
| } | ||
| if ($EnforceSignatureCheck) { $testSplat.EnforceSignatureCheck = $true } |
There was a problem hiding this comment.
Added to the splat only when set: Test-IntuneScript resolves an unset switch through the directive and the settings file, and a literal $false here would override both.
| # the signature check enforced | ||
| $body = "Get-ItemProperty HKCU:\Software\Contoso`nTest-Path `$env:USERPROFILE\x`nexit 1" | ||
| $path = New-TestScript 'Remediations\F\Detect.ps1' $body -Bom | ||
| $asUser = Repair-IntuneScript -Path $path -Context User -IncludeRule IslContextIssue |
There was a problem hiding this comment.
Limited to IslContextIssue because the rule gives one note under User (the Entra-join reminder) in place of the two System errors, so the total counts alone would be equal and prove nothing; the rule on its own gives 1 against 2.
| It 'counts the architecture the caller names, not the inferred one, in Remaining' { | ||
| # x86 is the portal default for a remediation, so the 32-bit System32 finding is there | ||
| # under Auto and gone under -Architecture x64 (REM-PROBE-SYS32) | ||
| $body = "Start-Process C:\Windows\System32\msiexec.exe -Wait`nexit 0" |
There was a problem hiding this comment.
A remediation infers x86, the portal default, where System32 is redirected (REM-PROBE-SYS32); -Architecture x64 is the native host and the finding goes. The third assertion compares the two repairs, so a change in the rule's other findings cannot hide a pass-through regression.
1 participant
Summary
Repair-IntuneScriptran its analysis withTest-IntuneScript's defaults for the context, the architecture and the signature check, because it had no parameter to pass on for any of them. A script deployed to the 64-bit host in system context was repaired as the inferred script, so its findings, its fixes and theRemainingcount could disagree withTest-IntuneScriptrun for the deployment. The command takes-Context,-Architectureand-EnforceSignatureChecknow, with the same values and defaults asTest-IntuneScript, and hands them to both analyses: the one that finds the fixes and the one that counts what is left after the write.Changes
Public/Repair-IntuneScript.ps1. The three parameters, passed through in the splat both analyses share.-ContextchangesRemainingthe way it changesTest-IntuneScript's count (two errors forHKCU:andUSERPROFILEunder System, one note under User);-EnforceSignatureCheckadds the unsigned-script error for a Win32 detection;-Architecture x64removes the 32-bit System32 finding that the remediation default reports, andRemainingequalsTest-IntuneScript's count for the same value in both cases.Verification