פתרון בעיות ב-GWMME

הסיבה לבעיה יכולה להיות:

• שרת Exchange לא פועל.
• בעיה ברשת חוסמת את החיבור בין מכונת הלקוח לבין שרת Exchange. כדי לאמת את החיבור, שולחים פינג לשרת ממכונת הלקוח.
• השתמשתם בשם שגוי של שרת Exchange או של האדמין. כדי לאמת את המידע הזה:
  1. במחשב הלקוח, לוחצים על לוח הבקרה דואר כדי ליצור פרופיל של Microsoft Outlook לחשבון האדמין שרוצים להשתמש בו להעברה.
  2. ב-GWMME, במסך Step 1 (פרטי השרת):
     • בשדה שם המארח/כתובת ה-IP, מזינים את שם המארח של Exchange מהפרופיל.
     • בשדה Admin username (שם משתמש של אדמין), מזינים את שם המשתמש מהפרופיל.

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

מוודאים שהזנתם את השם והסיסמה הנכונים של האדמין.

אם הבעיה נמשכת, צריך לוודא שהזנתם את השם הנכון של שרת Exchange:

1. במחשב הלקוח, לוחצים על לוח הבקרה דואר כדי ליצור פרופיל Outlook לחשבון האדמין שבו רוצים להשתמש להעברה.
2. ב-GWMME, במסך Step 1 (פרטי השרת):
   • בשדה שם המארח/כתובת ה-IP, מזינים את שם המארח של Exchange מהפרופיל.
   • בשדה Admin username (שם משתמש של אדמין), מזינים את שם המשתמש מהפרופיל.

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

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

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

0x80040109
Fail:While stamping the message

למרות שההודעות הועברו, הכלי GWMME לא שמר את המידע שההעברה הושלמה. אם מריצים מחדש העברה עם הסימון Only New Data (נתונים חדשים בלבד), הכלי GWMME מנסה להעביר את ההודעות האלה שוב. ההודעות לא ישוכפלו, אבל יכול להיות שיהיו כפילויות של אירועים ביומן או אנשי קשר.

אם ההעברה לא מצליחה עבור משתמש מסוים, צריך לוודא:

• הפורמט של השם או כתובת ה-SMTP של המשתמש בקובץ המשתמשים תקין.
• המשתמש לא מוסתר ברשימת הכתובות הכללית (GAL).
• למשתמש יש חשבון בשרת Exchange.
• המשתמש נכנס ל-Google Workspace, אישר את התנאים וההגבלות וסיים את יצירת חשבון Google Workspace שלו.

השלבים הבאים לפתרון בעיות אמורים לפתור את כל שגיאות האימות של GWMME OAuth:

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

GWMME לא מקצה משתמשים ב-Google Workspace. צריך ליצור את חשבונות המשתמשים ב-Google Workspace לפני שמבצעים העברת נתונים.

במקרה הזה, השנה בתאריך הנוכחי של המכונה שונתה ל-2022, ולכן נראה שהאישור לא עדכני. אפשר לראות את התאריך הנוכחי בתחילת כל שורה ביומן, והתאריכים Valid from ו-Valid until של האישור לא תואמים לתאריך הנוכחי. דגל השגיאה WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED מציין שהבדיקה של ביטול האישור נכשלה.

אפשר גם לראות את כתובת ה-IP של היעד ואת שם המארח שנפתר אחרי 'Network connection destination details' בשורה האחרונה של היומן. זהו 1e100.net address, כלומר הוא שייך ל-Google.

2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2025 ()> Secure connection failure. Status: 0x00010000. Info 0x00000009
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2030 ()> Failure details:
WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable.
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA: The function is unfamiliar with the Certificate Authority that generated the server's certificate.
Certificate details:
---Validity--
Valid from: 2016-09-20T04:08:45.000Z
Valid until: 2022-09-20T04:08:45.000Z
---Subject---
Created by http://www.fiddler2.com
DO_NOT_TRUST
*.google.com
---Issuer----
Created by http://www.fiddler2.com
DO_NOT_TRUST
DO_NOT_TRUST_FiddlerRoot
-------------
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2071 ()> Error result 5, hr = 0x80072f8f. Setting event 0000000000001638.
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2076 ()> Network connection destination details: 127.0.0.1:8888 (COMPUTERNAME)

במקרה הזה, Fiddler הותקן והוגדר לבצע פענוח של HTTPS (כלומר, הוא משתמש באישור משלו), אבל האישור שלו הוסר מרשימת האישורים המהימנים של Windows, ולכן הוא לא מהימן. שימו לב: מכיוון ש-Fiddler הוא שרת proxy, הוא התחבר ל-127.0.0.1 ולא ל-Google. דגלי השגיאה כוללים את WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA, שמשמעותו היא שהמערכת לא בוטחת ברשות האישורים (CA). שימו לב גם ש-Google לא הנפיקה את האישור הזה.

הודעת שגיאה דומה לזו מופיעה במסך הפלט או בקובץ יומן המעקב:

E:Generic ExchangeMigration!SetPropertyGuid @ 641 (user@example.com)> Failed with 0x80070005, last successful line = 637.

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

אם לחשבונות יש הרשאת קבלת הודעות בשם והשגיאה נמשכת, יכול להיות שבסביבת Exchange נדרש שלחשבונות המשתמשים תהיה גם הרשאת שליחת הודעות בשם.

חלק מהמשתמשים לא יכולים לבצע העברה מ-Exchange 2010, והם מקבלים שגיאות מסוג Failed with 0x80004005 בקובץ יומן המעקב. היומנים כוללים גם:

