Cisco ICM 4.6.2 計画ガイド

概要

このドキュメントでは、Cisco Intelligent Contact Management（ICM）のさまざまなコンポーネントをバージョン 4.0.x から 4.1.x または 4.5.x から 4.6.2 にアップグレードするために必要な適切な計画情報について説明します。 以前のリリース（2.x、3.x）から 4.6.2 にアップグレードする場合は、まず 4.1.x または 4.5.x にアップグレードする必要があります。 ICM リリース 4.0.x 以降からアップグレードする場合は、ICM 4.6.2 に直接アップグレードできます。 『Cisco ICM 4.6.x Release Notes』を参照してください。

前提条件

要件

次の項目に関する知識が推奨されます。

• 基本レベルの Cisco ICM サポートおよびトラブルシューティング

• アップグレードの計画方法

• Cisco ICM システムの管理とトラブルシューティング

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

• Cisco ICM バージョン 4.6.2 の最小ハードウェア要件

• Microsoft SQL Server バージョン 6.5

• Microsoft SQL Server バージョン 7.0

• Microsoft Windows 2000 のアップグレード

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

Cisco ICM 計画ガイドで取り上げない内容

このドキュメントでは、次の内容を取り上げません。

1. Microsoft SQL Server をバージョン 6.5 から 7.0（Cisco ICM 4.5.0 以降と互換性あり）にアップグレードする方法、または Microsoft Windows NT を Windows 2000（ICM 4.6.2 以降と互換性あり）にアップグレードする方法。

2. ICM のアップグレード方法。 このドキュメントは、ICM ソフトウェアをアップグレードするプロジェクト マネージャが、バージョン 4.6.x 用の ICM アップグレード プロセス マニュアルと併せて参照するための計画ガイドとして意図されています。

3. ICM と連動する CallManager、IP 自動音声応答（IVR）、コンピュータ テレフォニー インテグレーション（CTI）デスクトップ/クライアントといった Internet Protocol Contact Center（IPCC）コンポーネントや、Unity、Personal Assistant、自動アテンダントやその他レコーディング装置とのソリューションについては、このドキュメントでは取り上げません。 ただし、特定のバージョンの ICM には、これらのコンポーネントの特定のバージョンとの互換性があるため、包括的な ICM アップグレードを計画する際は、それらのコンポーネントを含める、あるいは考慮する必要は出てくるものと思われます。 ICM と併せた複数のアップグレードを計画する際は、このドキュメントに記載されているロードマップ/マッピング セクションが参考になります。

ICM 製品スイートのほとんどのコンポーネントは、冗長性を備えています。 ICM スイートの冗長性モデルには、次の 2 つがあります。

• ホット スタンバイ

• 実行の同期

この 2 つのモデルの違いと、どの ICM コンポーネントがどのモデルを使用するかを理解することが重要です。 冗長性モデルによって、アップグレード時のシステムの動作が異なってくるためです。

ICM CallRouters、ロガー、NIC、Peripheral Gateway（PG）、CTI ゲートウェイ（CG）、および CTI オペレーティング システム（OS)サーバの場合、冗長ペアを構成する 2 つのコンポーネントは一般に「A 側」と「B 側」と呼ばれます。 ディストリビュータ管理ワークステーション（AW）の場合は、それぞれプライマリ ディストリビュータとセカンダリ ディストリビュータと呼ばれます。

WebView および Historical Data Server（HDS）はハイブリッド モデルです。 「二重化された」WebView または HDS の実装は、プライマリまたはセカンダリ ディストリビュータとしての AW のペアと共存する WebView または HDS オプションで構成されます。 基礎となるディストリビュータ AW の動作にも左右されますが、HDS の複製プロセスが実行され、WebView は両方の側で同時にクライアント接続を受け入れます。 ただし、WebView で障害が発生しているときに、クライアントがもう一方の側にリダイレクトされることはありません。さらに、HDS の冗長ペアが存在するとしても、（WebView または Monitor ICM から送信される可能性がある）履歴クエリがその HDS 側にリダイレクトされることもありません。

Cisco ICM アップグレードの準備

複数のアップグレード パスのマッピング

Cisco ICM ソフトウェアのアップグレードに向けた最初のステップとして、アップグレード パスを作成します。 一貫性と互換性を確保し、正しいプロセスを設定するため、そして最新のドキュメントが参照されるようにするためには、アップグレード パスを綿密に計画する必要があります。 この項では、アップグレードを成功させるために推奨する手順を説明します。 システムが現在 ICM 4.6.2 のハードウェアおよびソフトウェア仕様に従っていて、アップグレードする予定のコンポーネントが ICM だけであれば、アップグレード パスを計画するのは簡単で、時間もかかりませんが、 ほとんどのお客様はこのカテゴリーに該当しません。 通常は、ハードウェアが第 1 に優先される考慮事項であり、サードパーティ製ソフトウェアについての考慮は後回しにされます。 見過ごされることが多いのですが、システム全体を考慮し、ICM リリースのアップグレードに伴って他にもアップグレードしなければならないコンポーネントがある場合は、それらのコンポーネントも確実にアップグレードする必要があります。 最初に確認しなければならないのは、バージョン間でのソフトウェアの互換性です。

