WindowsServer 2025 総合ガイド 第15回
DSC実践演習 ― Webサーバー環境の自動構築

前回（第14回）では、基礎編で手動設定したサービス管理とファイアウォール設定をDSC構成ファイルで自動化する方法を学びました。最終回となる第15回では、これまでの学習内容を総動員して、IIS Webサーバーの自動構築という実務レベルのシナリオに取り組みます。WindowsFeatureリソースによるIISのインストール、SSL/TLS証明書の設定、サービスとファイアウォールの構成を統合した複合構成ファイルを作成し、DSC v3による構成管理の実践力を仕上げましょう。

15.1 この記事で学ぶこと

• IIS Webサーバーの自動構築を通じて、複合的なDSC構成ファイルを作成できる
• SSL/TLS証明書を作成し、IISにHTTPSバインドを設定できる
• WindowsFeature、Service、Firewallの各リソースを組み合わせた統合構成を設計できる
• バックアップの基本的な考え方とWindows Server Backupの使い方を理解する
• DSC構成ファイルのトラブルシューティングができる
• 構成管理のベストプラクティスを理解する

15.2 前提条件

• 第14回完了（サービスとファイアウォールのDSC化を理解していること）
• DSC v3がインストールされ、dsc --versionでバージョンが確認できること
• PSDesiredStateConfigurationモジュールがインストールされていること
• NetworkingDscモジュールがインストールされていること（第14回でインストール済み）
• PowerShell 7.4を管理者として起動できる状態

15.3 シナリオ設定

15.3.1 目標：IIS Webサーバーの自動構築

今回のシナリオは、「新しいWindows Server 2025に、HTTPS対応のIIS Webサーバーを一から構築する」というものです。実務では、サーバーのセットアップ作業は何度も繰り返されます。新しいサーバーを追加するたびに手動で同じ設定を行うのは、時間がかかるうえにミスの原因にもなります。DSC構成ファイルにまとめておけば、同じ構成をどのサーバーにも素早く正確に適用できます。

15.3.2 構築する環境の要件

今回構築する環境の要件は以下のとおりです。

SSL/TLS証明書の設定について：DSC v3の標準リソースには、証明書の作成やIISバインドを直接管理するリソースが含まれていません。そのため、SSL/TLS証明書の設定はPowerShellコマンドで手動実施し、それ以外の部分をDSCで自動化するという方針で進めます。実務でも、すべてをDSCで管理するのではなく、手動設定とDSCを適切に使い分けることが重要です。

15.4 構成ファイルの設計

15.4.1 必要なリソースの洗い出し

構成ファイルを作成する前に、必要なリソースを洗い出し、全体像を把握することが重要です。いきなり構成ファイルを書き始めるのではなく、「何を」「どのような順序で」設定するかを設計しましょう。

15.4.2 適用順序の設計

リソースの適用順序は重要です。たとえば、IISがインストールされていない状態でW3SVCサービスの設定を行おうとしてもエラーになります。適用順序を制御するために、第14回で学んだdependsOnを活用します。

依存関係の設計は以下のようになります。

IIS役割のインストール
    ├─→ IIS管理ツールの追加
    ├─→ W3SVCサービスの起動設定
    └─→ ファイアウォール設定（HTTP/HTTPS）

すべてのリソースが「IIS役割のインストール」に依存する構造です。IISがインストールされることで初めて、W3SVCサービスが存在し、ファイアウォールの開放が意味を持ちます。

15.4.3 構成ファイルの分割 vs 統合

構成ファイルを1つにまとめるか、複数に分割するかは、状況に応じて判断します。

今回は学習目的のため、まず個別のリソースを順番に作成して動作を確認し、最終的に統合構成ファイルとしてまとめる方法を取ります。

15.5 IISのインストール（DSC）

15.5.1 手動でのIISインストール（振り返り）

第10回で学んだInstall-WindowsFeatureコマンドレットを使ったIISのインストール方法を振り返ります。

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

# 手動でのIISインストール（第10回で学んだ方法）
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

# インストール確認
Get-WindowsFeature -Name Web-Server

実行結果の例：

Display Name                                            Name                       Install State
------------                                            ----                       -------------
[X] Web Server (IIS)                                    Web-Server                     Installed

15.5.2 WindowsFeatureリソースによるDSC構成

この手動操作をDSC構成ファイルで表現します。WindowsFeatureリソースは、PSDesiredStateConfigurationモジュールに含まれるリソースで、Windows Serverの役割と機能のインストール状態を管理します。

