Microsoft Application Virtualization
在一個虛擬化環境中進行應用程式與 Windows 7 相容
Chris Jackson
Microsoft 應用程式虛擬化 (App-V) 4.6，boasting Windows 7 的完整支援右周圍角落 ； 規劃 Windows 7 部署的許多客戶都包括 App-V 其桌面轉換專案元件之間。 (OS 部署經常會結合與應用程式和 「 現代桌面 」 或 「 下一代桌面 」 開發案中的基礎結構的 overhaul)。
當 IT 專業人員認為有關配對投資在 App-V 和 Windows 7 時，下列問題幾乎都變成交談的一部分：
- 我聽說 App-V 是應用程式相容性的解決方案。 意思就能協助讓我的應用程式與 Windows 7 相容呢？
- 我需要 re-sequence App-V 封裝我已經建立的我目前的 Windows XP 桌上型電腦嗎？
- 我該怎麼來補救不相容的應用程式，當我使用 App-V 我部署的方案?
let’s 探索每個這些問題。
一個應用程式相容性的解決方案是 Microsoft App-V 嗎？
Microsoft App-V 是，先和 foremost 的應用程式管理及部署解決方案可以傳達至企業的明顯好處 — 降低封裝成本、 增加系統穩定性和支援動態存取軟體資產今天 ’s 高度行動工作團隊。 但成長錯譯經過一段時間多載的詞彙 應用程式相容性 行銷訊息的一部分：該 App-V 可以協助在應用程式和作業系統之間的相容性問題。 在大多數的情況下，can’t。 (這些例外狀況今天大多是針對歷史原因存在而且不東西定，讓我 won’t 進入此處的詳細資料)。
在訊息某些釐清導致產生客戶混淆 ； 我們現在 forego 「 應用程式相容性 」 一詞的使用，而是直接對基礎優點說話：您減少 (請注意策略性省略的單字相容性) 的應用程式對應用程式衝突，並，如此一來您大幅減少迴歸測試。
這是產品小組上的應用程式 OS 相容性的官方的立場來：
如先前的討論區中所述，App-V 不是一般用途的應用程式 OS 相容性解決方案 ； 不過，如果應用程式相容性填隙允許在指定的 Windows 版本上工作的原生應用程式虛擬 (非-化)，它會在大多數情況下和大部分修正使用 App-V 時 shimmed 應用程式虛擬化。 因此，一般的規則 App-V 會支援應用程式所使用的修正，只要 shimmed 應用程式可以在目標的 OS 版本上執行原本所提供 Microsoft ’s App Compat 工具的一部份。
所以，它 ’s 很清楚 App-V isn’t 要成為一個應用程式 OS 相容性的解決方案。 (我們會討論與 App-V 本文稍後的結合修正)。let’s 查看其他該應用程式虛擬化對作業系統相容性的影響。
是 Microsoft App-V 封裝相容性解決方案嗎？
當我們談論應用程式相容性時，它 ’s 公平到不同的套件相容性從執行階段相容性。 在實際上我們建議的程序的應用程式相容性測試 (圖 3] 所示的我六月 2009年發行項上 規劃您的應用程式相容性專案 ) 分隔安裝測試從執行階段測試。 let’s 開頭官方的產品小組指引：
它通常是可以一個作業系統上的序列，並且在不同的 OS 上執行虛擬化應用程式 ； 不過，這種情況下是這兩個應用程式和作業系統相關，而且不保證會因為 App-V 不是一般用途 OS 相容性解決方案適用於所有的應用程式/OS 組合。 如果遇到問題客戶可能需要在相同的作業系統環境上的序列 App-V 用戶端正在執行來解決這些問題時。
好讓這聽起來 doesn’t 因此周到 — 基本上官方的立場來是、 「 它相依 」但當您思考衡量風險，比較三種主要安裝程式技術在今天使用：
Setup.exe： 這執行任意程式碼，並因此任意的程式碼受限於應用程式本身的任意的程式碼是，在同一個潛在執行階段問題因此它會有經過徹底的測試。
Windows 「 安裝程式： 這樣也會執行程式碼執行的安裝，但大部分的這段程式碼是結構化、 宣告式程式碼。 只有自訂動作的命令式程式碼是任意，所以之外會影響針對資料庫和自訂動作中任意的程式碼執行的程式碼處理的規則中的可量化變更，您預期更好 (不過仍不完美) 相容性和較少的測試。
Microsoft 應用程式-五部分： 這 doesn’t 有執行程式碼。 它只會複製的是的虛擬檔案系統，然後說明 「 好，您的虛擬檔案系統是這裡 」 的資料 Blob 透過。所以，您主要的考量 isn’t 是否將會安裝應用程式 (複製資料的一個 Blob 是，畢竟、 真的簡單)，’s 應用程式的執行階段相容性。 所以，您預期安裝測試最短的所有三種技術。 ’s 善良!
所以，雖然沒有人即將正式說封裝將所有作用，它似乎在傳訊的主要的原因是許多人 conflate 安裝問題和執行階段問題。 在一般，您可以搜尋減少您預計的成本，如果您已經有投資在 Microsoft App-V 大幅測試的應用程式安裝。
做我要如何修正執行階段相容性問題時我的應用程式封裝與 Microsoft App-V？
還記得 tantalizing 元從支援陳述式嗎？ 「 應用程式-V 將支援應用程式所使用的 Microsoft ’s App Compat tools… 中提供的修正 」。如何您實際上實作的？ 是否兩個基本上相容吗？
幸運的是，答案是沒錯。 在實際上您有幾個這樣的不同選項。
在修正簡短入門
對於那些您修正不熟悉的一個填隙是一種非常幾個使用中的 Microsoft isn’t 縮略字的一些排序四-字母字。 ’s 比喻，依據英文單字填隙，是用來描述木頭或金屬插入兩個物件，使它們之間的一段的工程詞彙大小一起更佳的保護。 在此特定案例兩個物件是應用程式和 Windows，並填隙材料是使這兩個行為更能一起， 目錄 1 和 2 中所示的額外程式碼]。
.png)
圖 1 應用程式之前套用 「 填隙互動直接與 Windows。
.png)
圖 2 套用 「 填隙之後應用程式互動 Windows 間接 ； 填隙程式碼插入，可以修改要求 Windows、 從 Windows，回應或兩者
一個填隙運作方式使用 API 攔截。 Windows API 被實作使用 DLL 的集合。 每一個建置 Windows 應用程式匯入這些 DLL，並會保留在記憶體中這些函式的每一個地址的表格。 因為 Windows 功能的位址坐在資料表中，很直接了當填隙引擎來代替填隙 DLL 的位址以取代這個地址。 應用程式是要求移至填隙 Windows 本身，而不是 DLL，然後 Windows 會不知道 (因為 Shim DLL 是應用程式 ’s 處理序內的只是另一個 DLL) 的要求來自應用程式以外的其他來源通常不清楚。
比方就說很常用填隙是版本 lie 填隙。 若要實作此填隙，我們攔截用來判斷哪個版本的 Windows 應用程式執行的數種 API。 通常，這項資訊傳入 Windows 本身，而且它 truthfully 解答。 與套用 Shim，但是，這些 API 會攔截。 而不是在要求上傳遞至 Windows 的不同版本的 Windows 就會傳回 (如範例為 Windows XP，而非 Windows 7)。 如果應用程式設計成只在 Windows XP 上執行，這是一種一輪到相信它應用程式在正確的 OS 執行的方法。 (通常這是所有必要解決應用程式的相容性問題 ！)
有巨大的技巧，您可以播放與修正一些。 例如：
- 欺騙成相信目前的使用者本機的系統管理員群組的成員，即使他不是應用程式嘗試 ForceAdminAccess 填隙。 (許多應用程式完全失敗如果您不是本機系統管理員雖然您可以使用其他技巧例如 UAC 檔案和登錄虛擬化來解決造成檢查一開始的問題)。如何實作這項檢查可以是相當簡單。 比方說這個 Shim 會攔截 API IsUserAnAdmin 從 shell32.dll。 shimmed 函式 (其中有太效能特性相較於實際的 API) 的完整原始程式碼是 TRUE ； 只是傳回
- WrpMitigation 填隙技巧應用程式安裝到相信他們可以受到保護 Windows 資源保護 (WRP) 的檔案寫入。 如果嘗試寫入保護的檔案 Shim 首先會建立一個新的暫存檔案標記它以一旦控制代碼已關閉，並再傳回暫存檔案控制碼，它就像實際受保護的檔案被刪除。 應用程式會 crusty 舊版的 kernel32.dll] 或 [shell32.dll] (或兩者其他檔案時已被封裝撿起它) 安裝到暫存檔案，但再該暫存檔案消失，並受保護的檔案相符、 已經安裝補充程式的最新版本仍然會保留在檔案系統上。 所以，WRP 可以仍確保 don’t 與 shell32.dll 從 Windows 95 的古老複本結束您的電腦上，但是安裝程式 won’t 失敗 ACCESS_DENIED，當您使用此填隙。
- CorrectFilePaths 填隙可以將檔案從一個位置到另一個重新導向。 因此如果您嘗試要寫入 c:\myprogramdir (其會自動 isn’t 固定使用 UAC 檔案和登錄虛擬化) 的應用程式，您可以重新導向到每一使用者位置的執行階段時，會修改的檔案。 這可讓您以標準使用者身分執行而不必放鬆存取控制清單 (ACL) 因為您知道安全性同仁討厭它時放鬆 ACL。
- 有數百個一般用途的程式可以解決應用程式相容性問題的修正，而且它可以是明顯的成本將檔案儲存至能夠善用這些修正程式。 比方說客戶通常使用修正時：
- 廠商是商業用完，因此它們有沒有取得更新的版本的選項。 如果您 can’t 負擔取得不同的應用程式從新的廠商，或是自行建置新版本的這可以購買您一些時間。
- 應用程式 isn’t 重要到投資在更新的版本 (這會隨附支援陳述式)，不過因為它讓您的使用者快樂 don’t 介意是否它們執行不支援的版本。
- 在內部所開發應用程式，但您 don’t 想必須等待釋放完全更新的版本小組。 而是，您偏好套用暫時修正程式，並讓開發小組放開永久的修正程式搭配應用程式其下一個排定的版本。 使用這個方法不再需要停止所有的應用程式開發活動，並投入時間和資源來修正 Bug 的相容性。 可以套用暫時修正程式，並讓團隊於它已經是開發中間的新功能釋放了修正程式。
運用修正為您的應用程式相容性方法的一部份，可以導致省下顯著的成本，並大幅加速部署 Windows 7。
管理企業中的修正的選項
管理修正在企業中 從 2007 年十一月上的我份] 白皮書我大綱之間決定如何管理修正作為其組織中的應用程式相容性解決方案時選擇的大多數人的兩個主要選項。 若要簡短翻新它們是：
單一集中管理 Shim 資料庫 使用此選項部署包含對每個需要一個填隙的應用程式的項目的單一、 集中管理填隙資料庫。 您可以再發送出更新到中央資料庫時發現需要修正程式的其他應用程式。 這是 Microsoft 會使用的方法。 我們推出 Windows 7 與修正數千個應用程式，系統填隙資料庫，並如同我們找到更多我們交運透過 Windows Update 資料庫的更新。 將填隙資料庫到主映像和更新透過您的系統管理軟體 (例如系統中心組態管理員)，您可以執行相同的動作。
每個應用程式 shim 資料庫 或者，您可以部署應用程式直接與應用程式的修正程式。 有些客戶選擇要執行這項操作，因為它可以是成本較小型的環境中設定的管理中央資料庫的程序它們只會有一或兩個應用程式需要修正程式時。 每個應用程式填隙資料庫的重大缺點是它變得非常困難更新填隙資料庫，如果有任何問題。 不過，App-V 移除這一個缺點為現在您可以更新每個應用程式資料庫和所串流出您的使用者是更新的版。 (不過，您將會看到這介紹另一個更明顯的缺點)。
Microsoft App-V 用來部署軟體的方式 broadens 的選擇了 [在企業內部署應用程式的修正程式，而您可以選擇最佳無論使用何種方法適合處理序模型目前在組織中的位置。
shimming App-V 具有單一的應用程式，集中管理填隙資料庫
所以，戰術的觀點而言您有何可以部署單一且集中管理填隙資料庫，並讓其收取的應用程式使用 App-V 編序? ’s 簡單 — 像平常一樣只安裝! 使用 App-V 安裝應用程式就會啟動在很多相同的方式在應用程式通常會是，並使用相同的載入器機制修正套用的位置。 它們只是由代理程序啟動。 特別，sfttray.exe 是什麼運作啟動新的處理程序，而非瀏覽器。 處理程序樹狀目錄的結果顯示於 的 圖 3。
.png)
圖 3 的 A Surrogate 程序樹狀目錄
啟動應用程式時它進行載入器透過像任何其他應用程式一樣。 Microsoft 應用程式虛擬化用戶端介面層 (sftintf.dll) 會呼叫進入內部 API CreateProcessInternalW 的 CreateProcessW 到呼叫。 它會在 CreateProcessInternalW API，叫用填隙引擎和修正有線到處理程序。
確定，所以的 ’s 很簡單。 是否有任何攔截吗？ 嗯，是，有是其中一個。 它 doesn’t 妥善處理提高權限。 您只需 can’t 提高權限 (使用 RunAsAdmin 填隙) 應用程式的要求，或修復需要提高權限，例如使用 ElevateCreateProcess，應用程式的問題。 為什麼？ 因為的泡泡圖。
比方說 let’s 需要嘗試啟動自動更新的本身 (不幸的是，「 所有-太-經常工作) 的應用程式。 執行原生，說它發生問題，因為它使用 CreateProcess 的 API 也就是無法叫用提高權限。 然後將它會傳回錯誤-1073740756 – STATUS_ELEVATION_REQUIRED。 ElevateCreateProcess 填隙會攔截這個傳回值，並接著叫用應用程式資訊服務以提供提高權限。 但是這項服務無法找到提升權限，應用程式，因為服務都位於泡泡圖之外!
所以，只要您的應用程式並不需要提高權限，部署單一填隙資料庫解決方案是很簡單，如果您已經有處理程序破解 — 您只需繼續進行相同的動作。
shimming App-V 具有每個應用程式填隙資料庫的應用程式
部署修正解決應用程式相容性問題的替代方案是部署與應用程式修正。 MSI] 世界中則通常包括在安裝程式中的 [.sdb 檔案然後接著將稱為 sdbinst 對它卸除.sdb 檔所做的自訂動作。 這會安裝自訂的填隙資料庫做為安裝程式的一部分。 (如果您接下來需要更新該應用程式修正，您需要尋找所有已安裝的用戶端並執行指令碼來安裝的更新 complicates 事情稍微)。
與應用程式-V 您可以執行許多相同的動作。 因此.sdb 檔案都位於內部的泡泡，您就可以包含成序列本身，填隙資料庫 (.sdb) 檔案。 第一次，順序需要修正，才能正常運作的應用程式。 完成，我喜歡將自訂的填隙資料庫拖曳至 system32。
(雖然通常我建議人從未，曾經放置任何內容到 system32 除非由徐維斌 Ballmer 簽署您的薪資，報告鏈結包含 Steven Sinofsky，這個特定的執行個體中選擇將這麼做，因為它簡化了指令碼 — system32 將會在您的路徑，而且 ’re 不 實際上 離開 system32 剛內看起來的樣子 system32 虛擬檔案系統的生產系統中的任何項目)。
一旦我完成這，我編輯.sprj 檔案。 我瀏覽至 [虛擬檔案系統] 索引標籤，然後按一下 [檢視] | 虛擬檔案系統 | 新增。 然後，我瀏覽至我卸除.sdb 檔案 (c:\windows\system32\appshim.sdb) 的位置，再按 [確定]。 現在，此.sdb 檔案會出現泡泡圖內，並會安裝在安裝 softgrid 封裝時。 因為檔案容器的一部份它周圍執行應用程式的一部分 (和應用程式更新時，可以被更新)。
當然只具有.sdb 檔案，檔案系統上的 isn’t 足夠套用應用程式修正程式 — 他們必須進行安裝。 但是，填隙資料庫必須已安裝的 外 App-V 泡泡圖。 如果您在安裝填隙資料庫內的泡泡則虛擬化的.sdb 檔案 won’t 是設定為可探索直到程序建立之後時 ’s 晚填隙引擎來找到它，並在其上採取動作。 您需要有填隙資料庫存取泡泡圖之外載入器，因為正在建立處理程序。
幸運的是，App-V 包含一種機制來執行指令碼做為應用程式啟動程序的一部分。 如果您有看一下 OSD 檔案，應用程式使用您喜愛的文字編輯器的看到它是只可編輯的 XML。 < SOFTPGK > 項目包含 < 實作 > 項目]、 [< 相依性 > 項目]、 [< 封裝 > 項目]、 [< 抽象 > 項目]、 [< MGMT_SHORTCUTLIST > 項目] 和 [< MGMT_FILEASSOCIATIONS > 項目。 < 相依性 > 項目就是您想要編輯 — 您要加入子 < SCRIPT > 項目來執行自訂的填隙資料庫安裝。 這裡是 App-V 的一個可以自訂填隙資料庫安裝應用程式啟動時並再次移除它，當應用程式存在 (因此為清理背後本身的重要目標的 JIT 安裝) 的指令碼的範例：
<DEPENDENCY>
<CLIENTVERSION VERSION="4.6.0.0"/>
<SCRIPT EVENT="LAUNCH" PROTECT="TRUE" TIMING="PRE" WAIT="TRUE" EXTERN="TRUE">
<SCRIPTBODY LANGUAGE="Batch">sdbinst /q appshims.sdb</SCRIPTBODY>
</SCRIPT>
<SCRIPT EVENT="SHUTDOWN" PROTECT="TRUE" TIMING="POST" WAIT="TRUE" EXTERN="TRUE">
<SCRIPTBODY LANGUAGE="Batch">sdbinst /u appshims.sdb</SCRIPTBODY>
</SCRIPT>
</DEPENDENCY>
有了這個指令碼您將會從 外 的 App-V 泡泡，呼叫填隙資料庫安裝程式 (sdbinst.exe) 而應用程式部署順序中使用一個.sdb 居住 內 的 App-V 泡泡圖，並因此部署的引數。 因此，很容易部署與更新應用程式修正程式，就像任何其他部份的應用程式一樣。
安裝自訂的填隙資料庫處理程序需要系統管理員權限 ； 是它我們安裝這在執行階段的問題嗎？ don’t 要為您的使用者，會需要系統管理員權限，而且您的使用者 don’t 希望自己能夠按一下 UAC 對話方塊上的 [每次他們啟動他們的應用程式。 幸運的是，您 don’t 需要這麼做 ； 對 sdbinst.exe 呼叫自動提升為您。 處理程序樹狀目錄的安裝修正] 的 圖 4 所示。
.png)
圖 4 的 A 填隙安裝程序樹狀目錄
命令殼層建立，其中，然後會安裝自訂的填隙資料庫 sdbinst.exe 呼叫。 呼叫進行至應用程式資訊服務即提供提高權限的服務之前，這會兩次以 STATUS_ELEVATION_REQUIRED 失敗。 這項服務呼叫會檢查原則，以判斷是否應該提升應用程式的 consent.exe。 (在虛擬環境中) 原則是傳回而不需提示使用者 ； consent.exe 核准提高權限並建立自訂的填隙資料庫所安裝的 sdbinst.exe 提高權限執行個體。 但 ’s 一點要注意的是而不提示提高權限的原則只適用以無訊息模式是否能夠提高權限。 如果您是標準的使用者，每個應用程式的啟動會導致系統管理員認證如將每次關閉應用程式的提示。 這可能是才能查看以標準使用者環境中非常不利，因為這種方法只適用如果您已部署本機系統管理員的使用者。 我們希望這適用於使用者的百分比是極小!
結論
Microsoft 應用程式虛擬化是一種功能強大的應用程式管理和部署工具。 在中工作時它到您的 Windows 7 遷移的計劃，您可以受益潛在的降低成本安裝測試期間 (雖然此成本不為零我們承諾給)。
您也可以繼續運用大部分的處理程序，而對於解決使用修正應用程式相容性問題。 如果您部署單一、 整個組織填隙資料庫，轉換將會非常最少 — 您必須只能小心避免提高權限修正 (方式很多相同您應該在 App-V 環境中，在一般避免提高權限)。 如果您要部署每個應用程式修正，有封裝並部署填隙資料庫與應用程式一些簡潔的方法，但是您擁有的無法合理地執行應用程式以非系統管理員使用者非常顯著的缺點。 為等我增強式 (因為它是以 MSI 為基礎的應用程式部署) 建議致力於部署修正為單一的集中管理資料庫，您可以部署使用現有的系統管理軟體。 這可讓您尋找在未來更大型且較大的百分比，您的使用者的執行非系統管理員的身分的位置。
葛麗麗 Jackson (「 應用程式 Compat Scripting Guy 」 ) 是在 Microsoft 和 Windows 應用程式經驗 SWAT 小組的技術指導人員主體顧問。 Jackson 是建立技術文件訓練，[Windows 應用程式相容性] 欄位中的一個廣泛可辨識的專家，用在內部，以及 Microsoft 之外的服務產品基礎年與企業客戶和獨立軟體廠商的實際經驗。 Jackson 可以達到透過他 受歡迎的部落格 。