这里technet 帖子是否与此相关。我会将我询问和尝试的内容转移到此帖子中，但我将其作为参考。
环境为：2012 域控制器、Win 10 端点、Powershell 版本 5.something*
之前，我通过 GPO 启用了 SRP 和 AppLocker 进行测试。它按预期工作，所以我将我的计算机拉回到“正常”AD 组，并禁用应用程序标识服务。这可能是 3-4 天前的事了，所以不仅仅是 GP 部署缓慢。
我还尝试过应用一个允许所有 AppLocker 和 SRP 策略的“负面”策略，以防旧策略“纹身”直到被覆盖，但我这样做似乎也没有成功。
我发现了以下解决方法：
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.
这两种方式都会将 PS 置于全语言模式。
但是，我不想找到一种在部署自动化脚本时必须牢记的解决方法 - 我想将系统恢复到应用这些 GPO 之前的配置，其中 Powershell 默认以完整语言启动。我不相信部署不可逆的组织范围的 GPO。我不想解释即使我们回滚此 GPO，我们也将永远被困在 PS v2 中或以管理员身份运行脚本。
我已经尝试了列出的修复这里但
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.
*：这不是有与受限语言模式相关的错误的 PS 版本。我忘记了是哪个版本以及错误的具体内容，但我确认我没有运行该特定版本的 5。
答案1
因此，我最终找到的“修复”方法是在“反向”AppLocker 策略中添加“允许/签名者 *”。无论出于何种原因，这都可以解决签名脚本的问题。无论如何，我都会对脚本进行签名，以备将来使用，并计划对所有计划的脚本进行签名，因此就我的环境而言，这是“修复”的……不过，如果能有一个更实际的修复方法，即重置控件，那就太好了。