[ファイル: iis-feature.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# IIS Webサーバー機能のインストール
# 手動操作: Install-WindowsFeature -Name Web-Server -IncludeManagementTools
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: IIS-Feature-Installation
resources:
  # IIS Webサーバー役割のインストール
  - name: Install IIS Web Server
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web-Server Feature
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Server
            Ensure: Present

  # IIS管理ツールの追加
  - name: Install IIS Management Tools
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web-Mgmt-Tools Feature
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Mgmt-Tools
            Ensure: Present
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS Web Server')]"

構成ファイルの解説

WindowsFeature名の確認方法：使用可能なWindowsFeature名はGet-WindowsFeatureコマンドレットで確認できます。Get-WindowsFeature -Name Web-*を実行すると、IIS関連の機能一覧が表示されます。

構成のテスト

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

# テスト実行（変更は行われない）
dsc config test --file ./iis-feature.dsc.yaml

実行結果の例（IISがまだインストールされていない場合）：

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:15.000000+09:00"
    duration: PT15S
    securityContext: elevated
results:
  - metadata:
      Microsoft.DSC:
        duration: PT10S
    name: Install IIS Web Server
    type: Microsoft.Windows/WindowsPowerShell
    result:
      actualState:
        resources:
          - name: Web-Server Feature
            type: PSDesiredStateConfiguration/WindowsFeature
            properties:
              Name: Web-Server
              Ensure: Absent
      inDesiredState: false
  - metadata:
      Microsoft.DSC:
        duration: PT5S
    name: Install IIS Management Tools
    type: Microsoft.Windows/WindowsPowerShell
    result:
      actualState:
        resources:
          - name: Web-Mgmt-Tools Feature
            type: PSDesiredStateConfiguration/WindowsFeature
            properties:
              Name: Web-Mgmt-Tools
              Ensure: Absent
      inDesiredState: false

inDesiredState: falseと表示されているため、IISはまだインストールされていない状態です。変更が必要であることがわかります。

構成の適用

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

# 構成の適用
dsc config set --file ./iis-feature.dsc.yaml

注意：IISのインストールには数分かかる場合があります。また、環境によっては適用後に再起動が必要になることがあります。再起動が必要かどうかは、適用結果のメッセージで確認してください。

インストール後の手動確認

DSCで構成を適用した後は、必ず手動でも確認しましょう。

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

# IISがインストールされたことを確認
Get-WindowsFeature -Name Web-Server, Web-Mgmt-Tools | 
    Select-Object -Property DisplayName, Name, InstallState

実行結果の例：

DisplayName                  Name           InstallState
-----------                  ----           ------------
Web Server (IIS)             Web-Server        Installed
Web Management Tools         Web-Mgmt-Tools    Installed

# W3SVCサービスが存在し、動作していることを確認
Get-Service -Name W3SVC | Select-Object -Property Name, Status, StartType

実行結果の例：

Name  Status StartType
----  ------ ---------
W3SVC Running Automatic

# ブラウザからもアクセスできることを確認（ローカルテスト）
Invoke-WebRequest -Uri "http://localhost" -UseBasicParsing | 
    Select-Object -Property StatusCode, StatusDescription

実行結果の例：

StatusCode StatusDescription
---------- -----------------
       200 OK

15.6 SSL/TLS証明書の設定

15.6.1 HTTPS通信の必要性

現代のWebでは、HTTPS（Hypertext Transfer Protocol Secure）による暗号化通信が事実上の標準となっています。まず、なぜHTTPSが必要なのかを理解しましょう。

HTTP通信のリスク

HTTP（暗号化なし）で通信を行った場合、以下のリスクがあります。

現代のWebにおけるHTTPS必須化

Google Chromeをはじめとする主要なWebブラウザは、HTTPサイトに対して「保護されていない通信」という警告を表示します。また、検索エンジンのランキングにおいてもHTTPSが優遇されています。こうした背景から、たとえ社内向けのWebサーバーであっても、HTTPSを有効にすることが推奨されています。

15.6.2 SSL/TLS証明書の種類

HTTPSを有効にするにはSSL/TLS証明書が必要です。証明書にはいくつかの種類があります。

重要：本シリーズでは学習目的のため自己署名証明書を使用します。自己署名証明書は自分自身が発行元（認証局）となる証明書で、ブラウザからは「信頼されていない証明書」として警告が表示されます。本番環境では、DigiCert、GlobalSignなどの商用認証局から取得した証明書や、Let’s Encryptの無料証明書を使用してください。

15.6.3 証明書ストアの概念

Windows Serverでは、証明書は「証明書ストア」と呼ばれる場所に保存されます。証明書ストアとは、証明書を分類・管理するためのフォルダのようなものです。

IISのHTTPSバインドに使用する証明書は、Cert:\LocalMachine\My（個人ストア）に格納します。

15.6.4 自己署名証明書の作成

PowerShellのNew-SelfSignedCertificateコマンドレットを使って、自己署名証明書を作成します。このコマンドレットはWindows PowerShell 5.1に含まれるpkiモジュールの一部ですが、PowerShell 7.4からも互換性機能を通じて利用できます。

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

# 自己署名証明書の作成
$cert = New-SelfSignedCertificate `
    -DnsName "localhost" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -NotAfter (Get-Date).AddYears(1) `
    -FriendlyName "IIS Development Certificate" `
    -KeyAlgorithm RSA `
    -KeyLength 2048

各パラメータの説明は以下のとおりです。

作成された証明書を確認します。

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

# 作成した証明書の情報を表示
$cert | Select-Object -Property Subject, Thumbprint, NotBefore, NotAfter, FriendlyName

実行結果の例：

Subject      : CN=localhost
Thumbprint   : A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2
NotBefore    : 2026/02/08 10:00:00
NotAfter     : 2027/02/08 10:00:00
FriendlyName : IIS Development Certificate

Thumbprint（拇印）について：Thumbprintは証明書を一意に識別するハッシュ値で、40文字の16進数で表されます。IISへのバインド設定時にこの値を使用します。上記の例はサンプルであり、実際の値は環境ごとに異なります。

15.6.5 IISへのHTTPSバインド設定

作成した証明書をIISの既定のWebサイトにバインド（関連付け）して、HTTPS通信を有効にします。IISの管理に使用するコマンドレットはIISAdministrationモジュールに含まれています。

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

# IISAdministrationモジュールのインポート
Import-Module IISAdministration

# HTTPSバインドの追加
New-IISSiteBinding `
    -Name "Default Web Site" `
    -BindingInformation "*:443:" `
    -Protocol https `
    -CertificateThumbPrint $cert.Thumbprint `
    -CertStoreLocation "Cert:\LocalMachine\My"

各パラメータの説明です。

バインドが正しく設定されたことを確認します。

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

# サイトのバインド一覧を確認
Get-IISSite -Name "Default Web Site" | 
    Select-Object -ExpandProperty Bindings | 
    Select-Object -Property protocol, bindingInformation

実行結果の例：

protocol bindingInformation
-------- ------------------
http     *:80:
https    *:443:

15.6.6 HTTPS接続の確認

設定が完了したら、HTTPS接続をテストします。

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

# HTTPS接続のテスト（自己署名証明書のため、証明書検証をスキップ）
# PowerShell 7.4ではSkipCertificateCheckパラメータが使用可能
Invoke-WebRequest -Uri "https://localhost" -UseBasicParsing -SkipCertificateCheck | 
    Select-Object -Property StatusCode, StatusDescription

実行結果の例：

StatusCode StatusDescription
---------- -----------------
       200 OK

ブラウザでの確認：リモートデスクトップ経由でサーバーにアクセスしている場合は、サーバー上のブラウザでhttps://localhostを開いて確認することもできます。自己署名証明書を使用しているため、「この接続ではプライバシーが保護されません」という警告が表示されますが、「詳細設定」→「localhostにアクセスする（安全ではありません）」をクリックすれば、IISの既定ページが表示されます。

15.6.7 SSL/TLS証明書設定のまとめスクリプト

ここまでの証明書関連の操作をまとめたスクリプトを作成しておくと、再実行する際に便利です。

[ファイル: setup-https.ps1]

# HTTPS設定スクリプト
# 用途: 自己署名証明書の作成とIISへのHTTPSバインド設定
# 注意: 開発・テスト環境用。本番環境では商用CA証明書を使用すること

#Requires -RunAsAdministrator

# パラメータ設定
$dnsName = "localhost"
$certStorePath = "Cert:\LocalMachine\My"
$siteName = "Default Web Site"

# 1. 自己署名証明書の作成
Write-Host "自己署名証明書を作成しています..." -ForegroundColor Cyan
$cert = New-SelfSignedCertificate `
    -DnsName $dnsName `
    -CertStoreLocation $certStorePath `
    -NotAfter (Get-Date).AddYears(1) `
    -FriendlyName "IIS Development Certificate" `
    -KeyAlgorithm RSA `
    -KeyLength 2048

Write-Host "証明書を作成しました: $($cert.Thumbprint)" -ForegroundColor Green

# 2. IIS管理モジュールのインポート
Import-Module IISAdministration

# 3. 既存のHTTPSバインドを確認
$existingBinding = Get-IISSiteBinding -Name $siteName -Protocol https
if ($existingBinding) {
    Write-Host "既存のHTTPSバインドが見つかりました。スキップします。" -ForegroundColor Yellow
} else {
    # 4. HTTPSバインドの追加
    Write-Host "HTTPSバインドを追加しています..." -ForegroundColor Cyan
    New-IISSiteBinding `
        -Name $siteName `
        -BindingInformation "*:443:" `
        -Protocol https `
        -CertificateThumbPrint $cert.Thumbprint `
        -CertStoreLocation $certStorePath
    Write-Host "HTTPSバインドを追加しました。" -ForegroundColor Green
}

