תכונות שלא נתמכות ב-Domain Transfer Divestiture

אין תמיכה ב-Android Enterprise. כדי להימנע מאובדן נתונים, צריך לבצע את השלבים הבאים לפני ההעברה:

1. צריך לבדוק אם יש קישורי EMM פעילים ולהסיר את המכשירים שמשויכים לקישורים האלה. פרטים נוספים זמינים במאמר בנושא ניהול קישורי EMM.
2. אם אתם מפתחים אפליקציות פרטיות, חשוב לוודא שיש לסביבת המקור גישה לחשבון הפיתוח המשויך ב-Google Play.
3. במסוף Google Admin בסביבת המקור שלכם, צריך למחוק את קישורי ה-EMM. פרטים נוספים זמינים במאמר בנושא ביטול ומחיקת נתונים.

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

אם אתם משתמשים במינוי ל-Cameyo, אתם לא יכולים לשנות את הדומיין הראשי כי המינוי חוסם שינוי של הדומיין הראשי. כדי להמשיך בתהליך שינוי הדומיין, אתם קודם כל צריכים להסיר את כל הרישיונות ל-Cameyo שמשויכים לדומיין הראשי הנוכחי ורק אז להחליף אותו בדומיין החדש.

פרטים על ההשפעה של הסרת רישיונות ל-Cameyo מופיעים במאמר הסבר על תוכנית התשלומים של Cameyo.

• חשוב לוודא שהמדיניות לגבי אילוץ הרשמה מחדש מושבתת בכל הארגונים ושביטלתם את ניהול ההקצאות בכל המכשירים.
• בנוסף לכל הרישיונות, צריך להסיר גם את המינוי לפני שמשנים את הדומיין הראשי. במקרה הצורך, אפשר לשחזר את המינוי ולרשום מחדש את המכשיר בדומיין הראשי החדש אחרי ההחלפה.
• כדי להסיר רישיונות ל-Chrome Enterprise, אפשר לפנות אל ompf-helpdesk@google.com לקבלת עזרה.

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

• אין תמיכה ב-Essentials Starter,‏ Essentials,‏ Enterprise Essentials ו-Enterprise Essentials Plus.
• במהדורות Essentials Starter,‏ Essentials,‏ Enterprise Essentials ו-Enterprise Essentials Plus אין תמיכה ברישוי דומיין בשיטה חלקית (PDL).
  • אי אפשר להוסיף רישיונות אחרים ל-Google Workspace או ל-G Suite Business או Basic לסביבת יעד שנעשה בה שימוש ברישיונות ל-Essentials Starter,‏ Essentials,‏ Enterprise Essentials ו-Enterprise Essentials Plus.
  • אי אפשר להוסיף רישיונות ל-Enterprise Essentials או Essentials לסביבת יעד שכוללת רישיונות אחרים ל-Google Workspace או ל-G Suite Business או Basic.
  • כדי שתוכלו לעמוד בדרישות להעברה, צריך לשדרג מרישיון ל-Essentials Starter, ‏ Essentials, ‏ Enterprise Essentials ו-Enterprise Essentials Plus לרישיון נתמך לפני ההעברה.

• צריך להסיר את הרישיון הזה לאחסון ב-Drive לפני תחילת תהליך ההעברה.
• אם למשתמשים יש רישיונות ל-Business Starter או ל-G Suite Basic, והרישיון לאחסון ב-Google Drive מוסר:
  • הנתונים לא יימחקו וישארו זמינים.
  • לא יהיה אפשר להוסיף במוצרים נפח אחסון מעבר למגבלת האחסון.

  הערה: אם נפח האחסון נגמר, יש לכך השלכות ספציפיות לגבי מוצרים כמו Gmail, ‏ Drive ו-Google Photos. מידע נוסף

• אם למשתמשים יש רישיונות ל-Enterprise Plus,‏ Enterprise Standard,‏ Business Plus,‏ Business Standard או ל-G Suite Business, והרישיון לאחסון ב-Drive מוסר, ההסרה לא תשפיע על המשתמשים.
• מידע נוסף על רישיונות לאחסון ב-Drive

• אין תמיכה בחיוג בינלאומי ל-Google Meet והיומנים הקיימים לא יעברו לסביבת היעד.
• במקרה הצורך, אתם יכולים להגדיר תוסף חיוג בינלאומי ל-Meet בסביבת היעד. מידע נוסף

צריך להסיר את כל המינויים למכשירים ואת כל הרישיונות לפני החלפת הדומיין הראשי בפלייסהולדר לדומיין. תוכל:

