我有一个使用 Windows Installer 的内部应用程序。此应用程序的每次更新都是“重大升级”（不同的产品代码，相同的升级代码），它会调用 RemoveExistingProducts。（实际上，这意味着每次创建新版本时，您只需单击 MSI 文件即可安装它，因为它将卸载旧版本，然后安装新版本。）
目前，它是通过组策略中的机器配置部署的。任何链接的 GPO 都会在下次启动时安装该软件，效果很好。
我还有一个持续集成服务器 (TeamCity)，每次我们将某些内容提交到源代码控制并“固定”以进行部署时，它都会为该软件构建并运行测试。我甚至可以将新构建的 MSI 文件复制到网络共享以准备部署。
很遗憾，我没有找到以编程方式实际告诉 GPO 重新部署新更新的 MSI 文件的方法作为我的整合过程的一部分。
如果我只是覆盖现有的 MSI 文件而不触碰 GPO，那么安装了旧 MSI 的计算机就不会注意到此更改，而较新的计算机在组策略管理编辑器生成的脚本中找不到带有产品代码的 MSI 文件时会崩溃。很好，说得通。
如果我只是覆盖现有的 MSI 文件并单击 GPME 中的“重新部署应用程序”，似乎也会发生相同的行为。同样，我们似乎不高兴我们尝试使用包代码与 GPME 生成的脚本中的包代码不匹配的 MSI 文件进行重新部署。很好，有道理。
什么做工作是右键单击 GPME 中的安装包，点击“立即删除”，然后立即添加安装包 - 这将创建一个新的 *.aas 脚本，旧包将被删除，新包将在下次启动时安装。是否有某种方法可以通过批处理脚本来完成此操作，并将其添加到我的集成服务器的构建过程中？
谢谢！
后续更新
在回顾了 Evan 的言论后，我最终只编写了一个在启动时运行的小批处理脚本。我还编写了一个名为的小实用程序msicheck，用于确定是否安装了给定的 MSI 包。这足以满足我的需求，而且比翻阅 LDAP 规范页面要好得多！=)
答案1
我曾经想做一些类似的事情，并且过去也对这个话题做过一些研究。
我找不到任何公开的 API 来执行组策略编辑器正在执行的操作，即创建这些应用程序广告脚本 (.aas) 文件和 AD 中的相应记录。PowerShell 组策略 API 允许您配置基于注册表的设置，但不能配置其他组策略扩展的设置。
现在提到了组策略软件安装协议扩展（感谢欧盟反垄断协议！）我想您可以尝试自己使用引擎执行任务。执行包添加所需的 LDAP 事务和 .aas 文件的格式都在那里。看起来有点令人生畏（但很有趣）...
坦率地说，您对部署测试细节的关注值得称赞。我希望您编写的软件能被我的客户使用。您仅使用 Windows Installer 这一事实就让您领先于其他人。您了解组策略软件部署并实际对其进行测试，这让我很兴奋！我希望有相当一部分开发人员能够像您一样关心这个问题。