PowerShell Universal - 3.5.4

PowerShell Universal - 3.5.4

Release Notes

Automation

  • 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

Dashboard

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

Platform

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

Downloads

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?

Cheers!

You can add this to your config file:

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

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:

image

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?

https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d

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.