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

אין תמיכה ב-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 בסביבת היעד. מידע נוסף

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף זמין בקטע בנושא Google Voice בחלק רישיונות במקור.

• העברת דומיין ב-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.
• יש עוד נושאים שחשוב לשים לב אליהם לגבי רישיונות. פרטים נוספים מופיעים בקטעים בנושא ציוד ל-Google 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

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