ラノベのタイトルっぽくなってしまった...ハマった供養します。
結論
以下のAMIを選択
Microsoft Windows Server 2025 Base
ami-0f2b7d16d1c8c53d0 (64 ビット (x86))
Microsft Windows 2025 Datacenter edition. [English]
日本語化しても中途半端に英語が残ったり、設定が足りずハマったりしました。
Microsoft提供の日本語版のコミュニティAMIを使用しましょう。
ここから先は経緯や何が起きたかを記載します
経緯
社内SE時代にWindows Serverを触っていたのですが、現職ではAmazon Linuxが中心でした。
久しぶりに社内でWindows Serverが必要な場面があり意気揚々と構築したところハマりました。
みなさんも同じ轍を踏まないようにご注意ください。
冒頭の記事でコミュニティAMIの日本語版の存在は知っていたのですが、コミュニティAMIって追加料金かかること多いし公式AMI使うほうがベターかなと判断してしまいました。←ここが甘かった。
後々確認したらMicrosoft提供だし、コストも同じでした。（というかクイックスタートAMIもMicrosoft提供）
日本語化
2025版ではないですが検索すると出てくる記事を元に粛々と行いました。
「unicode対応ではないプログラムの言語」の設定をしてもPowerShellのログをテキストに出すと文字化けしていたのですが、改めてQiitaに記事を書くために以下サイトを見つけ再確認をしたところ冒頭のPowerShellのログ文字化けは解消しました…どうして
レジストリパス
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\00000411
値の名前 Layout File
値のデータ KBDJPN.DDL を kbd106.dll に変更
という感じで設定が漏れると地味にハマることになるようです。
設定後も怪しい箇所
記事書いているときにPowerShellの問題がなくなったので、英語の混在くらいになりました
日本語と英語の混在
設定画面
グループポリシーエディター
編集するときに日本語記事を参照すると場所か翻訳で当てる必要があってひと手間増える
Server Manager
リモートデスクトップで切断すると同じアカウントで再接続できない
そのため毎回ログオフする必要がある。これは英語OSが原因ではないのですが...
なにかの要因で切断されてしまった場合は、再起動するしかなくなり詰むのでAdministrator2的なアカウントを用意し、そっちでログインしユーザーをログオフして救出する必要がある。
Mac版のRDPクライアント が原因なような気がするが、色々グループポリシーも編集したけど解決せず、少し不便。
久しぶりにWindows Serverを触って
ここからは備忘録&ポエムです。
触っていた頃はオンプレの社内SE時代（およそ6年前）で、当時Linux系やクラウドを触っていなかったことに危機感があったので当時の想いを思い出します。
オンプレでやったこと、EC2でやらなくなったこと
※OSはWindowsに限らない内容も含みます
- 物理サーバーの手配
- 物理サーバーをラックにセットしネットワーク配線等を行う
- LANと電源ケーブルの両端にpanduitの回転ラベルをテプラで印刷して巻くまでがセット
- UPSとの連携設定
- IPアドレスの設定
- EC2だとセキュリティグループの設定等のみで良い
- ActiveDirectoryの参加
- リモートデスクトップの許可設定
- 初回からリモートデスクトップ接続なので
- バックアップ&リストア試験
- EC2だとamiないしEBSライフサイクルの設定すれば終了（本当は試験までするべきだが…）
- ライセンス周りの考慮
- 持ち込まない限りはamiに含まれているので楽
- Excelの台帳への記載
- 今はterraformを中心に必要に応じて別のドキュメントを整備
監視周りはCloudwatchAgentを入れて、CPUに加えて、メモリとディスク使用率と簡易的に死活監視を実施。
PowerShellやbatのログ管理にはCloudwatch Logsに転送するようにしました。ログローテーションはAgentでも消すことはできますが、スクリプト内で毎回消すことにしました。
設定したポリシーなど
やんわりと覚えている限りの内容なのでもう少し設定したような気もする
- WindowsUpdateを自動で適用しない
- リモートデスクトップは2接続まで許可
- amiだとデフォルトで変更されていたような気もする
- ログインの試行回数に制限、ロック時間を設定
思い出
工場系の社内SEでサーバールームがあるのは4拠点ほどで一番多い部屋でサーバーラック5個+情報ラックでした。物理サーバーの台数としては50台前後だったような。
各サーバールームがある場所は法定点検で年に1度停電するため、サーバーを停止&起動します。（基本社内向けの基幹システム+サブシステムなので止めてもOK）停止したときの静かなサーバールームと、復旧後に一斉に上がるサーバーの音は今でもなんとなく覚えています。
ちなみに停止時は特定サーバーを除きUPSを作動させて停止させていました。なので電源を抜くor法定点検開始のときはUPSがピーピー鳴って、サーバーが徐々に止まり、ピーピーだけが鳴って、最後静になるって感じです。
ExPing（懐かしい）で疎通を確認しつつ、全台ログインしてエラーがないかとか、機能チェックをやんわりと行ったような記憶があります。
監視や運用、バックアップ&リストア(試験)の部分はだいぶ鍛えられたのを覚えています。
当時はメール通知が主でしたが、今はSlackや便利なログ管理サービスがあり必要なものだけ通知しやすいようになりました。手段は違えどシステムを安定運用するための根幹は変わらないと再認識した構築でした。
英語版or日本語版の選択は判断が甘かった…ですがサーバーの動きとしては満たせいているので結果オーライかつ、次回は日本語版を最初から選びましょう。
ということで本記事を締めくくります。
採用募集しているので興味がある方は、Organizationから会社HPの採用ページを見ていただきつつ適宜Xでご連絡頂けると幸いです。