PowerShell Universal - 3.5.4

PowerShell Universal - 3.5.4

Release Notes


  • Fixed an issue where $UAJob.Identity.Name was $null in jobs
  • Fixed an issue where a serialization error could happen when running jobs when using SQL peristence


  • Fixed an issue where New-UDDatePicker and New-UDTimePicker would not update the UI when settings -TimeZone


  • Added additional validation for repository directory paths
  • Fixed an issue where enabling splatting for configuration files would fail to correctly format the files


Hi Adam!

Just updated to 3.5.4, but I only see the Integrated environment. Is there something I have to add to environments.ps1 to get the “agent” environment?


You can add this to your config file:

New-PSUEnvironment -Name "Agent" -Version "7.2.7" -Path "Universal.Agent" -Variables @('*')

Good to know. I updated 2 servers yesterday and was missing it as well. Is this because you don’t want to modify environments.ps1 during the install “just in case”?

So I’m having mixed success with the agent environment.

A simple script works just fine, but if I want to use an Az module, I get an error. For example, Get-AzAccessToken says:

The ‘Get-AzAccessToken’ command was found in the module ‘Az.Accounts’, but the module could not be loaded. For more information, run ‘Import-Module Az.Accounts’.

… and if you try Import-Module Az.Accounts, you get this:

Assembly with same name is already loaded

It seems that even though we’re in an external process, PSU is confused and thinks the assemblies for the Az modules are already in memory, even though the modules are not imported.

Any suggestions on this one, @adam?

Can you let me know what version of the Az module is installed?

It’s likely an assembly conflict. PSU might be using an older version of something that the Az module is using.

Luckily I have a job from yesterday where I ran Get-Module Az.Accounts -ListAvailable for exactly that purpose! :slight_smile:

ModuleType Version    PreRelease Name                                PSEdition 
---------- -------    ---------- ----                                --------- 
Script     2.10.3                Az.Accounts                         Core,Desk 

Thanks! I’ll take a look

1 Like

I can reproduce this. I’ll get an issue open for it and see if we can track it down. I’m super surprised this doesn’t happen in the integrated environment! :exploding_head:

Agreed! I was going to say - if it’s a conflict with something in PSU you’d think it’d manifest in the integrated environment too! I hope you can figure it out.

One thing I’m hoping to test with the agent environment is the Graph module’s connection. When you connect with an access token (which we do, because we’re using a managed identity) you automatically get a connection that persists across scripts. So if you call Disconnect-MgGraph from one script while another one is running, the running script also disconnects.

I’m really hoping that running a script in an agent environment will work around this so I can have scripts calling Graph running concurrently. I’m being very careful with my schedules right now so that scripts don’t overlap. :slight_smile:

Progress :wink:


1 Like

Surely you mean Azdf.ps1 :stuck_out_tongue:

Oh wow! Is the fix in 3.5.5? That’s amazing work.

I would love to see a post or even a video on how you go about diagnosing a problem like this!

Yep. This should be working in 3.5.5 now.

This was actually a dependency problem where the Microsoft.PowerShell.SDK NuGet package was not included with the Universal.Agent.exe project. It’s one of those circumstances of “how did this ever work” because I was seeing issues where it was throwing that error even when running a completely blank script. We include it with Universal.Server.exe so it must have been loaded in some other way in our previous testing.

I actually did a bunch of work adding and improving the logging we have within jobs to output to the admin console when JobDebugging is enabled in appsettings.json. This kind of eliminated a bunch of thoughts I had on assembly binding and finally realized that package wasn’t directly referenced. Once I added that reference, it immediately started working…

1 Like

Could this be an issue?


This could affect accounts trying to access PowerShell Universal with Windows Authentication, WS-Fed, IIS application pools and GMSA services that are using RC4 encryption but have AES disabled.

That said, there isn’t anything on the PSU side that needs to be done aside from following the Microsoft guidance for this CVE and patching domain controllers.