标签: app-v

App-V 是拥有少量但非常热情的粉丝群的技术之一。考虑到它可能对我的公司有用，我决定试一试。在对它进行了 2 周的深入研究并排序/发布了一些应用程序（Java、Reader、Citrix、Chrome 等）之后，我认为我对它的全部内容和功能有了很好的了解。

不幸的是，我很快得出结论，App-V 造成的问题多于它解决的问题，我发布这个问题是希望有人能帮助我理解我是否遗漏了产品的某些基本要点，或者App-V 不太适合我的环境。

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

承诺：应用共存。App-V 允许您一起打包和运行通常不能很好相处的应用程序。我们有两个业务线应用程序，它们分别依赖于专业版 Acrobat 9 和 Excel 2010。当安装现代版本的 Adob​​e Reader 或 MS Office 时，两者都会严重损坏，并且在 RDS 环境中都不能正常工作。由于 Office 和 Reader 是核心应用，我必须单独管理这些 PC，这很麻烦。App-V 应该允许我将这些应用程序连同它们的依赖项一起打包在 App-V 气泡中，这样它们就不会被它们本机安装的兄弟打扰。

现实： 它不是那样工作的。为了让共存正常运行，依赖应用程序（Acrobat Pro/Reader 和 Office 2010/2016）的两个实例都必须是虚拟的。这意味着我要么必须为整个组织将它们虚拟化，要么我仍然坚持单独管理这些 PC。App-V 没有给我任何东西。

Promise： App-V 允许您使用自己的自定义来打包应用程序，这样用户就不会看到诸如首次运行的对话框、无用的图标或他们不知道的信息提示（如服务器名称）等通常会生成帮助台的内容调用。

现实： 多年来，我在使用脚本、组策略等抑制所有垃圾方面做得非常好，所以我们已经在使用本机安装的应用程序来做到这一点。使用脚本和注册表黑客关闭这些程序所需的时间与在参考 PC 上对程序进行排序和自定义所需的时间大致相同。那里没有时间节省。此外，一些应用程序根本无法与 App-V 一起使用，因此您无论如何都必须编写脚本并破解它们。

承诺：虚拟应用程序完全沙盒化，提供更好的安全性和应用程序弹性。App-V 包不能相互交互，除非通过您控制的连接组。虽然微软明确警告这不是安全边界，但它确实减少了恶意软件的攻击面。此外，本机应用程序经常会在您的文件系统和注册表中留下垃圾，卸载时不会清除这些垃圾，从而使故障排除更加困难。但虚拟应用程序是独立的气泡，使它们很容易干净地删除或恢复到已知的良好状态。

现实： App-V 包不是 Docker 容器。它们对操作系统隐藏，但操作系统并未对它们隐藏。他们仍然在你的文件系统和注册表中留下垃圾。而且由于大多数应用程序都必须向操作系统公开 COM 接口，因此虚拟应用程序大多对操作系统隐藏，但并非完全隐藏。这使得故障排除更难，而不是更容易。此外，我们使用配置文件漫游、文件夹重定向，并拥有同质的桌面图像。任何需要一个多小时才能修复的计算机都会被破坏并重新加载。

承诺：流媒体内容。虚拟应用程序仅按需交付，并且仅占用人们实际使用的功能所需的磁盘空间。这很好，因为我们这里确实存在磁盘空间问题。此外，流内容可用于锁定的静态桌面，例如具有写入过滤器的瘦客户端或 VDI 方案。

现实：内容流传输太慢而无用。即使在具有 LAN 连接的标准工作站上，在获取和缓存包的关键位时首次启动也会有初始延迟。然后，随着新功能的使用，这些功能还有另一个延迟位。没有给出用户反馈，延迟时间长到让人们认为他们的电脑坏了。这会带来真正糟糕的用户体验。然后是笔记本电脑的问题。如果您在校外使用一个，那么如果您尝试使用尚未缓存的内容，那么您将陷入困境。您只能针对每个包缓解此问题，而不能针对每个设备缓解此问题。除非您使用的是 SCCM（我们使用的），在这种情况下，包从本地 SCCM 缓存“流”到本地 …