シナリオ 1：

Hardware upgrade > ICM version 4.6.2 upgrade > SQL version 7.0 upgrade >
 Microsoft Windows 2000 upgrade

シナリオ 2：

Hardware upgrade > NAM version 4.6.2 upgrade > SQL version 7.0 upgrade >
 Windows 2000 upgrade

シナリオ 3：

Hardware upgrade > ICM version 4.6.2 upgrade > CallManager version x.x > 
IPIVR version x.x > SQL version 7.0 upgrade > Windows 2000 upgrade

シナリオ 4：

Hardware upgrade > NAM version 4.6.2 upgrade > CallManager version x.x >
 IPIVR version x.x > > SQL 7.0 version upgrade > Windows 2000 upgrade

Cisco ICM/NAM

2 階層のサービス ビューロー アーキテクチャでは、Cisco ICM ソフトウェアがキャリア ネットワークからルート要求を受信し、それをカスタマー ICM に転送します。 一般に、NAM には一部のコールを直接ルーティングするために必要な小規模な設定だけが含まれていて、残りのコールは適切なカスタマー ICM にディスパッチされます。 NAM はカスタマー ICM から応答を受信して、それらの応答をキャリア ネットワークに転送します。

NAM システム専用の 4.6.x アップグレード計画ガイドが用意されています。

Cisco CallManager および IPIVR（IPCC）

IPCC システムを構成する 3 つの主要コンポーネントは、 Cisco ICM、Cisco CallManager、および Cisco Customer Response Solutions（CRS/CRA）（具体的には IP IVR/QueueManager）コンポーネントです。

これらのコンポーネントを組み合わせることで、エージェント状態のモニタリングと制御、ルーティング、連絡先のキューイング、CTI 機能、エージェントとスーパバイザのリアルタイム データ収集、管理用履歴レポート作成を含む、自動着信呼分配（ACD）機能が実現します。

Microsoft SQL Server 6.5 から SQL 7.0 へのアップグレード

シスコでは、ICM をご利用のお客様には、最初に ICM バージョン 4.6.2 にアップグレードしてから SQL バージョン 7.0 へのアップグレードを行うよう要請しています。 最初のアップグレードが完了してから次のアップグレードを開始するまでのテスト期間には、少なくとも 7 日を要します。

注: SQL Server 2000 は現在 ICM 4.6.2 でサポートされていません。

Microsoft Windows 2000 のアップグレード

シスコでは、ICM をご利用のお客様には、最初に ICM バージョン 4.6.2 にアップグレードしてから Windows 2000 へのアップグレードを行うよう要請しています。 最初のアップグレードが完了してから次のアップグレードを開始するまでのテスト期間には、少なくとも 7 日を要します。 Windows 2000 のアップグレードに関する承認済みのドキュメント（極めて重要なドメイン構造に関する情報を含む）は、Cisco Web サイトにある「Microsoft サポート情報」ページで入手できます。

Cisco ICM アップグレードの計画

ICM 4.6.2 へのアップグレードを計画する際は、考慮すべき事項がいくつかあります。 このドキュメントには、アップグレードを成功させるための計画を適切に立てる際に役立つ詳細な情報および参考資料が記載されています。

ICM 事前計画タスク

• サイトで ICM ソフトウェアと同時にアップグレードする予定のシステムとコンポーネント（ハードウェア、サードパーティ製ソフトウェア、IPCC、Microsoft Windows 2000、SQL 7.0 など）をすべて明らかにして取りまとめます。

• 組織内の ICM サポート チームと協力して、ICM システムに現在問題がないことを確認します。 アップグレードの前に ICM システムが正しく動作していることが、後々の問題解決に役立ちます。

• ICM を新しいバージョンにすることによって修正できる問題およよび追加される新しい機能を明らかにし、理解します。 新しい ICM の資料をすべて検討します。

• ICM をアップグレードする前またはアップグレードした後にアップグレードする必要があるサードパーティ製コンポーネント、ハードウェア、および他の ICM 以外のコンポーネントについて調べ、アップグレード計画を立てます。

• ICM バージョン 4.6.2 に関する ICM のリリース ノートを読みます。 これらの資料には、前提条件、機能の変更、および新機能に関する重要な情報が記載されています。

