在企业环境中管理填充程序的方法
在我于 2007 年 11 月发表的在企业环境中管理填充程序白皮书中，概括了在决定如何在组织中将填充程序作为应用程序兼容性解决方案进行管理时，大多数人会选择的两种主要方式。简单地说，它们是：
集中管理的单个填充程序数据库 通过这种方式，可以部署集中管理的单个填充程序数据库，这种数据库包含所有需要使用填充程序的应用程序的条目。这之后，发现其他应用程序需要使用修补程序时，可向中央数据库推出更新。这就是 Microsoft 所使用的方法。在发布 Windows 7 时，我们提供了一个系统填充程序数据库，它可以对数千个应用程序进行修复，在我们发现其他需要修复的应用程序时，则通过 Windows Update 向该数据库发布更新。您也可以这样做：将一个填充数据库放到主映像中，通过系统管理软件(如 System Center Configuration Manager)进行更新。
基于每个应用程序的填充程序数据库 另外，您也可以直接向应用程序部署应用程序修补程序。如果只有一两个应用程序需要修补程序，某些客户会选择这种方式，因为在小型环境中，与设置一个用于管理中央数据库的进程相比，这种方式成本更低。基于每个应用程序的填充程序数据库的一个明显缺点是，如果存在问题，更新填充程序数据库将会很困难。不过，App-V 没有这个缺点，现在，您可以对基于每个应用程序的数据库进行更新，然后将更新后的版本传送给用户。(不过，您将会看到，这引入了另外一个更加明显的缺点。)
Microsoft App-V 的软件部署方法拓宽了在企业范围内部署应用程序修补程序的选择，您可以选择一种最适合组织中现有进程模型的方法。
使用集中管理的单个填充程序数据库来填充 App-V 应用程序
从策略角度看，要部署集中管理的单个填充程序数据库并由使用 App-V 进行排序的应用程序选择该数据库，您必须做什么?很简单，按常规方法安装即可!使用 App-V 安装的应用程序的启动方式与应用程序的常规启动方式大致相同，这种应用程序使用应用了填充程序的加载程序机制。它们只是通过代理进程来启动。具体地说，sfttray.exe(而不是资源管理器)负责启动新的进程。因此，进程树如图 3 所示。
▲
图 3 代理进程树
应用程序启动时，它像任何其他应用程序一样运行加载程序。Microsoft Application Virtualization 客户端接口层 (sftintf.dll) 调用 CreateProcessW，后者调用内部的 API CreateProcessInternalW。填充程序引擎是在 CreateProcessInternalW API 中调用的，填充程序与该进程绑定。
那么，这就相当容易了。还有什么问题吗?是的，有一个。它不能很好地处理提升。例如，您不能简单地要求对某个应用程序进行提升(使用 RunAsAdmin 填充程序)，也不能对需要使用 ElevateCreateProcess 进行提升的应用程序的问题进行修复。为什么呢?原因是气泡图。
例如，我们来看一个尝试自行启动一次自动更新的应用程序(遗憾的是，这是一个十分常见的任务)。在以本机方式运行时，它产生了一个问题，即它使用了无法调用提升的 CreateProcess API。它随后返回错误 -1073740756 – STATUS_ELEVATION_REQUIRED。ElevateCreateProcess 填充程序捕获这个返回值，然后调用应用程序信息服务来提供提升。但该服务无法找到要提升的应用程序，因为该服务位于气泡图之外!
因此，只要应用程序不需要提升，在已创建一个进程的情况下，部署单个填充程序数据库解决方案就十分容易，您只需继续做相同的事情。