# 5. 設定の確認
Write-Host "`n=== 設定確認 ===" -ForegroundColor Cyan
Write-Host "証明書:" 
$cert | Select-Object -Property Subject, Thumbprint, NotAfter | Format-List

Write-Host "サイトバインド:"
Get-IISSite -Name $siteName | 
    Select-Object -ExpandProperty Bindings | 
    Select-Object -Property protocol, bindingInformation | Format-Table

Write-Host "HTTPS接続テスト:"
try {
    $response = Invoke-WebRequest -Uri "https://localhost" -UseBasicParsing -SkipCertificateCheck
    Write-Host "  Status: $($response.StatusCode) $($response.StatusDescription)" -ForegroundColor Green
} catch {
    Write-Host "  エラー: $($_.Exception.Message)" -ForegroundColor Red
}

15.7 ファイアウォール設定（DSC）

15.7.1 HTTP/HTTPSポートの開放

IISがWebリクエストを受信するためには、ファイアウォールでHTTP（TCP 80）とHTTPS（TCP 443）のポートを開放する必要があります。第14回で学んだNetworkingDsc/Firewallリソースを使用します。

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

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

  # HTTPS（TCP 443）の受信許可
  - name: Allow HTTPS Inbound
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: HTTPS Firewall Rule
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTPS-Inbound
            DisplayName: "Allow HTTPS Inbound"
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort: "443"
            Ensure: Present
            Enabled: "True"
            Description: "IIS Webサーバー用 HTTPS受信許可"

