Invoke-Command in Workflow sequence - powershell

Please help to get Invoke-Command working. It says -ScriptBlock parameter is null. It seems RegHomePage() function is not available in InlineScript{}.
function RegHomePage (){
get-item -path Registry::"HKEY_USERS\*\Software\Microsoft\Internet Explorer\Main" | `
Get-ItemProperty | Where-Object {$_."Start Page" -ne $null} | Set-ItemProperty -Name "Start Page" -Value "about:blank"
}
$creds = Get-Credential -Credential value\wadmin
workflow foreachtest
{
param([Parameter(mandatory=$true)][string[]]$computers)
foreach -parallel -throttlelimit 20 ($computer in $computers)
{
sequence
{
$isPing = Test-Connection -count 1 $computer -quiet
if($isPing){
$isWSMan = [bool](Test-WSMan $computer -ErrorAction SilentlyContinue)
}
if($isWSMan){
InlineScript{
Invoke-Command -ComputerName $USING:computer -ScriptBlock ${function:RegHomePage}
} -PSComputerName $computer
echo "$computer OK"
}
Else{
$Workflow:out += "$computer`r`n"
echo "$computer FAILED"
}
}
}
Out-File .\offline.txt -InputObject $out
}
foreachtest -computers (Get-Content .\comps.txt)

Seems to have a few issues with this inlineScript block.
Dont provide the PSComputerName parameter since you are already running a job on each computer. There is no need to reference other systems here.
I would suggest using Write-Output instead of echo (use powershell native commands)
Move the function within the inlinescript to bring it in scope of each iteration.
workflow testing {
foreach -parallel ($computer in $computers) {
sequence {
inlinescript {
function RegHomePage {
Get-Item -path Registry::"HKEY_USERS\*\Software\Microsoft\Internet Explorer\Main" | `
Get-ItemProperty | Where-Object {$_."Start Page" -ne $null} | Set-ItemProperty -Name "Start Page" -Value "about:blank"
}
Invoke-Command -ComputerName $using:computer -ScriptBlock ${Function:RegHomePage}
}
}
}
}
Following is what I tested with.
workflow testingWF {
Param ([string[]] $computers)
foreach -parallel ($computer in $computers) {
sequence {
InlineScript {
function testFunc {
Param($comp)
Write-Output "$($comp.split('.')[0]) == TestFunc"
}
Invoke-Command -ComputerName $Using:computer -ScriptBlock ${Function:testFunc} -ArgumentList $using:computer
}
}
}
}
testingWF serverFQDN1,serverFQDN2
#Prints
server1 == TestFunc
server2 == TestFunc
Suggestion on how to re-write the above code
Instead of using a workflow to run a parallel foreach loop, i would recommend replacing the functionality with -AsJob.
foreach($computer in $computers) {
Invoke-Command -ComputerName $computer -ScriptBlock ${Function:RegHomePage} -AsJob
}
# Remove Jobs when done
Get-Job | Wait-Job | Remove-Job

InlineScript dont support $using:function , try nested workflow nested work
You can move your function inside InlineScript block .
Are you sure that key -PSComputerName must have value $Computers instead $computer
Adding
Only one way to call function at inlinescriptblock, it's a put it inside. But may you can use nested workflow to call few times invoke comand. Example nested:
workflow Test-Workflow {
function mess{"get ready"}
workflow nest-test{
mess
}
nest-test
}
Test-Workflow
You can also read why you can't use import it to inline script in this tutorial:
tutorial

Related

Unable to pass variable to Invoke-command

