通过GPO更新MSI的问题(无法覆盖/卸载)

时间:2015-09-28 05:19:05

标签: windows windows-installer updating group-policy gpo

提前感谢您考虑这个问题。如果存在类似问题,我无法找到它。

问题:我们公司将应用程序打包到MSI中。在任何GPO之外安装时,此MSI会正确更新,阻止尝试降级(或从较高版本升级到较低版本),并且无论多久以前创建/安装这些版本,都无需卸载以前版本的应用程序。例如,我们可以安装1.2.3版本,然后安装版本2.3.4,应用程序将正确安装而不会出现问题。但是,我们与使用GPO的客户合作,将我们的应用程序部署到数百台PC上。每次我们提供应用程序的更新版本时,都会指出以下内容:

在通过GPO安装以前版本的应用程序的任何计算机上,无论以前的版本是什么,更新都会成功安装而不会出现问题。

在手动安装应用程序的计算机上(在GPO之外),并尝试通过GPO更新应用程序 - 除了旧版本之外还安装了应用程序,或者保留了注册表项。以前版本的应用程序和应用程序无法正常打开/运行。在这种情况下,必须手动删除注册表项,然后再次从干净的计算机尝试安装。

我们所知道的是,在最初通过GPO安装应用程序的任何机器上 - 更新应用程序都没有问题。在首先未使用GPO安装应用程序的每台计算机上,通过GPO进行更新失败,并出现上述问题之一。

我的问题是:是否存在技术问题,如何通过GPO部分处理安装? GPO是否需要对应用程序的整个生命周期负责?或者,合理的期望是,在安装了原始版本(在GPO之外)的原始版本的机器上,以及最初从GPO中安装应用程序时,应用程序是否都会更新?

我们知道的一个解决方案就是让所有计算机都管理应用程序生命周期(因为我们知道更新在该环境中工作),但这意味着许多计算机需要手动删除手动安装的版本 - 然后通过GPO正确处理安装,这是一项广泛的工作。

我们非常欢迎任何解决方案,正式阐述正确管理或期望的技术文档或信息链接。我们的研究表明,在GPO中管理整个应用程序生命周期是“最好的” - 但我还是无法确定这样做是否100%是必要的。

期待任何帮助。如果需要任何进一步的技术细节来帮助解决问题的可行性,请随时索取详细信息。

1 个答案:

答案 0 :(得分:0)

如果您最终在控制面板中安装了两个版本,那么所有其他事情都是正确的,最可能的解释是您使用每台计算机安装升级了每用户安装(反之亦然)。在GPO世界中,将其分配给用户或计算机,就像这样。通过获取详细日志并检查FindRelatedProducts操作以查找另一个产品但在不同的上下文中的指示,可以轻松验证。

当您一直处于GPO模式时,我假设每个人(无论是每个用户还是每台机器)都是一致的,因此升级始终有效,但他们不会交叉工作-context。

我相信GPO在大多数情况下都会抑制UI,而UI(或UI序列)有时会设置每个用户/每台机器。这可能是导致它的其他原因,具体取决于GPO如何发布到计算机或用户。