Update June 10th, 2021
As noted by user bbk in the comments, in recent versions of Windows 10 the script no longer have a static content but rather a dynamic one where part of the content includes date and time. Example:
- "# PowerShell test file to determine AppLocker lockdown mode 6/9/2021 15:15:08"
This also means that the hash no longer is static and cannot be excluded by mistake (which is good since you shouldn't have done that in the first place).
Update February 6th, 2020
It seems there have been some changes in how these files are used by Windows sometime since I wrote the original post and now. On a Windows 10 1909 I have observed the following:
- The content of the ps1,psm1 file is no longer "1" but rather
"# PowerShell test file to determine AppLocker lockdown mode " - The filehash is not reported in the eventlog for these event for me anymore (might just be my labsetup that is incorrect though).
- Found another good article discussing the topic further:
https://p0w3rsh3ll.wordpress.com/2019/03/07/applocker-and-powershell-how-do-they-tightly-work-together/
Original article below
If you are using AppLocker (which you should) and have enabled the function "MSI and Scripts" in AppLocker to whitelist only signed PowerShell scripts you will get some errors in the event log even though your scripts are signed. Checking the event viewer log for AppLocker events you will see that the logged on user tried to run 2 different scripts starting with __PSScriptPolicyTest and the extensions .ps1 and psm1. The full name is something like __PSScriptPolicyTest_bavjba32.xjg.ps1 where the name is __PSScriptPolicyTest_<8-random-numbers-and-letters>.<3-random-numbers-and-letters>.ps1/psm1

In my case I had a PowerShell logon script that was signed and allowed in AppLocker. The script itself ran as expected but the 2 PSScriptPolicyTest scripts was blocked in the log at the same time.

Troubleshooting
Troubleshooting this a little bit more I noticed that they are not signed and since they are located in "AppdataLocalTemp" we did not want to allow them by path (since the user have writing rights in that folder). The files got removed immediately after being created but I managed to capture them and the only content that was in them the was the number one:
1
The good thing is that it is always the same content and since AppLocker does not take the filename into account when creating a file hash I looked in the event log and saw that it was always the same file hash being blocked:
%OSDRIVE%\USERS\<USERNAME>\APPDATA\LOCAL\TEMP\__PSSCRIPTPOLICYTEST_FRWMRMNM.ZOV.PS1 was prevented from running.
UserData
- RuleAndFileData
PolicyName SCRIPT
RuleId {00000000-0000-0000-0000-000000000000}
RuleName -
RuleSddl -
TargetUser
TargetProcessId 7360
FilePath %OSDRIVE%\USERS\<USERNAME>\APPDATA\LOCAL\TEMP\__PSSCRIPTPOLICYTEST_FRWMRMNM.ZOV.PS1
FileHash 6B86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52DDB7875B4B
Fqbn -
TargetLogonId 0x2f813c
Once this hash was added to the whitelist:
6B86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52DDB7875B4B
Nothing was blocked in the event log any more and the logon script still ran without any issues.
Deep Dive
So what are those files really for? I have not found any official documentation about this behaviour so until I get some official confirmation that this is how it works it is just my assumptions.
Well it seems that these 2 script are being used to determine which Language Mode PowerShell is allowed to run in when using AppLocker! So by allowing them in the GPO the constraint mode was completely disabled for the user.

Since this is not wanted behaviour I removed the file hash for the PSScriptPolicyTest scripts so they got blocked by AppLocker again. After the GPO had been updated I checked Language mode for the user again:

Now it was back to the expected setting again.
Conclusions
- __PSScriptPolicyTest*.ps1/psm1 files are used to determine which Language Mode PowerShell will run in.
- Do NOT allow them (whitelist) in AppLocker since this will circumvent the Constraint mode security feature.
- If you are troubleshooting AppLocker the Errors in the event log for the 2 PSScriptPolicyTest scripts with the file hash 6B86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52DDB7875B4B can be safely ignored.
Hope this helps!
/Mattias
Mattias, any chance you could update this article again? I see it referenced a lot online, and the contents of the file are outdated. These ps1 files, in Windows 10, now appear to each contain a date/time stamp, thus changing the hash every time. The current phrase written to the file is formatted as "# PowerShell test file to determine AppLocker lockdown mode 6/9/2021 15:15:08"
Thank you for letting me know, have updated the post now!
Thanks for the article.
I am facing the similar situation. In end you have suggested not to put the hash in white list. Agree , but the what can be workaround if at all we want to run signed script in full language mode. is there any setting which we can do just before running the script and redo after running the script.
Please help.
You can allow these the same way as exe files using publisher or filehash. If you want to use signing you need to setup a PKI and create codesigning certs that the clients trust or by a real codesigning cert. https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/script-rules-in-applocker
If the script is allowed by applocker it will run in Full language mode. This should be easy to test. Create a script with the following code and allow it in applocker:
$ExecutionContext.SessionState.LanguageMode |out-file c:\temp\language.txt
Thank you so much! This was very helpful.
__PSScriptPolicyTest_<random_number>.ps1 files are generated by Microsoft Powershell to test against Applocker. If the file executes then it it assumed that Applocker is disabled. If the file does not execute then Powershell assumes it is enabled.
Thanks so much for the info – I've been receiving "Programs Blocked" logs through Trend – exactly the same info – (PSScriptPolicyTest) that you have described.
This is the first explanation that I could even start to understand!
I'm a simple desktop user – so didn't know what it was that was happening. Your answer has given me comfort to just ignore it!
Thanks again.
If I understand you correctly, there should be no path rule for this PSSCRIPTPOLICYTEST file in AppLocker??
If there's no AppLocker rule for this file, will it simply run normally without any alarming alerts going to the user??
The 8006 events for this file are the only last ones I need to eliminate before turning on AppLocker in our Citrix servers…
That is correct, these errors are "by design" and should be in the event log so you should not eliminate these. This is not something the normal user should notice (unless they explicitly look in the eventlog of course).
So anything along these lines: psscriptpolicystest*.ps1 and NETWORKDIAGNOSTICSRESOLVE.PS1 will just be noted in the log and not noticed by the user?? I'm just not wanting unexpected error messages for people to freak out about. 🙂 Thank you, Tom
Yes this is correct for my lab, but as always, test, test and test before going to production. My findings is from Windows Clients, I have not tested on servers or in citrix.
Thank you, I removed the path rule pertaining to psscriptpolicytest. Does this error, Description:
%OSDRIVE%\USERS\JANEDOE\APPDATA\LOCAL\TEMP\SDIAG_483FC606-45FD-4D80-A32F-44EBCB8B6BB7\NETWORKDIAGNOSTICSRESOLVE.PS1 was allowed to run but would have been prevented from running if the AppLocker policy were enforced., belong in the same realm??
Thank you, Tom
I'm not aware what the NETWORKDIAGNOSTICSRESOLVE.ps1 file does. And if this is something you will put in production I would recommened to test how it behaves in your environment. This is just my findings in my lab of how I THINK it works. This is not documented anywhere by Microsoft that I know of.
each time powershell is run the test scripts are reported with a different has for me so can't use the hash in the policy
Ok maybe there has been a change in never versions of Windows, I have not checked. Are you sure the hash changes and not just the filename? Also as I state in the post you should NOT whitelist the hash anyway since that will circumvent the security.
Mattias,
Fantastic article!
Could you please share how to managed to capture this file?
Thank you Richard! For this I simply created a small PowerShell script with a loop that tried to copy the file to another place. Once successfull it quit the loop. Since I knew the location (from the windows event) and also the filename (apart from the random in the middle). After I started the PowerShell script with the loop I ran another one in the user context and this would trigger PowerShell to create the temporary "__PSPolicyScript…" which the "loop script" then would catch and copy it to a place where I could examine it. There are also more advance… Read more »
Thank you for the article. It was the closest to the information i was after while trying to investigate some events detected on a Windows machines (using Endpoint Detection and Response tool).
I also like your strong advice on not whitelisting the locations. Too many times i read simple mistakes in AppLocker, which is an easy system, yet so effective.
Concise and easy to understand. Thanks 🙂