Hyper-V, Windows Azure / Microsoft Azure, Windows Server, Windows Server 2003

Windows Server 2003 を Azure に移行する際の手順と制限事項

by  •  • 0 Comments

オンプレで いまだに Windows Server 2003 を使っているセキュリティ意識のかけらもない人たちが、そろそろ重い腰を上げてクラウドに移行しようと思っているんじゃないかと思って、気を利かせてブログを書いてみます（皮肉

仮想化 (P2V) だけでは飽き足らず、クラウドにまで負の遺産を引き継ごうという人はいないと信じていますし、このブログが役に立たないことを切に願っています。(頼むからおとなしく Windows Server 2016 / 2019 を使ってくれ…)

ご注意

  • 仮に何らかのアンチウイルス製品でセキュリティ対策を行っていたとしても、Windows Server 2003 はカーネルの設計自体が古いので、極めて脆弱なことを自覚しましょう。
  • クラウドは Internet 経由でアクセスすることを前提としていますが、言わずもがな脆弱な Windows Server 2003 を Internet に晒すことは絶対に避けるべきです。(以前の投稿でも書きましたが、Azure の IP レンジは公開されているので、ポートスキャンや大量のログイン試行が行われます。)
  • つまり、VPN や ExpressRoute などの閉域接続 Only で使いましょう。
  • 加えて、Azure から Internet 宛の通信も可能な限りブロックしましょう。(むしろ、Windows Server 2003 をネットワークに繋いでくれるな。クラウドに持ち込んでくれるな。というお気持ち。)
  • Azure に移行したからといって、レガシーなシステムを塩漬けしていいわけでは決してありません。早く根本的な対応を考えましょう。
  • Windows Server 2003 は Azure 上でも動くことは動きますが、非常に制限が多いので、悪いことは言いませんから Windows Server 2016, 2019 に移行しましょう。

前提環境

  • Hyper-V 上で稼働する第 1 世代の仮想マシン (つまり not UEFI の BIOS 環境)
  • Windows Server 2003 R2 Enterprise SP2 x86
  • VHD ファイル
  • Windows Update や各種パッチを最新版まで適用 (修正が出ているのに適用していないとか論外です)

移行手順

とりあえず、移行元ということで素の Windows Server 2003 R2 SP2 をインストールしてみます。この画面を見るのも何年ぶりか…（リリースされた当時、私は中学生ですね。

Windows Update を最新まで適用します。(これまた懐かしい…。)

必ず RDP を有効化して、Firewall にも穴をあけておきます。(忘れると接続できません)

ユーザー名とパスワードを強固なものにしておきましょう。Administrator 残ってるとか論外です。パスワードに関しては、Azure の推奨は 12 文字以上。推測しやすいユーザー、パスワードを使っていて乗っ取られても知りませんよ。

Hyper-V 統合サービスも忘れずにインストールしておきましょう。(ドライバーとか、ホストとゲストの連携用のモジュールとかです)

Azure 上での利用がサポートされない役割・機能を使っていないかを確認しましょう。(日本語版は古い可能性があるので、なるべく英語版を見ましょう。)

その他、Windows Server 2003 に限った話ではないですが、Azure に移行する際の注意事項、制限事項は以下のドキュメントに詳しく記載があります。各モジュールの推奨バージョン / 推奨 KB まで明記されているので、非常に親切ですね。必ず 3 回は熟読し、漏れがないことを確認しましょう。(PowerShell でコマンドが書かれている時点で、Windows Server 2003 はアウトオブ眼中なのが分かりますね？)

OS 内の設定が終わったら、Hyper-V 上の VM を一度シャットダウンしてから、ディスクを容量固定の VHD (VHDX は不可) に変換します。ファイル サイズが 1 MB (1,048,576 Byte) の倍数でないと Azure 上でエラーになったりするので、VMware 等の non Hyper-V 環境からディスクを変換してきた場合は気を付けましょう。

Azure Storage を作成して、アカウント名とアクセス キーをメモっておきましょう。

AzCopy 等を使って、Page BLOB として VHD をアップロードします。(BlobType の指定を忘れるとアップロードしなおしなので要注意。) 最新の AzCopy は .NET Core 2.1 でビルドされているらしいので、適当にランタイムも入れてあげましょう。(.NET Core 2.1 の Supported OS が Windows Server 2008 R2 以降なので、2008 以前だとダメな気がします。あと 0x80070057 とかエラーが出た場合は、KB2533623 を適用してあげればよいかと。)

(コマンド例)
AzCopy.exe /Source:”VHD があるフォルダ (ファイル名含まず)” /Dest:”Azure Storage のコンテナーの URL” /DestKey:”Azure Storage のアクセス キー” /Pattern:”VHD のファイル名” /BlobType:Page

アップロードが完了したら、[すべてのサービス] – [ディスク] – [追加] から Managed Disks を作ります。ソースを “ストレージ BLOB” として、先ほどアップロードした Azure Storage 内の VHD を選択し、OS ディスクなら “Windows” を、データ ディスクなら “なし” を選択し、サイズを忘れずに実サイズにしておきましょう。(大きいサイズにすると VHD が拡張されてしまって、あとで縮小できなくなります。)