• ICM バージョン 4.6.2 に関するすべての Field Notice を読みます。

• ICM システムに含まれるさまざまな PG に関連するすべての周辺装置が、最低でも ICM バージョン 4.6.2 をサポートしているリリースであることを確認します。 ACD 互換性マトリックスと、ACD に関するシステム マネージャ向けガイドの補足資料を参照してください。

• すべてのハードウェア（CPU、ハード ドライブ、メモリ）、サードパーティ製ソフトウェア（Windows NT サービス パック、SQL サービス パック）、およびスイッチ（PBX、VRU）を、新しい ICM の要件を満たすようアップデートします。

• ICM 環境内の各コンポーネントを ICM バージョン 4.6.2 に対応させるための ICM ホットフィックスを確認します。

  注: このリンクにアクセスするには、登録ユーザとしてログインする必要があります。 アップグレード手順を行っている間に、ホットフィックス CD から該当するホットフィックスを直接ダウンロードすることを推奨します。

• ロガーと HDS のデータベースをバックアップします。 「ICM データベースのバックアップの実行」を参照してください。

• （ICM バージョン 4.5 以降の場合）SQL Server バージョン 6.5 から 7.0 へのアップグレードを計画している場合は、そのアップグレードを別途行います。

• Microsoft Windows NT から Windows 2000 へのアップグレードを計画している場合は、そのアップグレードを別途行います。

• すべての WebView II（ICM バージョン 4.5 以降の場合）のサードパーティ製ソフトウェアの要件が、対応する AW で適合していることを確認します。 適合しているかどうか確実でない場合は、ICM バージョン 4.6.2 の Cisco ICM ソフトウェア WebView 管理者ガイドで確認してください。

• アップグレードの前にカスタム レポートをすべてバックアップできるよう、適切なリソースをスケジュールします。

• アップグレードの後にカスタム レポートをすべて再作成できるよう、適切なリソースをスケジュールします。

• 必要に応じて、アップグレードの後にカスタム CTI 機能を再構築できるよう、適切なリソースをスケジュールします。

• 内部の組織、カスタマー ベース、および関連するすべてのベンダー（Cisco、AT&T、MCI など）に、アップグレードを実施すること、およびアップグレードの実施中または完了後に発生する可能性のある変更や機能停止について通知します。

• ハードウェア、ソフトウェア、またはネットワーク通信で問題が発生した場合に対応できるよう、適切な内部リソースをスケジュールします。 自動着信呼分配（ACD）ベンダー、ネットワーク管理者などに、アップグレードの実施中にオンサイトまたはオンコールで対応してもらわなければならない場合もあります。

• アップグレードの実施中に ICM スクリプトや設定に対する変更が行われないようにします。 それには、Regedt32 で特定のレジストリ キーを変更することで対処できます。 詳細については、バージョン 4.6.x の ICM アップグレード プロセス マニュアルを参照してください。

• すべてのシステム上のすべてのインターフェイスの IP アドレスを正確に記載した、有効なネットワーク ダイアグラムを用意します。

• ICM システムのアップグレード後に行う、コール ルーティング、CTI 機能、設定ツール、およびレポート機能に対するテスト手順を計画します。

• アップグレードの実施予定日の少なくとも 3 ～ 4 日前に ICM ソフトウェアを発注するようにします。 メディアが破損していたり、欠陥がある場合に備えて、各 CD を 2 枚ずつ発注するようにしてください。

• シスコのプロフェッショナル サービス グループから、計画に関するサポートを受けることができます。 価格を含む詳細については、エンゲージメント マネージャ（icmupgrades@cisco.com ）にお問い合わせください。

• マルチノードの CallManager クラスタでは、ICM PG を加入者に接続した状態にしておくことを推奨します。 PG を CallManager Publisher に接続できるのは、CallManager クラスタが 2 つのノードで構成されている場合のみです。

Cisco ICM のハードウェアの事前計画

ICM プラットフォームで使用されるすべてのハードウェアは、最低でも ICM バージョン 4.6.2 の最小要件を満たしている必要があります。 次の表に、ICM 4.6.2 ソフトウェアのアップグレードのみに関する最小要件を記載します。 シスコでは、ここに記載する「推奨される仕様」を満たすよう推奨します。 これらの最小要件には、アップグレードに伴って、新しい Cisco ICM ソフトウェア製品、新しい ICM サイト、あるいは新しい機能（CTI および MIS など）をインストールする場合に必要となり得るサイト計画は考慮されていません。 このような新規インストールの詳細については、シスコのシステム エンジニア（SE）または Cisco Technical Assistance Center（TAC）にお問い合せください。

