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,
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!
ModuleType Version PreRelease Name PSEdition
---------- ------- ---------- ---- ---------
Script 2.10.3 Az.Accounts Core,Desk
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!
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.
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…
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.