これならサポート終了に間に合う？ 「ストレージ移行サービス」によるWindowsファイルサーバの移行、やってみました：山市良のうぃんどうず日記（266）

Windows Server 2012／2012 R2の製品サポートが2023年10月10日に終了します。もし、これらのOSを実行しているファイルサーバやWindows Storage Server 2012／2012 R2搭載NASをまだ利用している場合は、急いで後継バージョンや代替ソリューションに移行しましょう。その際、Windows Server 2019で追加された「ストレージ移行サービス」が省力化や時短に大いに役に立つかもしれません。

[山市良，テクニカルライター]

山市良のうぃんどうず日記

Windows Server 2019で追加された「ストレージ移行サービス」とは

　「ストレージ移行サービス」（記憶域の移行サービス、Storage Migration Service）は、「Windows Server 2019」で追加された「サーバーの機能」の一つです。このサービスを利用すると、「Windows Server 2003」以降のWindows Serverやクラスタ、LinuxのSambaサーバ、「NetApp ONTAP 9」サーバを、「Windows Server 2012 R2」以降のWindows Serverやクラスタ、Azure VM（Azure仮想マシン）に移行することができます。

　ストレージ移行サービスは、SMB（Server Message Block）共有の設定、共有アクセス許可、NTFS（NT File System）アクセス許可およびその他の属性、ローカルユーザーとグループ（パスワードを除く）を含めて移行先デバイスに同期でき、「一括移行」（カットオーバー）というステップで移行先デバイスのコンピュータ名とネットワーク設定を、移行元デバイスのものに切り替えます。

　そのため、クライアントがSMB共有へのアクセスに使用していたネットワークパス（UNC《Uniform Naming Convention》パス）やネットワークドライブの割り当てを新しいデバイスでそのまま使用でき、以前と同じアクセス許可でSMB共有上のファイルやフォルダにアクセスすることができます。

　最近、Active Directoryドメイン環境でのNAS（ネットワーク接続型ストレージ）をストレージ移行サービスで移行し、それをドキュメント化するという仕事がありました。その際は、公式ドキュメントやGUIの日本語訳に戸惑うこともありましたが、以下の公式ドキュメントに従って操作することで、比較的スムーズに移行できました。

• 記憶域移行サービスを使用してサーバーを移行する（Microsoft Learn）

ストレージ移行サービスを使用したサーバ移行の大まかな作業ステップ

　ストレージ移行サービスの各種機能は、「StorageMigrationService」モジュールのコマンドレットとして提供されています。しかし、PowerShellのコマンドラインを駆使して実行する手順は公開されていません。その代わりに「Windows Admin Center」を使用する手順が公開されています。

　Windows Admin Centerを使用すると、ウィザードベースのGUIで移行ジョブを作成し、以下の3つのフェーズを順番に実行して、サーバを移行できます。ストレージ移行サービスを使用するには、Windows Admin Centerの管理環境と、移行元および移行先デバイスとは別のWindows Server 2019以降のサーバが必要です（画面1）。このサーバは、「オーケストレーターサーバ」として移行ジョブを制御し、移行元および移行先デバイス間のデータ転送や再起動を伴う設定変更を制御します。

ストレージ移行サービスによる移行フェーズ

• フェーズ1　インベントリサーバ：移行ジョブの（1）インベントリサーバ
• フェーズ2　転送：移行ジョブの（2）転送データ
• フェーズ3　一括移行（カットオーバー）：移行ジョブの（3）新しいサーバへ一括移行

画面1　Windows Admin Centerでオーケストレーターサーバにするサーバに接続し、「記憶域の移行サービス」ツールを開いて、ワンクリックでサービスをインストールした直後。「転送データ」（正しくは「データ転送」）など、日本語に戸惑うところも

　Active Directoryドメイン環境ではスムーズに移行が進みましたが、ワークグループ環境ではどうなるのか、幾つか気になる点があったので、実際にやってみました。以下の図1に、移行のために用意した環境を示します。

図1　ワークグループ環境での実施環境。オーケストレーターサーバとWindows Admin Centerの兼用は可

