この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
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 サービスドメインを次のように結合して構成されます。
ユーザが 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 が始まり、John の Lync URI は jsmith@example.com に変更されます。 それから、John が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。
ユーザの移行フェーズ 2 が始まり、Bob の Lync URI は bjones@example.com に変更されます。 IM and Presence サービスの John のコンタクト リストはフェーズ 2 に移行されるユーザすべてとの新しい接続 ID で更新されます。 それから、Bob が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。
どのLync/OCS URI も IM and Presence サービス サービス URI 形式に一致しない場合、移行プロセスを開始する前に Microsoft サーバ URI を変更する必要があります。 Microsoft サーバ URI を変更する方法の詳細については、ユーザ移行の Microsoft サーバの SIP URI 形式の確認に関するトピックを参照してください。
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 サービス ノードでプロビジョニングされるユーザ数が該当の上限値を超える場合、詳細なユーザ移行計画が必要です。 シスコのサポート担当者に連絡し、詳細な移行計画の定義を始めてください。
上記の表にある最大対応ユーザ数の値は、最悪の場合の数字、つまりすべての連絡先がフェデレーションされている場合に基づいています。
適切な移行計画により、130,000 件のフェデレーションされた連絡先のしきい値を超えずに、最大数のユーザを IM and Presence サービス ノードに段階的に展開できます。
高可用性が有効な場合、各 IM and Presence サービス ノードは、IM and Presence サービス 2 ノード サブクラスタ内のすべてのユーザに関連した負荷を処理できなければなりません。 そのため、ノードごとの制限は半分にする必要があります。
ご使用の Microsoft サーバ展開内の連絡先リスト平均サイズがわからない場合、移行計画が必要かどうか判断する際に最悪のケース(200 件の連絡先)を想定します。
上記の表にある最大対応ユーザ数の値は、5000 ユーザの IM and Presence サービス OVA テンプレートに基づくシスコ対応仮想プラットフォームを想定しています。 1000 ユーザの OVA に対する同等の数字を次に詳しく説明します。
最大対応ユーザ(ハイ アベイラビリティあり2) |
||
---|---|---|
IM and Presence サービスは 5000 ユーザの OVA でノードあたり最大 90,000 の SIP イントラドメイン フェデレーション接続をサポートできます。 次の表は、90,000 件のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を示しています。
最大対応ユーザ(ハイ アベイラビリティあり3) |
||
---|---|---|
シスコは、Lync/OCS から IM and Presence サービスへユーザを一括して移行できる多数のツールを提供しています。 移行計画を立てるには、多数のユーザを移行している場合に、各ツールが実行するのに必要な時間を知っておくことが重要です。 ここでは、次に示すツールごとの予想実行時間について説明します。
(注) |
Lync および OCS サーバ両方の混合配置がある場合、Lync ユーザに対してツールを実行し、次に OCS ユーザ対して再びツールを実行する必要があります。 |
連絡先リスト エクスポート ツール(ExportContacts.exe)は、平均毎秒 800 件の連絡先(つまり、毎分 48,000 件の連絡先)の速度で Lync/OCS から連絡先をエクスポートできます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。
連絡先のエクスポート時間(分)= Microsoft サーバ ユーザ数 x 連絡先リスト平均サイズ/48000
次の表は、多数のサンプル ケースの予想実行時間を示しています。
アカウント無効化ツール(DisableAccount.exe)は、平均毎秒 13 アカウント(毎分 800 アカウント)の速度で Lync/OCS アカウントを無効にできます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。
アカウントを無効にする時間(分)= Microsoft サーバ ユーザ数/800
次の表は、多数のサンプル ケースの予想実行時間を示しています。
アカウント削除ツール(DeleteAccount.exe)は、平均毎秒 13 アカウント(毎分 800 アカウント)の速度で Lync/OCS アカウントを削除できます。 次に示す等式をガイドとして使用し、Microsoft サーバ ユーザのセットに対するこのツールの予想実行時間を見積もることができます。
アカウントを削除する時間(分)= Microsoft サーバ ユーザ数/800
次の表は、多数のサンプル ケースの予想実行時間を示しています。
IM and Presence 一括管理ツール(BAT)は、IM and Presence サービス プラットフォームに応じて、さまざまな速度で連絡先をインポートできます。 次の表は、選択した IM and Presence サービス プラットフォームの予想インポート速度を示しています。
OVA テンプレート |
インポート速度 |
---|---|
2000 ユーザ OVA |
6 秒 |
5000 ユーザ OVA |
12 秒 |
15000 ユーザ OVA |
22 秒 |
次の表は、多数のサンプル ケースの予想実行時間を示しています。
インポート時間(速度 = 22 秒)4) |
||
---|---|---|
連絡先リスト エクスポート ツール、アカウント無効化ツール、およびアカウント削除ツールの計算式は、2Ghz 以上の CPU 処理能力、および 2GB の RAM を備えたハードウェアで実行する Lync/OCS および Active Directory(AD)に基づいています。
これらのユーザ移行ツールを実行しても、Microsoft Lync または Microsoft Office Communicator にサインインしている他の Microsoft サーバ ユーザ機能への影響はありません。
あらかじめスケジュールされたメンテナンスの時間帯にユーザ移行を実行して Microsoft サーバおよび AD システムの負荷を減らすことをお勧めします。
一括管理ツールの連絡先の名前変更ユーティリティ期間のレートは、2 つの主要な要因によって影響されます。
これらの要因は、各展開ごとに異なります。 大規模な操作(1000 以上の連絡先 ID の名前が変更されている)の場合、このジョブが完了するまで数時間かかる場合があります。 考えられるジョブの完了率を推測するには、ジョブ進行インジケータを表示して、影響を受けるユーザが更新されるレートを確認してください。
目次
移行中のユーザ 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 サービスドメインを次のように結合して構成されます。
ユーザが 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 が始まり、John の Lync URI は jsmith@example.com に変更されます。 それから、John が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。
ユーザの移行フェーズ 2 が始まり、Bob の Lync URI は bjones@example.com に変更されます。 IM and Presence サービスの John のコンタクト リストはフェーズ 2 に移行されるユーザすべてとの新しい接続 ID で更新されます。 それから、Bob が IM and Presence サービスに移動されます。 John と Bob 間の可用性と IM は保持されます。
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)
1 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。ご使用の展開内の IM and Presence サービス ノードでプロビジョニングされるユーザ数が該当の上限値を超える場合、詳細なユーザ移行計画が必要です。 シスコのサポート担当者に連絡し、詳細な移行計画の定義を始めてください。
注意事項
上記の表にある最大対応ユーザ数の値は、最悪の場合の数字、つまりすべての連絡先がフェデレーションされている場合に基づいています。
適切な移行計画により、130,000 件のフェデレーションされた連絡先のしきい値を超えずに、最大数のユーザを IM and Presence サービス ノードに段階的に展開できます。
高可用性が有効な場合、各 IM and Presence サービス ノードは、IM and Presence サービス 2 ノード サブクラスタ内のすべてのユーザに関連した負荷を処理できなければなりません。 そのため、ノードごとの制限は半分にする必要があります。
ご使用の Microsoft サーバ展開内の連絡先リスト平均サイズがわからない場合、移行計画が必要かどうか判断する際に最悪のケース(200 件の連絡先)を想定します。
上記の表にある最大対応ユーザ数の値は、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)
2 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。5000 ユーザ OVA
IM and Presence サービスは 5000 ユーザの OVA でノードあたり最大 90,000 の SIP イントラドメイン フェデレーション接続をサポートできます。 次の表は、90,000 件のフェデレーションされた連絡先のしきい値を超えずにサポートできる、IM and Presence サービス ユーザの最大数を示しています。
表 3 5000 ユーザの OVA を持つサポートされている IM and Presence サービス ユーザの最大数 最大対応ユーザ(ハイ アベイラビリティあり3)
3 これは、アクティブ/アクティブ モードで動作している 2 ノード サブクラスタを想定しています。ユーザ移行ツールの時間に関するガイドライン
連絡先リスト エクスポート ツール
アカウント無効化ツール
アカウント削除ツール
一括管理ツールの連絡先リストのインポート
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)
4 これらの数字は、22/秒の連絡先のインポート速度をサポートする最高使用のマシンに適用されます。注意事項
連絡先リスト エクスポート ツール、アカウント無効化ツール、およびアカウント削除ツールの計算式は、2Ghz 以上の CPU 処理能力、および 2GB の RAM を備えたハードウェアで実行する Lync/OCS および Active Directory(AD)に基づいています。
これらのユーザ移行ツールを実行しても、Microsoft Lync または Microsoft Office Communicator にサインインしている他の Microsoft サーバ ユーザ機能への影響はありません。
あらかじめスケジュールされたメンテナンスの時間帯にユーザ移行を実行して Microsoft サーバおよび AD システムの負荷を減らすことをお勧めします。