この記事の内容
スコープ
dropdown icon
はじめに
    自信から計画へ: このガイドの構成
プロジェクトの開始
発見と評価
dropdown icon
計画と実装
    専用インスタンスを有効にする(初回のセットアップウィザード)
    DI環境の構築(専用インスタンスのプロビジョニング)
    専用インスタンスへのアクセス:
    ピアリング/接続
    Webex バーチャルコネクト
    専用インスタンスのネットワークとセキュリティ要件(ネットワーク、 ファイアウォールポート、DNS情報のソース)
    ESN(生存能力の強化)
    ディレクトリ同期サービス
    SSO
    専用インスタンスクラスターとオンプレミスクラスターの統合
    証明書の統合
    Webex アプリや Jabber の移行計画
    E911
    エンジニアリングチームとユーザーの変化への備え
フリーズします
カットオーバー日または稼働開始
2日目

Webex Calling-専用インスタンスへの準備と移行プロセスのベストプラクティス

list-menuこの記事の内容
list-menuフィードバックがある場合

Webex Calling-Dedicated Instanceへの移行は、業務の効率化を目的として設計された包括的で7段階の移行フレームワークで進んでください。

スコープ

この記事では、通話環境を専用インスタンス(DI) Webex Callingに移行するパートナーや顧客向けに、構造化されたセルフサービス移行フレームワークを提供します。

この記事で説明されている移行手法とマイルストーンは、Webex Setup Assistプログラムの方法論に基づいており、シスコの提供、エンジニアリング、 開発チームの広範な実務経験を反映しています。 これらの方法は、BroadCloud、BroadWorks、Spark Calling、Unified CM(UCM)、ホステッドコラボレーションソリューション (HCS)、 サードパーティのPBXプラットフォームからの移行など、 過去7年間に何十万件もの独自の顧客ロケーション展開を通じて改良されてきました。 このガイダンスは、シングルシートでの導入から、 100,000シート、数百か所を超える大規模な導入まで、 幅広い顧客環境に適用され、移行ライフサイクル全体を通じて一貫性、品質、 運用効率を確保するために、長年確立されて実績のあるシスコのプロセスに従います。

この記事は、読者が専用インスタンスライセンス、Webex Control Hub 管理モデル、Webex Callingベースラインのユニファイドコミュニケーションマネージャーのソフトウェアと機能に精通していることを前提としています。

はじめに

正直に言うと、移行という言葉がITチームを興奮させることはめったにありません。 疑問がわいてきます。 「何が壊れますか?」「誰が仕事をしますか?」「私たちは何をコントロールできなくなりますか?」「明かりをつけたまま体を伸ばしているのに、 これは現実的ですか?」 これらは進歩への抵抗の兆候ではありません。 ミッションクリティカルな通話プラットフォームの移行は週末のプロジェクトではないことを理解している経験豊富な専門家の本能です。 音声は、 ユーザーが2週間の停電計画作業に気付く前に2秒の不具合に気付く唯一のサービスです。 そして、その現実では、すべての変更が必要以上に重いと感じます。

良いニュースは? 数字は恐怖とはまったく異なる物語を語ります。 適切に構成されたクラウド移行では、エンジニアリング作業の約 95% が準備に費やされ、 実際の変更にはわずか5%が費やされます。 さらに良いことに、その 95% のほとんどは、インベントリの衛生、 証明書管理、ダイヤルプランのレビュー、デバイスのライフサイクルの追跡、文書化など、 チームが2日目の通常の業務の一環としてすでに実行しているアクティビティで構成されています。 言い換えれば、 「移行作業」の大部分は、あなたがすでに行っている作業です。 この構造化されたアプローチは、 単に既存の業務リズムの上ではなく、それに合ったペースで、明確な結果に向けて導くだけです。

すべての移行を完全にリハーサルできることがわかると、「ミッション・インポッシブル」という感覚も薄れます。 小規模で代表的なパイロットでは、1人のプロダクションユーザーに触れる前に、エンドツーエンドのプロセス、 統合、フェイルオーバー動作、ユーザーエクスペリエンスを検証できます。 カットオーバー日は、 すでに正常に実行したプロセスを繰り返すだけなので、カットオーバー日には何も成り立ちません。 また、 予期しないことが起こった場合、ロールバックはカットオーバー自体を反映したものであり、明確なメンテナンス期間を設けています。 予測可能性は不安に取って代わります。

