Hi.
I just noticed that in our psu environment we have about 25 000 app tokens. It seems something in the system creates two new app tokens every hour. They are valid for a year and with the identity of “admin”. Is there any good way of finding out what creates these tokens?
After some more checking I realize that there is an admin token created every time a scheduled script runs. I guess this is by design? In that case, am I supposed to do anything to purge them? Doesn’t feel good having 25 000 tokens lying around…
What version of PSU are you running?
If you’re running 5.0.x, did you modify your scheduled jobs to account for the new gRPC changes that require app tokens to authenticate the internal processes? If so, maybe that’s to blame.
Oh, sorry, should have mentioned that of course. No, actually this instance is running an old version, 4.2.13…
There have been loads of bugs fixed between 4.2.13 and 4.4.0 (the latest of the 4.x series), so I’d suggest upgrading before spending time troubleshooting an issue that could very well have already been fixed along the way.
Agree, this was a known bug in earlier versions and it was fixed. I believe it was after the version you are on. The tokens will still be there, you will have to manually disable the tokens unless you wait out the period they are set to, but that could be awhile. But new tokens would stop generating
1 Like
Specifically, this was fixed in 4.2.14: Changelog | PowerShell Universal
3 Likes
How coincidental that it was fixed in the very next release.
1 Like
Thanks a lot to the whole lot of you! Looks like I’m simply overdue in upgrading my system…
1 Like
Happy to give you that nudge you needed. 
Hi.
Guess I’ll continue on the same thread… I am now in the progress of upgrading my environment. It’s kind of a struggle, with different permission errors. Ended up uninstalling and installing again, now at least the service starts and most of the environment is up. Can’t seem to get my API endpoints working though, when accessing them I just get “API environment is not running! Please ensure your environment is configured correctly.”. My notifications says this and also that “Invalid configuration: endpoints.ps1”. I’ve searched, but I can’t seem to find any problem with endpoints.ps1. In the management interface I can see and configure my endpoints as normally. Any idea what could be wrong?
edit: Actually, noticed now that also my scheduled scripts do not run, I just get " Error executing job: PowerShell did not respond in a timely fashion. PowerShell Universal is currently waiting 30 seconds for PowerShell to start running the script.". I think I’ll rollback the entire server to snapshot and start this from scratch when I’m better prepared, thought it was just a matter of installing a msi package…
edit 2: So, I’m happy back to 4.2.13 again. What shall I look at before trying to upgrade again? I guess something is not really correct setup in my environment… Unfortunately the guy who installed it isn’t in the company any more so I need to dig myself…
Hi again.
So… I tried upgrading and failed miserably, so I’m back to my working 4.2.13 environment again. I suspect the problem lies within my environments, so I need some help investigating what is going on here. What I see is version numbers that don’t match up. Can someone explain what I’m seeing here and what to do about it?
Both these pictures are from the same environment and to me it looks really weird that the numbers don’t match. Could this be what’s making things don’t working after the upgrade?
Maybe also this is relevant:
You can delete the environments and then re-run the environment discovery process to have them re-added, but it also looks like you’re missing the Agent one, too (unless it’s just not in the screenshots).
Assuming you’re going to be upgrading to PSU 4.4.0, with everything (such as PowerShell 7) up to date on your server, your environments.ps1 file should essentially look like this (assuming no custom environments or path differences):
New-PSUEnvironment -Name "Windows PowerShell 5.1" -Version "5.1.20348.2652" -Path "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Variables @('*') -RunspaceRecycling -Description "PowerShell environment for version 5.1.20348.2227. This was automatically detected on the server."
New-PSUEnvironment -Name "Integrated" -Version "7.3.7" -Path "Universal.Server" -Variables @('*') -RunspaceRecycling -Description "An environment for running scripts directly in the PowerShell Universal server."
New-PSUEnvironment -Name "Agent" -Version "7.3.7" -Path "Universal.Agent" -Variables @('*') -RunspaceRecycling -Description "An environment for running scripts in an external PowerShell Universal agent process."
New-PSUEnvironment -Name "PowerShell 7" -Version "Unknown" -Path "C:\Program Files\PowerShell\7\pwsh.exe" -Variables @('*') -RunspaceRecycling -Description "The current version of PowerShell 7."
You could also have multiple modules installed and that could be causing conflicts.
Try running Get-Module Universal* -List to verify you only have the one for your current install and not old remnant modules too.
1 Like
Nope, nothing missing in the screenshot, I only have three. Checked my other PSU environments as well, no Agent one.
The environment discovery process I haven’t heard of before, how do I kick that one off?
Get-Module just returns one Universal module (4.2.13) so I guess that’s in order.
But I guess after recreating my environments I need to either update settings.ps1 (DefaultEnvironment and ApiEnvironment) to reflect the possibly changed names or simply change the names back to what it was before? And I have quite many scripts set up to use a specific environments, will those settings be reset to default?
I guess there isn’t one in 4.x. My bad. There is in 5.x, but that doesn’t help you here.
I meant after you upgrade to 4.4.0, to see if you still have 4.2.13’s module listed along with 4.4.0’s.
Possibly, yes.
That, or just rename the environments to match your scripts so you don’t need to adjust the scripts (whichever is easier, I suppose). Given that you can just edit the environments.ps1 and scripts.ps1 files in an editor, find/replace all occurrences of old environment names should be pretty easy to do, so I would just do that.
1 Like
Nope. 5.x feels like a too big step right now.
But thanks for all input! Still don’t know exactly what went wrong, but I think I’ve understood enough of how this is connected to give it another whirl. But that’s a task for next week. I’ll tell you how it went!
1 Like
I can’t say I blame you, given the number of posts and bugs still to be addressed in future releases.
Ok, did a last try before the weekend anyway. I stumble in to the same problem, and it’s that my Powershell 7 don’t work at all in psu. No real explanation why, it just doesn’t seem to start. Tried upgrading PS7 on the server to latest version, but to no avail. If I try to start a terminal (using automation->terminals) with Powershell 7 it just says “Request failed with status code 500” 
Integrated and Powershell 5 environments work just fine… Also starting Powershell 7 directly on the server using the same path as in the environment setting works without problem…
edit: Also dug through every log file I can find. No explanation. Guess I’ll roll back to snapshot once again for the weekend…
You upgraded to PowerShell 7.4.5 (the newest currently available)?
Does the PowerShell 7 environment in PSU point to the path for 7.4.5 and show that that’s the detected version for that environment?
Yep. The PS installation wanted a reboot and after the reboot, the number in the environment setting said 7.4.5, so obviously it’s detected correctly. It just doesn’t start :-/
1 Like