完全支持 Windows 7 的 Microsoft Application Virtualization (App-V) 4.6 即將發(fā)布；很多計劃部署 Windows 7 的客戶都將 App-V 納入為他們的桌面轉(zhuǎn)換項目的組件。（操作系統(tǒng)部署常常會使“最新桌面”或“下一代桌面”計劃中的應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)發(fā)生重大改變。）

當(dāng) IT 專業(yè)人員考慮同時對 App-V 和 Windows 7 進(jìn)行投資時，幾乎總會提出以下問題：

◇ 聽說 App-V 是一個應(yīng)用程序兼容性解決方案。這是否意味著它可以幫助我的應(yīng)用程序與 Windows 7 兼容？

◇ 我是否需要對已為當(dāng)前的 Windows XP 桌面創(chuàng)建的 App-V 程序包重新排序？

◇ 將 App-V 用作部署解決方案時，我該怎么做才能解決不兼容應(yīng)用程序問題？

下面開始逐個探討這些問題。

Microsoft App-V 是不是應(yīng)用程序兼容性解決方案？

Microsoft App-V 首先是應(yīng)用程序管理和部署解決方案，它可為企業(yè)帶來明顯好處：降低打包成本，提高系統(tǒng)穩(wěn)定性，通過動態(tài)訪問軟件資產(chǎn)為現(xiàn)在移動性很高的工作人員提供支持。但是，在營銷宣傳中，人們過多使用了應(yīng)用程序兼容性這個術(shù)語，隨著時間的推移，該術(shù)語已被曲解為：App-V 可幫助解決應(yīng)用程序與操作系統(tǒng)之間的兼容性問題。大多數(shù)情況下，它是無法解決這些問題的。（現(xiàn)在的例外情況主要是歷史原因造成的，不應(yīng)夸大它的作用，因此，我在此不進(jìn)行詳細(xì)介紹。）

對于客戶因此產(chǎn)生的混淆，我們在措辭上進(jìn)行了一定的澄清；我們現(xiàn)在已不使用“應(yīng)用程序兼容性”這個術(shù)語，而是直接談及基本優(yōu)點(diǎn)：可以減少應(yīng)用程序之間的沖突（請注意，我們有意避開了“兼容性”這個詞），因此，可以顯著減少回歸測試。

產(chǎn)品團(tuán)隊對應(yīng)用程序與操作系統(tǒng)兼容性的官方觀點(diǎn)如下：

從以前的討論可知，App-V 不是通用的應(yīng)用程序與操作系統(tǒng)兼容性解決方案；不過，如果應(yīng)用程序兼容性填充程序允許某個應(yīng)用程序以本機(jī)方式（非虛擬化）在給定 Windows 版本上運(yùn)行，則在大多數(shù)情況下，對于大多數(shù)填充程序而言，該應(yīng)用程序?qū)⒃趯μ畛涞膽?yīng)用程序虛擬化之后與 App-V 一起運(yùn)行。因此，一般而言，只要填充的應(yīng)用程序能夠以本機(jī)方式在目標(biāo)操作系統(tǒng)版本上運(yùn)行，App-V 就支持應(yīng)用程序使用填充程序（這些填充程序是作為 Microsoft 的應(yīng)用程序兼容性工具的組成部分提供的）。

因此，很顯然，App-V 無意作為應(yīng)用程序與操作系統(tǒng)兼容性解決方案。（我們將在本文后面部分討論如何將填充程序與 App-V 結(jié)合起來。）讓我們看一看應(yīng)用程序虛擬化對操作系統(tǒng)兼容性產(chǎn)生的其他影響。

#p#

Microsoft App-V 是不是程序包兼容性解決方案？

當(dāng)我們談及應(yīng)用程序兼容性時，自然要將程序包兼容性與運(yùn)行時兼容性區(qū)分開。事實上，我們所建議的應(yīng)用程序兼容性測試過程（如我在 2009 年 6 月的規(guī)劃您的應(yīng)用程序兼容性項目文章中的圖 3 所示）將安裝測試與運(yùn)行時測試區(qū)分開。讓我們從產(chǎn)品團(tuán)隊官方指南開始：

