סיום התמיכה ב-printer drivers של Windows — איך אפליקציות עסקיות מתכוננות להדפסת דוחות ותוויות

“החלפנו את ה-PC ואפשרויות הנייר והמגשים שונות, למרות שזו אותה מדפסת.” “הגדרות ההדפסה השמורות לא חוזרות.” “מדפסת התוויות נעלמה מהרשימה.” להתכונן לסיום התמיכה ב-printer drivers פירושו לוודא ששינויים כאלה לא עוצרים את העסק.

הדבר הראשון להבין הוא ש-תוכנית סיום התמיכה ב-drivers והפעלת Windows protected print mode הם שני דברים שונים. ההדפסה הקיימת לא נעצרת כולה ברגע שתאריכי התוכנית עוברים. מצד שני, כשדרך בחירת ה-driver משתנה, או כש-Windows protected print mode מופעל, ההגדרות ויעדי ההדפסה שהאפליקציה הייתה תלויה בהם אובדים.¹²

המאמר הזה מיועד למפתחים שמתחזקים אפליקציות עסקיות של Windows ב-WinForms, WPF וכדומה, ולמנהלים שמפרסים מדפסות. הוא עובר על מה משתנה, מה לבדוק, מה לתקן, ואיך לאמת, בסדר הזה. לבחירת API הדפסה או שיטת פלט PDF מלכתחילה, ראו את המאמר הקודם, הדפסה ופלט PDF באפליקציות עסקיות של Windows.

סביבת הבסיס היא Windows 11 (24H2 ואילך לאימות WPP), PowerShell 5.1 ואילך (מודול PrintManagement), ו-C# (.NET 6 ואילך, או .NET Framework 4.x; System.Drawing.Printing / System.Printing). רמת הקושי היא בינונית.

1. קודם המסקנות

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

סדר ההחלטות הוא שלושה שלבים.

אם האפליקציה מציירת רק עם PrintDocument או FixedDocument, היא עקרונית יעד לאימות, לא לשכתוב. עם זאת, אם תור היעד עצמו נעלם תחת WPP ואי אפשר לרשום אותו מחדש, ההדפסה נכשלת גם כשקוד הציור תקין. נתיב אחר נחוץ קודם.

אם רוצים להתחיל בעבודה עצמה, ממשיכים בסדר הזה: לוקחים את הרשימה ב-5.1 → שופטים את יעד ההדפסה עם הטבלאות בפרק 4 וב-5.1 → בודקים את התלויות ב-5.2 עד 5.5 → בוחרים נתיב בפרק 6 → מאמתים בפרק 7. פרקים 2 עד 4 מסבירים את הרקע לנקודות שבהן ההחלטה אינה מובנת מאליה.

מכאן ואילך, Windows protected print mode מקוצר ל-WPP. “תור” הוא יעד הדפסה שרשום ב-Windows, ו-“spooler” הוא המנגנון שמקבל עבודות הדפסה ומעביר אותן ליעד הפלט.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 39, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה הוחלט — ציר זמן בשלושה שלבים

2.1 מה שמסתיים הוא אספקה ועדכונים, לא כיבוי גורף של drivers קיימים

המקור העיקרי הוא “End of servicing plan for third-party printer drivers on Windows” ב-Microsoft Learn. התוכנית הוכרזה בספטמבר 2023 והתאריכים שלה עודכנו במאי 2025. נכון לכתיבת המאמר, התוכנית היא כדלקמן.¹

drivers קיימים עדיין ניתנים להתקנה מ-Windows Update ומ-installers של היצרן, ו-Microsoft אומרת שאין לה תוכנית לבטל פונקציונליות של drivers מסוג v3/v4. כלומר, זו תוכנית להפסיק בהדרגה את אספקת ה-drivers והעדכון שלהם, לא תוכנית לבטל באותו יום את ה-drivers שכבר מותקנים על PCs בשטח.¹

flowchart TB
    accTitle: מה משתנה ומה לא עם סיום התמיכה ב-drivers
    accDescr: סיום התמיכה ב-printer drivers לבדו לא משנה לא את נקודת הכניסה של API הציור של האפליקציה ולא את ה-drivers הקיימים; רק כש-driver אחר נבחר בהתקנה חדשה או בזיהוי מחדש מוחלפים רשימת הנייר, היכולות הקנייניות ושם התור שה-driver החזיר, והשינויים שנגרמים מהפעלת Windows protected print mode, כולל הסרת מדפסות וירטואליות, הם מנגנון נפרד שמכוסה בפרק 4
    eos["סיום התמיכה ב-printer drivers"]
    eos --> keep["מה לא משתנה"]
    eos --> cond["כש-driver אחר נבחר בהתקנה חדשה או בזיהוי מחדש"]
    cond --> change["מה שמוחלף"]
    keep --> api["נקודת הכניסה של API הציור"]
    keep --> drv["drivers קיימים"]
    change --> caps["נייר, מגשים, יכולות קנייניות"]
    change --> qname["שם התור"]

איור 1: סיום התמיכה לבדו לא משנה דבר; כש-driver אחר נבחר, המידע והשמות שה-driver סיפק מוחלפים. השינויים שנגרמים מהפעלת WPP, כולל הסרת מדפסות וירטואליות, הם מנגנון נפרד (פרק 4).

2.2 drivers משתנים בשטח בעיקר בשני מצבים

גם אם התוכנית לא עוצרת drivers קיימים, הסביבה שהאפליקציה רואה משתנה במצבים הבאים.

כשמספר חבילות driver מתאימות לאותו מכשיר, Windows נותן לכל אחת דירוג ובוחר את הטובה ביותר. השינוי ב-1 ביולי 2026 גורם לבחירה הזו להעדיף את IPP class driver. במכשירים שעבורם IPP class driver אינו מועמד, חבילת היצרן יכולה להמשיך להיבחר.³¹

flowchart TB
    accTitle: שני נתיבים שבהם drivers מוחלפים בשטח
    accDescr: במכשירים ש-IPP class driver מתאים להם, הדירוג בוחר את IPP class driver בהחלפת PC, התקנת OS מחדש או זיהוי מדפסת מחדש וה-driver מוחלף; כש-Windows protected print mode מופעל, מדפסות על drivers של צד שלישי מוסרות, ה-driver מוחלף בדגמים שאפשר לרשום מחדש עם Windows Ready Print, ויעד ההדפסה אובד בדגמים שאי אפשר
    site["PC בשטח"]
    site --> r1["החלפת PC, התקנת OS מחדש, זיהוי מחדש"]
    site --> r2["Windows protected print mode מופעל"]
    r1 --> rank["מועדף במכשירים ש-IPP class driver מתאים להם"]
    r2 --> del["מדפסות על drivers של צד שלישי מוסרות"]
    rank --> swap["ה-driver מוחלף"]
    del --> re{"אפשר לרשום מחדש עם Ready Print?"}
    re -->|"כן"| swap
    re -->|"לא"| lost["יעד ההדפסה אובד"]

איור 2: הפרדה בין תוכנית סיום התמיכה לבין WPP מאפשרת להפריד בין המצבים שבהם ה-driver משתנה לבין המצבים שבהם יעד ההדפסה עצמו אובד.

חשוב כאן גם לא להתייחס לתמיכה ב-IPP ולהסמכת Mopria כאותו תנאי.

במכשיר שתומך ב-IPP בלי הסמכת Mopria, שינוי הדירוג יכול להחליף את ה-driver גם אם לא משתמשים ב-WPP. לעומת זאת, שם driver של “Microsoft IPP Class Driver” לבדו אינו מאשר שהמדפסת ניתנת לשימוש תחת WPP.¹⁴

flowchart TB
    accTitle: התאמת IPP class driver והסמכת Mopria הם תנאים נפרדים
    accDescr: אם המדפסת תומכת ב-IPP, שינוי הדירוג יכול לבחור את IPP class driver ולהחליף את ה-driver, בעוד שהסמכת Mopria היא תנאי נפרד שמחליט אם אפשר לרשום מחדש את המדפסת תחת Windows protected print mode, ודורש ש-IPP יהיה מופעל ונגיש במכשירים מחוברים לרשת ומצב IPP over USB במכשירים מחוברים ב-USB
    printer["מדפסת"]
    printer --> q1{"תומכת ב-IPP?"}
    q1 -->|"כן"| rank["ניתן להחלפה"]
    q1 -->|"לא"| keep["נשארת על driver היצרן"]
    printer --> q2{"מוסמכת Mopria?"}
    q2 -->|"לא"| ng["אי אפשר לרשום מחדש תחת WPP"]
    q2 -->|"כן"| q3{"חיבור USB?"}
    q3 -->|"לא"| q5{"IPP מופעל ונגיש?"}
    q5 -->|"כן"| ok["ניתן לרישום מחדש תחת WPP"]
    q5 -->|"לא"| ng
    q3 -->|"כן"| q4{"מצב IPP over USB?"}
    q4 -->|"כן"| ok
    q4 -->|"לא"| ng

איור 3: אפקט הדירוג נקבע לפי תמיכה ב-IPP; האם המדפסת שורדת תחת WPP נקבע לפי הסמכת Mopria ועוד IPP מופעל ונגיש (מצב IPP over USB לחיבורי USB).

2.3 לחתימת drivers יש חריגים, אבל המשך אינו מובטח

אחרי 15 בינואר 2026, drivers שעומדים באחד מהתנאים הבאים יכולים לקבל בקשת חריג חתימה לסקירה מקרה-מקרה.¹

