Принтер «Офлайн» назавжди: налаштування драйвера Windows, яке це ламає

Налаштування драйвера, яке ламає систему: SNMP-статус на порту

У Windows мережевий принтер часто представлений як Standard TCP/IP Port.
Цей порт — це не лише «IP-адреса». Він також містить конфігурацію моніторингу: протоколи, таймаути і — критично — запити стану через SNMP.

Коли увімкнено SNMP Status Enabled, Windows періодично опитує пристрій, щоб вирішити, чи він «онлайн».
Якщо цей запит не вдається (невірний community string, SNMP вимкнений на принтері, SNMP блокується фаєрволом, пристрій у сплячому режимі не відповідає на SNMP, або ACL у VLAN дозволяють 9100 але блокують UDP/161), Windows може позначити принтер як Offline.
Друк може продовжувати працювати на рівні протоколу, але Windows навіть не буде намагатися, бо вважає, що пункт призначення недоступний.

Ось чому ви бачите класичну фразу «Я можу пропінгувати, я можу відкрити веб-сторінку, але Windows показує offline». Ping — це ICMP.
Веб UI принтера — TCP/80 або TCP/443. Друк часто — TCP/9100 (RAW), TCP/515 (LPD) або IPP.
SNMP — це UDP/161. Різний протокол, різні ACL, різні режими відмови.

Конкретний патерн поломки

• Мережевий шлях в порядку (ICMP і HTTPS працюють).
• Принтер справний (друкує з інших машин або з передньої панелі тестової сторінки).
• Windows говорить Offline, бо перевірка стану порт-монітором не пройшла.
• Вимкнення SNMP-статусу на цьому порту миттєво переводить принтер в Online і черги знову йдуть.

Що робити, прямо і чесно

Якщо у вашому середовищі SNMP не підтримується надійно (а багато де так), вимкніть SNMP-статус для портів, що використовуються кінцевими користувачами.
Ви все одно можете запускати моніторинг парку через окрему систему моніторингу з відомою правильною SNMP-конфігурацією.
Змішувати «допомога UI показати рівні тонера» з «перекрити весь друк» — це архітектурний вибір, і він поганий.

Жарт №1: Принтери не мають «режимів офлайн». Вони мають режим «я караю вас за те, що ви повірили в галочки».

Що насправді означає «Офлайн» у Windows (і чого це не означає)

Статус «Офлайн» у Windows — це не універсальна істина. Це думка підсистеми друку, заснована на сигналах, яким вона довіряє.
Ця думка може бути хибною.

Шари, що беруть участь

• Застосунок: відправляє завдання в локальний спулер через Win32 print API.
• Spooler: ставить у чергу, рендерить і передає завдання порт-монітору.
• Port monitor: реалізує транспорт (Standard TCP/IP Port, WSD, LPR, IPP тощо).
• Транспорт: пакети в мережі (TCP/9100, UDP/161 для SNMP тощо).
• Пристрій: прошивка принтера, стани сну, додатки та дивовижна кількість «характеру».

«Офлайн» може виникати через:

• Порт-монітор вважає пристрій недосяжним (збій перевірки стану).
• Служба спулера нездорова або зависла.
• Драйвер викликає падіння процесу спулера або не може відрендерити.
• Принтер має іншу IP-адресу, ніж думає порт (DHCP змінив, DNS застарів).
• Політика або запис у реєстрі змушує працювати в режимі «Work Offline».

Два статуси, які не слід плутати

• Offline (пристрій недосяжний): Windows не надсилає завдання.
• Error / Attention required: Windows може надсилати завдання, пристрій може утримувати їх.

Виправлення залежить від того, який шар бреше. Ваше завдання — швидко виявити брехуна.

Швидкий план діагностики (перший/другий/третій)

Коли принтер «Офлайн» і користувачі ходять туди-сюди, як під час пожежної тривоги, вам не потрібна філософія друку.
Потрібно швидко відсортувати: мережа, пристрій, моніторинг порту Windows або спулер/драйвер.

Перший крок: перевірте базові речі правильним протоколом

1. Підтвердьте IP-адресу, на яку спрямовує Windows (властивості принтера → Ports, або через PowerShell).
2. Перевірте TCP/9100 (або налаштований протокол) з клієнта або сервера друку.
3. Перевіряйте SNMP/161 лише якщо SNMP-статус увімкнено; в іншому випадку ігноруйте його.