これらの最小要件を満たさないハードウェアは、要件を満たすようにアップグレードするか交換する必要があります。 サーバをアップグレード（RAM の追加など）できるかどうかを判別して確認するには、それぞれのハードウェア ベンダーにお問い合せください。

ハードウェアを交換する場合は、「Cisco Enterprise Contact Routing の製品構成表」を参照してください。

注: 製品構成表（BOM）には、ICM ならびに現在のシステムには適用されないその他のコンポーネント（ISN および E-Mail Manager）も記載されています。 BOM は一般的なガイドラインとして作成されたものであり、現在市場で入手できるハードウェアが反映されています。 したがって、一覧されている推奨事項は、次の表に記載されている内容とは大幅に異なる場合があります。

最小要件および推奨事項

NAM システム ノード	物理的な RAM	CPU	CPU 使用率	使用可能または空きディスク領域： 最小/推奨
Call Router	1.5GB	500MHz 以上	50% 未満	500MB/1 GB
Logger	1.5GB	500MHz 以上	50% 未満	500MB/1 GB
PG	768MB	500MHz 以上	50% 未満	500MB/1 GB
AW-ディストリビュータ	512MB	500MHz 以上	50% 未満	500MB/1 GB
AW-HDS	1.5GB	500MHz 以上	50% 未満	500MB/1 GB
AW-HDS-WebView	1.5GB ～ 2GB	500MHz 以上	50% 未満	1.5GB/2 GB
AW- クライアント	256MB	500MHz 以上	50% 未満	250 MB/500MB

* 記載されているのは RAM の最小要件です。 アップグレード前の評価で、RAM の使用率が搭載済みの物理 RAM の容量に近いか超えている場合は、最小値にかかわらず、RAM の追加が必要となります。

サードパーティ製ソフトウェアの事前計画

サードパーティ製ソフトウェアはすべて、サードパーティ製ソフトウェアの要件を記載した次の表に適合している必要があります。 サードパーティ製ソフトウェアの要件との適合性を維持することは、お客様の責任となります。 シスコでは、サードパーティ製ソフトウェアのアップグレードを行いません。 次の情報は、「Cisco Enterprise Contact Routing の製品構成表」で詳しく説明されています。

サードパーティ製ソフトウェアの要件

CallRouter
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
PCAnywhere	10.5
Microsoft Internet Explorer およびサービス パック	5.5 SP2 以降
Logger
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
Microsoft SQL およびサービス パック	6.5 SP5A
Microsoft SQL およびサービス パック	7.0 SP3
PCAnywhere	10.5
Microsoft Internet Explorer	5.5 SP2 以降
AW（リアルタイム クライアントのみ）
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
Microsoft SQL およびサービス パック	6.5 SP5A
Microsoft SQL およびサービス パック	7.0 SP3
PCAnywhere	10.5
Microsoft Internet Explorer	5.5 SP2 以降
InfoMaker	7.0.3
AW（リアルタイム ディストリビュータのみ）
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
Microsoft SQL およびサービス パック	6.5 SP5A
Microsoft SQL およびサービス パック	7.0 SP3
PCAnywhere	10.5
Microsoft Internet Explorer	5.5 SP2 以降
InfoMaker	7.0.3
HDS オプションを使用した AW（リアルタイム ディストリビュータのみ）
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
Microsoft SQL およびサービス パック	6.5 SP5A
Microsoft SQL およびサービス パック	7.0 SP3
PCAnywhere	10.5
Microsoft Internet Explorer	5.5 SP2 以降
InfoMaker	7.0.3
WebView サーバ
Microsoft Windows NT およびサービス パック	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
Microsoft SQL およびサービス パック	6.5 SP5A
Microsoft SQL およびサービス パック	7.0 SP3
PCAnywhere	10.5
InfoMaker	7.0.3
Microsoft Internet Explorer（または Netscape Navigator）	5.5 SP2 以降
Netscape Navigator（または Microsoft Internet Explorer）	4.7
Microsoft Internet Information Service（IIS）（Microsoft NT）	4.0
Microsoft IIS（Microsoft 2000）	5.0
Sun JDK	リリース 1.3.1
新しい Atlanta Servlet	リリース 3.1
Jaguar CTS	リリース 3.5 および 3.6.1 アップグレード
PG
Microsoft Windows NT	4.0 SP6A
Microsoft Windows 2000 およびサービス パック 2
PCAnywhere	10.5
Microsoft Internet Explorer	5.5 SP2 以降

Cisco ICM スイッチ互換性に関する事前計画

周辺装置（ACD および VRU/IVR）はすべて、現在の Cisco ICM リビジョンの要件を満たしていなければなりません。 現在、次の ACD 補足ガイドを利用できます。

