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コマンドレットを使ってサービスを管理しました。
| 操作 | コマンドレット | 例 |
|---|---|---|
| サービスの状態確認 | Get-Service |
Get-Service -Name "W32Time" |
| サービスの起動 | Start-Service |
Start-Service -Name "W32Time" |
| サービスの停止 | Stop-Service |
Stop-Service -Name "W32Time" |
| スタートアップの種類変更 | Set-Service |
Set-Service -Name "W32Time" -StartupType Automatic |
| サービスの再起動 | Restart-Service |
Restart-Service -Name "W32Time" |
たとえば、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 |
単一のサービスを管理する | サービスごとに詳細な設定を行う場合 |
PSDesiredStateConfiguration/ServiceSet |
複数のサービスに同じ設定を一括適用する | 複数サービスを同じ状態にする場合 |
本記事では、最も基本的なPSDesiredStateConfiguration/Serviceリソースを使用します。
ネイティブリソースとアダプター経由リソースの違い：第13回で学んだとおり、
Microsoft.Windows/Registryのようなネイティブリソースはトップレベルに直接記述できますが、PSDesiredStateConfiguration/Serviceはアダプター経由リソースのため、Microsoft.Windows/WindowsPowerShellアダプターのproperties.resources内に記述する必要があります。
14.4.2 Serviceリソースのプロパティ
PSDesiredStateConfiguration/Serviceリソースで設定できる主なプロパティは以下のとおりです。
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
Name |
String | ○（キー） | サービス名（表示名ではなくサービス名を指定） |
State |
String | サービスの状態。Running（実行中）または Stopped（停止） |
|
StartupType |
String | スタートアップの種類。Automatic（自動）、Manual（手動）、Disabled（無効） |
|
Ensure |
String | サービスの存在確認。Present（存在する）または Absent（存在しない） |
|
Description |
String | サービスの説明文 | |
DisplayName |
String | サービスの表示名 | |
Dependencies |
String[] | 依存するサービスのリスト | |
BuiltInAccount |
String | サービス実行アカウント。LocalService、LocalSystem、NetworkService |
サービス名と表示名の違いに注意：
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
この構成ファイルを分解して理解しましょう。
| 行 | 内容 | 説明 |
|---|---|---|
| 1行目 | # yaml-language-server: ... |
VS Code用のスキーマヒント（エディタ補完用） |
| 4行目 | $schema: ... |
DSC v3構成ファイルのスキーマ定義（必須） |
| 5〜6行目 | metadata: |
構成の名前（任意だが推奨） |
| 8行目 | type: Microsoft.Windows/WindowsPowerShell |
アダプター指定（PSDSC リソース使用時に必要） |
| 11行目 | type: PSDesiredStateConfiguration/Service |
Serviceリソースを使用 |
| 13行目 | Name: W32Time |
管理対象のサービス名 |
| 14行目 | State: Running |
サービスが実行中であるべき |
| 15行目 | StartupType: Automatic |
自動起動に設定 |
| 16行目 | 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化する際の基本となります。
| 操作 | 手動コマンド（PowerShell） | DSC構成（YAML プロパティ） |
|---|---|---|
| サービスを起動する | Start-Service -Name "W32Time" |
State: Running |
| サービスを停止する | Stop-Service -Name "W32Time" |
State: Stopped |
| 自動起動に設定 | Set-Service -Name "W32Time" -StartupType Automatic |
StartupType: Automatic |
| 手動起動に設定 | Set-Service -Name "W32Time" -StartupType Manual |
StartupType: Manual |
| 無効に設定 | Set-Service -Name "W32Time" -StartupType Disabled |
StartupType: Disabled |
| サービスの存在確認 | Get-Service -Name "W32Time" |
Ensure: Present |
DSC化のメリット：手動コマンドでは「起動する」「設定を変更する」という命令的なアプローチですが、DSCでは「この状態であるべき」という宣言的なアプローチです。DSCが自動的に現在の状態と目標状態を比較し、差異がある場合のみ変更を適用します。そのため、構成ファイルを何度適用しても安全です（冪等性）。
14.6 手動設定の振り返り：ファイアウォール
次に、第7回で学んだファイアウォール設定を振り返ります。
14.6.1 第7回で学んだファイアウォール管理コマンド
第7回では、以下のPowerShellコマンドレットを使ってファイアウォールを管理しました。
| 操作 | コマンドレット | 例 |
|---|---|---|
| 規則の一覧表示 | Get-NetFirewallRule |
Get-NetFirewallRule -Enabled True |
| 規則の作成 | New-NetFirewallRule |
New-NetFirewallRule -DisplayName "Allow HTTP" ... |
| 規則の変更 | Set-NetFirewallRule |
Set-NetFirewallRule -DisplayName "Allow HTTP" ... |
| 規則の有効化 | Enable-NetFirewallRule |
Enable-NetFirewallRule -DisplayName "Allow HTTP" |
| 規則の無効化 | Disable-NetFirewallRule |
Disable-NetFirewallRule -DisplayName "Allow HTTP" |
| 規則の削除 | Remove-NetFirewallRule |
Remove-NetFirewallRule -DisplayName "Allow HTTP" |
たとえば、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
| リソースタイプ | 説明 | 用途 |
|---|---|---|
NetworkingDsc/Firewall |
個別のファイアウォール規則を管理する | 受信/送信規則の作成・変更・削除 |
NetworkingDsc/FirewallProfile |
ファイアウォールプロファイル全体の設定を管理する | ドメイン/プライベート/パブリックプロファイルの設定 |
なぜ追加モジュールが必要なのか：PSDesiredStateConfigurationモジュールには
ServiceやWindowsFeatureといった基本的なリソースが含まれていますが、ファイアウォールのような専門的な管理機能は、コミュニティが開発したNetworkingDscモジュールで提供されています。PowerShell Galleryから簡単にインストールできます。
14.7.3 Firewallリソースのプロパティ
NetworkingDsc/Firewallリソースで設定できる主なプロパティは以下のとおりです。
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
Name |
String | ○（キー） | ファイアウォール規則の名前（一意な識別子） |
DisplayName |
String | 規則の表示名 | |
Direction |
String | 通信の方向。Inbound（受信）または Outbound（送信） |
|
Action |
String | 許可/拒否。Allow（許可）または Block（ブロック） |
|
Protocol |
String | プロトコル。TCP、UDP、Any など |
|
LocalPort |
String[] | ローカルポート番号（複数指定可） | |
Enabled |
String | 規則の有効/無効。True または False |
|
Profile |
String[] | 適用するプロファイル。Domain、Private、Public、Any |
|
Ensure |
String | 規則の存在。Present（存在すべき）または Absent（存在しないべき） |
|
Description |
String | 規則の説明 |
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構成の対応表（ファイアウォール）
| 操作 | 手動コマンド（PowerShell パラメータ） | DSC構成（YAML プロパティ） |
|---|---|---|
| 規則の名前 | -Name "Allow-HTTP-Inbound" |
Name: Allow-HTTP-Inbound |
| 表示名 | -DisplayName "Allow HTTP Inbound" |
DisplayName: Allow HTTP Inbound |
| 受信規則 | -Direction Inbound |
Direction: Inbound |
| 許可 | -Action Allow |
Action: Allow |
| TCPプロトコル | -Protocol TCP |
Protocol: TCP |
| ポート番号 | -LocalPort 80 |
LocalPort: - "80" |
| 規則の有効化 | -Enabled True |
Enabled: "True" |
| 規則の存在確認 | Get-NetFirewallRule -Name ... |
Ensure: Present |
| 規則の削除 | Remove-NetFirewallRule -Name ... |
Ensure: Absent |
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 段階的な適用
複合構成ファイルを一度に適用するのではなく、段階的に適用することをお勧めします。
- サービス設定のみを先に適用：サービス構成ファイル単体でテスト・適用する
- 適用結果を確認：
Get-Serviceで手動確認する - ファイアウォール設定を適用：ファイアウォール構成ファイル単体でテスト・適用する
- 適用結果を確認：
Get-NetFirewallRuleで手動確認する - 統合構成ファイルでテスト：すべてが正しいことを確認する
[実行環境: 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 サービスリソースのエラー
| エラー内容 | 原因 | 対処法 |
|---|---|---|
| Service ‘xxx’ not found | 指定したサービス名が存在しない | Get-Serviceで正確なサービス名を確認。表示名ではなくサービス名を指定する |
| Access denied | 管理者権限なしで実行している | 管理者権限でPowerShell 7.4を起動して再実行する |
| Cannot start service | サービスの依存関係が満たされていない | 依存するサービスの状態を確認し、必要に応じて構成ファイルに追加する |
| Invalid value for StartupType | StartupTypeの値が不正 | Automatic、Manual、Disabledのいずれかを指定する |
14.12.2 ファイアウォールリソースのエラー
| エラー内容 | 原因 | 対処法 |
|---|---|---|
| Module ‘NetworkingDsc’ not found | NetworkingDscモジュールがインストールされていない | Install-Module -Name NetworkingDsc -Forceでインストールする |
| Resource type not found | リソースタイプの指定が間違っている | dsc resource listで正確なリソースタイプを確認する |
| YAML parse error | YAML構文に誤りがある（インデント不正など） | インデントにスペースのみを使用しているか確認。VS Codeの YAML拡張機能でバリデーションを行う |
| LocalPort expects string array | LocalPortの値が数値になっている | - "80"のように文字列として指定する（- 80ではなく） |
14.12.3 依存関係のエラー
| エラー内容 | 原因 | 対処法 |
|---|---|---|
| Dependency not found | dependsOnで指定したリソースが存在しない |
resourceId()関数の引数（リソースタイプとリソース名）が正確か確認する |
| Circular dependency | リソースAがBに依存し、BがAに依存する循環参照 | 依存関係を見直し、循環参照を解消する |
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プロパティの対応関係
- 第5回で学んだサービス管理コマンド（
- サービスリソースの使用
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