はい、専用インスタンスに移行するということは、 特にインフラストラクチャと仮想化レイヤーに対する制御をある程度手放すことを意味します。 しかし、 チームがハイパーバイザーへのパッチ適用、ハードウェアアラートの追跡、OSレベルのセキュリティの管理、容量更新の計画に費やす時間など、何が得られるかを考えてみてください。 その時間はビジネスに戻り、 組織を実際に差別化するもの、つまりユーザーエクスペリエンス、採用、統合、 利害関係者が本当に気にかけているサービスに費やすことができます。 コントロールを失っているわけではありません。 差別化されていない重労働を戦略的焦点と交換しているのです。

引き換えに受け取るのは、シスコのエンジニアリングの深みと、数十万件の導入を通じて磨き上げられたパートナーエコシステムに支えられた、市場で最も先進的な通話、 会議、 コンタクトセンターのポートフォリオと緊密に統合されたプラットフォームです。 Unified CM使い慣れたエコシステムの全機能、つまりチームがすでに知っている同じ機能、同じ信頼性、 同じ管理モデルを維持できます。Control Hubは、習得が簡単で最新のユーザー指向の管理と分析の傘下であるControl Hubと組み合わせています。 最新のソフトウェアのアップグレード、更新、および重大な脆弱性のパッチは、 シスコ認定のコンピューティング上でシスコが管理し、 オンプレミス環境に期待するのと同じ(またはそれ以上)の信頼性を実現します。

そう、はい、変化にはリスクが伴います。 しかし、変更しないことには、それ自体の、より静かなリスクが伴います。 機能に遅れをとったり、絶え間なく複雑化する変更への対応、 リリースのアップグレードや脆弱性への対応、 ビジネスを差別化しなくなったインフラストラクチャでチームを圧迫したり、避けられない移行をプレッシャーの下で完了しなければならないまで延期したりします。 以下の構造化された、ゲート型のアプローチは、この移行を本来あるべき姿にするために設計されています。つまり、 準備が整い、ドラマが少なく、検証済みで、主に、 あなたがすでに行っている作業を通じて、次にコラボレーションが向かう方向に向けて構築されたプラットフォームに向けて実行されます。

自信から計画へ: このガイドの構成

その確信を実行可能なロードマップに変えるために、このガイドでは、 7つの段階に分かれた移行プロセスを順を追って説明します。各フェーズでは、 明確な開始基準と終了基準、現場から学んだ教訓、よくある不測の事態を防ぐための事前チェックを行います。

  • プロジェクトの開始
  • 発見と評価
  • 計画中
  • 実装
  • フリーズします
  • ライブに行く
  • 2日目に転送

このモデルが非常にうまく機能する理由の1つは、 生産環境へのリスクが意図的にゼロ近くまで前倒しされ、制御された最終段階でのみ上昇するということです。 各段階で期待できることは次のとおりです。

生産への影響 フェーズ
影響はありません プロジェクトの開始、発見と評価、計画
影響は最小限です 実装
運用プロセスに限られます フリーズします
直接的な影響 ライブに行く
key phases of a Webex Dedicated Instance migration project, ranging from project initiation to project closure.

実用的に言えば、 旅のほとんどは既存の環境と一緒に安全に行われます。 本番環境に入る頃には、 すべての統合が構築され、すべてのプロセスがリハーサルされ、すべてのフォールバックが検証されています。

ガイド全体を通して、 移行中や2日目にかけて頼りになる重要な情報リソースを参照しています。

  • シスココーリングセールスコネクト — シスココーリングセールスコネクトリンク
  • help.webex.com — 信頼できる製品および設定文書
  • Webex Spaces — シスコの専門家や同僚コミュニティに直接アクセスして、リアルタイムで質問できます

フレームワークと手元にあるリソースが整ったら、 各フェーズを詳しく見ていきましょう。まず、移行が成功するたびに始まる段階である「 プロジェクトの開始」から始めましょう。

プロジェクトの開始

生産への影響:影響なし

  • 主要な利害関係者を特定してください