構成のテストと適用

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

# テスト
dsc config test --file ./iis-firewall.dsc.yaml

# 問題なければ適用
dsc config set --file ./iis-firewall.dsc.yaml

適用後の手動確認

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

# ファイアウォール規則の確認
Get-NetFirewallRule -DisplayName "Allow HTTP*", "Allow HTTPS*" | 
    Select-Object -Property DisplayName, Direction, Action, Enabled

実行結果の例：

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

15.8 統合構成ファイルの作成

15.8.1 全リソースを含む構成ファイル

ここまで個別に作成してきたIISのインストール、サービス設定、ファイアウォール設定を1つの統合構成ファイルにまとめます。これにより、1回のdsc config setコマンドでWebサーバーの基盤を一括構築できるようになります。

[ファイル: iis-webserver.dsc.yaml]

# yaml-language-server: $schema=https://aka.ms/dsc/schemas/v3/bundled/config/document.vscode.json
# ============================================================
# IIS Webサーバー 統合構成ファイル
# 概要: IISのインストール、サービス設定、ファイアウォール設定を
#       一括で管理するための構成ファイル
# 対象: Windows Server 2025 Datacenter Edition
# 注意: SSL/TLS証明書の設定は別途 setup-https.ps1 で実施
# ============================================================
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
metadata:
  name: IIS-WebServer-Configuration
  author: admin
  created: "2026-02-08"
  description: "IIS Webサーバーの基盤構成（機能追加・サービス・ファイアウォール）"

resources:
  # ============================================================
  # 1. IIS Webサーバー役割のインストール
  # GUI: サーバーマネージャー > 役割と機能の追加 > Web Server (IIS)
  # CLI: Install-WindowsFeature -Name Web-Server
  # ============================================================
  - name: Install IIS Web Server
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web-Server Feature
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Server
            Ensure: Present

  # ============================================================
  # 2. IIS管理ツールの追加
  # GUI: サーバーマネージャー > 管理ツール > IISマネージャー
  # CLI: Install-WindowsFeature -Name Web-Mgmt-Tools
  # ============================================================
  - name: Install IIS Management Tools
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web-Mgmt-Tools Feature
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Mgmt-Tools
            Ensure: Present
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS Web Server')]"

  # ============================================================
  # 3. W3SVCサービスの自動起動設定
  # GUI: services.msc > World Wide Web Publishing Service
  # CLI: Set-Service -Name W3SVC -StartupType Automatic
  #      Start-Service -Name W3SVC
  # ============================================================
  - name: Configure W3SVC Service
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: W3SVC Service
          type: PSDesiredStateConfiguration/Service
          properties:
            Name: W3SVC
            State: Running
            StartupType: Automatic
            Ensure: Present
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS Web Server')]"

  # ============================================================
  # 4. HTTP（TCP 80）の受信許可
  # CLI: New-NetFirewallRule -DisplayName "Allow HTTP Inbound"
  #      -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
  # ============================================================
  - name: Allow HTTP Inbound
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: HTTP Firewall Rule
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTP-Inbound
            DisplayName: "Allow HTTP Inbound"
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort: "80"
            Ensure: Present
            Enabled: "True"
            Description: "IIS Webサーバー用 HTTP受信許可"
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS Web Server')]"

  # ============================================================
  # 5. HTTPS（TCP 443）の受信許可
  # CLI: New-NetFirewallRule -DisplayName "Allow HTTPS Inbound"
  #      -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
  # ============================================================
  - name: Allow HTTPS Inbound
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: HTTPS Firewall Rule
          type: NetworkingDsc/Firewall
          properties:
            Name: Allow-HTTPS-Inbound
            DisplayName: "Allow HTTPS Inbound"
            Direction: Inbound
            Action: Allow
            Protocol: TCP
            LocalPort: "443"
            Ensure: Present
            Enabled: "True"
            Description: "IIS Webサーバー用 HTTPS受信許可"
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS Web Server')]"

