Wymagania wstępne

Aby organizacja kwalifikowała się do migracji między regionami, nie musi posiadać żadnej z następujących usług:

• Webex dla BroadWorks
• Spark Call (przed uaktualnieniem do Webex Calling)

Jakie dane są migrowane

Wszystkie dane powiązane z Webex Identity, takie jak nazwa, adres e-mail i grupy użytkowników, są migrowane do regionu docelowego. Dane analityczne dla Webex Calling, Messaging i Devices zostaną również zmigrowane po zakończeniu migracji tożsamości Webex.

Wyjątki od tego, jakie dane są migrowane: Dane analityczne CCUC nie zostanie teraz przeniesiony. Migracja danych analitycznych nie dotyczy organizacji migrujących między amerykańskim centrum danych a kanadyjskim centrum danych.

Wpływ na usługi Webex

Podczas migracji

Po rozpoczęciu migracji:

• Migracja danych może potrwać mniej niż godzinę w przypadku organizacji Webex z mniej niż 10 000 użytkowników i może potrwać do ośmiu godzin w przypadku organizacji z około 100 000 użytkowników. Migrację danych należy zaplanować na dzień, w którym można uwzględnić wymagany przestój.

  Upewnij się, że wszystkie zadania wsadowe zostaną zakończone przed rozpoczęciem zaplanowanej migracji.

• Nie będziesz mieć dostępu do Control Hub, a użytkownicy nie będą mogli uzyskać dostępu do żadnych wiadomości, połączeń, centrum kontaktowego Webex ani usług spotkań dla witryn zarządzanych przez Control Hub.
• Jeśli w Twojej organizacji skonfigurowano jednokrotne logowanie (SSO), zostanie ono automatycznie wyłączone.
• Urządzenia lokalne zarejestrowane za pomocą Webex Edge for Devices a urządzenia zarejestrowane w chmurze nie będą mogły dołączać do spotkań ani nawiązywać połączeń.
• Zbiorcze usuwanie lub zmienianie działań w obszarze roboczym lub urządzeniu rozpoczętym tuż przed migracją może zostać przerwane przez migrację i może się nie powieść.
• Będziemy wysyłać przypomnienia e-mail do administratorów organizacji, a następnie aktualizacje statusu co dwie godziny w trakcie aktualizacji.

Co się dzieje po migracji i wymagane działania od Ciebie

• Jeśli w Twojej organizacji skonfigurowano SSO, po migracji użytkownicy nie będą mogli się zalogować, dopóki nie zostanie ponownie skonfigurowana SSO konfiguracja w następujący sposób:
  • Pobierz metadane SP.
  • Zaimportuj te metadane do dostawcy tożsamości.
  • Aktywuj SSO , przechodząc do Ustawienia organizacji > Uwierzytelnianie i przełączanie Jednokrotne logowanie na włączone.
• Kody aktywacyjne urządzenia które zostały wygenerowane, ale nie były używane przed migracją, będą musiały zostać wygenerowane ponownie.
• Jeśli Twoja organizacja używa integracji Okta do synchronizowania użytkowników Okta z Control Hub, musisz ponownie wygenerować token dostępu okaziciela, jak określono w kroki 3 i 4 w sekcji Konfigurowanie programu Okta do synchronizacji użytkowników w tym artykule .
• Dane Analytics nie pojawią się natychmiast po migracji. Migracja danych Analytics będzie kontynuowana w tle i potrwa do dwóch do trzech dni. Nie musisz nic robić, aby przywrócić dane analityczne. Pojawi się ponownie automatycznie. Wpływa to na to, że nie zobaczysz danych analitycznych w Control Hub do dwóch lub trzech dni po zakończeniu migracji.
• Migracja spowoduje zresetowanie lokalnych baz danych użytkowników, którzy używają połączeń UCM. W rezultacie historie połączeń zostaną zresetowane, a historia poprzednich połączeń nie będzie już dostępna.