Другий крок: перевірте «двигун думки» Windows

1. Подивіться конфігурацію Standard TCP/IP Port: чи увімкнено SNMP status? community string? правильний device index?
2. Переконайтесь, що ви не використовуєте WSD, якщо вам не до вподоби періодичні проблеми з виявленням.
3. Перезапустіть Print Spooler лише після того, як зберете достатньо доказів (стан черги, помилки).

Третій крок: ізолюйте збій в драйвері/спулері

1. Спробуйте Microsoft class driver (generic PCL / PS), щоб довести помилку, пов’язану з драйвером.
2. Перевірте логи PrintService на предмет падінь, таймаутів або помилок порту.
3. Перенесіть принтер на новий порт (той самий IP, свіжий порт), щоб очистити можливий пошкоджений стан монітора порту.

Цей план уперто прагне швидкості і впевненості. Ваша мета — не «пробувати щось».
Ваша мета — приймати по одному рішення на основі доказів.

Факти та історія, що пояснюють сучасний безлад

Друк — одна з тих галузей ІТ, де вчорашня обіцянка сумісності — сьогоднішній збій.
Кілька конкретних фактів допомагають пояснити, чому одна галочка може зруйнувати вівторок.

1. SNMP (Simple Network Management Protocol) походить із кінця 1980-х і призначався для легкого моніторингу пристроїв, а не як шлюз доступності для доставки завдань друку.
2. JetDirect-стиль RAW-друку на TCP/9100 став поширеним у 1990-х, бо був простим і швидким: відкривати TCP-сокет, стримити байти, закрити.
3. LPR/LPD (TCP/515) ще старіший, успадкований від UNIX-традицій друку, і поводиться по-іншому при відмовах (семантика черг, банерні опції).
4. Windows представив WSD (Web Services for Devices) для спрощення виявлення пристроїв. На практиці WSD може бути крихким через різні підмережі, стани сну та обмеження мультикасту.
5. Вендори принтерів постачають «status monitors», що опираються на SNMP, бо саме через нього отримують рівні тонера, статус лотків і застрягання паперу — поки команда безпеки не заблокує UDP/161.
6. SNMP v1/v2c використовують community strings, які фактично є спільними паролями; багато організацій вимикають або суворо обмежують SNMP, ламаючи припущення Windows про «public».
7. Сучасні політики жорсткої безпеки часто блокують вхідний та вихідний UDP за замовчуванням, і SNMP часто постраждає навіть якщо порти друку дозволені.
8. Режими сну принтерів можуть вибірково вимикати сервіси; деякі пристрої тримають TCP/9100 доступним, але не відповідають на SNMP, поки повністю не прокинуться.
9. Статус «Офлайн» у Windows не є стандартизованою мережею істини; він виводиться з перевірок порт-монітора і може помилятися в обидва боки.

Якщо ви колись думали, чому друк нагадує археологію — ось чому: кілька протоколів, кілька епох і багато «працює в моїй підмережі».

Доведіть як SRE: тести, які відокремлюють мережу, спулер та пристрій

Поводьтеся з принтером як із будь-якою іншою критичною залежністю. Визначте SLI (чи можемо доставити завдання?) і тестуйте точний транспорт.
«Ping працює» — це не SLI. Це настрій.

Одна ідея з культури надійності, парафразована від W. Edwards Deming: без даних ти просто ще одна людина з думкою.
Аварії друку суттєво покращуються, коли ви починаєте збирати правильні дані.

Практичні завдання (команди, виводи, рішення)

Ці завдання припускають, що ви на Windows-машині з PowerShell, та (для мережевих тестів) що у вас є щонайменше один Linux jump host.
Суть не в конкретному інструменті; суть — дисципліна: виконуйте команду, читайте вивід, приймайте рішення.

Завдання 1: Визначити об’єкт принтера та статус через PowerShell

cr0x@server:~$ powershell -NoProfile -Command "Get-Printer | Sort-Object Name | Select-Object -First 5 Name,PrinterStatus,WorkOffline"
Name                         PrinterStatus WorkOffline
----                         ------------ -----------
Accounting-3F-Ricoh          Offline              False
HR-2F-HP-LaserJet            Normal               False
Lobby-Canon-Color            Offline              False
PDFCreator                   Normal               False
Zebra-Shipping               Normal               False