15.8.2 依存関係の構造

統合構成ファイル内の依存関係を整理すると、以下のようになります。

Install IIS Web Server  ←── 他の全リソースが依存
    ├── Install IIS Management Tools  (dependsOn: Install IIS Web Server)
    ├── Configure W3SVC Service       (dependsOn: Install IIS Web Server)
    ├── Allow HTTP Inbound            (dependsOn: Install IIS Web Server)
    └── Allow HTTPS Inbound           (dependsOn: Install IIS Web Server)

すべてのリソースが「Install IIS Web Server」に依存しているため、必ずIISが先にインストールされます。それ以外のリソースは相互に依存していないため、IISインストール後は並列に処理される可能性があります。

15.8.3 コメントによるドキュメント化

統合構成ファイルでは、各リソースブロックの前にコメントで以下の情報を記載しています。

• リソースの番号と名称：管理しやすくするための連番
• GUIでの操作方法：手動でGUIから同じ設定をする場合の手順
• CLIでの操作方法：PowerShellコマンドレットでの相当操作

この情報があることで、構成ファイルを見た人が「何をしているのか」をすぐに理解でき、トラブルシューティング時にも手動での確認がしやすくなります。

15.9 段階的な構築と検証

15.9.1 テストファーストの実践

統合構成ファイルの適用は、以下の3ステップで行います。これは第13回から繰り返し学んできた「テストファースト」の実践です。

Step 1: テスト実行

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

# 1. テスト（変更は行われない）
dsc config test --file ./iis-webserver.dsc.yaml

テスト結果を確認し、inDesiredState: falseのリソースが変更対象です。意図しない変更がないことを確認してください。

Step 2: 構成の適用

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

# 2. 問題なければ適用
dsc config set --file ./iis-webserver.dsc.yaml

Step 3: 手動での動作確認

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

# 3-1. IIS機能の確認
Get-WindowsFeature -Name Web-Server, Web-Mgmt-Tools | 
    Select-Object -Property DisplayName, InstallState

# 3-2. W3SVCサービスの確認
Get-Service -Name W3SVC | 
    Select-Object -Property Name, Status, StartType

# 3-3. ファイアウォール規則の確認
Get-NetFirewallRule -DisplayName "Allow HTTP*", "Allow HTTPS*" | 
    Select-Object -Property DisplayName, Direction, Action, Enabled

# 3-4. HTTP接続テスト
Invoke-WebRequest -Uri "http://localhost" -UseBasicParsing | 
    Select-Object -Property StatusCode

すべての確認項目が期待どおりであれば、SSL/TLS証明書の設定に進みます。

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

# 4. SSL/TLS証明書の設定（DSCではなくスクリプトで実行）
.\setup-https.ps1

# 5. HTTPS接続テスト
Invoke-WebRequest -Uri "https://localhost" -UseBasicParsing -SkipCertificateCheck | 
    Select-Object -Property StatusCode

15.9.2 ブラウザでのHTTPS接続確認

コマンドラインでの確認に加えて、ブラウザからもHTTPS接続を確認しましょう。リモートデスクトップでサーバーに接続し、ブラウザのアドレスバーにhttps://localhostと入力します。

証明書警告への対処（自己署名の場合）

自己署名証明書を使用しているため、ブラウザに以下のような警告が表示されます。

• Microsoft Edge / Google Chrome：「この接続ではプライバシーが保護されません」→「詳細設定」→「localhost にアクセスする（安全ではありません）」をクリック
• Firefox：「警告: 潜在的なセキュリティリスクあり」→「詳細情報」→「危険性を承知で続行」をクリック