• להעביר את הרישיונות מסביבת המקור לסביבת היעד. צריך להעביר את כל הרישיונות לדומיין החדש. אי אפשר להעביר רק חלק מהרישיונות.

  מידע נוסף על העברת רישיונות

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

• אין תמיכה ב-Voice והנתונים לא יעברו מסביבת המקור אל סביבת היעד.
• הרישיון ל-Voice גם עלול לחסום את תהליך ההעברה, אפילו אם בסביבת המקור אין שימוש בו. אם הרישיון היה קיים בשלב כלשהו, אפשר יהיה להמשיך בהעברה בתנאים הבאים:
  • צריך לבטל ידנית את ההקצאה של כל המספרים ב-Voice למשתמשים, או שיכול להיות שהם יועברו.
  • צריך להסיר מהמשתמשים את כל הרישיונות ל-Voice.
  • צריך לבטל את המינוי לרישיון ל-Voice במלואו.
  • הלקוחות צריכים להסכים לכך שצוות מהנדסי התוכנה של Voice ימחק באופן סופי את כל הנתונים שנאספים בזיהוי קולי שקשורים לסביבת המקור.
• התנאים האלו נדרשים כי אם היה קיים רישיון ל-Voice בסביבת המקור, לא תהיה אפשרות לנהל ב-Voice משתמשים שהועברו בסביבת היעד. אין פתרון עקיף לבעיה הזו בשלב הזה.
• התנאים האלו חלים רק על רישיון ל-Voice ב-Google Workspace שמאפשר לאדמינים לנהל את Voice בשם המשתמשים. התנאים האלו לא חלים על משתמש יחיד שהשתמש ב-Voice בנפרד.

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

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

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

• השירות למפתחות הצפנה שהוגדר בסביבת המקור לא יועבר לסביבת היעד.
• הכלי Domain Transfer יכול להעביר קבצים מוצפנים ב-Google Drive. למרות זאת, בגלל שהשירות למפתחות הצפנה לא מועבר, לא תהיה אפשרות לפענח את המסמכים שהועברו, ולכן לא תהיה אפשרות לקרוא אותם.
• מהסיבה הזאת, ההפעלה של האפשרות הצפנה מצד הלקוח (CSE) בסביבת המקור תחסום את Domain Transfer. מידע נוסף

ספריות מותאמות אישית לא מועברות וצריך ליצור אותן מחדש ב"הארגון שלי" ב-Google Workspace בסביבת היעד.

• משתמשים שנמחקו לא מועברים.
• לא מומלץ למחוק משתמשים או לשחזר אותם בסביבת המקור במהלך 48 השעות שלפני ההעברה. מחיקה או שחזור עלולים לעכב את ההעברה.

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

• אי אפשר לשחזר משתמשים שנמחקו בסביבת המקור אחרי שההעברה מסתיימת, כי דומיין המקור שמשויך למשתמשים כבר לא קיים.

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

• רוב ההגדרות או כללי המדיניות מסביבת המקור לא נכללים בהעברה.
• זה כולל פריטים כמו הפעלת שירותים ותכונות לפי יחידה ארגונית או קבוצה, ניתוב אימייל, כללי תאימות ו-DLP, רשימות גישה ל-Google Drive או ל-OAuth, סיסמאות, אפליקציות מהימנות, SSO ל-SAML ומדינות או אזורים שבהם הנתונים נמצאים.

• עם זאת, הפריטים הבאים כן נכללים בהעברה:
  • מיפויים של כתובות URL מותאמות אישית ב-Google Sites במסוף Admin, כולל הדומיינים המשויכים, מועתקים מסביבת המקור לסביבת היעד.
• אחסונים שיתופיים בסביבת המקור מועברים ליחידה הארגונית הבסיסית להעברה ביעד. לאדמינים ביעד יש גישה לאחסונים השיתופיים, אבל יכול להיות שהגישה אליהם תהיה מוגבלת למשתמשים אחרים. תהליך ההעברה יכול לגרום לשינויים במגבלות מדיניות נוספות ברמת היחידה הארגונית או בכללים להרשאות שיתוף, אבל לא תהיה לו השפעה על רשימה של בקרת גישה של האחסון השיתופי.