This is my first time using the workflow, could anyone explain me what is wrong with the code ?
Powershell version is 5.1
$Script = {
return(Get-Service WINRM).Status
}
workflow pushupdate{
##Select OUs
$OUs=
"OU=Workstations,DC=contoso,DC=com",
"OU=Notebooks,DC=contoso,DC=com"
foreach -parallel ($computer in ($Ous | foreach { Get-ADComputer -Filter {enabled -eq $true} -SearchBase $_} | Select Name)) {
if ((Test-Connection $computer.name -Quiet) -eq "True") {
Write-Output "Running update on:" $computer.name
InlineScript {
Invoke-Command -ComputerName $computer.name -Script $Script -Verbose
}
}
else{
Write-Output $computer.name "unreachable!"
}
}
}
pushupdate
I keep getting the error:
Invoke-Command : Cannot validate argument on parameter 'ScriptBlock'. The argument is null. Provide a valid value for
the argument, and then try running the command again.
At pushupdate:245 char:245
Variables defined outside the InlineScript block are unknown to the Invoke-Command cmdlet unless you use them as $using:<varname>.
It seems however that you cannot do that with a variable which is actually a scriptblock. That needs to be defined inside the InlineScript itself:
workflow pushupdate{
# Select OUs
$OUs = "OU=Workstations,DC=contoso,DC=com", "OU=Notebooks,DC=contoso,DC=com"
# get a string array of computerNames
$computers = ( $Ous | ForEach-Object { Get-ADComputer -Filter "Enabled -eq 'True'" -SearchBase $_ } ).Name
foreach -parallel ($computer in $computers) {
if (Test-Connection -ComputerName $computer -Quiet -Count 1) {
Write-Output "Running update on:" $computer
InlineScript {
# define the scriptblock here
$script = {(Get-Service WINRM).Status}
Invoke-Command -ComputerName $using:computer -ScriptBlock $Script -Verbose
}
}
else{
Write-Output "$computer unreachable!"
}
}
}
pushupdate

Pipeline vs Parameter Argument input?