警告を承認すると、IISの既定のスタートページが表示されます。アドレスバーに鍵マーク（斜線付き）が表示され、HTTPS通信が行われていることを確認できます。

この警告は正常です：自己署名証明書は信頼された認証局が発行したものではないため、ブラウザはこの証明書を信頼できるかどうかを判断できません。本番環境で商用CA証明書やLet’s Encrypt証明書を使用すれば、この警告は表示されません。

15.10 バックアップの基本

15.10.1 バックアップの重要性

サーバーを運用するうえで、バックアップは最も重要な作業の1つです。ハードウェア故障、ソフトウェアの不具合、人為的なミス、セキュリティインシデントなど、データ損失のリスクは常に存在します。バックアップがなければ、障害発生時にサーバーを復旧することができません。

RPO（目標復旧時点）とRTO（目標復旧時間）

バックアップの計画を立てる際に、2つの重要な概念があります。

たとえば、毎日深夜にバックアップを取得している場合、RPOは最大24時間です。午前中に障害が発生すると、前日深夜の状態までしか戻せず、当日朝のデータは失われます。業務要件に応じて、バックアップの頻度と方法を決定します。

15.10.2 Windows Server Backup機能の追加

Windows Server 2025には「Windows Server Backup」という機能が用意されています。この機能を追加することで、wbadminコマンドやPowerShellコマンドレットを使ったバックアップ・リストアが可能になります。

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

# Windows Server Backup機能のインストール
Install-WindowsFeature -Name Windows-Server-Backup

# インストール確認
Get-WindowsFeature -Name Windows-Server-Backup

実行結果の例：

Display Name                                            Name                       Install State
------------                                            ----                       -------------
[X] Windows Server Backup                               Windows-Server-Backup          Installed

15.10.3 wbadminコマンドの基本

wbadminは、Windows Server Backupのコマンドラインツールです。バックアップの作成、スケジュール設定、リストアなどの操作を行えます。

バックアップの実行

以下は、Cドライブのシステム状態バックアップを実行する例です。

注意：VPS環境ではバックアップ先となる追加ディスクがない場合があります。ここではコマンドの書式と考え方を学ぶことを目的とし、実行は環境に応じて判断してください。

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

# システム状態のバックアップ（バックアップ先ボリュームが必要）
# wbadmin start systemstatebackup -backupTarget:E: -quiet

# バックアップ先がない場合は、コマンドの書式確認のみ
wbadmin /?

主要なwbadminサブコマンドは以下のとおりです。

バックアップの状態確認

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

# バックアップの一覧を確認
wbadmin get versions

# PowerShellコマンドレットでの確認（WindowsServerBackupモジュール）
Get-WBSummary

15.10.4 バックアップ運用の考え方

3-2-1ルール

バックアップの基本方針として、「3-2-1ルール」が広く推奨されています。

たとえば、以下のような構成が3-2-1ルールを満たします。

• 原本：サーバーのローカルディスク上のデータ
• バックアップ1：外部ストレージ（NASや外付けHDD）へのバックアップ
• バックアップ2：クラウドストレージ（Azure Backup、AWS S3など）へのバックアップ

定期的なリストアテスト

バックアップを取得しているだけでは不十分です。「バックアップからの復旧が本当にできるか」を定期的に確認することが重要です。バックアップファイルが破損していた、復旧手順が不明確だった、などの問題は、実際に復旧を試みるまで発覚しないことがあります。少なくとも四半期に一度はリストアテストを実施することを推奨します。

15.11 トラブルシューティング

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

DSC構成ファイルの作成・適用でよく遭遇するエラーと、その対処法を紹介します。

15.11.2 エラーメッセージの読み方

DSC v3のエラーメッセージは、問題の箇所を特定するための情報を含んでいます。エラーが発生した場合は、以下の順序で確認します。

エラー調査の思考プロセス：

1. エラーメッセージを読む：まずエラーメッセージの内容を確認します。「何が」「なぜ」失敗したのかが記載されています
2. 該当するリソースを特定する：エラーメッセージに含まれるリソース名（nameフィールド）を確認し、どのリソースで問題が発生したかを特定します
3. 構成ファイルの該当箇所を確認する：特定したリソースの記述を構成ファイルで確認し、プロパティやタイプ名に誤りがないか調べます
4. 手動で同じ操作を試す：構成ファイルのリソースが行おうとしている操作を、手動のPowerShellコマンドで実行してみます。手動でもエラーが出れば、問題は構成ファイルではなく環境にあります

15.11.3 デバッグ用トレースの活用

詳細な情報が必要な場合は、--trace-levelオプションを使用します。

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

# デバッグレベルのトレースでテスト実行
dsc config test --file ./iis-webserver.dsc.yaml --trace-level debug