• Aspect Call Center に関する Cisco ICM ソフトウェア ACD 補足ガイド

• Definity ECS に関する Cisco ICM ソフトウェア ACD 補足ガイド

• Nortel Meridian に関する Cisco ICM ソフトウェア ACD 補足ガイド

• Nortel Symposium に関する Cisco ICM ソフトウェア ACD 補足ガイド

使用しているスイッチのタイプがリストされていない場合は、保守契約会社にサポートを依頼してください。

Cisco ICM 固有の考慮事項

ソフトウェアのアップグレードを成功させるためには、次の考慮事項と要件を検討する必要があります。

ラボでのアップグレード

可能であれば、最初に ICM ラボ環境で ICM ソフトウェアのアップグレードをテストすることをお勧めします。 ICM ラボでのアップグレードを計画する際は、システムがハードウェア、ソフトウェア、および ACD との互換性の面において ICM 4.6.2 の要件を満たしていることを確認してください。 これによって、準備時間も含めた ICM システムのアップグレードに必要な時間枠が、より正確に計画に反映されるようになります。

不測の事態と復旧に関する計画

万一に備えて、Cisco ICM のアップグレードを開始する前に、綿密な復元計画を立てておくことが常に推奨されます。 障害が発生した場合（ソフトウェアやハードウェアなど）は、アップグレードを元に戻して復旧する必要があります。そのための時間を考慮してください。 障害が発生する可能性が最も高いのは、中央コントローラ、HDS、または AW を最初に設定する際です。 イベントの順序には、1 から 7 までのステップがあります。 障害が発生する可能性があるため、依存関係が必要な場合は特に十分な時間の余裕をもってアップグレードを計画することが推奨されます。 たとえば、お客様が Windows 2000 のアップグレードの要件を満たすために、ICM 4.6.2 へのアップグレードを計画しているとします。 その場合、障害の発生に備えて、両方のアップグレードを立て続けに行わないようにスケジュールすることが得策です。 計画段階で、同様の規模と重要度を持つ他のプロジェクトに移る前に、ICM システムのアップグレード、その取り消し、およびテストを行うのに十分な時間を考慮しておきます。 ICM ソフトウェアのアップグレードを元に戻すプロセスは、バージョン 4.6.x の ICM アップグレード プロセス マニュアルに記載されています。 ICM システムをアップグレード前の現行リリースに戻して復元する場合に備え、次の領域を適切にバックアップまたは保存して復元に利用できるようにしておく必要があります。

• ロガーおよび HDS 上の SQL データベースをバックアップします。

• 全ノードの Geotel レジストリ キーを保存します。

• 全ノードの ICR\BIN フォルダを保存します。

• 全ノードのカスタム ワーク フォルダを保存します（たとえば、レポートなど）。

CTI

シスコ プロフェッショナル サービス、サードパーティ ベンダー、または内部担当者にカスタム ソフトウェアを作成してもらった場合は、適切なカスタム エンジニアリング サービス グループにその成果物の検討を依頼し、ICM 4.6.2 との互換性を確認することを推奨します。

カスタム レポート

シスコ プロフェッショナル サービス、サードパーティ ベンダー、または内部担当者にカスタム レポート（Monitor ICM、WebView I、または WebView II）を作成してもらった場合は、ICM 4.6.2 と WebView II のアップグレードによって、それらのカスタム レポートが上書きされることに注意してください。 ICM をアップグレードする前に、レポートをバックアップしておく必要があります。 これらのレポートの再入力や作成に関するサポートが必要な場合は、アップグレードを始める前に、カスタム エンジニアリング サービス グループに相談することを推奨します。 レポートの種類によっては、カスタム エンジニアリング サービス グループが計画を立てるための時間も必要になります。

非 ICM データベース オブジェクト

非 ICM データベース オブジェクトはすべて、ICM 4.6.2 にアップグレードする際にすべて上書きされます。 アップグレードとすべてのテストが完了した後に、このデータを再入力するのは、お客様の責任です。

アプリケーション ゲートウェイ

ICM 4.6.2 と通信を行うアプリケーション ゲートウェイのバージョンは、2.0 以上でなければなりません。 これは、お客様が事前計画の一環として計画する必要があります。

データのバックアップ

Cisco ICM のアップグレードを始める前に、必要なすべてのアプリケーションのバックアップを取っておきます。 事前計画段階の一環として、プロジェクト マネージャはロガー A、ロガー B、および HDS の SQL データベースをバックアップするようお客様に要請する必要があります。 これ以外のデータを各ノードのアップグレード前にバックアップする作業は、アップグレード エンジニアがその職責の一部として行う必要があります。 バックアップする必要があるデータには、特定のディレクトリ、設定、各ノードのレジストリなどがあります。 詳細な手順（ノードごと）については、アップグレード エンジニアはバージョン 4.6.x の ICM アップグレード プロセス マニュアルを参照する必要があります。

