Impresora “Desconectada” para siempre: la configuración del controlador de Windows que la rompe

La configuración del controlador que lo rompe: estado SNMP en el puerto

En Windows, una impresora de red suele representarse mediante un Puerto TCP/IP estándar.
Ese puerto no es sólo “una dirección IP.” También contiene una configuración de monitorización: protocolos, tiempos de espera y—críticamente—consultas de estado SNMP.

Cuando Estado SNMP habilitado está activado, Windows consulta periódicamente al dispositivo para decidir si está “online”.
Si esa consulta falla (string de comunidad incorrecto, SNMP deshabilitado en la impresora, SNMP bloqueado por el cortafuegos, dispositivo en modo reposo sin respuesta SNMP, o ACL de VLAN que permiten 9100 pero bloquean UDP/161), Windows puede marcar la impresora como Desconectada.
Imprimir podría seguir funcionando a nivel de protocolo, pero Windows ni siquiera lo intentará porque cree que el destino no está disponible.

Por eso verás el clásico “puedo hacer ping, puedo abrir la página web, pero Windows muestra desconectada.” Ping es ICMP.
La UI web de la impresora es TCP/80 o TCP/443. La impresión suele ser TCP/9100 (RAW), TCP/515 (LPD) o IPP.
SNMP es UDP/161. Diferente protocolo, diferentes ACL, diferentes modos de fallo.

El patrón específico de fallo

• La ruta de red está bien (ICMP y HTTPS funcionan).
• La impresora está bien (imprime desde otras máquinas o imprime la página de prueba desde el panel frontal).
• Windows dice Desconectada porque la comprobación de estado del monitor de puerto falla.
• Desactivar el estado SNMP en ese puerto hace que la impresora aparezca Online inmediatamente y los trabajos fluyan de nuevo.

Qué hacer, sin rodeos

Si tu entorno no soporta SNMP de forma fiable (y muchos no lo hacen), desactiva el estado SNMP para los puertos de impresión de usuarios finales.
Aún puedes ejecutar monitorización de flota con un sistema de monitorización dedicado y una configuración SNMP fiable.
Mezclar “ayudar a la UI a mostrar niveles de tóner” con “bloquear toda la impresión” es una elección de diseño, y no es buena.

Broma #1: Las impresoras no tienen modos “offline”. Tienen modos “te castigo por creer en casillas” .

Qué significa realmente “Desconectada” en Windows (y qué no)

El estado “Desconectada” de Windows no es una verdad universal. Es la opinión del subsistema de impresión, basada en las señales que está configurado para confiar.
Esa opinión puede estar equivocada.

Las capas implicadas

• Aplicación: envía un trabajo al spooler local usando las API de impresión Win32.
• Spooler: encola, renderiza y entrega el trabajo a un monitor de puerto.
• Monitor de puerto: implementa el transporte (Puerto TCP/IP estándar, WSD, LPR, IPP, etc.).
• Transporte: paquetes en la red (TCP/9100, UDP/161 para SNMP, etc.).
• Dispositivo: firmware de la impresora, estados de reposo, accesorios y una sorprendente cantidad de personalidad.

“Desconectada” puede provenir de:

• El monitor de puerto piensa que el dispositivo es inalcanzable (consulta de estado fallida).
• El servicio Spooler está poco saludable o atascado.
• El controlador está provocando que el proceso del spooler falle o no pueda renderizar.
• La impresora está en una IP diferente a la que el puerto cree (DHCP cambió, DNS obsoleto).
• Una directiva o configuración del registro fuerza el comportamiento “Work Offline”.

Dos estados que no debes confundir

• Desconectada (dispositivo inalcanzable): Windows no enviará trabajos.
• Error / Atención requerida: Windows puede enviar trabajos; el dispositivo puede retenerlos.

La solución depende de qué capa está mintiendo. Tu trabajo es descubrir al mentiroso rápidamente.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando una impresora está “Desconectada” y los usuarios caminan en círculos como si fuera un simulacro de incendio, no necesitas una filosofía de impresión.
Necesitas un cribado rápido: red, dispositivo, monitorización de puerto de Windows o spooler/controlador.

Primero: valida lo básico con el protocolo correcto

