第 3 章新しいメールサーバーの計画時に解決すべき問題

この節では、各移行プロジェクトの計画時に解決すべきトピックについて説明します。

サイトの設定とユーザーの特性の明確化

すべてのユーザーが物理的、地理的に 1 つの場所、つまり、1つのビルの中にいますか ? 全員が同じ階にいますか ? 同じ部屋にいますか ? あるいは、セントルイスに本社があり、タンジール、バルセロナ、オシュコシュに支社があり、シンガポールとタスカルーサに工場がありますか ? 現在の電子メールシステムで、各ロケーションに Exchange サーバーとユーザーの数はどれだけありますか ? 移行後に、何台の Sun Java System サーバーが各ロケーションのユーザーにサービスを提供しますか ?

現在の電子メールシステムで、ユーザーはさまざまな Exchange サーバーにどのように割り当てられていますか ? 地理的に割り当てられているだけですか ? たとえば、販売部門、技術部門、カスタマサービス部門など組織内の管理エンティティ別に割り当てられていますか ? あるいは、製品 XYZ チーム、製品 ABC チームなど、業務の単位やチーム別に割り当てられていますか ?

それぞれのユーザーの教育と研修のバックグラウンドは ? ユーザーのコンピュータの使用年数は ? 移行中にユーザーは管理者やヘルプデスクの「支援」をどの程度必要としますか ?

ユーザーのグループ化の基準と関係

ユーザーを一度に移行するときの最適な人数を決定します。最適な移行グループサイズは、サーバー上にあるユーザーのデータ量である程度決まります。移行グループサイズは、ヘルプデスクの規模と対応能力に関連付ける必要があります。これは、少なくともある程度の割合のユーザーがヘルプデスクに支援を求めることが想定されるからです。

最初のいくつかの移行グループは、予想した最適なサイズよりも小さくする必要があります。これらの最初のグループでは、大きなグループで人数に相当してより大きな問題が発生する前に、マニュアルや通信計画などに関する予定外の問題が発生する可能性があるからです。最初のいくつかの小さな移行グループによって、後で大きなグループを移行するときのヘルプデスクに対する需要を予測することもできます。

結局、通常は、ビジネス機能、管理上のエンティティまたは近似によって関係する、論理グループでユーザーを移行すると便利です。これにより、移行プロセスを通してユーザーが互いにサポートできます。

デスクトップインストール方法

Sun Java System Connector Deployment Toolkit には、さまざまなツールが含まれており、これらのツールの操作オプションには、ほとんどの環境、状況、および管理者の選択に適した移行方針を作成および実行するための幅広い柔軟性があります。次のトピックスでは、最も一般的な事例と、その事例に Sun の移行ツールがどのように適応するかを説明します。

対話式ユーザーインストール (セルフサービス)

Sun Java System Connector セットアップウィザードは、エンドユーザーが自分自身で簡単に実行できるように設計されています。このセットアップウィザードはファイルサーバーにおくことができ、エンドユーザーのワークステーションに個別にインストールする必要はありません。ただし、ユーザーのデスクトップに Java System Connector ソフトウェアを物理的にインストールするには、アクセス特権が必要になりますが、これは多くの場合、ほとんどのエンドユーザーには許可されていません。エンドユーザーが自分のデスクトップに対するインストール権限を持っていない場合、次のどちらかの方針を選択します。

各ユーザーのワークステーションに出向き、自分の管理者特権でユーザーのデスクトップにソフトウェアを物理的にインストールする

Microsoft SMS などの設定管理ツールを使って、ソフトウェアを複数のユーザーのデスクトップへ「プッシュ」する (以下の「SMS またはその他の設定管理ツールによる自動「プッシュ」」を参照)

ユーザーのデスクトップにソフトウェアを物理的にコピーした後、ユーザーはセットアップウィザードを実行してソフトウェアを設定し、既存の個人用フォルダ (.pst) ファイルを変換することができます。

変換プログラムを実行するエンドユーザーは、Sun Java System サーバーにユーザー自身の資格情報を提供します。したがって、この方法では、パスワードで保護された .pst ファイル (「パスワードで保護された Outlook の個人用ストア」を参照) を変換することができ、ユーザーは新しい Sun Java System Connector ソフトウェアで使用するために変換する個人用ストアを指定できます (ユーザーは変換されていない電子メールメッセージを読むことはできますが、新しいサーバーは変換されていないアドレスを認識できないため、返信することはできません。非常に古い個人用ストアがあり、将来返信する可能性がほとんどないような場合、ユーザーはそれらのファイルを変換しないように選択することもできます。変換はバックグラウンドで行われ、ユーザーはコンピュータで他の作業を行えますが、このプロセスによって他のアプリケーションのパフォーマンスが低下する可能性があります)。

対話式ユーザーインストールの大きな欠点は次のとおりです。

組織のヘルプデスクに対するサポート要求の増加。これはユーザーの技術スキルと移行「前」と「後」のネットワーク設定の複雑さに応じて、かなりの量になる可能性がある