データベースのバックアップは、ICM ロガー、HDS、AW、あるいは SQL Server で最悪の障害が発生した場合に備えたプロセスとして定義されています。 最悪の障害とは、デバイスの再構築、またはデータの復元が必要となる場合を意味します。

ICM 製品は、ミッション クリティカルなアプリケーションをサポートするための耐障害性を備えた設計になっています。 具体的には、ICM の推奨アーキテクチャには、ICM システムからあらゆる単一障害点を排除するという目的があります。 このアーキテクチャが暗黙的に示しているのは、同一のデータベースを維持する冗長ロガーの存在です。

バックアップには、次の 4 つのコンポーネントが含まれます。

• データベース全体

• Cisco ICM の設定とスクリプトのデータ

• Microsoft Windows NT レジストリ

• カスタム フォルダ（該当する場合）

ICM データベースのバックアップについては、ICM データベースのバックアップ戦略に関するマニュアルを参照してください。

SQL データベースのバックアップに関する詳細は、Microsoft の Web サイトを参照してください。

デフォルト ルートの計画

お客様は、アップグレードの実施日時に先立って、デフォルト ルートの計画を立てておく必要があります。 該当する組織内の関係者、ベンダー（スイッチのベンダーなど）、TAC に通知しておくことにより、アラームに関する懸念を軽減できます。

一方の側の ICM 中央コントローラ（CallRouter/Logger）がシャットダウンされてアップグレードが完了すると、現行バージョンの ICM ソフトウェアを使用しているもう一方の側の ICM 中央コントローラ（CallRouter/Logger）がオフラインになり、アップグレードされた側がオンラインになります。 このスイッチオーバーが、アップグレード プロセスで ICM システムがコールをルーティングしない唯一の期間となります。 スイッチオーバーは数分で完了します。 この期間にコールをルーティングするために、おそらくデフォルトのネットワーク ルーティングを計画することになります。 デフォルトのネットワーク ルーティングを適切に計画しておかなければ、確実に悪影響が出ます。 二重化されたペアの両側が、異なるバージョンの ICM ソフトウェアを使用して同時に動作することはできません。したがって、最初にアップグレードする ICM 中央コントローラが完全に停止したことを確認してから、アップグレードされた側の ICM 中央コントローラを起動してください。 この時点でアップグレード済みの AW はオンラインになり、他の AW はすべてダウン状態になります。

アップグレード後のテスト計画

アップグレードを実施する前に、必ず、アップグレードが機能することを完全にテストするための計画を立ててください。 アップグレードの途中およびアップグレードが完了した直後に、コール ルーティング機能、リアルタイム レポートと履歴レポート、設定およびモニタリング ツールなどのコンポーネントをテストする必要があります。 通常、アップグレードによってシステムに悪影響が生じることはありませんが、それでもテストを行うことは基本的かつ予防的な作業です。 テスト フェーズを単純にするために、最も一般的に使用されるレポート作成ツールや設定ツールを対象としたテスト計画を策定することを推奨します。

CTI のスクリーン ポップや他の CTI 機能を対象としたテスト計画も立てる必要があります。 社内（非 Cisco 製の）CTI クライアント アプリケーションを使用しているサイトでは、コーディングの変更によって、特定のイベントに対するソフトウェアの表示や反応に影響が出る場合があります。 デスクトップ用の標準的な CTI ツールキットを使用している場合は、システムを Cisco ICM 4.6.2 と互換性のある最新バージョンにアップグレードすることを推奨します。 シスコの代理店に問い合せるか、シスコのエンゲージメント マネージャ（icmupgrades@cisco.com）にメールで問い合わせてください。

アップグレードは通常、オフピークの時間帯に行われます。 アップグレードが最もよく行われるのは、午前 0 時から朝の 7 時までの間で、週末に行われることも一般的です。 ほとんどの場合、アップグレードは一晩では終わりません。また、アップグレードのための時間枠が複数必要になることもあります。 最初のメンテナンス時間枠は、ICM 中央コントローラと重要な AW を最初にアップグレードさせることを目的に設けます。 その後、残りの重要性の低い AW および PG のアップグレードを必要に応じてスケジュールします。 このドキュメントで説明するように、アップグレード済みのマシンとアップグレード前のマシンの間でのフェールオーバー時の影響が最小限になるアップグレードの時間枠を特定する必要があります。

タイムフレームおよび順序の計画

