WindowsServer 2025 総合ガイド 第14回
サービスとファイアウォールのDSC化 ― 手動設定から自動化へ

前回（第13回）では、YAML構文の基礎とDSC構成ファイルの構造を学び、レジストリ設定を例に構成ファイルの作成・テスト・適用を実践しました。第14回では、基礎編で手動設定したサービス管理（第5回）とファイアウォール設定（第7回）をDSC構成ファイルで自動化する方法を学びます。「手動で理解した設定をDSCで再現する」という流れを通じて、構成管理の実践力を身につけましょう。

14.1 この記事で学ぶこと

• 基礎編で学んだサービス管理をDSC構成ファイルで自動化できる
• ファイアウォール設定をDSC構成ファイルで自動化できる
• 複数のリソースを組み合わせた複合構成ファイルを作成できる
• dependsOnによるリソース間の依存関係を定義できる
• 「手動で検証 → DSC化 → テスト → 適用」のワークフローを実践できる

14.2 前提条件

• 第13回完了（DSC構成ファイルの基本構造とYAML構文を理解していること）
• 第5回（サービス管理）と第7回（ファイアウォール）の内容を理解していること
• DSC v3がインストールされ、dsc --versionでバージョンが確認できること
• PSDesiredStateConfigurationモジュールがインストールされていること
• PowerShell 7.4を管理者として起動できる状態

14.3 手動設定の振り返り：サービス管理

まず、第5回で学んだサービス管理の内容を振り返ります。DSC構成ファイルを作成する前に、「手動ではどのようにサービスを管理していたか」を確認しておくことが重要です。手動の操作を理解していなければ、構成ファイルの内容が何を意味しているのか分からなくなるためです。

14.3.1 第5回で学んだサービス管理コマンド

第5回では、以下のPowerShellコマンドレットを使ってサービスを管理しました。

たとえば、Windows Timeサービスを「自動起動」に設定し、起動する手順は以下のとおりでした。

[実行環境: PowerShell 7.4 (管理者)]

# サービスの現在の状態を確認
Get-Service -Name "W32Time" | Select-Object -Property Name, Status, StartType

# スタートアップの種類を「自動」に変更
Set-Service -Name "W32Time" -StartupType Automatic

# サービスを起動
Start-Service -Name "W32Time"

# 設定結果を確認
Get-Service -Name "W32Time" | Select-Object -Property Name, Status, StartType

実行結果の例：

Name    Status StartType
----    ------ ---------
W32Time Running Automatic

14.3.2 手動設定の課題とDSC化の必要性

手動でのサービス管理には、以下のような課題があります。

• 再現性の問題：複数のサーバーに同じ設定を適用する場合、手動では手順の抜け漏れが発生しやすい
• 構成ドリフト：時間の経過とともに、誰かが設定を変更し、サーバーごとに設定が異なる状態になる可能性がある
• ドキュメントとの乖離：手順書と実際の設定が一致しなくなることがある
• 冪等性の欠如：手動コマンドは「既に起動しているサービスを起動しようとする」とエラーになることがある

DSCを使えば、「サービスがどのような状態であるべきか」を宣言的に定義でき、これらの課題を解決できます。構成ファイル自体がドキュメントの役割も果たすため、設定内容とドキュメントが常に一致します。

14.4 サービスリソースの使用

DSC v3でサービスを管理するには、PSDesiredStateConfigurationモジュールのServiceリソースを使用します。第13回で学んだとおり、このリソースはWindowsPowerShellアダプター経由で利用します。

14.4.1 利用可能なサービスリソースの確認

まず、DSC v3で利用可能なサービス関連のリソースを確認しましょう。

[実行環境: PowerShell 7.4 (管理者)]

# サービス関連のリソースを検索
dsc resource list --adapter Microsoft.Windows/WindowsPowerShell | Select-String "Service"

実行結果の例：

PSDesiredStateConfiguration/Service          resource  1.1    gs--t---  Microsoft.Windows/WindowsPowerShell
PSDesiredStateConfiguration/ServiceSet       resource  1.1    gs--t---  Microsoft.Windows/WindowsPowerShell

サービス管理に使用できるリソースは以下の2つです。

本記事では、最も基本的なPSDesiredStateConfiguration/Serviceリソースを使用します。

