Предварителни изисквания

За да отговаря вашата организация на условията за мигриране между региони, тя не трябва да разполага с никоя от следните услуги:

• Webex за BroadWorks
• Spark Call (преди надстройката до Webex Calling)

Какви данни се мигрират

Всички данни, свързани с Webex Identity, като например име, имейл адрес и потребителски групи, се мигрират към целевия регион. Аналитичните данни за Webex Calling, Messaging и Devices също ще бъдат мигрирани след завършване на миграцията на Webex Identity.

Въздействие върху Вашите Webex услуги

По време на миграцията

След като миграцията започне:

• Миграцията на данни може да отнеме по-малко от един час за организации на Webex с по-малко от 10 000 потребители и до осем часа за организации с около 100 000 потребители. Моля, планирайте миграцията на данните си на дата, на която можете да се настаните за необходимия престой.

  Уверете се, че всички пакетни задачи ще бъдат завършени преди началото на планираната миграция.

• Няма да имате достъп до Control Hub и потребителите няма да имат достъп до никакви съобщения, обаждания, контактен център Webex и услуги за срещи за управлявани от Control Hub сайтове.
• Ако вашата организация е настроила единично влизане (SSO), тя ще бъде автоматично деактивирана.
• Локалните устройства, регистрирани с Webex Edge за устройства и устройства , регистрирани в облака, няма да могат да се присъединяват към събрания или да извършват разговори.
• Работното пространство или устройството масово изтриване или промяна на действията, започнати точно преди миграцията, могат да бъдат прекъснати от миграцията и може да не са завършени успешно.
• Ще изпращаме имейл напомняния до администраторите на организацията, а след това ще публикуваме актуализации на състоянието на всеки два часа, докато актуализацията е в ход.

Какво се случва след миграцията и какви действия трябва да предприемете

• Ако вашата организация е създала SSO, тогава след миграцията потребителите не могат да влязат, докато SSO не бъде преконфигуриран, както следва:
  • Изтегляне на метаданни за SP.
  • Импортирайте тези метаданни към IdP.
  • Активирайте SSO, като отидете на настройки на организацията > Удостоверяване и включване на еднократното влизане.
• Кодовете за активиране на устройства, които са генерирани, но не са използвани преди миграцията, ще трябва да бъдат генерирани отново.
• Може да отнеме до 24 часа, за да заработят напълно устройствата след миграцията. Можете ръчно да рестартирате устройствата, за да ускорите този процес.
• Ако вашата организация използва Okta интеграция за синхронизиране на потребители на Okta в Control Hub, трябва да генерирате отново токена за достъп на носителя, както е посочено в стъпки 3 и 4 в раздела „Конфигуриране на Okta за синхронизация на потребители“ в тази статия.
• Аналитичните данни няма да се появят веднага след миграцията. Мигрирането на аналитични данни ще продължи във фонов режим и ще отнеме до два до три дни. Не се изискват никакви действия от ваша страна, за да възстановите аналитичните данни. Ще се появи отново автоматично. Последицата е, че няма да виждате аналитични данни в Control Hub до два или три дни след завършване на миграцията.
• Миграцията ще нулира локалните бази данни на потребителите, ако те използват UCM Calling. В резултат на това историята на обажданията ще бъде нулирана и историята на предишните обаждания вече няма да е налична.

Въздействие върху крайните потребители

• В началото на миграцията потребителите излизат от приложението Webex. Потребителите трябва да влязат отново по време на или след миграцията.
• Ако вашите потребители са конфигурирали локални настройки в своите настолни и мобилни клиенти на приложението Webex, тогава те трябва да преконфигурират някои от тези настройки. Следните настройки ще бъдат нулирани след миграцията:
  • Набиране
  • Предпочитания за аудио и видео
  • Достъпност
  • Предпочитания за съобщения
  • Устройства

  Други локални настройки, като общи настройки, предпочитания за уведомяване, външен вид (например тъмен режим) и настройки за поверителност ще бъдат запазени (без промяна) след миграцията.

Въздействие върху интеграциите

Възможни са много видове интеграции с Webex и те обикновено се оторизират от потребителите. Потребителските токени за интеграции се отменят след началото на миграцията на данни от общото приложение. За да продължат да работят интеграциите, потребителите с правилните привилегии ще трябва да преупълномощят достъпа си до тези интеграции.

Други интеграции, които не са оторизирани от потребителите, ще трябва да бъдат повторно оторизирани от администратори или служители по съответствието. Например, интеграциите на Events API могат да бъдат повторно оторизирани само от служители по съответствието.

• Вградени приложения— Токените за достъп и обновяване за потребителите не се мигрират, така че потребителите трябва да оторизират вградените приложения отново, след като миграцията на данни от общите приложения приключи. Това обикновено се прави чрез влизане във вграденото приложение.
• Интеграции— Токените за достъп и обновяване за потребителите не се мигрират, така че потребителите трябва да оторизират интеграциите отново, след като миграцията на общите данни на приложението приключи.
  • Някои интеграции са конфигурирани в Control Hub и може да бъдат деактивирани по време на миграцията. Един пример е интеграцията с ThousandEyes, която е изключена по време на миграцията и трябва да бъде преконфигурирана. Страницата с приложения в Control Hub също е добър източник за справка, за да видите кои интеграции са били изключени.
  • Интеграциите с решения за предотвратяване на загуба на данни трябва да бъдат повторно одобрени от служителите по съответствието.
  • Интеграциите на задачи и конекторитена Webex Contact Center трябва да бъдат повторно оторизирани.
  • Ако вашите потребители са изградили интеграции с Webex API, маркерите за достъп и обновяване, свързани с тези интеграции, вече няма да работят.
• Сервизните приложения трябва да бъдат повторно оторизирани. Клиентът трябва да поиска нов токен за достъп и обновяване.
• Ако вашата организация е създала ботове, токенът за достъп за всеки бот ще бъде отменен като част от миграцията. Ако се опитате да получите достъп до ботовете, ще получите грешка HTTP 401, тъй като токената за достъп ще бъде невалидна или изтекла. Трябва да регенерирате токена за достъп за всичките си ботове и да актуализирате конфигурациите на ботовете, за да използвате новия знак за достъп. Това може да стане чрез достъп, https://developer.webex.com/my-appsизбиране на всеки бот, който сте създали, и след това щракване върху Regenerate Access Token.

Въздействие върху видеосъобщенията (Vidcast)

Ако вашата организация използва видео съобщения (Vidcast), трябва да отворите заявка с екипа за поддръжка на Cisco след миграцията, за да прехвърлите данните от Vidcast в целевия регион. Това гарантира, че всички съществуващи видеоклипове и записи на Vidcast остават видими и достъпни в акаунта на Webex на всеки потребител.

Ако вашите потребители имат проблеми с влизането в Cisco.com със свързан Webex акаунт след миграцията, можете да ги уведомите, че могат да поискат да прекъснат връзката на акаунтите си с Webex, за да отстранят проблема.