1. Confirma la dirección IP que Windows está apuntando (propiedades de la impresora → Puertos, o vía PowerShell).
2. Prueba TCP/9100 (o el protocolo configurado) desde el cliente o el servidor de impresión.
3. Prueba SNMP/161 sólo si el estado SNMP está habilitado; si no, ignóralo.

Segundo: revisa el motor de opinión de Windows

1. Mira la configuración del Puerto TCP/IP estándar: ¿está activado el estado SNMP? ¿string de comunidad? ¿índice de dispositivo correcto?
2. Confirma que no estás usando WSD a menos que disfrutes del drama de descubrimiento intermitente.
3. Reinicia el servicio de Cola de Impresión (Print Spooler) sólo después de haber capturado suficiente evidencia (estado de la cola, errores).

Tercero: aislar fallos de controlador/spooler

1. Prueba un controlador de clase Microsoft (PCL / PS genérico) para demostrar fallos específicos del controlador.
2. Revisa los registros de PrintService en busca de caídas, tiempos de espera o errores de puerto.
3. Mueve la impresora a un nuevo puerto (misma IP, puerto nuevo) para limpiar un estado de monitor de puerto corrupto.

Este guion está sesgado hacia la velocidad y la certeza. Tu objetivo no es “probar cosas”.
Tu objetivo es tomar una decisión a la vez basada en pruebas.

Hechos e historia que explican el desastre actual

La impresión es uno de esos dominios informáticos donde la promesa de compatibilidad de ayer es la caída de hoy.
Algunos hechos concretos ayudan a explicar por qué una sola casilla puede descarrilar un martes.

1. SNMP (Simple Network Management Protocol) data de finales de los años 80 y fue diseñado para monitorización ligera de dispositivos, no como una puerta de disponibilidad para la entrega de trabajos.
2. La impresión RAW al estilo JetDirect en TCP/9100 se hizo común en los 90 porque era simple y rápida: abrir un socket TCP, enviar bytes, cerrar.
3. LPR/LPD (TCP/515) es aún más antiguo, heredado de tradiciones UNIX, y se comporta de forma diferente ante fallos (semántica de cola, opciones de banner).
4. Windows introdujo WSD (Web Services for Devices) para facilitar el descubrimiento. En la práctica, WSD puede ser frágil entre subredes, estados de reposo y restricciones multicast.
5. Los fabricantes de impresoras distribuyen “monitores de estado” que dependen de SNMP porque es así como obtienes niveles de tóner, estado de bandejas y atascos—hasta que un equipo de seguridad bloquea UDP/161.
6. SNMP v1/v2c usa strings de comunidad que son efectivamente contraseñas compartidas; muchas organizaciones desactivan SNMP o lo restringen, rompiendo la suposición por defecto “public”.
7. Los baselines modernos de endurecimiento cada vez más bloquean UDP entrante y saliente por defecto, y SNMP suele ser daño colateral incluso cuando los puertos de impresión están permitidos.
8. Los modos de reposo de las impresoras pueden apagar selectivamente servicios; algunos dispositivos mantienen TCP/9100 vivo pero dejan de responder SNMP hasta que se reactivan por completo.
9. El estado “Desconectada” de Windows no es una verdad de red estandarizada; se deriva de comprobaciones del monitor de puerto y puede estar equivocado en ambos sentidos.

Si alguna vez te has preguntado por qué la impresión se siente como arqueología, por eso: múltiples protocolos, múltiples eras y mucho “funciona en mi subred”.

Pruébalo como un SRE: pruebas que separan red, spooler y dispositivo

Trata la impresora como cualquier otra dependencia de producción. Define el SLI (¿podemos entregar un trabajo?) y prueba el transporte exacto.
“Ping funciona” no es un SLI. Es un estado de ánimo.

Una idea de fiabilidad parafraseada que puedes tomar de la cultura de ingeniería, a menudo atribuida a W. Edwards Deming: parafraseando la idea: sin datos, sólo eres otra persona con una opinión.
Los fallos de impresión mejoran drásticamente una vez que comienzas a recopilar los datos correctos.

Tareas prácticas (comandos, salidas, decisiones)

Estas tareas asumen que estás en una máquina Windows con PowerShell y (para pruebas de red) que tienes al menos un host Linux de salto.
El punto no es la herramienta exacta; es la disciplina: ejecutar un comando, leer la salida, decidir el siguiente paso.

