issue with powershell worklet claiming bracket is missing

  • 31 August 2021
  • 6 replies
  • 506 views
M

Hi, I am trying to make a worklet out of a powershell script I have to remove any unapproved Outlook plugins. I have this working fine from the command line, and I ran it through PSScriptAnalyzer too and everything seems to be working fine.


$scriptBlock = {



   $permittedAddIns = "Redemption.Addin","WorkSiteEmailManagement.Connect","imFileSite.Connect"



   # Registry paths to search

   $registryPaths = "Registry::HKEY_USERS\S-1-5-21-*\Software\Microsoft\Office\Outlook\Addins",

                    "Registry::HKEY_USERS\S-1-5-21-*\Software\Wow6432Node\Microsoft\Office\Outlook\Addins",

                    "HKLM:\SOFTWARE\Microsoft\Office\Outlook\Addins"

   # Build up a list of add-ins by searching the specified paths

   $addIns += ($registryPaths | ForEach-Object {Get-Item $_ | Get-ChildItem | Where-Object –Filter {($_.GetValue("LoadBehavior") -and $_.GetValue("LoadBehavior") -ne 0)}})



   write-Output $addins



   # Narrow down our list of add-ins to only those that don't match our permitted list

   $deniedAddIns = $addIns | Where-Object {$_.PSChildName -notin $permittedAddIns}



   # Loop through all of the denied add-ins, and set the LoadBehavior

   foreach ($addin in $deniedAddIns) {

       # If the current add-in's LB is already set to 0. Skip this one.

       if ($addin.GetValue("LoadBehavior") -eq 0) { continue }



       # Set the LoadBehavior to zero

       write-Output Set-ItemProperty –Path "Registry::$($addin.Name)" –Name "LoadBehavior" –Value 0 –WhatIf

   }

}



$results = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptblock



Write-Output $results



if ($results) {

    write-Output Exit 0

} else { write-Output Exit 1 }

When I paste the code into a worklet, i get this error when it runs:


At C:\ProgramData\amagent\execDir743745447\execcmd739207386.ps1:28 char:78 + ... wershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The string is missing the terminator: ". At C:\ProgramData\amagent\execDir743745447\execcmd739207386.ps1:11 char:48 + $addIns += ($registryPaths | ForEach-Object {Get-Item $_ | Get-Chi ... + ~ Missing closing '}' in statement block or type definition. At C:\ProgramData\amagent\execDir743745447\execcmd739207386.ps1:34 char:29 + } else { write-host Exit 1 } + ~ Missing closing ')' in expression. At C:\ProgramData\amagent\execDir743745447\execcmd739207386.ps1:1 char:16 + $scriptBlock = { + ~ Missing closing '}' in statement block or type definition. + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : TerminatorExpectedAtEndOfString COMMAND TIMED OUT.


Any ideas what the issue could be?


I do have crowdstrike installed on the systems that would be running this, but that stopped alerting after I made an exemption for the script so I dont think this is the cause, but wouldn’t be surprised if its coming into play, but where it runs fine when run from the command line, it seems less likely.


Also, i have write-output over the commands that actually change anything until I get it to at least run


Thanks Mike

6 replies

cgreggo
Userlevel 2

I’d drop the Write-Output here and just stick with the -WhatIf parameter.



I used to use Write-Output as a poor man’s “what if” in my code but after too many adventures into unexpected output, I use -WhatIf where I can, and a string into Write-Verbose -Verbose when I can’t.


Other than that, I have zero experience with passing a scriptblock to another PowerShell process within a worklet. I just run the PowerShell in the worklet without calling powershell.exe.

M

the scriptblock is needed due to the automox agent being a 32bit process, so it wasnt seeing the 64bit registry values. I’d much rather not need to use it at all as well, haha.


From what I can tell the whole issue is with this line:

$addIns += ($registryPaths | ForEach-Object {Get-Item $_ | Get-ChildItem | Where-Object –Filter {($.GetValue(“LoadBehavior”) -and $.GetValue(“LoadBehavior”) -ne 0)}})


if I make a new worklet with just that in it…no scriptblocks or anything, the worklet fails with the same error, but this runs fine manually from either the powershell prompt or from powershell ISE

K
Userlevel 1

Hi Mike,


It looks like there is an issue with some of the hyphens in the script. Removing and manually retyping the hyphen before “Filter” on line 10 and before each parameter on line 23 should allow the worklet to run.

D

Just checking in with the same issue, which I consider to be a bug. I was only in the testing phase of a worklet I was writing, the individual components of which had all been tested in interactive Powershell sessions. The issues only arose when the complete script was pasted into the remediation of a worklet.
 


The backtick after the { was one of many troubleshooting attempts, based on the assumption that Automox doesn’t like me starting new lines straight after a curly brace. I also tried a semicolon, removing the underscore from the variable name, removing all blank lines and comments from the script block contents, and putting the entire script block content on a single line.

The only thing that worked was manually typing this whole section of the worklet by hand, which isn’t much fun when the Automox console doesn’t auto–complete or flag syntax errors.

The contents of the script block was very simple, by the way. Like I said, this was a dry run to test the mechanics of the script before actually making it do useful stuff.

$script_installUpdates = {
    Write-Output "This output was generated in phase 2, before reboot, and after confirming that all Minfos threads are closed."
    Write-Output "This is the final line of $script_installUpdates"
}

 

K
Userlevel 1

Thank you for the feedback, I will bring this up internally to see how we can improve the experience and help troubleshooting these sorts of issues.

For the future, this is almost always an issue with Unicode dashes and quotes. PowerShell automatically corrects those characters when pasting in, which makes it even more difficult to find the cause.

D

Thanks @Ken-Automox ! Easy workaround for now is to paste into NP++ in UTF-8 mode before pasting into Automox.

Reply


Terms & ConditionsCookie settings