　移行元デバイスは、Windows Server 2012を実行するファイルサーバで、現在のSMB共有のパスは「\\FILESV\Documents」です（画面2）。

画面2　Windows Server 2012を実行する移行元デバイスのコンピュータ名、IPアドレス、ローカルユーザーとグループ、既存のファイルのNTFSアクセス許可

　移行先デバイスは「Windows Server 2022」の評価版を新規インストールして、最新状態に更新後、コンピュータ名を「NEWSV」に設定しただけのものです。ファイルサーバの役割サービスはインストールされていません（画面3）。どちらもワークグループ名「WORKGROUP」の構成です。これらのデバイスで事前に準備することは、ファイアウォールの受信の規則で幾つかの許可ルールを有効にすることだけです（有効化が必要なルールは公式ドキュメントで確認してください）。

画面3　移行先デバイス。Windows Server 2022評価版を新規インストールし、更新後、コンピュータ名を設定しただけの状態

ファイルサーバを移行するためのジョブ作成と実行

フェーズ1／2（インベントリサーバ／転送）

　Windows Admin Centerの「サーバーマネージャー」でオーケストレーターサーバに接続し、「記憶域の移行サービス」ツールを開いて、新しい移行ジョブを作成し、ウィザードの指示に従って「インベントリフェーズ」「転送フェーズ」と進みます。インベントリフェーズでは移行元デバイスを指定してスキャンし、SMB共有、構成（コンピュータ名やドメイン／ワークグループ名など）、ネットワーク設定、ボリューム情報を取得します。転送フェーズでは、移行元デバイスと移行先デバイスのドライブのマッピングと転送するSMB共有を選択し、転送を開始します。

　移行先デバイスがWindows Server 2019以降の場合、「必要な機能のインストール」で移行先デバイスに対して「ストレージ移行サービスプロキシ」（SMS-Proxy）の機能がインストールされます。その後、「デバイスの検証」を実行すると、「警告：移行先プロキシが見つかりませんでした」と検証エラーが表示されました。公式ドキュメントには、この検証エラーの回避方法として「Register-SMSProxy」の手動実行が示されています。ドメイン環境ではその手順で検証エラーを取り除いて「合格」させることができましたが、ワークグループ環境ではエラーを回避することができませんでした（画面4）。

画面4　ストレージ移行サービスプロキシ（SMS-Proxy）の検証エラーは、ワークグループ環境では回避できなかったので、無視することに

　移行先がWindows Server 2019以降であればストレージ移行サービスプロキシにより転送が高速化されるという利点がありますが、この機能が利用できない「Windows Server 2016」以前ではオーケストレーターがその役割を担います（ただし、低速転送になります）。そのため、この検証エラーは無視できると考えました。

　検証エラーを無視して転送を開始したところ、1つのファイルがエラーでスキップされました。エラーログを確認すると、それはローカルユーザーによって「暗号化ファイルシステム」（EFS）で暗号化されたファイルでした（画面5）。

画面5　ローカルユーザーによってEFSで暗号化されたファイルは転送時エラーになった

　その後、暗号化を解除し、転送を再実行することで転送フェーズは成功しました。ちなみに、以前行ったドメイン環境における移行ジョブでは、ドメインユーザーによって暗号化されたファイルはスキップされることなく転送できました。なお、実際の運用環境の場合、この転送フェーズが最も時間のかかるフェーズになります。

フェーズ3（一括移行）

　転送フェーズが成功修了すると、次は「一括移行フェーズ」です。このフェーズでは、ネットワーク設定の転送先にアダプターをマッピングし、切り替え後に移行元デバイスに設定するIPアドレス（DHCPを推奨）およびコンピュータ名などを指定し（画面6）、検証後、一括移行を開始します（画面7）。移行元デバイスの一括移行後のIPアドレスを静的に指定する場合、既にネットワーク上で使用済みのIPアドレス（例えば、移行先デバイスとIPアドレス）を指定すると、一括移行フェーズが途中（38％）でハングしてしまうので注意が必要です。

画面6　ネットワーク設定の移行先のアダプターを選択し、移行後の移行元デバイスのIPアドレスとコンピュータ名を構成する

