お世話になっております。水木です。
現場業務にて、AWS EC2 上の Windows Server を複製する機会がありました。
Linux サーバーの複製経験はありましたが、Windows の複製は初対応だったため、留意点や実際に直面した制約条件を備忘としてまとめます。
同様の作業を行う方の参考になれば幸いです。
作業内容
既存の Windows Server をもとに、
検証用（ダミー）のテストサーバーを複製・作成する
Windows Server 複製時の重要ポイント
SID（Security Identifier）について
Windows OS には SID（Security Identifier） という一意の識別子が割り当てられています。
SID は以下の用途で使用されます：
-
ユーザー
-
グループ
-
コンピュータアカウント
などを一意に識別するための可変長の識別番号です。
OS インストール時に自動生成され、
ファイルやフォルダのアクセス制御など内部的なセキュリティ管理に利用されます。
名前が変更されても、SID が同一であれば同一オブジェクトと認識されます。
SID が重複するとどうなるか？
既存サーバーをそのまま複製すると、SID が重複します。
SID の重複は以下のような問題を引き起こす可能性があります：
-
System Center Configuration Manager（SCCM）など、SID を利用して管理する製品への影響
-
ドメイン参加環境におけるセキュアチャネル破損
-
コンピュータアカウント競合
-
管理上の識別不整合
そのため、Sysprep による一般化（Generalize）が必須となります。
Sysprep とは？
Sysprep（System Preparation Tool） は、Windows OS をクローン展開する前に以下を実施するためのツールです。
-
SID のリセット
-
コンピュータ名の初期化
-
デバイス情報の一般化
-
展開前状態への初期化
これにより、安全に複製展開が可能になります。
今回の要件・制約条件
今回の案件では、以下の制約がありました。
-
現行サーバーと同一サブネット内に複製を作成する
-
別 VPC での起動は禁止（セキュリティポリシー上）
-
現行サーバーへ影響を与えないこと
-
複製サーバーはインターネット接続不可
-
現行サーバー上では Sysprep 実行不可
一般的な記事では「別VPCで検証用インスタンスを立てる」手順が多いですが、今回はその方法が使用できませんでした。
そのため、Security Group による通信隔離で対応する方針を取りました。
実施手順
0. 一時的な隔離用 Security Group 作成
新規 EC2 が他サーバーと通信しないよう、一時的な隔離用 SG を作成。
目的：
Sysprep 実行のための RDP 接続のみ許可
設定内容：
-
インバウンド
-
RDP（TCP 3389）のみ許可
アウトバウンド
- なし（全拒否）
1. 既存サーバーの AMI を取得
既存 EC2 から AMI を作成。
2. AMI から新規 EC2 を起動
手順0で作成した隔離用 SG をアタッチ。
3. RDP 接続
起動後、RDP でログイン。
4. 現在の SID を確認
コマンドプロンプトを起動し、以下を実行：
whoami /user
現在の SID を控えておく。
5. Sysprep 実行（EC2Launch Settings）
EC2Launch Settings を開き、
管理者パスワード → Specify
「Sysprep でシャットダウン」を選択
「YES」を押下する
クリーンアップフェーズのポップアップが表示
※検証時は3分から最長10分程処理に時間がかかりました。
実行後、自動シャットダウン。
6. 本番用 SG へ切り替え
隔離用 SG をデタッチし、使用予定の SG をアタッチ。
7. SID 再確認
再度ログインし、
whoami /user
を実行。
事前取得した SID と異なることを確認。
これにより、SID が正しく再生成されたことを確認できる。
今回のポイント
✔ 別VPCが使えない環境での対応
✔ Security Group による論理的隔離
✔ 現行サーバーに一切影響を与えない構成
✔ Sysprep 実行後の SID 検証まで実施
まとめ
Linux サーバーの複製は何度か経験がありましたが、
Windows の複製は SID や Sysprep という独自の考慮点があり、より注意が必要だと感じました。
初めに参考にした記事※では別VPCでの展開が前提でしたが、
今回はセキュリティ要件上それが禁止されていたため、サポートへ相談の上、Security Group による通信遮断で代替という形で進めました。
現場ごとに前提条件は異なります。
マニュアル通りではなく、要件に応じて最適解を選択できるよう、今後も経験を積んでいきたいと思います。