DSC 好像有好幾個版本，我該用哪一個？

如果你現在才要開始做宣告式組態管理，就用 Microsoft DSC v3(dsc.exe)。DSC 一共有四個系譜：內建於 Windows PowerShell 5.1 的 PSDSC v1.1、給 PowerShell 7 用的模組 PSDSC v2、用於 Azure Machine Configuration 之 Linux 支援的 PSDSC v3(預覽版)，以及被改寫成不依賴 PowerShell 的獨立命令 Microsoft DSC v3。v3 是跨平台的，組態不再寫成 PowerShell 腳本，而是寫成 YAML/JSON 資料，既有的 PSDSC 資源也能透過配接器繼續沿用。搜尋時加上「DSC v3」「dsc.exe」，比較容易把舊世代的資料區隔開來。

DSC v3 和步驟腳本(BAT 或 PowerShell)差在哪裡？

步驟腳本寫的是「要執行的步驟」，所以為了第二次執行時不會重複套用或出錯，冪等性必須由你自己做出來。DSC 把「應有的狀態」寫成資料，而與目前狀態的比對(test)以及差異的套用(set)則由資源負責。同一份組態文件執行幾次都沒關係，對於已經處於期望狀態的項目它什麼都不做，因此可以不必在意執行次數就發佈與重跑。而且組態本身就是 YAML 資料，用 Git 做差異審查和版本管理，比腳本容易太多。

既有的 PowerShell DSC 資源與 WinGet Configuration 資產會白費嗎？

不會白費。DSC v3 可以透過配接器資源(DSC 3.2 以上為 Microsoft.Adapter/PowerShell 與 Microsoft.Adapter/WindowsPowerShell，在此之前則是 Microsoft.DSC/PowerShell 與 Microsoft.Windows/WindowsPowerShell)呼叫以類別為基礎以及以 MOF 為基礎的既有 PSDSC 資源。此外，WinGet Configuration 從 v3 結構描述(WinGet 1.11 以上)開始，已經把 DSC v3 當成處理引擎使用。既有的 v2 格式 .winget 檔仍可在原本的處理引擎上運作，但要放到 DSC v3 的處理引擎上，就得依照官方的轉換指南改寫成 v3 格式。

用 DSC v3 要怎麼「持續地」強制某個組態？

DSC v3 本身是以命令方式啟動的工具，並沒有 v1.1 裡 LCM(Local Configuration Manager)那樣的常駐代理程式或自動修復機制。如果需要持續套用與稽核，就自己用工作排程器或 CI 定期執行 dsc config test 來偵測偏移，或者放到 Azure 的 Machine Configuration(透過 Azure Arc 也能把地端伺服器納入管理)這類協調層上。

直接執行 dsc config set 讓我有點怕，可以事先確認影響嗎？

可以。執行 dsc config test，就能在不做任何變更的前提下確認哪些資源執行個體不處於期望狀態。另外，dsc config set 還有 --what-if 選項，可以在不實際變更的情況下顯示「執行之後會有什麼、怎麼改變」的預測。先用 test 與 --what-if 看清楚差異，確認沒問題再執行 set，這樣的順序是安全的。

用 DSC 對 Windows 做宣告式組態管理 —— 從 dsc.exe 開始的 IaC

2026年08月28日 00:00 · 更新日期: 2026年09月09日 · Go Komura · Windows, DSC, IaC, PowerShell, winget, 組態管理

更新紀錄(僅初版,2026年08月28日發布)

2026年08月28日: 初次發布

新電腦的安裝步驟文件、寫著伺服器建置步驟的 Excel、離職者留下的祖傳 BAT 檔 —— 到今天為止，許多現場的 Windows 組態管理仍然靠「寫著步驟的文件」與「執行步驟的腳本」在運轉。這種做法的弱點很明確：步驟從執行的那一刻起就開始與現實脫節，而腳本在第二次執行時就會壞掉。

在 Linux 與雲端上，Terraform、Ansible 這類宣告式的 IaC(Infrastructure as Code)早已是常態。那麼，要用同樣的思維去管理 Windows 用戶端與伺服器本身，該用什麼呢？微軟給出的答案是 DSC(Desired State Configuration)，而隨著 2025 年被改寫成不依賴 PowerShell 的命令列工具 Microsoft DSC v3(dsc.exe) 問世，它終於變成「可以正常上手」的樣子了。¹

