我有一个使用Windows Installer的内部应用程序。 此应用程序的每个更新都是“主要升级”（不同的产品代码，相同的升级代码），并调用RemoveExistingProducts。 （实际上，这意味着只要点击MSI文件就可以安装新版本，因为它会卸载旧版本，然后安装新版本。）
它目前通过组策略中的机器configuration进行部署。 任何关联的GPO将在下次启动时安装该软件，而且这个工作很好。
我也有一个持续集成服务器（TeamCity），每次我们提交源代码控制和“钉住”部署的时候，都会为这个软件构build和运行testing。 我甚至可以将新build的MSI文件复制到networking共享中，以备部署。
不幸的是， 我没有看到实际告诉GPO作为我的集成过程的一部分以编程方式重新部署新更新的MSI文件的方法。
如果我只是覆盖现有的MSI文件，而不触摸GPO，那么更改不会被安装了旧版MSI的机器发现，而当新的机器无法find带有产品代码的MSI文件由组策略pipe理编辑器生成的脚本。 好，有道理。
如果我只是覆盖现有的MSI文件，并在GPME中单击“重新部署应用程序”，似乎也会发生同样的行为。 再一次，我们似乎很不高兴，我们试图重新部署一个MSI文件，它的软件包代码与GPME生成的脚本不匹配。 好，有道理。
在GPME中右键点击安装包，点击“立即删除”，然后右键添加安装包 – 创build一个新的* .aas脚本，旧的包被删除，下一个安装的新包开机。 有一些方法可以通过批处理脚本来完成，我可以将其添加到集成服务器的构build过程中？
谢谢！
在回顾了Evan的评论之后， 我最终只写了一个在Startup上运行的小批量脚本 。 我还写了一个名为msicheck的小工具，用于确定是否安装了指定的MSI软件包。 这足以满足我的需求，而且比通过LDAP规范的页面浏览要好得多！ =）
我曾经有过类似的想法，并且对过去的话题做过一些研究。
没有公开的API，我已经能够find组策略编辑器正在做什么来创build这些应用程序广告脚本（.aas）文件和AD中的相应logging。 PowerShell组策略API允许您configuration基于registry的设置，但不能configuration其他组策略扩展的设置。
现在提到了组策略软件安装协议扩展 （感谢欧盟的反托拉斯解决scheme！），我想你可以尝试和推出引擎来自己执行任务。 执行添加软件包所需的LDAP事务以及.aas文件的格式在那里。 它看起来有点令人生畏（虽然很有趣）…
坦率地说，你对注意细节部署testing是值得赞扬的。 我希望你正在编写我的客户使用的软件。 单独使用Windows Installer的事实使您领先于包装。 你知道组策略软件部署，实际上是testing它让我头晕！ 我希望有一小部分开发者关心你所做的事。