Cisco Unified Communications Manager リリース 10.5(1)の IM and Presence サービスのパーティション イントラドメイン フェデレーション
ユーザの移行計画
ユーザの移行計画

ユーザの移行計画

移行中のユーザ ID の保守

Lync/OCS からIM and Presence サービスへの移行時には、Microsoft Lync および Microsoft Office Communicator のユーザは同じ ID(URI)を維持する必要があります。 移行中に同じ ID を保守する場合、次のような利点があります。

  • ユーザの ID が変わらないため、ユーザのアベイラビリティ状態を維持できます。

  • また、ユーザの連絡先リストを Microsoft サーバから IM and Presence サービスに直接インポートできるため、ユーザの連絡先リストをより単純に移行できます。

IM and Presence サービス の URI は、Cisco Unified Communications Manager のユーザ ID と IM and Presence サービスドメインを次のように結合して構成されます。

<userid>@<domain>

ユーザが Cisco Unified Communications Manager ユーザ インターフェイスまたは Cisco Unified Communications Manager Bulk Administration Tool(BAT)を通して手作業で追加されている場合、ユーザ作成時に指定したユーザ ID がユーザの Microsoft サーバ URI のユーザ部分と一致していることを確認する必要があります。 たとえば、Microsoft ユーザの URI が bobjones@foo.com の場合、bobjones というユーザ ID でユーザを作成する必要があります。

Cisco Unified Communications Manager が Active Directory からのユーザと同期するよう設定されている場合、Cisco Unified Communications Manager のユーザ ID へのマッピングに使用する [Active Directory] フィールドが Microsoft サーバの URI のユーザ部分と一致していることを確認する必要があります。 次の点に注意してください。

  • Cisco Unified Communications Manager は、限定された数の [Active Directory] フィールドの userID とマッピングします。ほとんどの場合、ID は sAMAccountName です。

  • Cisco Unified Communications Manager が userID を sAMAccountName にマッピングする場合、移行ユーザの Microsoft サーバの URI も <sAMAccountName>@<domain> というフォーマットに一致する必要があります。

  • Bob Jones の sAMAccountName が bjones の場合、Microsoft サーバの URI は bjones@cisco.com でなければなりません。

  • Microsoft のサーバの URI がどれも <sAMAccountName>@<domain> フォーマットに一致しない場合、スIM and Presence サービスにそのバッチを移行する前に、Microsoft Server ユーザの各バッチの URI を変更できます。

移行前のタスク

Lync/OCSSIP URI が IM and Presence サービス URI 形式の <userid>@<domain> に一致しない場合、段階的にユーザを移行する Microsoft Server URI を変更できます。 以前のリリースでは、移行プロセスを開始する前にすべての移行ユーザの URI を変更しなければなりませんでした。 このリリースでは、バッチを移行する直前にユーザの各バッチの URI を変更できます。

各バッチを移行する直前に Microsoft サーバ SIP URI を変更する場合は、Microsoft Server ユーザの各バッチを移行する前に、IM and Presence サービスの連絡先リストを更新し、移行しようとしている Microsoft サーバ ユーザの最新の SIP URI (接続 ID)を含めることを保障しなければなりません。 次の例について考えてみます。

移行例

John Smith、Bob Jones は、Lync のユーザで、互いの連絡先リストの両方に表示されます。 Lync URI は、john.smith@example.com と bob.jones@example.com です。 John は移行のフェーズ 1 中に IM and Presence サービスに移行され、Bob は移行のフェーズ 2 中に移行されます。

図 1. マイグレーション前

ユーザの移行フェーズ 1 が始まり、John の Lync URI は jsmith@example.com に変更されます。 それから、John が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。

図 2. ユーザの移行フェーズ 1



ユーザの移行フェーズ 2 が始まり、Bob の Lync URI は bjones@example.com に変更されます。 IM and Presence サービスの John のコンタクト リストはフェーズ 2 に移行されるユーザすべてとの新しい接続 ID で更新されます。 それから、Bob が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。

図 3. ユーザの移行フェーズ 2



Microsoft Server SIP URI の変更

どのLync/OCS URI も IM and Presence サービス サービス URI 形式に一致しない場合、移行プロセスを開始する前に Microsoft サーバ URI を変更する必要があります。 Microsoft サーバ URI を変更する方法の詳細については、ユーザ移行の Microsoft サーバの SIP URI 形式の確認に関するトピックを参照してください。

IM and Presence サービス ユーザの連絡先の名前変更