技術チームや影響を受けるビジネスチームだけでなく、 関係するパートナーも関係していることを忘れないでください。必要な利害関係者の例は次のとおりです。

  • IT管理
  • ビジネス管理
  • 音声サービスチーム
  • コンタクトセンターチーム
  • ネットワークチーム
  • DNS/DHCP チーム
  • セキュリティチーム
  • IAMチーム(例:エントラ、AD、SSO)
  • チェンジボード
  • MACD パートナー
  • マネージドサービスパートナー
  • サードパーティの統合ベンダー(ページング、ファックス、レコーディングなど)
  • ローカル、オンプレミスのサポート
  • レッドスカイ/公共安全チーム。

  • プロジェクトリーダーまたはプロジェクトマネージャーの選択。

専用インスタンスへの移行には、 従来の「アプリケーションレベルのみ」の統合よりも複雑な調整が必要であることを考えると、内部のプロジェクト管理と、毎週の電話、内部チームの調整、外部ベンダーの関与、 変更の調整などのすべての関連タスクを担当するチームメンバーを割り当てることが望ましいです。

  • プロジェクトを開始したときの入力を同期します

ハードウェア専有インスタンスへの移行戦略が取られているのには、複数の利点と理由があります。 将来の解決策についての基本的なビジョンを作ることが重要です。

クラスターの統合、ダイヤルプラン、予定されている新機能などの変更はありますか?

ソフトウェアエンドポイントを「そのまま」移行しますか、それともWebex アプリへの移行を前提としていますか?

ユーザーとコンタクトセンターの関係はどうですか?

  • 専用インスタンスでスピードを上げましょう

専用インスタンスの紹介:専用インスタンスの紹介

BDM(ビジネス意思決定者用スライド)BDM

TDM(テクニカル・ディシジョンメーカー・スライド)TDM。

発見と評価

生産への影響:影響なし

発見と評価は、 専門的なプロジェクトや技術的なプロジェクト計画立案の基礎となる、 必要なスコープ要素をすべて特定することを目的として、 インプットに関する前回のチーム同期会議で得られた情報を継続して活用することです。

  • 既存のクラスターセットアップ

すべての機能と統合が完了した状態で、既存のオンプレミス設定を定義します。 見るべき例は次のとおりです:

  • 用途とサイズ、
  • 場所、
  • IPアドレス、
  • ユーザーの同期/プロビジョニング方法(ローカル、LDAP)、
  • 認証が設定されました(SSO)、
  • CA証明書と自己署名証明書、
  • セキュリティモード、
  • ILS/GDPRの使用、
  • 特徴、
  • Extension Mobility次のようなクロスサイト機能に特に重点を置いています。
  • CER/911インテグレーション、
  • MRAの使用、
  • CDR、
  • ボイスメールとO365との統合、
  • ジャバー対ウェベックスアプリ
    • Jabberを移行する場合、 既存のJabberエンドポイントの設定方法(xml設定、音声サービスドメインなど)と、 SCCMの使用などの再構成のオプションに注目する必要があります。 標準的なシナリオは次のとおりです。Jabberの設定
  • チェックしたいフォーカスのあるデバイスのリスト
    • 非推奨デバイス(Rel12.0x以降、非推奨リストに追加された新しいデバイスはありません)非推奨の電話
    • サポート終了デバイス(デバイスはどのソフトウェアリリースにも登録できますが、 2日目からはサポートされません)
    • CSR-Compatibility-Matrix-Interactive.html
    • 特別な制限デバイス 7925、7940、7960 古い電話機モデルを専用インスタンスに登録します
      • ヘルプのツール:

        専用インスタンスの移行前アシスタント:評価レポートを生成する

        Control Hubの移行前アシスタントは、ソースデータを収集し、サードパーティツールを使用してUCMからDedicated Instanceに移行するための前提条件を確認するのに役立ちます。 移行前に、準備状況を評価し、チェックリストを提供し、 オンプレミスクラスターと専用インスタンスのデータを比較できるようにします。

        アシスタントを実行するには、 オンプレミスクラスタをWebex CloudConnected UC環境にオンボーディングする必要があります。 全体的な説明と前提条件は、こちらで確認できます :Webexクラウド接続UC

        UCMのオンボーディングプロセス:Webex クラウドコネクテッドUCのセットアップ

        移行前アシスタントから読みやすいxls形式の出力として得られる重要な洞察のリスト:

        • ノードと実行中のソフトウェア
        • エンタープライズパラメーター
        • SIPトランクのリスト
        • アプリケーションのユーザー、役割のリスト
        • デバイスの数(およびデバイスの全リスト)、ルートグループとパーティション、 場所、エンドユーザー
        • CMグループ、デバイスプール
        • DBレプリケーションのヘルスステータス
        • COPをインストールしました
        • 番号計画
        • 電話サービス
        • 遠隔地の目的地
      • あなたの特定の質問に答えるためのWebex Spacesです:

        UCMクラウドと専用インスタンスに聞いてください: webexteams://im?スペース=5db6bb40-d3c7-11e9-a319-df8a35abe85a

        RedSky Externalに聞いてください-E911ソリューションプラスパートナー参加してください:https://eurl.io/#fWfT1SnOz

        Webex セットアップアシストに聞いてください-Webex Calling そして DI: webexteams: //im?スペース=76beab50-084b-11ed-abc8-ab581010b1de。