• למדפסות שלא יכולות לקבל הסמכת Mopria.
• חבילות שה-OS היעד הגבוה ביותר שלהן הוא Windows 10 או מוקדם יותר.
• drivers native ARM64.

הגשות חסומות כברירת מחדל גם ל-WHQL וגם ל-Attestation, והופכות לסקירה ידנית עם מסמך הצדקה מצורף. גם כשהתנאים חלים, אין ערובה שהיצרן יגיש או ש-Microsoft תאשר.⁵ גם, היכולת לקבל driver חתום והיכולת להשתמש בו בסביבה עם WPP מופעל הם שני דברים שונים. ההכנה למדפסות תוויות וקבלות מכוסה בפרק 6.

flowchart TB
    accTitle: תנאים שבהם חתימת driver עדיין מותרת אחרי 15 בינואר 2026
    accDescr: הגשות driver מיצרנים חסומות כברירת מחדל, ורק אלה שעומדים באחד משלושה תנאים, מדפסות שלא יכולות לקבל הסמכת Mopria, חבילות שהיעד הגבוה ביותר שלהן הוא Windows 10 או מוקדם יותר, ו-drivers native ARM64, יכולות לקבל בקשת חריג לסקירה מקרה-מקרה, שעשויה להוביל לאישור אבל אינה מבטיחה חתימה
    submit["הגשת driver של יצרן"]
    submit --> block["חסום כברירת מחדל"]
    block --> c1["דגם שלא יכול לקבל הסמכת Mopria"]
    block --> c2["Windows 10 או מוקדם יותר כיעד הגבוה ביותר"]
    block --> c3["Native ARM64"]
    c1 --> apply["אפשר לבקש חריג"]
    c2 --> apply
    c3 --> apply
    apply --> review["סקירה מקרה-מקרה"]
    review --> maybe["עשוי להיות מאושר (אין ערובה)"]

איור 4: עמידה בתנאים רק מכניסה את ה-driver לסקירה; האם הוא ייחתם אינו מובטח.

3. איך זה עובד — נתיב ה-driver המסורתי ו-Windows Ready Print

3.1 מה שמשתנה הוא נתיב ההדפסה מעבר ל-API הציור

בהדפסת Windows המסורתית, האפליקציה מוציאה פקודות ציור GDI או XPS, ה-spooler מקבל את העבודה, ו-printer driver ממיר אותה לשפת המדפסת (PDL) ושולח אותה. גם נתיב ההדפסה GDI וגם נתיב ההדפסה XPS יושבים מעל המבנה הזה.⁶

flowchart TB
    accTitle: נתיב ה-driver המסורתי
    accDescr: ה-spooler שרץ כ-SYSTEM עושה spool לפקודות הציור GDI או XPS של האפליקציה העסקית, ו-driver v3 או v4 של צד שלישי ממיר אותן ל-PDL קנייני ושולח אותן למדפסת, בתוך תהליך ה-spooler עצמו בלי driver isolation, או בתהליך נפרד מה-spooler במצב shared או isolated
    app["אפליקציה עסקית (GDI / XPS)"] --> spooler["Spooler (הרשאות SYSTEM)"]
    spooler --> iso{"Driver isolation"}
    iso -->|"None"| inproc["driver של צד שלישי בתוך תהליך ה-spooler"]
    iso -->|"Shared / Isolated"| host["driver של צד שלישי בתהליך נפרד"]
    inproc --> pdl["המרה ל-PDL קנייני"]
    host --> pdl
    pdl --> printer["מדפסת"]

איור 5: בנתיב המסורתי התהליך שונה עם isolation, אבל המבנה שבו קוד של צד שלישי בתוך מחסנית ההדפסה מטפל בהמרה ל-PDL זהה.

היורש הוא Windows Ready Print. זה השם הכולל להדפסה דרך IPP (Internet Printing Protocol), סריקה דרך eSCL, ו-Universal Print, והוא אינו דורש driver של צד שלישי. הוא מתוכנן למדפסות Mopria certified, והעצמאות מארכיטקטורת ה-CPU היא יתרון נוסף.⁷

Windows 10 21H2 ואילך מגיעים עם Microsoft IPP Class Driver, שמטפל במדפסות תואמות Mopria גם ברשת וגם ב-USB.¹ תורי ענן של Universal Print משתמשים ב-Universal Print Class Driver ה-inbox.⁸

