Here is the technet post related to this. I will transfer what I've asked and tried to this post, but I am including it for reference.
Environment is: 2012 Domain Controller, Win 10 Endpoints, Powershell version 5.something*
Previously, I had SRP and AppLocker enabled through GPO for testing. It worked as expected so I pulled my computer back into the 'normal' AD group, and disabled Application Identity service. This was probably 3-4 days ago, so it's not just GP being slow to deploy.
I've also tried applying a 'negative' policy with an allow-all AppLocker and SRP policy applied, in case the old policy "tattoos" itself until over written, but I didn't seems to get any success doing this either.
I have found the following workarounds:
1) Launching Powershell as an administrator.
2) Launching Powershell using the -v 2 switch in order to launch Powershell 2.0 instead of 5.0.
3) I am almost certain that signing our scripts would allow them to run in Full Language, but I haven't tested.
Both of these place PS in Full Language mode.
However, I do not want to find a workaround that we have to keep in mind when deploying automated scripts - I want to restore the system to its configuration before I applied these GPOs, where Powershell launches in Full Language by default. I do not believe in deploying organization wide GPOs that aren't reversible. I don't want to have to explain how even if we roll back this GPO we'll be stuck running scripts in PS v2 or as administrator forever.
I have tried the fix listed here but
A) the environmental variable and the registry entry it corresponds to did not exist.
B) Creating that environmental variable as a system EV did not work. I did not try doing so as a user level EV because I don't think that's a viable solution.
*: It's not the PS version with the bug related to Constrained Language Mode. I forget which version that is and the specifics of the bug, but I confirmed I'm not running that specific version of 5.
