Powershell Execution Policy

[darrell.ping.beinetworks]

I have an Ignite script (Exchange Server Message Queue Information) thats failing due to the execution policy not being restricted. I know for this one machine I could sign in and change it but I was hoping there was a way I could do this from within LabTech so as we add more systems I dont have to manually make this change. Any help with this would be awesome. Thanks!

-D

[rsloan.labtechsoftware]

There is a built in default script that you can call from within another script that will set the Powershell execution policy to unrestricted then when it is finished set it back to the previous setting. The script is called Set Powershell Execution Policy and is found in Scripts->Maintenance->Powershell. The Exchange Message Queues script uses this sub script on line 21 and again on line 27 to set it back to the original setting. We have seen that sometimes the Set Powershell Execution Policy script won't work until you set the policy to unrestricted and back. Follow the instructions below for how to do this.

If the Set Powershell Execution Policy function script is failing try running the command below from the Command Prompt tab of the agent it is failing on.

~get-executionpolicy (this will tell you what the policy is before you change it)
~set-executionpolicy unrestricted

Then run the command below to verify the previous command was successful. It should return Unrestricted.

~get-executionpolicy

If it was successful set the policy back to what it was before then try the script again.

[mkeigher.choicesolutions]

Hey Darrel,

Just saw your post here and I'm sure you have by now accomplished what you were after doing by now...right?

Anyways, here's a tip for running PoSH commands via LabTech.

Whenever you are starting a PoSH statement in LabTech, then use the Powershell Command as Admin "script step' and change directory to where your PS1 file is, and then perform another step to then execute the script (had issues running a PS1 from another folder??), with the following addition to the start of the script:

powershell.exe -ExecutionPolicy Bypass

Example:





I suppose you "could" use it in the 'Execute Script" script function too, but I use it here, and it works all the time.

This method is WAY EASIER than messing with the Execution Policy.

Quick caveat: As only 'admins' can Bypass the Execution Policy you MUST run this with the PowerShell Command AS ADMIN function, for it to work!

Happy PoSHing!

[mbastian.labtechsoftware]

Due to the diversity of target agents that I end up working with, and taking a "least amount of change" approach, here's what I have found to be the most reliable and effective way of calling PowerShell scripts. With this method, you will never have to change the execution policy, as Martyn has mentioned:

LabTech script functions:

1. FILE WRITE function - Write out the contents of the PowerShell script you'd like to execute against the target agent. This enables you to use all of your LabTech expansion variables, and you can also use the latest version of PowerShell that is on that remote agent. Unfortunately at the current point in time, the "PowerShell Command / PowerShell Command as Admin / Execute Script" functions will only natively support PowerShell 2.0 and below.

2. SHELL / SHELL as Admin function - Use a shell command to execute the file you've just written down to the target machine. The following command will accomplish this:

%windir%\system32\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy ByPass -File %windir%\temp\MyPowerShellFile.ps1 -NonInteractive

You can also execute commands inline should you only need to run a few commands by switching the -FILE parameter over to a -Command parameter.

%windir%\system32\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy ByPass -NonInteractive -Command "get-service | ? {$_.Status -eq 'Stopped' -AND $_.DisplayName -like 'LTAge*'} | start-service;"


Hope this helps clear up some of the confusion out there. I'll have a bunch more information for you guys at Automation Nation!

Another note: If you're using the PowerShell Command / PowerShell Command as Admin / Execute Script functions, you need to convert your write-host statements to write-output for capturing the standard output. If you call the PowerShell script via the aforementioned PowerShell.exe method, you can leave the scripts as is. Execute Script is definitely a cool new function, and is surely a good method if you've got a quick script that needs executing.

[dwhite.raymorgan]

Another note: If you're using the PowerShell Command / PowerShell Command as Admin / Execute Script functions, you need to convert your write-host statements to write-output for capturing the standard output. If you call the PowerShell script via the aforementioned PowerShell.exe method, you can leave the scripts as is.

Leaving a "Write-Host" statement will trash the script output and only return "OK".

That really should be in the knowledgebase, or a known issue ticket, or the Documentation for the function. Or best yet, fixed if possible!

Darren

[al.murphymckay]

[quote="dwhite.raymorganLeaving a "Write-Host" statement will trash the script output and only return "OK".]

That really should be in the knowledgebase, or a known issue ticket, or the Documentation for the function. Or best yet, fixed if possible!

Darren[/quote]

This little note of the Write-host trashing the script with only OK was a god send. Thanks so much, this saved me so much time and cooled me down from getting hot over why it wasn't working. There seems to be always a little trick to get it LT and powershell to work and I am grateful for your post.

Al