它目前通过组策略中的计算机配置进行部署.任何链接的GPO都会在下次启动时安装该软件,这非常有用.
我还有一个持续集成服务器(TeamCity),每当我们提交源代码控制并“部署”它时,就会为这个软件构建和运行测试.我甚至可以将新构建的MSI文件复制到网络共享以准备部署.
不幸的是,作为集成过程的一部分,我没有看到实际告诉GPO以编程方式重新部署新更新的MSI文件的方法.
如果我只是覆盖现有的MSI文件并且不接触GPO,那么安装了旧版MSI的机器就不会注意到这一变化,而当新的机器找不到包含产品代码的MSI文件时,它们会变得很糟糕.组策略管理编辑器生成的脚本.很好,很有意义.
如果我只是覆盖现有的MSI文件并在GPME中单击“重新部署应用程序”,则会出现相同的行为.同样,我们似乎不满意我们正在尝试使用MSI文件重新部署,该文件的包代码与GPME生成的脚本中的包不匹配.很好,很有意义.
什么工作是右键单击GPME中的安装包,点击“立即删除”,然后右后方添加安装包 – 这将创建一个新的* .aas脚本并删除旧包并在下一个安装新包开机.有没有办法通过批处理脚本执行此操作,我可以将其添加到集成服务器的构建过程中？
谢谢！
后续更新
在回顾了Evan的评论I ended up just writing a small batch script that runs at Startup之后.我还写了一个名为msicheck的小工具,它确定是否安装了给定的MSI包.这足以满足我的需求,并且比浏览LDAP规范的页面要好得多！ =)
没有暴露的API,我已经能够找到组织策略编辑器正在做的事情来创建这些应用程序广告脚本(.aas)文件和AD中的相应记录. PowerShell组策略API允许您配置基于注册表的设置,但不能配置其他组策略扩展的设置.
现在有一个对Group Policy Software Installation Protocol Extension的引用(感谢欧盟的反垄断解决方案！),我想你可以试着自己动作引擎来执行任务.执行添加包和.aas文件格式所需的LDAP事务就在那里.它看起来有点令人生畏(尽管很有趣)……
坦率地说,您对细节的关注：部署测试值得赞扬.我希望你写的是我的客户使用的软件.您单独使用Windows Installer这一事实使您处于领先地位.您了解组策略软件部署并且实际上正在测试它让我头晕目眩！我希望一些可测量的开发人员能够像你明确表达的那样关心.