I have a questions regard what the difference is when accepting values through either a Pipeline, or Parameter input.
I ask because:
Accepting values by pipeline in my script, works.
Accepting values using the parameter argument such as, "-ComputerName" sort of works.
I say sort of because, It does take my input from the same variable up until theres one that it cant connect to, then it stops the script. Is there a reason for this?
Heres my script for anyone curious:
Function Set-DWRCVersion {
<#
NAME
Set-DWRCVersion
SYNTAX
Set-DWRCVersion [[-ComputerName] <string[]>] [<CommonParameters>]
EXAMPLES
Set-DWRCVersion -ComputerName LocalHost,ComputerOne
'LocalHost','ComputerOne' | Set-DWRCVersion
$CritNames | Set-DWRCVersion
$CritNames | Set-DWRCVersion |Export-Csv "$($env:USERPROFILE.Substring(0,20))\Desktop\NewCrit.CSV" -Force -NoTypeInformation
#>
[cmdletbinding()]
Param(
[Parameter(Mandatory=$true,
ValueFromPipeline=$true,
ValueFromPipeLineByPropertyName=$true)]
[ValidateLength(1,15)]
[Alias('Comp','CN','name')]
[string[]]$ComputerName)
Process{
try{
[string]$Path = "C:\Users\Abraham\Desktop\dwrcs" #Dameware File Path (current)
foreach($Computer in $ComputerName){
$PSSession = New-PSSession -ComputerName $Computer -ErrorAction Stop
$TestPath = Invoke-Command -Session $PSSession -ScriptBlock { Test-Path -Path "C:\Windows\dwrcs" }
if($TestPath -eq $false){
Copy-Item -Path $Path -Destination "\\$Computer\C$\Windows" -Recurse -Force }
#Start-Sleep -Seconds 1
$EXEVersion = Invoke-Command -Session $PSSession -ScriptBlock { [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Windows\dwrcs\DWRCS.EXE").FileVersion }
$DLLVersion = Invoke-Command -Session $PSSession -ScriptBlock { [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Windows\dwrcs\DWRCRSS.dll").FileVersion }
if($EXEVersion -notmatch '12.1.2.584'){
[PSCustomObject] #{
"Computer Name" = $Computer
"Status" = "Online"
"DWRC Version" = $EXEVersion
"DWRCRSS DLL" = $DLLVersion
"DWRC Check" = "Not up to date" }
""
Write-Output -InputObject "Version not current"
Write-Output -InputObject "Stopping Service. . ."
Invoke-Command -Session $PSSession -ScriptBlock {
Stop-Service -Name dwmrcs;
Get-Item -Path C:\windows\dwrcs | Rename-Item -NewName "dwrcs.old" }
Remove-Item -Path "\\$Computer\c$\Windows\dwrcs.old" -Recurse -Force -ErrorAction SilentlyContinue
#Start-Sleep 1
Write-Output -InputObject "Copying new files over. . ."
Copy-Item -Path $Path -Destination "\\$Computer\C$\Windows" -Recurse -Force
Write-Output -InputObject "Starting Service. . ."
Invoke-Command -Session $PSSession -ScriptBlock { Start-Service -Name dwmrcs }
}
elseif($EXEVersion -match '12.1.2.584') {
[PSCustomObject] #{
"Computer Name" = $Computer
"Status" = "Online"
"DWRC Version" = $EXEVersion
"DWRCRSS DLL" = $DLLVersion
"Version Check" = "Up to Date" }
}
else { Write-Output -InputObject "Error Occured"
Throw "$($Error[0].Exception.Message)" }
}
} Catch {
[PSCustomObject] #{
"Computer Name" = $Computer
"Status" = "Offline"
"DWRC Version" = $null
"DWRCRSS DLL" = $null
"Version Check" = $null }
} Finally {
if ($PSSession) {
Get-PSSession | Remove-PSSession }
}
}
}
Overall, its a pretty simple script where it will get some remote file versions for me. I am just not sure why accepting values from the pipeline doesn't stop the script, but inputting them using the regular Parameter does.
Im importing from a csv to get the names using the following:
$Crit = Import-Csv -Path "$($env:USERPROFILE.Substring(0,20))\Desktop\med.csv"
$CritNames = $Crit.'NetBios Name' -replace "AREA51\\",""
<# Names return like so:
COmputerOne
COmputerTwo
COmputerThr
Etc.. #>
And when running it using the pipeline input: $CritNames | Set-DWRCVersion which works but, Set-DWRCVersion -ComputerName $CritNames doesn't; well it does up until it hits an offline computer then stops the script.
Is there something im missing? Can someone much smarter than me edumacate me?(:
You can solve this by moving the try/catch/finally statement inside the foreach loop:
process {
foreach($Computer in $ComputerName){
try {
# ...
}
catch {
# ...
}
finally {
# ...
}
}
}
Why would this make a difference?
When explicitly binding a value via -ComputerName, the process block is only invoked once - but when you supply input via the pipeline, the process block is invoked once per input item.
You can observe this behavior with a simple test function like this:
function Test-ProcessInvocation {
param(
[Parameter(Mandatory,ValueFromPipeline)]
[string[]]$ComputerName
)
process {
"Running process block with $($ComputerName.Length) input arguments: [$ComputerName]"
}
}
Running this with both input modes will make this behavior clearly visible:
PS ~> Test-ProcessInvocation -ComputerName 1,2,3
Running process block with 3 input arguments: [1 2 3]
PS ~> 1,2,3 |Test-ProcessInvocation
Running process block with 1 input arguments: [1]
Running process block with 1 input arguments: [2]
Running process block with 1 input arguments: [3]
This means that running Set-DWRCVersion -ComputerName Computer1,Computer2 translates to this sequence of statements:
# Single invocation of `process` block with $ComputerName = all input values at once
try {
foreach($Computer in 'Computer1','Computer2'){
}
}
catch {}
finally {}
Running 'Computer1','Computer2' |Set-DWRCVersion on the other hand:
# `process` block repeats per input item
try {
foreach($Computer in 'Computer1'){
}
}
catch {}
finally {}
try {
foreach($Computer in 'Computer2'){
}
}
catch {}
finally {}
As a result, throwing an error inside the foreach loop when invoking via the pipeline never "skips" any items, because the loop is only ever operating on one at a time.
By inverting the relationship between the loop and the try/catch statement, any errors will now have been captured and handled inside the loop, and it will no longer skip the remaining input values in $ComputerName.

Error on running Pester test using foreach-object -parallel

I have this infrastructure pester test. Code for demonstration purpose:
Describe 'WEB-Tests' {
$servers = 'ServerA','ServerB'
$sessions = #()
foreach ($server in $servers) {
$sessions += New-PSSession -ComputerName $server
}
$sessions | foreach-object {
Context " Service is Running on $($_.ComputerName)" {
$service = invoke-command -session $_ -scriptblock { get-service 'some service' }
It "Service $($service.Name) should be Running" {
$service.Status | Should be "Running"
}
}
}
}
This works fine. If I replace the $sessions|foreach-object with $sessions|foreach-object -Parallel, i get this error -
New-PesterState: C:\Program Files\WindowsPowerShell\Modules\Pester\4.9.0\Functions\Context.ps1:77:128
Line |
77 | … '] .) -TestNameFilter $null -TagFilter #() -SessionState SessionState
| ~~~~~~~~~~~~
| Cannot process argument transformation on parameter 'SessionState'. Cannot convert the "SessionState" value of type "System.String" to type
| "System.Management.Automation.SessionState".
Exception: The Context command may only be used from a Pester test script.
Please suggest on how to achieve parallelism here as there are hundreds of servers.
RESOLVED-I figured out a workaround by using jobs and it serves the purpose.
Describe 'WEB-Tests' {
$servers = 'ServerA','ServerB'
$sessions = #()
foreach ($server in $servers) {
$sessions += New-PSSession -ComputerName $server
}
Get-Job | Remove-Job
invoke-command -session $sessions -scriptblock { get-service W3SVC,WAS } -AsJob
$j = Get-Job | wait-job
($results = $j | Receive-Job) | out-null
Context "IIS Services are Running" {
foreach ($result in $results) {
It "Service $($result.Name) should be Running on $($result.PSComputerName)" {
$result.Status | Should be "Running"
}
}
}
}

Accessible a powershell variable inside a function / workflow

I am working on a Powershell script with a function and a Workflow. Unfortunately, I was unable to access variables inside the function. Here is an example :
$location = "c:\temp"
function PingComputer
{
Param($ip)
$res = Test-Connection -ComputerName $ip -quiet -Count 1
If ($res -eq "true")
{
Try
{
#Some tasks if pings are ok
#For example : copy-item -path $location -destination $dest -force -recurse
}
Catch
{
#Catch exceptions
}
}
Else
{
#Ping fail
}
}
workflow parallelPingCOmputer {
Param($ips)
$i=0
foreach -parallel($ip in $ips)
{
PingComputer($ip)
$workflow:i++
$count = $ips.Count
InlineScript {
#write-host "$using:i : " $using:ips.count " : $using:ips "
Write-Progress -Activity "Poste : $using:ip" -Status "Postes effectués : $using:i sur $using:count" -PercentComplete (($using:i / $using:Count) * 100)
sleep -s 1
}
}
}
$request = parallelPingComputer -ips $ip_list | Select-object date, computer, result | out-gridview
This is a simplified version of my current script. But, as you can see, the variable $location can't be accessed inside my function PingComputer. I tried to modify its scope as global or script, but nothing works.
The message I get with the copy-item is "path is null"... How can I make my variable accessible ?
If you want to reuse the function, just copy the function inside the workflow and keep it outside. Else, copy the function inside the workflow and remove the one outside like the code below. It could solve your problem without using a function inside the workflow.
I made an example on my Github :
Workflow Get-Ping{
Param(
[Parameter(Mandatory = $true)][string[]]$Computers
)
Foreach -Parallel ($computer in $Computers){
$ping = $null
$version = $null
if(Test-Connection -ComputerName $computer -Count 1 -Quiet){
$ping = "Online"
$version = Get-WmiObject -Namespace "root\cimv2" -Class "Win32_OperatingSystem" -PSComputerName $computer | select Version
}
else{
$ping = "Offline"
}
#if no gwmi use -ComputerName $computer
$arrayResults = New-Object -Type PSObject -Property #{
Hostname = $computer
Ping = $ping
Version = $version.Version
}
return($arrayResults)
}
}
$computers = Get-Content ".\Computers.txt"
Write-Host "$($computers.Count) computers found" -ForegroundColor Green
Get-Ping -Computers $computers | Select-Object Hostname, Ping, Version | Sort-Object Hostname | Out-GridView -Title "Powershell Workflow - Ping"

start-job Run command in parallel and output result as they arrive

I am trying to get specific KBXXXXXX existence on a list of servers , but once my script one server it takes time and return result and come back and then move to next one . this script works perfectly fine for me .
I want my script to kick off and get-hotfix as job and other process just to collect the results and display them.
$servers = gc .\list.txt
foreach ($server in $servers)
{
$isPatched = (Get-HotFix -ComputerName $server | where HotFixID -eq 'KBxxxxxxx') -ne $null
If ($isPatched)
{
write-host $server + "Exist">> .\patchlist.txt}
Else
{
Write-host $server +"Missing"
$server >> C:\output.txt
}
}
The objective it to make the list execute faster rather than running serially.
With Powershell V2 you can use jobs as in #Andy answer or also in further detail in this link Can Powershell Run Commands in Parallel?
With PowerShell V2 you may also want to check out this script http://gallery.technet.microsoft.com/scriptcenter/Foreach-Parallel-Parallel-a8f3d22b using runspaces
With PowerShell V3 you have the foreach -parallel option.
for example (NB Measure-Command is just there for timing so you could make a comparison)
Workflow Test-My-WF {
param([string[]]$servers)
foreach -parallel ($server in $servers) {
$isPatched = (Get-HotFix -ComputerName $server | where {$_.HotFixID -eq 'KB9s82018'}) -ne $null
If ($isPatched)
{
$server | Out-File -FilePath "c:\temp\_patchlist.txt" -Append
}
Else
{
$server | Out-File -FilePath "c:\temp\_output.txt" -Append
}
}
}
Measure-Command -Expression { Test-My-WF $servers }
For this use PowerShell jobs.
cmdlets:
Get-Job
Receive-Job
Remove-Job
Start-Job
Stop-Job
Wait-Job
Here's an untested example:
$check_hotfix = {
param ($server)
$is_patched = (Get-HotFix -ID 'KBxxxxxxx' -ComputerName $server) -ne $null
if ($is_patched) {
Write-Output ($server + " Exist")
} else {
Write-Output ($server + " Missing")
}
}
foreach ($server in $servers) {
Start-Job -ScriptBlock $check_hotfix -ArgumentList $server | Out-Null
}
Get-Job | Wait-Job | Receive-Job | Set-Content patchlist.txt
Rather than use jobs, use the ability to query multiple computer that's built into the cmdlet. Many of Microsoft's cmdlets, especially those used for system management, take an array of strings as the input for a -Computername parameter. Pass in your list of servers, and the cmdlet will query all of them. Most of the cmdlets that have this ability will query the servers in series, but Invoke-Command will do it in parallel.
I haven't tested this as I don't have Windows booted at the moment, but this should get you started (in sequence).
$servers = gc .\list.txt
$patchedServers = Get-HotFix -ComputerName $servers | where HotFixID -eq 'KBxxxxxxx'|select machinename
$unpatchedServers = compare-object -referenceobject $patchedServers -differenceobject $servers -PassThru
$unpatchedServers |out-file c:\missing.txt;
$patchedServers|out-file c:\patched.txt;
In parallel:
$servers = gc .\list.txt
$patchedServers = invoke-command -computername $servers -scriptblock {Get-HotFix | where HotFixID -eq 'KBxxxxxxx'}|select -expandproperty pscomputername |sort -unique
As before, I don't have the right version of Windows available at the moment to test the above & check the output but it's a starting point.