IM and Presence サービス一括管理ツールを使用すると、IM and Presence サービスのユーザの連絡先リスト内の連絡先 ID の名前を段階的に変更できます。 これは、IM and Presence サービス連絡先リストを、Lync/OCSURI が変更される度に更新できることを意味しています。


(注)  


IM and Presence サービス連絡先リストを更新する必要がある場合、この更新は、(変更された URI を持つ)Microsoft サーバ ユーザが Cisco Unified Communications Manager 上で IM and Presence サービスに対して有効にされる前に実行する必要があります。


詳細は、連絡先 ID の名前変更に関するトピックを参照してください。

詳細なユーザ移行計画

IM and Presence サービスおよび Lync/OCS 間のパーティション イントラドメイン フェデレーション統合は、Microsoft サーバから IM and Presence サービスへの段階的移行中にユーザ間で基本的な通信を実現するよう設計されています。

ただし、パーティション イントラドメイン フェデレーション統合により、パフォーマンス上のオーバーヘッドが発生します。 このため、IM and Presence サービスは、サーバあたり最大 130,000 件の SIP ドメイン内フェデレーションの連絡先をサポートします。 Microsoft サーバから IM and Presence へのユーザ移行中に IM and Presence サービス ノード上でこのフェデレーションされた連絡先のしきい値を超えないようにするため、詳細な移行計画が必要な場合があります。

次の計算式を使用して、上記のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を見積もることができます。

最大対応ユーザ = 130,000/連絡先リストの平均サイズ

この計算式に基づいて、次の表は 130,000 件のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を示しています。

表 1 IM and Presence サービスの最大対応ユーザ数

連絡先リストの平均サイズ

最大対応ユーザ(高可用性なし)