通常，可以在一個操作系統(tǒng)上排序，然后在另一個操作系統(tǒng)上運(yùn)行虛擬化應(yīng)用程序；但是，這種方案既取決于應(yīng)用程序，也取決于操作系統(tǒng)，未必適用于所有應(yīng)用程序/操作系統(tǒng)組合，因為 App-V 不是通用的操作系統(tǒng)兼容性解決方案。如果遇到問題，客戶可能需要在運(yùn)行 App-V 客戶端的操作系統(tǒng)環(huán)境中進(jìn)行排序，以便解決這些問題。

這聽起來并不怎么樣，官方觀點(diǎn)基本上是“視情況而定”。但是，當(dāng)您要考慮衡量風(fēng)險時，請比較現(xiàn)在所使用的三種基本安裝技術(shù)：

Setup.exe：這種方式將運(yùn)行任意代碼，從而該任意代碼將與應(yīng)用程序本身的任意代碼面臨相同的潛在運(yùn)行時問題，因此必須徹底進(jìn)行測試。

Windows Installer：這種方式也運(yùn)行代碼來執(zhí)行安裝，但所運(yùn)行的代碼大部分是結(jié)構(gòu)化的聲明代碼。只有自定義操作的命令性代碼是任意的，因此，除了規(guī)則中的可量化變化之外（這些規(guī)則會影響針對數(shù)據(jù)庫運(yùn)行的代碼以及自定義操作中的任意代碼的處理），有望獲得更好（不過仍不完美）的兼容性，需要的測試也會更少。

Microsoft App-V：這種方法根本不必運(yùn)行代碼。它只是在一個作為虛擬文件系統(tǒng)的數(shù)據(jù) Blob 上進(jìn)行復(fù)制，然后說“好的，您的虛擬文件系統(tǒng)在這里。”這樣，您主要關(guān)注的問題不是應(yīng)用程序是否會安裝（復(fù)制一個數(shù)據(jù) Blob 畢竟真的很容易），而是應(yīng)用程序的運(yùn)行時兼容性。因此，在所有三種技術(shù)中，這種方式的安裝測試是最短的。那真是太好了！

因此，盡管沒有官方說法表示程序包會全部正常運(yùn)行，但這種信息流傳開來的主要原因似乎是，很多人都將安裝問題與運(yùn)行時問題混為一談。一般而言，如果投資于 Microsoft App-V，就有望大大降低應(yīng)用程序安裝測試的預(yù)計成本。

#p#

應(yīng)用程序與 Microsoft App-V 一起打包時，如何解決運(yùn)行時兼容性問題？

還記得支持聲明中誘人的說法嗎？“App-V 將支持應(yīng)用程序使用填充程序（這些填充程序是作為 Microsoft 的應(yīng)用程序兼容性工具的組成部分提供的）....”實際上如何去實現(xiàn)這一點(diǎn)？這兩種程序是否基本上兼容？

令人高興的是，答案是肯定的。事實上，可以通過幾種不同的方式做到這一點(diǎn)。

填充程序簡要介紹

對于不熟悉填充程序的人來說，填充程序是 Microsoft 很少使用的四字母單詞之一，它不是某種縮寫詞。它以英語單詞“shim”（墊片）進(jìn)行比喻，這是一個工程術(shù)語，用于描述插在兩個物體之間，使它們更好地配合在一起的木片或金屬片。在我們的特定環(huán)境下，兩個物體就是應(yīng)用程序和 Windows，而墊片材料是使兩者更好地一起發(fā)揮作用的附加代碼，如圖 1 和 2 所示。
 

圖 1 應(yīng)用填充程序之前，應(yīng)用程序與 Windows 直接交互。