Tarea 1: Identificar el objeto impresora y el estado desde 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

Qué significa: Puedes ver si Windows lo considera Desconectada y si “WorkOffline” está activado.

Decisión: Si WorkOffline es True, corrígelo primero (es una bandera del lado cliente). Si es False y el estado es Desconectada, pasa al diagnóstico del puerto.

Tarea 2: Encontrar qué puerto usa la impresora

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

Qué significa: La impresora está ligada a un objeto puerto, a menudo nombrado como la IP.

Decisión: Consulta ese puerto a continuación; la solución suele estar ahí.

Tarea 3: Inspeccionar la configuración del puerto (SNMP es el sospechoso habitual)

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

Qué significa: Windows está usando RAW/9100 para imprimir pero también SNMP para decidir el estado.

Decisión: Si SNMP está bloqueado/deshabilitado/desajustado, desactívalo o corrige la comunidad/índice.

Tarea 4: Desactivar el estado SNMP en el puerto (la solución que realmente arregla)

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

Qué significa: Has eliminado a SNMP como guardián.

Decisión: Vuelve a comprobar el estado de la impresora. Si cambia a Normal y la impresión funciona, has confirmado la causa raíz.

Tarea 5: Verificar que la impresora quede en línea tras el cambio SNMP

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

Qué significa: Windows ha dejado de marcarla como Desconectada.

Decisión: Imprime una página de prueba o envía un trabajo pequeño. Luego estandariza esta configuración para impresoras similares.

Tarea 6: Si debes mantener SNMP, prueba la accesibilidad UDP/161 desde Linux

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

Qué significa: Al menos la ruta de red a UDP/161 está abierta (nota: el “succeeded” en UDP no prueba una respuesta completa).

Decisión: Sigue con una consulta SNMP real.

Tarea 7: Validar comunidad SNMP e índice de dispositivo con una consulta 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

Qué significa: SNMP responde usando la comunidad esperada.

Decisión: Si esto falla (timeout), las comprobaciones de estado basadas en SNMP también fallarán. O arregla SNMP de extremo a extremo o desactiva el estado SNMP en el puerto de Windows.

Tarea 8: Probar el transporte real de impresión (TCP/9100) desde Linux

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

Qué significa: El socket se abre. Es una señal fuerte de que el transporte es accesible.

Decisión: Si 9100 está bloqueado pero SNMP funciona, Windows podría seguir mostrando Online mientras los trabajos fallan—modo de fallo distinto. Arregla el firewall/ACL para el protocolo de impresión.

Tarea 9: Confirmar que la UI web del dispositivo sea accesible (ayuda a detectar cambios de IP)

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

Qué significa: HTTP responde, lo que reduce las probabilidades de una IP totalmente equivocada, pero no prueba la impresión.

Decisión: Si HTTP falla pero el ping funciona, puede haber un cortafuegos de impresora o la dirección equivocada. Confirma vía DHCP/ARP.

Tarea 10: Revisar ARP para detectar conflictos de IP (los sigilosos)

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

Qué significa: Tienes una dirección MAC para esa IP.

Decisión: Compárala con la que informa la impresora en su página de configuración. Si no coincide, tienes un conflicto de IP o un intercambio de dispositivo, y Windows está hablando con lo equivocado.

Tarea 11: En Windows, reinicia el Print Spooler y vuelve a comprobar el estado inmediatamente

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

Qué significa: El Spooler vuelve a estar en ejecución. Esto limpia algunas colas atascadas y el estado del monitor.

Decisión: Si Desconectada cambia a Normal sólo después del reinicio y luego regresa, sospecha de monitorización de estado (SNMP/WSD) o de un controlador/monitor de puerto inestable.

Tarea 12: Revisar el registro operativo PrintService en busca de errores de puerto/controlador

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.

Qué significa: Estás viendo fallos concretos: “error de puerto”, “dispositivo no listo” y tiempos.

Decisión: Los errores de puerto te empujan hacia la configuración del puerto (SNMP/WSD/protocolo). “Dispositivo no listo” aún puede ser bloqueo por SNMP, pero también apunta a firmware, estados de reposo o estados físicos del dispositivo.

Tarea 13: Confirmar si la impresora usa WSD (a menudo la villana intermitente)

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

Qué significa: Si tu impresora afectada usa un puerto WSD, estás en tierra de descubrimiento.