計画と実装

生産への影響:既存の生産環境への影響を最小限に抑えます

ハードウェア専有インスタンスの移行プロセスに関するシスコのベストプラクティスを以下に示します。

A flowchart detailing the migration process for a Webex Dedicated Instance, covering initial setup, configuration, and iterative cutover waves.

専用インスタンスを有効にする(初回のセットアップウィザード)

専用インスタンスを有効にするには、「専用インスタンスを有効にする」を参照してください。

DI環境の構築(専用インスタンスのプロビジョニング)

DI環境を構築するには、Webex Calling 基本構成については専用インスタンスを参照してください

最も一般的な質問、メモ:

  • ビルドのサイズについてはこちらで説明しています(専用インスタンスのサイジング): https://help.webex.com/en-us/article/dk3o5r/Introduction-to-Dedicated-Instance クラスターの数と一般的なサイズは、購入したライセンスの数と同じです。 一般的なサイズでは、フレックス契約に基づく予備金の増加(15% または 20% はタイプによって異なります )と、ナレッジワーカー1人あたりのアクティブデバイス3台の提供)に対応しています。Cisco Cloud プラットフォーム認定を受けたクラス最高のコンピューティング。すべてのビルドで中規模のOVAを使用し、 完全に導入された専用インスタンスクラスタは、 最大8台のコール処理サーバーまたは約50,000台のデバイスをサポートできます。
  • SMEはオプションです。クラスターやリージョンを3つ以上購入する必要があります。 シスコ側からの設計と容量の見直しが必要です
  • 最初のMRA容量は20%ですが、 TACチケットで実際のニーズに応じて最大100%まで増やすことができます
  • 名前の前に「x」が付いている構成要素は、自動化、サービスビリティ、 分析の統合で使用されるように、基本構成用の専用インスタンスの名前を変更しないでください Webex Calling
  • 1つのリージョンに3つ以上のクラスターが必要な場合は、 DIインスタンスの標準IPアドレスはオプションではありません

参照。標準IPアドレス、データセンターの場所:データセンターの場所。

専用インスタンスへのアクセス:

専用インスタンスアプリケーションにアクセスするには、「専用インスタンスアプリケーションへのアクセス」を参照してください

最も一般的な質問、メモ:

  • DIアプリケーションには、コントロールハブから、またはお客様のネットワークから直接アクセスできます。 高速道路を除いてCLIアクセスも提供されています。
  • ユーザーランク:
    • 3-パートナー管理者
    • 4 — 顧客管理者
    • 5 — エンタープライズユーザー
  • 自動化によって作成されたWebexスペース(ProAdmin)で共有されているDIアプリケーションにアクセスするための認証情報。

ピアリング/接続

Webex Calling 専用インスタンスと会議のエッジ接続シナリオの詳細な説明を含むネットワークアーキテクチャ。PA_Edge_Connect_Design.pdf

*ドキュメントは慎重に使用する必要があります。正確なユースケースにもよりますが、 互いに矛盾したり補完したりする可能性のある複数のシナリオを説明しています。 専用インスタンスへの正確な参照は、「 専用インスタンスアーキテクチャのエッジコネクト」の章にあります。

