WDS ז״ל: מיקרוסופט נפרדת משירות ההתקנות שכל איש סיסטם הכיר

יש שירותים שלא מקבלים מסיבת פרידה. יום אחד הם פשוט הופכים מ״ככה תמיד עשינו״ לשורה בדוקומנטציה שמסומנת Deprecated. ב-21 בספטמבר 2026 מיקרוסופט פרסמה הודעה מוקדמת: החל מגרסת Windows Server הבאה היא מתכננת להוציא לגמלאות את תפקיד השרת Windows Deployment Services — כולל שירותי WDS, כלי הניהול, הממשקים, ה-Multicast ויכולת ה-PXE שמגיעה איתו.

במילים של אנשי סיסטם: WDS לא נעלם מ-Windows Server 2025 מחר בבוקר, אבל השעון התחיל לתקתק. מי שמחזיק סביבו תהליך התקנות, Image מותאם, סקריפטים או SCCM שתלוי ב-WDS צריך למפות את התלות ולבנות מעבר. זה לא אירוע של ״להחליף Role״ — זו הזדמנות לבדוק מחדש איך הארגון מעלה מחשב חדש מהרגע שהוא יוצא מהקרטון ועד שהוא מאובטח, מנוהל ומוכן לעובד.

לחצו להגדלה

לפני ההספדים: מה WDS בכלל עשה?

Windows Deployment Services הגיע לעולם כדי לפתור כאב אמיתי: במקום לעבור מחשב-מחשב עם דיסק או USB, המחשב עלה מהרשת. כרטיס הרשת ביקש כתובת מ-DHCP, קיבל הפניה לשירות האתחול, הוריד סביבת Windows PE דרך PXE — ומשם התחיל תהליך התקנה של Windows על הדיסק המקומי.

• ▸Network Boot באמצעות PXE — אתחול מחשבים חדשים גם כשאין עליהם מערכת הפעלה.
• ▸Boot Images — בדרך כלל WinPE, סביבת ההתקנה והתחזוקה הקלה של Windows.
• ▸Install Images בפורמט WIM — תמונת Windows שאפשר לפרוס שוב ושוב על תחנות ושרתים.
• ▸Unattended Installation — קובצי תשובות שמצמצמים לחיצות ידניות במהלך ההתקנה.
• ▸Multicast — הפצת Image לקבוצת מחשבים תוך ניסיון לחסוך רוחב פס לעומת שליחה נפרדת לכל תחנה.
• ▸Driver Injection ו-Capture — שילוב מנהלי התקנים ויצירת Image מתבנית קיימת, בתהליכים שבארגונים רבים הלכו והסתבכו עם השנים.

WDS היה מצוין בלענות על השאלה ״איך נעלה Image מהרשת?״. העולם המודרני שואל שאלה רחבה יותר: ״איך נביא מכשיר למצב ארגוני מלא, מאובטח ומנוהל — מכל מקום?״

אז WDS מת? כן, אבל לא היום

כאן חשוב לדייק. Deprecation איננו Removal. ההודעה של מיקרוסופט לא מסירה את WDS מ-Windows Server 2016, ‏2019, ‏2022 או 2025, ואינה מבטלת את התמיכה בהם מעבר למחזור החיים הרשמי שלהם. WDS ממשיך לעבוד בגרסאות הנתמכות. מיקרוסופט מודיעה שבגרסת Windows Server הבאה התפקיד והיכולות הנלוות מתוכננים להיכנס לסטטוס Deprecated, ורק בגרסה עתידית — בלי תאריך סופי שפורסם — צפויה הסרה מלאה.

• ▸2021 — תרחישי Windows Setup שהתבססו על boot.wim ממדיית ההתקנה במצב WDS הוצאו משימוש עבור Windows 11 והלאה; תרחישי PXE עם Image מותאם עדיין נשארו.
• ▸אפריל 2026 — תרחישי Hands-Free Deployment של WDS הושבתו כברירת מחדל והפכו ללא נתמכים לאחר עדכוני האבטחה שפורסמו מ-14 באפריל 2026, כחלק מהקשחת אבטחה.
• ▸ספטמבר 2026 — מיקרוסופט נתנה הודעה מוקדמת על הוצאת כל תפקיד WDS ו-PXE המסופק על ידו לגמלאות בגרסת Windows Server הבאה.
• ▸בעתיד — WDS יוסר מגרסת מערכת הפעלה עתידית; מיקרוסופט טרם פרסמה מועד הסרה מחייב.

מה בדיוק נכנס לרשימת הפרידה?

זו לא רק הקונסולה הישנה. ההודעה מכסה את תפקיד WDS המובנה, את Deployment Server ואת Transport Server, את מנגנון ה-PXE וה-Network Bootstrap של WDS, את WDSUTIL והממשקים, את ה-APIs, את תהליכי ה-Multicast ואת רכיבי WinPE-WDS-Tools שנועדו לעבוד מול לקוח WDS. לכן בדיקת תלות אמיתית חייבת לעבור גם על אוטומציות וכלים שאולי משתמשים ב-WDS מאחורי הקלעים.

SCCM לא מת — והוא גם כבר לא נקרא SCCM

רבים עדיין אומרים SCCM, אבל השם העדכני הוא Microsoft Configuration Manager, או בקיצור ConfigMgr. המוצר עצמו ויכולת Operating System Deployment שלו אינם יוצאים משימוש בעקבות ההודעה. להפך: מיקרוסופט מציגה את Configuration Manager כפתרון עשיר וגמיש יותר לפריסת Windows Images.

