דרישות מקדימות

כדי שהארגון שלך יהיה זכאי להגר בין אזורים, אסור שהארגון שלך יכלול אף אחד מהשירותים הבאים:

• Webex for BroadWorks
• Spark Call (לפני השדרוג ל - Webex Calling)

אילו נתונים מועברים

כל הנתונים המשויכים ל-Webex Identity, כגון שם, כתובת דוא"ל וקבוצות משתמשים, מועברים לאזור היעד. נתוני ניתוח עבור שיחות, הודעות ומכשירים של Webex יועברו גם הם לאחר השלמת העברת Webex Identity.

• העברת נתונים עשויה להימשך פחות משעה עבור ארגוני Webex עם פחות מ-10,000 משתמשים, ועשויה להימשך עד שמונה שעות עבור ארגונים עם כ-100,000 משתמשים. עליך לקבוע מועד להעברת הנתונים שלך בתאריך שבו תהיה לך אפשרות לארח לפי זמן ההשבתה הנדרש.

  ודא שכל עבודות האצווה יושלמו לפני תחילת ההעברה המתוכננת.

• לא תהיה לך גישה למרכז הבקרה, ולמשתמשים לא תהיה גישה לכל הודעות, שיחות, מרכז קשר של Webex ושירותי פגישות באתרים המנוהלים על ידי מרכז הבקרה.
• אם הארגון שלך הגדיר כניסה יחידה (SSO), הוא יושבת באופן אוטומטי.
• מכשירים מקומיים הרשומים ב-Edge ומכשירים הרשומים בענן לא יכולים להצטרף לפגישות או לבצע שיחות.
• הנדידה עלולה לקטוע את סביבת העבודה או את פעולות המחיקה או השינוי של המכשיר ממש לפני שההעברה תושלם.
• נשלח תזכורות בדוא"ל למנהלי הארגון, ולאחר מכן עדכוני סטטוס כל שעתיים בזמן שהעדכון מתבצע.

מה קורה לאחר ההעברה והפעולות הנדרשות מצידך

• אם הארגון שלך הגדיר SSO, לאחר ההעברה משתמשים לא יוכלו להתחבר עד ש-SSO יוגדר מחדש באופן הבא:
  • הורד מטא-דאטה של SP.
  • ייבא את המטא-דאטה הזה ל-IdP.
  • הפעלת SSO על ידי מעבר אל הגדרות ארגון > אימות והפעלה של כניסה יחידה.
• קודי הפעלת מכשיריםשנוצרו אך לא נעשה בהם שימוש לפני ההעברה יצטרכו להיווצר שוב.
• ייתכן שיחלפו עד 24 שעות עד שהמכשירים יפעלו במלואם לאחר ההעברה. ניתן לאתחל מכשירים באופן ידני כדי להאיץ את התהליך הזה.
• אם הארגון שלך משתמש בשילוב Okta כדי לסנכרן משתמשי Okta לתוך Control Hub, עליך ליצור מחדש את אסימון הגישה של ה-bearer כפי שצוין ב- שלבים 3 ו- 4 תחת הגדרת Okta לסנכרון משתמשים במאמר זה.
• נתוני אנליטיקס לא יופיעו מיד לאחר ההעברה. העברת נתוני האנליטיקס תימשך ברקע ותימשך עד יומיים-שלושה. אין צורך בפעולות כלשהן מצידך כדי להחזיר את נתוני האנליטיקה. זה יופיע מחדש באופן אוטומטי. ההשפעה היא שלא תראו נתוני ניתוח ב-Control Hub עד יומיים-שלושה לאחר השלמת ההעברה.
• ההעברה תאפס את מסדי הנתונים המקומיים של משתמשים אם הם משתמשים ב-UCM Calling. כתוצאה מכך, היסטוריית השיחות תאופס והיסטוריית השיחות הקודמות לא תהיה זמינה עוד.

השפעות על משתמשי הקצה