Webex Edge接続します

Webex Edge 最も一般的な質問を接続してください、メモ:

  • 専用インスタンス2のリンクは「必須」
  • 4つのリンクはオプションですが、「クロッシング」はできません。これらは 「ペア」で使用されます
  • いずれかのリンクへのDIトラフィックの優先順位付けはサポートされておらず、 一般的には適用されません。これは、 各側/DCが独自のサブネット/25Dedicated Instanceデータセンターの場所を通知しているためです。
これは、 前述のネットワークアーキテクチャ文書でも以下のように説明されています。 A network architecture diagram illustrating the connectivity between a customer network and the Webex backbone via a cloud exchange provider, featuring primary and secondary routing paths.

Webex バーチャルコネクト

Webex Virtual Connectについて知るには、専用インスタンス-仮想接続を参照してください

最も一般的な質問、メモ:

  • バーチャルコネクトでサポートされる最大帯域幅は250Mbpsです
  • このオプションは、ESNの導入には適していない/サポートされていません。

専用インスタンスのネットワークとセキュリティ要件(ネットワーク、 ファイアウォールポート、DNS情報のソース)

ネットワークとセキュリティの要件については、ネットワークとセキュリティの要件を参照してください

最も一般的な質問、メモ:

  • SNMPの監視は許可されていません。SNMPの例外は、 コントロールハブ経由のサービスリクエストが必要なCERとInformacastのワークフローです。
  • DIから外部SFTPへのアクセスはありません。アップデート、アップグレード、 その他のワークフローに使用されるSFTPはDI環境内にあり、アクセスは限られたシナリオ(Control Hubサービスリクエストに沿った新しいCOP/ファームウェアへのアクセスなど)でのみ提供されます。

ESN(生存能力の強化)

はじめに/ 一般情報:拡張生存性から始めましょう

前提条件:エンハンスト・サバイバビリティの前提条件

アクティベーション用:強化されたサバイバビリティを有効にしてください。

最も一般的な質問、メモ:

  • ESN Flex SKUは「地域ごと」ベースです。たとえば、 南北アメリカで5つのESNノードを統合する必要がある場合は、1つのESN SKUを注文する必要があります。これにより、 クラスターで許可される最大呼処理ノード数に影響を与えずに、1つのクラスターに最大8つのESNノードを接続できます
  • お客様は、必要な仮想化リソースをプロビジョニングし、Medium OVA Publisherをインストールする責任があります。Medium OVA Publisherは、 自動化によってさらにサブスクライバーに変換され、クラスターに接続されます。https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-unified-communications-manager.html
  • シスコはCA証明書に責任を負います。アクティベーションの過程で、 ESNノードをリストに含めるためにクラスターの証明書の更新/更新を許可するように求められます。

ディレクトリ同期サービス

オンプレミスのUCMでLDAP経由でユーザーを同期したり、 ローカルで作成したりする従来の方法に加えて、専用インスタンスでは、コントロールハブ(Webex Common Identity Service)を介してAzureまたはディレクトリコネクタ経由でユーザーを同期するオプションがあります。 Webex CIディレクトリサービスでは、 SSO導入のみがサポートされています。

専用インスタンスのWebex Common IDによるディレクトリサービスの統合

最も一般的な質問、メモ:

  • 特定のクラスターのAzure ADのプロビジョニングが完了すると、 新しい同期アグリーメントを作成したり、 グループ設定以外の同じクラスターの構成設定を変更したりすることはできません。 ディレクトリサービスをリセットするには、Cisco TACサポートに連絡してください。その後、プロビジョニング用の新しい契約を作成できます。
  • 新しい契約が作成されてから18時間以内に同期を有効にする必要があります。LDAPで同期されたユーザーは、24時間使用しないと非アクティブになり、削除されます。 Unified CMユーザーはログインしてサービスを利用できなくなります。
  • Call Managerの設定も編集可能のように見えます。 同期契約のプロビジョニング中に自動化によって作成された設定以外は変更しないでください。 設定では同期は1回と表示されていますが、Control Hubは24時間周期でCommon Identity Unified CM Cisco Unity Connection がまたはに変更されると同期します。
  • サービスはディレクトリ同期 (!) にのみ使用されます。認証は、 前提条件としてSSOを介して設定する必要があります。