• קריאות MAPI אקראיות ל-Exchange 2010.
• שגיאות מסוג 'BufferTooSmall' ביומן הגישה של הלקוח לקריאה לפרוצדורה מרוחקת (RPC) בשרת הגישה של הלקוח ב-Exchange Server 2010.RPC

זו בעיה ידועה ב-Exchange 2010, ב-Outlook 2007 וב-Outlook 2010. יכול להיות שתצטרכו לעדכן ל-Exchange 2010 SP2 RU3. למידע נוסף, אפשר לעיין במסמכי העזרה של מיקרוסופט בנושא שגיאות של קריאות MAPI שנכשלו.

אם יש לכם הרבה מקרים של קודי שגיאת HTTP‏ 500, 502 ו-503 ביומנים וההודעות לא מועלות עם קוד השגיאה 0x8004106a, יכול להיות שיש בעיה בתיבת הדואר של היעד. בדרך כלל הסיבה לכך היא עומס גבוה.

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

• משביתים את כל תוכנות הסנכרון (כמו IMAP,‏ POP, מכשירים ניידים ותוכנות אימייל).
• אפשר להעביר הודעות רק ממקור אחד בכל פעם.

הבעיות הבאות מצביעות על כך שהמשתמשים לא הוקצו בצורה נכונה:

• שינויים באירוע ביומן לא משותפים עם המשתתפים.
• התראות ועדכונים ביומן לא מועברים ליומנים של המשתתפים.

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

כברירת מחדל, הכלי GWMME מעביר נתונים בקצב של 25 משתמשים בשנייה. הקצב הזה חורג ממספר השאילתות לשנייה (QPS) שמוגדר כברירת מחדל גם ל-Contacts API וגם ל-Calendar API.

כדי לפתור את הבעיה, מריצים העברות של אנשי קשר ויומנים:

• בנפרד מהעברות של אימיילים.
• בשיעור נמוך יותר של 4 עד 8 משתמשים לשנייה.

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

יכול להיות שתצטרכו גם להסיר את מגבלות הגודל של התיקיות ולוודא שהתיקיות מוצגות ב-IMAP. פרטים נוספים זמינים במאמר בנושא הפעלה והשבתה של POP ו-IMAP למשתמשים.

‫Google Workspace מעריך את מספר ההודעות בתיבת הדואר הנכנס אחרי מיגרציה. הוא לא מספק ספירה מוחלטת. יכול להיות שמספר ההודעות שמוצג בתיבת הדואר הנכנס ב-Gmail יהיה שונה ממספר ההודעות בתיבת הדואר הנכנס בגרסה הקודמת של Gmail.

אם לדעתכם חסרות לכם הודעות, כדאי לבדוק אם:

• ההודעה, כולל הקבצים המצורפים, לא גדולה מ-25MB. אי אפשר להעביר הודעות שגדולות מ-25MB. פרטים נוספים זמינים במאמר שליחת קבצים מצורפים עם הודעה ב-Gmail.
• ‫Gmail לא חוסם קובץ שמצורף להודעה. מערכת Gmail מונעת צירוף של סוגים מסוימים של קבצים, כמו קבצים להפעלה. פרטים נוספים מופיעים במאמר סוגי הקבצים שנחסמים ב-Gmail.
• ההודעה נמצאת בתיקייה או בטווח תאריכים שכלולים בהעברה.

הודעות חסרות או הודעות שהועברו עם שולח או נמען שגויים יכולות להתרחש בהעברות של קובצי Exchange או PST. יכול להיות שכתובת ה-SMTP של השולח או הנמען של ההודעה חסרה, ובמקומה נעשה שימוש בכתובת X.500 של Exchange. זה יכול לקרות אם לא נוצר פרופיל ברשימת הכתובות הגלובלית (GAL) או אם המשתמש הוסר מה-GAL.

מה קורה כש-GWMME מוצא כתובת X.500

כש-GWMME מוצא כתובת X.500, הוא מחפש פרופיל אימייל של MAPI שרשום בשרת ההעברה ומתאים לאותו שם ארגון Exchange בפורמט X.500. אם נמצאה כתובת כזו, GWMME יפתור את כתובת X.500 באמצעות רישום פנקס הכתובות בפרופיל הדואר של MAPI.

אם GWMME לא מוצא את המידע הזה בפנקס הכתובות של Exchange, הוא מנסה להמיר את כתובת X.500 לכתובת SMTP. כדי לעשות את זה, המערכת מתייחסת לערך CN האחרון של כתובת X.500 ומשתמשת בו כשם המשתמש של כתובת האימייל. לדוגמה, כתובת X.500‏ ‎ /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS מובילה לכתובת האימייל ex_alias@example.com ב-SMTP.

איך משתמשים בפנקס הכתובות של Exchange כדי לפתור את הבעיה שקשורה לכתובת X.500

1. יוצרים פרופיל אימייל MAPI (לא במצב מטמון) בשרת שמבצע את ההעברה.
2. מוודאים שפרופיל האימייל של MAPI מוגדר בשרת שמשמש לביצוע ההעברה של קובצי PST.
3. פרופיל הדואר של MAPI צריך להיות מחובר לשרת Exchange המקורי כדי ש-GWMME יוכל לפתור את הנמענים בצורה תקינה באמצעות GAL.
4. כדי למנוע שגיאות אימות, צריך להגדיר את פרופיל הדואר של MAPI באמצעות המשתמש או חשבון השירות שמחוברים כרגע.

הערה חשובה

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

יכול להיות שבהודעות שהועברו יוצגו השעה והתאריך של ההעברה, ולא השעה והתאריך של ההודעה המקורית.

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

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

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