שירות Domain Transfer Divestiture של Google Workspace לא יכול להעביר עניינים והחזקות לצורך משפטי ב-Google Vault. במקום זאת, אדמינים בסביבות המקור והיעד צריכים לפעול לפי השלבים הבאים כדי להעביר פריטים ב-Vault.
לפני שמתחילים
שימוש ב-Vault API – כדי להעביר עניינים והשעיות ב-Vault, צריך להשתמש ב-Vault API. אי אפשר לבצע את הפעולות האלה דרך ממשק המשתמש של Vault. פרטים על ה-API מופיעים במאמר בנושא Google Vault API.
טיפ: אפשר להשתמש ב-Google Apps Manager (GAM), כלי של צד שלישי לשורת הפקודה, כדי לקבל עזרה בשימוש ב-Vault API. הכלי זמין ב-GitHub.
שלב 1: הורדת עניינים והשעיות
כדי לבצע את המשימה הזו, אתם צריכים להיות סופר-אדמינים ב-Google Workspace או אדמינים ב-Vault.
אחרי ההעברה, לא תהיה לכם גישה לעניינים ולהקפאות ב-Vault בסביבת המקור. כדי לשמור על הגישה במהלך תהליך ההעברה, צריך להוריד את התיקים וההשעיות מסביבת המקור לפחות שבוע לפני ההעברה. כדי לעשות זאת, משתמשים בשיטות ובפרמטרים של ה-API שמופיעים בטבלאות הבאות:
| הורדת מסמכים | |
| השיטה של ה-API |
matters.list רשימת התיקים שלמשתמש יש גישה אליהם. מידע נוסף |
| פרמטרים | view: FULL
מציין אילו חלקים מהעניין יוחזרו בתגובה. state: OPEN הצגת רשימה של עניינים פתוחים בלבד. אי אפשר ליצור עניינים במצב closed או deleted. אם רוצים לכלול את העניינים, צריך להוסיף אותם כ-open, ואז לסגור או למחוק אותם. |
| הורדה של השעיות | |
| השיטה של ה-API |
matters.holds.list הצגת רשימה של כל ההשעיות לצורך משפטיות בתיק. טוקן דף ריק ב-ListHoldsResponse מציין שאין יותר השעיות להצגה. מידע נוסף |
| פרמטרים | view: FULL_HOLD
מציין אילו חלקים של ההקפאה יוחזרו. |
שלב 2: ניקוי של עניינים והשעיות שהורדו
אחרי שמורידים את העניינים וההשעיות, צריך לנקות אותם כך שיכללו רק משתמשים להעברה.
הסרת הפניות לישויות שלא מועברות, כמו משתמשים, קבוצות ותיקיות משותפות. בדומה לשלבים שלפני ההעברה, תצטרכו להסיר את כל ההפניות לישויות שלא ניתן להעביר כדי להעלות עניינים והשעיות בדייר היעד.
שלב 3: העלאת עניינים והקפאות
עניינים
| השיטה של ה-API | matters.create
יוצר עניין עם השם והתיאור שצוינו. המצב ההתחלתי הוא פתוח, והבעלים הוא מבצע הקריאה ב-method. מחזירה את העניין שנוצר עם תצוגת ברירת המחדל. מידע נוסף |
עוד דברים שכדאי לזכור:
- חשוב לרשום את מזהה הטיפול החדש שנוצר. כך אפשר לשמור על מיפוי בין מספר התיק במאגר בסביבת המקור לבין מספר התיק במאגר בסביבת היעד.
- אין אילוץ ייחודיות על שמות של עניינים. אם יש לכם עניינים שנכשלו בסביבת המקור ואתם מנסים ליצור אותם מחדש ביעד (במצב לא נכשל), יכול להיות שייווצרו עניינים כפולים.
- כשמבצעים העלאה, המשתמש שמבצע את ההעלאה הופך לבעלים. מידע נוסף על התחזות למשתמשים באמצעות חשבון שירות
החזקות
| השיטה של ה-API | matters.holds.create
יצירת הקפאה בעניין שצוין. מידע נוסף |
עוד דברים שכדאי לזכור:
- השמות הייחודיים של ההשעיות נאכפים במסגרת עניין, כך שאין צורך לדאוג לגבי העלאת כפילויות.
- חשוב לרשום את מזהה ההשעיה החדש שנוצר. היא מאפשרת לכם לשמור על מיפוי בין מזהה ההשעיה של סביבת המקור לבין מזהה ההשעיה של סביבת היעד.
- אם מספר החשבונות בהקפאה עולה על מגבלת החשבונות שאפשר להוסיף בזמן היצירה, אפשר להוסיף עוד חשבונות בנפרד להקפאה אחרי שהיא נוצרה. אפשר להשתמש ב-method matters.holds.accounts.create של ה-API. מידע נוסף
שלב 4: ממתינים 24 שעות
אחרי שההעלאה מסתיימת, צריך להמתין לפחות 24 שעות כדי לוודא שההקפאות החדשות הועברו לכל המשתמשים הרלוונטיים.