画面7　一括移行を開始。コンピュータ名やドメイン参加設定、IPアドレスの入れ替え、移行先デバイスへの各種設定の移行のため、移行元および移行先デバイスが何度か再起動される

ファイルサーバ移行後の状態と追加作業

　一括移行が完了すると、クライアントからの以前の移行元デバイスのコンピュータ名やIPアドレスによるアクセスは、移行先デバイスへと切り替わります。クライアント側の設定変更は必要ありません。共有のアクセス許可やNTFSの「アクセス制御リスト」（ACL）も引き継がれています（画面8）。

画面8　移行元デバイスのネットワークパスは、一括移行後は移行先デバイスへのアクセスとなり、共有やNTFSアクセス許可、NTFS属性が引き継がれている（ローカルユーザーによるEFSの暗号化は解除する必要があった）

　移行元デバイスについても、移行元デバイス上のデータはそのまま残り、新しいコンピュータ名またはIPアドレスで当面、SMB共有にアクセスすることができます。つまり、移行に問題がないと判断できたなら、いつでも撤去できるということです。

　ローカルユーザーとグループは移行先デバイスに移行されますが、ユーザーアカウントは無効化され、127文字のランダムなパスワードが設定された状態になります（AdministratorやAdministratorsなど組み込みのアカウントは変更されません。パスワードが移行されることもなく、新しいサーバで設定したAdministratorのパスワードのままです）。

　これは、移行元でユーザーのパスワードを忘れてしまっていた場合や、簡単な（脆弱《ぜいじゃく》な）パスワードが使用されていた場合でも、移行先でセキュリティ関連の問題が引き継がれる事態を回避するための仕様です。ローカルユーザーのアカウントを引き続き使用するには、アカウントを有効にして新しいパスワードを割り当てる必要があります（画面9）。ドメイン環境ではローカルユーザーのアカウントを共有に利用することはないと思いますが、ワークグループ環境では必須の追加作業になります。

画面9　ストレージ移行サービスによる移行ではローカルユーザーのパスワードは同期されない。ランダムなものに設定され、アカウントは既定で無効になる

移行は“やってみないと分からない”ことばかり

　ドメイン環境ではスムーズに実施できたストレージ移行サービスによるファイルサーバ移行、ワークグループ環境ではドキュメントには書かれていない、さまざまなケースに遭遇しました。

　ストレージ移行サービスを使用すると、OSとストレージ移行サービスプロキシを自動プロビジョニングしてAzure VMに移行することが可能です。公式ドキュメントには移行先のAzure VMのOSとしてWindows Server 2012 R2、Windows Server 2016、Windows Server 2019、Windows Server 2022（推奨）から選択できると書いています。しかし、実際に途中までウィザードを進めてみたところ、Windows Server 2016とWindows Server 2019のイメージしか選択肢にありませんでした（画面10）。

画面10　Azure VMへ移行する場合のOSの選択肢は、現在、Windows Server2016とWindows Server 2019のみ

　機能や仕様変更が新バージョンやService Pack（SP）で提供されていた以前の製品とは異なり、最近のOS、アプリケーション、ツールは、機能が固定されておらず、更新プログラムや拡張機能の更新によって機能や仕様が変化します。そして、往々にして、公式ドキュメントが最新の状況に追い付いていません。

　最後に、ストレージ移行サービスを事前に評価するために、Windows Serverの評価版を利用する場合は、必ずWindows Server 2022評価版を使用してください。少なくとも、オーケストレーターサーバとしてWindows Server 2019評価版は使用できません。

　これは、Windows Server 2019評価版とEssentialsエディションのインストールメディアの既知の問題であり、これらのOSで利用可能な「サーバーの役割」と「サーバーの機能」に、ストレージ移行サービスとストレージ移行サービスプロキシが存在しないからです。この問題については、既に既知の問題として公式ドキュメントに書かれていますが、実際にやってみてから問題に遭遇し、悩んだ揚げ句にようやく既知の問題にたどり着くということもあります。

　時間を無駄にしないために、何か新しい技術を使用するという場合は、公式ドキュメントをまず確認し、システム要件や既知の問題を調べておきましょう。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2008 to 2024（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。