Що це означає: Ви бачите, чи Windows вважає принтер Offline і чи встановлено «WorkOffline».

Рішення: Якщо WorkOffline = True, виправте це спочатку (це клієнтський прапорець). Якщо WorkOffline = False і статус Offline, переходьте до діагностики порту.

Завдання 2: Знайти, який порт використовує принтер

cr0x@server:~$ powershell -NoProfile -Command "Get-Printer -Name 'Accounting-3F-Ricoh' | Select-Object Name,PortName,DriverName"
Name                PortName      DriverName
----                --------      ----------
Accounting-3F-Ricoh 10.20.30.45   Ricoh PCL6 V4 Driver

Що це означає: Принтер прив’язаний до об’єкта порту, часто названого як IP.

Рішення: Запитуйте цей порт далі; виправлення зазвичай там.

Завдання 3: Переглянути конфігурацію порту (SNMP — звичайний підозрюваний)

cr0x@server:~$ powershell -NoProfile -Command "Get-PrinterPort -Name '10.20.30.45' | Format-List *"
Name               : 10.20.30.45
PrinterHostAddress : 10.20.30.45
PortNumber         : 9100
Protocol           : Raw
SNMPEnabled        : True
SNMPCommunity      : public
SNMPDevIndex       : 1

Що це означає: Windows використовує RAW/9100 для друку, але також SNMP для визначення стану.

Рішення: Якщо SNMP блокується/вимкнено/непогоджено, вимкніть його або виправте community/index.

Завдання 4: Вимкнути SNMP-статус на порту (виправлення, що зазвичай працює)

cr0x@server:~$ powershell -NoProfile -Command "Set-PrinterPort -Name '10.20.30.45' -SNMPEnabled $false; Get-PrinterPort -Name '10.20.30.45' | Select Name,SNMPEnabled"
Name         SNMPEnabled
----         -----------
10.20.30.45  False

Що це означає: Ви прибрали SNMP як «сторожа».

Рішення: Перевірте статус принтера знову. Якщо він зміниться на Normal і друк працює — ви підтвердили корінну причину.

Завдання 5: Перевірити, що принтер став онлайн після зміни SNMP

cr0x@server:~$ powershell -NoProfile -Command "Get-Printer -Name 'Accounting-3F-Ricoh' | Select Name,PrinterStatus"
Name                PrinterStatus
----                ------------
Accounting-3F-Ricoh Normal

Що це означає: Windows перестав позначати його як Offline.

Рішення: Надішліть тестову сторінку або невелике завдання. Потім уніфікуйте цю настройку для схожих принтерів.

Завдання 6: Якщо ви маєте тримати SNMP, перевірте доступність UDP/161 з Linux

cr0x@server:~$ nc -vz -u 10.20.30.45 161
Connection to 10.20.30.45 161 port [udp/snmp] succeeded!

Що це означає: Принаймні мережевий шлях до UDP/161 відкритий (зверніть увагу: “succeeded” для UDP не є повною гарантією відповіді).

Рішення: Продовжіть реальним SNMP-запитом.

Завдання 7: Перевірити community та device index через SNMP-запит

cr0x@server:~$ snmpget -v2c -c public 10.20.30.45 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: RICOH MP C4504ex / 1.23 / NIC 1.0

Що це означає: SNMP відповідає з очікуваним community string.

Рішення: Якщо це не вдається (timeout), перевірки стану на основі SNMP теж фейлить. Виправіть SNMP енд-ту-енд або вимкніть SNMP-статус у Windows-порту.

Завдання 8: Протестуйте реальний транспорт друку (TCP/9100) з Linux