Decisión: Prefiere un Puerto TCP/IP estándar con IP estática (o reserva DHCP) para impresoras críticas para el negocio.

Tarea 14: Recrear el puerto limpiamente (útil para estado corrupto del monitor de puerto)

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

Qué significa: Has movido la impresora a un objeto puerto nuevo.

Decisión: Ahora configura ese puerto explícitamente (protocolo, SNMP desactivado o correcto), luego vuelve a probar. Si esto lo arregla, el puerto antiguo estaba mal configurado o era obsoleto.

Tarea 15: Vaciar trabajos atascados (sólo después de haber registrado evidencia)

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"

Qué significa: Estás limpiando una cola atascada que puede mantener la impresora en mal estado.

Decisión: Si los trabajos se vuelven a atascar inmediatamente con Desconectada, vuelve a la monitorización de puerto y la estabilidad del controlador en lugar de repetir el ritual de purga.

Tarea 16: Validar aislamiento del controlador cambiando a un controlador de clase conocido y estable

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

Qué significa: Tienes controladores alternativos disponibles.

Decisión: Si la impresora queda en línea y imprime con un controlador de clase Microsoft pero no con el controlador del proveedor, el monitor/controlador del proveedor es tu inestabilidad. Estandariza o fija versiones.

Tres microhistorias corporativas (cómo falla esto en la realidad)

1) El incidente causado por una suposición errónea: “Hacer ping significa que está bien”

Un piso de finanzas tenía un único MFP de alto volumen que procesaba todo, desde facturas hasta paquetes de cumplimiento.
Una mañana pasó a “Desconectada” en la mitad de los escritorios tras una ventana de cambios de seguridad.
El equipo de escritorio hizo lo que los equipos de escritorio hacen bajo presión: hicieron ping a la impresora, vieron respuestas y concluyeron que la red era inocente.
Entonces reinstalaron controladores. Repetidamente. La cola creció. La gente empezó a pasear papeles como si fuera 1997.

El equipo de red fue llamado tarde. Revisaron la lista de cambios de firewall y encontraron una regla que endurecía el egress UDP.
TCP/9100 estaba permitido. HTTPS al dispositivo estaba permitido. UDP/161 no.
Ese fue todo el misterio: el Puerto TCP/IP estándar de Windows estaba configurado con estado SNMP habilitado, usando “public”.
La sonda SNMP falló, Windows declaró la impresora muerta y se negó a enviar trabajos—aunque la impresión RAW habría funcionado.

La solución fue doble: desactivar las comprobaciones de estado SNMP en los puertos del lado cliente y configurar la monitorización separada de la impresión.
La lección no fue “los firewalls son malos.” La lección fue “no uses un protocolo de monitorización como puerta de disponibilidad.”

Después, añadieron un runbook de una página: si el ping funciona pero la impresión está desconectada, prueba 9100 y revisa el estado SNMP en el puerto.
El tiempo medio de reparación bajó de horas a minutos porque el equipo dejó de confiar en la señal equivocada.

2) La optimización que salió mal: “Usemos WSD, es moderno”

Un despliegue global de oficinas estandarizó en puertos WSD de Windows porque facilitaba el despliegue inicial.
Conectar una impresora, dejar que Windows la descubriera, los usuarios podían imprimir—no había que coordinar reservas de IP en docenas de sitios.
Durante unos meses fue una victoria. Luego empezaron las pequeñas rarezas.

Los dispositivos mostraban Desconectada tras una actualización de firmware y luego “mágicamente” volvían tras un reinicio.
Algunas impresoras permanecían Online pero los trabajos desaparecían en un purgatorio de “Imprimiendo…”.
En una oficina, una impresora se renombró en Windows tras ser sustituida, rompiendo scripts que mapeaban impresoras por nombre.
La resolución de problemas fue difícil porque WSD abstrae el transporte y el descubrimiento. No tienes una identidad estable puerto/IP sobre la que razonar rápidamente.

El problema llegó durante un proyecto de segmentación de red.
El tráfico de descubrimiento multicast se vio limitado entre VLANs y el descubrimiento WSD perdió fiabilidad.
Las impresoras aparecían Desconectadas en oleadas dependiendo de en qué subred anduviera el portátil.
“Pero ayer funcionaba” era cierto; “está diseñado para esto” no lo era.

