ファイルサーバの移行方法4つを比較~WORKGROUP編~

ファイルサーバの移行を考える

WORKGROUP 環境でのファイルサーバの移行はどのように行うか。おおよそのインフラエンジニアは以下の4つのうちのどれかで移行しているのではないでしょうか。

  • 通常のコピー
  • robocopy
  • FSMT(File Server Migration Toolkit)
  • Windows Server 移行ツール

移行対象

4つの移行方式で、ファイルサーバの移行で最も気を使う以下の5つの項目を移行することができるのかを検証していきます。検証に使用する Windows のバージョンは移行元と移行先共に 2016 です。

  1. 共有設定
  2. 共有フォルダアクセス許可
  3. NTFSアクセス許可
  4. クォータ
  5. ファイルスクリーン

共有設定①

共有設定②

共有設定③

共有フォルダアクセス許可

NTFSアクセス許可

クォータ

ファイルスクリーン

最も確実な移行方法とは

先に検証結果を出しておきます。それぞれの移行方式について、何が移行可能で、何が移行不可能なのかを表にしたものが以下です。

共有設定共有フォルダアクセス許可NTFSアクセス許可クォータファイルスクリーン
通常コピー×××××
robocopy××××
FSMT××
Windows Server 移行ツール不明不明不明不明不明

×は移行不可能、△は一部移行可能という意味です。

Windows Server 移行ツールに関して、少なくとも Windows Server 2016 から 2016 へ移行はできませんでした。詳細は後述します。

それぞれの移行結果について

通常コピー

通常コピーについては完全にアウトです。データ以外の何も移行することができません。当然クォータやファイルスクリーンも駄目です。通常コピーでファイルサーバの移行はほぼ不可能ですね。

共有されていない

NTFSアクセス許可もリセット

robocopy

次に robocopy を使用したファイルサーバ移行です。コマンドは以下のものを使用しました。

robocopy \\FILE-SEVER\D$\ D:\ /E /COPYALL /R:1 /W:1 /XA:A

robocopy はルートフォルダをコピーすることができないので、ドライブの直下に共有フォルダがある場合はこのようなコマンドになってしまいます。

参考リンク:Robocopyはルートフォルダとそのタイムスタンプをコピーしません

「XA:A」はアーカイブ属性を除外するコマンドです。Dドライブ直下は隠しファイルがいくつか存在し、スキップはされるもののエラーが表示されてうざいので除外オプションを追加しています。

ちなみに、robocopy はコピー先で実行した方が速い説があるようなので、コピー先で実行しています。

参考リンク:robocopy の速度向上ノウハウ~遅い原因と見直すべき5点~ | SEの道標

結果は以下のように共有設定の移行は不可能でした。共有設定が移行されていないのでクォータやファイルスクリーンも駄目です。

共有されていない

NTFSアクセス許可については、一応移行できています。ただし、移行元と移行先ではユーザの SID が異なるため、下図のように SID がそのまま表示されて無効な値となってしまいます。

プリンシパルの解決ができない

robocopy はそもそもファイルのコピーツールなので、共有設定などを移行できないのは当然と言えます。

ただし、robocopy でアクセス権は移行できるので、移行後に Power Shell の「Get-SmbShareAccess」コマンドレットや「Grant-SmbShareAccess」コマンドレットで共有設定を与えることは可能です。

Permcopy

昔の Windows には「Permcopy」コマンドという共有設定をコピーできるコマンドが搭載されていましたが、最近の Windows には標準搭載されていません。Powershell を使いましょう。

参考リンク:フォルダ共有のアクセス権限設定バックアップ | TechNet

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 の「無効なセキュリティ記述子を解決する」というオプションがデフォルトで有効になっているためです。

共有フォルダアクセス許可は移行できるが SID の解決ができない(SID が無効なため移行時に削除された)

NTFS許可も移行できるが SID の解決ができない(SID が無効なため移行時に削除された)

FSMT はそもそもAD 環境でのファイルサーバ移行ツールのようです。

このツールは、Active Directory を使用した環境での利用を前提としています。Active Directory を使っておらず、ローカルユーザーとローカルグループで運用されている環境では、アクセス許可のコピーが正常に行えません。

『ひとり情シスに贈るWindows Server 2008/2008 R2からのサーバー移行ガイド』より引用

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 はインストール済みです。

.NET Framework は問題なし

この現象について、事例自体は検索にヒットしましたが、解決方法は見つかりませんでした。

参考リンク:Сannot run Windows Server Migration Tools because a required version of .NET Framework is not installed | TechNet

結局 robocopy しか選択肢が無い

Windows Server 移行ツールの動作が怪しい以上、Windows Server 移行ツールを使う前提で移行を考えると痛い目を見そうです。

結局のところ、最初から robocopy と powershell を使って移行するか、Windows Server 移行ツールによる移行に失敗したときに備えて robocopy での移行手順を押さえておくしかありません。

つまり、WORKGROUP 環境におけるファイルサーバ移行はほぼ robocopy 一択です

コメントを残す

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

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)