powershell vs GPO 用於安裝、配置、維護
我的問題是關於使用 powershell 腳本在 2008R2 域中安裝、配置、更新和維護 Windows 7 Pro/Ent 工作站，而不是使用 GPO/ADMX/msi。
情況如下：
由於一部累積企業顛簸的喜劇，我們突然發現自己必須在很短的通知和傳遞時間表內設計、配置和部署完整的 Windows Server 2008R2 和 Windows 7 Pro/Enterprise。當然，無論如何我都不是 Windows 專家，而且我們人手不足，以至於我們的流行語賓果遊戲包括“自動化”和“一鍵式”以及“它需要只是工作”。（FWIW，我從 DEC 開始，然後是 solaris 和 cisco，然後是各種風格的 linux，現在還有一點 BSD。我使用 Windows 發送電子郵件和填寫表格）。
所以我們決定請一個承包商來為我們做這件事。他們趕上了最後期限。該系統已啟動並且大部分可用，這很好。我們無法做到這一點。但它是“主要”部分現在被證明是 PIMA，無論如何我都必須學習微軟的東西，直到/如果我們能與這些人簽訂新契約以進行持續運營。
這是我的問題。承包商幾乎只使用 powershell 進行部署、配置和更新。上週的密集閱讀使我認為，部署、配置和更新微軟東西的普遍接受的做法使用 GPO 和 ADMX 模板的元素，可能還有一些第三方的東西，比如 PolicyPak。
是否有充分的理由我還沒有發現 powershell 腳本比 GPO 方法更受歡迎？
當他從假期回來時，我將與承包商負責人討論這個問題，他會直接跟我說話（我認為他們也沒有設置我們）。但我也可以看到這可能是一個宗教問題，所以我仍然想了解一下這方面的背景。
想法？或網路連結？
謝謝！
這裡沒有“正確”的答案。我個人的偏好是對設置/策略使用組策略，但對於應用程序部署使用 PowerShell（甚至是舊的 WSH 腳本或批處理文件），假設您有一個沒有復雜信任問題的域。但是，也有取捨。在 PowerShell 中做任何事情當然是合法的。
應用程序部署（GPO 與腳本）：
使用基於 GPO 的軟體部署，您只能使用 MSI 包。對於不是通過 MSI 分發的產品（例如 setup.exe），這可能很煩人。在這種情況下，您必須將其打包為 MSI。享受 Adobe Reader 的 MSI+MSP 發行版（必須製作 AIP）。如果您需要自定義安裝，則需要使用 MSI 轉換。腳本中可能是單行的東西可能會變成一個複雜的多步驟過程。
當您部署的所有內容都可以作為 MSI 獲得時，您無需進行特殊自定義即可安裝它，那麼 GPO 部署將非常順利。您可以使用 WMI 目標並自動解除安裝超出策略的內容。但是一旦你走出那個盒子，事情就會變得更加複雜。此外，當出現問題時，可能很難從事件查看器中弄清楚發生了什麼。
使用腳本，您可以安裝或解除安裝幾乎任何東西，MSI、EXE 等等。如果您需要在安裝之前進行一些清理工作（例如，從沒有完全解除安裝的先前版本中清除舊的系統資料庫項），您可以這樣做。如果出現問題，您可以根據需要添加盡可能多的調試/重試/解決方法程式碼，並且可以在啟用日誌記錄的情況下執行 msixec。
您的腳本通常需要一些條件邏輯來檢查軟體是否已經安裝（以及什麼版本），然後在需要時呼叫安裝程序。如果您沒有程式背景，這可能會令人生畏。它不再是點擊式解決方案。因為你是自己寫的，所以你也有更多的機會把事情搞砸。
我們從 GPO 切換到 PowerShell 來部署應用程序，這讓事情變得容易多了。當新版本出現時，我們需要做的就是將新的安裝程序文件放到我們的 AppDeployment 共享中並更新腳本中的 $expected_version 變數。大約需要 1/10 的時間。
您還可以採用混合方法，將 GPO 用於 MSI 內容，將腳本用於其他所有內容。我不喜歡這個，因為我喜歡有一個地方去看看安裝了什麼。
請注意，使用組策略，應用程序部署在重新啟動之前不會發生。如果您使用的是啟動腳本，這也是正確的。但是，如果您使用PowerShell 遠端處理或計劃任務，您可能無需重新啟動即可將其關閉（雖然可能會變得混亂）。
設置和配置（GPO 與腳本）：
組策略首選項使用起來非常簡單，例如創建系統資料庫值、映射網路驅動器、創建快捷方式等。組策略具有後台刷新功能這一事實很巧妙，因為您可以應用設置而無需強制使用者重新啟動。項目級別定位為您提供了很大的靈活性（這是對 GPO 級別的 WMI 和安全過濾的補充）。
但是，組策略首選項遠非完美。我的一些煩惱：
- 管理 Internet Explorer 的方法太多了，其中一些已棄用，有些不適用於最新的 IE。我總是最終只是直接管理系統資料庫設置。
- 事件查看器中的隨機錯誤是愚蠢的。範例：我創建了一個項目來刪除計劃任務。太好了，它已經從我所有的工作站中消失了。現在事件查看器開始填充錯誤“我無法刪除任務，因為它不存在”。呸！
- 申請一次而不是重新申請會在你的職業生涯中至少搞砸一次。
- 更新與替換。請注意，因為您可能會選錯一個。
- 您可以對項目級別目標執行的操作有一些限制。如果您需要 for() 循環或字元串操作（修剪字元、調整大小寫），您將回到腳本。
- GPP 文件操作總是發生，即使文件沒有被更改。您的工作站將一遍又一遍地從伺服器上複製相同的文件，即使他們不需要它。這可能會意外地影響您的伺服器和網路。項目級別目標可以幫助緩解這種情況，但請注意您是否選中了“如果未應用則刪除”。
- 事件查看器中的許多 GPP 錯誤不包含實際解決問題的有用資訊。您必須打開跟踪。
您可以使用 PowerShell 進行設置，但它也有一些缺點：
- 使用 PowerShell 管理系統資料庫設置變得混亂（至少使用本機系統資料庫提供程序）。在我看來，微軟在將系統資料庫值設為“屬性”而不是實際項目時搞砸了。它使事情變得比它需要的複雜得多。您需要一堆條件邏輯來測試系統資料庫項並在創建值之前創建它們。組策略在這方面要簡單得多。
- 有很多“基本的”系統管理員任務是您無法在 PowerShell 中本地完成的（例如，創建快捷方式、管理計劃任務）。您必須呼叫 Wsh、.Net 框架或使用第三方模組。
- 腳本僅在啟動/登錄時執行。沒有後台刷新（除非您設置了計劃任務）。
- 如果您必須呼叫舊版 Window 命令實用程序（net.exe、schtasks.exe），則呼叫該命令可能會很棘手，甚至更“棘手”的是要使其螢幕輸出與 PowerShell 的輸出完美配合。您可能有一個失敗的命令並且您不知道它。
關於腳本（PowerShell 或其他）與 GPO 的其他一些一般性評論：
- 腳本幾乎是程式項目。隨著時間的推移，程式碼會增長並變得更加複雜。如果您不將其視為“真正的”程式項目，帶有註釋、版本歷史、子常式等，它將變得無法維護，您的繼任者最終會因為不理解而報廢。
- 系統管理員（通常）不是程序員。他們不知道正確的程式規則（見第 1 點）。對於沒有程式背景的管理員來說，即使是結構良好的程式碼也可能令人生畏和難以閱讀。請注意您目前和未來員工的技能。
- 腳本的優勢在於它們可以檢查到版本控制中並進行區分。對於 GPO，這有點難做到。
- 腳本更容易複製到 USB 密鑰上並隨身攜帶。你的承包商可能就是這種情況。他可能有一些來自以前項目的現有腳本，他可以為您的項目回收這些腳本。在我的環境中，我有兩個氣隙網路（不要問），但配置相似，因此我們盡可能使用 PowerShell 腳本，這樣我們就可以在兩個網路之間重新循環程式碼。
- GPO 的優勢在於您可以使用RSoP等工具來獲取應用於特定工作站/使用者的所有設置的報告。這對於審計和故障排除可能很重要。
- GPO 更“可發現”。我可以進入一個不熟悉的環境，並很快了解應用了哪些策略和設置。有了一個腳本，我必須開始研究程式碼，並希望它得到很好的評論。
- PowerShell Remoting對於您想在一堆系統上執行的一次性命令非常方便，並且您不希望它成為“永久”策略（例如，每個人都刪除這個臨時文件）。
無論您使用哪種方法，請確保事情有據可查。您應該在微觀級別（“為所有會計工作站實施設置 x 以解決應用程序 y 的問題”）和宏觀級別（“我們所有的工作站設置都儲存在名為 x 的 GPO 中”）記錄事物）。
後續編輯： PowerShell 4 添加了一個名為Desired State Configuration的新功能。這看起來可以用來實現組策略首選項的某些功能。它可能會改變遊戲規則。還沒有使用它，但它看起來真的很酷。
後續編輯 2： 我意識到的一件事是我沒有正確區分Group Policy Policies與Preferences。首選項非常類似於 PowerShell 腳本。策略更“僵化”，並且在腳本中實施起來更棘手。為此，您必須讓腳本填充 HKLM\Software\Policies，但您必須注意與 GPO 的衝突。在這種情況下，做一個或另一個，而不是兩個。