Set-PSUCache Roles issue
Hey,
I just tried using Set-PSUCache for the first time.
The data im storing could be considered sensitive and I noticed that there's a -Roles param on this cmdlet, and a column in the database for roles (Though the roles dont show in the UI from the cache menu).
In my script I have the following command:
Set-PSUCache -Key "Keyname" -Value $Data -Persist -Role "RoleName" -Integrated
This works the first run, when the cache doesnt exist, but if I rerun my script, it fails with:
Status(StatusCode="Unknown", Detail="Exception was thrown by handler.", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1784817449.405000000","description":"Error received from peer ipv6:[::1]:58801","file":"..\..\..\src\core\lib\surface\call.cc","file_line":953,"grpc_message":"Exception was thrown by handler.","grpc_status":2}")
I've tried adding the role to the execution roles on the script (I also have the role on my account while running the script). I've tried with and without -Integrated but it's the same issue.
Removing the role entirely seems to work fine without issue.
All Comments (7)
Hello insomniacc,
Thank you for confirming that the first write succeeds, the second write fails, and that the behavior is the same with or without -Integrated. The fact that removing -Role allows the cache entry to be updated helps narrow this to the role-protected update path.
Could you please provide the following?
1. Your exact PowerShell Universal version and build.
2. The database provider in use: SQLite, SQL Server, or PostgreSQL.
3. How the script is executed, such as manually from the admin console, by a schedule, from an App, or through an API endpoint.
4. The PowerShell environment and any Run As identity configured for the script.
Could you also test with a new key, a non-sensitive value, and a test role?
Set-PSUCache -Key "RoleCacheTest" -Value "First" -Persist -Role "<TEST_ROLE>" -Integrated
Set-PSUCache -Key "RoleCacheTest" -Value "Second" -Persist -Role "<TEST_ROLE>" -Integrated
Get-PSUCache -Key "RoleCacheTest" -Integrated
Please let us know whether the final command returns "First", "Second", or also produces an error.
If possible, please include the PowerShell Universal server log entries from the same timestamp as the failed second write. We are specifically looking for the internal exception associated with the generic gRPC handler error.
Best regards,
Ruben Tapia
Sorry for the delay.
1.2026.2.3
2. SQL
3. Manually via admin console currently, but it will also be running on a schedule once i get it working.
4. Integrated. No Run As identity configured on the script, but my PSU instance runs as a service in the context of a domain service account.
I tried the example code in a new script.
I actually tested it with my administrators role which I have on my account, this should give full permissions to everything in my instance.
The output was as follows:
An exception: Grpc.Core.Internal.CoreErrorDetailException
and 'First'
1059f023-da2e-46bf-ab6f-abffb52122d0.png
Hello insomniacc,
Thank you for providing these details and for testing the simplified example. The results are very helpful, especially the confirmation that the first value remains stored after the second write fails.
We will adjust our lab environment today to match your configuration as closely as possible and attempt to reproduce the behavior. We will then review the findings with our Development team tomorrow.
We appreciate your contribution and the clear reproduction information.
Best regards,
Ruben Tapia
Hello insomniacc,
Thank you again for the detailed reproduction information.
We have now reproduced the same behavior internally using PowerShell Universal 2026.2.3 in an isolated environment.
Our control test without -Role successfully updated the persistent cache value from "First" to "Second". However, when -Role was specified, the first write succeeded and the second write failed, leaving the original value unchanged.
We also reproduced the behavior:
- With both the Administrator role and a custom test role.
- With and without -Integrated.
- With and without -Persist.
Based on these results, we are treating this as a reproducible defect in the role-protected cache update path rather than an issue specific to your SQL database or execution context.
We will review the laboratory findings and evidence with our Development team tomorrow. We will update this thread once we have their technical assessment or require any additional validation.
Thank you for your contribution and for providing a clear minimal reproduction.
Best regards,
Ruben Tapia
Just wanted to note, that I've seen the following behavior with Get-PSUCache:
In the PSU Admin menu my cached item shows data on the datetime columns:
While using Get-PSUCachewith the -Detail param returned this object:
8f4fd27f-358b-46b9-a1a5-a16719a6f8c4.png
c4a5d21e-781b-44eb-8657-bf47a3e317d0.png
Hello insomniacc,
Thank you for reporting this additional behavior and for including the comparison between the Admin UI and Get-PSUCache -Detail.
The values returned by the cmdlet appear to be the default DateTime values rather than the timestamps displayed in the Admin UI. We have added this finding to the case as a separate cache-related behavior because it may not have the same root cause as the role-protected update failure.
We have already reproduced the original Set-PSUCache issue internally in PowerShell Universal 2026.2.3. We will also validate the Get-PSUCache -Detail timestamp behavior in the lab and include both findings in our discussion with the Development team.
At this point, no additional testing is required from you. We will update the thread after the Development review or if we need a specific additional validation.
Thank you again for the detailed information and for helping us narrow down both behaviors.
Best regards,
Ruben Tapia
You're welcome, thanks for continuing to improve the product!