• משתמשי היעד בהתאמה אישית לא עוברים מסביבת המקור לסביבת היעד.
• אם מעבירים קבצים ששותפו עם משתמשי היעד שהוגדרו כברירת מחדל בסביבת המקור, צריך לבחור איך רוצים שהקבצים המועברים ישותפו בדומיין היעד. פרטים נוספים זמינים בקטע בנושא Google Drive,‏ Docs,‏ Sheets,‏ Slides,‏ Forms ו-Drawings באפליקציות ליבה.
• משתמשי היעד שמוגדרים במסמכים של המשתמשים להעברה עדיין יהיו זמינים, אבל לא תהיה אפשרות לראות אותם או לשנות אותם דרך מסוף Google Admin בסביבת היעד.
• משתמשים שהועברו יכולים לראות את הרשאות השיתוף של משתמשי היעד, אבל תוצג אזהרה אם משתמשי היעד הם חיצוניים לארגון.
• משתמשים שהועברו יכולים לשנות או למחוק את הרשאות השיתוף. אם מסירים אותם, אי אפשר להוסיף אותם שוב כי המדיניות בסביבת היעד חלה רק על משתמשי היעד בסביבת היעד שזמינים במסגרת אפשרויות השיתוף.

מידע נוסף על משתמשי היעד

• חשבונות לא מנוהלים הם משתמשים שיצרו חשבון Google באופן עצמאי, תוך שימוש באחד מהדומיינים של הארגון. מידע נוסף זמין במאמר בנושא איתור והוספה של חשבונות לא מנוהלים.
• הזמנות בהמתנה שנשלחו לחשבונות לא מנוהלים לא מועברות מסביבת המקור לסביבת היעד.
• כשמעבירים חשבונות לא מנוהלים עם הדומיין שלהם לישות אחרת, פג התוקף של ההזמנה בהמתנה.
• אם לוחצים על ההזמנה בהמתנה, מקבלים את הודעת השגיאה הבאה "פג התוקף של ההזמנה. הקישור הקודם לאימות של כבר לא פעיל".

• קבוצות דינמיות יועברו, אבל העדכונים לחברי הקבוצה יושהו עד לעדכון התנאים לחברות בקבוצה. מידע נוסף זמין בקטע שלב 3: משימות של סביבת היעד.
• כל החברים בקבוצה בזמן ההעברה יישארו בקבוצה גם אחריה, בלי קשר לכללי החברות בקבוצה.
• קבוצות דינמיות חייבות להכיל רק משתמשים וקבוצות באותו דייר (tenant).
• יש בעיה מוכרת שקבוצות דינמיות שלא מועברות לא מתעדכנות כמו שצריך ושומרות הפניות למשתמשים ולקבוצות שהועברו, לכן לא מומלץ להשאיר קבוצות דינמיות בסביבת המקור.

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

• קבצים של Apps Script יועברו ביחד עם תוכן נוסף ב-Drive, אבל פרויקטים ב-Google Cloud שמגבים אותם לא יועברו. הפרויקטים האלו ימשיכו להיות כפופים למדיניות הארגון בסביבת המקור. מידע נוסף
• הפתרון העקיף המומלץ הוא שהמשתמשים יצרו עותק של הקבצים שלהם ב-Drive לאחר ההעברה. הפעולה הזו תיצור פרויקטים חדשים ב-Google Cloud שכפופים למדיניות הארגון בסביבת היעד.
• לאחר ההעברה האפליקציות עשויות לא לעבוד באופן תקין, והמשתמשים עשויים לראות מסכי הסכמה ל-OAuth שהם צריכים לאשר אותם כדי להריץ סקריפטים. בנוסף, יכול להיות שיופיעו שגיאות אם בסביבת היעד מוגדרת מדיניות שונה שמגבילה את ההיקפים שאפשר לבקש כשמשתמשים ב-Apps Script.

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

• צ'אטים ישירים מועברים, אבל צ'אטים קבוצתיים לא מועברים.
• המרחבים וההודעות שכלולות בהם לא מועברים.
• אם משתמש להעברה הוא מנוי במרחב בסביבת המקור, הוא יישאר מנוי במרחב הזה גם אחרי ההעברה. אבל המשתמש מוגדר בתור משתמש חיצוני והמרחב יהיה מחוץ לדייר (tenant) היעד. כלומר:
  • לא תהיה אפשרות למצוא את המרחב באפליקציות כמו Vault.
  • אם המרחב נוצר כשהאפשרות "אנשים מחוץ לארגון שלך יוכלו להצטרף" מסומנת, למשתמש שהועבר עדיין תהיה אפשרות לגשת למרחב אחרי ההעברה.
  • אם המרחב נוצר כשהאפשרות "אנשים מחוץ לארגון שלך יוכלו להצטרף" לא מסומנת, חדר הצ'אט לא יהיה גלוי למשתמש שמעביר את הבעלות בממשק המשתמש, אבל הוא יוכל לראות אותו ב-Gmail. המשתמש להעברה יוכל לראות הודעות חדשות, אבל לא יוכל לשלוח הודעות. כל משתמש שלא מועבר יכול להסיר את המשתמש להעברה מהמרחב, או שמשתמשים להעברה יכולים להסיר את החשבון שלהם. הכלל הזה רלוונטי גם לחלק מהשיחות הקבוצתיות.

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

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

