Product: PowerShell Universal
Version: 5.3.2
I’m not sure where else to ask this:
@adam , when installing the PSU agent onto an event hub machine, what context do the sent scripts run under? Are they ran by the NT system account, or the account that installed the script (i.e. workstation administrator in a domain joined environment)? (How) can this be changed if desired?
I only just started messing with Event Hubs the other day, and was that’s one of the things I was wondering, too - whether it runs them as the user the service is running under or something else (and how to change it, if necessary).
They run as the system account. You can change it by updating the service logon account. Open service.msc and change the account to change what it runs under.
They are magical!!! The lifeblood of my main project. I’m wrestling with so many layers of issues, however, and this one may have been the cause of one. The hypothetical scenario where I can get everything to work properly is quite an enticing vision of the future to aspire to however, so I press on!
They are the foundation of our new management system we are building for the several hundred servers we manage. They have been fantastic and allows a really distributed approach vs the monolith we have had for years.
The big challenge for us, and it looks like Adam just added a new feature to help to 5.4, is how we protect tokens and prevent users from being able to modify scripts. The token issue will be taken care of in 5.4, i’m still trying to solve how to prevent modification of scripts that might have to run under an elevated service account login.
We are even considering storing scripts inside of a secret store that we Invoke-Expression the value to load the module. That still leaves the agent.json config that could be modified to execute something else.
@adam I recall you saying that a ps1 file was needed because of (and forgive me if I remember this wrong) how modules and such need to load, like the agent couldn’t just receive a PS script and IEX it in memory, correct? I guess i’m checking my memory and wondering if it is possible, with maybe even limited use cases, that the PS script to execute could be sent with the payload from the server and executed from memory without the need of a PS1 file? That would solve just about all of our security concerns and really lock down distributed systems.
You can send scripts down from the server and run with Invoke-expression. It’s actually what this monitoring module I made does: gallery/APIs/PowerShellUniversal.API.Monitoring/PowerShellUniversal.API.Monitoring.psm1 at main · ironmansoftware/gallery · GitHub
I’m sure we could implement something a little more robust but this avoids having the script live on disk.
See the solution marked here - scripts sent down in this manner are sent from the server to the agents at runtime, saved into a temp file, and then executed. You can easily modify the provided script to automatically delete the temp file as well. This ensures that your agents are receiving the most up-to-date version of the script, saved within your repository and thus behind the built-in authentication/authorization provided, as well as ensuring that the script is not tampered with before execution.
Edit - Adam’s too fast!
OMG, I think I misread the documents… I had a reply all set to go and just saw that scriptpath is optional as I was checking myself. Well, then that solves my issue lol! I could swear that scriptpath was required 
Thank you everyone, and with 5.4 that should fully lock down security!
Don’t worry too much. That has changed in the last few versions to allow just any module to be called. I still think it would be neat if we just had a “run on event Hub” option for scripts. No need to do anything fancy.
We have some items in the backlog to surface agents as PSU computers to allow this.
That would be VERY useful!
Is there a way to prevent the connection ID from changing each time the agent service is restarted?
No. That’s internal to SignalR. We added a -Computer parameter to Send-PSUEvent to provide a static identifier. It will internally look up the connection ID for that machine if it’s connected. We probably should add an alias to that parameter though because it’s super confusing with the -ComputerName parameter also existing on that cmdlet…
We could also enhance the config so you could specify the computers name, kinda like nodename for app settings.json.
Since we’re keeping this alive - related to Jesse’s question, is there a reason WHY those agent services would restart every day? We have about 3000 disconnected sessions due to service restarts daily on each of our agents.
Similarly, can a provision be added to overwrite an entry in the database if the computer/username match a previous connection to overwrite the connection ID and connected/disconnected timestamps? I can make a feature request if you think this would belong there
I don’t know why they would cause disconnects. Services shouldn’t be restarting, to my knowledge. Something could be severing the connection and it causes a reconnect but IDK what that would be. Cranking up logging on the agent would likely be helpful. The server is likely just seeing them disconnect but doesn’t know why.
Your second question would be a feature request. We could make it so just a single record per host is stored. Then you’d know if it was disconnected or not without having to worry about past sessions.
Yeah I tried checking with Debug - it’s at random times, all three of our currently connected agents disconnect and reconnect shortly after. It’s not a problem, honestly, if we could get that proposed feature! I’ll do a write up and reference this thread.
Not sure of your environment \ Network but network appliances can be set with maximum connection durations… if that is applicable.
We too run Agents using a Windows Service Account for the purpose of single management of a secured, non-trusted Active Directory. Its one of the features we chose PowerShell Universal for and works well for our use case
Not here unfortunately; the logs do not match up. Good idea though!