圖 2 應(yīng)用填充程序之后，應(yīng)用程序與 Windows 間接交互；填充程序代碼注入后，它可以修改向 Windows 發(fā)出的請求和/或來自 Windows 的響應(yīng)。

填充程序的作用是通過 API 偵聽實現(xiàn)的。Windows API 是使用 DLL 集合實現(xiàn)的。每個針對 Windows 構(gòu)建的應(yīng)用程序都導(dǎo)入這些 DLL，并在內(nèi)存中維護(hù)一個由所有這些功能的地址構(gòu)成的表。因為 Windows 功能的地址位于一個表中，所以，填充程序引擎直接用填充程序 DLL 的地址替換該地址。應(yīng)用程序通常不知道要將請求發(fā)送到填充程序 DLL 而不是發(fā)送到 Windows 本身，Windows 也不知道請求是來自應(yīng)用程序以外的源（因為填充程序 DLL 只不過是應(yīng)用程序進(jìn)程內(nèi)的另一個 DLL）。

例如，一個十分常用的填充程序是版本欺騙填充程序。為了實現(xiàn)此填充程序，將偵聽幾個用于確定運(yùn)行應(yīng)用程序的 Windows 版本的 API。通常，這種信息將傳遞給 Windows 本身，后者會如實應(yīng)答。但在應(yīng)用填充程序之后，這些 API 將被偵聽。這樣，將返回一個不同的 Windows 版本（例如，Windows XP 而不是 Windows 7），而不是將請求傳遞給 Windows。如果應(yīng)用程序編寫為只在 Windows XP 上運(yùn)行，這樣可以騙過應(yīng)用程序，使它認(rèn)為自己正在正確的操作系統(tǒng)上運(yùn)行。（通常，這樣就可以解決應(yīng)用程序兼容性問題！）

使用填充程序，可以采用很多技巧。例如， 

◇ ForceAdminAccess 填充程序嘗試使應(yīng)用程序確信當(dāng)前用戶是本地管理員組的成員，即使他并不是該組成員。（如果您不是本地管理員，很多應(yīng)用程序會徹底失敗，不過，您可以使用其他一些技巧（如 UAC 文件和注冊表虛擬化）來解決初始檢查所引起的問題。）實現(xiàn)這種檢查的方法可以非常簡單。例如，此填充程序從 shell32.dll 偵聽 API IsUserAnAdmin。所填充的功能的完整源代碼（與實際 API 相比，具有極好的性能特性）只返回 TRUE。

◇ WrpMitigation 填充程序使應(yīng)用程序安裝程序相信，它們可以寫入受 Windows 資源保護(hù) (WRP) 功能保護(hù)的文件。如果嘗試寫入受保護(hù)的文件，該填充程序首先創(chuàng)建一個新的臨時文件，一旦句柄關(guān)閉就將其標(biāo)記為已刪除，然后將句柄返回到該臨時文件，就好像它是實際受保護(hù)的文件。應(yīng)用程序?qū)⑴f版本 kernel32.dll 或 shell32.dll（或者在將其打包時它所選擇的任何其他文件）安裝到臨時文件中，但隨后該臨時文件消失，受保護(hù)文件的經(jīng)過修補(bǔ)的最新匹配版本保留在文件系統(tǒng)中。這樣，WRP 仍可確保您不會在自己的計算機(jī)上最終得到來自 Windows 95 的舊版本 shell32.dll，但在使用此填充程序時，安裝程序不會因 ACCESS_DENIED 而失敗。

◇ CorrectFilePaths 填充程序可將文件從一個位置重定向到另一個位置。因此，如果應(yīng)用程序嘗試寫入 c:\myprogramdir（不會使用 UAC 文件和注冊表虛擬化對它進(jìn)行自動修復(fù)），則可以將在運(yùn)行時修改的文件重定向到基于每個用戶的位置。這樣，您可以以標(biāo)準(zhǔn)用戶的身份運(yùn)行而不必放寬訪問控制列表 (ACL) 限制，因為您知道，安全人員不愿意放寬 ACL。