SSO

SSOは専用インスタンスでは必須ではありません。 とにかく、Webex 共通アイデンティティ、Webex Appの使用などの一部の主要サービスでは必須です。 SAML SSOの導入は、 UCMオンプレミスの導入と変わりません。以下で説明します。 唯一の運用上の微妙な違いは、 アクティベーション中にSSOテストにランク1のユーザーを必要とするアクティベーションプロセスに関するものです。 パートナーと顧客はランク3〜5の権限に制限されているため、アクティベーションにはシスコのサポートが必要です。コントロールハブ(チケットのUCアプリケーション管理タイプ) のサービスリクエストでリクエストする必要があります

CUCM_b_saml-sso-deployment-guide-release-15.html

サービスリクエストを開くには、サービスリクエストの提出方法を参照してください。

専用インスタンスクラスターとオンプレミスクラスターの統合

ほとんどの移行シナリオは、一回限りの移行では実現できず、事前にテストする必要があり、 ある程度の相互統合が必要であることを考えると、 最初のステップの1つとしてクラスタ間トランクと関連する構成を設定することをお勧めします。 使用中の場合はILS。

証明書の統合

移行に向けてシステムを準備する上で最も重要なタスクの1つは、 オンプレミスとクラウドシステムの間で証明書を交換することです。これらはすべて安全な統合です。 これにより、 工場出荷時の状態にリセットしなくても、 電話機を新しいクラスターに自由に移動したり、古いクラスターに戻したりできます。

最も一般的な質問、メモ:

通常、これにはDIからの証明書を共有し、 オンプレミス側にアップロードすることが含まれます

  • コールマネージャー.pem (マルチサン)
  • ITLリカバリ。pem
  • CAの中級証明書
  • ルート証明書 CA

お客様のCUCM側からDIへ:

  • Callmanager.pem(マルチSAN)がマルチSANでない場合は、パブリッシャーとTFTPサーバーの証明書を含めてください。
  • ITLリカバリー。PEM(パブ)
  • CAの中間証明書(証明書がCAによって署名されている場合)
  • ルート証明書CA(証明書がCAによって署名されている場合)。

Webex アプリや Jabber の移行計画

最も一般的な質問、メモ:

JabberとWebexAppの相互通信の相互運用性 WebexアプリとJabberの相互運用性をセットアップします。

E911

専用インスタンスの導入では、Cisco Emergency Responder(CER) とRedSkyの両方が電話とクライアントの追跡に使用されます。 オンプレミスの電話は、 Emergency Responderを使用して電話の場所を特定し、 適切な発送場所を設定してからRedSkyに通話をルーティングして配信します。 Webexアプリのユーザーは、 HELD+プロトコルを使用してRedSkyで追跡されます。

専用インスタンスには、南北アメリカ地域に導入されたCERが付属しています。 シスコはプロキシ情報を追加しますが、パートナー/顧客の責任はRedSkyの詳細を追加し、 ELINを設定することです。 LUAスクリプトを追加し、 パートナー/顧客はそれを機能させるためにパラメータを設定する必要があります。最も一般的な質問、メモ

  • レッドスカイポータルでレッドスカイアカウントを取得する方法:
  • BOTはWebexで利用可能です — E911カスタマーアカウントの設定 (E911Account@webex.bot)「サポート」と入力し、表示されるフォームに記入して送信してください。 アカウントが作成され、 BOTに入力された管理者のメールアドレスにメールが送信されます
  • 専用インスタンス用にE911を設定し、E911を設定します

サポート中のWebex Spaces:

RedSky Externalに聞いてください-E911ソリューションプラスパートナー参加:https://eurl.io/#fWfT1SnOz。

エンジニアリングチームとユーザーの変化への備え

エンジニアリングチームが専用インスタンスのあらゆる側面を把握するための推奨リソースは次のとおりです。

フリーズします

生産への影響:影響は運用プロセスに限定されます

フリーズフェーズの目的は、 ソースシステムからターゲットの専用インスタンスにデータを移動し、カットオーバーを確実に成功させるために必要な検証を実行することです。 チームがデータ移動、 データ整合性チェック、テストフェールオーバー、および関連するテストに必要な時間を確保できるように、 凍結には2〜3週間の期間を設けることをお勧めします。

