Contents
ファイルサーバの移行を考える
WORKGROUP 環境でのファイルサーバの移行はどのように行うか。おおよそのインフラエンジニアは以下の4つのうちのどれかで移行しているのではないでしょうか。
- 通常のコピー
- robocopy
- FSMT(File Server Migration Toolkit)
- Windows Server 移行ツール
移行対象
4つの移行方式で、ファイルサーバの移行で最も気を使う以下の5つの項目を移行することができるのかを検証していきます。検証に使用する Windows のバージョンは移行元と移行先共に 2016 です。
- 共有設定
- 共有フォルダアクセス許可
- NTFSアクセス許可
- クォータ
- ファイルスクリーン
最も確実な移行方法とは
先に検証結果を出しておきます。それぞれの移行方式について、何が移行可能で、何が移行不可能なのかを表にしたものが以下です。
共有設定 | 共有フォルダアクセス許可 | NTFSアクセス許可 | クォータ | ファイルスクリーン | |
通常コピー | × | × | × | × | × |
robocopy | × | × | △ | × | × |
FSMT | △ | △ | △ | × | × |
Windows Server 移行ツール | 不明 | 不明 | 不明 | 不明 | 不明 |
×は移行不可能、△は一部移行可能という意味です。
Windows Server 移行ツールに関して、少なくとも Windows Server 2016 から 2016 へ移行はできませんでした。詳細は後述します。
それぞれの移行結果について
通常コピー
通常コピーについては完全にアウトです。データ以外の何も移行することができません。当然クォータやファイルスクリーンも駄目です。通常コピーでファイルサーバの移行はほぼ不可能ですね。
robocopy
次に robocopy を使用したファイルサーバ移行です。コマンドは以下のものを使用しました。
robocopy \\FILE-SEVER\D$\ D:\ /E /COPYALL /R:1 /W:1 /XA:A
robocopy はルートフォルダをコピーすることができないので、ドライブの直下に共有フォルダがある場合はこのようなコマンドになってしまいます。
「XA:A」はアーカイブ属性を除外するコマンドです。Dドライブ直下は隠しファイルがいくつか存在し、スキップはされるもののエラーが表示されてうざいので除外オプションを追加しています。
ちなみに、robocopy はコピー先で実行した方が速い説があるようなので、コピー先で実行しています。
結果は以下のように共有設定の移行は不可能でした。共有設定が移行されていないのでクォータやファイルスクリーンも駄目です。
NTFSアクセス許可については、一応移行できています。ただし、移行元と移行先ではユーザの SID が異なるため、下図のように SID がそのまま表示されて無効な値となってしまいます。
robocopy はそもそもファイルのコピーツールなので、共有設定などを移行できないのは当然と言えます。
ただし、robocopy でアクセス権は移行できるので、移行後に Power Shell の「Get-SmbShareAccess」コマンドレットや「Grant-SmbShareAccess」コマンドレットで共有設定を与えることは可能です。
昔の Windows には「Permcopy」コマンドという共有設定をコピーできるコマンドが搭載されていましたが、最近の Windows には標準搭載されていません。Powershell を使いましょう。
FSMT(File Server Migration Toolkit)
FSMT は Microsoft が提供しているファイルサーバの移行ツールです。以下のリンクが2019年9月現在での最新バージョンです。
DL:Microsoft File Server Migration Toolkit 1.2 | Microsoft ダウンロードセンター
FSMT は移行先サーバにインストールします。インストール後のウィザード実行には .NET Framework 3.5が必要ですのでインストールしてください。
移行結果を見てみると共有設定は移行可能なんですが、ネットワークパスがおかしくなりますし、なぜかフォルダ名が小文字に変換されます。
共有フォルダアクセス許可とNTFSアクセス許可も移行はできるんですが、robocopy と同じく SID の解決ができません。下図ではアクセス許可が消えているように見えますが、FSMT の「無効なセキュリティ記述子を解決する」というオプションがデフォルトで有効になっているためです。
FSMT はそもそもAD 環境でのファイルサーバ移行ツールのようです。
このツールは、Active Directory を使用した環境での利用を前提としています。Active Directory を使っておらず、ローカルユーザーとローカルグループで運用されている環境では、アクセス許可のコピーが正常に行えません。
『ひとり情シスに贈るWindows Server 2008/2008 R2からのサーバー移行ガイド』より引用
ひとり情シスに贈るWindows Server 2008/2008 R2からのサーバー移行ガイド
posted with ヨメレバ天野 司 日経BP 2019年07月05日
Windows Server 移行ツール
ローカル環境でのファイルサーバ移行の本命は Windows Server 移行ツールだったんですが、移行元でコマンドを実行した際に以下のエラーとなって移行不可能でした。
c:\SMT_ws16_amd64>SmigDeploy.exe
前提条件を確認しています。
——————————————————————————–
エラー: 必要なバージョンの .NET Framework がサーバーにインストールされていないため、Windows Server 移行ツールを実行でき ません。移行元サーバーには .NET Framework 2.0 以降のリリースの .NET Framework をインストールし、Windows Server 2012 以降のリリースの Windows Server オペレーティング システムには .NET Framework 4.0 以降のリリースの .NET Framework をインスト ールして、このコマンドを再実行してください。
勿論 .NET Framework はインストール済みです。
この現象について、事例自体は検索にヒットしましたが、解決方法は見つかりませんでした。
結局 robocopy しか選択肢が無い
Windows Server 移行ツールの動作が怪しい以上、Windows Server 移行ツールを使う前提で移行を考えると痛い目を見そうです。
結局のところ、最初から robocopy と powershell を使って移行するか、Windows Server 移行ツールによる移行に失敗したときに備えて robocopy での移行手順を押さえておくしかありません。
つまり、WORKGROUP 環境におけるファイルサーバ移行はほぼ robocopy 一択です。
Windows Server 移行ツールの件、同じような現象が起きましたが
移行元ではスタートボタンーWindows管理ツールーWindows Server移行ツールでPSを起動して「Receive-SmigServerData」でエラー無くできました。
貴重な情報ありがとうございます。ブログやっててよかったです。
後日再検証して更新します。<(_ _)>
横から失礼します。
こちら再検証されましたか?
私も同じエラーが発生しているので使用できそうかお聞きしたいです。
> sknさん
すみませんが、再検証はまだしていません。