Really unhappy about Invoke-PSUScript behavior of PSU v4 and v5

PowerShell Universal
1

I have loved PSU. I have bragged about it, it’s usefulness, recommended it to others etc. We are in fact in the process of possibly using it for more purposes in our organisation by other groups.

But right now I am a bit irritated since I have dealt with our technological debt and quickly moved from v2 via v3 to v4, looking ahead into v5.

I may also be an idiot and have missed something completely. In that case, please tell.

I have gripes about how resent versions of PSU are handling jobs. Incrementally changed behavior of child jobs are breaking my solution, leaving me, as far as I can see, without good options without significant architectural changes. I, frankly, want the old behavior back. At least be able to opt-out somehow.

One way to achieve this could be to add a Invoke-PSUScript -Detached flag or something along those lines to start jobs from other jobs without setting a parent job for it. I.e., behave as if it was called by a dashboard.

TL;DR:

So what’s going on? In PSU v2 and v3 jobs were jobs, plain and simple. If I started a job from a dasboard, I got a job. If I started it from another job, I got a job. They behaved the same. All jobs were presented as a flat list, both in the global and the per-script views. A parent job id may have been set, but no fuss was made about it.

Enter PSU v4. Superficially, it is the same. The presentation is the same as in v3. Jobs are jobs. But, suddenly the job output is deleted, or “groomed”, by a completely different schedule. This is a major, breaking change that is, as far as I can tell, unmentioned in any docs (I’m happy to be proven wrong). Because in v4, the data of the script, log, pipeline etc, are no longer groomed according to the settings of the script itself, but according to the settings of the parent script invoking it.

So suddenly running Invoke-PSUScript by a dashboard, hence no parent job, and running Invoke-PSUScript by another script, that does not happen to be a dashboard, behave different in, for my solution, really, really significant ways.

Now, with PSU v5, the situation has become worse. Now jobs started by other jobs are also presented completely different. They are completely hidden from the Job view of the script itself. They are hidden beneath the invoking job in the global view, making the output very hard to find. Jobs invoked by the dashboard are proper jobs. Jobs invoked by other jobs are just some sub-component of the invoking job. Invoke-PSUScript produces two, completely different results depending on context.

So why is this an issue for my solution? I have a possibly long-running script which is involved in moving IT-forensic information nationally between storage solutions and domains, across long distances, possibly transforming information, possibly injecting information in systems for analytics etc. It is a bit of a beast. The output of this script is kept for some time for follow ups, statistics etc. 60 days 1000 invokations was the limit we maxed out in v2.

It can be invoked manually from data collected by PSU and presented in a dashboard. It can also be invoked automatically by PSU, e.g, by way of “orders” placed on disk by other automations and collected by PSU. The automatic invokations are made by a frequently running script which is simply responsible for checking some prerequisites and then invoking the major script. The output of this parent script is completely uninteresting, but PSU has decided that it is the most important thing ever and that the output I really want is just garbage. I have thoughts.

Please, give me an option to start jobs without hiding it under a parent job and deleting my data with some other policy than that of the script itself.

Regards,
Fredrik Jönsson

Product: PowerShell Universal
Version: 4.4.1, 5.0.10
2

Sorry you don’t like that behavior and that’s good feedback. I can open some GitHub issues to address it.

That said, you can remove the UAJobID variable in a parent job that starts other jobs to avoid this.

Remove-Variable -Name 'UAJobId'

1..5 | % {
    Invoke-PSUScript -Name 'Child.ps1'
}

The result is just a list of jobs without parenting.

image
image600×654 14.4 KB

In terms of the admin console, v4 has a check box to view child jobs so they aren’t nested in the table.

In v5, we should add that back to avoid having to click through there.

I’m also looking into the grooming issue. It was reported yesterday.

1 Like
3

Thanks Adam. Really appreciate your input. It should be possible to utilize this is a work-around for my purposes, I’ll look into that.

4

I have tried the workaround with Remove-Variable with our current production system running 4.4.1 and it works fine for my purposes.

I think an option to Invoke-PSUScript to get this behavior, same as if it was started from a dashboard, would be a non-intrusive solution that would work fine for me.

5

Got to add, apart from this issue the new releases are very good and the upgrade has been fine. Obviously had to adjust a few things, but these are major version upgrades, so the necessary adaptions have been less than expected rather than anything else.

In the migration to MSSQL, the pipeline output of old jobs was lost. A slight bummer to us, but we could live with that.

Issues we’ve had earlier are gone, like +24h jobs (we rarely have those any more due to other performance improvements, but had one just after the upgrade, the time ticker in the job view lapsed after 24h, super, super minor, but otherwise the job ran just fine), error handling is much improved with a better error status on jobs where errors are proceeded by warnings, simpler setup with windows authentication without ISS, etc. etc.

1 Like