Wpływ na użytkowników końcowych

• Na początku migracji użytkownicy są wylogowani z aplikacji Webex. Użytkownicy muszą się ponownie zalogować podczas migracji lub po niej.
• Jeśli użytkownicy skonfigurowali ustawienia lokalne w swoich komputerach i komputerach klienckich aplikacji Webex , muszą ponownie skonfigurować niektóre z tych ustawień. Następujące ustawienia zostaną zresetowane po migracji:
  • Dzwonienie
  • Preferencje audio i wideo
  • Dostępność
  • Preferencje wiadomości
  • Urządzenia

  Inne ustawienia lokalne, takie jak ustawienia ogólne, preferencje powiadomień, wygląd (np. tryb ciemny) i ustawienia prywatności, zostaną zachowane (bez zmian) po migracji.

Wpływ na integracje

Dzięki Webex możliwe jest wiele typów integracji, które zazwyczaj są autoryzowane przez użytkowników. Tokeny użytkowników do integracji są cofane po rozpoczęciu migracji wspólnych danych aplikacji. Aby integracje mogły nadal działać, użytkownicy z uprawnieniami prawnymi będą musieli ponownie autoryzować dostęp do tych integracji.

Inne integracje, które nie są autoryzowane przez użytkowników, będą musiały zostać ponownie autoryzowane przez administratorów lub funkcjonariuszy ds. zgodności. Na przykład integracje API Events mogą być ponownie autoryzowane tylko przez funkcjonariuszy ds. zgodności.

Nieautoryzacja integracji spowoduje, że integracje przestaną działać.

• Aplikacje wbudowane— tokeny dostępu i odświeżania dla użytkowników nie są migrowane, więc użytkownicy muszą ponownie autoryzować aplikacje wbudowane po zakończeniu migracji danych wspólnej aplikacji. Zazwyczaj odbywa się to przez zalogowanie się do osadzonej aplikacji.
• Integracje— tokeny dostępu i odświeżania dla użytkowników nie są migrowane, więc użytkownicy muszą ponownie autoryzować integracje po zakończeniu migracji wspólnych danych aplikacji.
  • Niektóre integracje są konfigurowane w Control Hub i mogą być dezaktywowane podczas migracji. Jednym z przykładów jest integracja ThousandEyes, która jest wyłączona podczas migracji i musi zostać ponownie skonfigurowana. Strona aplikacji w Control Hub jest również dobrym odniesieniem do sprawdzania, jakie integracje zostały wyłączone.
  • Integracje z rozwiązaniami zapobiegania utracie danych muszą być ponownie autoryzowane przez funkcjonariuszy ds. zgodności.
  • Integracje zadań i łączniki Webex Contact Center muszą być ponownie autoryzowane.
  • Jeśli Twoi użytkownicy zbudowali dowolne integracje interfejsu API Webex, tokeny dostępu i odświeżania powiązane z tymi integracjami przestaną działać.
• Aplikacje usługowe muszą zostać ponownie autoryzowane. Klient musi poprosić o nowy token dostępu i odświeżania.
• Jeśli Twoja organizacja utworzyła boty, token dostępu dla każdego bota zostanie unieważniony w ramach migracji. Jeśli spróbujesz uzyskać dostęp do botów, otrzymasz błąd HTTP 401, ponieważ token dostępu będzie nieprawidłowy lub wygasł. Musisz ponownie wygenerować token dostępu dla wszystkich swoich botów i zaktualizować konfiguracje botów, aby używały nowego tokena dostępu. Można to zrobić, otwierająchttps://developer.webex.com/my-apps , wybierając każdego utworzonego bota, a następnie klikając Wygeneruj ponownie token dostępu .

Jeśli po migracji użytkownicy mają problemy z zalogowaniem się do Cisco.com przy użyciu powiązanego konta Webex, możesz poinformować ich, że mogą poprosić o usunięcie łącza do swoich kont z Webex w celu rozwiązania problemu.