タイムフレームの考慮事項

アップグレードの計画を立てる際に考慮する必要のある領域は、次のとおりです。

• 二重化する中央コントローラのフル バージョン（ルータとロガー）は、2 つとも同じソフトウェア リリースでなければなりません。 A 側と B 側のバージョンが異なる間は、中央コントローラを起動してはなりません。 アップグレード中のサービス中断を最小限に抑えるために推奨されるイベントの順序については、「Cisco ICM アップグレードのタイムフレーム」と「サードパーティ製ソフトウェアの要件」の表を参照してください。

• 二重化する PG は同じリリースでなければなりません。 A 側と B 側のバージョンが異なる間は、PG を起動してはなりません。 アップグレード中のサービス中断を最小限に抑えるために推奨されるイベントの順序については、「Cisco ICM アップグレードのタイムフレーム」の表を参照してください。

• AW と HDS を動作させるには、中央コントローラと同じリビジョンにアップグレードする必要があります。 計画を立てる際の参考として、これらのサーバは、中央コントローラと同じメンテナンス時間枠でアップグレードしてください。 サーバのバージョンがルータとロガーより古いバージョンの場合、サーバは動作しません。

• PG には下位互換性があります。 中央コントローラよりバージョンが 1 つ遅れていても、PG は引き続き動作します。 これは、サービスを中断させることなく PG のアップグレードを終了するのに十分な時間の余裕を持たせるための設計です。 すべての ICM ノードを同一の ICM リリースにすることを強く推奨します。また、リリースを統一させるまでの時間は、可能な限り短くする必要があります。

• AW と PG のイベントの順序は、これらのマシンの優先順位とテストに基づいて計画してください。 これは特に、これらのノードのメンテナンス時間枠が複数にわたっている場合に必要なことです。

• 一般的なカスタマー メンテナンス時間枠は 8 ～ 10 時間です。 これはつまり、平均的な規模またはそれを上回る規模のインストールの場合、数回のメンテナンス時間枠にわたってアップグレード作業を行わなければならないことを意味します。 アップグレードのメンテナンス時間枠をスケジュールする際は、次の表に一覧するタイムフレームに留意してください。

Cisco ICM アップグレードのタイムフレーム (ノードごとの推定値)

ICM ノード	おおよその期間
ICM CallRouter	45 分
ICM データベース サーバ（ロガー）	45 分～ 1 時間
ICM PG	30 分
ICM AW リアルタイム クライアントのみ	30 分
ICM AW リアルタイム ディストリビュータのみ	30 分
ICM AW HDS	45 分～ 2 時間
WebView が搭載された ICM HDS	45 分～ 2 時間
** データベースのサイズと ICM のリリースに大きく依存します。 期間には、データ移行にかかる時間は含まれていません。
上記の時間には、データベースのバックアップやサードパーティ製ソフトウェアまたはハードウェアのアップグレードなど、アップグレード前の作業にかかる時間は含まれていません。 これらの作業は、ICM をアップグレードする前に行っておく必要があります。 Cisco ICM Enterprise Edition の「Field Notice - ICM 4.6.2 のアップグレードに関する考慮事項」に記載されている、ICM のデータ移行の進捗状況を判別するための手順も参照してください。

Cisco ICM のスケジュールおよびイベントの順序

次の表に、初期メンテナンス時間枠での一般的なイベントの順序を記載します。

ステップ	アップグレードのステップ	ルーティング	期間（平均）
1	中央コントローラ A 側をアップグレード	B 側	1.5 時間
2*	優先順に従ってアップグレード（1 台の AW、1 台の HDS、または 1 台の WebView tousai HDS）	B 側	30 分
3	中央コントローラ B 側とアップグレード前の AW（HDS マシンと WebView サーバを含む）をダウン状態にする	ネットワーク	５　分
4	最初に中央コントローラ A 側を起動。 次に、他のアップグレード済みマシンを起動	A 側	５　分
5	アップグレード済みシステムをテスト	A 側	お客様のテスト計画に依存
6	中央コントローラ B 側をアップグレード	A 側	1.5 時間
7	最初に中央コントローラ B 側を起動してテスト	A 側	10 分
8	中央コントローラ A 側と B 側の間でのフェールオーバーをテスト	A 側または B 側	５　分
9*	時間とアップグレード エンジニアの数に応じて、残りの AW、HDS マシン、および WebView サーバを優先順に従ってアップグレード	A 側	30 分（AW）、各 1.5 時間（HDS または WebView サーバ）
10**	残りの PG をアップグレード	ICM のアクティブ側	各 30 分
合計時間：		11 時間以上