管理者の時間と労力の問題。この作業を実行する権限のないユーザーのデスクトップへソフトウェアを物理的にコピーするために、複数のユーザーのワークステーションを飛び回る必要がある

管理者によるユーザーのコンピュータでのインストールの実行

前述のように、一部のユーザーに「セルフサービス」でインストールさせ、別のデスクトップで全体または一部のインストールを実行し、設定作業を行う管理者を割り当てたい場合があります。この方法では、自分自身の移行作業の準備が不足している管理職や技術力のあまりないユーザーの移行を円滑に行えます。配備計画で、このような管理者による直接のサポートが保証されるのは、組織のすべてのユーザーなのか、特定のユーザーなのかを明確にする必要があります。

SMS またはその他の設定管理ツールによる自動「プッシュ」

ユーザーデスクトップへのソフトウェアのインストールにはアクセス特権が必要になりますが、多くの場合、ほとんどのエンドユーザーには許可されていません。そういったネットワークのほとんどの管理者は、Microsoft SMS などの設定管理ツールを使って、ソフトウェアを複数のユーザーデスクトップへ「プッシュ」します。これにより、ユーザーのアクセス特権の必要性が回避されます。エンドユーザーがソフトウェアをインストールできないように「ロックダウン」した Windows 環境にネットワークからサービスが提供されている場合は、このような自動設定管理によって、管理者はそれぞれのユーザーデスクトップに何度も足を運ばないですみます。

「プッシュ」方式の配布を実現するには、配備設定プログラムを使って、ユーザーごとに 2 種類のバンドル版インストールパッケージを作成します。これらのパッケージは続けて実行されます。1 番目のパッケージでは、必要な Sun Java System ソフトウェアの「プッシュ」インストールを実行します。2 番目のパッケージでは、対話式プロセスを実行します。このプロセスで、ユーザーはインストールするソフトウェアと既存のデータファイルの変換に関するオプションを選択できます。この「プッシュ」方式を使ってエンドユーザーの変換プロセスを自動化することもできますが、パッケージは、ユーザーの Sun Java System 資格情報など、各エンドユーザーに固有の情報を使って起動する必要があるため、スクリプトが必要になります。

『デスクトップ配備設定プログラムリファレンス』では、Microsoft SMS を使ってこの「プッシュ」方式のソフトウェアの配布を実行する方法を説明しています。このリファレンスでは、SMS スクリプトでコマンド行スイッチを使用して、個人用フォルダ (.pst) ファイルに必要なユーザーのパスワードをデスクトップインストールプログラムに渡して、プロセスを完全に自動化する方法についても説明しています。

デスクトップインストール用のコマンド行スイッチ

Sun Java System Connector セットアップウィザードは、コマンド行スイッチをサポートしており、前述の他のデスクトップインストール方法や SMS スクリプトと組み合わせて使用できます。SMS スクリプトの使い方は、『Sun Java System Connector for Microsoft Outlook デスクトップ配備設定プログラムリファレンス』の「特殊な環境に関するアプリケーションノート」で説明しています。

インストールパッケージでは、次のコマンド行スイッチをサポートしています。

/USERNAME=xxx (xxx は、Sun サーバーのユーザー名)
/PASSWORD=xxx (xxx は、Sun サーバー上のパスワード)
/FULLNAME=xxx (xxx は、ユーザーの表示名)
/EMAILADDRESS=xxx (xxx は、ユーザーの電子メールアドレス)
/DN=xxx (xxx は、Sun サーバーのユーザー DN)
/NEWPROFILENAME=xxx (xxx は、作成したプロファイルの名前)
/SAVEPASSWORD=n (n = 1 (保存する) または 0 (保存しない))

次のスイッチは、Exchange プロファイルを変換する場合に役に立ちます。

/OLDDOMAIN=xxx (xxx は、Exchange ドメイン)
/OLDUSERNAME=xxx (xxx は、Exchange ユーザー名)
/OLDPASSWORD=xxx (xxx は、Exchange パスワード)

メッセージ以外の重要なサーバーデータの移行

古いサーバーにはユーザーに関する貴重な情報が含まれています。効果的な移行では、この情報を引き出して、新しい Sun Java System サーバーのユーザーアカウントを提供します。ユーザーの古いメールメッセージの他に、古いサーバーにはユーザーのカレンダ、仕事、個人アドレス帳、連絡先があります。またこの古いサーバーには、ユーザー名、プライマリインターネットアドレス、インターネットエリアス、電話番号、住所、さらにユーザーの所属部署、役職などの説明情報や企業のすべての公開配布リストも含まれています。

サーバーデータの移行の詳細説明は、このマニュアルの範囲を超えていますが、古いサーバーは、Sun Java System 上のユーザープロビジョニングやメールルーティングの変更に役立つ貴重なデータリソースであることを理解する必要があります。Sun のプロフェッショナルサービスは、配備計画でサーバーデータの移行を理解して調整するときに役立ちます。また、サードパーティーでもサーバーデータの移行を支援する技術とコンサルティングの専門家を用意しています。

サーバーの移行の移行期間中のメールルーティング

