我正在寻找有关 Windows 10 与 Windows 7 中 GPO 登录脚本的执行方式可能发生的任何更改的信息。
我有一个通过 GPO 为 Windows 7 设置的登录脚本 (powershell)。在测试 Windows 10 映像时，此脚本似乎先复制到我的本地配置文件临时文件夹 (c:\users\myaccount\appdata\local\temp)，名称为随机字符串 (dyyxi3ra.i2u.ps1)，然后再执行。这是一个问题，因为我们使用的管理软件通过设置的规则阻止了它。规则已经到位，只是刚刚在我的 Windows 10 测试映像上发现了这一点（7 仍在运行）。
有人知道这是预期的行为吗？这是 Windows 7 的变化吗？Google 没有帮助，而 TechNet 就像大海捞针，我不确定大海是否存在。
提前致谢。
ETA：这似乎是正常行为。第二次登录时，我收到类似的消息，提示脚本被阻止，并收到不同的随机字符串 .ps1。它再次尝试从本地配置文件临时文件夹运行。
我将通过签署脚本进行测试，但我必须先更新我的代码签名证书。我希望问题出在执行策略上，这将解决问题。
ETA2：在我的测试中，似乎每次执行远程存储的脚本时，它都会将某些内容（脚本本身？）复制到本地配置文件临时文件夹中的临时文件中。包括登录脚本。如果有人能向我提供一些相关文档，我将不胜感激。
ETA3：迄今为止的调查结果更新...
这似乎是 powershell V4 及更早版本与 V5 之间的一些变化。我在 Windows 7 设备上安装了 WMF5，安装后，我可以复制在 Windows 10 设备上看到的相同行为。
我找到了一篇文章，解释了与我所看到的类似的事情，但他们使用的是 AppLocker。
https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx
我认为 Bit9 可能正在检测 powershell 语言模式并触发它，但将模式从 FullLanguage 更改为 ConstrainedLanguage 似乎对我的环境没有任何影响。
https://technet.microsoft.com/en-us/library/dn433292.aspx
我不知道这是否会在任何人心中触发任何东西，但 Powershell 命令提示符会触发 Bit9 通知，而 Powershell ISE 不会。我在两者中都运行了 get-module 来查看正在加载哪些模块，并在设备之间进行了比较。至少有一个设备在启动时没有加载任何模块，所以我排除了模块是罪魁祸首的可能性。powershell.exe 和 ISE 之间有什么不同可能导致应用程序白名单应用程序触发？
答案1
长话短说，为了与 AppLocker 兼容，微软在 powershell v5 中内置了在启动时将 .ps1 文件（可能还有 .psm1）写入 %temp% 的功能，以确定以哪种语言模式启动。
监控从 %temp% 启动的脚本是一种很好的安全做法。不幸的是，如果您使用应用程序白名单应用程序来执行此操作（如 Bit9 或 AppLocker），并创建一个规则来监控使用该目录基于文件扩展名的 powershell 脚本，则每次启动 powershell 时都很有可能触发该规则。
至少就我而言，这意味着任何时候在用户上下文中运行 .ps1 文件（例如 powershell 登录脚本），它都会触发白名单应用程序的通知并可能阻止该脚本。脚本签名和执行策略设置在我测试中无关紧要。
一些相关链接可供进一步了解信息：
https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx
https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
https://community.spiceworks.com/topic/1451109-srp-whitelist-causing-odd-behavior-in-powershell-v5