# JSON形式でトレースを出力（スクリプトでの処理に便利）
dsc config test --file ./iis-webserver.dsc.yaml --trace-level debug --trace-format json

トレースレベルは以下の5段階があります。

15.11.4 よくあるYAML構文ミスの例

YAML構文は慣れるまでミスが起きやすいため、代表的な例を紹介します。

ミス1：タブ文字の使用

# NG: タブ文字でインデント
resources:
	- name: Example    # ← タブ文字（目に見えない）
	  type: Microsoft.Windows/Registry

# OK: スペースでインデント
resources:
  - name: Example      # ← スペース2つ
    type: Microsoft.Windows/Registry

ミス2：コロンの後にスペースがない

# NG: コロンの後にスペースがない
properties:
  Name:Web-Server     # ← コロンの後にスペースがない

# OK: コロンの後にスペースあり
properties:
  Name: Web-Server    # ← コロンの後にスペース1つ

ミス3：インデントの不揃い

# NG: 同じレベルのインデントが揃っていない
properties:
  Name: W3SVC
   State: Running     # ← インデントが1つ多い

# OK: 同じレベルのインデントが揃っている
properties:
  Name: W3SVC
  State: Running      # ← 同じインデント

VS Codeの活用：VS Codeの設定で「Editor: Render Whitespace」をallに設定すると、スペースとタブ文字が視覚的に区別でき、インデントのミスを発見しやすくなります。また、YAML拡張機能を有効にしておくと、構文エラーがリアルタイムで表示されます（第13回で設定済み）。

15.12 構成管理のベストプラクティス

15.12.1 構成ファイルのバージョン管理

構成ファイルはテキストファイルであるため、Git等のバージョン管理システムで管理できます。バージョン管理を行うことで、以下のメリットがあります。

• 変更履歴の追跡：誰が、いつ、何を変更したかが記録される
• ロールバック：問題が発生した場合に、以前のバージョンに戻せる
• コードレビュー：変更内容をチーム内でレビューしてから適用できる
• ドキュメント化：コミットメッセージが変更の理由を記録する

[実行環境: PowerShell 7.4 (一般ユーザー)]

# Gitリポジトリの初期化（例）
git init dsc-configurations
Set-Location -Path dsc-configurations

# 構成ファイルを追加
git add iis-webserver.dsc.yaml
git commit -m "IIS Webサーバーの基盤構成ファイルを追加"

15.12.2 環境ごとの構成分離

実務では、開発環境・ステージング環境・本番環境など、複数の環境を管理することがあります。環境ごとに異なる設定値（ポート番号、証明書、データベース接続先など）を分離して管理することが重要です。

構成ファイルのディレクトリ構造の例を以下に示します。

dsc-configurations/
├── base/                          # 全環境共通の構成
│   └── iis-webserver.dsc.yaml
├── environments/                  # 環境固有の設定
│   ├── dev/
│   │   └── firewall-rules.dsc.yaml
│   ├── staging/
│   │   └── firewall-rules.dsc.yaml
│   └── production/
│       └── firewall-rules.dsc.yaml
├── scripts/                       # 補助スクリプト
│   └── setup-https.ps1
└── README.md                      # ドキュメント

15.12.3 コードレビューの実施

構成ファイルの変更を本番環境に適用する前に、必ずチームメンバーによるレビューを実施しましょう。レビューでは以下の観点を確認します。

• 構成ファイルのYAML構文は正しいか
• リソースタイプとプロパティ名は正確か
• 依存関係は適切に定義されているか
• セキュリティ上の問題はないか（不要なポートの開放など）
• テスト環境で事前に検証されているか

15.12.4 定期的な構成ドリフト確認

構成ドリフト（Configuration Drift）とは、手動での変更やソフトウェアのアップデートなどによって、サーバーの実際の状態がDSC構成ファイルで定義した状態から乖離してしまうことです。定期的にdsc config testを実行して、構成ドリフトが発生していないかを確認しましょう。

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

# 構成ドリフトの確認
dsc config test --file ./iis-webserver.dsc.yaml

# すべてのリソースが inDesiredState: true であれば、ドリフトなし
# inDesiredState: false のリソースがあれば、手動変更などによるドリフトが発生している

この確認をタスクスケジューラ（第10回で学習）で定期実行し、結果をログに記録しておくと、ドリフトの早期発見に役立ちます。

15.13 シリーズ総括

15.13.1 学習内容の振り返り

全15回にわたるWindows Server 2025学習シリーズが完了しました。入門編から応用編まで、体系的にサーバー管理の基礎とDSC v3による自動化を学んできました。各編の内容を振り返ります。