La solución eventual fue deliberadamente aburrida: IPs estáticas (o reservas DHCP), Puertos TCP/IP estándar, RAW/9100 o IPP dependiendo del modelo, estado SNMP desactivado a menos que fuera explícitamente necesario y compatible.
Aún usaron descubrimiento—pero sólo para inventario inicial, no para impresión en producción.

3) La práctica aburrida pero correcta que salvó el día: “Fijar la línea base conocida buena”

En una empresa mediana con un servidor de impresión central, la flota era mixta de fabricantes y años modelo.
El equipo mantenía una línea base simple: cada cola de impresora tenía una IP documentada, protocolo de puerto y una versión de controlador probada.
El estado SNMP estaba desactivado salvo si el dispositivo estaba en una subred controlada con acceso SNMP confirmado y String de comunidad no predeterminado.
También mantenían el registro operativo PrintService habilitado y reenviaban eventos clave.

Un jueves, se desplegó una actualización de controlador del proveedor como parte de “mejoras rutinarias.”
En una hora, varias colas empezaron a mostrar Desconectada intermitentemente y el proceso spooler en el servidor mostró picos breves de CPU.
El help desk vio “Desconectada” y se preparó para el caos habitual.
Pero el equipo tenía la línea base y un plan de reversión.

Compararon las configuraciones de puerto en una cola afectada con la línea base y encontraron que la actualización había vuelto a activar las comprobaciones de estado SNMP.
También cambió el índice de dispositivo SNMP en algunos puertos—inofensivo en papel, fatal en producción.
Revirtieron el paquete de controladores, reaplicaron la plantilla de puerto de la línea base y el incidente terminó antes de que la mayoría de usuarios se dieran cuenta.

Nadie aplaude a un equipo por tener una hoja de cálculo y una lista de verificación aburrida.
Por otro lado, nadie aplaude durante una caída de impresión tampoco—sólo fulminan con la mirada.

Broma #2: Un fallo de impresora es el único incidente donde todo el mundo de repente se convierte en experto en “la ruta crítica.”

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Desconectada” pero el ping funciona

• Causa raíz: La comprobación de estado SNMP falla; el monitor de puerto de Windows marca la impresora como Desconectada.
• Solución: Desactiva Estado SNMP habilitado en el Puerto TCP/IP estándar, o repara SNMP (UDP/161 permitido, comunidad correcta, índice de dispositivo correcto).

2) Síntoma: La impresora muestra Online, los trabajos se quedan en “Imprimiendo…”

• Causa raíz: TCP/9100 bloqueado, dispositivo atascado, o protocolo incorrecto (RAW vs LPR) respecto a lo que el dispositivo espera.
• Solución: Prueba la conectividad TCP al puerto (9100/515/631). Alinea el protocolo del puerto de Windows con la configuración del dispositivo. Revisa el registro de trabajos del dispositivo.

3) Síntoma: La impresora pasa a Desconectada tras el reposo y vuelve tras reiniciar

• Causa raíz: El firmware en reposo apaga SNMP o retrasa respuestas; la monitorización agota el tiempo y marca Desconectada.
• Solución: Desactiva el estado SNMP, aumenta tiempos de espera (donde sea soportado) o ajusta la configuración de reposo para impresoras gestionadas.

4) Síntoma: Sólo algunos usuarios ven Desconectada; otros imprimen bien

• Causa raíz: Diferentes puertos/protocolos por cliente, mezcla WSD vs TCP/IP, o diferencias de ACL por subred.
• Solución: Estandariza el despliegue vía servidor de impresión, elimina puertos WSD y aplica una plantilla de puerto única por modelo/sitio.

5) Síntoma: Desconectada empezó tras una actualización de controlador

• Causa raíz: El instalador/controlador restableció la configuración del puerto, reactivó la monitorización SNMP o cambió el stack del monitor.
• Solución: Compara configuraciones de puerto antes/después. Reaplica la línea base (SNMP desactivado salvo requisito). Fija versiones de controladores.

6) Síntoma: La IP de la impresora es correcta en la documentación, pero Windows sigue “Desconectada”

• Causa raíz: Conflicto de IP, intercambio de dispositivo o reasignación DHCP sin reserva.
• Solución: Valida la MAC vía ARP, confirma la página de configuración de la impresora y pasa a reserva DHCP o IP estática con control de cambios.

