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?
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.
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.
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.