ndollimount

It looks like Adam was replying to someone else when he mentioned being fixed in 5.6.8. For your issue, you advised that you’re setting it as “-AutoInclude $false”. This is incorrect syntax for a switch parameter. Have a look at a sample I put together; you can run it to see the results as commented.

To summarize; if you don’t want to include a switch in a command, simply omit it from your command. Alternatively, you need to use the syntax of -SwitchName:$false to include it as false.

function test {
    param(
        [Parameter(Mandatory=$false)][switch]$testSwitch
    )

    if ($testSwitch) {
        Write-Information -MessageData "Switch activated!" -InformationAction Continue
    } else {
        Write-Information -MessageData "Switch not activated!" -InformationAction Continue
    }
}

test # not activated
test -testSwitch # activated
test -testSwitch:$false # not activated
test -testSwitch $false # error due to incorrect syntax

Hey guys, we use this functionality A LOT with our scripts to speed up data processing and I wanted to share a tidbit of info I picked up along the way. As @AnonymousUser mentioned, you can import external scripts into your script block; that is one way of doing it. Another way is to write the function outside the script block inside the main script, then you put the function’s text into a variable, then pull in the variable text to a new function inside the script block. I don’t know the logic behind this part but it ends up allowing PowerShell to use much less memory than having the function existing right in the script block.

As mentioned, each job has its own memory, so they can’t access each other’s memory. They can access the main process by using the USING statement, like $USING:parentScriptVariable. This is useful for reading data but doesn’t work to pass data back. Another piece that I’ve learned is how to pass data back to the main script using a synchronized hashtable. Since we then have access to write back data, we can increment a counter to be used to display progress. I know, it’s a lot, but the example I have below has all this tied together.

This example has a list of targets to check connectivity to, and it will send a notification via a JOIN message if any of them are unreachable. It’s not the best use case for this type of parallel processing but it’s simple enough to show it in action. I’ve redacted the URLs.

# checkAlive function that will run inside each job
function checkAlive {
    param(
        [Parameter(Mandatory = $true)][string]$target,
        [Parameter(Mandatory = $true)][string]$serviceName
    )

    try {
        if ((Invoke-WebRequest -Uri $target).StatusCode -eq 200) {
            $syncHash.output.Add(@{"$serviceName" = "Alive"})
        }
        else {
            sendJoinNotification -notificationTitle 'SiteAliveCheck' -notificationText "$serviceName is Down." -deviceID $USING:Secret:joinDeviceID -joinAPI $USING:Secret:joinAPIKey
            $syncHash.output.Add(@{"$serviceName" = "Down"})
        }
    }
    catch {
        sendJoinNotification -notificationTitle 'SiteAliveCheck' -notificationText "$serviceName is Down." -deviceID $USING:Secret:joinDeviceID -joinAPI $USING:Secret:joinAPIKey
        $syncHash.output.Add(@{"$serviceName" = "Down"})
    }
}

# list of targets to check
$targets = @(
    @{
        target = 'https://seerr.jellyfin.domain.com'
        name   = 'Jellyseer'
    },
    @{
        target = 'https://jellyfin.domain.com'
        name   = 'Jellyfin'
    },
    @{
        target = 'https://bitwarden.domain.com'
        name   = 'Bitwarden'
    },
    @{
        target = 'https://budget.domain.com'
        name   = 'Budget Client Site'
    },
    @{
        target = 'https://api.budget.domain.com'
        name   = 'Budget API'
    },
    @{
        target = 'https://ubi.domain.com'
        name   = 'Unifi Network Application'
    },
    @{
        target = 'http://servername:8989'
        name   = 'Sonarr'
    },
    @{
        target = 'http://servername:7878'
        name   = 'Radarr'
    },
    @{
        target = 'http://servername:8181'
        name   = 'SABnzbd'
    }
)
# This converts the function to a string so it can be passed to the jobs
$checkAliveString = $function:checkAlive.ToString()

$syncHash = [hashtable]::Synchronized(@{
        running = 0 # Number of jobs running
        output  = [System.Collections.Generic.List[object]]::new() # An empty list to store any output that can be processed later
    })

$jobs = $targets | ForEach-Object -ThrottleLimit 5 -AsJob -Parallel {
    $syncHash = $USING:syncHash # Access the shared hashtable
    $syncHash.running++ # Increment the running job count
    $function:checkAlive = $USING:checkAliveString # 'Import' the function into the job

    checkAlive -target $PSItem.target -serviceName $PSItem.name
}

while($jobs.State -eq "Running"){
    Write-Progress -Id 1 -Activity "Checking services..." -Status "Working on $($syncHash.Count) of $($targets.Count)" -PercentComplete ($syncHash.Count / $targets.Count * 100)
} # Once all jobs are done, the while loop will exit

We have 126 schedules and roughly 210 in-use scripts. We have 3 Linux worker nodes and a single Windows worker node for a few AD cmdlets needed. We also have a separate web node that sits in AWS that only runs dashboards, of which is running ~12 dashboards at any given time. We run a single PostgreSQL server that doesn’t seem to have any issues handling things, which is nice. We have configured 180 days data retention and 7 days log retention.

We’re also with you on having lots of bugs reported/fixed; their support has been fantastic .

Hi @davidwruck , I’m not sure specifically about multimode but I do know there are a couple bugs in 5.1.2 that will be fixed in 5.2.0 that I would advise waiting on that are affecting our deployment.

Odd behavior with job status updates on long-running scripts · Issue #4177

There seems to be a ‘PowerShell Universal is starting…’ loop occurring · Issue #4167

I wanted to point out that there’s a noticeable increase in performance in this version. I assume it’s related to the change in log level writing. Regardless of why, I’m happy about it. Thanks!

Could this allow me to run a script on one node but use the Invoke-PSUScript cmdlet to execute it on another node without API access to that other node?

I may have submitted a feature request for this functionality yesterday…

I can confirm that this has been fixed in 5.0.9. I installed the nightly build to check on some other fixes.

Hi all,

I was messing around with an API endpoint with the intention of uploading a backup file from a server. The overall process was very simple thanks to the demo video and worked fine until I tried to upload the ~900MB backup file. I tested with a bunch of files of smaller sizes to see how small would work and I was able to have a ~70MB file upload but a ~130MB file fail with the “Buffer limit exceeded” error. Anything larger gets the error and anything smaller works. I’m assuming a 100MB limit somewhere but I can’t figure out where and whether this limit can be changed or removed.

Any ideas?

For reference or if anyone wants to test it, here’s the code from my “/backups” endpoint.

switch($Method){
    'Post' {
        [IO.File]::WriteAllBytes("D:\Server Backups\$([GUID]::NewGuid().toString())_$($UploadFilename)", $Data)
    }

    'Get' {
        $backupFiles = (Get-ChildItem -Path "D:\Server Backups").Name
        return ($backupFiles | ConvertTo-Json -Depth 100)
    }
}

Product: PowerShell Universal
Version: 4.3.4