ネイティブリソースとアダプター経由リソースの違い：第13回で学んだとおり、Microsoft.Windows/Registryのようなネイティブリソースはトップレベルに直接記述できますが、PSDesiredStateConfiguration/Serviceはアダプター経由リソースのため、Microsoft.Windows/WindowsPowerShellアダプターのproperties.resources内に記述する必要があります。

14.4.2 Serviceリソースのプロパティ

PSDesiredStateConfiguration/Serviceリソースで設定できる主なプロパティは以下のとおりです。

サービス名と表示名の違いに注意：Nameプロパティにはサービス名（W32Timeなど）を指定します。DisplayName（Windows Timeなど）ではありません。サービス名はGet-ServiceコマンドレットのName列に表示される値です。

14.5 サービス構成ファイルの作成

それでは、実際にサービスを管理するDSC構成ファイルを作成していきましょう。

14.5.1 単一サービスの構成例：Windows Timeサービス

まず、第5回で手動設定したWindows Timeサービスの設定をDSC構成ファイルで再現します。

手動での設定コマンド：

[実行環境: PowerShell 7.4 (管理者)]

# 手動での設定（第5回で学んだ方法）
Set-Service -Name "W32Time" -StartupType Automatic
Start-Service -Name "W32Time"

これをDSC構成ファイルで表現すると、以下のようになります。

