Write-PSULog does not work in the authentication form script. 2026.2.3
Hi,
I would like to log failed login attempts and have noticed that
Write-PSULog -Level Error -Message "error"
does not log at all when used inside the Authentication.ps1.
I would appreciate it if either Write-PSULogs could be used or if auth failures were logged by the platform natively.
A "auth failed" trigger event would also be helpful since there is already an event for API auth failure.
Hi,
I would like to log failed login attempts and have noticed that
Write-PSULog -Level Error -Message "error"
does not log at all when used inside the Authentication.ps1.
I would appreciate it if either Write-PSULogs could be used or if auth failures were logged by the platform natively.
A "auth failed" trigger event would also be helpful since there is already an event for API auth failure.
@Dynamic66
Hello Dynamic66,
Thank you for reporting this.
I understand that you are using PowerShell Universal 2026.2.3 and would like to log failed authentication attempts from `Authentication.ps1`, but `Write-PSULog` does not appear to generate a log entry when executed from that authentication flow.
I would like to narrow down whether this is specific to the authentication execution context or affects `Write-PSULog` more generally on the instance.
Could you please confirm the following?
* Are you using Forms Authentication?
* How is PSU hosted: Windows Service, IIS, Docker, or another method?
* Has this ever worked for you on an earlier PSU version, or was this first tested on 2026.2.3?
* Does the same `Write-PSULog -Level Error -Message "error"` command successfully create an entry when executed from a regular PSU script?
If possible, please also provide the minimum relevant section of `Authentication.ps1` showing where `Write-PSULog` is being called. I will also review this scenario for reproduction against PSU 2026.2.3.
Regarding a native failed-login event or trigger similar to `API Authentication Failed`, I will treat that separately while reviewing the current available behavior.
Best regards,
Ruben Tapia
Hello Dynamic66,
I apologize for the delay in getting back to you.
I wanted to let you know that today I will be working on reproducing your scenario in our lab, focusing on the behavior of `Write-PSULog` within the authentication flow on PowerShell Universal 2026.2.3.
I will review the results and update this thread once the testing is completed and we have more concrete findings to share.
Thank you for your patience.
Best regards,
Ruben Tapia
Hello Dynamic66,
Thank you for your patience while I tested this scenario.
I completed an isolated reproduction using PowerShell Universal 2026.2.3 with a minimal Forms Authentication configuration. In this environment, I was not able to reproduce the reported `Write-PSULog` failure.
The results were consistent across repeated tests:
* `Write-PSULog` worked from a normal Automation script.
* During successful Forms Authentication, both the common authentication message and the success-specific message were written successfully 3/3.
* During rejected authentication, both the common authentication message and the failure-specific message were also written successfully 3/3.
* I used an independent marker in the failed-authentication branch to confirm that the branch itself was being executed.
* The post-authentication checks correctly distinguished successful authentication from rejection.
Based on these results, I do not currently have evidence of a reproducible `Write-PSULog` defect in PSU 2026.2.3.
The next useful step would be to compare your configuration with the minimal scenario I tested. Could you please share:
* Your PSU hosting method, such as Windows Service, IIS, or Docker.
* The minimum relevant section of your Forms Authentication configuration showing where `Write-PSULog` is called.
* Where you expect the message to appear and which PSU logs you are checking.
* Whether the same `Write-PSULog` command works from a regular PSU script on the same instance.
Best regards,
Ruben Tapia
• Hosting Linux - Docker
• Database type: PostgreSQL
• Browser and version: Brave/Chromium
• Whether 2026.2.3 was a clean installation or upgrade, and the previous version: upgraded from 2026.2.3
• Whether any custom authentication or identity configuration is involved: no
Hey,
did some more testing.
in the log files i see that the error is log.
Form Authentication
Login users with a custom login script.
param(
[PSCredential]$Credential
)
$ErrorMessage = "Bad username or password"
Write-PSULog -Level Error -Feature "script" -Message $ErrorMessage
New-PSUAuthenticationResult -ErrorMessage $ErrorMessage2026-08-13 08:42:31.515 +00:00 [ERR][] Bad username or password
however in the live logs they never show up where usually they do for me when i use this cmdlet in apps, scripts and APIs.
from a script i can get this into the logs tab.write-psulog -Level Error -Message "hello from script" -Feature "script" -Console[8/13/2026 10:38:07 AM] [Error] [script-. '/home/data/Repository/Scripts/test.ps1'] hello from script
Hello Dynamic66,
Thank you for the additional testing and for clarifying what you are seeing.
This new information is very helpful. Since the message is being written to the log files successfully, we are going to adjust our lab to focus specifically on the difference between persisted logging and the Live Logs behavior.
We will update the test scenario to more closely match your environment and compare:
* Linux / Docker hosting
* Forms Authentication on PSU 2026.2.3
* `Write-PSULog` without `-Console`
* The same test with `-Console` as the only changed variable
* Authentication Live Logs versus `Platform > Logging`
* Successful and rejected authentication attempts
We will repeat the relevant tests to confirm whether the behavior is consistent and whether the difference is related specifically to the PowerShell console stream or to the logging UI.
For now, there is no need to provide additional logs. We will first complete this adjusted lab and share our findings here.
Thank you again for the detailed follow-up.
Best regards,
Ruben Tapia
Hello Dynamic66,
Thank you again for the additional details. We adjusted our lab to specifically test the difference you reported.
Using PSU 2026.2.3 on Linux/Docker, we found a consistent difference in Forms Authentication:
* Without `-Console`, `Write-PSULog` persisted the message successfully 3/3, but it did not appear in `Platform > Logging` 3/3.
* With only `-Console` added, the same message persisted 3/3 and appeared in `Platform > Logging` 3/3.
* We repeated the result with both SQLite and PostgreSQL, with identical behavior.
* A regular Automation script reached `Platform > Logging` with or without `-Console`, so the behavior appears specific to the Forms Authentication context under the conditions tested.
We are not declaring a root cause at this stage, but the behavior is deterministic in our lab.
Could you please try changing only your authentication logging line to:
`Write-PSULog -Level Error -Feature "script" -Message $ErrorMessage -Console`
Then let us know:
* Does the message still appear in the persistent log file?
* Does it now appear in the live logging view you are using?
* Is that view specifically `Platform > Logging`, or another Authentication Live Log view?
Because this is a public forum, please sanitize any screenshots or additional evidence before posting. Remove credentials, tokens, license keys, email addresses, usernames, internal domains, hostnames, IP addresses, and private URLs.
Best regards,
Ruben Tapia
Hey, the -Console parameter makes it work! Thanks
yes it still shows up in the persistent logs
2026-08-14 09:35:32.870 +00:00 [ERR][] Bad username or password 2026-08-14 09:35:32.871 +00:00 [ERR][PowerShellUniversal.Authentication.FormsAuthenticationService] Bad username or password
yes, i was talking about Platform > Logging and also noticed that it does not auto update the log even with the life check active.
Thanks for the help the issue can be closed :)
Hello Dynamic66,
Thank you for confirming.
I’m glad to hear that adding `-Console` resolved the Platform > Logging visibility issue while the messages continue to be written to the persistent logs.
Thank you as well for confirming the behavior regarding the live refresh. We have documented the findings from this investigation.
This topic can now be marked as resolved.
Best regards,
Ruben Tapia