השאלה מס' 2 אשר אני שומע אצל לקוחות רבים שלי (הראשונה היא: קפה…? ) היא "למה לי להריץ Sysprep?" או "אני משתמש ב- NewSID, זה מספיק לי. למה אני צריך להפעיל את ה- Sysprep הזה?", וכהנה וכהנה שאלות ותהיות סביב נושא ה- System Preparation Tool הידוע בכינויו Sysprep.

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

לקוחות רבים מחליטים לכלול בתהליך השיבוט שלהם דווקא כלים ושיטות אחרות, ביניהם ניתן למנות את NewSID או הסרה ידנית של ערכים מה- Registry והצהרה על כך שלאחר מכן "המחשב מוכן לשימוש". כפי שציינתי מעלה – Sysprep היא הדרך היחידה לשיבוט נכון של מערכת ההפעלה, מיקרוסופט הודיעה כי לא בדקה פעולות ותוכניות אחרות כדוגמת NewSID ולכן לא תינתן תמיכה בנושא.

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

• עבודה עם Network Load Balancing – בעת עבודה עם Network Load Balancing (או NLB בקצרה) של Microsoft בתצורות Unicast ו- Multicast, קיימות בעיות רבות כאשר עובדים עם מכונות עם SID זהה. הבעיות אינן בעלות דפוס חוזר על עצמו וכוללות ניתוקים וחיבור איטי.
  
• עבודה עם SMS/Configuration Manager – קיים קושי רב לעבוד במקביל למערכות SMS/SCCM עם תחנות בעלות SID זהה. הדיווחים המתקבלים על מערכות שכאלו בעייתי, הן ברמת WSUS להפצת עדכונים, והן ברמת עבודה עם SMS Advanced Client.
  
• עבודה עם Windows Server Update Services (WSUS) – קיימות בעיות רבות בעת עבודה עם מכונות בעלות SID זהה במקביל ל- WSUS, הבעיה הפופולארית ביותר שנתקלתי בה היא מקרי "דריסה" של חשבונות מחשבים אחרים על-ידי חשבון מסוים המדווח ל- WSUS אודות עדכונים. כך ששאר התחנות בעלות אותו SID לא יכולות לדווח יותר (גם במידה ונרשמו) עקב "לקיחת הבעלות" של אותו חשבון מחשב.
  
• עבודה עם Exchange Server 2007/2010 – Exchange עושה המון בעיות בעבודה עם SIDs זהים, במיוחד במידה ובה שני שרתי Exchange (לדוג' ב- DAG/CAS Array) בעלי SID זהה, או בעת עבודה עם שרת Exchange ו- DC בעלי SID זהה.
  

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

במידה ויש לנו בעיות מסוימות שמתאימות לבעיות הקיימות בעת עבודה עם SIDs זהים, או שאיננו יודעים אם ה- Images בארגון עברו Sysprep ניתן תמיד להריץ את PsGetSID.

תוכנית ה- PsGetSID ניתנת להורדה כחלק מה- PsTools או מה- Sysinternals Suite והפעלה פשוטה שלה תציג את ה- SID של חשבון המחשב שלכם.

במידה וגילתם כי קיים SID זהה במספר מחשבים בארגון, יש לבנות Image מחדש המכיל את ה- Sysprep בתוכו ולהפיצו למחשבי היעד בהתאם. במחשבים המשמשים תפקיד מרכזי בארגון וחווים מבעיות דומות יש לשאול האם ניתן להמשיך ללא אותו שירות לזמן מסוים, ובהתאם למצב, להוציא את המכונה מה- Domain, להפעיל Sysprep, ולהחזירה ל- Domain באופן זמני (ובמועד מאוחר יותר לבצע התקנה של מכונה נקייה בצורה נכונה ומעבר מלא אליה).

טוב, שכנעת אותי. איפה Sysprep נמצא?

תוכנית ה- Sysprep עבור מערכות Windows XP/Server 2003 זמינה בתקליטור ההתקנה של Windows, תחת תיקיית Support\Tools בקובץ בשם Deploy.cab. עבור התקנה אוטומטית ניתן להעזר בקובץ Setupmgr.exe ולבנות קובץ תשובות לצורך התקנה אוטומטית של מערכת עם Sysprep, מידע נוסף אודות עבודה עם Setupmgr.exe לבניית קובץ תשובות עבור Sysprep ניתן למצוא בקישור הבא.

במערכות Windows Vista/Server 2008 ומעלה תוכנית ה- Sysprep זמינה ב- C:\Windows\system32\sysprep, שם נמצא Sysprep.exe. עבור התקנה אוטומטית ניתן להעזר ב- Windows Automated Installation Kit (WAIK), ולבנות קובץ תשובות מבוסס XML. מידע נוסף אודות יצירת קובץ תשובות ל- Sysprep באמצעות Windows System Image Manager, אשר מהווה חלק מ- WAIK, ניתן למצוא בקישור הבא.

לסיכום

השתדלתי לרכז בפוסט זה מספר נקודות בנושא בעיות נפוצות בעת עבודה עם מכונות אשר לא עברו שיבוט עם Sysprep, מומלץ לעבוד על-פי ה- Best Practices וההמלצות של מיקרוסופט ובכך להימנע במלאכת איתור וטיפול בתקלות בתרחישים לא רצויים שאינם נתמכים, ולהשקיע את הזמן הפנוי… בקפה .