למה חשוב להריץ Sysprep לפני שכפול מכונות?

29 בנובמבר 2011

 

NetanelBenShushan מאת: נתנאל בן-שושן, מנהל תחום Microsoft באנקור תשתיות מחשוב ו- Microsoft MVP

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

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

חשוב לציין – Sysprep מבצע פעולות נוספות מלבד שינוי SID (והן חשובות הרבה יותר מסוגיית ה- SID), הוא אחראי על ייצור מחדש (Regenerate) של LSA Secrets, Machine Private Keys ושלל שינויים נוספים. הדרך בה בחרתי לזהות במאמר זה תחנות שלא עברו את תהליך ה- Sysprep היא באמצעות SID זהה. אך SID זהה כשלעצמו אינו הבעיה היחידה, אלא הבעיות הנגזרות מעבודה עם SID הזהה.

לקוחות רבים מחליטים לכלול בתהליך השיבוט שלהם דווקא כלים ושיטות אחרות, ביניהם ניתן למנות את 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 של חשבון המחשב שלכם.

clip_image002

במידה וגילתם כי קיים 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 וההמלצות של מיקרוסופט ובכך להימנע במלאכת איתור וטיפול בתקלות בתרחישים לא רצויים שאינם נתמכים, ולהשקיע את הזמן הפנוי… בקפה J.

 

נתנאל בן-שושן (CCA, CSA, JNCIA-SSL, MCSA/E, MCTS, MCITP) מנהל תחום Microsoft באנקור תשתיות מחשוב ו- Microsoft MVP. נתנאל מתמחה בעיקר בתשתיות מיקרוסופט, תקשורת נתונים ואבטחת מערכות מידע. נתנאל מפעיל את האתר http://www.ben-shushan.net המכיל מידע רב בשפה העברית בתחום ה- IT, ואת הבלוג http://blogs.microsoft.co.il/blogs/netanelb

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

6 תגובות

  1. יאיר30 בנובמבר 2011 ב 9:15

    אם משכפלים מכונה (וירטואלית לדוגמה)
    ואת השיכפול – מוציאים מהדומיין
    נותנים למכונה שם חדש
    ומכניסים לדומיין

    פעולות אלו לא משנות את הSID ?
    תודה

    הגב
  2. HaimL5 בדצמבר 2011 ב 19:38

    לא, היא לא משנה.
    במערכות וירטואליות ההמלצה לעבוד עם TEMPLAES.

    להכין TEMPLATE – לבצע SYSPREP ולאחר ה SYSPREP לדאוג שהמכונה תישאר כבויה.
    כך שבכל התקנה של שרת חדש ה SYSPREP מתבצע.

    הגב
  3. יגאל12 בדצמבר 2011 ב 7:59

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

    הגב
  4. netanelbs12 בדצמבר 2011 ב 20:00

    יגאל,

    או שתתקין את השינויים באמצעות Batch/Script לאחר שפיכת ה- IMAGE.

    או שתצור IMAGE חדש (תתקין OS+אפליקציות+שינויים נדרשים+תריץ SYSPREP ותלכוד את ה- IMAGE) ותפיץ אותו.

    הגב
  5. אלי שגיא15 בדצמבר 2011 ב 9:30

    מרק רוסינוביץ', מפתח הNewSID וכל SysInternals יצא בעצמו במאמר שמנסה להפריך את מה שאנחנו חושבים (וגם כותב המאמר) על SID זהה:
    The Machine SID Duplication Myth (and Why Sysprep Matters)
    http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

    למרות כל זאת הוא עדיין מצדיק את השימוש בSysPrep ועדיין לדעתי אפשר לערער על מסקנותיו מאחר והנסיון בשטח יכול להראות אחרת.

    בשורה התחתונה SysPrep נראית כפרקטיקה המומלצת הטובה ביותר וחסינת הבעיות שיש.

    הגב
  6. גיא11 בינואר 2012 ב 15:54

    מאמר מאוד נחמד, וחביב, ההסברים באתר שלך מאוד מובנים.

    רק רציתי לציין שלפי מה שהבנתי, האתר שלך מכיל את הצעדים של STEP BY STEP עבור הכנה של מחשבים להפצה ע"י WDS. (אלא אם כן אני טועה).

    מה שאני בד"כ עושה לאחר כל התקנת שרת 2008R2 חדש שאני מרים, אני פשוט נכנס לתיקיית ה SYSPREP, ומשם בוחר באפשרות OOBE, למטה מסמן REBOOT, ושלום על ישראל. 🙂

    הגב