すべてのユーザーが同時に古いサーバーから新しいサーバーへ移行するわけではありません。ユーザーの実際の移行の前に新しいサーバーのユーザーアカウントが作成され、提供されます。このため、移行期間中は同じアドレスのユーザーメールボックスが古いサーバーと新しいサーバーの両方に同時に存在します。したがって、一時的なメール転送規則を定義して、ユーザーのメールが移行期間中に正しくルーティングされるようにする必要があります。

組織で新しいインターネットアドレスを導入する場合でも、古いアドレスを古いサーバー上に保持する必要があります。これはユーザーの古いプライマリインターネットアドレスが正しいサーバーに引き続き配信される場合にのみ、古いメッセージへの返信が配信可能になるためです。特定のドメインに対するすべてのインターネットメールは、関連する MX レコードで指定された単一のサーバーへ配信される必要があるため、新しい Sun Java System サーバーを指定するようにその MX レコードを更新する時期を組織で決定する必要があります。

移行期間の初めに MX レコードが Sun Java System サーバーに切り替えられる場合は、ローカルメールボックスに配信できないすべてのメールが、古いサーバー上の対応するメールボックスに送信されるように、Sun Java System サーバーを設定する必要があります。さらに、Sun Java System サーバー上に新しいユーザーのプロビジョンがあるたびに、本来は新しいメールボックスに配信されるすべてのメールが古いサーバー上の対応するユーザーメールボックスに転送されるように、新しいサーバーで転送規則を定義する必要があります。各ユーザーが新しいサーバーへ移行するたびに、新しいサーバーの最初の転送規則を削除し、すべてのユーザーのメールを対応する Sun Java System のメールボックスへ転送するように、古いサーバーで新しい規則を定義する必要があります。

一方、移行期間の最後まで MX レコードで古いサーバーを指定する場合は、ローカルで配信できないメールを Sun Java System サーバー上の対応するユーザーメールボックスに送信するように、古いサーバーを設定する必要があります。ユーザーが新しいサーバーへ移行するたびに、古いサーバーの他のユーザーから送信されたメールを Sun Java System サーバー上のユーザーの新しいアカウントに転送するように、古いサーバーで新しい規則を定義する必要があります。

移行中のグローバルアドレス帳の同期

大きな組織では、段階的移行を完了するのに数週間または数か月も必要になる可能性があります。また、移行中は一部のユーザーが 2つのシステムに同時に存在します。多くの組織では、すべてのユーザーが正確な企業ディレクトリ (個人電話帳、グローバルアドレス帳) へのアクセスを維持することが好まれますが、これを正確にするためには、従業員の雇用、異動、解雇のたびに 2 つのサーバーのディレクトリを定期的に同期する必要があります。したがって、配備計画では移行期間にわたって 2 つのディレクトリを定期的に同期するためのメカニズムを指定する必要があります。

Sun のプロフェッショナルサービスはこの問題を解決するための支援をします。またディレクトリの同期を実行するために利用できる製品もいくつかあります。

Sun Java System サーバーの新しいユーザー ID とパスワード

ほとんどのネットワークシステムは、ユーザーパスワードを発見できないように設計されています。これは特に Microsoft Exchange に当てはまります。これらのセキュリティ保護により、古いサーバーから新しいサーバーへ移行するときにユーザーの既存パスワードを自動的に保持することは不可能になります。

一方、多くの組織では、Sun Java System への移行中に、インターネットアドレスの形式を標準化するか、ドメインを結合することが好まれます。したがって、組織はアカウント名とインターネットアドレスの派生方法とユーザーの新しいパスワードの割り当て方法を事前に決定する必要があります。

また、ネットワーク管理者は、これらのユーザー資格情報をユーザーとヘルプデスクの両方に伝達する方法を工夫する必要もあります。一般的な方法の 1 つは、グループの移行の前に電子メールのマージを準備して、移行するグループの各メンバーがそれぞれ、新しいサーバーへのグループの最初のログインに間に合うように、自分の資格情報を受け取るようにすることです。

パスワードで保護された Outlook の個人用ストア

Outlook ユーザーはパスワードを個人用フォルダ (.pst) ファイルに割り当てることができますが、Sun Java System Connector セットアップウィザードでは、新しい Connector ソフトウェアと Sun Java System サーバーで使用できるように変換するために、これらのファイルを開いて変更する必要があります。したがって、エンドユーザーは変換したいすべての .pst ファイルに対してパスワードを入力する必要があります。

セットアップウィザードでは、必要に応じて必要なパスワードを自動的にユーザーに求めますが、これは明らかにユーザーの操作が必要になり、サイレントモードのセットアップは不可能になります。セットアップウィザードをサイレントモードで実行する場合は、変換中にすべてのパスワードを削除するか、適切なパスワードを入力してウィザードを実行するようにユーザーに指示することができます。セットアップウィザードをサイレントモードで実行しているときにパスワードで保護されたファイルが検出されると、ファイルは変換されず、すべてのファイルが変換されなかったことが報告されます。管理者の配備設定ツールの設定により、セットアップウィザードはエラーとしてイベントをログに記録することもできます。