簡介
不得不說MED-V、APP-V和Hyper-V的命名方式很直觀的傳達的產品的特性，比起微軟從前的其他拗口冗長難記的產品名稱有很好的改進。
軟體點評
就產品技術而言，APP-V算是中規中矩，安裝配置也不算複雜，只要環境條件具備，搭建企業級桌面程式並不困難，問題就在於MDOP需要的環境條件不少，少了哪一道東風或哪個步驟設定不當的話，即便萬事俱備這赤壁也是燒不起來。
硬體和環境的原因，Microsoft Desktop Optimization Pack套件之中的資產清單和組策略管理等等H編輯沒有仔細的一一體驗，但相信微軟的出品應該不會讓人太失望（當然偶爾也有VISTA這樣的例外吧）
微軟MDOP（Microsoft Desktop Optimization Pack ）套件最大的亮點莫過於用於客戶終端展現的桌面虛擬化MED-V和用於虛擬化程式推送交付的APP-V；連同Hyper-V基本上就構成了微軟端到端的虛擬化全線解決方案。不過就產品本身而言，微軟的虛擬化產品相對與競爭對手已經遲到了很長時間，而且MDOP套件是面對批量軟體保障（SA）客戶，所以Beta階段的產品無論是在微軟技術社區或下載中心始終無跡可尋，到目前為止MED-V一點影子都沒有見到過，讓人倍覺神秘之餘多少也有些許失望，所以H編輯這次也只能體驗下APP-V的虛擬化程式的樂趣。
進入2008年以後不得不說微軟對於產品的命名方式更加的貼合用戶需求，本來對於新技術的學習和接受就是一件很費功夫事，再讓用戶去記拗口冗長難記的研發代號或者產品名稱全稱簡稱等，你說究竟有多少的腦細胞因此絞盡汁液，光榮犧牲。但這次MED-V、APP-V和Hyper-V為例，它們的命名方式很直觀的傳達的產品的特性，比起微軟其他產品算是有很好的改進了。
完成的MDOP除了上圖羅列的各項以外，目前位置還有MED-V缺席，有訊息傳聞說MED-V會在09年初正式推出。完整版本的MDOP會包括以下六大項目。
· Microsoft Application Virtualization4.5 (APP-V) ——微軟應用程式虛擬化技術
· Microsoft Enterprise Desktop Virtualization (MED-V) —— 微軟企業桌面虛擬化技術
· Microsoft 資產清單服務——將軟體清單數據結合數據倉庫功能套用於商業智慧型
· Microsoft 診斷和恢復工具集——加速桌面修復的強大工具
· Microsoft 高級組策略管理——增強的組策略，實現變更管理
· Microsoft System Center 桌面錯誤監控——主動管理應用程式和作業系統的錯誤
下面來就分享一下MDOP中重點關注的新的應用程式虛擬化軟體Application Virtualization 4.5（APP-V）的安裝設定過程。這個APP-V在從前叫Softgrid，從字面上理解分散式格線計算的一個變形品種，用格線計算的模式來理解程式虛擬化技術的客戶端到實現虛擬化的伺服器端之間的相互通信和計算負載分配機制也是有些異曲同工的意思。
安裝步驟
要安裝APP-V並實現全部的功能，需要的步驟並不算很多，下面都是必須做到的步驟：
1、安裝前的環境搭建：建立域控制器，安裝.Net Framework 2.0，IIS服務，MSXML6.0等系統環境組件，另外，資料庫SQL Server也是必須的。
2、安裝程式虛擬化伺服器端Application Virtualization Management Server。
3、安裝客戶端Application Virtualization Client。
4、安裝程式序列化工具Application Virtualization Sequencer。
一、系統準備，安裝活動目錄，.Net Framework 2.0， IIS， MSXML6.0，在安裝過程前也會對現有系統做檢測，缺少哪些部件也會給出提示，算是半傻瓜化操作。不過這些缺少的組件或補丁需要用戶自行下載安裝，如果能在安裝程式種集成到一個包中會更加方便些，否則APP-V安裝過程也許會被打斷。
在Windows Server 2003下，添加刪除程式處添加組件，安裝好.Net Framework 2.0， IIS組件。安裝SQL Server資料庫(裡面已經包含了MSXML組件)，這些稍後會用到，否則安裝過程會被終止而不是回退到上一步。
之前也提到了APP-V需要資料庫的支持，所以先安裝SQL Server資料庫，新建好用於程式虛擬化的資料庫，這樣前期工作就算是做好了。
安裝Application Virtualization Management Server
在App-V 4.5中，Server共分為Application Virtualization Management Server與Application Virtualization Streaming Server兩種，Application Virtualization Management Server使用 Active Directory 組來管理用戶授權。除了Active Directory域服務以外，這些伺服器還安裝了SQL Server，以管理資料庫和數據存儲。Management Server 通過Application Virtualization Management Console（Microsoft Management Console 的一個管理單元）得以控制。由於 Application Virtualization Management Server 會按照需要將應用程式傳輸給最終用戶，因此理想情況下這些伺服器適合執行更具有可靠、高頻寬LAN的系統配置。
而後者Application Virtualization Streaming Server，可以滿足可能不具備支持Management Server的基礎結構的公司的需要。與Application Virtualization Management Server不同，Streaming Server不使用SQL或Management Console。這些伺服器使用訪問控制列表 (ACL)來授予用戶授權，這種架構比較適合在中小型企業，節點較少同業也不具備大型資料庫支持的小型網路環境中。
我們打開MDOP 2008R2的安裝界面，選擇Application Virtualization for Desktop 4.5進行安裝。
3.進入安裝界面，一路Next。
APP-V Server Mnangement組件不多，默認情況下是全部安裝，需要的磁碟空間在400M左右。
這裡用到了我們裝的SQL Server資料庫，假如系統檢測不到有資料庫的存在，點下一步就會自動報錯。因為SQL Server就裝在本地，所以這裡直接選local。所有通信連線埠都採用默認設定，如果默認連線埠已經被占用的話，也要記住改用的連線埠，在稍後的配置時還會用到，如果伺服器和客戶端之間不匹配，後果自然是失敗了。
安裝默認554的連線埠。
然後需要為APP-V指定兩個管理和用戶的組，這在之前設定動態目錄的時候需要預先新建出來，用不同的組給APP-V賦予不同許可權，管理員可以進行Server的管理，用戶用於登入接受伺服器分發的虛擬化程式。
選擇Content的位置，Content目錄用於存放經過序列化分拆的程式包OSD檔案，伺服器會從此向組內客戶端分發程式。默認路徑會比較深，找起來很麻煩，當然也可以自定義。
這一步比較關鍵的是要將此資料夾共享，可以向Admin和User組內成員開放共享，為方便起見也可以將資料夾share給everyone，而且everyone有讀取許可權才有用，這一步十分關鍵，完成這一步，安裝完成。
完成以後在“管理工具”內就出現“APP-V management console”控制台項目，運行啟動，選擇右邊的Connect to Application Virtualization System連線服務端。
即使Server端安裝在本地，但也要給出完整計算機名稱、通信協定類型和連線埠。
用記事本打開content下的DefaultApp.osd，注意選中的地方，將協定改為RSTP，連線埠改為與安裝時候的一致，不得不說DefaultApp.osd默認的322竟然和安裝時默認的554不統一，這種小細節最有可能煩死人了。
將左邊視窗展開，點擊Applications，在中間視窗右擊Default Application，選擇屬性。這一步非常的關鍵，一定要將OSD Path和Icon Path的本地路徑進行修改，要選擇為網路路徑，否則後面會配置不了，因為content已經設定為已分享檔案夾，所以其他用戶通過網路地址可以訪問到。
可以根據需要，設定Shortcuts屬性， 可以選擇將其派發至客戶端指定的位置：桌面、開始選單或者快速啟動欄。
安裝Application Virtualization Client
在客戶端上選擇安裝Application Virtualization Client程式。
過程中，注意要選擇的自定義，否則會錯過很多設定項目，從前面大家可能都心裡有數了，即便是默認設定，APP-V也並沒有完全遵守默認規則，所以還是自定義比較踏實，畢竟自己改動的地方要改回來也是心裡有數吧。
客戶端會映射一個共享的網路磁碟也就是剛才我們在服務端共享的content資料夾。我們可以看到首選驅動器號為Q，往後一直到Z都可選，這基本上不會和本地磁碟混淆。
在立即設定發布伺服器上一定要打勾，類型選擇Application Virtualization Server，正確填寫主機名，連線埠填寫我們使用的554連線埠，總之和先前填寫要一致，最後一個選項打勾。
安裝完成以後記得要重啟系統，然後打開Application Virtualization Client選擇發布伺服器，可以看到TEST伺服器，右鍵選擇refresh server，刷新伺服器信息。
如果在伺服器端已經完成程式虛擬化步驟，刷新伺服器發布信息以後，桌面、開始選單或者之前指定的位置出現程式的圖示，且可以運行。這表示server與client之間可以正常通信，安裝成功。
安裝Application Virtualization Sequencer
對於Sequencer，熟悉Softgrid的同學應該不會陌生，除了Server和Client兩個端之外，Sequencer也是其中的重要主角，Sequencer是一個序列化的工具，所謂的序列化就是將應用程式序列化，講整體分割為小塊，其結果以檔案形式獨立存儲，塊可以組合使用，不會改變應用程式本身。Sequencer的作用就是把整個應用程式分拆並且序列化為多個單獨功能部件。經過序列化的應用程式各個功能其實是獨立分割的，在客戶端需要使用到哪一個功能時，會想Server發出請求指令，而Server會將單獨的功能分包小塊傳送過去，這不需要把所有程式一鍋端，這很大的降低網路和伺服器負載壓力。
Sequencer在APP-4.5中的變化不大，在序列化過程中，Sequencer 會虛擬一個監視環境，要序列化的應用程式安裝在序列化計算機上。接下來，序列化應用程式啟動，並執行其最重要且最常用的功能，使監視過程可以配置主要功能塊。
需要注意的是在實際環境中，一般企業會包含多種版本的桌面作業系統，在製作應用程式序列包時應該，而且最好在相同的作業系統上進行打包，這樣應用程式才能保證在相應的客戶端作業系統版本上正常運行。
在實際套用中，我們需要的是一個乾淨的系統，以避免產生的序列化檔案有不必要的誤差和衝突，最好用虛擬機來實現，在一個乾淨虛擬系統上裝了Sequencer，產生序列化檔案並上傳上App-V server後，在把虛機回滾到程式未安裝的乾淨系統狀態，繼續做另一個軟體的序列化。這樣貌似很麻煩，但多個序列化後的程式包在客戶端執行時，會有很多不必要的序列塊，有可能引發潛在的程式衝突，而且Sequencer製作過的程式包以後都可以永久保存，麻煩一點換來的是一勞永逸也算值得。
安裝App-V Sequencer，這個過程沒什麼要特別配置的地方，一路next選擇默認安裝完畢即可，不過在測試中我們出現過安裝中斷甚至沒有錯誤提示的經歷，不過在更換了一個系統以後就可以順利安裝了，這估計是缺少系統檔案的原因。
製作應用程式虛擬化檔案包
安裝好了我們就做個測試看看，H手上只有一些測試軟體，這裡就地取材將磁碟測試軟體Iometer製作為序列化軟體，製作程式包的方法都是一樣的。
啟動Sequencer後有製作嚮導，可以按部就班的進行學習。在確定程式包的名稱和放置程式包的路徑之後，Sequencer會啟動一個監視器，這個監視器會記錄下應用程式的各個安裝部件並一一進行序列化。
啟動“監視器”之後，Sequencer會自動縮小到系統系統列上。然後我們就可以開始安裝應用程式的操作了，這些我們選用的是用於測試磁碟性能的Iometer，安裝簡單也比較小巧，安裝的步驟也在本地系統安裝程式沒有兩樣。
Iometer安裝完畢後，切回Sequencer點“下一步”停止監視器。
步驟5，顯示監視器收集到的程式信息，這裡可以把程式的默認路徑改為"Q"盤，對於客戶端來說，虛擬化程式的快取檔案都在之前安裝APP-V client時所定義的Q盤上，我們需要將虛擬化程式的路徑改為客戶端的本地路徑。
對於各個程式組件，可以測試它們能否正常啟動。
可以完成Iometer的序列化了。
在部署標籤上填寫APP-V伺服器端的主機名稱和連線埠，並程式包的信息修改符合伺服器本地路徑、名稱等相關信息。以為這些檔案最後是要複製到伺服器的content目錄中的，關鍵信息都要同一一致。
然後可以保存這個項目的檔案，以後就再也不需要製作Iometer的程式包了，只需要保存好這些檔案。
正式啟動APP-V程式虛擬化
說了這么多，都是為現在這一步作的準備，客戶端服務端和序列化工具的安裝設定就是這整個系統的搭建過程。因為其中的細節不少，H覺得APP-V配置過程雖然不很複雜，但卻要求十分細心，試想一下如果企業的客戶節點有成百上千個的話，部署過程就相當的可怕了，當然對於那樣龐大的任務量也有對應的技術手段，那就是另外一回事了。
先把製作好的程式包複製到content資料夾中，切換回APP-V management console控制台，在應用程式項上右鍵選擇“導入應用程式”。
選擇已經放置妥當的content\Iometer目錄下iometer.sprj檔案，填加可以訪問該程式的帳號組，填加之前在動態目錄中定義好的組就可以。
一定要務必把OSD Path和Icon Path指向到\伺服器名\content下，否則顯示不出相應的圖示和程式組。
最後一步：用組內成員登入client系統，原本的客戶機也是一個剛剛安裝好的乾淨系統。
啟動系統後，發現，開始選單已經出現了我們需要的“iometer”，名稱、圖示完全沒有問題。
點擊運行，iometer成功啟動，操作和本地安裝的程式一模一樣。
到此，APP-V程式虛擬化系統宣告搭建成功。
結束語：
APP-V系統架構圖
App-V解決方案以活動目錄為基礎，結合App-V Server、Sequencer、App-V Client一併形成完整的虛擬應用程式解決方案，其中Sequencer用以測試和製作需要部署的應用程式包，App-V Server用以向App-V Client分發Sequencer生成的程式包。
在App-V架構中，一般建議Sequencer要與Client作業系統一致，並在使用Sequencer部署應用程式包的時候保持系統的乾淨。比如說，一個企業中的客戶端都是Windows XP，那么用於生成Sequencer的伺服器也希望是Windows XP，雖然有的軟體可以部署在不同的作業系統版本上，建議作業系統上沒有安裝其他多餘的第三方軟體。
在企業的實際運用中，可能客戶端會涉及到不同版本的作業系統。通常的做法是部署多台不同版本的作業系統，並安裝Sequencer。這樣負責的要求下，最好使用虛擬系統以保持系統乾淨。
當使用Sequencer製作好應用程式包，將生成一個啟用虛擬化的應用程式檔案 (.sft)、一個開放軟體描述檔案 (.osd)、一個圖示檔案 (.ico) 和一個項目檔案 (.sprj)，並上傳到共享存儲或是App-V Server上後，結合活動目錄的許可權管理，發布應用程式包到客戶端。客戶端在第一次打開應用程式捷徑或者相關聯的檔案時，將向App-V Server下載，並只下載5% ~ 20%的代碼用以運行“最短啟動代碼”。
同時，下載後的應用程式將可以在控制臺中的SoftGrid管理中看到下載的比例，應用程式使用中不會在本地計算機上安裝。與以往的終端服務不通的是：在本地執行，並支持脫機狀態運行。當應用程式需要升級時，管理員只需要將原有生成的應用程式項目檔案重新導入，並安裝升級後重新分發即可，不會影響用戶的繼續使用。
當客戶端需要使用到前面“最短啟動代碼”里沒有的功能時，將自動在伺服器中下載相應的代碼以運行。從統計學上來說，一個企業的所有客戶端在同一時間使用同一軟體的同一功能的可能性是相當小的，所以這樣也能起到一個數據分流的作用，從而大大加快速度。
在MDOP套件中還有企業用於桌面管理的其他工具，利用MDOP對客戶端進行應用程式部署的時候，企業還可以通過App-V對部署的程式進行管理。同時，也可以使用App-V解決方案實現企業客戶端的桌面標準化、桌面高可用性和桌面可管理性。
工作原理
抓住Microsoft App-V遷移視窗期
那些當初讓你開始套用虛擬化的理由在今天可能已經不再成立。Microsoft App-V 4.5或4.6的生命周期即將結束，你現在就該決定選擇什麼樣的套用虛擬化工具，這樣才能確保你能在此之前完成遷移。
如果你還在使用App-V 4.5或4.6，你就該開始考慮你的遷移計畫了。
Microsoft App-V 4.5目前已處於其產品生命周期的擴展支持期，擴展支持將在2019年1月8日終止。App-V 4.6也只有幾個月就要進入擴展支持期,擴展支持期將從2015年7月14日開始。App-V4.6版的擴展支持期將在2020年7月14日終止,相信你已經記下了這個截止日期。
顯然你現在還不必驚慌失措；畢竟和（已經終止支持的）Windows XP相比，這些截止日期看起來還不算迫在眉睫。但現在也正是開始規劃遷移App-V的最佳時機。那么，你應該向哪裡遷移？Microsoft App-V 5看起來是最輕鬆的答案，但如果你有時間回答幾個問題，請回顧一下，你最初為什麼會做應用程式虛擬化。今天你的答案很可能與當初有著天壤之別。
為什麼你採納App-V套用虛擬化
早期的App-V應用程式虛擬化，App-V主要用途是實現應用程式之間的隔離。相同App-V應用程式的不同版本需要在Windows的單個實例上共存，這就是我們曾經歷的所謂的"DLL 地獄"。（App-V套用虛擬化可以做到套用的共存和隔離。）
此外，過去用於App-V套用虛擬化的串流組件也吸引了眾多的公司。通過App-V串流應用程式，只有必要的App-V應用程式數據塊才會被傳送給用戶的桌面系統。App-V應用程式仍然在本地執行，但App-V存儲和網路占用大幅降低。如果遠程用戶需要運行Word程式，你可以將App-V程式塊按需傳送給用戶，和用戶立即需要的App-V數據相比，用戶不會馬上調用的那些App-V非關鍵數據塊會處於較低的傳輸優先權。
自從那時起，App-V應用程式虛擬化的使用場景逐漸發生著改變，隔離和串流不再盛行，關注的重點變成了單純的App-V應用程式管理。
為什麼今天還可能會用到App-V套用虛擬化
App-V應用程式虛擬化的基礎其實就是給App-V應用程式軟體打包。這些App-V軟體包可以包含單個應用程式或一組具備依存關係的應用程式，比如包含某些外掛程式的Outlook程式。即使你不需要隔離和串流App-V應用程式，套用打包也可以非常有效地減少你的App-V桌面基礎映像（無論是物理還是虛擬桌面）數量。
問題是，如果採用傳統的App-V應用程式虛擬化工具——可以說我指的就是Microsoft App-V或者VMware ThinApp——你就無法將全部（關聯程式）都打包。由於這樣或那樣的原因，某些App-V應用程式就是無法打包虛擬化後運行，所以這些特例必須部署在基本映像中。每個App-V應用程式的情況各不相同，但問題通常都出在被公司遺忘的某箇舊App-V應用程式的某個功能上。如果你只是想把App-V應用程式虛擬化當成App-V應用程式的管理手段來用，結果可能會讓你失望。
考慮到上述因素，如果你正在考慮從App-V 4.6 遷移到 5，就該弄清楚，你今天打算以哪種方式使用App-V應用程式虛擬化。你需要隔離、安全和套用串流應用程式功能嗎？如果答案是肯定，那你可以繼續App-V。
如果你只是想要一個漂亮的App-V應用程式管理平台，不妨看看其它App-V替代選擇。有很多方法獨到的App-V現代套用管理平台可選。FsLogix 使用策略來隱藏Windows中的App-V應用程式，即使這些App-V套用已經部署在基本映像中。
Cloudhouse管理的App-V應用程式包並非孤立存在，App-V應用程式包默認以集成的狀態來運行。Spoon把套用放在其Web前端的微虛擬機組件上運行。即使是已經擁有自己ThinApp的VMware，今天也有了一個獨特的App-V應用程式管理產品：App-V Volumes，在虛擬磁碟上的現代化的App-V應用程式包。
有很多種選擇，選擇哪個平台，取決於你打算如何使用App-V。沒人會喜歡切換平台，但如果必須切換，現在正是作出籌劃的大好時機。