אפליקציות ל-Chat

• במהלך התהליך ב-Domain Transfer, אפליקציות ל-Google Chat עשויות להפסיק להגיב, להיעלם מצ'אטים ישירים וממרחבים, או להפסיק לעבוד כצפוי.
• במקרים הבאים יכול להיות שאפליקציה תשמור על הפונקציונליות שלה ללא צורך בהעברה:
  • האפליקציה פורסמה ב-Google Workspace Marketplace.
  • מפתח האפליקציה היה חבר בסביבת היעד בפעם הראשונה שהגדרות האפליקציה נשמרו.
  • האפליקציה שותפה רק עם משתמשים מסוימים דרך כתובת האימייל שלהם, וכתובות האימייל האלו נשארו זהות לאחר המיזוג.
• אם תהליך ההעברה ישפיע על האפליקציה שלכם, ייתכן שמפַתח אפליקציות הצ'אט יצטרך להעביר אותה לפרויקט חדש ב-Google Cloud. מידע נוסף על העברת אפליקציית צ'אט

• אם אתם רוצים להעביר את המספרים ב-Voice לסביבת היעד, אפשר לעשות זאת על ידי Google.
• יש כמה מגבלות שקובעות אם אפשר להעביר מספר ב-Voice.
  • סביבת המקור:
    • המספר צורף ממקור אחר. כלומר, זה יכול להיות מספר בהמתנה או מספר שכלול בהעברה אחרת.
    • ‫Google לא מנהלת את המספר ישירות.
    • המספר כלול בקבוצת מספרים. זה כולל מספרים בשווייץ (CH), איטליה (IT) וגרמניה (DE).
  • סביבת היעד:
    • יכול להיות שלא תוכלו להיות בעלים של מספר ממדינה או אזור מסוימים. זה יכול לקרות בגלל שאין לכם גרסה מתאימה של Google Voice Enterprise, או שלא הגדרתם כתובת ראשית במדינה או באזור האלו.
    • מספר המספרים בהעברה חורג מהמגבלה שמוגדרת בדומיין היעד.
• אם אפשר לבצע את ההעברה:
  • ‫Google תתאם מולכם את המועד לתהליך ההעברה.
  • אתם לא צריכים לבטל את ההקצאה של כל המספרים מראש.
  • אתם צריכים להסכים לבצע את כל הפעולות שנדרשות על ידי Google.
  • לאחר הפעלת ההעברה, משתמשי Voice בסביבת המקור לא יוכלו לקבל שיחות במספרים שלהם עד שהתהליך ב-Domain Transfer יסתיים והמספרים יוקצו מחדש.

פרטים נוספים זמינים בקטע בנושא Google Voice בחלק רישיונות במקור.

ארטיפקטים ב-Vault (עניינים, החזקות לצורך משפטי, חיפושים ועוד):

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

• העברת דומיין ב-Google Workspace לא תעביר הרשמות לתוכניות אלפא ולתוכניות בטא.
• אם יש תוכניות ספציפיות שסביבת המקור או סביבת היעד רשומות אליהן, אבל הסביבה השנייה לא רשומה אליהן, צריך להגיש בקשה לרישום לתוכניות האלה ולקבל אישור.
• אם היעד רשום לתוכניות שמותאמות לדומיין, צריך לאשר כל דומיין מקור חדש.
• מומלץ להירשם לפני ההעברה כדי שחוויית המשתמש והתכונות הזמינות למשתמשים שמועברים יהיו זהות לאורך כל תהליך ההעברה.

חשוב

• ארגון ב-Google Cloud: בזמן ההעברה, משתמשים וקבוצות הופכים לחיצוניים לארגון ב-Google Cloud שמשויך לסביבת המקור או לפלייסהולדר לדומיין.
• לקוחות OAuth: אם יש לכם לקוחות OAuth שמוגדרים כאפליקציות פנימיות (כולל לקוחות שמשמשים לאימות באמצעות שרת proxy לאימות זהויות), לא תהיה אפשרות לאמת את המשתמשים לאחר ההעברה כי הם מוגדרים כחיצוניים לארגון המשויך ב-Google Cloud. לפני ההעברה, מומלץ לבדוק אם כדאי להגדיר את הלקוחות כחיצוניים או להוסיף את המשתמשים כבודקים ולא לפרסם באופן חיצוני.