Managed Disks が出来上がったら、[VM の作成] から Azure VM を作成しましょう。

受信ポートは忘れずに “なし” にしておきましょう。

パブリック IP も付与しないように。NSG は “Basic” で、受信ポートは先ほどと同じく “なし” にしておきましょう。(もし血迷ったとしても、Windows Server 2003 を Internet に公開しようと思わないこと。あえてセキュリティ インシデントを起こしたいなら別ですが。)

その他は適宜ウィザードに沿って選択して、Azure VM をデプロイしましょう。

で、出来上がったものがこちら。Public IP を付与していないので、Private IP 経由でないとアクセスできません。VPN や ExpressRoute の接続はドキュメントを見ながら別途構築しましょう。

ちゃんと RDP できますね。(2003 だからネットワーク レベル認証じゃないけど…

ハードウェアが変わったので、ライセンス認証をしろと言われますね。まだ NSG で出力方向の通信を制限していないので、ネットワーク経由で認証だけ済ませてしまいましょう。(ライセンス周りは詳しくないので、ちゃんと自己責任で調べてほしいんですが、ちゃんとクラウドに持ち込んでいいランセンス形態でやってくださいね。ライセンス モビリティの権利がないものでやるとアウトだと思います。詳細はライセンス購入元の販社に問い合わせましょう。)

ということで、Azure VM として Windows Server 2003 を構築することができました。(まだ終わりじゃないよ)

移行後に忘れずにやるべきこと

まず、最低限やるべきは以下ですかね。

  • パフォーマンス テスト (移行前後の環境で CPU やディスクの負荷テストを必ず実施して、きちんと性能劣化が生じない VM サイズ・ディスクにサイジングしましょう。)
  • アプリケーションの動作確認 (言わずもがなですが、CPU の命令セットの差異とか、MAC アドレスでライセンス認証しているようなアプリで認証が飛ぶとか、ブロードキャスト パケット等に対応していない Azure VNET の仕様とバッティングしないかとか…。VM が動くのとアプリが正常稼働できるかは全く別物ですし、Microsoft はあくまでも仮想化基盤の提供だけなので、ウワモノは構築するユーザーの責任です。)
  • 可用性の確保 (Azure VM はメンテナンスや HW 障害によってダウンすることがあります。V2C しただけでは事故りますので、必ず 2 台以上で冗長化する構成にするか、1 台だとメンテや障害の影響でダウンしうることをユーザーに事前に説明しましょう。クラウドにはクラウドのお作法がありますし、それを説明するのも V2C する人の責任です。SLA の要件を満たさずにサポートにクレーム入れても当然ですが返金されませんよ。)

加えて、ネットワークの通信制御もちゃんと対応しておきましょう。[ネットワーク] の設定画面から、以下のような形で必要最低限の IP / Port との通信だけを許可します。

  • 受信 方向の通信は、RDP やサービス用の必要最低限のポートだけ許可
  • 基盤側との連携用に Azure LoadBalancer からの受信を許可 (168.63.129.16 の全ポート開けておきましょう。)
  • 送信方向の通信も、仮に乗っ取られた場合に被害が拡大しないように必要なポート以外は拒否 (NSG は IP 制限しかできないので、URL フィルターが必要な場合は自前の Proxy でやるか、Azure Firewall を別途デプロイしましょう。)
  • その他すべての通信を拒否 (既定の 65000 番台のルールは打ち消しておきましょう。)

その他、運用上の制限事項・注意事項

  • VM Agent がインストールできません (Azure VM は VM Agent をインストールすることで基盤側との連携を実現していますが、x64 しか用意されておらず、仮に 64 bit OS だったとしても Windows Server 2003 では動かないはずです。)
  • 拡張機能が使えません (Azure Backup をはじめとする拡張機能も VM Agent が必要なため動きません。)
  • 動作やパフォーマンスに問題が出たとしても、サポートされません。(延長サポート フェーズすら終了した OS なので当たり前ですね。)
  • 繰り返しですが、Windows Server 2003 は極めて脆弱です。セキュリティには最大限の注意を払いましょう。IaaS として Azure VM を使う場合、OS やアプリケーションの運用・管理はユーザー責任です。(Internet からアクセスできる状況下で Administrator とか、SQL Server の sa みたいな脆弱なユーザー名、パスワードを使っていれば数日で乗っ取られますし、オンプレミスと VPN 等で接続していれば、逆流されて社内まで浸食される恐れもあります。)

公式の KB もあったので、追記しておきます。(こちらも英語版を推奨)

ということで、「Azure 上でも Windows Server 2003 は動く」ものの、「動かしていいわけではない」ですし、「推奨されているわけではない」ということを肝に銘じておきましょう。「Windows Server 2003 を Azure へ移行して、このまま塩漬けしよう」なんてユーザーさんから言われた際に、「そろそろ塩漬けはやめませんか？」と勇気を持って一声かけて欲しいなーと思ったりするサポートの中の人でした。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。