◇ 有數(shù)百個通用填充程序可用來解決應(yīng)用程序兼容性問題，利用這些修補(bǔ)程序可節(jié)省大量的成本。例如，客戶常常在以下情況下使用填充程序：

◇ 供應(yīng)商已停止經(jīng)營，因此無法獲得更新版本。如果您無法承擔(dān)從新供應(yīng)商處獲得另外的應(yīng)用程序或自己構(gòu)建新版本的費(fèi)用，這樣可以為您爭取一些時間。

◇ 應(yīng)用程序不是十分重要，不值得投資于更新版本（伴隨著支持聲明），但您的用戶樂于使用它，所以您不介意他們是否運(yùn)行不受支持的版本。

◇ 應(yīng)用程序是內(nèi)部開發(fā)的，但您不想非要等到團(tuán)隊發(fā)布完全更新的版本。相反，您愿意采用臨時性修補(bǔ)程序，允許開發(fā)團(tuán)隊在應(yīng)用程序的下一次計劃發(fā)布時發(fā)布永久性修補(bǔ)程序。通過這種方法，就不再需要停止所有應(yīng)用程序開發(fā)活動，可以投入時間和資源來修復(fù)兼容性 Bug。您可以使用臨時性修補(bǔ)程序，并允許團(tuán)隊發(fā)布包含開發(fā)過程中已實現(xiàn)的新功能的修補(bǔ)程序。

利用填充程序解決應(yīng)用程序兼容性問題，可以顯著節(jié)省成本，大大加速 Windows 7 的部署。

#p#

在企業(yè)環(huán)境中管理填充程序的方法

在我于 2007 年 11 月發(fā)表的在企業(yè)環(huán)境中管理填充程序白皮書中，概括了在決定如何在組織中將填充程序作為應(yīng)用程序兼容性解決方案進(jìn)行管理時，大多數(shù)人會選擇的兩種主要方式。簡單地說，它們是：

集中管理的單個填充程序數(shù)據(jù)庫 通過這種方式，可以部署集中管理的單個填充程序數(shù)據(jù)庫，這種數(shù)據(jù)庫包含所有需要使用填充程序的應(yīng)用程序的條目。這之后，發(fā)現(xiàn)其他應(yīng)用程序需要使用修補(bǔ)程序時，可向中央數(shù)據(jù)庫推出更新。這就是 Microsoft 所使用的方法。在發(fā)布 Windows 7 時，我們提供了一個系統(tǒng)填充程序數(shù)據(jù)庫，它可以對數(shù)千個應(yīng)用程序進(jìn)行修復(fù)，在我們發(fā)現(xiàn)其他需要修復(fù)的應(yīng)用程序時，則通過 Windows Update 向該數(shù)據(jù)庫發(fā)布更新。您也可以這樣做：將一個填充數(shù)據(jù)庫放到主映像中，通過系統(tǒng)管理軟件（如 System Center Configuration Manager）進(jìn)行更新。

基于每個應(yīng)用程序的填充程序數(shù)據(jù)庫 另外，您也可以直接向應(yīng)用程序部署應(yīng)用程序修補(bǔ)程序。如果只有一兩個應(yīng)用程序需要修補(bǔ)程序，某些客戶會選擇這種方式，因為在小型環(huán)境中，與設(shè)置一個用于管理中央數(shù)據(jù)庫的進(jìn)程相比，這種方式成本更低。基于每個應(yīng)用程序的填充程序數(shù)據(jù)庫的一個明顯缺點(diǎn)是，如果存在問題，更新填充程序數(shù)據(jù)庫將會很困難。不過，App-V 沒有這個缺點(diǎn)，現(xiàn)在，您可以對基于每個應(yīng)用程序的數(shù)據(jù)庫進(jìn)行更新，然后將更新后的版本傳送給用戶。（不過，您將會看到，這引入了另外一個更加明顯的缺點(diǎn)。）

