הגירת PST ל-Microsoft 365 לחברות טכנולוגיה: AzCopy מול Outlook Import, מקרה בוחן 60GB
בעולם הסטארטאפים, ה-IT צריך לתמוך בצמיחה (Scale) בלי להתפשר על אבטחה. המאמר הזה מנתח איך עושים את זה נכון.
TL;DR, בקצרה
- 📦 הגרנו משרד עורכי דין מ-POP3/IMAP ל-Microsoft 365, כולל תיבת דואר "לוויתן" של 60GB
- 🚀 השתמשנו ב-AzCopy + Purview Network Upload במקום ב-Outlook Import הידני, ובצדק
- 🧠 פיצלנו את העבודה ל-שתי משימות ייבוא נפרדות, Quick Wins ו-Heavy Lifter
- ✅ אפס אובדן נתונים. אפס Downtime. הלקוח עבד כרגיל למחרת בבוקר.
בוא נדבר בגובה העיניים. אם אתה MSP שמבצע הגירות דואר ללקוחות, אתה מכיר את הסיפור הזה: הלקוח רוצה לעבור ל-Microsoft 365, יש לו "קצת היסטוריה" בתיבת הדואר, ואתה חושב, "אין בעיה, נייבא PST ונגמור עם זה."
ואז אתה מגלה שה"קצת היסטוריה" הזו שוקלת 60 גיגה. ושהלקוח הוא משרד עורכי דין, שבו כל מייל הוא מסמך משפטי שלא ניתן לאבד. ושאין לך חלון תחזוקה של יותר מלילה אחד.
זה המקום שבו Outlook Import הופך מ"פתרון" למוקש, ו-AzCopy עם Purview Network Upload הופכים להנשק האסטרטגי.
הבעיה: למה Outlook Import זה "צינור גינה"
נתחיל מהבסיס. כשאתה מייבא PST דרך Outlook (File → Open & Export → Import/Export), בעצם קורה הדבר הבא:
Outlook Import, "צינור הגינה"
- • קובץ ה-PST נקרא מקומית מהמחשב
- • כל פריט נשלח אחד אחד דרך חיבור ה-Outlook לשרת
- • המחשב חייב להיות דלוק כל הזמן
- • Outlook חייב להיות פתוח, אי אפשר לעבוד
- • אם הרשת נופלת, מתחילים מחדש
- • קובץ 60GB? מדברים על ימים, לא שעות
- • אין שום לוג, אם משהו נכשל, אתה לא יודע מה
AzCopy + Purview, "צינור הכיבוי"
- • ה-PST עולה ל-Azure Storage ישירות
- • ההעלאה רצה ברקע, המחשב חופשי
- • אחרי ההעלאה, הייבוא הוא Server-to-Server
- • Microsoft מעבד את הקובץ בענן
- • Resumable, אם הקשר נופל, ממשיכים מאיפה שעצרו
- • קובץ 60GB? שעות ספורות להעלאה + עיבוד אוטומטי
- • לוגים מלאים בממשק Purview, פריט בפריט
בשורה התחתונה: Outlook Import הוא כלי שמתאים לתיבה של 2GB של מנהלת חשבונות שרוצה להעביר כמה מיילים ישנים. כש-MSP מטפל בהגירה של ארגון שלם, עם תיבות של עשרות גיגה ודרישה לאפס אובדן נתונים, זה חובבנות.
המשימה: מה עמד מולנו
הלקוח, משרד עורכי דין, עבד שנים על ספק דואר מקומי (POP3/IMAP). ההחלטה נפלה לעבור ל-Microsoft 365, עם Exchange Online ואבטחת מידע ברמה שמתאימה לאופי הרגיש של העבודה.
מפת השטח:
📧 תיבות "רגילות"
5-8 תיבות בגודל של 2-8GB כל אחת. Shared Mailboxes ומשתמשים קטנים. ניתן לטפל בהם ביחד, "Quick Wins".
🐋 "הלוויתן"
תיבת דואר אחת של השותף הבכיר, 60GB. שנים של התכתבויות משפטיות, מסמכים מצורפים, וארכיון שלא ניתן לגעת בו. כל פריט הוא קריטי.
⚠️ הבעיה: מגבלת 50GB
Exchange Online Plan 1 מגיע עם מגבלה של 50GB לתיבת דואר. הלוויתן שלנו שוקל 60GB. אי אפשר פשוט "לדחוף" את זה פנימה.
הפתרון:
- • שדרוג לרישיון Exchange Online Plan 2 (מגבלה של 100GB)
- • הפעלת Online Archive (מוסיף עד 1.5TB של אחסון ארכיון)
- • פיצול הייבוא: תיבה ראשית + תיבת ארכיון, עם קובצי PST נפרדים
האסטרטגיה: "הרוטב הסודי" של MSP אמיתי
העלאה עם AzCopy, הכנת השטח
הצעד הראשון הוא להעלות את כל קובצי ה-PST ל-Azure Storage דרך Microsoft Purview → Data Lifecycle Management → Import. בממשק הניהול, יוצרים Import Job חדש, ומקבלים SAS URL (Shared Access Signature), כתובת זמנית ומאובטחת שמאפשרת העלאה.
# העלאת קובצי PST עם AzCopy
# שימו לב: ב-PowerShell חייבים .\ לפני הפקודה
.\azcopy.exe copy "C:\PST-Files" "https://xxxxxxxxx.blob.core.windows.net/ingestiondata?sv=xxxx&se=xxxx&sp=rwl&sig=xxxxxxxxx" --recursive
# פלט מוצלח:
Number of Transfers Completed: 8
Number of Transfers Failed: 0
Final Job Status: Completed
💡 טיפ חשוב: אם אתה מריץ את AzCopy מ-PowerShell ומקבל שגיאה, וודא שאתה משתמש ב-.\azcopy.exe עם הנקודה-אחורה-סלש בהתחלה, ולא סתם azcopy. זו טעות קלאסית שמבזבזת 20 דקות של Debugging.
פיצול עבודות, הטריק שחוסך שעות
זו הנקודה הקריטית ביותר, והיא מה שמפריד בין MSP שעושה הגירות לבין מישהו שמנסה לראשונה.
כשאתה יוצר Import Job ב-Purview, יש שלב שנקרא "Analysis", מייקרוסופט סורקת את כל קובצי ה-PST שהעלית ומוודאת שהם תקינים. שלב הניתוח הזה לוקח זמן, והוא רץ על כל הקבצים ב-Job ביחד.
למה לפצל?
❌ Job אחד לכולם
קובץ ה-60GB מאט את שלב הניתוח (Analysis) של כל ה-Job. תיבות קטנות של 2-3GB שיכלו להיות מוכנות תוך שעה, ממתינות שעות עד שהלוויתן מסיים ניתוח.
✅ שני Jobs נפרדים
Job 1, "Quick Wins": כל התיבות הקטנות + Shared Mailboxes. מסיים Analysis מהר → מתחיל ייבוא מיד.
Job 2, "Heavy Lifter": רק ה-60GB. רץ במקביל, לוקח את הזמן שלו, בלי לעכב אף אחד.
התוצאה: בזמן שהלוויתן עדיין בשלב ניתוח, כל שאר המשתמשים כבר סיימו ייבוא ועובדים עם המייל ההיסטורי שלהם. הלקוח מרגיש שהעבודה מתקדמת, ואתה לא תקוע בהמתנה.
קובץ Mapping, לוגיקה של Primary vs. Archive
קובץ ה-Mapping (CSV) הוא מה שאומר ל-Purview לאן לייבא כל PST. העמודה הקריטית: IsArchive.
# קובץ CSV לדוגמה (Mapping File)
Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,SPFileContainer,SPManifestContainer,SPSiteUrl
Exchange,,user1-primary.pst,user1@client-domain.co.il,FALSE,/,,,,
Exchange,,user1-archive.pst,user1@client-domain.co.il,TRUE,/,,,,
Exchange,,shared-info.pst,info@client-domain.co.il,FALSE,/,,,,
Exchange,,partner-main.pst,partner@client-domain.co.il,FALSE,/,,,,
Exchange,,partner-archive.pst,partner@client-domain.co.il,TRUE,/,,,,
IsArchive = FALSE
הנתונים נכנסים לתיבה הראשית. זה הדואר ה"חי" שהמשתמש רואה ב-Outlook מיד.
IsArchive = TRUE
הנתונים נכנסים לOnline Archive. זה הארכיון שנגלל אוטומטית מתחת לתיבה הראשית ב-Outlook.
ה-"Gotchas", הדברים שלא כתובים בתיעוד
כל MSP שעשה הגירת PST מכיר את הרגע שבו הכל נראה בסדר, אבל משהו... לא מסתדר. הנה המלכודות שפגשנו:
Gotcha #1: "הנתונים הנעלמים", הם שם, רק מוסתרים
אחרי שהייבוא הסתיים "בהצלחה" (סטטוס: Completed), פתחנו את Outlook ו... התיבה נראתה ריקה. פאניקה לשנייה.
מה באמת קרה: Purview מייבא את הנתונים לתוך מבנה התיקיות הקיים. אם הייתה תיקיית "Inbox" ב-PST, הנתונים התמזגו עם ה-Inbox הקיים. זה נראה כאילו שום דבר לא נוסף, כי המיילים החדשים מופיעים ממוינים לפי תאריך מקורי, כלומר, הם "קבורים" בתחתית, לפי השנה שלהם.
✅ הפתרון:
- • מיינו לפי תאריך מהישן לחדש, תראו את הנתונים המיובאים
- • בדקו את רשימת התיקיות, תיקיות חדשות מה-PST אמורות להופיע
- • בדקו את גודל התיבה ב-Admin Center, זה המספר שלא משקר
Gotcha #2: ה-Archive חייב להיות מוכן לפני ה-Validation
אם יש לך שורות ב-Mapping עם IsArchive = TRUE, אבל ה-Online Archive לא הופעל עדיין על המשתמש, ה-Validation ייכשל, וה-Import Job ייתקע.
✅ הפתרון:
- • לפני שאתה מתחיל את ה-Import Job, הפעל Archive לכל המשתמשים הרלוונטיים
- • ודא שה-Archive מופיע ב-Exchange Admin Center (לפעמים לוקח כמה דקות)
- • תן ל-Archive שם ברור, זה מה שהמשתמש רואה ב-Outlook
Gotcha #3: שגיאת ה-PST Path ב-Mapping
עמודת FilePath בקובץ ה-CSV צריכה להכיל את הנתיב היחסי ב-Azure Storage, לא את הנתיב המקומי. אם העלית ישירות ל-root, משאירים אותה ריקה. אם העלית לתת-תיקייה, מציינים אותה בלי "/" בהתחלה.
דוגמה:
אם השתמשת ב-azcopy copy "C:\PST-Files" ..., הקבצים נמצאים ב-root, וה-FilePath צריך להיות ריק.
אם השתמשת ב-azcopy copy "C:\PST-Files\subfolder" ..., ה-FilePath הוא subfolder.
ה-Cutover: החלפת רשומות MX ומניעת "מוח מפוצל"
ברגע שכל ה-PSTs מיובאים ותיבות הדואר מוכנות ב-Exchange Online, הגיע הרגע הקריטי: החלפת רשומות ה-MX.
🧠 מה זה "Split Brain" ולמה זה מסוכן?
כל עוד רשומות ה-MX מצביעות על השרת הישן, דואר חדש מגיע לשם, אבל המשתמשים כבר מחוברים ל-Microsoft 365. התוצאה: מיילים חדשים "נעלמים" (הם בשרת הישן), תשובות יוצאות מ-365, ונוצר כאוס.
לכן: ברגע שה-Import Jobs סיימו, מחליפים MX מיד. אין "נמתין ליום ראשון." כל שעה שמחכים = שעה של Split Brain.
🔄 טיפול ב-"Gap", מיילים שנפלו באמצע
בין הרגע שייצאנו את ה-PST מהשרת הישן לבין הרגע שהחלפנו את ה-MX, נכנסו מיילים חדשים לשרת הישן. איך מטפלים?
- 1️⃣ חיבור IMAP ב-Outlook: מוסיפים את חשבון השרת הישן כחשבון IMAP נוסף ב-Outlook של המשתמש
- 2️⃣ Drag & Drop: גוררים את המיילים מתיקיות ה-IMAP לתיקיות המקבילות ב-Exchange Online
- 3️⃣ ניתוק IMAP: אחרי שווידאנו שהכל עבר, מסירים את החשבון הישן
חלופה: אם ה-IMAP של הספק הישן לא נגיש, אפשר לייצא PST קטן (רק של הימים האחרונים) ולייבא אותו בנפרד דרך Purview.
📋 Cutover Checklist
- ☑️ כל ה-Import Jobs בסטטוס Completed
- ☑️ וידוא גודל תיבות ב-Admin Center תואם ל-PST שיובאו
- ☑️ פתיחת Outlook וסריקה ויזואלית של תיקיות
- ☑️ שינוי רשומות MX ל-Microsoft 365
- ☑️ עדכון רשומות SPF, DKIM, DMARC
- ☑️ בדיקת שליחה וקבלה, פנימית וחיצונית
- ☑️ סגירת ה-Gap: העברת מיילים שנכנסו לשרת הישן
- ☑️ תקשורת ללקוח: "אתם ב-Microsoft 365. ברוכים הבאים."
ציר הזמן של הפרויקט
הכנה: הקמת חשבונות M365, הקצאת רישיונות (Plan 2 ללוויתן), הפעלת Archive, ייצוא PST מהשרת הישן
העלאה: AzCopy upload של כל ה-PSTs. יצירת שני Import Jobs (Quick Wins + Heavy Lifter). התחלת Analysis.
ייבוא: Quick Wins סיימו Analysis → התחלת Import. Heavy Lifter עדיין ב-Analysis (צפוי).
Cutover: Quick Wins: Import Complete. Heavy Lifter: Import Started → Completed. שינוי MX. טיפול ב-Gap. הלקוח חי ב-M365.
לקחים מהשטח
תכנן את הרישוי מראש
אל תגלה באמצע ההגירה שהתיבה לא נכנסת. בדוק גדלים, קנה Plan 2 למי שצריך, הפעל Archive, לפני שאתה מתחיל.
פצל תמיד לפי גודל
לא משנה כמה תיבות יש. אם יש תיבה אחת שגדולה משמעותית מהשאר, תן לה Job נפרד. זה חוסך שעות ומונע תסכול.
אל תסמוך על Outlook, סמוך על Admin Center
Outlook מציג מה שהוא רוצה. גודל תיבה, מספר פריטים, סטטוס ייבוא, בודקים תמיד ב-Admin Center ו-Purview.
MX Records, אין פשרות
ברגע שהייבוא הושלם, מחליפים MX מיד. כל דקה של Split Brain היא דקה שבה מיילים הולכים לאיבוד או נשלחים מהמקום הלא נכון.
Outlook Import vs. AzCopy, השוואה
| קריטריון | Outlook Import | AzCopy + Purview |
|---|---|---|
| מהירות (60GB) | ימים (2-5) | שעות (4-12) |
| המחשב חופשי? | ❌ | ✅ |
| Resumable | ❌ | ✅ |
| לוגים מפורטים | ❌ | ✅ |
| יכולת Scale | תיבה אחת בכל פעם | עשרות/מאות במקביל |
| תמיכה ב-Archive | ⚠️ ידני | ✅ IsArchive flag |
| מתאים ל-MSP? | לא. | בהחלט. |
סיכום: מה מפריד "תומך IT" מ-MSP אמיתי
כל אחד יכול לפתוח Outlook וללחוץ "Import". זה לא דורש ידע, ניסיון, או תכנון. זה מה שעושה מישהו שגוגל את הפתרון באמצע הלילה.
MSP מקצועי? הוא מבין את ה-Pipeline מקצה לקצה. הוא יודע מתי לפצל Jobs, איך לתכנן רישוי, מה לוודא לפני ה-Validation, ואיך לטפל ב-Gap. הוא לא "מנסה", הוא מבצע, עם תוכנית, כלים, ותיעוד.
השורה התחתונה:
- ✅ AzCopy + Purview, הכלי הנכון להגירת PST בקנה מידה
- ✅ פיצול עבודות, אסטרטגיה, לא פשרה
- ✅ תכנון רישוי, לפני, לא אחרי שנתקעים
- ✅ Cutover מיידי, Split Brain הוא לא אופציה
מוכנים ל-Due Diligence הבא שלכם?
המומחים שלנו ב-SouliTEK ישמחו לבצע סקירה מקצועית ולהתאים עבורכם תוכנית פעולה.