Windows NT 4.0 Serverマイグレーションの現状と問題点(2/2) |
|||
|
|||
聞き手、文責:デジタルアドバンテージ 2003/08/22 |
NT4 Serverをインストールしてインプレース・アップグレードするのが王道
―― NT4 Serverから、Windows 2000 Serverへの一般的な移行手順を教えてください。
吉池:ドメインの設定や管理がきちんとなされているという前提なら、メインとなるドメイン・コントローラに対してインプレース・アップグレードを実行するのが最も素直な方法でしょう。これなら、すべての環境をそのまま引き継いでWindows 2000 Serverに移行できます。エンド・ユーザーにはまったく影響を及ぼしません。ユーザーは、いつ何が変わったのか分からないでしょう。
―― もう少し具体的にお願いします。
吉池:リプレースする新しいサーバにまずNT4 Serverをインストールします。インストールが完了したら、このNT4 ServerコンピュータをBDC(Backup Domain Controller)として既存のNT4ドメインに参加させます。そしてリプレース対象のNT4 Serverで運用されているPDC(Primary Domain Controller)の情報をBDCに同期させてから、PDCをBDCに降格させ、新しいNT4 ServerのBDCをPDCに昇格させます。この後、PDCとなったNT4 Server(新しい方のサーバ)に対し、Windows 2000 Serverへのインプレース・アップグレードを実行するのです(下図参照)。
NT4 Serverのリプレース手順(1) |
既存のNT4 Serverをリプレースするには、新しいサーバにNT 4 Serverをインストールし、これを既存のドメインにBDCとして参加させて、PDCの情報と同期させる。 |
NT4 Serverのリプレース手順(2) |
次に、追加したBDCをPDCに昇格し、元のPDCはBDCに降格する。 |
NT4 Serverのリプレース手順(3) |
PDCとなったNT4 Server(新しい方のサーバ)をWindows 2000 Serverにインレース・アップグレードする。 |
―― なるほど。いったんNT4 Serverをインストールするのがポイントですね。しかし最新のハードウェアでは、NT4用のドライバが提供されないなど、NT4をインストールできないケースもありませんか。
吉池:確かに、そこがこの方法の問題点の1つです。特に心配なのはデバイス・ドライバですね。ですからこの方法は万能とはいえません。しかし最もトラブルが発生しにくい方法なので、これが使えるときには使うようにしています。
―― Windows 2000 Serverでは、Active Directoryを利用できるわけですが、移行時にNTドメインの統合などは行わないのでしょうか。
吉池:そうですね。いったんメインとなるドメインを構成してから、そこに従属しているドメインから各種のオブジェクトを移行してドメインを統合します。この作業にはさまざまなツールが提供されていますのでそれらを利用します。
―― 大きなドメインに作り直すのですね。
吉池:ええ。最終的にはそうします。
移行期間はどれくらいかかるのか
―― ケース・バイ・ケースだとは思いますが、企業がNT4 Serverからの移行を検討し始めてから作業が完了するまではどの程度の時間がかかるのでしょうか。
吉池:数千人以上の規模では、調査と設計に4〜5カ月くらいはかかります。またこの規模になると、万一移行作業に失敗した場合の影響が非常に大きいので、リハーサルを何度か繰り返し、手順の見直しなどを行って精度を上げていきます。これに1カ月くらいかかります。そして準備が整った時点で、一気に移行作業を実施します。トータルでは半年程度といったところでしょうか。大規模な環境で、複数の拠点があるような場合には、メインとなるドメインを構築してから、拠点ごとに移行処理を行うので、さらに数カ月はかかります。これまでで、最も長くかかったケースでは、1年という例がありました。
気になる移行時のトラブルは?
―― 移行作業で深刻なトラブルが起こるという例もあるのですか。
吉池:残念ながらあります。Windows 2000 Serverの発表直後のときには、Windows 2000 Server側の問題でトラブルが発生するケースもありましたが、これらについてはすでに修正されています。最も厄介なのは、NT4ドメインが正しく管理されていない環境で移行作業を実施し、問題が発生するケースでしょう。
― 具体的にはどのようなケースでしょうか。
吉池:現場のニーズからボトムアップ的に構築された比較的小規模なドメインで、正式な管理者もいない状態で運用されているようなケースが典型です。PCやネットワークに詳しい人がボランティア的に管理しているケースが多いのですが、専業ではないので、ネットワークの細部までは必ずしも掌握していません。こういった状況で、うっかりサーバOSの移行を実施すると、問題が発生する場合が少なくありませんし、原因究明も困難なので問題解決も容易ではありません。
― 仮に問題が起こって解決不能に陥ったらどうすればよいのでしょう。
移行時に解決不能の問題が発生した場合は、デザインからあらためてやり直すのが早道だと思います。(本間氏) |
本間:突き放すようないい方になってしまいますが、結果的には、デザインからあらためてやり直すのが早道だと思います。
吉池:イベント・ビューアに表示されたエラーを1つ1つ潰していけばよいというものではありません。重要なことは、ネットワーク全体を掌握して、どこで何が起こっているのかを管理者が理解することです。これには、ネットワークの再デザインが最も手っ取り早い手段でしょう。NT4 Serverのインストールは自分たちでできたから、Windows 2000 Serverへのアップグレードも同じようにできると考えるのは間違いです。移行作業では、既存資産を新しい環境でも使えるようにしなければなりません。簡単そうでありながら、これが一番難しいのです。まず、いま動いているものが何なのか、それらはどうなっているのかを正しく理解するところから始まるのです。
―― 自分で構築したNT4 Server環境であっても、移行はインテグレータなどの専門家に任せた方がよいということでしょうか。
吉池:そういうケースもあると思います。
クライアントの移行は段階的実施が主流
―― これまでは、主にサーバの移行についてお話を伺いましたが、クライアント側の移行についてはどうでしょうか。Windows 2000 Server/Windows Server 2003では、Active Directoryを利用できるのですが、Windows 98/Meなどのクライアントでは、セキュリティ機能もないし、グループ・ポリシーも適用できないなど、Active Directoryの恩恵をあまり受けられませんね。
本間:もちろん、クライアントも含めて一気に移行できれば簡単なのですが、現実には、予算の問題などから、リース期間の満了時期に合わせて、クライアント側は段階的に移行させるというのが一般的のようです。また予算の問題以外にも、クライアント/サーバ・システム(以下C/Sシステム)として構築されたクライアント・ソフトウェアが、新しいOSではうまく動かないといった互換性の問題が発生することもあります。
― 業務アプリケーションの互換性問題ですか。それは厄介ですね。とはいえ、古いクライアントをいつまでも使い続けられないとすれば、どうやってその問題を解消すればよいでしょうか。
吉池:1つは、クライアント・アプリケーションを新しいOSでも問題なく動くように改修することです。しかしクライアント・ソフトウェアのバージョン管理が複雑になるなど、現実にこの方法を選択するユーザーはあまり多くありません。2つ目は、C/Sシステムをやめて、業務アプリケーションをWebアプリケーションに移行させ、クライアント側はWebブラウザだけで利用できるようにする方法です。これはなかなかよい方法ですが、業務アプリケーションの根本的な変更を伴いますから、ソフトウェア移行に多大なコストがかかるという欠点があります。これに対し最近増えているのは3つ目の方法で、シトリックス社の「MetaFrame」を利用して、既存のC/Sシステムをできる限り流用しながら、サーバ側だけですべてを実行できるようにする方法です。
―― MetaFrameというと、ターミナル機能を利用して、サーバ側で実行したアプリケーションのウィンドウをクライアント側に表示し、あたかもクライアントで実行しているように見せるシステムですね。
吉池:そうです。MetaFrameでは、Windows 95/98/Meをはじめ、クライアント向けのアクセス・ソフトウェアが提供されています。MetaFrameサーバを設置して、業務アプリケーションをサーバ側で実行できるように構成すれば、後はクライアントにアクセス・ソフトウェアをインストールするだけで、Windows OSのバージョンに依存することなく業務アプリケーションを実行可能になります。この場合、既存の業務アプリケーションにはほとんど手を入れる必要がありません。
移行作業に向けた情報源、移行に向けて準備すべきこと
―― これから自分でNT4 Serverの移行を行おうとしている管理者が頼りにできる情報源はありますか。
移行にあたっては、正常な状態がどうなのかを把握するために、作業開始前に、現在の状態をさまざまなモニタ・ツールでモニタしておくことをお勧めします。(吉池氏) |
吉池:やはり、マイクロソフトがWebで公開しているサポート技術情報が役に立ちます。何か疑問や問題に突き当たったら、まずはサポート技術情報を検索してみるとよいでしょう。何らかのヒントを得られるはずです。それからActive Directoryへの移行では、DNSの設定がハードルになることが多いようです。隅々まで読みこなす必要はないでしょうが、DNSのバイブルといわれている書籍の『DNS and BIND』(オライリー・ジャパン発行)に一通り目を通しておくとよいでしょう。
―― そのほか、自分で移行作業を行うに当たり、注意すべきことはありますか。
吉池:移行作業を開始する前に、現在の状態をさまざまなモニタ・ツールでモニタしておくことをお勧めします。この作業は軽視されがちですが、正常な状態がどうだったのかを把握しておかないと、何か不都合が起こっても、何がおかしいのか分からなかったり、場合によっては問題が起こっていること自体を認識できなかったりします。本当なら、移行作業の直前だけでなく、日ごろからネットワークの状態をモニタしておくのが理想でしょう。
INDEX | ||
[Trend Interview] | ||
NT4 Serverマイグレーションの現状と問題点(1/2) | ||
NT4 Serverマイグレーションの現状と問題点(2/2) | ||
「Trend Interview」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|