入門編（第1回〜第3回）：環境構築とPowerShellの基礎

基礎編（第4回〜第11回）：サーバー管理の基本スキル

応用編（第12回〜第15回）：DSC v3による構成管理の自動化

15.13.2 習得したスキル一覧

このシリーズを通じて、以下のスキルを習得しました。

15.13.3 継続的な学習に向けて

このシリーズで学んだ内容は、Windows Serverインフラエンジニアとしてのスタートラインです。ここからさらにスキルを伸ばすために、以下の学習パスを提案します。

次のステップ：推奨する学習トピック

学習リソース

• Microsoft Learn（https://learn.microsoft.com/ja-jp/）：無料のハンズオンラボとラーニングパスが充実。「Windows Server の基礎」コースがおすすめ
• PowerShell公式ドキュメント（https://learn.microsoft.com/ja-jp/powershell/）：コマンドレットリファレンスやスクリプティングガイド
• DSC v3公式ドキュメント（https://learn.microsoft.com/en-us/powershell/dsc/overview?view=dsc-3.0）：DSC v3のリファレンスとチュートリアル
• DSC v3 GitHubリポジトリ（https://github.com/PowerShell/DSC）：ソースコード、サンプル、Issue（質問・バグ報告）
• PowerShell Gallery（https://www.powershellgallery.com/）：DSCリソースモジュールの検索・インストール
• Microsoft Tech Community（https://techcommunity.microsoft.com/）：技術ブログ、フォーラム、コミュニティディスカッション

資格の取得

スキルの証明として、以下のMicrosoft認定資格の取得を検討してみてください。

• AZ-800：Administering Windows Server Hybrid Core Infrastructure（Windows Serverハイブリッドコアインフラストラクチャの管理）
• AZ-801：Configuring Windows Server Hybrid Advanced Services（Windows Serverハイブリッド高度サービスの構成）
• AZ-900：Azure Fundamentals（Azureの基礎。クラウドの基本を学ぶ最初の一歩として）

15.14 まとめ

第15回（最終回）では、以下の内容を学びました。

• IIS Webサーバーの自動構築
  • WindowsFeatureリソースによるIIS役割と管理ツールのインストール
  • Serviceリソースによる W3SVCサービスの自動起動設定
  • Firewallリソースによる HTTP/HTTPS ポートの開放
  • これらを統合した複合構成ファイルの作成とdependsOnによる依存関係の定義
• SSL/TLS証明書の設定
  • HTTP通信のリスクと、現代のWebにおけるHTTPS必須化の背景
  • New-SelfSignedCertificateによる自己署名証明書の作成
  • New-IISSiteBindingによるIISへのHTTPSバインド設定
  • 自己署名証明書は開発・テスト用途であり、本番環境では商用CA証明書を使用すべきこと
• バックアップの基本
  • RPO（目標復旧時点）とRTO（目標復旧時間）の概念
  • Windows Server Backup機能の追加とwbadminコマンドの基本
  • 3-2-1ルールによるバックアップ運用の考え方
  • 定期的なリストアテストの重要性
• トラブルシューティング
  • DSC構成ファイルでよくあるエラーの種類と対処法
  • エラーメッセージの読み方と原因特定の思考プロセス
  • --trace-levelオプションによるデバッグ情報の取得
  • YAMLの構文ミス（タブ文字、コロン後のスペース、インデント）の具体例と対策
• 構成管理のベストプラクティス
  • Git等によるバージョン管理
  • 環境ごとの構成分離
  • コードレビューの実施
  • 定期的な構成ドリフト確認

本シリーズ全15回を通じて、Windows Server 2025の基本的な管理スキルと、DSC v3による構成管理の自動化を体系的に学びました。「手動で理解する → 自動化する」というアプローチは、トラブルシューティング時にも大きな力を発揮します。手動での操作を理解しているからこそ、自動化ツールが何をしているのかを把握でき、問題が発生した際にも冷静に対処できます。ここで身につけたスキルを土台に、Active DirectoryやAzure連携、コンテナ技術など、さらに高度な領域への学習を進めていってください。

15.15 参考リンク

• DSC v3 Overview – Microsoft Learn
• Get started with Microsoft Desired State Configuration v3.0.0 – PowerShell Team
• Using DSC v3 on Windows Server 2025 – Microsoft Tech Community
• New-SelfSignedCertificate – Microsoft Learn
• New-IISSiteBinding – Microsoft Learn
• Configuring SSL with the IIS PowerShell Snap-in – Microsoft Learn
• wbadmin – Microsoft Learn
• DSC v3 GitHub リポジトリ – PowerShell/DSC
• NetworkingDsc モジュール – GitHub
• Windows Server ドキュメント – Microsoft Learn