בואו נודה בזה, קשה לנו לטפל בקבצי PST – לאף אחד אין צורת עבודה אחידה (חוץ מללקוחות שאני מנחה, ככה לפחות אני מאמין, וייתכן שעוד כמה אחרים…), חלק עצלים מדי בשביל לגעת בסוגיה הזו – "אם זה עובד, אל תיגע, גם ככה אני נותן לכל עובד בארגון 300MB וזה צריך להספיק לו", חלק חוששים לבצע זאת – בין אם הפחד משינוי תפיסת העבודה או מחוסר הידיעה של מה יקרה ביום שאחרי (החל מהיבטי נפחי האחסון שנזדקק להם ב- Exchange, ברישוי, במידה ונרצה להפעיל Personal Archive של Exchange 2010/2013 או להפעיל פתרונות צד ג' כמו Symantec Enterprise Vault, וכיוצא בזה).
אני לא מתכוון לגעת בכלל ההיבטים הללו לעומק, המטרה של הפוסט הזה היא לשפוך קצת אור (קצת, כן?) על איך אני ממליץ להיפטר מקבצי ה- PST ואיך לעבוד עם תיבות גדולות יותר ופתרונות ארכיון (במידת הצורך).
קצת היסטוריה
אם נחזור אחורה, קבצי ה- PST (ראשי תיבות של Personal Storage Table), הינם קבצים אשר היו מיועדים לעבודה עם Exchange Client, Windows Messaging וגם Outlook. לפי המוצרים ש- PST נתמך בהם (החל – Exchange Client) ניתן להבין שלמוצר יש פז"ם.
רבים סיגלו את המשתמשים לעבוד עם קבצי ה- PST ממגוון סיבות – בעבר גודל התיבות לא היה כמו היום, ומשתמשים היו מסתפקים בכמה מגה-בייטים (גילוי נאות: התיבה שלי היום גם מסתפקת בכמה מגה-בייטים, "רק" 300 מגה-בייטים). בנוסף, לא כולם היו עובדים עם Exchange וצורת העבודה היותר פופולארית אז הייתה POP3/IMAP שדרשו גם הם קבצי PST.
חלק מן הארגונים היו משתמשים ב- PST לסיבות שונות – חלק היו מנחים את המשתמשים לאחסן ב- PST כל מה שהם צריכים לארכב (כלומר, ה- PST שימש מעין "ארכיון" אליו היו מעבירים או מעתיקים פריטים), חלק מן הארגונים היו דורשים להעביר את כל המידע שלא נוגע לעבודה לשם (כמו המייל שאחד העובדים היה שולח בתפוצת נאט"ו עם הבדיחה על ההיא עם הפרקינסון ביד, או חג שמח לכולם), כך שתיבת הדואר תכיל מידע חיוני בלבד. חלק השתמשו בה עקב גודל התיבה כ"תיבה משנית" והיו עובדים איתה תדיר (בניגוד לארכיון) על-גבי המחשב האישי.
במרוצת השנים, החלו לאחסן קבצי PST על-גבי שיתופים ברשת (ולא על המחשב האישי), למרות שקבצים אלו לא נועדו להיות מאוחסנים ברשת היו כאלו שהתעלמו מההנחיות הללו. (למעט עבודה עם Outlook 2010/2013 מול Remote Desktop Session Host של Windows Server 2008 R2).
ואז תופעת ה- PST Corrupted התרחשה לעיתים תכופות יותר, מזו שהייתה מתרחשת על דיסקים מקומיים. לכן יכולנו להשתמש ב- ScanPST, מה שכל יועץ שסיפק תמיכה ללקוחות לפי שעות אהב ב- ScanPST זה את ה- Phases שצריך לעבור בשביל לטפל בקבצים. למה? כי בקבצי PST גדולים, התהליך היה לוקח שעות (ואפילו לקח למעלה מיממה כמה פעמים לקבצים ממש גדולים).
כל התופעות והמגבלות הללו היו גורמות לקבצי ה- PST להיות מסורבלים למדי, וקשים לתחזוקה. למה? תיכף נדבר על זה.
נתנאל, למה קבצי PST מסרבלים את העבודה?
הו, שאלה מצוינת. אז בהמשך לחלק הקודם בו סקרתי "מעט" את ההיסטוריה של קבצי ה- PST. להלן הנקודות העיקריות שנדרשת עבורן מחשבה בעת עבודה עם PST:
- במידה וה- PST של המשתמשים מאוחסן כנדרש על התחנות; האם יש סקריפט או תוכנה אשר דואגת לגבות את הקבצים הללו במקרה של אובדן לפטופ\תחנה\Corruption ב- PST וכו'? בדרך כלל לא כולים מגבים את כל התחנות שלהם, ולפעמים קורה מצב בו לפטופ הולך לאיבוד (דרך מרפסת…), או נגנב, או שמחשב נהרס עקב נוזקה או בלאי (דיסקים קשיחים מתים לפעמים, כן כן…), ואין לנו דרך לשחזר את המידע הכה חשוב שלנו שהיה על ה- PST…
- כשלים ב- PST גורמים לבזבוז זמן של העובד – אם הייתה אפשרות לשים את זה על קופסאות של Outlook (בדיוק כפי שמדביקים על קופסאות של סיגריות את ההערות הללו) זה היה מצויין. הרי מה קורה במצב של PST Corruption? צריך להריץ ScanPST, ומה העובד יכול לעשות בזמן הזה חוץ מלגשת ב- OWA/ActiveSync לחלק מהמידע שלו? ברמת דואר- שום כלום.
- חוסר גישה מ- OWA/ActiveSync – בהמשך לנקודה הקודמת, פתרונות המבוססים על שימוש ב- PST לא נגישים מכל מקום, ומצריכים גישה ישירה (בין אם מקומית או דרך הרשת באמצעות VPN) לקבצי ה- PST. לכן, OWA לא יוכל לעזור לעובד להיות נגיש מכל מקום לכל פריטי הדואר שלו…, כנ"ל לגבי ActiveSync.
- לא ניתן להריץ פעולות E-Discovery על מידע שנמצא בקבצי PST, וכך לא ניתן לבצע חיפוש לדוגמא של מידע שנמצא שם.
מה עושים בנידון?
ובכן, יש כמה אפשרויות.
אפשרות אחת
היא להמשיך לתחזק קבצי PST על-גבי דיסקים מקומיים במחשב, ולגבות אותם באמצעות כלים כמו DPM. כמובן שבהתאם לסוג הארגון ולאופיו נצטרך להפעיל פתרונות יצירתיים להגנה על המידע (כדוגמת הצפנת דיסקים קשיחים בלפטופים, או איך דואגים לגבות PST גם כאשר הלקוח נייד מחוץ לארגון לאורך זמן). אני באופן אישי, הייתי מעדיף את האפשרות השנייה.
אפשרות שנייה
היא לאגד את קבצי ה- PST אל תוך שרת ה- Exchange ולהיפטר מהם, להעניק למשתמשים תיבות גדולות יותר, למנוע באמצעות Group Policy עבודה עם קבצי PST, (ניתן דרך Registry גם במחשבים שלא ב- AD) ובמידת הצורך, לתיבות שחורגות מהגודל הסטנדרטי שהקצתן לארגון – לספק פתרון ארכוב עבור המידע שהיה ב- PST.
כך ניתן לדוגמה לקבוע מדיניות בה גודל תיבה הוא 5GB, וקיים ארכיון של עד כ- 15GB. ניתן ליצור גם Archive, Personal & Retention Policy Tags ולקבוע כי מידע שישן יותר מ- X זמן יעבור באופן אוטומטי לארכיון.
חשוב לציין כי Personal Archive של Exchange 2010/2013 דורש Enterprise CAL (צריך להיערך מבחינת רישוי) ו- Outlook 2007 SP2 ומעלה.
היתרון בעבודה בשיטה שכזו – היא שאין יותר PST – הכל מנוהל דרך ה- Exchange, והתיבה עם כלל המידע נגישה מכל מקום – אפילו מ- OWA. אבל… מערכות Exchange Server 2010/2013 אינן עובדות בתצורה של Single Instance מבחינת אחסון מידע, ובכך ארגון יכול לבזבז יותר נפח ב- SAN/DAS\דיסקים מקומיים לטובת מידע שעלול להיות כפול בכמה וכמה מקומות. איך ניתן לחסוך נפח דיסק? ניתן לעבוד עם פתרונות צד ג' לארכוב מידע כדוגמת Enterprise Vault של Symantec.
אתה מצפה שאני אעבור עכשיו מחשב אחר מחשב, ואתחיל למפות בארגון את כלל קבצי ה- PST שלי?
זו אפשרות אחת, אם אין לך מה לעשות, ואתה רוצה לכתוב סקריפט שיאתגר את היכולות שלך. אפשרות אחרת, שתהיה נוחה יותר – ואני משתמש בה אפילו – היא לעבוד עם Microsoft Exchange PST Capture (שיצא בגרסא 2.0ge PST Capture 2.0ואתה רוצה לכתוב סקריפט שיאתגר את היכולות שלך. במקרה של אובדן לפטופ\תחנה\שגי לא מזמן).
כלי ה- Exchange PST Capture מאפשר להתקין Agent על תחנות ולאסוף מידע מהן לגבי מיקום קבצי ה- PST, ולהעביר אותן ל- Exchange Server On-Premise בתוך הארגון או ל- Exchange Online בענן.
מי שמעוניין להתחיל לעבוד עם הכלי, ולא יודע איך – מוזמן לגשת לסדרת המאמרים המעולה של MSExchange על הכלי ולהתחיל לקרוא, להתקין ולהעלים את קבצי ה- PST בארגון!
לסיכום, אז מה היה לנו?
דיברנו על ההיסטוריה של קבצי ה- PST, על המגבלות שלהם ועל מה שגורם להם לסרבל לנו את העבודה כמנהלי רשת ושל המשתמשים במצבי Corruption. בנוסף, סקרנו אפשרויות להילחם ב- PST (או לקבל בקרה מלאה עליהם) וסיפקתי המלצות לדרך עבודה נוחה במלחמה בקבצי ה- PST. מקווה שתנצחו!
מקווה ששפכתי מעט אור על הנקודות החשובות הללו.
חג שמח,
נתנאל בן-שושן.