השפעות

• פרויקטים ב-Google Cloud יישארו בארגון שמשויך לסביבת המקור.
• שם הצומת של הארגון ישתנה לשם הפלייסהולדר לדומיין אחרי שמתבצעת ההחלפה עם הדומיין הראשי. יכול להיות שיחלפו כמה ימים עד שהשינוי הזה יעודכן.
• אפשר לשמור את סביבת המקור כדי לנהל את הארגון שמשויך ב-Google Cloud. למרות זאת, התהליך ב-Domain Transfer הופך את סביבת המקור ללא מתאימה לשימוש ב-Google Workspace כסביבת ייצור.
• הרשאות לניהול זהויות והרשאות גישה (IAM) למשתמשים ולקבוצות Google לא יושפעו.
• פרויקטים ב-Google Cloud שמצורפים לקבצים ב-Apps Script יישארו בסביבת המקור.

נקודות מעקב

צריך לבדוק ולהתאים את הפריטים הבאים כדי לוודא את הרציפות לאחר השלמת ההעברה:

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

העברה ל-Google Cloud

• מיגרציה של פרויקטים ב-Google Cloud עשויה להיות תהליך מורכב, בהתאם לאופי של הפרויקטים. אם נדרש לבצע מיגרציה, אפשר לבצע אותה לפני או אחרי תהליך ההעברה. עם זאת, לא מומלץ לבצע את שני התהליכים באותו הזמן.

  איש הקשר שלכם לגבי Google Cloud יכול לקשר אתכם לצוות ב-Google שמנהל את תהליכי המיגרציה של פרויקטים ב-Google Cloud.

• כללי המדיניות וההגדרות לא מועברים. לאחר ההעברה, כללי המדיניות בסביבת היעד חלים על המשתמשים שהועברו.
• אם בסביבת המקור מוגדר ניהול מתקדם של מכשירים ניידים במכשירי Android, הסביבה לא עומדת בתנאים להעברה והיא לא תופעל. במקרים מסוימים, כל האפליקציות שאינן אפליקציות מערכת עשויות להיות מוסרות אצל חלק מהמשתמשים, במהלך ההעברה מסביבת המקור שמוגדר בה ניהול מתקדם של מכשירים ניידים עבור מכשירי Android.
• מידע נוסף על ניהול נקודות קצה ב-Google

• מכשירי Chromebook וציוד ל-Meet שרשומים בסביבת המקור לא מועברים. צריך להסיר את המכשירים מסביבת המקור ולהקצות אותם מחדש בסביבת היעד. בקישורים הבאים תוכלו לקבל מידע נוסף על מכשירי Chrome ועל ציוד ל-Meet.
• יש נושאים נוספים לגבי רישיונות שחשוב לשים לב אליהם. פרטים נוספים מופיעים בקטעים בנושא ציוד ל-Meet במאמר רישיונות במקור.
• מכשירי Chrome שמשויכים אוטומטית לארגון לא מועברים. פרטים על השלבים הבאים מופיעים בקטע בנושא מכשירי Chrome שרשומים דרך הארגון בקטע שלב 1: משימות במקור.

Looker Studio – הרשאות שיתוף של מקור נתונים או דוח. פרטים נוספים זמינים בקטע שלב 3: משימות בסביבת היעד.

• שירותים שהוקצו למשתמשים עשויים להמשיך לפעול כצפוי. לדוגמה, ב-YouTube, המשתמשים שולטים בכל תהליכי הבעלות והאימות, ולא הארגון.
• השירותים הבאים היו חלק מההעברות הקודמות. למרות שלא דווח על בעיות רציניות, ההתנהגות בעבר לא מנבאת את ההתנהגויות בהווה או בעתיד:
  • Campaign Manager
  • Display & Video 360
  • Google Ads
  • Google Analytics
  • ‫Google Play (חנות ומערכת אקולוגית)
  • Search Ads 360
  • YouTube

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

• אין תמיכה בשירותי EMM שמשמשים לאבטחת נתונים ארגוניים במכשירים הניידים של העובדים.
• כולל טכנולוגיות כמו:
  • BlackBerry EMM
  • Citrix XenMobile
  • IBM MaaS360
  • Microsoft Enterprise Mobility + Security
  • MobileIron
  • VMware AirWatch

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