凍結段階でMACDが必要になった場合は、 両方のシステムで必要な変更を行う必要があります。

データの移動/コピーには複数の方法やツールがあります。 一般的には、 以下のようにアクティブ/非アクティブのパーティションとツールを使用することをお勧めします。

UCM:

BATのエクスポート/インポートと関連するスクリプト

リリース15とSUの一括管理ガイド:CUCM_b_bulk-administration-guide-15.html。Cisco Unified Communications Manager

YarnlabのようなUCM移行のための外部ツール。

ユニティ:

  • Cisco Unityツール。 Cisco UnityCisco Unity Connection 無料の関連ツールのコレクションです。

https://www.ciscounitytools.com/index.html

Unityの移行にはCobraの使用をお勧めします。

CER:

マニュアル、一括エクスポート/インポート

設定データを移動したら、次の重要な項目/アクションを検討してください。

  • さまざまな電話機モデルのテストグループを新しいDI TFTPに再ポイントする場合は、手動またはDHCPのオプション150を使用してください。 証明書の統合が完了したら、 移行とロールバックの両方のシナリオをテストできます
  • テストゲートウェイの再構成(可能な場合)
  • 実際の生産カットオーバーのためのゲートウェイ構成テンプレートの準備。 必要に応じて、スクリプトを書きます。
  • CHでの通話動作の変更によるWebexAppユーザーの移動
  • 定義済みのログイン方法とホームクラスタの変更によるJabberの移動
  • 基本的なコールフローと機能から環境機能までのテスト:
    • ネット上またはVPN経由で接続されているときの動作の一貫性のチェック
    • 電話とソフトウェアエンドポイントを使ったMRAのテスト
    • PSTN
    • 911サービスのテスト

カットオーバー日または稼働開始

すべてのカットオーバーはユニークで、計画は環境の微妙な違いに対応する必要があります。 一般的に言えば、プロセスのステップは次のとおりです。

  • プロアクティブなTACチケットを作成します(定期発送)
  • デバイスの切り替えは、関連するすべてのサブネットのオプション150の変更と、 オンプレミスのコールマネージャーでの電話のリセットによって行われます
  • 新しいシステムで登録された電話を確認することは、 新しい専用インスタンスシステムへの登録が成功するまでのプロセスを管理する簡単な方法です
  • 確認後、 オンプレミスと専用インスタンスで必要な構成(アクティブパーティションとヌルパーティションの場合の回線とルートのパターン、ホームクラスタ、広告)を一括更新します
  • ゲートウェイ、SRST、ハードウェアメディアの設定を変更してください
  • 定義したテストプログラムを実行してください:
    • サイト内、サイト間、PSTNコールのテスト
    • MRA
    • 911
    • ボイスメール
    • 該当する機能
割り当てられたメンテナンス期間を超えないように、移行/カットオーバーの手順にはロールバックのタイミングが必要です。 ロールバック自体は、 カットオーバーMOP自体と同様の簡単なプロセスです。 ロールバックでは、以前に実行したすべてのアクションを元に戻す必要があります

2日目

  • 記載されているトピックに関連するサービスリクエスト:サービスリクエストの提出方法
    • DNS エントリ
    • ファイアウォールの更新
    • ファームウェアのアップロード
    • クラウド接続
    • 監査ログ設定
    • UCアプリケーション管理
    • DI-MT インターオープ SIP トランク
    • UCアプリケーションのライフサイクル
    • サービスとしてのインフラストラクチャ
      • パートナー運営ガイド

これは、テクニカルサポート、 変更管理、インシデント管理、更新、アップグレード、容量管理、 証明書管理、DRSパートナー運用ガイドを説明する最も重要な文書の1つです

  • 責任マトリックス

この文書では、オンボーディング時にパートナー、シスコ、お客様の間でRACIが分割され、 運用責任の割り当てマトリックスが説明されています

  • レッドスカイ Webex Space webexteamsに聞いてください://私は?スペース=7074fce0-489a-11ea-89f3-8f977dd07aa0。
この投稿記事は役に立ちましたか?
この投稿記事は役に立ちましたか?