Microsoft App-V 的軟件部署方法拓寬了在企業(yè)范圍內(nèi)部署應(yīng)用程序修補(bǔ)程序的選擇，您可以選擇一種最適合組織中現(xiàn)有進(jìn)程模型的方法。

#p#

使用集中管理的單個填充程序數(shù)據(jù)庫來填充 App-V 應(yīng)用程序

從策略角度看，要部署集中管理的單個填充程序數(shù)據(jù)庫并由使用 App-V 進(jìn)行排序的應(yīng)用程序選擇該數(shù)據(jù)庫，您必須做什么？很簡單，按常規(guī)方法安裝即可！使用 App-V 安裝的應(yīng)用程序的啟動方式與應(yīng)用程序的常規(guī)啟動方式大致相同，這種應(yīng)用程序使用應(yīng)用了填充程序的加載程序機(jī)制。它們只是通過代理進(jìn)程來啟動。具體地說，sfttray.exe（而不是資源管理器）負(fù)責(zé)啟動新的進(jìn)程。因此，進(jìn)程樹如圖 3 所示。
 

圖 3 代理進(jìn)程樹

應(yīng)用程序啟動時，它像任何其他應(yīng)用程序一樣運(yùn)行加載程序。Microsoft Application Virtualization 客戶端接口層 (sftintf.dll) 調(diào)用 CreateProcessW，后者調(diào)用內(nèi)部的 API CreateProcessInternalW。填充程序引擎是在 CreateProcessInternalW API 中調(diào)用的，填充程序與該進(jìn)程綁定。

那么，這就相當(dāng)容易了。還有什么問題嗎？是的，有一個。它不能很好地處理提升。例如，您不能簡單地要求對某個應(yīng)用程序進(jìn)行提升（使用 RunAsAdmin 填充程序），也不能對需要使用 ElevateCreateProcess 進(jìn)行提升的應(yīng)用程序的問題進(jìn)行修復(fù)。為什么呢？原因是氣泡圖。

例如，我們來看一個嘗試自行啟動一次自動更新的應(yīng)用程序（遺憾的是，這是一個十分常見的任務(wù)）。在以本機(jī)方式運(yùn)行時，它產(chǎn)生了一個問題，即它使用了無法調(diào)用提升的 CreateProcess API。它隨后返回錯誤 -1073740756 – STATUS_ELEVATION_REQUIRED。ElevateCreateProcess 填充程序捕獲這個返回值，然后調(diào)用應(yīng)用程序信息服務(wù)來提供提升。但該服務(wù)無法找到要提升的應(yīng)用程序，因為該服務(wù)位于氣泡圖之外！

因此，只要應(yīng)用程序不需要提升，在已創(chuàng)建一個進(jìn)程的情況下，部署單個填充程序數(shù)據(jù)庫解決方案就十分容易，您只需繼續(xù)做相同的事情。

#p# 

使用基于每個應(yīng)用程序的填充程序數(shù)據(jù)庫來填充App-V 應(yīng)用程序

通過部署填充程序來解決應(yīng)用程序兼容性問題的另一種方法是隨應(yīng)用程序部署填充程序。在 MSI 環(huán)境中，通常將 .sdb 文件包括在安裝程序中，然后加入一個自定義操作，該自定義操作針對它所放置的 .sdb 文件調(diào)用 sdbinst。這樣，會將自定義填充程序數(shù)據(jù)庫作為安裝程序的一部分來安裝。（如果您隨后需要對該應(yīng)用程序的填充程序進(jìn)行更新，則需要找到所有已安裝的客戶端，并運(yùn)行一個腳本來安裝更新，這會使事情變得有些復(fù)雜。）

您可以使用 App-V 完成幾乎相同的工作。您可將填充程序數(shù)據(jù)庫 (.sdb) 文件包括在序列本身之中，這樣 .sdb 文件就位于氣泡圖內(nèi)。首先，對需要使用填充程序的應(yīng)用程序進(jìn)行排序，以便其正常運(yùn)行。然后，將自定義填充程序數(shù)據(jù)庫放入 system32 中。