7) Síntoma: Reiniciar el spooler “lo arregla” un rato

• Causa raíz: Estado del monitor de puerto fluctuante, corrupción de cola o inestabilidad del controlador que el reinicio limpia temporalmente.
• Solución: Arregla la causa raíz: monitorización de puerto (SNMP/WSD), versión de controlador, o recrea el puerto/cola limpiamente.

8) Síntoma: El servidor de impresión muestra Desconectada, pero la impresión directa por IP desde un puesto funciona

• Causa raíz: La subred del servidor no puede alcanzar SNMP o el protocolo de impresión configurado, o la configuración de puerto del servidor difiere.
• Solución: Prueba desde el servidor específicamente. Alinea la configuración de puertos del servidor. No supongas que la conectividad del puesto equivale a la del servidor.

Listas de verificación / plan paso a paso

Lista A: Arreglar rápidamente una sola estación (táctico)

1. Obtén el nombre de la impresora como la ve Windows (PowerShell Get-Printer).
2. Revisa el estado Work Offline:
   • Si WorkOffline=True, ponlo en false (UI o policy) y vuelve a probar.
3. Encuentra el nombre del puerto (Get-Printer -Name ... | Select PortName).
4. Inspecciona la configuración del puerto (Get-PrinterPort):
   • Si SNMPEnabled=True, desactívalo como diagnóstico.
5. Vuelve a comprobar el estado e imprime una página de prueba.
6. Si sigue Desconectada:
   • Confirma la conectividad con el protocolo de impresión (TCP/9100 u otros) desde la red del puesto.
   • Recrea el puerto y vuelve a enlazar la impresora a él.
7. Si el spooler está atascado:
   • Captura los registros PrintService y luego reinicia el spooler una vez.
8. Si es específico del controlador:
   • Prueba con controladores Microsoft PS/PCL para aislar problemas del proveedor.

Lista B: Arreglar la flota (estratégico, para evitar repeticiones)

1. Decide tu estándar de transporte de impresión por clase de modelo:
   • RAW/9100 es simple y está muy soportado.
   • IPP puede ser excelente en entornos modernos, pero estandarízalo intencionalmente.
   • Evita WSD para colas compartidas críticas salvo que puedas garantizar el comportamiento multicast de descubrimiento.
2. Asigna identidades estables:
   • Usa reservas DHCP o IP estáticas con control de cambios.
   • Mantén registros DNS consistentes si imprimes por nombre.
3. Separa monitorización de impresión:
   • Si necesitas SNMP para telemetría de flota, hazlo desde una subred/herramienta de monitorización con configuración SNMP conocida y fiable.
   • No dejes que SNMP decida si Windows siquiera intentará imprimir.
4. Configura una línea base de puertos:
   • Estado SNMP desactivado por defecto.
   • Si está activado: comunidad no predeterminada, ACL validadas, comportamiento de índice documentado.
5. Fija versiones de controladores:
   • Prueba actualizaciones en una OU piloto primero.
   • Documenta pasos de reversión.
6. Centraliza vía servidor de impresión (cuando corresponda):
   • Un conjunto de puertos para gestionar.
   • Distribución de controladores consistente.
   • Mejores registros y control.
7. Habilita y usa registros:
   • Mantén habilitado el registro operativo PrintService.
   • Decide qué errores son accionables y enrútalos al equipo correcto.
8. Documenta el runbook de “Desconectada”:
   • Qué revisar primero (configuración de puerto) y en qué no perder tiempo (reinstalar controladores por reflejo).

Lista C: Cuando hay endurecimiento de seguridad involucrado (la colisión predecible)

1. Confirma los puertos requeridos por método de impresión (no adivines).
2. Si SNMP está bloqueado, desactiva proactivamente el estado SNMP en todos los Puertos TCP/IP estándar usados para impresión.
3. Si SNMP debe permitirse, define el alcance: permite UDP/161 sólo desde el/los servidor(es) de impresión hacia las impresoras, no desde todos los puestos.
4. Tras cambios de firewall, valida con un trabajo real de impresión y una prueba de protocolo (9100/515/631), no sólo con ping.

Preguntas frecuentes

1) ¿Por qué desactivar SNMP hace que la impresora aparezca “Online” al instante?

