不幸的是,我很快得出结论,App-V产生的问题比解决的问题多得多,我发布这个问题是希望有人可以帮助我理解我是否遗漏了产品的某些基本要点,或者是否App-V不适合我的环境.

所以这是我理解的App-V承诺列表,以及我观察到的现实：

承诺：应用程序共存. App-V允许您将通常无法相处的应用程序打包和运行.我们有两个业务线应用程序,分别依赖于Pro版本的Acrobat 9和Excel 2010.当安装了现代版本的Adobe Reader或MS Office时,两者都可怕地破坏,并且在RDS环境中都不能很好地工作.由于Office和Reader是核心应用程序,我必须单独管理这些PC,这是一个痛苦的屁股. App-V应该允许我将这些应用程序与它们的依赖项打包在App-V泡泡中,这样它们就不会受到本机安装的兄弟的干扰.

现实：它不起作用.为了使共存正常运行,依赖应用程序(Acrobat Pro / Reader和Office 2010/2016)的两个实例都必须是虚拟的.这意味着我要么必须让它们为整个组织虚拟化,要么我仍然无法单独管理这些PC. App-V对我没有任何帮助.

承诺：App-V允许您使用自己的自定义程序打包应用程序,以便用户看不到首次运行的对话框,无用的图标或提示他们不知道的信息(如服务器名称),这些信息通常会生成帮助台调用.

现实：多年来我通过脚本,组策略等来抑制所有垃圾,我已经非常好了,所以我们已经使用本机安装的应用程序来实现这一点.使用脚本和注册表黑客程序关闭这些程序所花费的时间与在参考PC上对程序进行排序和自定义所需的时间大致相同.那里没有时间节省.此外,一些简单的应用程序不适用于App-V,所以你必须编写脚本并破解它们.

承诺：虚拟应用程序完全沙箱化,提供更好的安全性和应用程序弹性.除了您控制的连接组之外,App-V软件包不能相互交互.虽然微软明确警告说这不是安全边界,但它确实减少了恶意软件的攻击面.此外,本机应用程序经常在您的文件系统和注册表中留下粪便,在卸载时不会被清除,从而使故障排除更加困难.但虚拟应用程序是自包含的泡泡,使它们易于干净地移除或恢复到已知的良好状态.

现实：App-V包不是Docker容器.它们对操作系统是隐藏的,但操作系统并未对它们隐藏.他们仍然在你的文件系统和注册表中留下粪便.而且由于大多数应用程序都必须将COM接口暴露给操作系统,因此虚拟应用程序大部分都是从操作系这使得故障排除更难,而不是更容易.此外,我们使用配置文件漫游,文件夹重定向,并具有同类桌面映像.任何需要一个多小时才能修复的计算机都会被修复并重新加载.

承诺：流媒体内容.虚拟应用程序仅按需提供,并且只占用人们实际使用的功能所需的磁盘空间.这很好,因为我们周围有一个磁盘空间问题.此外,流式内容可用于锁定的静态桌面,例如具有写入过滤器的瘦客户端或VDI方案.

现实：内容流传输速度太慢而无法使用.即使在具有LAN连接的标准工作站上,首次启动时也会出现初始延迟,同时提取和缓存包的关键位.然后,当使用新功能时,这些位还有另一个延迟.没有给出用户反馈,延迟时间足以让人们认为他们的计算机坏了.这会带来真正糟糕的用户体验.然后是笔记本电脑的问题.如果你带一个校外课程,如果你试图使用一些尚未缓存的东西,你就会死在水中.您只能缓解每个程序包的问题,​​而不是每个设备.除非你使用SCCM(我们是),在这种情况下,软件包从本地SCCM缓存“流”到本地App-V缓存,占用TWICE的空间.好极了！

所以我重申我的问题. App-V有什么好处？我可以看到虚拟化应用程序的一些巨大好处,并且有完整的网站专门用于App-V配方和技术.我想要喜欢这个产品.但是由于我所概述的问题,我无法证明这一点.

或者我在这里遗漏了什么？