（盡管我通常會建議人們絕不要將任何內(nèi)容放到 system32 中，除非您的工資單是由 Steve Ballmer 簽發(fā)的，并且您的上級包括 Steven Sinofsky；在這種特定情況下，我才會選擇這樣做，因為這樣可簡化腳本編寫，system32 將在您的路徑中，并且不會在生產(chǎn)系統(tǒng)的 system32 中實際留下任何內(nèi)容，就像是在虛擬文件系統(tǒng)的 system32 中那樣）。

做完這項工作后，我將編輯 .sprj 文件。我瀏覽到“虛擬文件系統(tǒng)”選項卡，然后單擊“視圖”|“虛擬文件系統(tǒng)”|“添加”。然后，我瀏覽到放置 .sdb 文件的位置 (c:\windows\system32\appshim.sdb)，并單擊“確定”。此時，該 .sdb 文件將位于氣泡圖內(nèi)，并在安裝 softgrid 軟件包時進(jìn)行安裝。因為該文件是容器的一部分，所以它將作為應(yīng)用程序的一部分進(jìn)行傳送（可在更新應(yīng)用程序時進(jìn)行更新）。

當(dāng)然，要使用應(yīng)用程序修補(bǔ)程序，只是將 .sdb 文件放到文件系統(tǒng)中還不夠，還必須安裝這些修補(bǔ)程序。不過，填充程序數(shù)據(jù)庫必須安裝在 App-V 氣泡圖的外面。如果將填充程序數(shù)據(jù)庫安裝在氣泡圖內(nèi)，則在創(chuàng)建進(jìn)程之前，不會發(fā)現(xiàn)虛擬化的 .sdb 文件；創(chuàng)建進(jìn)程之后，填充程序找到該文件并針對它進(jìn)行操作已經(jīng)太晚。您需要使填充程序數(shù)據(jù)庫在創(chuàng)建進(jìn)程時能夠被氣泡圖外面的加載程序訪問。

令人高興的是，App-V 包含一個將腳本作為應(yīng)用程序啟動進(jìn)程的一部分來運(yùn)行的機(jī)制。如果您使用最喜歡的文本編輯器來查看應(yīng)用程序的 OSD 文件，就會發(fā)現(xiàn)只能對 XML 進(jìn)行編輯。<SOFTPGK> 元素包含一個 <IMPLEMENTATION> 元素、一個 <DEPENDENCY> 元素、一個 <PACKAGE> 元素、一個 <ABSTRACT> 元素、一個 <MGMT_SHORTCUTLIST> 元素和一個 <MGMT_FILEASSOCIATIONS> 元素。<DEPENDENCY> 元素是您需要編輯的元素，您將添加子 <SCRIPT> 元素，以便安裝自定義填充程序數(shù)據(jù)庫。下面是一個腳本示例，該腳本可在應(yīng)用程序啟動時安裝自定義填充程序數(shù)據(jù)庫，并在應(yīng)用程序退出時將其刪除（因此，這是一種可清理其身后內(nèi)容的 JIT 安裝，是 App-V 的一個重要目標(biāo)）：
 

通過該腳本，您可從 App-V 氣泡圖的外面調(diào)用填充程序數(shù)據(jù)庫安裝程序 (sdbinst.exe)，但要使用位于 App-V 氣泡圖內(nèi)部的 .sdb 的一個參數(shù)，該 .sdb 隨后將作為應(yīng)用程序部署序列的一部分進(jìn)行部署。因此，應(yīng)用程序修補(bǔ)程序的部署和更新十分容易，就像它們是該應(yīng)用程序的任何其他部分一樣。