注: 上記の時間には、データベースのバックアップやサードパーティ製ソフトウェアまたはハードウェアのアップグレードなど、アップグレード前の作業にかかる時間は含まれていません。 これらの作業は、ICM をアップグレードする前に行っておく必要があります。

通常は、最初のアップグレード時間枠でアップグレードのステップ 1 からステップ 9 までを実施するように計画します。 この最初の時間枠は、一般にプロジェクトで最も重要なものです。 残りの AW および PG は、必要に応じてステップ 10 でアップグレードできます。 AW は、中央コントローラと同じバージョンになるまで動作しないことに注意してください。 複数のメンテナンス時間枠にまたがってアップグレードを調整する必要がある場合は、最優先される AW を特定して最初にアップグレードする必要があります。 PG（A 側および B 側）は、中央コントローラより完全に 2 つ分古いリビジョンでも動作するため、大多数の PG は必要に応じて 2 番目のメンテナンス時間枠でも処理できます。

Cisco ICM Enterprise Edition の「Field Notice - ICM 4.6.2 のアップグレードに関する考慮事項」に記載されている、ICM のデータ移行の進捗状況を判別するための手順も参照してください。

Cisco ICM ソフトウェアの注文

Cisco ICM ソフトウェアを注文する際は、有効な CCO ログインと、有効かつアクティブなメンテナンス契約番号を所持している必要があります。 ソフトウェアの CD は次のリンクから発注できます。

ベース ICM ソフトウェア

シスコでは、注文する ICM リリースごとに 2 つのセットをリクエストすることを推奨しています。 メディアに障害が発生した場合は、2 つ目のメディアを使用できるためです。 配送には、最短でも 4 営業日かかることをご了承ください。 最新のすべてのホットフィックスを確実に入手できるように、ソフトウェアの発注は、アップグレードの実施予定日時より 2 週間以上先行して行わないようにしてください。 ソフトウェアが届いたら、パッケージを開封して、すべての CD が含まれていることを確認します。 サードパーティ製ソフトウェアである WebView は、ICM ソフトウェアとは別の CD に収録されています。

Cisco ICM ソフトウェア アップグレード： ノードごとの準備

このドキュメントではアップグレードに備えて準備するための手順（ソフトウェア、ハードウェア、SQL のバックアップなど）について概説していますが、ICM のアップグレードを行う担当者は、アップグレードが失敗したときに備えて、各ノードで予防措置をとっておく必要があります。 これらのステップは、バージョン 4.6.x の ICM アップグレード プロセス マニュアルに詳しく記載されています。 このマニュアルは、登録された CCO ログイン アカウントを所持していれば入手できます。

エンジニアがこれらの追加の予防措置をとることは必要不可欠です。 アップグレードが失敗した場合は、アップグレードを取り消して、任意の時点での状態に戻さなければならないからです。 バックアップを正しく行うために必要な準備を行う必要があります。 たとえば、このドキュメントでは、ノードのアップグレードを開始する前に、各ノードで次の項目を保存する方法について説明しています。

• 全ノードの Geotel レジストリ キーを保存します。

• 全ノードの icr\bin フォルダを保存します。

• 「route print」のコピーを作成して保存します。

• 「ipconfig /all」のコピーを作成して保存します。

• 「netstat -a -n」のコピーを作成して保存します。

Cisco ICM Upgrade Success Program

Cisco ICM のアップグレードを自分で計画および実行する代わりに、シスコのプロジェクト マネージャとエンジニアのチームがアップグレードをお手伝いできます。 Cisco ICM Upgrade Success Program では、お客様にいくつかのパッケージを提案し、そこからニーズに合うものを選択できるようにします。

Cisco ICM Upgrade Success Program の詳細については、担当の Cisco アカウント チームに直接お問い合せになるか、エンゲージメント マネージャ（icmupgrades@cisco.com）にメールを送信してください。 お客様のサイトへのプログラムのオファリングについて検討させていただきます。

これはプロフェッショナル サービス オファリングであり、有償の作業明細書を通して実行されます。 価格は、システムのサイズやプロジェクトの規模などの他、いくつかの要素に基づいて決まります。 このプログラムには次のような利点があります。

• お客様のサイト固有のニーズを満たす、複数のプログラム オファリング

• 個別サポート

• アップグレードの実績

• 専用のリソース

• ハードウェアおよびサードパーティ製ソフトウェアに関するサイトの評価

• 詳細なアップグレード計画

• 管理されたスケジュール

シスコ認定パートナーから ICM システム/メンテナンス契約を購入された場合は、アップグレード計画のサポートについてはそちらに直接お問い合せください。

関連情報

• ICM データベースまたはMicrosoft SQL 6.5のバックアップの実行
• Field Notice
• テクニカルサポート - Cisco Systems