目標讀者是那些用步驟文件與腳本管理 Windows 電腦與伺服器組態、想要轉向宣告式管理的開發者與資訊人員。前提環境是 Windows 10/11 與 DSC 3.0 以上版本，並以 PowerShell 的基本操作作為背景知識。難度為中級。

1. 先講結論

DSC 裡寫的不是「要執行的步驟」，而是用 YAML 寫「應有的狀態」。與目前狀態的差異偵測(test)與套用(set)由資源負責，所以同一份檔案執行幾次都安全(冪等)，組態也變成可以在 Git 上審查的資料。現在才要開始的話，Microsoft DSC v3(dsc.exe)是唯一的選擇。

步驟腳本與宣告式組態的差別，會顯現在「壞掉的方式」上。寫著步驟的腳本，對中途失敗的電腦或已經設定完成的電腦再跑一次，就會因為重複套用或錯誤而停住。宣告式的組態只寫了「應有的狀態」，所以不管跑幾次、從什麼樣的中間狀態開始跑，都會收斂到同一個結果。²

flowchart TB
    accTitle: 命令式步驟文件與宣告式組態的對比
    accDescr: 命令式腳本由上而下執行步驟，因此重跑會造成重複套用或中斷；而宣告式的 DSC 宣告應有的狀態並只套用差異，所以執行幾次都會收斂到同一個狀態
    imp["命令式：寫步驟（BAT・步驟文件）"] --> i1["由上而下依序執行"]
    i1 --> i2["重跑會重複套用・出錯"]
    dec["宣告式：寫狀態（DSC）"] --> d1["偵測與目前狀態的差異"]
    d1 --> d2["只套用差異・跑幾次都安全"]

圖1: 命令式腳本對「執行次數」很敏感，而宣告式組態不論執行幾次都會收斂到同一個狀態。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 17 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 釐清「DSC」這個名字帶來的混亂 —— 四個系譜

學習 DSC 時最先絆住人的，不是技術本身，而是搜尋結果的混亂。名字叫「DSC」的機制一共有四個系譜，寫法、執行方式與相容性都不一樣。³

系譜	實體	定位
PSDSC v1.1	Windows PowerShell 5.1 內建	舊式方案。LCM 常駐・MOF 格式
PSDSC v2	給 PowerShell 7 用的模組	PSDesiredStateConfiguration 2.x
PSDSC v3(預覽版)	PowerShell 模組	供 Azure Machine Configuration 的 Linux 支援之用
Microsoft DSC v3	獨立的 `dsc.exe`	本文的主角。不依賴 PowerShell・跨平台

Microsoft DSC v3 並不是把先前的 PowerShell DSC(PSDSC)單純更新一版，而是切開對 PowerShell 的依賴之後重新改寫出來的另一項產品。組態不再是 PowerShell 腳本而是 JSON/YAML 資料，資源可以用任何語言實作，而且在 Linux、macOS、Windows 上的行為一致。¹