cr0x@server:~$ nc -vz 10.20.30.45 9100
Connection to 10.20.30.45 9100 port [tcp/*] succeeded!

Що це означає: Сокет відкривається. Це сильний сигнал, що транспорт доступний.

Рішення: Якщо 9100 заблокований, але SNMP працює, Windows може показувати Online, а завдання падатимуть — інший режим відмови. Виправте фаєрвол/ACL для протоколу друку.

Завдання 9: Підтвердити доступність веб-інтерфейсу пристрою (допомагає виявити зміну IP)

cr0x@server:~$ curl -I http://10.20.30.45/
HTTP/1.1 200 OK
Server: Embedded-Web-Server
Content-Type: text/html

Що це означає: HTTP відповідає, що зменшує ймовірність зовсім неправильної IP-адреси, але не доводить здатність друкувати.

Рішення: Якщо HTTP не відповідає, але ping працює — можливо, внутрішній фаєрвол принтера блокує або адреса невірна. Підтвердіть через DHCP/ARP.

Завдання 10: Перевірити ARP для виявлення конфліктів IP (підступний варіант)

cr0x@server:~$ arp -an | grep 10.20.30.45
? (10.20.30.45) at 00:26:73:aa:bb:cc [ether] on eth0

Що це означає: Ви отримали MAC-адресу для цього IP.

Рішення: Порівняйте її з тією, яку принтер показує на сторінці налаштувань. Якщо не збігається — у вас конфлікт IP або заміна пристрою, і Windows спілкується з невірним обладнанням.

Завдання 11: На Windows перезапустіть Print Spooler і негайно перевірте стан

cr0x@server:~$ powershell -NoProfile -Command "Restart-Service Spooler -Force; Start-Sleep 2; Get-Service Spooler | Select Status,Name"
Status Name
------ ----
Running Spooler

Що це означає: Spooler знову працює. Це очищує деякі застряглі черги та стани моніторів.

Рішення: Якщо Offline змінюється на Normal лише після перезапуску, а потім знову регресує — підозрюйте моніторинг стану (SNMP/WSD) або нестабільний драйвер/порт-монітор.

Завдання 12: Перевірити журнал PrintService Operational на помилки порту/драйвера

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-PrintService/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/4/2026 9:41:02 AM
Id               : 372
LevelDisplayName : Error
Message          : The document Print Document, owned by user DOMAIN\jdoe, failed to print on printer Accounting-3F-Ricoh. Data type: RAW. Size of the spool file: 24576 bytes. Error: The device is not ready.

TimeCreated      : 2/4/2026 9:40:51 AM
Id               : 808
LevelDisplayName : Warning
Message          : Printer Accounting-3F-Ricoh was paused due to a port error.

Що це означає: Ви бачите конкретні відмови: «port error», «device is not ready» та часові мітки.

Рішення: Помилки порту вказують на конфігурацію порту (SNMP/WSD/протокол). «Device not ready» може також вказувати на сон/пробудження прошивки або фізичні стани пристрою.

Завдання 13: Підтвердити, чи використовує принтер WSD (часто проміжний лиходій)

cr0x@server:~$ powershell -NoProfile -Command "Get-PrinterPort | Where-Object { $_.Name -like 'WSD*' } | Select-Object -First 3 Name,PrinterHostAddress,Protocol"
Name                           PrinterHostAddress Protocol
----                           ------------------ --------
WSD-3a4b5c6d-7e8f-9012-3456    10.20.30.45        WSD
WSD-11223344-5566-7788-99aa    10.20.30.88        WSD
WSD-a1b2c3d4-e5f6-7788-9900    10.20.31.12        WSD

Що це означає: Якщо ваш постраждалий принтер використовує порт WSD — ви в царині виявлення.

Рішення: Для бізнес-критичних принтерів надавайте перевагу Standard TCP/IP Port зі статичною IP-адресою (або резервуванням DHCP).

Завдання 14: Створити порт заново чисто (добре для пошкодженого стану монітора порту)

cr0x@server:~$ powershell -NoProfile -Command "Add-PrinterPort -Name 'IP_10.20.30.45' -PrinterHostAddress '10.20.30.45'; Set-Printer -Name 'Accounting-3F-Ricoh' -PortName 'IP_10.20.30.45'; Get-Printer -Name 'Accounting-3F-Ricoh' | Select Name,PortName"
Name                PortName
----                --------
Accounting-3F-Ricoh  IP_10.20.30.45

Що це означає: Ви перемістили принтер на свіжий об’єкт порту.

Рішення: Тепер налаштуйте цей порт явно (протокол, SNMP off або коректно), потім протестуйте. Якщо це вирішує проблему — старий об’єкт порту був неправильно налаштований або застарів.

Завдання 15: Очистити застряглі завдання (лише після збору доказів)

cr0x@server:~$ powershell -NoProfile -Command "Get-PrintJob -PrinterName 'Accounting-3F-Ricoh' | Select-Object -First 3 ID,DocumentName,JobStatus"
ID DocumentName               JobStatus
-- ------------               ---------
19 Quarterly-Budget.xlsx      Error, Offline
20 Benefits-Handbook.pdf      Spooling
21 Invoice-Run-0204.pdf       Printing

cr0x@server:~$ powershell -NoProfile -Command "Get-PrintJob -PrinterName 'Accounting-3F-Ricoh' | Remove-PrintJob"

Що це означає: Ви очищаєте забиту чергу, що може тримати принтер у поганому стані.

Рішення: Якщо завдання одразу стають знову в стані Offline, повертайтесь до діагностики порту і стабільності драйвера замість повторного ритуалу очищення.

Завдання 16: Перевірити ізоляцію драйвера, перемкнувшись на відомий стабільний class driver

cr0x@server:~$ powershell -NoProfile -Command "Get-PrinterDriver | Where-Object { $_.Name -match 'Microsoft|Generic' } | Select-Object -First 5 Name"
Name
----
Microsoft IPP Class Driver
Microsoft PS Class Driver
Microsoft PCL6 Class Driver
Generic / Text Only
Send To OneNote 16 Driver

Що це означає: У вас є альтернативні драйвери.

Рішення: Якщо принтер стає онлайн і друкує з Microsoft class driver, але не з драйвером від виробника — нестабільний компонент саме в драйвері/моніторі виробника. Стандартизуйтесь або фіксуйте версії.

Три корпоративні міні-історії (як це провалюється в реаліях)

1) Інцидент, спричинений хибним припущенням: «Ping означає, що все гаразд»

На фінансовому поверсі був один високопродуктивний MFP, що обробляв все — від рахунків до пакетів відповідності.
Одного ранку він показав «Offline» на половині робочих станцій після вікна змін безпеки.
Команда десктопів робила те, що роблять під тиском: пропінгували принтер, побачили відповіді і вирішили, що мережа ні до чого.
Потім вони перевстановлювали драйвери. Повторювали. Черга зростала. Люди ходили з паперами, наче 1997 рік.

Мережеву команду підключили пізніше. Вони перевірили список змін фаєрволу і знайшли правило, що звужувало UDP egress.
TCP/9100 був дозволений. HTTPS до пристрою дозволений. UDP/161 — ні.
Ось і вся загадка: Standard TCP/IP Port Windows був налаштований з увімкненим SNMP-статусом, використовуючи «public».
SNMP-запит фейлився, Windows оголосив принтер мертвим і відмовлявся відправляти завдання — хоча RAW-друк міг би працювати.

Виправлення було двоетапним: вимкнути перевірки SNMP-статусу на клієнтських портах і налаштувати моніторинг окремо від друку.
Урок не в тому, що «фаєрволи погані». Урок у тому, що не слід використовувати протокол моніторингу як ворота доступності.

Після цього вони додали односторінковий ранбук: якщо ping працює, але друк офлайн — тестуйте 9100 і перевірте SNMP-статус на порту.
Середній час відновлення впав із годин до хвилин, бо команда перестала довіряти хибному сигналу.

2) Оптимізація, що зіграла злий жарт: «Використаємо WSD, це сучасно»

Глобальний офіс стандартизував розгортання на WSD-портах Windows, бо це спрощувало первинне налаштування.
Підключив принтер, дай Windows його знайти, користувачі друкують — немає потреби координувати резервування IP у десятках сайтів.
Декілька місяців здавалося, що все чудово. Потім почалися дивні випадки.

Пристрої показували Offline після оновлення прошивки, потім «магічно» поверталися після перезавантаження.
Деякі принтери залишалися Online, але завдання зникали в порожнечі «Printing…».
В одному офісі принтер самостійно перейменувався в Windows після заміни, що ламало скрипти, які мапили принтери за іменем.
Усунути проблему було складно, бо WSD абстрагує транспорт і виявлення. У вас немає стабільної порту/IP-ідентичності, про яку можна швидко міркувати.

Відкат проблеми почався під час проєкту сегментації мережі.
Мультикаст-трафік виявлення був обмежений між VLANами і надійність WSD впала.
Принтери масово почали показувати Offline залежно від того, в яку підмережу підключався ноутбук.
«Але вчора працювало» було правдою; «воно задумане для цього» — ні.

Остаточне рішення було навмисно нудним: статичні IP (або резервування DHCP), Standard TCP/IP порти, RAW/9100 або IPP залежно від моделі, SNMP статус вимкнений, якщо це не потрібно та не підтверджено.
Вони й досі використовували виявлення — але лише для інвентаризації, не для продуктивного друку.

3) Нудна, але правильна практика, яка врятувала ситуацію: «Фіксуй відому-робочу базу»

В середній компанії з центральним сервером друку парк містив мікс вендорів і років випуску.
Команда підтримувала просту базу: кожна черга мала задокументовану IP, протокол порту і версію драйвера, що була протестована.
SNMP-статус був вимкнений, якщо пристрій не знаходився у контрольованій підмережі з підтвердженим доступом SNMP і нестандартним community string.
Вони також тримали ввімкненим журнал PrintService Operational і форвардили ключові події.

Одного четверга оновлення драйвера від вендора було запущено як частина «рутинних покращень».
За годину декілька черг почали показувати Offline періодично, а процес спулера на сервері показував короткі сплески CPU.
Служба підтримки побачила «Offline» і готувалась до звичного хаосу.
Але команда мала базу та план відкату.

Вони порівняли налаштування порту на ураженій черзі з базою і виявили, що оновлення перейменувало SNMP-статус на ввімкнений.
Також воно змінило SNMP device index на деяких портах — на папері безпечне, в продакшні фатальне.
Вони відкотили пакет драйверів, поновили шаблон порту з бази, і інцидент завершився до того, як більшість користувачів помітили.

Ніхто не аплодує команді за те, що працює зі спреедом і нудним чеклістом.
З іншого боку, під час збою ніхто теж не аплодує — лише дивляться з докорами.

Жарт №2: Аварія принтера — єдиний інцидент, під час якого всі раптом стають експертами у «critical path».

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Offline», але ping працює

• Корінна причина: Перевірка стану SNMP не проходить; порт-монітор Windows позначає принтер як Offline.
• Виправлення: Вимкніть SNMP Status Enabled на Standard TCP/IP порту або відновіть SNMP (дозвольте UDP/161, правильний community, коректний device index).

2) Симптом: Принтер показує Online, завдання зависають у «Printing…»

• Корінна причина: TCP/9100 заблокований, пристрій застряг, або неправильний протокол (RAW vs LPR) порівняно з очікуванням пристрою.
• Виправлення: Перевірте TCP-зв’язок до порту (9100/515/631). Узгодьте порт Windows з конфігурацією пристрою. Перегляньте журнал завдань на пристрої.

3) Симптом: Принтер переходить в Offline після сну, потім повертається після перезавантаження

• Корінна причина: Прошивка у сплячому режимі вимикає SNMP або затримує відповіді; моніторинг таймаутить і позначає Offline.
• Виправлення: Вимкнути SNMP-статус, збільшити таймаути (де підтримується) або налаштувати параметри сну пристрою для керованих принтерів.

4) Симптом: Лише деякі користувачі бачать Offline; інші друкують нормально

• Корінна причина: Різні порти/протоколи на клієнтах, змішані WSD vs TCP/IP, або відмінності ACL по підмережах.
• Виправлення: Стандартизувати розгортання через сервер друку, видалити WSD-порти і застосувати один шаблон порту на модель/сайт.

5) Симптом: Offline з’явився після оновлення драйвера

• Корінна причина: Встановник драйвера скинув налаштування порту, знову ввімкнув SNMP-моніторинг або перемістив на інший стек моніторингу.
• Виправлення: Порівняйте налаштування порту до і після. Поновіть шаблон (SNMP off за замовчуванням). Фіксуйте версії драйверів.

6) Симптом: IP принтера в документації правильний, але Windows все одно «Offline»

• Корінна причина: Конфлікт IP, заміна пристрою або переназначення DHCP без резервації.
• Виправлення: Підтвердіть MAC через ARP, перевірте сторінку конфігурації принтера і переведіть на резервацію DHCP або статичну IP з контролем змін.

7) Симптом: Перезапуск спулера «вирішує» проблему на трохи

• Корінна причина: Флапінг стану порту, корупція черги або нестабільність драйвера, яку тимчасово очищає перезапуск.
• Виправлення: Усуньте первинну проблему: моніторинг порту (SNMP/WSD), версію драйвера або створіть порт/чергу заново.

8) Симптом: Сервер друку показує Offline, але прямий IP-друк з робочої станції працює

• Корінна причина: Субмережа сервера не може дістатися до SNMP або налаштований протокол друку, або налаштування порту на сервері відрізняються.
• Виправлення: Тестуйте безпосередньо з сервера. Узгодьте налаштування портів сервера. Не думайте, що підключення робочої станції означає те саме для сервера.

Чеклісти / покроковий план

Чекліст A: Швидко виправити одну робочу станцію (тактичний)

1. Отримайте ім’я принтера так, як Windows його бачить (PowerShell Get-Printer).
2. Перевірте стан Work Offline:
   • Якщо WorkOffline=True, встановіть його в false (через UI або політику) і повторно протестуйте.
3. Знайдіть ім’я порту (Get-Printer -Name ... | Select PortName).
4. Перегляньте налаштування порту (Get-PrinterPort):
   • Якщо SNMPEnabled=True, вимкніть його як діагностику.
5. Перевірте статус і надрукуйте тестову сторінку.
6. Якщо все ще Offline:
   • Підтвердіть доступність протоколу друку (TCP/9100 або інші) з мережі робочої станції.
   • Створіть порт заново і прив’яжіть принтер до нього.
7. Якщо спулер завис:
   • Збережіть журнали PrintService, потім перезапустіть спулер один раз.
8. Якщо це специфічно для драйвера:
   • Перевірте з Microsoft PS/PCL class driver, щоб ізолювати проблему з драйвером виробника.

Чекліст B: Виправити парк (стратегічно, щоб уникнути повторів)

1. Визначте стандарт транспорту друку для кожного класу пристроїв:
   • RAW/9100 простий і широко підтримуваний.
   • IPP може бути відмінним у сучасних середовищах, але стандартизуйте його навмисно.
   • Уникайте WSD для критичних у спільному доступі черг, якщо ви не можете гарантувати поведінку multicast.
2. Призначте стабільні ідентичності:
   • Використовуйте резервування DHCP або статичні IP з контролем змін.
   • Підтримуйте консистентні DNS-записи, якщо друкуєте за іменем.
3. Відокремте моніторинг від друку:
   • Якщо потрібен SNMP для телеметрії парку, робіть це з підмережі/інструменту моніторингу з відомою SNMP-конфігурацією.
   • Не дозволяйте SNMP вирішувати, чи буде Windows намагатися друкувати.
4. Базуйте конфігурацію портів:
   • SNMP-статус вимкнений за замовчуванням.
   • Якщо увімкнено: нестандартний community, перевірені ACL і задокументована поведінка device index.
5. Фіксуйте версії драйверів:
   • Тестуйте оновлення у пілотній OU перш ніж розгортати.
   • Документуйте кроки для відкату.
6. Централізуйте через сервер друку (коли доречно):
   • Один набір портів для управління.
   • Послідовний розподіл драйверів.
   • Кращі журнали та контроль.
7. Увімкніть і використовуйте логи:
   • Тримайте увімкненим PrintService Operational log.
   • Визначте, які помилки є дієвими, і маршрутизовуйте їх відповідній команді.
8. Задокументуйте ранбук «Offline»:
   • Що перевіряти першим (налаштування порту) і на що не витрачати час (друк перевстановлення драйвера як рефлекс).

Чекліст C: Коли залучена політика безпеки (передбачуваний конфлікт)

1. Підтвердіть необхідні порти для кожного методу друку (не вгадуйте).
2. Якщо SNMP заблокований, проактивно вимкніть SNMP-статус на всіх Standard TCP/IP портах, що використовуються для друку.
3. Якщо SNMP має бути дозволений, визначте область: дозволяйте UDP/161 лише з серверів друку до принтерів, а не з усіх робочих станцій.
4. Після змін у фаєрволі, перевіряйте реальним завданням друку та тестом протоколу (9100/515/631), а не лише ping.

FAQ

1) Чому вимкнення SNMP миттєво переводить принтер в «Online»?

Тому що Windows перестає використовувати відповіді SNMP як доказ життя для цього порту.
Якщо друк через TCP/9100 працює, Windows може знову відправляти завдання без очікування успішного UDP/161.

2) Чи втрачу я інформацію про тонер і статус лотків, якщо вимкну SNMP-статус?

Часто — так, принаймні у Windows UI.
Це компроміс: багатший статус проти надійної доставки завдань. Для більшості продуктивних середовищ надійність важливіша.
Використовуйте спеціалізований інструмент моніторингу для телеметрії через SNMP замість того, щоб покладатися на неї в UI десктопів.

3) Чи є «SNMP Status Enabled» налаштуванням драйвера чи Windows?

Це налаштування порту на об’єкті Standard TCP/IP Port у Windows.
Драйвери та інсталятори можуть його змінювати (іноді «на благо»), саме тому воно з’являється після оновлень.

4) Що з SNMP v3?

Деякі середовища використовують SNMP v3 для безпеки, але базова поведінка моніторингу порту Windows залишається тією самою концептуально: він очікує відповіді SNMP.
Якщо v3 не налаштовано повністю (пристрій, ACL, облікові дані), ви й надалі отримаєте симптоми Offline.

5) Чому це відбувається лише на ноутбуках або коли користувачі переміщуються?

Бо різні мережі мають різні ACL. Одна VLAN може дозволяти UDP/161; інша — ні.
Або мультикаст, потрібний для WSD, працює в одному місці, але не в іншому. Стандартизуйте порти і уникайте виявлення-залежного друку для користувачів у русі.

6) Що краще використовувати: RAW (9100) чи IPP?

RAW простий і повсюдний. IPP може бути відмінним і сучаснішим, особливо з новими пристроями і драйверами.
Виберіть один варіант на клас пристрою і підтримуйте його навмисно. Справжній ворог — це «змішані випадкові налаштування».

7) Чому перевстановлення принтера іноді «виправляє» Offline?

Перевстановлення часто створює об’єкт порту заново, скидає таймаути або перемикає поведінку моніторингу.
Це не вирішення проблеми; це рулетка, яка іноді потрапляє на кращу конфігурацію.
Вам потрібна справжня корінна причина: SNMP-ворота, крихкість WSD або проблема з драйвером.

8) Чи може принтер бути Online у Windows, але все одно не друкувати?

Абсолютно. «Online» може базуватися на SNMP, але друк може не працювати через блокування TCP/9100, помилки рендерингу драйвера, автентифікацію або затримки на пристрої.
Завжди тестуйте реальний транспорт друку і перевіряйте журнали PrintService.

9) Чи гірше ця проблема на серверах друку?

Може бути. Сервери друку централізують залежність: одна конфігурація порту впливає на багатьох користувачів.
Саме тому виправлення на сервері потужне — стандартизувавши налаштування портів один раз, ви позбавляєте багатьох користувачів проблем.

10) Яка найкраща превентивна міра?

Стандартизувати порти: Standard TCP/IP Port зі стабільною IP-адресою, відомим протоколом і SNMP-статусом вимкненим, якщо ви не довели надійність SNMP на шляху.

Висновок: наступні кроки для стандартизації

Принтер, який «Офлайн» назавжди, зазвичай не зламаний. Windows просто переконаний, що він такий, бо порт-монітор не отримав відповіді на SNMP.
Це не мережевий детектив; це конфігураційна помилка з дуже гострим краєм.

Практичні наступні кроки:

1. Для поточного інциденту: Перевірте порт принтера. Якщо SNMP-статус увімкнено — вимкніть і перевірте статус знову.
2. Для наступного інциденту: Додайте протокольні тести у ранбук: TCP/9100 (або 515/631) і SNMP лише коли релевантно.
3. Для довготривалої стабільності: Стандартизуйте стабільні IP/порти, уникайте WSD для критичних черг, фіксуйте версії драйверів і відокремлюйте телеметрію (SNMP) від доставки завдань.

Друк ніколи не буде гламурним. Але він може бути передбачуваним, а передбачуваність — це головна мета операцій.