flowchart TB
    accTitle: נתיב Windows Ready Print
    accDescr: ה-spooler מקבל את פקודות הציור של האפליקציה העסקית, ואו Microsoft IPP Class Driver ה-inbox מרנדר ל-PWG Raster או PDF בלקוח ושולח דרך IPP למדפסת Mopria certified, או Universal Print Class Driver ה-inbox שולח דרך IPP over HTTPS לשירות Universal Print; Windows protected print mode מאפשר רק את נתיב Windows Ready Print הזה
    app["אפליקציה עסקית (GDI / XPS)"] --> spooler["Spooler"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["רינדור ל-PWG Raster / PDF"]
    render --> printer["מדפסת Mopria certified (IPP)"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["שירות Universal Print (IPP over HTTPS)"]
    wpp["Windows protected print mode"] -.->|"מאפשר רק את נתיב Ready Print"| ipp
    wpp -.-> up

איור 6: גם Windows Ready Print עובר ב-spooler. מה שמשתנה הוא שההמרה והשליחה עוברות מ-driver של צד שלישי ל-class drivers ה-inbox.

IPP הוא פרוטוקול מבוסס HTTP, והוא מזהה מדפסת לפי URI כמו ipps://printer.example.com/ipp/print. ה-PDLs שמשמשים להדפסה בלי driver מוגבלים לכמה פורמטים מבוססי תקנים ציבוריים, כמו PWG Raster ו-PDF, והמסמך הסופי מרונדר בצד הלקוח.⁹ עם Universal Print, ה-spooler שולח את העבודה לשירות דרך IPP over HTTPS.⁸

נקודת הכניסה כפי שהאפליקציה רואה אותה לא משתנה. אפליקציה שמציירת עם GDI או XPS קוראת לאותם APIs. מה שמשתנה הוא המנגנון שמעבר לזה שמחזיר את רשימת גדלי הנייר והמגשים, מספק יכולות קנייניות, וממיר ל-PDL. לכן אפליקציות שתלויות במידע ש-driver מחזיר או בהגדרות קנייניות מושפעות יותר מאפליקציות שמציירות בלבד. ליכולות ספציפיות ליצרן, בודקים גם אם הן מסופקות דרך Print Support App (PSA).¹⁰

3.2 בודקים הדפסה, פקס וסריקה בנפרד במכשירים רב-תכליתיים

האם מכשיר יכול לעבור ל-Windows Ready Print תלוי בכך שלמכשיר יש את הפונקציה ומממש את הפרוטוקול המתאים.¹

לא מסיקים מתמיכת הדפסה Mopria לבדה שגם פקס וסריקה יכולים לעבור.

flowchart TB
    accTitle: סדר לבדיקת כל פונקציה של מכשיר רב-תכליתי בנפרד
    accDescr: בוחרים את הפונקציות שמשתמשים בהן אחת בכל פעם, בודקים בסדר שלמכשיר יש את הפונקציה, שהוא תומך בפרוטוקול בטבלה, ושהוא במצב IPP over USB כשמחובר ב-USB, ובודקים את הפונקציות שנשארו בנפרד במקום לעשות reuse לתוצאת ההדפסה לפקס או לסריקה
    start["בוחרים פונקציה אחת שמשתמשים בה"]
    start --> feature{"למכשיר יש את הפונקציה?"}
    feature -->|"כן"| protocol{"תומך בפרוטוקול בטבלה?"}
    feature -->|"לא"| unmet["התנאי לפונקציה הזו לא מתקיים"]
    protocol -->|"כן"| usb{"חיבור USB?"}
    protocol -->|"לא"| unmet
    usb -->|"כן"| mode{"מצב IPP over USB?"}
    usb -->|"לא"| checked["התנאי לפונקציה הזו נבדק"]
    mode -->|"כן"| checked
    mode -->|"לא"| unmet
    checked --> next["בודקים את הפונקציות שנשארו בנפרד"]
    unmet --> next

איור 7: בודקים בסדר של זמינות פונקציה, פרוטוקול נתמך, והתנאי הנוסף לסוג החיבור. לא עושים reuse לתוצאת ההדפסה לפקס או לסריקה.

3.3 הרקע הוא אבטחת מחסנית ההדפסה

לפי ההסבר ב-Microsoft Learn, באגים שקשורים להדפסה היוו 9% ממקרי MSRC (Microsoft Security Response Center) שספרה בשלוש השנים הקודמות. ה-spooler רץ עם הרשאות SYSTEM, נגיש באופן רחב ממשתמשים רגילים, וטוען קוד של צד שלישי לפי דרישה. חלק מה-drivers הישנים אינם תואמים ל-mitigations מודרניים כמו CFG ו-CET, מה שמקשה להחיל mitigations שדורשים שכל פיסת קוד משתתפת תתמוך בהם.⁹

flowchart TB
    accTitle: למה mitigations לא יכולים להיכנס כל עוד נטענים drivers של צד שלישי
    accDescr: ה-spooler שרץ כ-SYSTEM טוען קוד של צד שלישי, וכי drivers ישנים אינם תואמים ל-mitigations כמו CFG ו-CET, mitigations שדורשים שכל משתתף יתמוך בהם אינם ניתנים להחלה על ה-spooler, מה שמקל לנצל פגיעויות
    sys["ה-spooler רץ כ-SYSTEM"]
    load["טוען קוד של צד שלישי לפי דרישה"]
    old["drivers ישנים אינם תואמים ל-mitigations"]
    sys --> risk["קל יותר לנצל פגיעויות"]
    load --> nomit["Mitigations (CFG / CET / ACG) אינם ניתנים להחלה"]
    old --> nomit
    nomit --> risk

איור 8: mitigations נכנסים רק ברגע שכל משתתף תומך בהם, כך שאי אפשר להגן על ה-spooler במלואו אלא אם מסירים את ה-drivers.

איפה driver של צד שלישי רץ תלוי בהגדרת printer driver isolation.¹¹

driver שמצהיר DriverIsolation=2 ב-INF שלו משתמש בתהליך המשותף כברירת מחדל, ו-driver שלא מצהיר רץ בתוך תהליך ה-spooler כברירת מחדל. מנהלים יכולים לדרוס את זה מ-Print Management console או מ-Group Policy. בכל מצב, עם זאת, קוד של צד שלישי עדיין רץ בתוך מחסנית ההדפסה.¹¹ WPP הוא מצב ההפעלה שמסיר את התלות הזו בקוד של צד שלישי.

flowchart TB
    accTitle: איך נקבע התהליך שבו רץ driver של צד שלישי
    accDescr: driver שמצהיר DriverIsolation=2 ב-INF שלו רץ כברירת מחדל בתהליך משותף נפרד מה-spooler, driver בלי ההצהרה רץ כברירת מחדל בתוך תהליך ה-spooler, ומנהלים יכולים לדרוס את זה מ-Print Management console או מ-Group Policy ל-shared, בתוך תהליך ה-spooler, או תהליך נפרד ייעודי (isolated)
    inf{"ה-INF מצהיר DriverIsolation=2"}
    inf -->|"כן"| shared["רץ בתהליך משותף נפרד (ברירת מחדל)"]
    inf -->|"לא"| inproc["רץ בתוך תהליך ה-spooler (ברירת מחדל)"]
    admin["נדרס על ידי הגדרות administrator או policy"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["רץ בתהליך נפרד ייעודי (isolated)"]

איור 9: מצב ה-isolation נקבע לפי הצהרת ה-INF והגדרות administrator; drivers ישנים בלי ההצהרה רצים בתוך תהליך ה-spooler כברירת מחדל.

4. מה נעלם תחת Windows protected print mode

4.1 WPP הוא מצב הפעלה ש”משתמש רק ב-Windows Ready Print”

WPP הוצג ב-Windows 11 24H2. נכון לכתיבת המאמר הוא כבוי כברירת מחדל, וכשהוא כבוי הוא לא מטיל הגבלות על התקנת drivers או יכולות הדפסה.¹²¹³ מפרידים בין הדרך שבה מפעילים אותו לבין מי יכול לכבות אותו בחזרה.

כשמפעילים דרך Group Policy, המשתמש לא יכול לכבות בלי לפנות ל-administrator. OMA-URI של Intune הוא נתיב נוסף שמחיל את אותה device policy מבוססת ADMX. מניחים ש-המשתמש יכול לכבות ממסך Settings רק כשהמשתמש הפעיל ממסך Settings.¹⁴²¹³

flowchart TB
    accTitle: שלושה נתיבים להפעלת Windows protected print mode
    accDescr: אפשר להפעיל Windows protected print mode מאפליקציית Settings, מ-Group Policy, או מ-OMA-URI של Intune; המשתמש יכול לכבות מאפליקציית Settings רק כשהמשתמש הפעיל שם, וכשהוא הופץ ב-Group Policy או ב-policy של Intune אי אפשר לכבות בלי שה-administrator ישנה את ה-policy
    s["אפליקציית Settings (הופעל על ידי המשתמש)"] --> wpp["Windows protected print mode מופעל"]
    g["Group Policy"] --> wpp
    i["Intune (OMA-URI)"] --> wpp
    s -.->|"המשתמש יכול לכבות באפליקציית Settings"| off["כבוי"]
    g -.->|"המשתמש לא יכול לכבות"| adm["כיבוי דורש שינוי policy של administrator"]
    i -.->|"המשתמש לא יכול לכבות"| adm

איור 10: יש שלושה נתיבי הפעלה, והמשתמש יכול לכבות רק כשהמשתמש הפעיל מאפליקציית Settings.

4.2 תורים ששורדים, תורים שנעלמים, ותורים שחייבים רישום מחדש

האפקט בזמן ההפעלה תלוי לא רק במדפסת עצמה אלא גם ב-עם איזה driver היא רשומה כרגע.²

flowchart TB
    accTitle: מה קורה למדפסות כש-Windows protected print mode מופעל
    accDescr: בהפעלה, מדפסות שהותקנו עם drivers של צד שלישי ומדפסות וירטואליות לא נתמכות, XPS Document Writer ומדפסת הפקס הווירטואלית מוסרות; דגמים שהם Mopria certified ו, לחיבורי רשת, יש להם IPP מופעל ונגיש או, לחיבורי USB, במצב IPP over USB, ניתנים לרישום מחדש עם Windows Ready Print, ומכשירים לא נתמכים אינם ניתנים לשימוש כל עוד הוא מופעל
    on["WPP מופעל"]
    on --> third["מדפסות על drivers של צד שלישי מוסרות"]
    on --> soft["מדפסות וירטואליות לא נתמכות מוסרות"]
    soft --> xps["XPS Document Writer ופקס גם מוסרים"]
    third --> mopria{"מוסמכת Mopria?"}
    mopria -->|"כן"| conn{"סוג החיבור"}
    conn -->|"רשת"| ipp{"IPP מופעל ונגיש?"}
    conn -->|"USB"| usb{"מצב IPP over USB?"}
    ipp -->|"כן"| re["רושמים מחדש עם Windows Ready Print"]
    usb -->|"כן"| re
    ipp -->|"לא"| no["לא שמיש כל עוד מופעל"]
    usb -->|"לא"| no
    mopria -->|"לא"| no

איור 11: תור על driver של יצרן נעלם פעם אחת גם אם המדפסת Mopria certified. בודקים את תנאי הרישום מחדש בנפרד.

כל עוד WPP מופעל, אי אפשר להשתמש ב-drivers של צד שלישי שהוסרו. גם, כיבוי WPP בחזרה לא מחזיר אוטומטית מדפסת שהותקנה מחדש עם Windows Ready Print ל-driver המקורי שלה.²¹⁰

בצד האפליקציה, הדברים לבדוק הם עיבוד שמניח את גדלי הנייר, המגשים והיכולות הקנייניות ש-driver של יצרן מחזיר, מדפסות וירטואליות בסגנון port monitor DLL, ו-XPS Document Writer. יצירת קובצי XPS ישירות עם XpsDocument וכדומה שונה מהדפסה לתור הווירטואלי שנקרא XPS Document Writer, ואינה מושפעת מההסרה הזו.

4.3 גם הניהול והפנים של ה-spooler משתנים

תחת WPP, binaries של צד שלישי כמו port monitor DLLs כבר לא נטענים. APIs לטעינת מודולים כמו AddPrintProvidorW כבר לא יכולים לטעון מודולים חדשים, ורק ה-binaries החתומים על ידי Microsoft שנחוצים ל-IPP נטענים. AddPrintProvidorW הוא האיות ההיסטורי ב-winspool.h; ההסבר ב-Microsoft Learn כותב אותו כ-AddPrintProviderW.⁹

ההגבלה הזו מאפשרת לרינדור XPS לרוץ עם הרשאות משתמש במקום SYSTEM, ותהליך העובד החדש של ה-spooler משתמש ב-token מוגבל עם הרשאות כמו SeTcbPrivilege מוסרות. יצירת child process אסורה, וגם CFG, CET ו-ACG מופעלים.⁹

flowchart TB
    accTitle: שינויים ב-spooler תחת Windows protected print mode
    accDescr: הפסקת טעינת binaries של צד שלישי מאפשרת להגביל טעינת מודולים, לרנדר XPS עם הרשאות משתמש, להריץ תהליכי עובד עם token מוגבל, לאסור יצירת child process, ולהפעיל CFG, CET ו-ACG
    nodrv["binaries של צד שלישי אינם נטענים"]
    nodrv --> r["טעינה מוגבלת"]
    nodrv --> l["הרשאות מופחתות"]
    nodrv --> m["Mitigations מופעלים"]
    r --> r2["רק binaries חתומים על ידי Microsoft"]
    l --> l2["XPS בהרשאות משתמש, token מוגבל"]
    m --> m2["בלי child processes, CFG / CET / ACG"]

איור 12: ה-mitigations שלא יכלו להיכנס באיור 8 ניתנים להפעלה רק ברגע ש-binaries של צד שלישי מוסרים.

Point and Print שומר על תצורת IPP שלו אבל כבר לא מתקין drivers של צד שלישי. גם הליכי provisioning שנבנו על ההנחה ש-“חיבור לשרת ההדפסה מפיץ את ה-driver” צריכים להישקל מחדש.⁹

האם WPP מופעל כרגע אפשר לבדוק עם WinRT API Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo.IsProtectedPrintEnabled ב-Windows 11 24H2 ואילך.¹⁵ הגדרת Group Policy היא הערך WindowsProtectedPrintGroupPolicyState תחת HKLM\Software\Policies\Microsoft\Windows NT\Printers\WPP.¹³

שימו לב שלקוח עם WPP מופעל לא יכול לנהל שרת הדפסה עם WPP כבוי מ-Print Management. מספקים למנהלים לקוח ניהול נפרד עם WPP כבוי.¹⁴

5. ספירת מלאי של אפליקציות קיימות — ארבעת המקומות לבדוק

flowchart TB
    accTitle: ארבעת המקומות לספירת מלאי באפליקציה עסקית
    accDescr: בקוד ההדפסה של אפליקציה עסקית, ארבעת המקומות, שמירת הגדרות ספציפיות ל-driver, תלויות בשם תור (כולל אלה בתוך SDKs וספריות), תלויות במדפסות וירטואליות שלא נתמכות על ידי WPP, ושליחת RAW לתורים שלא שורדים WPP, הם יעדים לשכתוב, וקוד שמצייר בלבד הוא יעד לאימות
    app["קוד הדפסה של אפליקציה עסקית"]
    app --> deps["סופרים את ארבע התלויות"]
    app --> d0["ציור בלבד"]
    deps --> d1["שמירת הגדרות ספציפיות ל-driver"]
    deps --> d2["תלות בשמות תורים"]
    deps --> d3["תלות במדפסות וירטואליות"]
    deps --> d4["שליחת RAW"]
    d2 -.-> d2n["כולל בתוך SDKs"]
    d3 -.-> d3n["אלה שלא נתמכות על ידי WPP"]
    d4 -.-> d4n["לתורים שלא שורדים"]
    d1 --> fix["שכתוב"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["אימות"]

איור 13: רק ארבע התלויות הן יעדים לשכתוב; קוד שמצייר בלבד הולך לאימות.

5.1 קודם לוקחים את רשימת ה-drivers בשטח ושופטים את יעד ההדפסה

האם נחוץ שכתוב נקבע אחרי שרואים מה מותקן בשטח. לוקחים את רשימת התורים וה-drivers עם מודול PrintManagement של PowerShell. רישום עם Get-Printer ו-Get-PrinterDriver אינו דורש הרשאות administrator, אבל שלב pnputil במחצית השנייה כן.¹⁶¹⁷

# לכל תור, מציגים את שם ה-driver, גרסה ראשית (3 = v3, 4 = v4), יצרן, ושם קובץ INF
Get-Printer |
    Select-Object Name, DriverName, PortName,
        @{ Name = "DriverMajorVersion"; Expression = { (Get-PrinterDriver -Name $_.DriverName).MajorVersion } },
        @{ Name = "Manufacturer"; Expression = { (Get-PrinterDriver -Name $_.DriverName).Manufacturer } },
        @{ Name = "InfName"; Expression = { Split-Path -Leaf (Get-PrinterDriver -Name $_.DriverName).InfPath } } |
    Sort-Object DriverName |
    Format-Table -AutoSize

# מציגים רק חבילות driver של צד שלישי, עם השם המפורסם (oemN.inf), שם ה-INF המקורי, והספק (דורש הרשאות administrator)
pnputil /enum-drivers /class Printer

MajorVersion מבדיל בין v3 ל-v4.¹⁸ עם זאת, ההבחנה v3/v4 וההבחנה inbox/צד-שלישי הן נפרדות. מסווגים כך.

InfPath מ-Get-PrinterDriver הוא הנתיב ל-INF בתוך driver store ואינו מובטח להחזיר את שם oemN.inf המפורסם. מצליבים את השם המפורסם, שם ה-INF המקורי והספק ש-pnputil /enum-drivers מחזיר מול שם הקובץ של InfPath ו-Manufacturer. pnputil /enum-drivers מציג רק חבילות צד שלישי; חבילות inbox לא מופיעות ברשימה.¹⁹¹⁷

flowchart TB
    accTitle: הליך לספירת המדפסות בשטח
    accDescr: לוקחים את רשימת התורים וה-drivers עם PowerShell, ולפי DriverName ולפי הצלבת Manufacturer מול רשימת חבילות צד שלישי מ-pnputil מחלקים אותם לתורים על IPP class driver, תורי Universal Print (תואמי WPP), תורים על drivers inbox אחרים (XPS ופקס מוסרים, Generic / Text Only אי אפשר להניח ששורדים, Microsoft Print to PDF אינו ברשימת ההסרה ולכן נשפט בנפרד), ותורים על drivers של יצרן (מועמדים להחלפה); לתורים על IPP class driver מאשרים בנפרד הסמכת Mopria, IPP מופעל ונגיש לחיבורי רשת, ומצב IPP over USB לחיבורי USB, ואז מצליבים כל תור מול התורים שהגדרות האפליקציה וקוד ההדפסה מצביעים אליהם
    list["לוקחים את הרשימה עם Get-Printer / Get-PrinterDriver"]
    list --> cls{"DriverName והספק"}
    cls -->|"IPP Class"| ipp["תור על IPP class driver"]
    cls -->|"Universal Print Class"| up["תור Universal Print"]
    cls -->|"Inbox אחר"| inbox["שופטים בנפרד עם טבלת פרק 4"]
    cls -->|"יצרן"| vendor["מועמד להחלפה"]
    ipp --> mop["בודקים Mopria, נגישות IPP, USB"]
    mop --> match["מצליבים מול הגדרות וקוד האפליקציה"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["ממיינים עם טבלת ההחלטה"]

איור 14: לקיחת הרשימה ומיון לפי שם אינם דורשים הרשאות administrator; הצלבת הספק דורשת הרשאות administrator ל-pnputil.

מצליבים את הרשימה הזו מול התורים שהגדרות האפליקציה, קוד ההדפסה וה-SDKs שהיא משתמשת בהם מפנים אליהם. אם רושמים את ה-driver, הסמכת Mopria, סוג החיבור, נגישות IPP ומצב הפעלת USB לכל אתר לקוח, אפשר לעשות את השיפוט עם הטבלה בפרק 4.

אם יעד ההדפסה לא שורד WPP ואי אפשר לרשום אותו מחדש, מספקים את הנתיב החלופי בפרק 6 או מחליטים לא להשתמש ב-WPP לפני ספירת הקוד. אם המכשיר יכול להיות מושפע משינוי דירוג IPP גם בלי WPP, ממשיכים מ-5.2 ואילך. אם לא משתמשים ב-WPP ולהחלפת driver אין אפקט, ההחלטה היא להמשיך לפעול בנתיב הנוכחי.

כדי לבדוק את שם ה-driver מתוך האפליקציה, קוראים PrintQueue.QueueDriver.Name עם System.Printing של WPF.²⁰

using System.Printing;

// מכלי ניהול או מאפליקציית desktop, מציגים את שם ה-driver של כל תור
using var server = new LocalPrintServer();
foreach (PrintQueue queue in server.GetPrintQueues(
    new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }))
{
    Console.WriteLine($"{queue.Name}\t{queue.QueueDriver?.Name}\t{queue.QueuePort?.Name}");
}

עם זאת, מרחב השמות System.Printing אינו תומך בשימוש בתוך Windows service. אם מדפיסים משירות תושב, שמים את האבחון הזה בכלי הניהול במקום.²¹ למגבלות על הדפסה משירות, ראו איך בונים ומפעילים Windows Services ופרק 7 במאמר הקודם.

5.2 בדיקה 1: האם נשמרות ומשחזרות הגדרות ספציפיות ל-driver?

הדבר הקשה ביותר למצוא הוא הגדרות הדפסה שמורות. הסיבה שהן נשברות שונה לפי איך שומרים אותן.

DEVMODE יכול לשאת נתונים פרטיים אחרי החברים הציבוריים שלו, עם הגודל שניתן ב-dmDriverExtra. Windows מאמת רק את החלק הציבורי, ונתונים פרטיים פגומים יכולים להקריס את ה-driver בתהליך האפליקציה או ה-spooler.²²

flowchart TB
    accTitle: החלקים הציבוריים והפרטיים של DEVMODE
    accDescr: מבנה DEVMODE נושא נתונים פרטיים שה-driver מגדיר ומסומנים ב-dmDriverExtra אחרי החברים הציבוריים; רק החלק הציבורי מאומת על ידי Windows והחלק הפרטי ניתן לפירוש רק על ידי ה-driver הזה, כך ששמירה בשלמות מאבדת את משמעותו כשה-driver משתנה
    dm["מבנה DEVMODE"]
    dm --> pub["חלק ציבורי (dmSize)"]
    dm --> priv["חלק פרטי (dmDriverExtra)"]
    pub --> chk["מאומת על ידי Windows"]
    priv --> only["מפורש רק על ידי ה-driver הזה"]
    only --> lost["מאבד את משמעותו כשה-driver משתנה"]

איור 15: מהגדרה שנשמרת בשלמות, החלק שנשבר הוא החלק הפרטי.

PrinterSettings שקיבל את ההגדרות דרך SetHdevmode מעתיק את האזור הפרטי הזה פנימית.²³ גרסת .NET Framework של PrinterSettings נושאת את המאפיין Serializable, ו-binary serialization כולל שדות פרטיים כברירת מחדל, כך ששמירת האובייקט כולו נושאת את אותה תלות.²⁴²⁵

גרסת .NET של PrinterSettings, לעומת זאת, אין לה מאפיין Serializable, ומימוש ששומר את המאפיינים הציבוריים בנפרד בפורמט משלו אינו שומר את buffer ה-DEVMODE ה-native או את אזור dmDriverExtra.²⁴ מה לעקוב אחריו במקרה הזה הוא ערכים תלויי driver.

flowchart TB
    accTitle: שמירת DEVMODE ושמירת ערכים מנוהלים נשברות אחרת
    accDescr: מימוש ששומר את buffer DEVMODE בשלמותו ואחד שעושה serialize ל-PrinterSettings שלם אחרי קבלת האזור הפרטי דרך SetHdevmode נושאים את החלק הפרטי איתם ומאבדים את משמעותם כשה-driver משתנה; מימוש ששומר ערכי מאפיינים ציבוריים נושא מספרי נייר ומגשים Custom או ספציפיים ליצרן שהם ערכים מול רשימת driver היצרן ואינם מובטחים לאותה משמעות תחת IPP class driver; שניהם מוחלפים בתכנון ששומר רק את הכוונה
    a["שומרים DEVMODE בשלמות"]
    a --> a1["נושא את החלק הפרטי איתו"]
    s["שומרים בשלמות אחרי SetHdevmode"] --> a1
    a1 --> a2["מאבד את משמעותו כשה-driver משתנה"]
    b["שומרים ערכי מאפיינים ציבוריים"]
    b --> b1["נושא מספרי נייר ומגשים מותאמים"]
    b1 --> b2["אין ערובה לאותה משמעות ב-driver החדש"]
    a2 --> c["שניהם עוברים לשמירת הכוונה בלבד"]
    b2 --> c

איור 16: שמירת האובייקט כולו אחרי SetHdevmode נופלת בצד החלק הפרטי; אופני הכשל שונים, אבל שניהם נושאים מצב driver.

אם RawKind מייצג PaperKind או PaperSourceKind סטנדרטי, הוא שומר על משמעותו כשה-driver משתנה. מה שאינו מובטח הוא שמספרים Custom או ספציפיים ליצרן מצביעים לאותו נייר או מגש ב-driver אחר. לא מתייחסים לערכים סטנדרטיים כנשברים באופן גורף.²⁶²⁷

flowchart TB
    accTitle: אילו ערכי נייר ומגש שמורים נשברים
    accDescr: מבין ערכי RawKind, אלה שתואמים לגדלי נייר סטנדרטיים (PaperKind) כמו A4 או מקורות נייר סטנדרטיים (PaperSourceKind) כמו Upper ו-Lower שומרים על משמעותם כשה-driver משתנה, בעוד ש-Custom וערכים ספציפיים ליצרן הם מספרים מול רשימת driver היצרן ו-IPP class driver אינו מובטח לפרש אותם כאותו נייר או מגש
    raw["RawKind שמור"]
    raw --> std["ערכים סטנדרטיים (PaperKind וכו')"]
    raw --> cus["ערכי Custom וספציפיים ליצרן"]
    std --> keep["שומר על משמעותו כשה-driver משתנה"]
    cus --> lost["אין ערובה לאותו נייר או מגש"]

איור 17: מה שנשבר אינו הערכים הסטנדרטיים אלא הערכים המותאמים מול רשימת driver היצרן.

גם PrintTicket מגדיר את המילות המפתח הציבוריות שלו ב-namespace psk אבל יכול להכיל הרחבות פרטיות ספציפיות למכשיר. הכלל הוא שאלמנטים של צד שלישי שייכים ל-namespace שמשויך בבירור לצד השלישי הזה. אם namespace של יצרן מופיע ב-XML השמור, בודקים אותו כהגדרה ספציפית ל-driver.²⁸²⁹

תיקון: שומרים רק את ה-“כוונה”

שומרים את הכוונה, כלומר את בחירת גודל הנייר, הכיוון, דופלקס, עותקים ומגש, בקובץ הגדרות משלכם באמצעות מילות מפתח ציבוריות. במקום לשאת קדימה את המצב הפנימי של ה-driver, מצליבים אותו מול היכולות הנוכחיות מיד לפני ההדפסה.

ב-WPF, מקבלים את היכולות עם PrintQueue.GetPrintCapabilities, מבטאים את הבקשה כ-PrintTicket, ומעבירים אותה ל-MergeAndValidatePrintTicket.³⁰ הדבר לעקוב אחריו כאן הוא ש-בקשה לא נתמכת לא בהכרח מייצרת שגיאה. ה-driver עשוי לפתור את הקונפליקט ולהחזיר ticket תקף, בדרך כלל עם ההגדרה מוחלפת בברירת מחדל או דומה.

אם ValidationResult.ConflictStatus הוא ConflictResolved, משווים את הדופלקס והמגש ב-ValidatedPrintTicket עם הבקשה, רושמים את ההפרש, ומודיעים למשתמש.³¹

flowchart TB
    accTitle: תכנון ששומר רק את הכוונה ובודק אותה מול יכולות מיד לפני ההדפסה
    accDescr: קובץ ההגדרות מחזיק רק את הכוונה לנייר, כיוון, דופלקס, עותקים ומגש במילות מפתח ציבוריות; מיד לפני ההדפסה, מקבלים את יכולות המדפסת הנוכחית עם GetPrintCapabilities, עוברים ב-MergeAndValidatePrintTicket, מדפיסים כמו שזה אם ConflictStatus הוא NoConflict, ואם הוא ConflictResolved משווים את הפריטים שהוחלפו עם הבקשה ושולחים אותם ללוג ולהתראה
    cfg["קובץ הגדרות: כוונה בלבד (נייר, כיוון, דופלקס, עותקים)"]
    cfg --> caps["GetPrintCapabilities מיד לפני ההדפסה"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatus"}
    st -->|"NoConflict"| print["מדפיסים"]
    st -->|"ConflictResolved"| tell["רושמים ומודיעים על ההפרש מהבקשה"]

איור 18: שומרים את כוונת ההגדרות ומאמתים אותה מול היכולות הנוכחיות בזמן ההדפסה. לא משתמשים בשקט בהגדרה שהוחלפה; בודקים את ההפרש.

ב-WinForms, בוחרים מחדש את הנייר מ-PrinterSettings.PaperSizes לפי Kind או ממדים ולא לפי שם. מקורות נייר מ-PaperSources ניתנים לשימוש חוזר כשהם ערכים סטנדרטיים ייחודיים כמו Upper או Lower, אבל כמה מגשים קנייניים יכולים לחזור מקובצים יחד כ-PaperSourceKind.Custom. ו-PaperSource אינו נושא ממדי נייר. לא מזהים מגש קנייני לפי Kind לבדו; או ממפים אותו במפורש ליכולות הנוכחיות או נותנים למשתמש לבחור שוב.²⁷

5.3 בדיקה 2: האם יש תלות בשמות מדפסת או תור?

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

המקומות לבדוק הם שלושה: קובץ ההגדרות, שמות מקודדים בקוד, והפנים של SDKs וספריות דוחות. גם כשלקוד שלכם אין שם קבוע, SDK של יצרן עשוי לקרוא לתור או ל-driver ספציפי פנימית. מצליבים את תיעוד ה-SDK מול הרשימה מ-5.1.

flowchart TB
    accTitle: שלושה מקומות שבהם תלות בשם תור יכולה להסתתר
    accDescr: תלות בשם תור יכולה להסתתר בשלושה מקומות, שם קבוע בקובץ ההגדרות, שם קבוע מקודד בקוד, והתור או ה-driver ש-SDK של יצרן או ספריית דוחות קורא פנימית; שני הראשונים נמצאים בחיפוש בקוד ובהגדרות, האחרון בתיעוד ה-SDK וברשימה מ-5.1
    dep["תלות בשמות תורים"]
    dep --> cfg["שם קבוע בקובץ ההגדרות"]
    dep --> code["שם קבוע מקודד בקוד"]
    dep --> sdk["קבוע בתוך ה-SDK או הספרייה"]
    cfg --> grep["מוצאים בחיפוש בקוד ובהגדרות"]
    code --> grep
    sdk --> doc["מאשרים עם תיעוד ה-SDK ורשימת 5.1"]

איור 19: גם כשלקוד שלכם אין שם תור, תלות עשויה להישאר בתוך SDK או ספרייה.

התיקון הוא לבדוק בהפעלה שהשם המוגדר קיים ב-PrinterSettings.InstalledPrinters, ואם הוא לא נמצא, לרשום ולהודיע למשתמש. גם מאפשרים לבחור מחדש את יעד ההדפסה ממסך ההגדרות.

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

flowchart TB
    accTitle: אימות שם המדפסת בהפעלה
    accDescr: בהפעלה, בודקים אם שם המדפסת בקובץ ההגדרות קיים ב-InstalledPrinters; אם כן, מדפיסים; אם לא, רושמים, מודיעים למשתמש, ונותנים להם לבחור שוב, ולא נופלים בשקט למדפסת ברירת המחדל
    start["הפעלה: שם מדפסת מההגדרות"]
    start --> exists{"קיים ב-InstalledPrinters?"}
    exists -->|"כן"| print["מדפיסים לתור הזה"]
    exists -->|"לא"| log["רושמים ומודיעים למשתמש"]
    log --> pick["בוחרים שוב במסך ההגדרות"]
    exists -.->|"לא עושים את זה"| silent["נופלים בשקט למדפסת ברירת המחדל"]

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

5.4 בדיקה 3: האם משתמשים במדפסת וירטואלית כדי לייצר קבצים?

ארכיון דוחות שמדפיס למדפסת PDF של צד שלישי וצופה בתיקיית הפלט, או עיבוד שיוצר קבצי ביניים עם XPS Document Writer, מפסיק לעבוד כשהתור שהוא משתמש בו מוסר על ידי WPP.

עם זאת, מה שמוסר הוא מדפסות תוכנה שלא נתמכות על ידי WPP. לא מבלבלים בין מוצרים לא נתמכים כמו אלה בסגנון port monitor DLL לבין מוצרים שעודכנו לתמיכה ב-WPP, כמו OneNote. שלב 3 בפרק 7 מאשר אם התור שבאמת משתמשים בו הוא יעד הסרה.²

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

5.5 בדיקה 4: האם שליחת RAW עוברת בתור ש-WPP מסיר?

שליחת RAW היא השיטה של לדחוף נתוני שפת מדפסת דרך ה-spooler עם OpenPrinter → StartDocPrinter (סוג נתונים “RAW”) → WritePrinter → EndDocPrinter. המסמך חייב לתאר במלואם את הגדרות ההדפסה בשפת החומרה, והגדרות DEVMODE אינן בשימוש.³²³³

זו הגישה הסטנדרטית לתוויות ולקבלות, אבל שליחת RAW אינה “תקשורת ישירה שעוקפת את ה-spooler”. גם אם ה-driver משמש בפועל רק כ-pass-through לפורט, ה-pass-through הזה אובד כש-WPP מסיר את התור.

flowchart TB
    accTitle: נתיב שליחת RAW ואיפה WPP מסיר אותו
    accDescr: האפליקציה דוחפת נתוני שפת מדפסת ל-spooler עם OpenPrinter, StartDocPrinter ו-WritePrinter, ותור שלא שורד WPP (כמו תור על driver של יצרן) פועל כ-pass-through לפורט ואחר כך למדפסת, כך שכש-WPP מסיר את התור ה-pass-through נעלם
    app["אפליקציה: StartDocPrinter (RAW), WritePrinter"]
    app --> spooler["Spooler"]
    spooler --> queue["תור שלא שורד WPP (pass-through)"]
    queue --> port["פורט"]
    port --> printer["מדפסת תוויות או קבלות"]
    wpp["WPP מופעל"] -.->|"התור נעלם"| queue

איור 21: שליחת RAW משתמשת ב-driver רק כ-pass-through, אבל ה-pass-through עצמו נעלם.

מה לבדוק הוא לאיזה צירוף של תור, driver ופורט שולחים. לא רק תורים על drivers של יצרן אלא גם drivers inbox למדפסות פיזיות מלבד IPP class driver, כמו Generic / Text Only, אי אפשר להניח ששורדים. כל דבר שמאושר שנעלם ברשימת ההסרה בפרק 7 צריך נתיב אחר באותה מידה.¹³

גם, Microsoft Learn לא קובעת שאפשר לשלוח PDL קנייני כ-RAW לתור על IPP class driver. כי זה תלוי ב-PDLs שמימוש IPP של המדפסת מקבל, לא מסיקים ש-“מעבר ל-IPP מעביר את אותם נתוני RAW”.

6. נתיב מילוט למדפסות תוויות וקבלות

KomuraSoft ממליצה להחזיק לפחות נתיב פלט אחד לתוויות ולקבלות שאינו תלוי ב-spooler.

גם כשמדפסת נופלת תחת חריג החתימה בפרק 2, המשך אספקת driver היצרן והשימוש בו תחת WPP אינם מובטחים.¹ הנחיית troubleshooting של Microsoft גם מתעדת מקרה שבו מדפסות קבלות ותוויות מחוברות USB הפסיקו להדפיס אחרי עדכון ב-2021 והבעיה נפתרה ב-Known Issue Rollback.³⁴ לדעת את נתיבי הפלט בנפרד היא ההכנה.

לתכנון חיבור מחדש ב-TCP, החשיבה ב-מלכודות אפליקציית תקשורת serial חלה. לבחירת שיטת USB, ראו איך עובדים עם התקני USB מאפליקציית Windows. IPP כבוי כברירת מחדל בחלק מהמדפסות וצריך להפעיל אותו.⁴

השם “SDK” לבדו אינו אומר אם נתיב בלתי תלוי. משתמשים בתיעוד ה-SDK וברשימה מ-5.1 כדי לאשר אם הוא מדבר עם המכשיר ישירות או בסוף קורא לתור Windows.

כשמשתמשים בתור Windows, Universal Print בצד התואם ל-WPP, אבל גם הוא עובר ב-spooler. תור שאינו IPP class driver ואינו Universal Print נעצר תחת WPP אם הוא driver של צד שלישי, XPS או פקס, ותור inbox שלא ברשימת ההסרה, כמו Microsoft Print to PDF, נשפט בנפרד. “תואם WPP” ו-“בלתי תלוי ב-spooler” הם סיווגים שונים.

flowchart TB
    accTitle: זרימה להחלטה אם נתיב פלט תלוי ב-spooler
    accDescr: אם נתיב המועמד שולח לתור הדפסה של Windows, אז תור על IPP class driver שהמדפסת שלו Mopria certified ו, לחיבורי רשת, יש לה IPP מופעל ונגיש או, לחיבורי USB, במצב IPP over USB, ותור Universal Print כחלק מ-Windows Ready Print, תלויים ב-spooler אבל תואמי WPP; תורים על מכשירים לא-Mopria-certified או drivers של צד שלישי, ותורים שמוסרים לפי טבלת פרק 4 כמו XPS Document Writer ופקס, יכולים להיעצר תחת WPP; תורי inbox שלא ברשימת ההסרה כמו Microsoft Print to PDF נשפטים בנפרד כמו ב-5.1; אם הוא לא שולח לתור, SDK שקורא פנימית לתור או ל-driver חוזר לאותו שיפוט, בעוד ש-SDK שלא או נתיב ששולח ישירות למכשיר הוא נתיב מילוט שאינו תלוי ב-spooler
    route["נתיב פלט מועמד"]
    route --> q1{"שולח לתור הדפסה של Windows?"}
    q1 -->|"כן"| q4{"תור על IPP class driver?"}
    q4 -->|"כן"| q5{"מוסמכת Mopria?"}
    q5 -->|"כן"| q9{"IPP נגיש? (USB: over USB)"}
    q9 -->|"כן"| depok["תלוי, אבל תואם WPP"]
    q9 -->|"לא"| dep["תלוי, ויכול להיעצר תחת WPP"]
    q5 -->|"לא"| dep
    q4 -->|"לא"| q6{"תור Universal Print?"}
    q6 -->|"כן"| depok
    q6 -->|"לא"| q7{"מוסר לפי טבלת פרק 4?"}
    q7 -->|"כן (driver צד שלישי, XPS, פקס)"| dep
    q7 -->|"לא (Print to PDF וכו')"| indiv["שופטים בנפרד (5.1)"]
    q1 -->|"לא"| q2{"עובר ב-SDK של יצרן?"}
    q2 -->|"כן"| q3{"קורא לתור או ל-driver פנימית?"}
    chk["בודקים: תיעוד SDK ורשימת 5.1"] -.-> q3
    q3 -->|"כן"| q4
    q3 -->|"לא"| indep["נתיב מילוט בלי תלות"]
    q2 -->|"לא"| indep

איור 22: זה מתכנס לאיזה תור הנתיב בסוף עובר; מלבד תור על IPP class driver למכשיר Mopria certified ותור Universal Print, הכל מלבד תורי inbox שלא ברשימת ההסרה יכול להיעצר תחת WPP.

7. הליך אימות — עם ובלי WPP

קודם מאשרים את ענף האימות לפי אם משתמשים ב-WPP או לא. בשני המקרים, שומרים את הפלט מלפני השינוי ומאמתים עם יעדי ההדפסה שבאמת משתמשים בהם.

flowchart TB
    accTitle: הליך אימות הדפסה מפוצל לפי אם משתמשים ב-WPP
    accDescr: משחזרים את כל התורים במכונת בדיקה ושומרים את הפלט מלפני השינוי; אם משתמשים ב-WPP, מפעילים אותו, רושמים את התורים שהוסרו, משווים את הפלט אחרי רישום מחדש של מכשירים תואמים, ובודקים את הנתיב החלופי למכשירים לא תואמים; אם לא משתמשים, מזהים מחדש מכשירים פיזיים שכפופים לשינוי דירוג IPP עם WPP כבוי ומשווים את הפלט, ולכל השאר מאשרים הדפסה בתורים בפועל
    prepare["משחזרים ורושמים את כל התורים"]
    prepare --> baseline["שומרים את תוצאות ההדפסה מלפני השינוי"]
    baseline --> use{"משתמשים ב-WPP?"}
    use -->|"כן"| enable["מפעילים ורושמים את התורים שהוסרו"]
    enable --> compatible["רושמים מחדש מכשירים תואמים לפי הצורך"]
    compatible --> compare["משווים עם אותן הדפסות כמו קודם"]
    enable --> alternate["בודקים מכשירים לא תואמים בנתיב החלופי"]
    use -->|"לא"| physical{"מכשיר פיזי שכפוף לשינוי דירוג IPP?"}
    physical -->|"כן"| redetect["מסירים ומזהים מחדש עם WPP כבוי"]
    redetect --> compare
    physical -->|"לא"| existing["מאשרים הדפסה בתורים בפועל"]
    compare --> finish["רושמים את התוצאות ומשחזרים את מכונת הבדיקה"]
    alternate --> finish
    existing --> finish

איור 23: הפלט מלפני השינוי הוא קו הבסיס המשותף, ורק סביבות שמשתמשות ב-WPP מפעילות אותו. סביבות שלא משתמשות בודקות את שינוי דירוג IPP ואת ההדפסה בתורים בפועל.

7.1 הכנה משותפת: משחזרים כל יעד הדפסה במכונת בדיקה, לא בייצור

משתמשים ב-PC עם Windows 11 24H2 ואילך לאימות, ו-לא עושים את זה ב-PC ייצור. לחיבורי רשת, VM שיכול להגיע לאותן מדפסות מספיק. כדי להעריך רישום מחדש ב-USB או תקשורת ישירה, משתמשים במכונת בדיקה פיזית, אלא אם ה-VM יכול להעביר את אותו ממשק USB.

בלי קשר אם משתמשים ב-WPP, שלבים 1 ו-2 למטה שומרים את המצב לפני השינוי.

1. משחזרים כל תור שהאפליקציה משתמשת בו בשטח. מתקינים לא רק את המדפסות הפיזיות על drivers של יצרן אלא גם מדפסות PDF וירטואליות של צד שלישי ותורי inbox כמו Generic / Text Only, באותה תצורה. רושמים את שמות ה-drivers והגרסאות עם הסקריפט מ-5.1. ה-diff של ההסרה יכול לשפוט רק תורים שקיימים במכונת הבדיקה.
2. רצים על יכולות ההדפסה ושומרים את הפלט. בודקים את מסכי ההגדרות של נייר, מגש, דופלקס ועותקים, את הדפסת כל דוח, פלט PDF והדפסת תוויות, כדי ליצור קו בסיס להשוואה מאוחרת.

flowchart TB
    accTitle: תורים לשחזר במכונת הבדיקה
    accDescr: מבין התורים שהאפליקציה משתמשת בהם כפי שנמצאו בספירת 5.1, משחזרים את המדפסות הפיזיות על drivers של יצרן, את המדפסות הווירטואליות כמו PDF של צד שלישי, ואת התורים על drivers inbox כמו Generic / Text Only, כולם במכונת הבדיקה באותה תצורה כמו בשטח, ומראים שרשימת ההסרה בשלב 3 יכולה לשפוט רק תורים שקיימים במכונת הבדיקה
    inv["ספירת 5.1: תורים שהאפליקציה משתמשת בהם"]
    inv --> phys["מדפסות פיזיות (drivers של יצרן)"]
    inv --> virt["מדפסות וירטואליות (PDF של צד שלישי וכו')"]
    inv --> inbox["drivers inbox (Generic / Text Only וכו')"]
    phys --> vm["משחזרים במכונת הבדיקה באותה תצורה"]
    virt --> vm
    inbox --> vm
    vm --> judge["שופטים הישרדות עם רשימת ההסרה בשלב 3"]
    note["תורים חסרים לא מופיעים ב-diff ההסרה"] -.-> judge

איור 24: תור שנעדר ממכונת הבדיקה לא מופיע ב-diff ההסרה, ולכן קודם משחזרים כל תור שהספירה מצאה.

7.2 סביבות שמשתמשות ב-WPP: מפעילים אותו ומאמתים, כולל יעדי ההדפסה שנעלמו

אחרי שלבים 1 ו-2, ממשיכים בסדר הבא.

3. מפעילים WPP ורושמים את התורים שמוסרים. בחירת “Set up” תחת “Windows protected print mode” ב-“Printers & scanners” באפליקציית Settings מציגה את יעדי ההסרה בדיאלוג.² כשמפעילים דרך Group Policy, אין דיאלוג, ולכן שומרים את תוצאת Get-Printer לפני החלת ה-policy ומפעילים מחדש את מכונת הבדיקה אחרי ההחלה. מאשרים שהוא מופעל עם IsProtectedPrintEnabled או מסך Settings, ואז לוקחים את הרשימה שוב ורושמים את ה-diff.¹⁴
4. מתקינים מחדש את המדפסות התואמות שהוסרו. מתקינים אותן מחדש עם Windows Ready Print ומאשרים עם הסקריפט מ-5.1 ש-DriverName של המדפסת הפיזית השתנה ל-Microsoft IPP Class Driver.
5. חוזרים על אותן הדפסות ומשווים עם לפני השינוי. בודקים את הבחירות במסכי ההגדרות, את שחזור ההגדרות השמורות, ואת אובדן יעדי ההדפסה בגלל שינויי שם תור. גם מצליבים את השוליים, הגופנים והקווים של הפלט מול הפלט משלב 2.
6. מדפיסים מכשירים לא תואמים דרך הנתיב החלופי מפרק 6. משחזרים את המצב שבו “המדפסת אינה ברשימה” ומאשרים שהפלט עדיין עובד. לא רק הקוד שתיקנתם אלא גם הנתיב שסיפקתם הוא יעד אימות.

7.3 סביבות שלא משתמשות ב-WPP: מאמתים את השינוי בבחירת driver בלי להפעיל אותו

בסביבה שהחלטתם לא להשתמש ב-WPP, לא מבצעים את שלבים 3 ו-4. הפעלת WPP מסירה תורים שלמים, מה שמסתיר את אפקט הדירוג לבדו.

7.4 שחזור אחרי אימות והכנת הליך ה-provisioning

מכונת בדיקה ש-WPP הופעל בה באפליקציית Settings המקומית ניתנת לשחזור עם “Turn off”. אם הוחל מ-Group Policy או Intune, נחוץ שינוי policy בצד administrator, ולכן מכינים הליך שחזור שתואם לנתיב ההפעלה.²¹³

כיבוי WPP בחזרה משאיר את המדפסות שהותקנו מחדש עם Windows Ready Print כמו שהן. מדפסות שהיו לא תואמות מותקנות מחדש ידנית.²¹⁰

ל-provisioning, בונים את policy ה-WPP ואת הליך רישום המדפסות מחדש לתוך מנגנון ההפצה שפורס ב-מ-Group Policy ל-Intune. הפצת drivers של צד שלישי דרך Point and Print דורשת אישורי administrator כברירת מחדל מאז KB5005652 ב-2021,³⁴ ותחת WPP ההפצה עצמה כבר לא קורית.⁹ בסביבות שמשתמשות ב-WPP, מחליפים הליכים שתלויים בהפצת driver בהחלת policy ובהליך הרישום מחדש האלה.

flowchart TB
    accTitle: עדכון הליך ה-provisioning
    accDescr: ההליך שהפיץ drivers של צד שלישי דרך Point and Print מושמט כי אישורי administrator נדרשים מאז 2021 ותחת WPP ההפצה עצמה כבר לא קורית, ובמקומו policy ה-WPP (Group Policy או OMA-URI) והליך רישום המדפסות מחדש נבנים לתוך מנגנון ההפצה
    old["מפיצים drivers של צד שלישי דרך Point and Print"]
    old --> why1["אישורי administrator נדרשים מאז 2021"]
    old --> why2["אין הפצה בכלל תחת WPP"]
    why1 --> drop["משמיטים מההליך"]
    why2 --> drop
    drop --> add["בונים פנימה את policy ה-WPP והליך הרישום מחדש"]

איור 25: הליך הפצת drivers מוחלף בהליך להפצת policy ה-WPP ורישום מדפסות מחדש.

8. סיכום

התגובה הנדרשת נקבעת בסדר “האם יעד ההדפסה שורד?” → “במה הקוד תלוי?” → “תחת אילו תנאים מאמתים?”.

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

flowchart TB
    accTitle: עץ החלטה אם לתקן או רק לאמת
    accDescr: קודם מחליטים אם תור היעד שורד WPP (תור ענן Universal Print או מדפסת וירטואלית נתמכת ב-WPP) או אם אפשר לרשום מחדש את המדפסת הפיזית עם Windows Ready Print; אם לא, בוחרים בין אספקת נתיב אחר לבין אי-שימוש ב-WPP; אם המכשיר תומך ב-IPP וניתן להחלפה בשינוי הדירוג, בודקים בסדר שמירת הגדרות ספציפיות ל-driver, תלויות בשמות תורים או במדפסות וירטואליות (כולל בתוך SDKs וספריות), ושליחת RAW, ומתקנים כל אחד שחל לפני שממשיכים; לבסוף, סביבות שמשתמשות ב-WPP הולכות לאימות עם WPP מופעל בפרק 7, סביבות שלא שולחות מכשירים פיזיים עם IPP לאימות זיהוי מחדש עם WPP כבוי ותורי ענן או וירטואליים לבדיקות פלט בפועל, ואם לא משתמשים ב-WPP ולהחלפה אין אפקט, ממשיכים לפעול בנתיב הנוכחי
    q0{"האם התור שורד WPP או ניתן לרישום מחדש?"}
    q0 -->|"לא"| alt{"מה לעשות"}
    alt -->|"מספקים נתיב אחר"| qi{"תומך ב-IPP וניתן להחלפה?"}
    alt -->|"לא משתמשים ב-WPP"| qi2{"תומך ב-IPP וניתן להחלפה?"}
    qi -->|"כן"| q1{"נשמרות הגדרות ספציפיות ל-driver?"}
    qi -->|"לא"| verify["רק מאמתים (פרק 7)"]
    qi2 -->|"כן"| q1
    qi2 -->|"לא"| keep["ממשיכים לפעול בנתיב הנוכחי"]
    q0 -->|"כן"| q1
    q1 -->|"כן"| fix1["מתקנים (5.2)"]
    fix1 --> q2{"תלוי בשמות תורים או במדפסות וירטואליות?"}
    sdk["כולל תלויות בתוך SDKs וספריות"] -.-> q2
    q1 -->|"לא"| q2
    q2 -->|"כן"| fix2["מתקנים (5.3, 5.4)"]
    fix2 --> q3{"שולח RAW לתור שלא שורד WPP?"}
    q2 -->|"לא"| q3
    q3 -->|"כן"| fix3["מספקים pass-through (פרק 6)"]
    fix3 --> vq{"משתמשים ב-WPP?"}
    q3 -->|"לא"| vq
    vq -->|"כן"| verify
    vq -->|"לא"| pq{"מכשיר פיזי עם IPP?"}
    pq -->|"כן"| redetect["אימות זיהוי מחדש בלי WPP (7.3)"]
    pq -->|"לא"| outchk["מאשרים פלט בתורים בפועל"]

איור 26: קודם מחליטים אם התור שורד WPP; לתלויות קוד, ממשיכים לבדיקה הבאה גם אחרי תיקון אחד, ומאמתים את הנתיב המתוקן בסוף. אם לא משתמשים ב-WPP, מאמתים לא עם הפעלת WPP בפרק 7 אלא בזיהוי מחדש של מכשירים פיזיים עם IPP כש-WPP כבוי ובפלט בפועל בתורי ענן ווירטואליים.

שמים את מועד ההכנה על תוכנית הפריסה שלכם, לא על תאריכי Microsoft

נאמר ש-WPP יופעל כברירת מחדל בעתיד, אבל אין תאריך.¹⁰ שמים את מועד ההכנה לפני שמפעילים WPP בעצמכם, או לפני שמפרסים את עדכון התכונות Windows 11 24H2 ואילך לשטח. 1 ביולי 2027 הוא אבן דרך בצד אספקת ה-drivers, לא מועד אחרון לאפליקציות עסקיות.¹

flowchart TB
    accTitle: איפה לשים את מועד ההכנה בצד האפליקציה העסקית
    accDescr: לוקחים את הרשימה וסופרים עכשיו, מסיימים את שינויי הנתיב והאימות עד המועד שלכם, כלומר לפני שמפעילים WPP בעצמכם או לפני שמפרסים את עדכון התכונות 24H2 ואילך; עצירת עדכוני driver ב-1 ביולי 2027 היא אבן דרך בצד האספקה, לא מועד ההכנה, והמטרה היא להגיע למצב שלא מושפע מהפעלת ברירת המחדל של WPP, שתזמונה לא נקבע, מתי שזה יבוא
    now["עכשיו: לוקחים את הרשימה וסופרים"]
    now --> prep["שינויי נתיב ואימות"]
    prep --> deadline["מועד: לפני הפעלת WPP בעצמכם / לפני פריסת עדכון התכונות"]
    deadline --> fine["לא מושפעים כש-WPP מופעל כברירת מחדל (תזמון לא נקבע)"]
    ms["1 ביולי 2027: עדכוני driver נעצרים"] -.->|"אבן דרך בצד האספקה, לא מועד"| prep

איור 27: שמים את המועד על תוכנית הפריסה שלכם, ולא הופכים את תאריכי אבן הדרך של Microsoft לקו החיתוך שלכם.

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

סביבות שנשארות ב-Windows 10 מחוץ להיקף התוכנית הזו, אבל התמיכה ב-Windows 10 (22H2) בערוץ הרגיל הסתיימה באוקטובר 2025. ל-Enterprise LTSC ול-IoT Enterprise LTSC יש תאריכי סיום שונים לפי מהדורה, ולכן בודקים את מחזור החיים. להחלטות שכוללות ESU ו-LTSC, ראו אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10, ולמחשבים תעשייתיים, איזה Windows לשים על PC תעשייתי?. ההכנה להדפסה אינה שלמה עד שחוזרים על אימות פרק 7 ב-Windows 11 שאליו עוברים.

מאמרים קשורים

• הדפסה ופלט PDF באפליקציות עסקיות של Windows — בחירה בין System.Drawing.Printing, WPF וספריות דוחות
• איך בונים פלט דוחות Excel — COM / Open XML / תבניות
• איך בונים ומפעילים Windows Services — מבחירה בין Task Scheduler לשירותים ועד הפיכת BackgroundService ל-Windows Service
• איך עובדים עם התקני USB מאפליקציית Windows — בחירה בין Virtual COM, HID ו-WinUSB
• מלכודות אפליקציית תקשורת serial — דרך חיבור מחדש ותכנון לוג
• מ-Group Policy ל-Intune — מדריך מיגרציית ניהול מכשירים לעסקים קטנים ובינוניים
• אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10 — טבלת החלטה ל-ESU, LTSC והחלפה

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בספירת התלויות ב-printer drivers של אפליקציות עסקיות עם הדפסת דוחות ותוויות, בשכתוב נתיבי הדפסה (יצירת PDF ישירה, שליטה ישירה במדפסות תוויות), ובתכנון תוכניות אימות שמניחות Windows protected print mode.

• ייעוץ טכני וסקירת תכנון
• Windows Custom Software Development
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם המדפסות והאפליקציות שעובדות היום יפסיקו פתאום להדפיס אחרי יולי 2026 או יולי 2027?

לא. התוכנית של Microsoft היא ניתוק הדרגתי בצד האספקה: drivers חדשים של צד שלישי כבר לא מתפרסמים ב-Windows Update, דירוג ה-drivers מעדיף את IPP class driver, ועדכונים כבר לא מתקבלים. התוכנית קובעת במפורש שהיא לא מבטלת drivers קיימים, ו-drivers קיימים עדיין ניתנים להתקנה מ-installers של היצרן. המצבים המסוכנים הם, במכשירים ש-IPP class driver מתאים להם, הרגע שמחליפים PC או מתקינים מחדש את ה-OS וה-driver מוחלף אוטומטית ב-IPP class driver, והרגע שבו Windows protected print mode מופעל.

האם Windows protected print mode מופעל כברירת מחדל?

נכון לכתיבת המאמר (ספטמבר 2026) הוא כבוי כברירת מחדל, ומפעילים אותו מאפליקציית Settings, מ-Group Policy או מ-Intune. עם זאת, ה-FAQ של Microsoft קובע במפורש שהוא יופעל כברירת מחדל בנקודה עתידית כלשהי. אין תאריך, ולכן ההכנה היא להגיע למצב שבו הפעלה לא גורמת לבעיה לפני שזה קורה.

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

מדפסות שלא יכולות לקבל הסמכת Mopria מופיעות בין התנאים שבהם חתימת driver ממשיכה להיות מותרת כחריג אחרי 15 בינואר 2026. כך ש-driver של יצרן עשוי להישאר זמין בינתיים, אבל בסביבה שבה Windows protected print mode מופעל, מדפסות שמשתמשות ב-drivers של צד שלישי מוסרות, כך שאי אפשר להשתמש בהן כמו שהן. SDK של יצרן שמדבר עם המכשיר ישירות ב-TCP, USB או serial, או נתיב שמפעיל את המדפסת בשליחת שפת המדפסת ישירות, מנתק אתכם משינויים ב-Print Spooler. SDK שקורא פנימית לתור Windows או ל-driver נעצר באותה מידה כש-driver הצד השלישי נעלם, כך שזה אינו נתיב מילוט.

האם קוד ההדפסה של האפליקציה יכול להישאר על PrintDocument?

נתיב ההדפסה GDI ונתיב ההדפסה XPS נשארים, ו-Microsoft קובעת במפורש שאין לה תוכנית לבטל פונקציונליות של drivers מסוג v3/v4. אפליקציה שמציירת רק עם PrintDocument או FixedDocument היא משהו לאמת, לא משהו לתקן. מה שצריך תיקון הוא קוד ששומר ומשחזר הגדרות ספציפיות ל-driver (החלק הפרטי של DEVMODE או namespace פרטי ב-PrintTicket), קוד שתלוי בשם תור ספציפי או בשם מדפסת וירטואלית (כולל מה ש-SDK של יצרן או ספריית דוחות קורא פנימית), וקוד ששולח נתוני RAW דרך ה-spooler לתור שלא שורד WPP (כמו תור על driver של יצרן). עם זאת, אם מדפסת היעד עצמה היא דגם שאי אפשר לרשום מחדש עם Windows Ready Print, כל התור נעלם תחת Windows protected print mode גם כשהקוד רק מצייר, כך שהכנת נתיב אחר באה קודם.

מאיפה מתחילים?

מתחילים בלקיחת רשימת המדפסות וה-drivers בכל אתר לקוח. Get-Printer ו-Get-PrinterDriver של PowerShell אומרים איזה תור משתמש באיזה driver (v3 או v4, או IPP class driver) בלי הרשאות administrator. אחר כך מצליבים את הרשימה מול התורים שהאפליקציה מציינת בשם, שומרת להם הגדרות, או שולחת אליהם RAW, וממיינים ל-'משאירים כמו שזה', 'מאמתים' ו-'משנים את הנתיב' לפי טבלת ההחלטה במאמר הזה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.