flowchart TB
    accTitle: DSC 四個系譜的譜系
    accDescr: 從 Windows PowerShell 5.1 內建的 PSDSC v1.1 衍生出給 PowerShell 7 用的 PSDSC v2 與給 Machine Configuration 用的 PSDSC v3 預覽版，而與它們分開、被改寫成不依賴 PowerShell 的 Microsoft DSC v3 成為現行主角的關係
    v11["PSDSC v1.1（WinPS 5.1 內建）"] --> v2["PSDSC v2（PowerShell 7）"]
    v2 --> v3ps["PSDSC v3 預覽版"]
    v11 -.->|"改寫"| dsc3["Microsoft DSC v3（dsc.exe）"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["本文的主角"]

圖2: 搜尋「DSC」時，四個系譜的資訊會混在一起冒出來。先分辨一篇文章或一份資料講的是哪個系譜，這件事很重要。

以下本文中寫到「DSC」，指的都是 Microsoft DSC v3。舊世代的資產不會白費，這一點後面(第 6 節)會說明。

3. 宣告式到底是什麼意思 —— get・test・set 與冪等性

DSC 的核心概念是資源。資源針對「登錄檔值」「Windows 功能」「環境變數」這類每一種組態對象，提供狀態的取得(Get)、判定(Test)、套用(Set)等操作。Get 是所有資源都會實作的。Test 對於沒有自帶實作的資源，由 DSC 用取得結果與宣告的比對(合成測試)來代勞。Set 只有能強制狀態的資源才會實作，像作業系統資訊這種唯讀的資源就沒有。⁴ 使用者把「該怎麼設定」交給資源，自己只用資料寫清楚「什麼應該是什麼樣子」。

正是這樣的分工帶來了冪等性。在套用組態文件(dsc config set)時，DSC 會先對每個執行個體做 test，只對不處於期望狀態的執行個體呼叫 set。所以同一份組態套用幾次都安全。要注意的是，單獨對資源執行 dsc resource set 時一定會呼叫 set，是否有事前測試則取決於資源自身的實作(implementsPretest)，這是兩者的差別。⁵

flowchart TB
    accTitle: 由 get・test・set 構成的收斂迴圈
    accDescr: test 把組態文件裡寫的應有狀態與目前狀態做比對，沒有差異就什麼都不做，有差異則由 set 只套用差異，並可用 get 確認結果，這就是冪等的收斂流程
    doc["組態文件（應有的狀態）"] --> test["test：與目前狀態比對"]
    test -->|"沒有差異"| ok["什麼都不做（冪等）"]
    test -->|"有差異"| set["set：只套用差異"]
    set --> get["get：確認結果狀態"]

圖3: DSC 的套用是「先比對，再只改必要的部分」的迴圈，從此可以擺脫執行次數這個概念。

用程式碼來看它與命令式腳本的差別。例如「往登錄檔寫入這個值」這件事，在腳本裡要自己把存在檢查、建立、更新都分別寫出來。

# 命令式:寫「步驟」。分支與順序全都要自己管理
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

在 DSC 裡，同一件事寫成「應有狀態」的宣告。沒有存在檢查，也沒有分支。

# 宣告式:寫「狀態」。怎麼建立、怎麼修正是資源的工作
- name: 應用程式的運作模式
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. 裝上 dsc.exe，單獨呼叫資源試試看

DSC 的安裝方式有兩種。要嘛從 GitHub 的 Release 下載封存檔解壓縮後加入 PATH，要嘛在 Windows 上經由 Microsoft Store 來源用 winget 安裝。¹

# 從 Microsoft Store 來源搜尋並安裝穩定版
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

裝好之後，先列出本機可以使用的資源。

dsc resource list

在寫組態文件之前，資源也可以一個一個單獨呼叫。正是這種「可以小步嘗試」的特性，讓 v3 學起來輕鬆許多。⁶

# 取得目前的狀態(get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# 判定是否處於期望狀態(test) ── 完全不做變更
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: dsc resource 命令的四種操作
    accDescr: dsc resource 命令之下掛著列出資源的 list、取得目前狀態的 get、不做變更只判定是否處於期望狀態的 test，以及套用狀態的 set（僅限實作了 Set 的資源）這四種操作的結構
    cli["dsc resource 命令"] --> l["list：資源一覽"]
    cli --> g["get：取得目前狀態"]
    cli --> t["test：只判定・不變更"]
    cli --> s["set：套用（支援 Set 的資源）"]

圖4: 不寫組態文件也能單獨呼叫資源。先只用 get 與 test 從觀察開始，是安全的入門路線。

凡是伴隨 set 的變更操作，以及處理 HKLM、系統設定的資源，都需要系統管理員權限。試手時從寫入目標位於使用者底下(例如 HKCU)的例子開始，會比較穩當。

5. 組態文件 —— 用 YAML 寫「應有的狀態」

把多個資源集中宣告在一起的就是組態文件。它用 YAML 或 JSON 撰寫，至少要定義 $schema 與 resources 兩項。每個資源執行個體都帶有 name(在文件內唯一的顯示名稱)、type(資源的完整限定名稱)、properties(期望的狀態)。²

# standard-pc.dsc.config.yaml ── 標準用戶端電腦應有的狀態
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: 應用程式的運作模式
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

用上 parameters 與 variables，就能在一份文件裡表達各環境之間的差異(例如依部門而不同的設定值)。運算式的寫法是 ARM 範本函式的一個子集。²

flowchart TB
    accTitle: 組態文件的結構
    accDescr: 組態文件由表示文件結構描述的 schema、吸收環境差異的 parameters 與 variables，以及資源執行個體的陣列 resources 構成，而每個執行個體都帶有 name・type・properties 的結構
    docroot["組態文件（YAML / JSON）"] --> sch["$schema：文件結構描述的 URI"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources：執行個體的陣列"]
    res --> inst["name・type・properties"]
    par -.-> inst

圖5: 組態文件只是「結構描述+參數+資源宣告」這樣單純的資料，而不是程式。

套用之前一定要先插入一步「觀察」。dsc config test 不做任何變更就回報有沒有差異，dsc config set --what-if 則顯示「執行之後會有什麼改變」的預測。⁷

# 1. 確認有沒有差異(不做變更)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. 預測顯示套用之後會有什麼變化(不做變更)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. 認可之後再套用
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. 確認套用之後的狀態
dsc config get --file .\standard-pc.dsc.config.yaml

反方向也有入口。dsc config export 會針對用 --file 傳入的輸入文件中列舉的資源(僅限支援 export 的資源)，產生一份包含系統上所有執行個體的組態文件並輸出到標準輸出。它可以當成把既有環境的現況記錄下來的起點。⁸

# 傳入列舉了目標資源的輸入文件，儲存目前現況的組態文件
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: 安全套用的四個步驟
    accDescr: 先用不做變更的 dsc config test 確認有沒有差異，再用 dsc config set 的 what-if 選項預測顯示變更內容，認可之後用 set 套用，最後用 get 確認結果的安全順序
    t["dsc config test（有無差異）"] --> w["set --what-if（預測變更）"]
    w --> s["dsc config set（套用）"]
    s --> g["dsc config get（確認結果）"]

圖6: 只要不打亂「觀察→預測→套用→確認」的順序，宣告式組態的套用就沒有一翻兩瞪眼的恐懼。

組態文件是資料而不是程式，這是它在維運上最大的優點。「這台電腦上應該設定了什麼」可以當成 YAML 的差異來審查，而變更歷史本身就成了組態的變更歷史。

6. 讓既有資產繼續發揮價值 —— PSDSC 資源的配接器與 WinGet Configuration

一聽到「v3 是另一項產品」，難免會擔心過去的資產，但 DSC v3 可以透過配接器資源這個機制呼叫舊世代的 PSDSC 資源。以 DSC 3.2 以上的現行名稱來說，給 PowerShell 7 以類別為基礎的資源用的是 Microsoft.Adapter/PowerShell，給 Windows PowerShell 5.1 以 MOF 為基礎、以腳本為基礎的資源用的是 Microsoft.Adapter/WindowsPowerShell(在此之前的名字是 Microsoft.DSC/PowerShell 與 Microsoft.Windows/WindowsPowerShell)。⁹ 多年累積下來的 PSDSC 資源生態系，可以從 v3 的組態文件直接觸及。

另一個連接點是 WinGet Configuration。在 PC 裝機的文章裡介紹過的 .winget 檔，從 v3 結構描述(WinGet 1.11 以上)開始，已經直接把 DSC v3 當成處理引擎來用。只要在組態檔的 metadata 中把處理引擎指定為 dscv3，文件的內容就是 DSC v3 的組態文件本身。¹⁰

# WinGet Configuration v3 ── 內容就是 DSC v3 的組態文件
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: 應用程式的運作模式
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

這裡有一個需要注意的地方。既有的 v2 格式(用 properties.configurationVersion: 0.2.0 並把資源放在 properties 底下的寫法)檔案，並不能原樣在 dscv3 處理引擎上運作。v2 檔案仍會在原本的處理引擎上繼續運作，但要放到 DSC v3 上，就要依照官方的轉換指南(範例儲存庫裡的「Convert to v3」)遷移寫法。¹⁰

flowchart TB
    accTitle: 以 DSC v3 為中心的分層結構
    accDescr: winget configure 或 Azure Machine Configuration 這類協調層呼叫 DSC v3，DSC v3 直接呼叫原生資源，而既有的 PSDSC 資源則經由配接器資源呼叫的分層結構
    orch["winget configure・Machine Configuration"] --> dsc["dsc.exe（DSC v3）"]
    dsc --> native["原生資源（Registry 等）"]
    dsc --> adapter["配接器資源"]
    adapter --> psdsc["既有 PSDSC 資源（PowerShell 資產）"]

圖7: DSC v3 既是一個獨立的工具，同時也是 winget、Azure 這些上層工具的共同基礎。既有的 PSDSC 資產就掛在配接器底下。

也就是說，用 v3 學到的知識與寫下的組態，在手邊的 dsc.exe 上、在裝機用的 winget configure 上、在雲端管理的 Machine Configuration 上都通用。這不是重新學，而是匯流。¹

7. 讓它跑進日常維運 —— 用 Git 管理，偵測偏移

組態文件的存放地點要選Git 儲存庫。這麼一來，組態變更就走上「用 Pull Request 審查、合併、再套用」這條和軟體開發一樣的流程。步驟文件忘了更新這個概念本身就消失了。

套用之後的課題是組態偏移(有人手動改了設定，於是漸漸偏離應有的狀態)。在 DSC 裡，偏移偵測就等於定期執行 dsc config test。test 不做任何變更，所以能把偵測與修復分開，這是很重要的性質。先只把偵測自動化，修復(set)則等看清楚差異內容之後再做，這才是穩當的做法。

# 定期執行用:區分 test 本身的失敗、個別資源的錯誤與偏移，三者都以非零結束
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test 的執行本身失敗了(結束代碼: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # 文件驗證失敗或部分資源以非零結束。檢查沒有跑完，不能回報為健康
    Write-Error "部分資源的檢查發生錯誤。請確認 messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "偵測到組態偏移"
    exit 1
}

定期執行的載體，在用戶端電腦上可以用工作排程器(無人執行的設計在另一篇文章裡說明)，在成群的伺服器上可以用 CI 執行器。如果組織已經把管理集中到 Azure，那麼 Machine Configuration 就是一個受管的承接方，能對 Azure VM 以及經由 Azure Arc 納管的地端伺服器做稽核與套用。¹¹

flowchart TB
    accTitle: 以 Git 為起點的組態管理維運循環
    accDescr: 放在 Git 儲存庫裡的組態文件先經 Pull Request 審查再套用，由工作排程器或 CI 定期執行 test 偵測偏移，確認差異後或者修復、或者回到更新組態的循環
    git["Git 儲存庫（組態文件）"] --> pr["變更用 Pull Request 審查"]
    pr --> apply["用 dsc config set 套用"]
    apply --> sched["定期執行：dsc config test"]
    sched -->|"偵測到偏移"| judge["確認差異並判斷如何處置"]
    judge -.->|"組態是對的"| fix["用 set 修復"]
    judge -.->|"現實是對的"| git

圖8: 面對偏移的手段不只有「修復」。如果現場的變更是對的，那麼改掉組態文件再合併，才是宣告式管理的規矩。

圖8 右下角的分支很容易被忽略。偏移並不總是「壞事」，有時只是現場必要的變更還沒有寫回組態而已。這種時候不該把電腦改回去，而應該讓組態文件去貼合現實。權威始終在 Git 裡的宣告——只要守住這條紀律，不論倒向哪一邊，管理都不會垮。

8. 限制與陷阱

把上手之前該知道的限制老實列出來。

沒有 LCM。 v1.1 裡的 LCM(Local Configuration Manager)是一個常駐代理程式，它會保存組態並做定期套用與自動修復。v3 是「只在被呼叫時才動的命令」，不會以服務的形式常駐。¹ 如果需要持續強制，就得像上一節那樣自己選擇執行的載體(工作排程器、CI、Machine Configuration)。這不是退步，而是把「如何觸發執行」開放給現代工具的設計變更，不過帶著 v1.1 的 pull server 那套感覺過來的人，確實會一時不適應。

系統管理員權限的處理。 涉及整台機器的資源(HKLM、Windows 功能等)在 set 時需要提升權限，透過配接器使用 Windows PowerShell 系的 PSDSC 資源時，也以系統管理員身分執行為前提。⁶ 在撰寫組態文件的階段就把依使用者的設定與依機器的設定分開，執行內容的設計會輕鬆許多。

不要把祕密資訊寫進組態。 組態文件是要放進 Git 的資料。不要把密碼與 API 金鑰直接寫死，而應該做成參數化、在執行時傳入的設計。

別人的組態檔要先讀過再執行。 組態文件擁有透過資源改變系統的力量。從公開儲存庫取得的 .winget 檔與組態文件，要先確認內容以及所引用資源的可信度，然後再套用。這是官方文件也明確警告過的維運必修項目。¹²

flowchart TB
    accTitle: v1.1 的 LCM 常駐型與 v3 的命令型的對比
    accDescr: PSDSC v1.1 裡由常駐的 LCM 保存組態並負責定期 pull 與自動修復，而 DSC v3 只是以命令的形式被啟動，因此定期執行的載體要從工作排程器、CI、Machine Configuration 之中自己挑選並準備
    v1["PSDSC v1.1：LCM 常駐"] --> pull["保存組態並定期 pull・自動修復"]
    v3["DSC v3：只以命令啟動"] --> push["執行的載體自己準備"]
    push -.-> ex["工作排程器・CI・Machine Configuration"]

圖9: v3 裡沒有「記住組態並擅自幫你修好的某個人」。把這看成不方便，還是看成重新拿回了執行的控制權，正是設計上的分水嶺。

9. 總結 —— 把步驟文件換成儲存庫

現在才要開始做 Windows 的宣告式 IaC，就用 Microsoft DSC v3(dsc.exe)。請隨時留意，你正在讀的資料屬於四個「DSC」系譜中的哪一個。³
DSC 用 YAML/JSON 寫的不是「步驟」而是「應有的狀態」，由 test(比對)與 set(套用差異) 保證冪等的收斂。先從 dsc resource get/test 的觀察開始，再用 --what-if 確認影響，最後才套用，這個流程是安全的。⁷
既有的 PSDSC 資源經由配接器、裝機用的 .winget 資產經由 WinGet Configuration v3 結構描述，都能匯入 v3 的世界(v2 格式的檔案需要依轉換指南遷移寫法)。⁹¹⁰
v3 裡沒有 LCM。把組態的正本放在 Git 上，用定期執行的 dsc config test 偵測偏移，再依「組態是對的就修復、現實是對的就更新組態」的紀律轉起來，這就是維運的骨架。

步驟文件的宿命，就是從寫下的那一刻起便與現實漸行漸遠。宣告式的組態管理，把這種落差變成了「能被偵測出來的差異」。先把自己電腦上的幾項設定寫成組態文件，跑一次 dsc config test 看看吧。你應該能體會到步驟文件正在被儲存庫取代的感覺。

參考連結

Microsoft Learn, Microsoft Desired State Configuration overview. 關於 DSC v3 是一個宣告式、冪等的組態平台，不依賴 PowerShell 並可在 Linux・macOS・Windows 上運作；不包含 LCM(Local Configuration Manager)，以命令的形式啟動而不以服務常駐；透過配接器資源與 PSDSC 資源保持相容；可以從 winget 的 Microsoft Store 來源(穩定版 ID 9NVTPZWRC6KQ)或 GitHub Release 安裝；以及 WinGet、Microsoft Dev Box、Azure Machine Configuration 是協調層的早期夥伴。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, DSC configuration documents. 關於組態文件是宣告應有狀態的 YAML/JSON 資料檔，而「該怎麼設定」由資源負責；必要屬性是 $schema 與 resources，每個執行個體都帶有 name・type・properties；用 parameters 與 variables 可以減少重複定義並表達動態的值；由 dsc config get/test/set/export 四種操作來處理；以及支援 ARM 範本運算式函式的一個子集。 ↩ ↩² ↩³
Microsoft Learn, Desired State Configuration (DSC) Overview. 關於 DSC 有四個版本(內建於 Windows PowerShell 5.1 的 PSDSC 1.1、給 PowerShell 7 用的 PSDSC 2.0、用於 Azure Machine Configuration 之 Linux 支援的 PSDSC 3.0 預覽版，以及作為不依賴 PowerShell 的獨立產品的 Microsoft DSC 3.0)，並且 Microsoft DSC 3.0 是真正的跨平台方案、也能使用既有的 PSDSC 資源。 ↩ ↩²
Microsoft Learn, DSC Resources. 關於資源是組態對象的標準化介面，用宣告式語法寫下「什麼是應有的狀態」，而「該怎麼設定」由資源承擔；資源必定具備 Get 與 Test 操作，大多數資源還支援用 Set 強制狀態；用完整限定型別名稱(owner.group.area/name)指定資源；以及配接器資源讓非命令型的資源也能被使用。 ↩
Microsoft Learn, dsc resource set. 關於 dsc config set 中 DSC 一定會對每個執行個體做測試(資源自帶的 test 實作或合成測試)，並只對不處於期望狀態的執行個體呼叫 set；相對地，單獨的 dsc resource set 一定會呼叫 set，是否有事前測試取決於資源資訊清單的 set.implementsPretest；以及對於沒有 implementsPretest 的資源，建議在 set 之前先執行 dsc resource test。 ↩
Microsoft Learn, Get started with DSC. 關於發現資源、單獨呼叫資源、管理組態文件這一入門流程；用 Microsoft.Windows/Registry 資源的 get・test・set 做單獨操作；用 dsc config test/set/get 驗證、套用、確認組態；以及處理 Windows PowerShell 系的 PSDSC 資源時需要系統管理員權限的終端機。 ↩ ↩²
Microsoft Learn, dsc config set. 關於 dsc config set 是把組態文件中應有的狀態套用到系統上的命令，以及用 –what-if 選項可以在不實際做出變更的前提下顯示「執行之後會有什麼、怎麼改變」的預測。另附 DSC Resource manifest whatIf property，關於當資源沒有直接實作 what-if 行為時，這項資訊會由 test 結果合成出來。 ↩ ↩²
Microsoft Learn, dsc config export. 關於 export 子命令會針對用 –file 或 –input 傳入的輸入文件中列舉的資源，產生並回傳定義了所有既有執行個體的組態文件；輸入文件中只能指定資訊清單裡帶有 export 區段的資源，且每種資源型別只宣告一次。 ↩
Microsoft Learn, Microsoft.Adapter/WindowsPowerShell. 關於配接器資源讓與 Windows PowerShell 5.1 相容的 PSDSC 資源(腳本、類別、二進位)可以被 DSC v3 發現與呼叫；它使用內建的 PSDesiredStateConfiguration 1.1 模組；這個名字在 DSC 3.2 中取代了原本的 Microsoft.Windows/WindowsPowerShell 配接器；以及在 PowerShell 7 上使用以類別為基礎的資源時要用 Microsoft.Adapter/PowerShell(舊稱 Microsoft.DSC/PowerShell)。 ↩ ↩²
Microsoft Learn, WinGet Configuration file v3 schema reference. 關於 WinGet Configuration 的 v3 結構描述把 DSC v3 當成處理引擎；需要 WinGet 1.11 以上與 dscv3 處理引擎(作為獨立套件 Microsoft.DesiredStateConfiguration 自動安裝)；要在 metadata.winget.processor.identifier 中指定 dscv3 並把 resources 直接寫在文件的根部；以及官方範例儲存庫裡備有從 v2 格式轉換的指南。 ↩ ↩² ↩³
Microsoft Learn, Understanding Azure Machine Configuration. 關於 Azure Policy 的 Machine Configuration 功能可以對 Azure 虛擬機器與支援 Azure Arc 的伺服器，以受管的方式做作業系統內設定的稽核(audit)與組態(configure)。 ↩
Microsoft Learn, configure 命令 (winget). 關於 winget configure 是用 WinGet Configuration 檔把機器設定成期望狀態的命令；執行前應確認檔案內容並驗證相關資源可信度的警告；以及用 show/list/test/validate/export 子命令可以顯示檔案內容、列出已套用的組態、把目前狀態與期望狀態做比對、驗證檔案、匯出組態。 ↩

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。

查看服務聯絡我們

常見問題

整理諮詢這個主題時常見的問題。

DSC 好像有好幾個版本，我該用哪一個？: 如果你現在才要開始做宣告式組態管理，就用 Microsoft DSC v3(dsc.exe)。DSC 一共有四個系譜：內建於 Windows PowerShell 5.1 的 PSDSC v1.1、給 PowerShell 7 用的模組 PSDSC v2、用於 Azure Machine Configuration 之 Linux 支援的 PSDSC v3(預覽版)，以及被改寫成不依賴 PowerShell 的獨立命令 Microsoft DSC v3。v3 是跨平台的，組態不再寫成 PowerShell 腳本，而是寫成 YAML/JSON 資料，既有的 PSDSC 資源也能透過配接器繼續沿用。搜尋時加上「DSC v3」「dsc.exe」，比較容易把舊世代的資料區隔開來。
DSC v3 和步驟腳本(BAT 或 PowerShell)差在哪裡？: 步驟腳本寫的是「要執行的步驟」，所以為了第二次執行時不會重複套用或出錯，冪等性必須由你自己做出來。DSC 把「應有的狀態」寫成資料，而與目前狀態的比對(test)以及差異的套用(set)則由資源負責。同一份組態文件執行幾次都沒關係，對於已經處於期望狀態的項目它什麼都不做，因此可以不必在意執行次數就發佈與重跑。而且組態本身就是 YAML 資料，用 Git 做差異審查和版本管理，比腳本容易太多。
既有的 PowerShell DSC 資源與 WinGet Configuration 資產會白費嗎？: 不會白費。DSC v3 可以透過配接器資源(DSC 3.2 以上為 Microsoft.Adapter/PowerShell 與 Microsoft.Adapter/WindowsPowerShell，在此之前則是 Microsoft.DSC/PowerShell 與 Microsoft.Windows/WindowsPowerShell)呼叫以類別為基礎以及以 MOF 為基礎的既有 PSDSC 資源。此外，WinGet Configuration 從 v3 結構描述(WinGet 1.11 以上)開始，已經把 DSC v3 當成處理引擎使用。既有的 v2 格式 .winget 檔仍可在原本的處理引擎上運作，但要放到 DSC v3 的處理引擎上，就得依照官方的轉換指南改寫成 v3 格式。
用 DSC v3 要怎麼「持續地」強制某個組態？: DSC v3 本身是以命令方式啟動的工具，並沒有 v1.1 裡 LCM(Local Configuration Manager)那樣的常駐代理程式或自動修復機制。如果需要持續套用與稽核，就自己用工作排程器或 CI 定期執行 dsc config test 來偵測偏移，或者放到 Azure 的 Machine Configuration(透過 Azure Arc 也能把地端伺服器納入管理)這類協調層上。
直接執行 dsc config set 讓我有點怕，可以事先確認影響嗎？: 可以。執行 dsc config test，就能在不做任何變更的前提下確認哪些資源執行個體不處於期望狀態。另外，dsc config set 還有 --what-if 選項，可以在不實際變更的情況下顯示「執行之後會有什麼、怎麼改變」的預測。先用 test 與 --what-if 看清楚差異，確認沒問題再執行 set，這樣的順序是安全的。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽

用 DSC 對 Windows 做宣告式組態管理 —— 從 dsc.exe 開始的 IaC

1. 先講結論

2. 釐清「DSC」這個名字帶來的混亂 —— 四個系譜

3. 宣告式到底是什麼意思 —— get・test・set 與冪等性

4. 裝上 dsc.exe，單獨呼叫資源試試看

5. 組態文件 —— 用 YAML 寫「應有的狀態」

6. 讓既有資產繼續發揮價值 —— PSDSC 資源的配接器與 WinGet Configuration

7. 讓它跑進日常維運 —— 用 Git 管理，偵測偏移

8. 限制與陷阱

9. 總結 —— 把步驟文件換成儲存庫

相關文章

相關的諮詢領域

參考連結

用 winget + PowerShell 自動化 PC 配置 ── 讓操作手冊變得可執行

Windows 名稱解析的順序 ── hosts、DNS 快取、LLMNR/mDNS 與 DoH

快速啟動的真面目 ── Windows 的「關機」為什麼和重新啟動不一樣

在 C#・PowerShell 中使用 WMI/CIM ── 硬體資訊取得・處理程序監控・遠端查詢的實務指南

群組原則(GPO)實務入門 ── 運作機制、生效確認與 Intune 的分工

相關主題

Windows 技術主題