[ファイル: w32time-service.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# Windows Timeサービスの構成
# 手動操作: Set-Service -Name "W32Time" -StartupType Automatic / Start-Service -Name "W32Time"
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: W32Time-Service-Configuration
resources:
  - name: Configure Windows Time Service
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Windows Time Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W32Time
            State: Running
            StartupType: Automatic
            Ensure: Present

この構成ファイルを分解して理解しましょう。

構成のテスト

構成ファイルを作成したら、適用前にテストを実行します。

[実行環境: PowerShell 7.4 (管理者)]

# 構成のテスト（変更は行われない）
dsc config test --file ./w32time-service.dsc.yaml

実行結果の例（サービスが既に目的の状態にある場合）：

metadata:
  Microsoft.DSC:
    version: 3.1.0
    operation: test
    executionType: actual
    startDatetime: 2026-02-08T10:00:00.000000+09:00
    endDatetime: 2026-02-08T10:00:05.000000+09:00
    duration: PT5S
    securityContext: elevated
results:
  - metadata:
      Microsoft.DSC:
        duration: PT4.5S
    name: Configure Windows Time Service
    type: Microsoft.Windows/WindowsPowerShell
    result:
      desiredState:
        resources:
          - name: Windows Time Service
            type: PSDesiredStateConfiguration/Service
            properties:
              Name: W32Time
              State: Running
              StartupType: Automatic
              Ensure: Present
      actualState:
        result:
          - name: Windows Time Service
            type: PSDesiredStateConfiguration/Service
            result:
              inDesiredState: true
      inDesiredState: true
      differingProperties: []

テスト結果の見方は第13回で学んだとおりです。

• inDesiredState: true：既に目的の状態であり、変更不要
• inDesiredState: false：目的の状態と異なるため、変更が必要

構成の適用

テストでinDesiredState: falseが表示された場合は、構成を適用します。

[実行環境: PowerShell 7.4 (管理者)]

# 構成の適用
dsc config set --file ./w32time-service.dsc.yaml

# 適用後の状態確認
dsc config get --file ./w32time-service.dsc.yaml

14.5.2 複数サービスの構成例

実務では、複数のサービスをまとめて管理したい場面がよくあります。たとえば、サーバーの基本的な運用に必要な複数のサービスを一括で管理する構成ファイルを作成してみましょう。

[ファイル: basic-services.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# 基本サービスの構成
# サーバー運用に必要な基本サービスをまとめて管理
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: Basic-Services-Configuration
resources:
  - name: Configure Basic Services
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        # Windows Timeサービス：時刻同期
        # 手動操作: Set-Service -Name "W32Time" -StartupType Automatic
        - name: Windows Time Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W32Time
            State: Running
            StartupType: Automatic
            Ensure: Present

        # Windows Eventログサービス：イベントログ記録
        # 手動操作: Get-Service -Name "EventLog" で状態確認
        - name: Windows Event Log Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: EventLog
            State: Running
            StartupType: Automatic
            Ensure: Present

        # DNS Clientサービス：名前解決
        # 手動操作: Get-Service -Name "Dnscache" で状態確認
        - name: DNS Client Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: Dnscache
            State: Running
            StartupType: Automatic
            Ensure: Present

このように、1つのアダプター（Microsoft.Windows/WindowsPowerShell）のresources配列内に複数のServiceリソースを並べることで、複数のサービスを一括管理できます。

[実行環境: PowerShell 7.4 (管理者)]

# 複数サービスの構成をテスト
dsc config test --file ./basic-services.dsc.yaml

14.5.3 手動コマンドとDSC構成の対応表

ここで、手動コマンド（PowerShell）とDSC構成（YAML）の対応関係を整理しておきましょう。この対応を理解することが、手動設定をDSC化する際の基本となります。

DSC化のメリット：手動コマンドでは「起動する」「設定を変更する」という命令的なアプローチですが、DSCでは「この状態であるべき」という宣言的なアプローチです。DSCが自動的に現在の状態と目標状態を比較し、差異がある場合のみ変更を適用します。そのため、構成ファイルを何度適用しても安全です（冪等性）。

14.6 手動設定の振り返り：ファイアウォール

次に、第7回で学んだファイアウォール設定を振り返ります。

14.6.1 第7回で学んだファイアウォール管理コマンド

第7回では、以下のPowerShellコマンドレットを使ってファイアウォールを管理しました。

たとえば、HTTP（TCP 80番ポート）の受信を許可する規則を作成する手順は以下のとおりでした。

[実行環境: PowerShell 7.4 (管理者)]

# HTTPの受信を許可する規則を作成（第7回で学んだ方法）
New-NetFirewallRule `
    -DisplayName "Allow HTTP Inbound" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -Action Allow `
    -Profile Any `
    -Enabled True

14.6.2 ファイアウォール設定のDSC化の必要性

手動でのファイアウォール管理には、サービス管理と同様の課題に加えて、以下のような特有の課題があります。

• 設定の複雑さ：ファイアウォール規則は多数のパラメータを持ち、手動での設定ミスが起きやすい
• 規則の重複：同じポートに対する規則を複数回作成してしまう可能性がある（手動では冪等性がない）
• 監査の困難さ：多数の規則の中から、意図した設定が正しく適用されているか確認が難しい

第12回で学んだように、DSCの冪等性によって「規則が既に存在する場合は何もしない」という動作が自動的に保証されます。これにより、構成ファイルを何度適用しても規則が重複することはありません。

14.7 ファイアウォールリソースの使用

DSC v3でファイアウォール規則を管理するには、NetworkingDscモジュールのFirewallリソースを使用します。このリソースもアダプター経由で利用します。

14.7.1 NetworkingDscモジュールのインストール

ファイアウォールのDSCリソースは、PSDesiredStateConfigurationモジュールには含まれていません。別途NetworkingDscモジュールをインストールする必要があります。

[実行環境: PowerShell 7.4 (管理者)]

# NetworkingDscモジュールのインストール
Install-Module -Name NetworkingDsc -Force -AllowClobber

# インストールの確認
Get-Module -Name NetworkingDsc -ListAvailable | 
    Select-Object -Property Name, Version

実行結果の例：

Name           Version
----           -------
NetworkingDsc  9.0.0

14.7.2 利用可能なファイアウォールリソースの確認

モジュールをインストールしたら、利用可能なファイアウォールリソースを確認します。

[実行環境: PowerShell 7.4 (管理者)]

# ファイアウォール関連のリソースを検索
dsc resource list --adapter Microsoft.Windows/WindowsPowerShell | Select-String "Firewall"

実行結果の例：

NetworkingDsc/Firewall                resource  ...  gs--t---  Microsoft.Windows/WindowsPowerShell
NetworkingDsc/FirewallProfile         resource  ...  gs--t---  Microsoft.Windows/WindowsPowerShell

なぜ追加モジュールが必要なのか：PSDesiredStateConfigurationモジュールにはServiceやWindowsFeatureといった基本的なリソースが含まれていますが、ファイアウォールのような専門的な管理機能は、コミュニティが開発したNetworkingDscモジュールで提供されています。PowerShell Galleryから簡単にインストールできます。

14.7.3 Firewallリソースのプロパティ

NetworkingDsc/Firewallリソースで設定できる主なプロパティは以下のとおりです。

14.8 ファイアウォール構成ファイルの作成

ファイアウォール規則をDSC構成ファイルで管理する方法を実践しましょう。

14.8.1 基本的なポート開放の構成

HTTP（TCP 80番ポート）の受信を許可する規則をDSC構成ファイルで定義します。

手動での設定コマンド：

[実行環境: PowerShell 7.4 (管理者)]

# 手動でのファイアウォール規則作成（第7回で学んだ方法）
New-NetFirewallRule `
    -DisplayName "Allow HTTP Inbound" `
    -Name "Allow-HTTP-Inbound" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -Action Allow `
    -Profile Any `
    -Enabled True

これをDSC構成ファイルで表現すると、以下のようになります。

[ファイル: firewall-http.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# HTTP受信許可のファイアウォール規則
# 手動操作: New-NetFirewallRule -DisplayName "Allow HTTP Inbound" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: Firewall-HTTP-Configuration
resources:
  - name: Configure HTTP Firewall Rule
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Allow HTTP Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTP-Inbound
            DisplayName: Allow HTTP Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "80"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any
            Description: "HTTP通信（TCP 80）の受信を許可"

LocalPortの書き方に注意：LocalPortは配列として指定します。YAMLでは- "80"のようにリスト形式で記述し、値は文字列として指定します。複数ポートを指定する場合は- "80"と- "443"のように複数行で記述するか、1つの規則ではなく別々の規則として定義することもできます。

[実行環境: PowerShell 7.4 (管理者)]

# ファイアウォール構成のテスト
dsc config test --file ./firewall-http.dsc.yaml

14.8.2 複数規則の一括定義

Webサーバーでよく必要になるHTTP（80）とHTTPS（443）の両方を開放する構成ファイルを作成します。

[ファイル: firewall-web.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# Webサーバー用ファイアウォール規則
# HTTP(80)とHTTPS(443)の受信を許可
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: Firewall-Web-Configuration
resources:
  - name: Configure Web Firewall Rules
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        # HTTP（TCP 80）の受信許可
        # 手動操作: New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
        - name: Allow HTTP Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTP-Inbound
            DisplayName: Allow HTTP Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "80"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any
            Description: "HTTP通信（TCP 80）の受信を許可"

        # HTTPS（TCP 443）の受信許可
        # 手動操作: New-NetFirewallRule -DisplayName "Allow HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
        - name: Allow HTTPS Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTPS-Inbound
            DisplayName: Allow HTTPS Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "443"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any
            Description: "HTTPS通信（TCP 443）の受信を許可"

14.8.3 手動コマンドとDSC構成の対応表（ファイアウォール）

14.9 複合構成ファイルの作成

ここまで、サービスとファイアウォールを個別に管理する構成ファイルを作成してきました。実務では、これらを1つの構成ファイルにまとめて管理したい場面が多くあります。ここでは、サービスとファイアウォールを組み合わせた複合構成ファイルを作成し、リソース間の依存関係を定義する方法を学びます。

14.9.1 サービスとファイアウォールの組み合わせ

以下の構成ファイルは、Windows Timeサービスの設定と、Webサーバー向けのファイアウォール規則を1つのファイルにまとめたものです。

[ファイル: server-baseline.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# サーバーベースライン構成
# サービス管理とファイアウォール設定を統合管理
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: Server-Baseline-Configuration
resources:
  # ========================================
  # セクション1: 基本サービスの構成
  # ========================================
  - name: Configure Basic Services
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        # Windows Timeサービス
        - name: Windows Time Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W32Time
            State: Running
            StartupType: Automatic
            Ensure: Present

        # Windows Event Logサービス
        - name: Windows Event Log Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: EventLog
            State: Running
            StartupType: Automatic
            Ensure: Present

  # ========================================
  # セクション2: ファイアウォール規則の構成
  # ========================================
  - name: Configure Firewall Rules
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        # HTTP受信許可
        - name: Allow HTTP Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTP-Inbound
            DisplayName: Allow HTTP Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "80"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any

        # HTTPS受信許可
        - name: Allow HTTPS Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTPS-Inbound
            DisplayName: Allow HTTPS Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "443"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any

この構成ファイルでは、トップレベルのresources配列にアダプターリソースを2つ配置し、それぞれの中にサービスリソースとファイアウォールリソースを定義しています。

14.9.2 dependsOnによる依存関係の定義

複合構成ファイルでは、リソース間に「この設定が完了してから次の設定を適用する」という依存関係を定義できます。DSC v3では、dependsOnプロパティとresourceId()関数を使って依存関係を表現します。

たとえば、「サービスの設定が完了してからファイアウォール規則を設定する」という依存関係を定義する場合は、以下のように記述します。

[ファイル: server-baseline-with-deps.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# サーバーベースライン構成（依存関係付き）
# サービスの設定完了後にファイアウォール規則を適用
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: Server-Baseline-With-Dependencies
resources:
  # ========================================
  # セクション1: 基本サービスの構成（先に実行）
  # ========================================
  - name: Configure Basic Services
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Windows Time Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W32Time
            State: Running
            StartupType: Automatic
            Ensure: Present

  # ========================================
  # セクション2: ファイアウォール規則の構成（サービス設定後に実行）
  # ========================================
  - name: Configure Firewall Rules
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Allow HTTP Inbound
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTP-Inbound
            DisplayName: Allow HTTP Inbound
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort:
              - "80"
            Enabled: "True"
            Ensure: Present
            Profile:
              - Any
    # サービス構成が完了してからファイアウォール規則を適用
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Configure Basic Services')]"

dependsOnの構文

dependsOnプロパティの値は、resourceId()関数を使って依存先のリソースを指定します。

dependsOn:
  - "[resourceId('リソースタイプ', 'リソース名')]"

• リソースタイプ：依存先リソースのtypeプロパティの値
• リソース名：依存先リソースのnameプロパティの値

複数のリソースに依存する場合は、リスト形式で複数指定できます。

dependsOn:
  - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Configure Basic Services')]"
  - "[resourceId('Microsoft.Windows/Registry', 'Some Registry Setting')]"

dependsOnの注意点：dependsOnはトップレベルのリソース間でのみ設定できます。アダプター内部の個別リソース（たとえばPSDesiredStateConfiguration/Serviceの各インスタンス）に対して直接dependsOnを設定することはできません。アダプター内部のリソースの実行順序を制御したい場合は、アダプターごとにリソースを分けて、トップレベルでdependsOnを設定します。

14.9.3 依存関係の実行順序

dependsOnを使った場合の実行順序を図解すると、以下のようになります。

【dependsOnなしの場合】
  Configure Basic Services  →  Configure Firewall Rules
  （DSCが最適な順序で実行、順序は保証されない）

【dependsOnありの場合】
  Configure Basic Services  →  Configure Firewall Rules
  （必ずサービス設定 → ファイアウォール設定の順序で実行）

dependsOnが特に重要になるのは、リソース間に明確な前提条件がある場合です。たとえば「IISのインストール（WindowsFeature）が完了してから、IIS関連のサービス（W3SVC）を設定する」といったケースでは、dependsOnで正しい順序を保証する必要があります。

14.10 既存設定との整合性確認

DSCを導入する際に重要なのは、既に手動で設定されている環境にDSCを適用する場合の注意点です。

14.10.1 テスト実行の重要性

既存の環境にDSC構成を適用する前に、必ずdsc config testでテストを実行してください。テスト実行は現在の状態と目標状態を比較するだけで、実際の変更は行いません。

[実行環境: PowerShell 7.4 (管理者)]

# ステップ1: まずテストで差分を確認（変更は行われない）
dsc config test --file ./server-baseline.dsc.yaml

テスト結果から、以下の情報を読み取ります。

• 変更が必要なリソース：inDesiredState: falseのリソースを確認する
• 差異の内容：differingPropertiesでどのプロパティが異なるかを確認する
• 予期しない変更がないか：意図しないリソースがfalseになっていないか確認する

14.10.2 段階的な適用

複合構成ファイルを一度に適用するのではなく、段階的に適用することをお勧めします。

1. サービス設定のみを先に適用：サービス構成ファイル単体でテスト・適用する
2. 適用結果を確認：Get-Serviceで手動確認する
3. ファイアウォール設定を適用：ファイアウォール構成ファイル単体でテスト・適用する
4. 適用結果を確認：Get-NetFirewallRuleで手動確認する
5. 統合構成ファイルでテスト：すべてが正しいことを確認する

[実行環境: PowerShell 7.4 (管理者)]

# ステップ1: サービス構成のテスト
dsc config test --file ./basic-services.dsc.yaml

# ステップ2: 問題なければ適用
dsc config set --file ./basic-services.dsc.yaml

# ステップ3: 手動で結果を確認
Get-Service -Name "W32Time", "EventLog", "Dnscache" |
    Select-Object -Property Name, Status, StartType

# ステップ4: ファイアウォール構成のテスト
dsc config test --file ./firewall-web.dsc.yaml

# ステップ5: 問題なければ適用
dsc config set --file ./firewall-web.dsc.yaml

# ステップ6: 手動で結果を確認
Get-NetFirewallRule -DisplayName "Allow HTTP*", "Allow HTTPS*" |
    Select-Object -Property DisplayName, Direction, Action, Enabled

実行結果の例：

Name     Status StartType
----     ------ ---------
W32Time  Running Automatic
EventLog Running Automatic
Dnscache Running Automatic

DisplayName          Direction Action Enabled
-----------          --------- ------ -------
Allow HTTP Inbound   Inbound   Allow  True
Allow HTTPS Inbound  Inbound   Allow  True

14.10.3 ロールバックの考慮

DSC v3には自動的なロールバック機能はありません。そのため、構成を適用する前に以下の対策を講じておくことが重要です。

• 現在の状態を記録する：適用前にdsc config getで現在の状態を取得し、保存しておく
• 元に戻す構成ファイルを準備する：必要に応じて、元の状態に戻すための構成ファイルを作成しておく
• テスト環境で検証する：可能であれば、本番環境に適用する前にテスト環境で検証する

[実行環境: PowerShell 7.4 (管理者)]

# 適用前に現在の状態をファイルに保存
dsc config get --file ./server-baseline.dsc.yaml | 
    Out-File -FilePath "./backup-state-$(Get-Date -Format 'yyyyMMdd-HHmmss').json"

14.11 構成管理のワークフロー

ここまで学んだ内容を踏まえて、実務で推奨される構成管理のワークフローを整理します。

14.11.1 4ステップのワークフロー

DSCによる構成管理は、以下の4ステップで進めます。

ステップ1        ステップ2            ステップ3           ステップ4
┌─────────┐    ┌──────────────┐    ┌────────────┐    ┌─────────┐
│ 手動で   │ →  │ DSC構成       │ →  │ テスト環境  │ →  │ 本番環境 │
│ 設定検証 │    │ ファイル作成  │    │ でDSCテスト │    │ に適用   │
└─────────┘    └──────────────┘    └────────────┘    └─────────┘
 PowerShellで     YAML構成ファイル     dsc config test    dsc config set
 動作確認         を作成                で差分確認          で適用

ステップ1：手動で設定を検証する

新しい設定を行う場合は、まずPowerShellで手動実行し、動作を確認します。

[実行環境: PowerShell 7.4 (管理者)]

# 例：新しいサービス設定を手動で検証
Set-Service -Name "W32Time" -StartupType Automatic
Start-Service -Name "W32Time"
Get-Service -Name "W32Time"  # 動作確認

ステップ2：動作確認後、DSC構成ファイルを作成する

手動で動作を確認できたら、その設定をDSC構成ファイル（YAML）に変換します。手動コマンドのパラメータとDSCプロパティの対応表（本記事の14.5.3、14.8.3を参照）を活用してください。

ステップ3：テスト環境でDSCテストを実行する

[実行環境: PowerShell 7.4 (管理者)]

# テスト実行（変更なし）
dsc config test --file ./構成ファイル名.dsc.yaml

# テスト結果を確認し、意図した差分のみであることを確認

ステップ4：本番環境に適用する

[実行環境: PowerShell 7.4 (管理者)]

# 構成の適用
dsc config set --file ./構成ファイル名.dsc.yaml

# 適用後の状態確認
dsc config get --file ./構成ファイル名.dsc.yaml

14.11.2 このワークフローを守る理由

このワークフローが重要な理由は以下のとおりです。

• ステップ1（手動検証）：設定内容の正しさを確認し、意図しない影響がないことを確認する
• ステップ2（DSC化）：検証済みの設定をコード化することで、再現性とドキュメント性を確保する
• ステップ3（テスト）：YAML構文の誤りやプロパティの設定ミスを事前に検出する
• ステップ4（適用）：テスト済みの構成を安全に適用する

基礎編で学んだ手動スキルが活きる場面：このワークフローからも分かるとおり、DSCを使うからといって手動での設定スキルが不要になるわけではありません。むしろ、手動での理解がDSC構成ファイルの正確な作成に不可欠です。基礎編（第5回、第7回）で学んだ手動設定の知識は、DSC化する際の「何を」「どう」設定すべきかの判断基準になります。

14.12 よくあるエラーと対処法

14.12.1 サービスリソースのエラー

14.12.2 ファイアウォールリソースのエラー

14.12.3 依存関係のエラー

14.12.4 エラー調査の基本手順

エラーが発生した場合は、以下の手順で調査します。

[実行環境: PowerShell 7.4 (管理者)]

# 1. トレースレベルをdebugにしてテスト実行
dsc config test --file ./構成ファイル名.dsc.yaml --trace-level debug

# 2. 手動でリソースの状態を確認
Get-Service -Name "W32Time" | Select-Object -Property *
Get-NetFirewallRule -DisplayName "Allow HTTP*" | Select-Object -Property *

# 3. リソースが利用可能か確認
dsc resource list --adapter Microsoft.Windows/WindowsPowerShell | Select-String "Service"
dsc resource list --adapter Microsoft.Windows/WindowsPowerShell | Select-String "Firewall"

14.13 まとめ

第14回では、以下の内容を学びました。

• 手動設定からDSC化への流れ
  • 第5回で学んだサービス管理コマンド（Get-Service、Set-Service、Start-Service）をDSC構成ファイルで再現する方法
  • 第7回で学んだファイアウォール管理コマンド（New-NetFirewallRule）をDSC構成ファイルで再現する方法
  • 手動コマンドのパラメータとDSCプロパティの対応関係
• サービスリソースの使用
  • PSDesiredStateConfiguration/Serviceリソースのプロパティ（Name、State、StartupType）
  • 単一サービスおよび複数サービスの構成ファイル作成
  • アダプター経由での記述方法
• ファイアウォールリソースの使用
  • NetworkingDscモジュールのインストール
  • NetworkingDsc/Firewallリソースのプロパティ（Name、Direction、Action、Protocol、LocalPort）
  • ポート開放規則の構成ファイル作成
• 複合構成ファイルと依存関係
  • サービスとファイアウォールを1つの構成ファイルにまとめる方法
  • dependsOnとresourceId()関数によるリソース間の依存関係定義
  • トップレベルリソース間でのみdependsOnを設定できること
• 構成管理のワークフロー
  • 「手動で検証 → DSC化 → テスト → 適用」の4ステップ
  • 既存環境への適用時のテスト実行の重要性
  • 段階的な適用とロールバックの考慮

14.14 次回予告

第15回では「DSC実践演習 ― Webサーバー環境の自動構築」と題して、IIS Webサーバーの自動構築を通じた実践的な複合構成ファイルの作成、SSL/TLS証明書の設定、バックアップの基本、そしてシリーズ全体の総括を行います。今回学んだサービスとファイアウォールのDSC化に加え、WindowsFeatureリソースによるIISのインストールを組み合わせ、実務レベルの自動構築を体験しましょう。

14.15 参考リンク

• DSC Configuration document resource instance schema – Microsoft Learn
• DSC Service Resource – Microsoft Learn
• NetworkingDsc モジュール – GitHub
• Get started with DSC – Microsoft Learn
• Get started with Microsoft Desired State Configuration v3.0.0 – PowerShell Team
• Using DSC v3 on Windows Server 2025 – Microsoft Tech Community
• DSC v3 GitHub リポジトリ – PowerShell/DSC
• NetworkingDsc – PowerShell Gallery