• בתחילת ההעברה, המשתמשים יוצאים מאפליקציית Webex. על המשתמשים להתחבר שוב במהלך או אחרי ההעברה.
• אם המשתמשים שלך הגדירו הגדרות מקומיות במחשב שולחני ובסלולר של אפליקציית Webex, עליהם להגדיר מחדש חלק מההגדרות האלה. ההגדרות הבאות יאופסו לאחר ההעברה:
  • התקשרות
  • הצג העדפות שמע ווידאו
  • נגישות
  • העדפות לפגישה
  • מכשירים

  הגדרות מקומיות אחרות כגון הגדרות כלליות, העדפות הודעות, מראה (למשל מצב כהה) והגדרות פרטיות יישמרו (ללא שינוי) לאחר ההעברה.

השפעות על אינטגרציות

ישנם סוגים רבים של אינטגרציות אפשריות עם Webex, והן בדרך כלל מאושרות על ידי המשתמשים. אסימוני משתמש לאינטגרציות מבוטלים לאחר תחילת העברת נתוני האפליקציה המשותפת. כדי שהאינטגרציות ימשיכו לפעול, משתמשים בעלי ההרשאות המתאימות יצטרכו לאשר מחדש את הגישה שלהם לאינטגרציות אלו.

אינטגרציות אחרות שאינן מורשות על ידי משתמשים יצטרכו לקבל אישור מחדש על ידי מנהלי מערכת או קציני תאימות. לדוגמה, רק קציני ציות יכולים לאשר מחדש את האינטגרציות של Events API.

• אפליקציות מוטמעות— אסימוני גישה ורענון עבור משתמשים אינם מועברים, לכן על המשתמשים לאשר שוב אפליקציות מוטמעות לאחר סיום העברת נתוני האפליקציות הנפוצות. בדרך כלל זה נעשה על ידי כניסה לאפליקציה המוטמעת.
• אינטגרציות— אסימוני גישה ורענון עבור משתמשים אינם מועברים, לכן על המשתמשים לאשר אינטגרציות שוב לאחר סיום העברת נתוני האפליקציה המשותפת.
  • חלק מהאינטגרציות מוגדרות במרכז הבקרה וייתכן שהן יושבתו במהלך ההעברה. דוגמה אחת היא האינטגרציה של ThousandEyes, אשר כבויה במהלך ההגירה ויש להגדיר אותה מחדש. דף האפליקציות במרכז הבקרה הוא גם מקור טוב לראות אילו אינטגרציות כובתו.
  • אינטגרציות עם פתרונות למניעת אובדן נתונים צריכות לעבור אישור מחדש על ידי קציני ציות.
  • יש לאשר מחדש את שילובי המשימות והמחברים של מרכז הקשר של Webex.
  • אם המשתמשים שלך בנו אינטגרציות Webex API, אסימוני הגישה והרענון המשויכים לאינטגרציות אלו לא יעבדו עוד.
• יש לאשר מחדש את אפליקציות השירות. הלקוח צריך לבקש גישה חדשה ואסימון רענון.
• אם הארגון שלך יצר בוטים, אסימון הגישה עבור כל בוט יבוטל כחלק מההעברה. אם תנסה לגשת לבוטים, תקבל שגיאת HTTP 401 מאחר שאסימון הגישה לא יהיה חוקי או שפג תוקפו. עליך ליצור מחדש את אסימון הגישה עבור כל הבוטים שלך, ולעדכן את תצורות הבוטים שלך כדי להשתמש באסימון הגישה החדש. ניתן לעשות זאת על ידי גישהhttps://developer.webex.com/my-apps, בחירה בכל בוט שיצרת ולאחר מכן לחיצה על יצירת אסימון גישה מחדש.

השפעות על העברת הודעות וידאו (Vidcast)

אם הארגון שלך משתמש בהעברת הודעות וידאו (Vidcast), עליך לפתוח פנייה לצוות התמיכה של סיסקו לאחר ההעברה כדי להעביר נתוני Vidcast לאזור היעד. זה מבטיח שכל סרטוני הווידאו וההקלטות הקיימים של Vidcast יישארו גלויים ונגישים בחשבון Webex של כל משתמש.

אם המשתמשים שלך מתקשים להיכנס ל- Cisco.com עם חשבון Webex מקושר לאחר ההעברה, תוכל ליידע אותם ש- הם יכולים לבקש לבטל את קישור החשבונות שלהם מ-Webex כדי לתקן את הבעיה.