- Головна
- /
- Стаття
Найкращі практики в процесі підготовки та міграції до Webex Calling - Виділений екземпляр
Перейдіть до Webex Calling - Виділений екземпляр за допомогою всеосяжної системи міграції із семи дверцятами, розробленої для оперативної ефективності.
Сфера застосування
У цій статті наведено структуровану структуру міграції самообслуговування для партнерів та клієнтів, які мігрують середовище викликів у виділений екземп Webex Calling ляр (DI).
Практики та етапи міграції, описані в цій статті, базуються на методології програми Webex Setup Assist і відображають великий досвід роботи команд Cisco з доставки, інженерії та розробників у реальному світі. Ці методи були вдосконалені за допомогою сотень тисяч унікальних розгортань розташування клієнтів протягом останніх семи років, включаючи міграцію з платформ BroadCloud, BroadWorks, Spark Calling Unified CM (UCM), Hosted Collaboration Solution (HCS) та сторон ніх АТС. Ці вказівки застосовуються до широкого спектру клієнтських середовищ, від розгортання на одному місці до масштабних реалізацій, що перевищують 100 000 місць та сотні місць, і дотримуються давно встановлених, перевірених процесів Cisco для забезпечення послідовності, якості та ефективності роботи протягом усього життєвого циклу міграції.
У статті передбачається, що читачі вже знайомі з Webex Calling - ліцензуванням виділених екземплярів, адміністративною моделлю Webex Control Hub та базовим програмним забезпеченням та функціями Unified Communications Manager.
Вступ
Будемо чесними — слово мі грація рідко викликає хвилювання в ІТ-команді. Це викликає питання. «Що ламається?» «Хто виконує роботу?» «Над чим ми втрачаємо контроль?» «Це навіть реалістично, поки ми вже розтягнуті, тримаючи світло увімкненим?» Це не ознаки опору прогресу; це інстинкти досвідчених професіоналів, які розуміють, що переміщення критичної для місії платформи викликів - це не проект вихідного дня. Голос - це єдина послуга, де користувачі помічають двосекундний збій, перш ніж помітити двотижневі зусилля з планування відключень - і ця реальність змушує кожну зміну відчувати себе важчою, ніж слід.
Хороші новини? Цифри розповідають зовсім іншу історію, ніж страх. У добре структуро ваних хмарних міграціях приблизно 95% інженерних зусиль інвестується в підготовку, і лише 5% у фактичні зміни. Навіть краще, більшість із цих 95% складається з діяльності, яку ваша команда вже виконує в рамках звичайних операцій другого дня - гігієна запасів, управління сертифікатами, перевірка плану набору номера, відстеження життєвого циклу пристрою та документація. Іншими словами, основ на частина «міграційної роботи» - це робота, яку ви вже робите. Цей структурований підхід просто спрямовує його до визначеного результату, у темпі, який вписується у ваш існу ючий операційний ритм, а не поверх нього.
Почуття «місії неможливої» також згасає, коли ви бачите, що кожну міграцію можна повністю репетирувати. Невеликий, репрезент ативний піло т дозволяє перевірити наскрізний процес, інтеграції, поведінку відмови та досвід користувача до того, як торкнеться одного виробничого користувача. Ніщо не залишається на волю випадковості в наступний день, тому що наступний день - це просто повторення процесу, який ви вже успішно виконали. І якщо трапиться щось несподіване, відкат - це дзеркало самого розрізу, обмежене чітким вікном обслуговування. Передбачуваність замінює тривогу.
Так, перехід на виділений екземпляр означає відмову від певного контролю — зокрема над рівнями інфраструктури та віртуалізації. Але подумайте, що ви отримуєте: час, який ваша команда витрачає на виправлення гіпервізорів, переслідування апаратних сповіщень, управління безпекою на рівні операційної системи та планування оновлення можливостей. Цей час повертається до бізнесу, де його можна витратити на те, що насправді відрізняє вашу організацію - досвід користувачів, прийняття, інтеграцію та послуги, про які справді піклуються ваші зацікавлені сторони. Ви не втрачаєте контролю; ви торгуєте недиференційованими важкими навантаженнями для стратегічної спрямованості.
В обмін ви отримуєте платформу, щільно інтегровану з найсучаснішим портфелем телефонних дзвінків, зустрічей та контактних центрів на ринку, що підтримується інженерною глиби ною Cisco та партнерською екосистемою, вдосконаленою сотнями тисяч розгортань. Ви зберігаєте всю потужність знайомої Unified CM екосистеми — ті самі функції, ту саму надійність, ту саму адміністративну модель, яку вже знає ваша команда — тепер у поєднанні з Control Hub, сучасною, орієнтованою на користувачів парасолькою управління та аналітики, яку справді легко вивчити. Оновлення, оновлення та виправлення критичних вразливостей у найновішому програмному забезпеченні кер ує Cisco на обчислювальних пристроях, сертифікованих Cisco, з тією ж (або кращою) надійністю, яку ви очікуєте від вашого локального середовища.
Так, так - зміни несуть ризик. Але не змін юватись несе свій власний, більш тихий ризик: відставання за функціями, усунення постійної складності змін, випуск оновлень та вразливостей, розширення вашої команди на інфраструктуру, яка більше не відрізняє бізнес, і затримка неминучого переходу, поки це не потрібно зробити під тиском. Стру ктурований, закритий підхід, розроблений таким чином, щоб зробити цю міграцію такою, якою вона повинна бути: добре підготовлена, малодраматична та висо ко перевірена - виконана переважно за допомогою роботи, яку ви вже виконуєте, до платформи, створеної для того, куди рухається подальша співпраця.
Від впевненості до плану: як організовано цей посібник
Щоб перетворити цю впевненість у виконувану дорожню карту, цей посібник проведе вас через процес міграції із се ми критеріями, кожен з яких містить чіткі критерії входу та виходу, уроки, отримані з поля та попередні перевірки, які запобігають найпоширені шим сюрпризам:
- Ініціація проекту
- Відкриття та оцінка
- Планування
- Реалізація
- Заморожувати
- Перейти в прямому ефірі
- Переїзд до 2-го дня
Однією з причин, чому ця модель працює так добре, є те, що ризик для вашого виробничого середовища навмисно завантажується майже до нуля і зростає лише на контрольованому, остаточному кроці. Ось чого очікувати на кожному етапі:
| Вплив на виробництво | Фази |
|---|---|
| Відсутність впливу | Ініціювання проекту, виявлення та оцінка, планування |
| Мінімальний вплив | Реалізація |
| Обмежено операційними процесами | Заморожувати |
| прямий вплив | Перейти в прямому ефірі |
На практиці: більша частина подорожі відбувається безпечно поряд з вашим існуючим середовищем. Коли ви досягнете моменту, який торкається виробництва, кожна інтеграція була побудована, кожен процес репетирований і кожен запасний варіант перевірений.
У цьому посібнику ми посилаємось на основні інформаційні ресурси, на які ви будете покладатися під час міграції та аж до другого дня:
- Cisco Calling Sales Connect - По си лання підключення продажу дзвінків Cisco
- Help.webex.com — авторитетна документація продукту та конфігурації
- Webex Spaces — прямий доступ до експертів Cisco та спільнот колег для запитань у режимі ре ального часу
З набором фреймворків і наявними ресурсами давайте детально розглянемо кожну фазу — починаючи з того, де починається кожна успішна міграція: І ніціювання проекту.
Ініціація проекту
Вплив на виробництво: БЕЗ впливу
- Визначте ключові зацікавлені сторони
Пам'ятайте, що мова йде не лише про технічні команди та вплинуті бізнес-команди, а й про залу чених партнерів. Ось приклад необхідних зацікавлених сторін:
- ІТ-менеджмент
- Управління бізнесом
- Команда голосових служб
- Команда контакт-центрів
- Мережева команда
- Команда DNS/DHCP
- Команда безпеки
- Команда IAM (наприклад, Entra, AD, SSO)
- Змінити дошку
- Партнер MACD
- Партнер керованих послуг
- Постачальники інтеграції 3d партії (підкачка, факс, запис тощо)
- Локальна, локальна підтримка
- RedSky/Команда громадської безпеки.
- Вибір керівника проекту або менеджера проекту.
Враховуючи, що міграція на виділений екземпляр передбачає більш складну координацію, ніж традиційні інтеграції «лише на рівні додатків», бажано, щоб член команди був призначений для управління внутрішнім проектом та всіма пов'язаними завданнями, такими як щотижневі дзвінки, координація внутрішніх команд, залучення зовнішніх постачальників, координація змін тощо.
- Синхронізація входів, з яких ви починаєте проект
Існує безліч переваг і причин, чому існує стратегія міграції на виділений екземп ляр. Важливо базове бачення майбутнього рішення.
Чи є якісь зміни, такі як консолідація кластерів, план набору номера, нові функції заплановані?
Ви мігруєте кінцеві точки програмного забезпечення «як є» або міграція передбачає переміщення до програми Webex?
Яке відношення користувачів до Контакт-центрів?
- Отримайте швидкість за допомогою виділеного екземпляра
Вступ до виділеного екземпляра: Вступ до виділеного екземпляра
BDM (слайди, що приймають рішення про бізнес) BDM
TDM (слайди, що приймають технічні рішення) T DM.
Відкриття та оцінка
Вплив на виробництво: БЕЗ впливу
Виявлення та оцінка - це продовження та використання інформації, отриманої під час попередніх зустрічей команди синхронізації на вхідних даних з метою виявлення всіх необхідних елементів сфери, які стануть основою для професійної розробки проекту та техні чного плану проекту
- Налаштування існуючого кластера
Визначте існуючі налаштування On-Prem з усіма виконаними функціями та інтеграціями. Ось приклади, на які варто подивитися:
- Застосування та розміри,
- Локації,
- IP-адресація,
- Як користувачі синхронізували/забезпечували (локальний, ldap),
- Конфігурована автентифікація (SSO),
- CA проти сертифікатів, що підписуються самостійно,
- Режим безпеки,
- Використання ILS/GDPR,
- Особливості,
- Особливий акцент на міжсайтових функціях, таких як: Extension Mobility
- Інтеграція CER/911,
- Використання МРА,
- КДР,
- Голосові повідомлення та інтеграція з O365,
- Джаббер проти WebExApp
- У разі міграції Jabber слід зосередитися на тому, як налаштовано існуючі кінцеві точки Jabber (наприклад, конфігурація xml, домен голосової служби) та які варіанти переконфігурації, наприклад використання SCCM. Нижче наведено стандартні сценарії: Н алаштування Jabber
- Список пристроїв з фокусом для перевірки
- Застарілі пристрої (з Rel12.0x не додано нових пристроїв до списку застарілих пристроїв) Застарілі телефони
- Закінчення підтримки пристроїв (Пристрої все ще можуть бути зареєстровані в будь-якому випуску програмного забезпечення, але не підтриму ються з точки зору Дня 2)
- CSR-Compatibility-Matrix-Interactive.html
- Пристрої спеціальних обмежень 7925, 7940, 7960 Реєстрація старих моделей телефонів у виділеному екземпля рі
- Інструменти в довідці:
Спеціалізований помічник перед міграцією: С творення зві тів про оцінку
Помічник перед міграцією в центрі керування допомагає збирати вихідні дані та перевіряти передумови для міграції з UCM на виділений екземпляр за допомогою стороннього інструменту. Перед міграцією він оцінює готовність, надає контрольні списки та дозволяє порівнювати дані між локальним кластером та виділеним екземпляром.
Щоб запустити Assistant, ваш локальний кластер повинен бути підключений до середовища We bex Cloud UC. Загальний опис та передумови ви можете знайти тут: Web Excloud-ConnectedUC
Процес інсталя ції для UCM: Налаштування Webex Cloud Connected -UC
Список важливих відомостей, які ви можете отримати в якості виводу з Pre-Migration Assistant у легко читаному форматі xls:
- Вузли та запущене програмне забезпечення
- Параметри підприємства
- Список SIP-магістралей
- Список користувачів програми, ролі
- Кількість пристроїв (і повний список пристроїв), Групи маршрутів і розділів, Місцезнаходження , Кінцеві користувачі
- Групи CM, Пули пристроїв
- Стан здоров'я реплікації БД
- Встановлені КОП
- Плани нумерації
- Телефонні послуги
- Віддалені напрямки
- Webex Spaces для підтримки з вашими конкретними запитаннями:
Запитайте хмару UCM та виділений екземпляр: webexteams: //im? просторо=5дб6бб40-д3с7-11е9-а319-дф8а35абе85а
Запитайте допомогу з налаштування Webex - Webex Calling і DI: webexteams: //im? просторо=76беаб50-084б-11ед-абц8-аб581010б1де.
- Інструменти в довідці:
Планування та реалізація
Вплив на виробництво: мінімальний вплив на існуюче виробниче середовище
Найкращі практики Cisco щодо процесу міграції виділених екземплярів наведен і нижче:
Активувати виділений екземпляр (майстер налаштування першого разу)
Щоб активувати виділений екземпляр, див. Активувати виділений екземп ляр
Збірка середовища DI (забезпечення виділеного екземпляра)
Щоб створити середовище DI, зверніться до Виділеного екзе мпляра для Webex Calling базової конфігурації
Найбільш поширені питання, примітки:
- Розмір збірки пояснюється тут (Розмір виділеного екземпляра): https://help.webex.com/en-us/article/dk3o5r/Introduction-to-Dedicated-Instance Кількість кластерів та загальний розмір відповідають кількості придбаних ліцензій. Заг алом розмір враховує зростання резервів відповідно до угоди Flex (15% або 20% залежить від типу) та надання 3 активних пристроїв на одного працівника знань). Cisco Cloud сертифікована платформа, найкраща в своєму класі обчислювальна система з використанням середніх OVA для всіх збірок, а повністю розгорнутий кластер виділеного екземпляра може підтримувати до 8 серверів обробки викликів або приблизно 50 000 пристроїв
- МСП є необов'язковим, вимагають придбання мінімум 3 кластерів та/або регіонів. Вимага йте перегляду дизайну та потужності з боку Cisco
- Початкова потужність MRA становить 20% і може бути збільшена до 100% залежно від фактичної потреби за допомогою квитка TAC
- Елементи конфігурації з «x» перед назвою не повинні бути перейменовані, оскільки використовується в інтеграціях автоматизації, серві сності та аналітики Виділений екземпляр для Webex Calling базов ої конфігу рації
- Якщо потрібно мати більше 3 кластерів в одному регіоні, то стандартна IP-адресація для DI- екземплярів НЕ є варіантом
Посилання. Стандартна IP-адресація, Розташування центрів обробки даних: Розташування центрів обробки даних.
Доступ до виділеного екземпляра:
Щоб отримати доступ до програми виділеного екземпляра, зверніться до програм виділених екземплярів Access
Найбільш поширені питання, примітки:
- Програми DI можна отримати доступ через Контрольний центр або безпосередньо з мережі Клієнта. Доступ CLI також надається, за винятком швидкісних доріг.
- Ранги користувачів:
- 3 - Адміністратор партнерів
- 4 - Адміністратор клієнтів
- 5 - корпоративний користувач
- Облікові дані для доступу до програм DI поділяються в створеному автоматизацією просторі Webex , де ProAdmin.
Пірінг/Підключення
Мережева архітек тура з детальним описом сценаріїв підключення Edge дляWebex Calling, виділеного екземпля ра та зустрічей. PA_Edge_Connect_Design.pdf
*Документ слід використовувати обережно, оскільки описує кілька сценаріїв, які можуть бути суперечли вими або доповнювати один одного, залежно від конкретного випадку використання. Точне посилання на виділений ек зе мпляр можна знайти в розділі «Edge Connect для архітектури виділеного екземпляра»
Webex EdgeПідключити
Webex EdgeПідклю чити Найпоширеніші питання, примітки:
- Посилання виділеного екземпляра 2 є «обов'язковими»
- 4 посилання є варіантом, але «перетин» не допускається, вони використовуються в «парах»
- Будь-яке визначення пріоритетів DI-трафіку щодо одного з посилань НЕ підтримується і, як правило, не застосовується, оскільки кожна сторона/DC рекламує свою унікальну підмережу /25 розташування центрів обробки даних виді лених екземплярів.
Віртуальне підключення Webex
Найбільш поширені питання, примітки:
- Максимальна підтримувана пропускна здатність за допомогою Virtual Connect становить 250 Мбіт/с
- Цей параметр не підходить/не підтримується у разі розгортання ESN.
Вимоги до мережі та безпеки виділених екземплярів (джерело для мережі, порти брандмауера, інформація про DNS)
Щоб дізнатися про вимоги до мережі та безпеки, зверніться до Вимо ги до мережі та безпеки
Найбільш поширені питання, примітки:
- Моніторин@@ г SNMP НЕ допускається. Винятком SNMP є робочі процеси CER та Inform acast, які потребують запиту на обслуговування через Control Hub
- Немає доступу від DI до зовнішнього SFTP. SFTP, що використовується для оновлень, оновлень та інших робочих процесів, знаходиться в середовищі DI, і доступ надається для обмежених сценаріїв (наприклад, доступ до нової копії/мікропрограми відповідно до запиту служби центру керування).
ESN (підвищена живучість)
Почніть з/Загальна інформація: Почніть роботу з покращен ою виживаністю
Передумови: Покращ ені передумови виживання
Для активації: Актив уйте підвищену живучість.
Найбільш поширені питання, примітки:
- ESN Flex SKU діє на основі «для кожного регіону». Наприклад, якщо вам потрібно інтегрувати 5 вузлів ESN в Америці, вам потрібно замовити 1 ESN SKU, який дозволить приєднати до 8 вузлів ESN до одного кластеру без впливу на максимальну кількість вузлів обробки викликів, дозво лених у кластері
- Замовник несе відповідальність за забезпечення необхідних віртуалізованих ресурсів та встановлення 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
- Cisco відповідає за сертифікати CA. В процесі активації вам буде запропоновано авто ризувати поновлення/оновлення сертифікатів Кластеру, щоб включити ноду ESN до списку.
Служба синхронізації каталогів
Поряд з традиційним методом, який використовується з UCM on-prem для синхронізації користувачів через ldap або для створення локальних, існує опція з виділеним екземпляром для синхронізації користувачів через Control Hub (Webex Com mon Identity Service) з Azure або через Directory Connector. Для служби каталогів Webex CI підтримується лише розгортання SSO.
Інтеграція служб каталогів через спільну ідентифікацію Webex для виділеного екземпляра
Найбільш поширені питання, примітки:
- Після завершення підготовки Azure AD для певного кластера ви не зможете створювати нові угоди про синхроні зацію та змінювати будь-які налаштування конфігурації для того ж кластера, окрім налаштувань групи. Зверніться до Cisco TAC служби підтримки, щоб скинути службу каталогів. Потім ви можете створити нову угоду для надання послуг.
- Ви повинні включити синхронізацію протягом 18 годин з моменту створення нової у годи. Синхронізовані користувачі LDAP стають неактивними і видаляються після 24 годин бездіяльності. Користувачі не зможуть увійти в систему та користуватися послу Unified CM гами.
- Навіть конфігурація в диспетчері викликів виглядає як редагована, вона не повинна змінюватися за межі того, що створюється автоматизацією під час надання угоди синхронізації. Хоча налаштування відображають синхронізацію один раз, Центр керування синхронізується при 24-годинному циклі змін у Common Identity на Unified CM або Cisco Unity Connection.
- Сервіс використовується тільки для синхронізації каталогів (!). Аутентифікація повинна встановлюватися за допомогою SSO, що є обов'язковою умовою.
SSO
SSO не є обов'язковим для виділеного екземпляра. У будь-якому випадку це обов'язкове для деяких ключових служб, таких як Webex Common Identity, використання WebExApp. Розгортання SAML SSO нічим не відрізняється від розгортання UCM на місці та опис ане нижче. Єдиний операційний нюанс пов'язаний з процесом активації , який вимагає від користувача рангу 1 для тестування SSO під час активації. Партнери та клієнти обмежені привілеями Rank3-5, тому підтримка Cisco необхідна для активації, і її слід запитувати через запит на обслуговування в Control Hub (тип квитка UC Application Management)
CUCM_b_saml-sso-deployment-guide-release-15.html
Щоб відкрити Запит на обслуговування, зверніться до розділу Як отримати запит на послугу.
Інтеграція кластера виділених екземплярів з локальним кластером
Враховуючи, що більшість сценаріїв міграції не можуть відбуватися як одноразова міграція, необхідність попереднього тестування та певний рівень перехресної інтеграції, ми рекомендуємо встановити міжкластерний магістраль та відповідну конфігурацію як один із перших кроків. ILS, якщо використовується.
Об'єднання сертифікатів
Одним з найважливіших завдань підготовки системи до міграції є обмін сертифікатами між локальними та хмарними системами, усі безпечні інтеграції. Роблячи це, ви дозволяєте телефонам вільно переміщатися до нового кластера та назад до старих кластерів без необхідності скидання до заводських налаштувань.
Найбільш поширені питання, примітки:
Зазвичай це передбачає частку сертифікатів від DI та завантаження їх на On-Prem сторону
- Менеджер дзвінків.pem (мульти-SAN)
- ІТЛВідновлення.pem
- Проміжний сертифікат CA
- Кореневий сертифікат CA
З боку клієнта CUCM до DI:
- CallManager.pem (Multi-SAN), якщо він не є мульти-SAN, включіть Сертифікати видавця та серверів TFTP.
- ITLRecovery.pem (паб)
- Проміжний сертифікат CA (у випадку, якщо сертифікати підписані CA)
- Кореневий сертифікат CA (у випадку, якщо сертифікати підписані CA).
План міграції програми Webex та/або Jabber
Найбільш поширені питання, примітки:
- Як зберегти користувацький досвід з входом в Jabber в новій системі? Які зміни /сценарії можливі для продовження використання Jabber, як у локальній системі? Ось можливі варіанти: Налаштувати Jabber у виділеному екземплярі для використання домену клієнта для входу Н алаштувати Jabber у виділеному екземплярі для використання домену клієнта для входу
E911
У розгортанні виділеного екземпля Cisco Emergency Responder ра (CER) і RedSky будуть використовуватися для відстеження телефонів і клієнтів. Локальні телефони будуть відстежуватися за допомогою служби ек стреної допомоги для ідентифікації місцезнаходження телефону та встановлення відповідного місця відправлення, перш ніж направляти дзвінок на RedSky для доставки дзвінків. Користувачі програми Webex відстежуватиму ться в RedSky за допомогою протоколу HELD +.
Виділений екземпляр постачається з розгорнутим CER в регіоні Америки. Cisco додає інформацію про проксі, тоді як відповідальність партнера/клієнта полягає в тому, щоб додати деталі RedSky та налаштувати ELIN. Додаємо сценарій LUA і Партнер/Клієнт повинен налаштувати параметри, щоб він працював. Найпоширеніші питання, примітки
- Як отримати аккаунт RedSky на порталі RedSky:
- BOT доступний у Webex - Налаштування облікового запису клієнта E911 (E911Account@webex.bot) Введіть «підтримка» та заповніть форму, яка з'явиться та надішліть. Буде створено обліковий запис і надіслано електронний лист на адресу адміністратора, вказану в BOT
- Налаштування E911 для виділеного екземпляра, Н алаш тування E911
Підтримка просторів Webex:
Запитайте зовнішнього RedSky - приєднуйтесь до партнера E911 Solutions Plus: https://eurl.io/#fWfT1SnOz.
Інженерні команди та готовність користувачів до змін
Нижче наведено рекомендовані ресурси для інженерних команд, щоб ознайомитися з усіма аспектами виділеного екземпляра:
- Підключення продажів Cisco Calling
- Довідка.WebEx.com
- Академія Webex: Академія
- Ресурси усиновлення. Ресурси для прийняття корисні для обох: допомога у стратегії впровадження сервісу та функцій, А також база знань буклетів «Як зробити» та коротких відео, які можуть бути великою підтримкою для Кінцевих користувачів. ресурси.webex.com.
Заморожувати
Вплив на виробництво: вплив обмежений операційними процесами
Метою фази Freeze є переміщення даних із вихідної системи до цільового виділеного екземпляра та виконання необхідних перевірок для забезпечення успішного переходу. Ми рекомендуємо 2-3 тижні для за морожування, щоб переконатися, що команди мають необхідний час для переміщення даних, перевірки узгодженості даних, відмови тестування та відповідного тестування.
Якщо є потреба в MACD під час фази заморожування, необхідні зміни повинні бути виконані в обох системах.
Існує кілька способів та інструментів для переміщення/копіювання даних. Як правило, ми рекомендуємо використовувати активні/неактивні розділи та інструменти, як показано нижче:
UCM:
Експорт/імпорт BAT та пов'язані сцен арії
Посібник з масов Cisco Unified Communications Manager ого адміністрування для випуску 15 та SU: CUCM_b_bulk-administration-guide-15.html.
Зовнішні інструменти для міграції UCM, як-от Yarnlab.
Єдність:
- Cisco UnityІнструменти. Колекція безкоштовних Cisco Unity та Cisco Unity Connection супутніх інструментів.
https://www.ciscounitytools.com/index.html
Ми рекомендуємо використовувати кобри для міграції Unity.
CER:
Ручний, масовий експорт/імпорт
Після переміщення даних конфігурації розглянемо наступні важливі елементи/дії:
- Вручну або через опцію 150 на DHCP щодо переадресації тестової групи різних моделей телефонів на новий DI TFTP. Після консолідації сертифікатів ви можете протестувати обидва: сценарій міграції та відкату
- Реконфігурація тестового шлюзу, якщо є
- Підготовка шаблонів конфігурації шлюзів для фактичного скорочення виробництва. Сценарії, якщо потрібно.
- Переміщення користувача WebExApp через зміну поведінки виклику в CH
- Переміщення Jabber за допомогою визначеного раніше методу входу та зміни домашнього кластера
- Тест основних потоків викликів і функціональності аж до можливостей середовища:
- Перевірка послідовності поведінки в мережі або підключення через VPN
- Тест MRA з кінцевою точкою телефону та програмного забезпечення
- PSTN
- Тест служби 911
Вихідний день або запуск
Кожен виріз унікальний, і план повинен враховувати нюанси точного середовища. Загалом кажучи, етапи процесу:
- Створення активного квитка TAC (запланована відправка)
- Перезавантаження пристроїв здійснюється за допомогою зміни опції 150 на всіх пов'язаних підмережах та скидання телефонів у диспетчері дзвінків
- Перевірка зареєстрованих телефонів на новій системі — це простий спосіб контролювати процес успішної реєстрації в новій системі виділених екземплярів
- Після перевірки, масове оновлення необхідних конфігурацій (лінії та шаблони маршрутів з точки зору активних та нульових розділів, домашнього кластера, реклами) на локальному та виділеному екземплярі
- Змінити конфігурації шлюзів, SRST, апаратних носіїв
- Виконати визначену тестову програму:
- Тестувати внутрішньосайтові, міжсайтові, PSTN виклики
- MRA
- 911
- Голосова пошта
- Застосовувані функції
день2
- Підтримка виділених екземплярів рівня 1 (TAC) Підтримка виділених екзе мплярів рівня 1
- Запити на послуги, пов'язані з переліченими те мами: Як підняти запит на послугу
- Запис DNS
- оновлення брандмауера
- Завантаження прошивки
- Хмарне підключення
- Параметри журналу аудиту
- Управління додатками UC
- DI-MT Міжопераційні SIP-магістралі
- Життєвий цикл програми UC
- Інфраструктура як послуга
- Посібник з операцій партнерів
- Посібник з операцій партнерів
Це один з найважливіших документів, який пояснює технічну підтримку, управління змінами, управління інцидентами, оновлення, оновлення, управління потужністю, управління сертифікатами, керівництво операціями партнера DRS
- Матриця відповідальності
- Запитайте RedSky Webex Space webexteams: //im? просторо=7074фце0-489а-11еа-89ф3-8ф977дд07аа0.