自定義填充程序數(shù)據(jù)庫的安裝過程要求擁有管理員權(quán)限；在運(yùn)行時進(jìn)行安裝這是否會發(fā)生問題？您不希望您的用戶擁有管理員權(quán)限，您的用戶也不希望每次啟動應(yīng)用程序時都不得不單擊 UAC 對話框。令人高興的是，您無需那樣做；對 sdbinst.exe 的調(diào)用會自動提升。安裝填充程序的進(jìn)程樹如圖 4 所示。

圖 4 填充程序安裝進(jìn)程樹

將創(chuàng)建一個命令 Shell，該命令 Shell 隨后調(diào)用 sdbinst.exe 來安裝自定義填充程序數(shù)據(jù)庫。在調(diào)用應(yīng)用程序信息服務(wù)（提供提升的服務(wù)）之前，會失敗兩次，其錯誤為 STATUS_ELEVATION_REQUIRED。上述服務(wù)調(diào)用 consent.exe，后者對策略進(jìn)行檢查以確定是否應(yīng)提升應(yīng)用程序。策略（在虛擬環(huán)境中）返回“是”而無需提示用戶；consent.exe 批準(zhǔn)提升，并創(chuàng)建 sdbinst.exe 的一個提升實例，該實例將安裝自定義填充程序數(shù)據(jù)庫。但是請務(wù)必注意，不提示就提升的策略只有在您能提升的情況下才會無提示運(yùn)行。如果您是標(biāo)準(zhǔn)用戶，則每次啟動應(yīng)用程序都會出現(xiàn)一條需要管理員憑據(jù)的提示，每次關(guān)閉應(yīng)用程序也是如此。因為在標(biāo)準(zhǔn)用戶環(huán)境中人們非常不希望出現(xiàn)這種情況，所以，只有在已部署本地管理員用戶的情況下，這種方法才有效。我們希望只有極少的用戶需要應(yīng)用這種方法！

#p#

結(jié)論

Microsoft Application Virtualization 是一個功能強(qiáng)大的應(yīng)用程序管理和部署工具。如果在 Windows 7 遷移計劃中使用該工具，有可能降低安裝測試過程中的成本（不過，成本不會降到 0）。

繼續(xù)利用大多數(shù)同樣的過程，還可以使用填充程序解決應(yīng)用程序兼容性問題。如果要在組織范圍內(nèi)部署單個填充程序數(shù)據(jù)庫，要進(jìn)行的轉(zhuǎn)換任務(wù)很少，只需小心避免提升填充程序（與在 App-V 環(huán)境中通常應(yīng)避免提升的情況大體一樣）。如果要部署基于每個應(yīng)用程序的填充程序，可以使用一些適當(dāng)?shù)姆绞絹泶虬筒渴饝?yīng)用程序的填充程序數(shù)據(jù)庫，不過，這種情況下，有一個顯著的缺點(diǎn)，即無法合理地以非管理員用戶的身份運(yùn)行應(yīng)用程序。因此，強(qiáng)烈建議（就像在基于 MSI 的應(yīng)用程序部署中那樣）盡量以集中管理的單個數(shù)據(jù)庫的形式部署填充程序，這種情況下，可以使用現(xiàn)有的系統(tǒng)管理軟件進(jìn)行部署。如果采用這種方式，將來在您的用戶中，以非管理員身份運(yùn)行的用戶的比重會越來越大。

Chris Jackson（“應(yīng)用程序兼容性專家”）是 Microsoft 的首席顧問，也是 Windows 應(yīng)用程序體驗 SWAT 團(tuán)隊的技術(shù)主管。Jackson 是在 Windows 應(yīng)用程序兼容性領(lǐng)域享有盛名的專家，他根據(jù)多年與企業(yè)客戶和獨(dú)立軟件供應(yīng)商合作的實際經(jīng)驗，負(fù)責(zé)創(chuàng)建在 Microsoft 內(nèi)部和外部使用的技術(shù)文檔、培訓(xùn)和服務(wù)項目。可通過 Jackson 的廣受歡迎的博客與他聯(lián)系。

原文地址

本文來源：微軟TechNet中文站