記憶域移行サービスを使用してサーバーを移行する
このトピックでは、記憶域移行サービスと Windows Admin Center を使用して、Windows Server、Windows フェールオーバー クラスター、Samba サーバー、または NetApp FAS アレイを、それらのファイルや構成も含めて、別の Windows サーバーまたは Windows フェールオーバー クラスターに移行する方法について説明します。 このサービスをインストールし、必要なファイアウォール ポートを開いてから、移行には 3 つの手順が必要になります。その 3 つとは、サーバー インベントリの作成、データの転送、新しいサーバーへのカットオーバーです。
手順 0: 記憶域移行サービスをインストールし、ファイアウォール ポートを確認する
まずは、Storage Migration Service をインストールし、必要なファイアウォール ポートが開いていることを確認してください。
記憶域移行サービスの要件を確認し、最新バージョンの Windows Admin Center を PC または管理サーバーにインストールします (まだインストールしていない場合)。 また、最新バージョンの記憶域移行サービス拡張機能も必要です。これは、[設定]>[拡張機能] で [拡張機能を自動的に更新します] が有効になっている場合は、Windows Admin Center によって自動的にインストールされます。 ドメイン参加済みのソース コンピューターを移行する場合には、Storage Migration Service はソース コンピューターと同じドメインまたはフォレストに参加済みのサーバーにインストールしたうえで実行する必要があります。
Windows Admin Center で、Windows Server 2019 または Windows Server 2022 を実行しているオーケストレーター サーバーに接続します。
これは、記憶域移行サービスのインストール先となるサーバーで、移行の管理に使用します。 1 つのサーバーのみを移行する場合は、宛先サーバーが Windows Server 2019 または Windows Server 2022 を実行しているのであれば、その宛先サーバーを使用できます。 複数のサーバーを移行する場合は、別個のオーケストレーション サーバーを使用することをお勧めします。[サーバー マネージャー] (Windows Admin Center 内) >[記憶域移行サービス] の順に移動し、[インストール] を選択して、記憶域移行サービスとその必須コンポーネントをインストールします (図 1を参照)。
図 1: 記憶域移行サービスのインストール
Windows Server 2019 または Windows Server 2022 を実行しているすべての宛先サーバーに、記憶域移行サービス プロキシをインストールします。 これが宛先サーバーにインストールされていると、転送速度が倍増します。
これを行うには、Windows Admin Center で宛先サーバーに接続し、[サーバー マネージャー] (Windows Admin Center 内) >[役割と機能]>[機能] の順に移動し、[記憶域移行サービス プロキシ] を選択してから、[インストール] を選択します。移行先または移行元が Windows フェールオーバー クラスターである場合は、オーケストレーター サーバーにフェールオーバー クラスタリング ツールをインストールします。 最新バージョンの Windows Admin Center では、インベントリの [ジョブ設定] で [フェールオーバー クラスターから移行する] を選択すると、この処理が自動的に行われます。
記憶域移行サービスのインベントリ フェーズ外にインストールするには、Windows Admin Center でオーケストレーター サーバーに接続してから、[サーバー マネージャー] (Windows Admin Center 内) >[役割と機能]>[機能]>[リモート サーバー管理ツール]>[機能管理ツール] の順に移動し、[フェールオーバー クラスタリング ツール] を選択して、[インストール] を選択します。注意
NetApp FAS アレイから移行する場合は、最新バージョンの NetApp PowerShell Toolkit を手動でオーケストレーターにインストールする必要があります。 このツールキットは、mysupport.netapp.com とアクティブな NetApp サポート契約を締結している、NetApp のすべてのライセンス ユーザーが利用できます。
Windows Server 2016 または Windows Server 2012 R2 を実行しているすべてのソース サーバーおよび宛先サーバーで、Windows Admin Center で各サーバーに接続し、[サーバー マネージャー] (Windows Admin Center 内) >[ファイアウォール]>[受信規則] の順に移動して、次の規則が有効になっていることを確認します。
- ファイルとプリンターの共有 (SMB 受信)
- Netlogon サービス (NP 受信)
- DCOM-In (Windows Management Instrumentation)
- WMI-In (Windows Management Instrumentation)
サード パーティのファイアウォールを使用している場合、開く必要のある受信ポート範囲は、TCP/445 (SMB)、TCP/135 (RPC/DCOM エンドポイント マッパー)、および TCP 1025-65535 (RPC/DCOM エフェメラル ポート) です。 Storage Migration Service のポートは TCP 28940 (オーケストレーター) と TCP 28941 (プロキシ) です。
移行管理にオーケストレーター サーバーを使用しており、イベントや転送するデータのログをダウンロードしたい場合には、そのサーバーでも [ファイルとプリンターの共有 (SMB 受信)] ファイアウォール規則が有効になっていることを確認します。
手順 1: ジョブを作成してサーバーのインベントリを作成し、移行対象を明確にする
この手順では、移行するサーバーを指定し、それらのサーバーをスキャンして、ファイルと構成に関する情報を収集します。
[新しいジョブ] を選択し、ジョブに名前を付けて、Windows サーバーとクラスター、Samba を使用する Linux サーバー、NetApp FAS アレイのいずれを移行するかを選択します。 [OK] をクリックします。
[前提条件の確認] ページで前提条件を確認します。 [次へ] を選択します。
NetApp FAS アレイから移行する場合は、[NetApp FAS アレイの選択] ページで、使用する NetApp FAS アレイの IP アドレス、管理者の資格情報、パスワードを入力します。 [次へ] を選択します。
Windows サーバーまたはクラスターから移行する場合は、[資格情報の入力] ページで、移行元のサーバーで使用している管理者の資格情報を入力して、[次へ] を選択します。
Linux サーバーから移行する場合は、代わりに [Samba の資格情報] ページと [Linux の資格情報] ページにある資格情報 (SSH パスワードや秘密キーなど) を入力します。
NetApp FAS アレイから移行する場合は、[Enter credentials and prescan NetApp](資格情報の入力と NetApp のプレスキャン) ページを使用して、移行元の NetApp CIFS サーバーで使用している管理者の資格情報を入力して、[スキャンの開始] をクリックします。このようにすると、NetApp FAS アレイ上で実行されているすべての NetApp CIFS サーバーが一覧表示されます。 移行しない CIFS サーバーは、チェックをオフにできます。 [次へ] を選択します。[必須ツールのインストール] ページで、必要なツールがエラーなしでインストールされていることを確認します。 [次へ] を選択します。
Windows サーバーまたはクラスター、あるいは Linux Samba から移行する場合は、[デバイスの追加とスキャン] ページで [デバイスの追加] を選択し、Active Directory でソース サーバー クラスターを検索します。 アスタリスクを使用して、ワイルドカード部分検索を実行できます。 また、完全なソース サーバー名やクラスター化されたファイル サーバーの名前を入力することもできます。 [OK] を選択します。
ほかにインベントリが必要なサーバーがあれば、そのすべてについてこれを繰り返します。 NetApp FAS アレイから移行している場合は、[サーバーの選択とスキャン] ページに既にソース サーバーが一覧表示されています。[検証] を選択して、すべてのサーバーについて検証が成功していることを確認します。
注意
NetApp CIFS サーバーでは、バックアップ権限のエラーは予期されるものです。 このエラーは無視してかまいません。
[スキャンの開始] を選択します。
スキャンが完了すると、ページが更新されます。図 2: サーバーのインベントリ作成
各サーバーを選択して、インベントリにより検出された共有、構成、ネットワーク アダプター、ボリュームを確認します。
記憶域移行サービスでは、Windows の操作に干渉する可能性があることがわかっているファイルやフォルダーは転送されません。そのため、Windows システム フォルダーにあるすべての共有について警告が表示されます。 転送フェーズでは、このような共有をスキップする必要があります。 詳細については、「転送から除外されるファイルとフォルダー」を参照してください。[次へ] を選択してデータの転送に進みます。
手順 2: 古いサーバーから宛先サーバーにデータを転送する
この手順では、宛先サーバー上でデータの配置先を指定してから、データを移行します。
[データの転送]>[資格情報の入力] ページで、移行先の宛先サーバーで使用している管理者の資格情報を入力して、[次へ] を選択します。
[Add a destination device and mappings](宛先デバイスとマッピングの追加) ページに、最初のソース サーバーが表示されます。 移行先のサーバーまたはクラスター化されたファイル サーバーの名前を入力してから、[デバイスのスキャン] を選択します。 ドメインに参加しているソース コンピューターから移行する場合は、宛先サーバーを同じドメインに参加させる必要があります。 また、[新しい Azure VM の作成] をクリックしてからウィザードを使用して、新しい宛先サーバーを Azure にデプロイすることもできます。 この方法では、VM のサイズ指定、記憶域のプロビジョニング、ディスクのフォーマット、ドメインへの参加、移行先の Windows Server 2019 または Windows Server 2022 への記憶域移行サービス プロキシの追加が自動的に行われます。 任意のサイズの Windows Server 2022 (推奨)、Windows Server 2019、Windows Server 2016、および Windows Server 2012 R2 VM から選択でき、マネージド ディスクを使用できます。
注意
[新しい Azure VM の作成] を使用するには、次のものが必要です。
- 有効な Azure サブスクリプション。
- 作成権限を持っている既存の Azure Compute リソース グループ。
- 既存の Azure Virtual Network とサブネット。
- その Virtual Network とサブネットに関連付けられており、この Azure IaaS VM から、オンプレミスのクライアント、ドメイン コントローラー、記憶域移行サービス オーケストレーター コンピューター、Windows Admin Center コンピューター、および移行対象のソース コンピューターへの接続を可能にする Azure ExpressRoute 回線または Azure VPN ソリューション。
次に示すのは、記憶域移行サービスを使用して Azure VM に移行する方法を説明しているビデオです。
ソース ボリュームを移行先ボリュームにマップし、転送しないすべての共有 (Windows システム フォルダーにあるすべての管理用共有を含む) の [Include](含める) チェックボックスをオフにし、Azure File Sync でクラウドを使った階層化をしているボリュームまたは共有に対して [Azure File Sync] チェックボックスが設定されていることを確認して、[次へ] を選択します。
注意
NetApp CIFS サーバーを移行する場合、ソース ボリュームにドライブ文字は表示されません。 これらのボリュームを任意の移行先ボリュームにマップできます。また、複数の NetApp CIFS ボリュームを同じ移行先ボリュームにマップすることもできます。 フォルダーの上書きや競合を避けるため、新しいルート フォルダー パスが作成されます。その後、正しいレベルで共有が作成されます。 [共有] の詳細ペインに、作成しようとしているフォルダー構造が表示されます。
図 3: ソース サーバーとその記憶域の転送先
ソース サーバーがほかにもあれば、それについても宛先サーバーとマッピングを追加し、[次へ] を選択します。
[Adjust transfer settings](転送設定の調整) ページで、ソース サーバー上のローカルのユーザーとグループを移行するかどうかを指定して、[次へ] を選択します。 これは宛先サーバーにローカルのユーザーとグループを作り直すためのもので、これを使用すると、ファイルまたは共有についてローカルのユーザーとグループに設定されているアクセス許可が失われずに済みます。 ローカルのユーザーとグループを移行する場合のオプションは次のとおりです。
- [Rename accounts with the same name](同じ名前のアカウント名を変更する) は、既定で選択されており、ソース サーバー上のすべてのローカルのユーザーとグループを移行します。 ソースと移行先に同じ名前のローカルのユーザーまたはグループが見つかると、移行先のユーザーまたはグループの名前が変更されます (管理者ユーザーや管理者グループなど、それらが組み込みのユーザーまたはグループである場合を除く)。 ソース サーバーか宛先サーバーがドメイン コントローラーである場合は、この設定を使用しないでください。
- [Reuse accounts with the same name](同じ名前のアカウントを再利用する) は、ソースと移行先に同じ名前のユーザーとグループをマップします。 ソース サーバーか宛先サーバーがドメイン コントローラーである場合は、この設定を使用しないでください。
- [Don't transfer users and groups](ユーザーとグループを転送しない) は、ローカルのユーザーとグループの移行をスキップします。これは、ソースか移行先がドメイン コントローラーである場合、または DFS レプリケーションのデータをシードする場合 (DFS レプリケーションではローカルのグループやユーザーをサポートしていません) に必要です。
注意
移行されたユーザー アカウントは移行先で無効にされ、複雑でランダムな 127 文字のパスワードが割り当てられます。このため、それらのアカウントを引き続き使用するには、移行が完了してから、それらを有効にして新しいパスワードを割り当てる必要があります。 こうすることによって、ソースで旧アカウントのパスワードを忘れてしまっていた場合や、旧アカウントに脆弱なパスワードを使用していた場合に、宛先でもセキュリティ関連の問題が続く事態を回避できます。 ローカル管理者パスワードを管理する 1 つの方法として、ローカル管理者パスワード ソリューション (LAPS) を確認することもできます。
注意
NetApp CIFS サーバーを移行する場合、ローカルのユーザーとグループを移行することはできません。
[検証] を選択し、[次へ] を選択します。
[転送の開始] を選択してデータの転送を開始します。
お客様が初めて転送する場合、Microsoft は移行先にあるすべての既存のファイルをバックアップ フォルダーに移動します。 クラウドを使った階層化をしている Azure File Sync を実行する宛先サーバーの場合、このバックアップ オプションはサポートされていません。 それ以外の点では、クラウドを使った階層化をしている Azure File Sync は完全にサポートされており、更新された転送情報の詳細が Windows Admin Center に表示されます。 以降の転送では、既定では、最初に移行先のバックアップをすることはせず、移行先の更新が行われます。
また、記憶域移行サービスは重複する共有を処理できるため、同じジョブで同じフォルダーを 2 度コピーすることはされません。転送が完了したら、宛先サーバーを確認して、すべてが正しく転送されていることを確認します。 転送されなかったファイルのログをダウンロードしたい場合は、[エラー ログのみ] を選択します。
注意
転送の監査証跡を保持する必要がある場合や、ジョブで複数の転送を実行する予定の場合は、[ログの転送] または他のログ保存オプションをクリックして、CSV コピーを保存します。 転送を実行するごとに、データベース内の前回の実行に関する情報が上書きされます。 多数のファイルを移行する場合は、この CSV ファイルを保存するためのタイムアウトを調整することが必要になる場合があります。 詳細については、「転送エラー CSV のダウンロード時の記憶域移行サービスのタイムアウト」を参照してください。
この時点で、次の 3 つの選択肢があります。
- 次のカットオーバー手順に進み、宛先サーバーでソース サーバーの ID を引き継ぐ。
- ソース サーバーの ID を引き継がずに、移行を完了とする。
- もう一度転送を実行し、前回の転送よりも後に更新されたファイルのみをコピーする。
Azure とファイルを同期することが目的である場合は、ファイルを転送した後か、宛先サーバーにカットオーバーした後に、Azure File Sync を使用して宛先サーバーを設定できます (「Azure File Sync のデプロイの計画」を参照してください)。
手順 3: 新しいサーバーにカットオーバーする
この手順では、ソース サーバーから宛先サーバーへのカットオーバーを実施し、IP アドレスとコンピューター名を宛先サーバーに移行します。 この手順を終えると、アプリとユーザーが移行元のサーバーの名前とアドレスを使って新しいサーバーにアクセスできるようになります。
- 移行ジョブから移動していた場合は、Windows Admin Center で [サーバー マネージャー]>[記憶域移行サービス] の順に移動して、完了するジョブを選択します。
- [Cut over to the new servers](新しいサーバーにカットオーバーする)>[資格情報の入力] ページで、[次へ] を選択して、前に入力した資格情報を使用します。
- [Configure cutover](カットオーバーの構成) ページで、宛先のどのネットワーク アダプターでソースの各アダプターから設定を引き継ぐかを指定します。 このようにすると、カットオーバーの一部としてソースの IP アドレスが宛先に移動され、ソース サーバーには新しい DHCP または静的 IP アドレスが指定されます。 全部のネットワークの移行または一部のインターフェイスをスキップするオプションがあります。
- カットオーバーにより IP アドレスが宛先に移行した後にソース サーバーに使用する IP アドレスを指定します。 Windows サーバーまたはクラスターを移行する場合や、Linux Samba に移行する場合は、DHCP を使用するか、新しい静的 IP アドレスを指定することができます。 静的アドレスを使用する場合、新しいサブネットを古いサブネットと同じにする必要があります。そうしないと、カットオーバーが失敗します。 NetApp FAS アレイを移行する場合は、DHCP の代わりに NetApp サブネットを使用します。
図 4: ソース サーバー、および宛先へのそのネットワーク構成の移動の様子
- 宛先サーバーがソース サーバーの名前を引き継いだ後に、ソース サーバーの名前をどのように変更するかを指定します。 ランダムに生成される名前を使用することも、自分で名前を入力することもできます。 [次へ] を選択します。
- ソース移行資格情報にソース コンピューターまたはクラスター化されたファイル サーバーをドメインから削除するアクセス許可がない場合は、[設定の調整] ページで、新しい AD ユーザー資格情報にそのアクセス許可を与えてから、新しい名前を使用してそれらを追加し直すことが必要な場合があります。
- [Validate source and destination device](ソースと宛先のデバイスの検証) ページで [検証] を選択して、[次へ] を選択します。
- カットオーバーの準備ができたら、[一括で開始] を選択します。
アドレスと名前が移動され、サーバーがその度に数回再起動している間、ユーザーとアプリが中断を経験する可能性がありますが、移行によるそれ以外の影響はありません。 カットオーバーにかかる時間は、サーバーの再起動の速さ、および Active Directory と DNS のレプリケーション時間によって異なります。
移行後の操作
サーバーまたはクラスターを移行した後、考えられる移行後の操作についてその環境を評価します。
- 使用を停止したソース サーバーのための計画を作成する。 記憶域移行サービスでは、宛先サーバーがソース サーバーの ID をして、ソースの名前と IP を変更し、ユーザーやアプリケーションがソース サーバーにアクセスできないようにするカットオーバー プロセスを使用します。 しかし、ソース サーバーがオフにされるわけではなく、上記以外のソース サーバーの内容は変更されません。 ソース サーバーを使用停止するための計画を作成する必要があります。 使用データが不足している場合に備え、オフライン バックアップを復元しなくてもファイルを簡単に取得できるようにするため、少なくとも 2 週間はソースをオンラインのままにしておくことをお勧めします。 その後、さらに 4 週間は、サーバーをオフにして、サーバーをデータの取得に引き続き利用できるものの、運用リソースや電源リソースは消費しないようにしておくことをお勧めします。 その後、サーバーの最終的な完全バックアップを実行してから、物理サーバーの場合は転用について、仮想マシンの場合は削除について評価します。
- 新しい宛先サーバーで証明書を再発行する。 宛先サーバーがオンラインではあったもののカットオバーされていない間に、自動登録などのプロセスによって証明書が発行されている可能性があります。 Windows Server の名前を変更しても、既存の証明書は自動的に変更または再発行されません。そのため、既存の証明書には、カットオーバー前のそのサーバーの名前が含まれている場合があります。 そのサーバー上の既存の証明書を調べて、必要に応じて新しい証明書を再発行する必要があります。