Porque Windows deja de usar las respuestas SNMP como señal de vida para ese puerto.
Si imprimir por TCP/9100 va bien, Windows puede enviar trabajos de nuevo sin esperar éxito en UDP/161.

2) ¿Perderé niveles de tóner y estado de bandejas si desactivo el estado SNMP?

A menudo, sí—al menos en la UI de Windows.
Es un intercambio: estado más rico frente a entrega de trabajos fiable. Para la mayoría de entornos de producción, la fiabilidad gana.
Usa una herramienta de monitorización adecuada para la telemetría basada en SNMP en lugar de depender de ella para la impresión de escritorio.

3) ¿“Estado SNMP habilitado” es una configuración del controlador o de Windows?

Es una configuración de puerto en el objeto Puerto TCP/IP estándar en Windows.
Los controladores e instaladores pueden cambiarla (a veces “útilmente”), por eso aparece tras actualizaciones.

4) ¿Qué pasa con SNMP v3?

Algunos entornos usan SNMP v3 por seguridad, pero el comportamiento básico de monitorización de puertos de Windows sigue siendo el mismo conceptualmente: quiere una respuesta SNMP.
Si v3 no está configurado de extremo a extremo (dispositivo, ACLs, credenciales), seguirás viendo síntomas de Desconectada.

5) ¿Por qué sólo ocurre en portátiles o cuando los usuarios se mueven?

Porque diferentes redes tienen diferentes ACL. Una VLAN puede permitir UDP/161; otra puede no hacerlo.
O el multicast necesario para el descubrimiento WSD funciona en un sitio y no en otro. Estandariza puertos y evita la impresión dependiente de descubrimiento para usuarios que se desplazan.

6) ¿Deberíamos usar RAW (9100) o IPP?

RAW es simple y ubicuo. IPP puede ser excelente y más moderno, especialmente con dispositivos y controladores nuevos.
Elige uno por clase de dispositivo y sopórtalo intencionalmente. El verdadero enemigo es “predeterminados aleatorios mezclados.”

7) ¿Por qué reinstalar la impresora a veces “arregla” Desconectada?

Reinstalar a menudo recrea el objeto puerto, restablece tiempos de espera o alterna el comportamiento de monitorización.
No es una solución; es una tirada de dados que a veces cae en una configuración mejor.
Quieres la causa raíz real: bloqueo por SNMP, fragilidad WSD o un problema del controlador.

8) ¿Puede una impresora estar Online en Windows pero aún así no imprimir?

Absolutamente. “Online” podría basarse en SNMP, pero la impresión podría fallar por bloqueos en TCP/9100, errores de renderizado del controlador, autenticación o colas retenidas en el dispositivo.
Siempre prueba el transporte real de impresión y revisa los registros de PrintService.

9) ¿Es este problema peor en servidores de impresión?

Puede serlo. Los servidores de impresión centralizan la dependencia: una configuración de puerto impacta a muchos usuarios.
Eso también es por lo que arreglarlo en el servidor es poderoso—estandariza la configuración de puertos una vez y toda la oficina deja de sufrir.

10) ¿Cuál es la mejor medida preventiva?

Estandariza tus puertos: Puerto TCP/IP estándar con una IP estable, protocolo conocido y estado SNMP desactivado a menos que hayas probado que SNMP es fiable en esa ruta.

Conclusión: próximos pasos que puedes estandarizar

La impresora que está “Desconectada” para siempre por lo general no está rota. Windows simplemente está convencido de que lo está, porque un monitor de puerto no pudo obtener una respuesta SNMP.
Eso no es un misterio de red. Es un error de configuración con un borde muy cortante.

Pasos prácticos siguientes:

1. Para el incidente actual: Inspecciona el puerto de la impresora. Si el estado SNMP está activado, desactívalo y vuelve a comprobar el estado.
2. Para el próximo incidente: Añade pruebas de protocolo a tu runbook: TCP/9100 (o 515/631) y SNMP sólo cuando sea relevante.
3. Para la estabilidad a largo plazo: Estandariza en IPs/puertos estables, evita WSD para colas críticas, fija versiones de controladores y separa la telemetría (SNMP) de la entrega de trabajos.

La impresión nunca será glamurosa. Pero puede ser predecible, y lo predecible es el objetivo de las operaciones.