ההבדל המהותי הוא ש-WDS היה בעיקר מנוע Boot והפצת Image. Configuration Manager מנהל תהליך שלם באמצעות Task Sequence: חלוקת דיסק, החלת Image, התקנת Drivers לפי דגם, הצטרפות ל-Domain, התקנת Applications, עדכונים, BitLocker, סקריפטים, בדיקות ותיעוד סטטוס. כלומר, לא רק ״Windows עלה״ — אלא ״המחשב הגיע למצב שהארגון הגדיר״.

לחצו להגדלה

הניואנס החשוב: SCCM יכול להשתמש ב-PXE בלי WDS

בסביבות ותיקות, Distribution Point של Configuration Manager עדיין עשוי להשתמש ב-WDS מאחורי הקלעים כדי לענות לבקשות PXE. זו בדיוק התלות שמיקרוסופט מבקשת להסיר. החלופה היא Configuration Manager PXE Responder without WDS — רכיב שמספק את תהליך ה-PXE עבור OSD בלי להתקין את תפקיד WDS המובנה.

• ▸OSD ב-Configuration Manager נשאר נתמך — אין כאן הודעת פרישה ל-SCCM/ConfigMgr.
• ▸סביבת ConfigMgr עם WDS-backed PXE צריכה לעבור ל-PXE Responder שאינו תלוי ב-WDS.
• ▸ה-PXE Responder ללא WDS עובד ב-Unicast; תהליכי Multicast שתלויים ב-WDS אינם עוברים איתו.
• ▸מעבר מ-Multicast ל-Unicast מחייב בדיקת רוחב פס, עומס על Distribution Points, גודל גלים וחלונות הפצה.

ומה עם Intune ו-Windows Autopilot?

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

זה פתרון מצוין למחשבים ניידים, עובדים מרוחקים וארגונים שמתקדמים לניהול Cloud-native — אבל הוא לא תחליף אחד-לאחד לכל תרחיש WDS. כשצריך להתקין Bare Metal במעבדה מבודדת, לפרוס שרתים, להחליף מערכת הפעלה לחלוטין או לעבוד באתר ללא קישור יציב לענן, OSD מקומי או פתרון PXE עצמאי עדיין יכול להיות הבחירה הנכונה.

לחצו להגדלה

HTTP Boot, PXE עצמאי ופתרונות צד שלישי

מיקרוסופט מדגישה שגם מימושי PXE עצמאיים ומוצרי Deployment שאינם תלויים בתפקיד WDS אינם מושפעים מההודעה. HTTP או HTTPS Boot עשויים להשתלב בפתרונות מסוימים כאשר ה-UEFI, הרשת וכלי ההפצה תומכים בכך. אבל אסור לבלבל: HTTP(S) Boot אינו מוצג כתחליף ל-PXE-based OSD של Configuration Manager. הוא מנגנון אתחול אפשרי, לא מערכת ניהול פריסה מלאה.

כך בונים תוכנית מעבר בלי להשבית את חדר המחשבים

• ▸Inventory — אתר כל שרת עם WDS Role, ‏Deployment Server או Transport Server, ואל תשכח שרתי מעבדה ו-DR.
• ▸Dependencies — חפש WDSUTIL, ‏WDS APIs, ‏WinPE-WDS-Tools, ‏Custom Images, סקריפטים, Multicast ו-ConfigMgr Distribution Points.
• ▸Classify — הפרד בין תחנות קצה, מחשבי מעבדה, שרתים, אתרים מבודדים, Recovery ותרחישי Bare Metal.
• ▸Choose — עבור ConfigMgr, בדוק PXE Responder ללא WDS; עבור מחשבי משתמשים, בחן Autopilot ו-Intune; לתרחישים מיוחדים, בדוק PXE עצמאי או מוצר Deployment מתאים.
• ▸Pilot — הרץ פיילוט עם דגמי חומרה אמיתיים, UEFI ו-Secure Boot, ‏VLANs שונים, Driver Packages ותרחישי כשל.
• ▸Capacity — אם Multicast הופך ל-Unicast, מדוד עומס אמיתי ואל תנחש. ייתכן שתצטרך Distribution Point נוסף או גלי פריסה קטנים יותר.
• ▸Rollback — השאר סביבת WDS נתמכת זמינה בזמן המעבר, תעד את התהליך והגדר נקודת חזרה לכל גל.

למה זה חומר חובה לאיש System Administrator?

כי פריסת מערכת הפעלה אף פעם לא עומדת לבד. PXE תלוי ב-DHCP ובתכנון VLAN; ‏WinPE צריך Drivers וגישה לרשת; הצטרפות לדומיין נוגעת ב-DNS, ‏Active Directory והרשאות; אבטחה נוגעת ב-Secure Boot, ‏BitLocker, תעודות ו-GPO; ואוטומציה אמיתית עוברת דרך PowerShell. מי שמבין רק את הקונסולה רואה כפתור. מי שמבין Windows Server ותשתיות רואה את השרשרת כולה — ויודע איפה היא נשברה.

השורה התחתונה

WDS לא נכשל. הוא פשוט פתר בעיה של דור אחר — דור שבו המחשב ישב ליד השרת, ה-Image היה המלך וכל תהליך ההקמה התחיל בכבל רשת. היום ארגונים צריכים גם Bare Metal, גם עובדים מהבית, גם Zero Touch, גם אבטחה וגם ניהול שוטף. לכן השאלה הנכונה אינה ״מה מחליף WDS?״, אלא ״איזה מסלול פריסה מתאים לכל סוג מכשיר בארגון?״. איש הסיסטם שידע לענות עליה לא רק ישרוד את סוף WDS — הוא יוביל את המעבר.