Windows Server移行ツール/FSMTでファイルサーバーを移行する:今から始めるWindows Server 2003移行のススメ(4)
ファイルサーバーの移行とは、単純に考えるとファイル/フォルダーのコピーである。ただし、適切なアクセス権や共有の設定は必須だ。こうした作業を楽にするツールが提供されているので、その使用方法を紹介する。
【オンプレかクラウドか】ファイルサーバーの移行先を検討しよう
Windows Server 2003で構築されたファイルサーバーは、OSが登場した時期を考えると、そのほとんどは物理サーバーにインストールされたものになるだろう。しかし、現在は仮想化環境が一般的となり、その延長にはクラウドもある。そこで、ファイルサーバーの移行先としては、オンプレミス環境だけではなく、クラウド環境という選択も考えられるようになっている。
クラウド環境へ移行する場合
マイクロソフトが提供するパブリッククラウド「Microsoft Azure」のIaaS(Infrastructure as a Service)を利用することで、ファイルサーバーをクラウド環境に移行することができる。
その場合、Microsoft Azureと既存のオンプレミス環境は、VPN(Virtual Private Network)で接続する。これにより、Microsoft Azureがあたかもプライベートなブランチサイトのように利用できるようになるので、そこにファイルサーバー環境を構築するのだ(図1)。このような環境を構築すれば、オンプレミス環境の「新規サーバーへの移行」と同様の手順で移行することが可能になる。
【参考情報】Microsoft Azure自習書
- Microsoft Azure自習書シリーズNo.7:企業内システムとMicrosoft AzureのVPN接続、ファイルサーバー連携
- Microsoft Azure自習書シリーズNo.8:企業内システムとMicrosoft AzureのVPN接続、Active Directory、ファイルサーバー連携
オンプレミス環境へ移行する場合
オンプレミス環境でファイルサーバーを移行する場合は、Active Directory環境で構築されたドメインに参加していることが前提となる。現在の最新サーバーOSとなるWindows Server 2012 R2に移行することで、新機能を活用したより高度なファイルサーバーの運用が可能になる。まずは、既存のファイルサーバーの移行を完了し、その後、Windows Server 2012 R2で利用可能な機能を検討したい。
本稿ではWindows Server 2012 R2への移行をターゲットに解説を進めるが、移行方法の1つである「インプレースアップグレード」(既存のサーバーOS上で新規OSをアップグレードインストールすること)は考慮しない。その理由は、Windows Server 2003からWindows Server 2012 R2へのインプレースアップグレードがサポートされていないからだ。
ここで、簡単にWindows Server 2003からのインプレースアップグレードパスをおさらいしておこう。Windows Server 2003は、Windows Server 2008 R2までのインプレースアップグレードがサポートされている。ただし、次のような要件がある。
- 「Service Pack(SP)2」が適用されていないWindows Server 2003はサポートしない
- 異なるアーキテクチャ間のインプレースアップグレード(x86からx64など)はサポートしない
- 異なる言語間のインプレースアップグレード(英語からドイツ語など)はサポートしない
- 異なるエディション間のアップグレード(例えば、Windows Server 2008 Foundation SKUからWindows Server 2008 Datacenter SKU)はサポートしない
- 種類が異なるビルド間のインプレースアップグレードはサポートしない
Windows Server 2008 R2は64bit(x64)版しか提供されていないので、Windows Server 2003の32bit版からのインプレースアップグレードはサポートされない。Windows Server 2003が提供された当時はx64版よりもx86版の使用が多かったこともあり、多くのパターンとして当てはまるのは、Windows Server 2003(x86版)からのインプレースアップグレードとなり、その場合はWindows Server 2008(x86)までとなる(表1)。
Windows Server 2012 R2がサポートするインプレースアップグレードパスは、Windows Server 2008 R2 SP1以降が対象になる(表2)。先ほど紹介した「異なるアーキテクチャ間のインプレースアップグレード」は存在しない。Windows Server 2008 R2以降ではx86版は提供されておらず、全てx64版となるからだ。だたし、インプレースアップグレードの要件としては次のようなものがある。
- 既存のドメインコントローラーが64bit版であること(Windows Server 2012 R2はx64のみ提供)
- 同じ言語であること
- 既存の「Server Core」ドメインコントローラーをフルインストールモードに切り替える(または、その逆方向に切り替える)場合は、インプレースアップグレード後に構成を変更する
以上のことから、Windows Server 2003のファイルサーバーをWindows Server 2012 R2へ移行する場合は、新規にWindows Server 2012 R2サーバーを構築して、そこに移行することになる(図2)。
新規構築するWindows Server 2012 R2のファイルサーバーは、既存のファイルサーバーと同じドメインに参加させることで、アクセス権を維持したフォルダーやファイルの移行が可能になる。
【移行前の準備】共有アクセス権とNTFSアクセス権に注意
ファイルサーバーは、既存のフォルダー構造を維持したままで移行することも可能だ。しかし、多くの企業では自社の成長や使い勝手に合わせて拡張されていることが多い。なので、本来理想とする構造になっていないのであれば、ファイルサーバーの移行はこれを変更するよい機会になるだろう。
また、ファイルサーバーの移行では、アクセス権のチェックも重要なポイントになる。ファイルサーバーのフォルダーのセキュリティは「共有アクセス権」と「NTFSアクセス権」の組み合わせで構成されており、両方のチェックを経てクライアントからのアクセスが行われる。
これは移行作業中も同様で、そもそも移行元サーバーのフォルダーやファイルにアクセスできなければ移行することはできない。そこで、トラブルなく移行を進めるためのステップとして、共有アクセス権を「Everyone:フルコントロール」に設定して、ファイルアクセスに対するNTFS権で制御する手法を取るのがよいだろう。
セキュリティ本来の考えからすると、NTFSアクセス権と同じように、共有アクセス権にもアクセス可能なユーザーやグループを個別に割り当てることが理想だ。しかし、運用ベースで考えた場合には、共有アクセス権は全てのユーザーをアクセス可能にし、NTFSアクセス権で一元的にアクセスを制御した方が運用は容易になる(図3)。
次に、NTFSアクセス権で着目すべき点は、移行元のフォルダーやファイルに管理者である「administrator」や「SYSTEM」のアクセス権が設定されているかどうかを確認することだ。
その理由としては、特定のユーザーだけがアクセス可能なフォルダーやファイルには、当然、管理者である「administrator」や「SYSTEM」のアカウントからはアクセスできないからだ。つまり、移行を行う管理者アカウントからアクセスできなければ、移行もできないということになる。
これはユーザー個人に対して「フルコントロール」の権限を与えている組織に見られる現象でもある。また、個人用フォルダーなども同様だ。このような場合、マルウェア対策ソフトなども正常動作が妨げられる原因になる。
ファイルサーバーの移行は、単純に考えるとフォルダー/ファイルのコピーになる。ただし、組織で運用するには各ユーザーに対する適切なアクセス権の付与が必要になるので、それらの情報も同時に移行する必要がある。
この2つの作業を同時に行うための適切なツールが用意されているので、これを使用してファイルサーバーを移行するのが基本的なアプローチとなる。
本稿で紹介するのは、マイクロソフトから無償で提供されている「Windows Server移行ツール」と「ファイルサーバー移行ツールキット(FSMT)」の2つだ。これらを活用することで、ファイルサーバーを容易に移行できるだろう。
【移行方法1】「Windows Server移行ツール」による移行
「Windows Server移行ツール」は、Windows Server 2012 R2の「標準機能」として提供されており、共有フォルダーの共有設定や、ユーザーデータを移行することができる。Windows Server移行ツールは、以下の5つのWindows PowerShellコマンドレットで構成されている。
- Export-SmigServerSetting
- Import-SmigServerSetting
- Get-SmigServerFeature
- Send-SmigServerData
- Receive-SmigServerData
Windows Server移行ツールによるファイルサーバーの具体的な移行方法は、次のようになる(図4)。移行元のサーバーと移行先のサーバーでの操作があるので、混乱しないように注意してほしい。
移行先のWindows Server 2012 R2での操作
(1)移行先のWindows Server 2012 R2サーバー(以下、移行先サーバー)上で、「役割と機能の追加ウィザード」から「Windows Server移行ツール」の機能をインストールする。
(2)次の「SmigDeploy」コマンドを実行する(移行元のファイルサーバーがWindows Server 2003(64bit版)で、「D:\Work」フォルダーに移行ツール(移行ストア)を準備する場合)。
「C:\Windows\System32\ServerMigrationTools」のパスに移動
SmigDeploy /package /architecture amd64 /os WS03 /path
(3)指定したフォルダーの「SMT_ws03_amd64」サブフォルダーに移行ツールが用意されたので、このフォルダーを移行元のWindows Server 2003ファイルサーバー(以下、移行元サーバー)にコピーする。
(4)次の「Netsh」コマンドを実行して、「Windowsファイアウォール」に「受信の規則」(7000/TCP、7000/UDPの許可)を追加する。
Netsh advfirewall firewall add rule name=“ServerMigration(TCP-In)” dir=in protocol=TCP localport=7000 action=allow
Netsh advfirewall firewall add rule
移行元のWindows Server 2003での操作
(5)Windows PowerShell 2.0を利用するために、移行元サーバーに「.NET Framework 2.0 SP1」と「Windows Management Framework Core」をインストールする。
- Microsoft.NET Framework 2.0 Service Pack 1(x86)
- Microsoft.NET Framework 2.0 Service Pack 1(x64)
- Windows Management Framework Core x86(KB968930)
- Windows Management Framework Core x64(KB968930)
(6)次の「Netsh」コマンドを実行して、移行元サーバーのWindowsファイアウォールに「送信の規則」(7000/TCP、7000/UDPの許可)を追加する。
Netsh firewall add portopening protocol=ALL port=7000 name="ServerMigration"
(7)移行元サーバーで、手順(3)で移行先サーバーからコピーした移行ツール(「SMT_ws03_amd64」フォルダー)の「SmigDeploy.exe」を実行する。すると、Windows PowerShellウィンドウが開くので次の「Export-SmigServerSetting」コマンドレットを実行して、ローカルユーザーとローカルグループを移行するための「svrmig.mig」ファイル(移行データ)を出力する。
Export-SmigServerSetting -User All -Group -Path <移行データの格納先パス> -Verbose
移行先のWindows Server 2012 R2での操作
(8)「移行データ」(svrmig.mig)を移行元サーバーから移行先サーバーへコピーする。
(9)移行先サーバーの「サーバーマネージャー」から「Windows Server移行ツール」を起動し、次の「Import-SmigServerSetting」コマンドレットを実行して「移行データ」(svrmig.mig)をインポートする。
Import-SmigServerSetting -User All -Group -Path <移行データの格納先パス> -Verbose
このコマンドにより、移行先サーバーには移行元サーバーと同じローカルユーザーとローカルグループが作成される。ただし、セキュリティ上の理由からユーザーアカウントは無効にされており、「ユーザーは次回ログオン時にパスワードの変更が必要」が有効になっている。
移行元のWindows Server 2003での操作
(10)共有設定とデータの移行のため、移行元サーバーで、次の「Send-SmigServerData」コマンドレットを実行する。このコマンドレットを実行すると、指定したフォルダーの移行は保留され、移行先サーバーからのコマンドレッドを待つ状態となる。ただし、5分が経過しても接続がない場合はタイムアウトになり、コマンドレットの待機状態は終了する。
Send-SmigServerData -Include All -ComputerName "移行先サーバー名" -SourcePath "移行元サーバーの共有フォルダーのローカルパス" -DestinationPath "移行先サーバーの共有フォルダーのローカルパス" -Recurse
移行先のWindows Server 2012 R2での操作
(11)5分以内に移行先サーバーで、次の「Receive-SmigServerData」コマンドを実行する。
Receive-SmigServerData
以上の操作でファイルサーバーを移行できる。移行元サーバー、移行先サーバーでそれぞれ操作が必要になるので、慎重に行ってほしい。
【移行方法2】「ファイルサーバー移行ツールキット」による移行
「ファイルサーバー移行ツールキット 1.2」(File Server Migration Toolkit:FSMT)は、マイクロソフトが無償で提供するGUIの移行ツールになる(画面1)。Windows Server 2012/2012 R2でFSMTを利用するには、「.NET Framework 3.5」(.NET 2.0および3.0を含む)のインストールが必要になる。
FSMTの特徴は、複数のファイルサーバーからの移行をサポートしていることだ。「分散ファイルシステム」(Distributed File System:DFS)にも対応しているので、新しいサーバーにファイルを移動した後も、元のUNC(Universal Naming Convention)パスを維持できる。
FSMTの基本的な操作はウィザードの指示に従って進めるだけなので、迷うことなく実行できるだろう。具体的なファイルサーバーの移行の流れは次のようになる。
(1)新規プロジェクトの作成
(2)セットアップ(移行元サーバー、共有フォルダー、移行先のパスなどを指定)
(3)コピー
(4)最終処理(移行元サーバーの共有を停止する、など)
(5)移行完了(レポートの表示)
【新機能】新しいファイルサーバーではこの機能を使え!
今回紹介した2つのツールで、同じようにファイルサーバーを移行することができる。Windows Server移行ツールでは、移行するフォルダーごとにコマンドレッドを実行する必要があるので、フォルダー構造のトップレベルで実行すれば容易に移行ができる。
一方、FSMTは、ファイル共有されているファイルのみを移行できる。また、筆者が遭遇した現象としては、空フォルダーが移行されなかったので注意が必要だ。
Windows Server 2012 R2に移行したら、ぜひ導入を検討してほしいのが「ファイルサーバーリソースマネージャー」(FSRM)だ。これは、ファイルサーバー用の管理ツールであり、次の機能を提供する。
- クォータの管理(ディスク使用量の制限)
- ファイルスクリーンの管理(アップロード禁止ファイルの指定)
- 記憶域レポートの管理(レポーティング機能)
- 分類管理(自動ファイル分類)
- ファイル管理タスク(分類に基づいたポリシー適用)
さらに、「サーバーマネージャー」→「ファイルサービスと記憶域サービス」→「ボリューム」メニューから「共有フォルダー」のプロパティを開くと、次の設定が可能になる(画面2)。
- アクセス許可設定に基づいた列挙:ユーザーが共有フォルダーにアクセスした際、アクセス権のないフォルダーは表示しない
- 共有のキャッシュ:共有内容をオフラインで使用できる
- データアクセスの暗号化:ファイル共有へのネットワークアクセスを暗号化された状態で行う
特に、「アクセス許可に基づいた列挙」は、ぜひ利用してほしい機能だ。これにより、アクセス権のないフォルダーは表示されなくなるので、ユーザーの生産性も向上するだろう。Windows Server 2012 R2ではWindows Server 2003では利用できなかった多くの機能を搭載しており、これらを利用することでファイルサーバーをより有効に活用できるようになる。
マイクロソフトが期間限定公開中 Active Directoryのスキルをブラッシュアップしよう!
クラウドの登場により、Active Directoryに求められる役割も変化しつつあります。
クラウドに対応させるためのActive Directoryの設計ポイントとはどにあるのか? iOSやAndroidは、Active Directoryにどう絡むのか? Azure Active Directoryとは何者か? 生産性を高めるためのセキュリティを実現するには、どのようなインフラが必要か?
今こそ、Active Directoryの役割を再学習し、古い知識をリセットしましょう!
- 第1回 Active Directoryの位置づけ
- 第2回 Active Directory ドメイン サービスの新しい役割
- 第3回 Active Directory フェデレーション サービスの役割 解説編
- 第4回 Active Directory フェデレーション サービスの役割 構築編
- 第5回 認証のためのプロキシ Web Application Proxy
- 第6回 Microsoft Azure Active Directoryとは
筆者紹介
阿部 直樹(あべ なおき)
エディフィストラーニング株式会社所属のマイクロソフト認定トレーナー。Active Directory、Network、Security、Hyper-V、Clusterなどを担当。マイクロソフト トレーナー アワード(2010年)およびMicrosoft MVP for Hyper-V(Apr 2010 - Mar 2014)を受賞。個人ブログ『MCTの憂鬱』でマイクロソフト関連情報を発信中。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 基礎から分かるActive Directory再入門(1):Active Directoryはなぜ必要なのか
本連載では「Active Directoryとは?」「なぜ、Active Directoryを使う必要があるのか?」などをあらためて考察し、より効果的に運用するための方法を探っていく。 - Windows Server 2003からの乗り換え案内:Windows Server 2012 R2で行こう!
Windows Server 2003のサポート終了日「2015年7月」が迫ってきた。本稿では、Windows Server 2003から最新のWindows Server 2012 R2へ移行する理由やメリットについて取り上げる。 - Windows Server 2012 R2とSystem Center 2012 R2が企業のクラウド導入を強力に後押しする
マイクロソフトがビジョンとして掲げる「クラウドOS」。そのクラウドOSを具現化したサーバーOSが、Windows Server 2012 R2だ。では、クラウドOSとは何なのか。クラウドOSによってどのようなビジネスメリットがもたらされるのか。 - Windows Server 2012 R2登場(1):企業のIT基盤を変革する“クラウドOS”とは何か
本連載では、Windows Server 2012 R2とSystem Center 2012 R2の導入で、企業のIT環境やエンドユーザーの現場はどう変化するのか、新バージョンに実装された新機能を中心に探ってみる。