最大対応ユーザ(高可用性あり1

200

650

325

150

866

433

100

1300

650

75

1733

866

50

2600

1300

25

5000

2500

1 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。

ご使用の展開内の IM and Presence サービス ノードでプロビジョニングされるユーザ数が該当の上限値を超える場合、詳細なユーザ移行計画が必要です。 シスコのサポート担当者に連絡し、詳細な移行計画の定義を始めてください。

注意事項

  1. 上記の表にある最大対応ユーザ数の値は、最悪の場合の数字、つまりすべての連絡先がフェデレーションされている場合に基づいています。

    適切な移行計画により、130,000 件のフェデレーションされた連絡先のしきい値を超えずに、最大数のユーザを IM and Presence サービス ノードに段階的に展開できます。

  2. 高可用性が有効な場合、各 IM and Presence サービス ノードは、IM and Presence サービス 2 ノード サブクラスタ内のすべてのユーザに関連した負荷を処理できなければなりません。 そのため、ノードごとの制限は半分にする必要があります。

  3. ご使用の Microsoft サーバ展開内の連絡先リスト平均サイズがわからない場合、移行計画が必要かどうか判断する際に最悪のケース(200 件の連絡先)を想定します。

  4. 上記の表にある最大対応ユーザ数の値は、5000 ユーザの IM and Presence サービス OVA テンプレートに基づくシスコ対応仮想プラットフォームを想定しています。 1000 ユーザの OVA に対する同等の数字を次に詳しく説明します。

1000 ユーザ OVA

IM and Presence サービスは 1000 ユーザの OVA でノードあたり最大 18,000 の SIP イントラドメイン フェデレーション接続をサポートできます。 次の表は、18,000 件のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を示しています。
表 2 1000 ユーザ OVA のある、サポートされている IM and Presence サービス ユーザの最大数

連絡先リストの平均サイズ

最大対応ユーザ(ハイ アベイラビリティなし)

最大対応ユーザ(ハイ アベイラビリティあり2)

200

90

45

150

120

60

100

180

90

75

240

120

50

360

180

25

720

360

18

1000

500

2 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。

5000 ユーザ OVA

IM and Presence サービスは 5000 ユーザの OVA でノードあたり最大 90,000 の SIP イントラドメイン フェデレーション接続をサポートできます。 次の表は、90,000 件のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を示しています。

表 3 5000 ユーザの OVA を持つサポートされている IM and Presence サービス ユーザの最大数

連絡先リストの平均サイズ

最大対応ユーザ(ハイ アベイラビリティなし)

最大対応ユーザ(ハイ アベイラビリティあり3)

200

450

225

150

600

300

100

900

450

75

1200

600

50

1800

900

25

3600

1800

18

5000

2500

3 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。

ユーザ移行ツールの時間に関するガイドライン

シスコは、Lync/OCS から IM and Presence サービスへユーザを一括して移行できる多数のツールを提供しています。 移行計画を立てるには、多数のユーザを移行している場合に、各ツールが実行するのに必要な時間を知っておくことが重要です。 ここでは、次に示すツールごとの予想実行時間について説明します。


(注)  


Lync および OCS サーバ両方の混合配置がある場合、Lync ユーザに対してツールを実行し、次に OCS ユーザ対して再びツールを実行する必要があります。


連絡先リスト エクスポート ツール

連絡先リスト エクスポート ツール(ExportContacts.exe)は、平均毎秒 800 件の連絡先(つまり、毎分 48,000 件の連絡先)の速度で Lync/OCS から連絡先をエクスポートできます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。

連絡先のエクスポート時間(分)= Microsoft サーバ ユーザ数 x 連絡先リスト平均サイズ/48000

次の表は、多数のサンプル ケースの予想実行時間を示しています。

表 4 連絡先リスト エクスポート ツールの予想実行時間サンプル

Microsoft サーバ ユーザ数

連絡先リストの平均サイズ

連絡先エクスポート時間

2000

100

5 分

5000

75

8 分

15000

60

19 分

アカウント無効化ツール

アカウント無効化ツール(DisableAccount.exe)は、平均毎秒 13 アカウント(毎分 800 アカウント)の速度で Lync/OCS アカウントを無効にできます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。

アカウントを無効にする時間(分)= Microsoft サーバ ユーザ数/800

次の表は、多数のサンプル ケースの予想実行時間を示しています。

表 5 アカウント無効化ツールの予想実行時間サンプル

Microsoft サーバ ユーザ数

アカウントを無効にする時間

2000

3 分

5000

7 分

15000

20 分

アカウント削除ツール

アカウント削除ツール(DeleteAccount.exe)は、平均毎秒 13 アカウント(毎分 800 アカウント)の速度で Lync/OCS アカウントを削除できます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。

アカウントを削除する時間(分)= Microsoft サーバ ユーザ数/800

次の表は、多数のサンプル ケースの予想実行時間を示しています。

表 6 アカウント削除ツールの予想実行時間サンプル

Microsoft サーバ ユーザ数

アカウントを削除する時間

2000

3 分

5000

7 分

15000

20 分

一括管理ツールの連絡先リストのインポート

IM and Presence 一括管理ツール(BAT)は、IM and Presence サービス プラットフォームに応じて、さまざまな速度で連絡先をインポートできます。 次の表は、選択した IM and Presence サービス プラットフォームの予想インポート速度を示しています。

表 7 仮想マシン上の IM and Presence サービス BAT のインポート速度

OVA テンプレート

インポート速度

2000 ユーザ OVA

6 秒

5000 ユーザ OVA

12 秒

15000 ユーザ OVA

22 秒

次の表は、多数のサンプル ケースの予想実行時間を示しています。

表 8 BAT Contact List Import ユーティリティの予想実行時間サンプル

ユーザ数

連絡先リストの平均サイズ

インポート時間(速度 = 22 秒)4

2000

100

2 時間 32 分

5000

75

4 時間 45 分

15000

60

11 時間 22 分

4 これらの数字は、22/秒の連絡先のインポート速度をサポートする最高使用のマシンに適用されます。

注意事項

  1. 連絡先リスト エクスポート ツール、アカウント無効化ツール、およびアカウント削除ツールの計算式は、2Ghz 以上の CPU 処理能力、および 2GB の RAM を備えたハードウェアで実行する Lync/OCS および Active Directory(AD)に基づいています。

  2. これらのユーザ移行ツールを実行しても、Microsoft Lync またはMicrosoft Office Communicator にサインインしている他の Microsoft サーバ ユーザ機能への影響はありません。

  3. あらかじめスケジュールされたメンテナンスの時間帯にユーザ移行を実行して Microsoft サーバおよび AD システムの負荷を減らすことをお勧めします。

一括管理ツールの連絡先の名前変更

一括管理ツールの連絡先の名前変更ユーティリティ期間のレートは、2 つの主要な要因によって影響されます。

  • クラスタ内の、連絡先リスト内で名前の変更された連絡先 ID を持つユーザの数

  • そのようなユーザごとに名前が変更された連絡先 ID の平均数

これらの要因は、各展開ごとに異なります。 大規模な操作(1000 以上の連絡先 ID の名前が変更されている)の場合、このジョブが完了するまで数時間かかる場合があります。 考えられるジョブの完了率を推測するには、ジョブ進行インジケータを表示して、影響を受けるユーザが更新されるレートを確認してください。