Windows no ve otros PCs: Haz que el descubrimiento de red funcione de verdad

febrero 7, 2026 • febrero 7, 2026 • Lectura: 23 min • Views: 0

¿Te fue útil?

Suele ser siempre la misma escena: abres el Explorador de archivos, haces clic en Red y está desierto. Mientras tanto puedes hacer ping al otro PC, navegar por internet, y Teams se come tu CPU como si le pagaran por ciclo. Entonces, ¿por qué Windows no puede “ver” un equipo que claramente está ahí?

Porque “Descubrimiento de red” no es una sola cosa. Es un montón de servicios, reglas de firewall, rutas de resolución de nombres, comportamientos heredados de navegación SMB y lo que sea que tu router considere buena idea hoy. Vamos a volver a hacerlo aburrido—del buen tipo de aburrido.

Qué es realmente el “Descubrimiento de red” (y por qué miente)

Cuando los usuarios dicen “Windows no ve otros PCs”, normalmente se refieren a uno de estos casos:

La vista Red del Explorador está vacía o faltan máquinas específicas.
Fallar al mapear una unidad por nombre (por ejemplo, \\FILES01\Share).
El acceso por IP funciona (por ejemplo, \\192.168.1.50\Share) pero los nombres no.
Ping funciona pero SMB no.
SMB funciona pero el equipo no aparece en las listas de exploración.

Esos son modos de fallo distintos. Trátalos de forma diferente.

Aquí está la verdad incómoda: la carpeta Red en el Explorador de archivos no es un sistema de monitorización fiable. Es una interfaz que se alimenta de mecanismos de descubrimiento que pueden bloquearse por perfiles de red, firewalls, estado de servicios o posturas de seguridad modernas. Puede estar equivocada incluso cuando el uso compartido de archivos funciona bien.

Así que el objetivo no es “hacer aparecer iconos”. El objetivo es:

Que los nombres de host se resuelvan de forma consistente.
Que los puertos SMB sean accesibles en la red correcta.
Que los recursos compartidos sean accesibles con la autenticación correcta.
Que el descubrimiento funcione donde realmente lo quieres (normalmente LAN Privada) y que esté bloqueado en otros sitios (Wi‑Fi público, aeropuertos, etc.).

Una cita para pegar en el monitor: “La esperanza no es una estrategia.” — Gordon R. Sullivan. (Si gestionas sistemas en producción, ya lo aprendiste de la manera cara.)

Guía de diagnóstico rápido (revisa esto primero)

Esta es la secuencia “sácame del atasco en cinco minutos”. ejecútala en el PC que no puede ver otros y, si es necesario, en el PC objetivo que debería ser visible.

1) Confirma que estás en el perfil de red correcto

Si está en Público, el descubrimiento debería estar limitado. Arregla eso antes de tocar cualquier otra cosa.

2) Prueba resolución de nombres vs. accesibilidad

Prueba ping TARGET y ping TARGET_IP.
Prueba Test-NetConnection TARGET -Port 445 y por IP.

Si la IP funciona y el nombre falla: es DNS/LLMNR/mDNS/NetBIOS, no “compartir”.

3) Revisa grupos de reglas del firewall y servicios de descubrimiento

Windows puede decir “Descubrimiento de red activado” mientras las reglas del firewall estén deshabilitadas o mientras los servicios Function Discovery estén detenidos.

4) Ignora el Explorador y prueba SMB directamente

Abre \\TARGET\Share. Si funciona, tienes un problema de navegación/descubrimiento, no de uso compartido de archivos.

5) Si esto es un dominio corporativo, asume GPO

Especialmente si “funcionó ayer”. Las Group Policies pueden revertir servicios, reglas de firewall y comportamiento de resolución de nombres. No lo arregles a mano: corrige la política.

Datos interesantes y breve historia (dejarás de culpar a lo incorrecto)

Un poco de contexto ayuda porque la red de Windows es un museo cuyos objetos siguen enchufados.

La tradición de la “lista de navegación” viene de NetBIOS/Computer Browser, un sistema heredado que usaba elecciones por broadcast para decidir quién lista máquinas. Por eso era inestable en redes con múltiples subredes.
SMBv1 solía estar ligado al antiguo comportamiento de navegación. Cuando SMBv1 se deshabilitó ampliamente por motivos de seguridad, mucha gente interpretó la vista más vacía de Red como “la red se rompió”.
WS-Discovery (WSD) se convirtió en un método más moderno para descubrir dispositivos y algunos escenarios de Windows, pero depende mucho del firewall y del comportamiento multicast.
LLMNR existe porque el DNS no siempre está presente en redes pequeñas. Es útil, y también un objetivo común para ataques de interceptación de credenciales en entornos hostiles.
mDNS ya no es “solo para Apple”. Windows soporta mDNS en builds modernas y aparece en hogares con dispositivos mixtos más de lo que la gente cree.
Los perfiles de red (Público/Privado/Dominio) se introdujeron para reducir incidentes tipo “me conecté al Wi‑Fi del café y expuse mis compartidos”. Las fallas de descubrimiento suelen ser una característica, no un error.
SMB sobre TCP/445 reemplazó a NetBIOS sobre TCP/139 en la mayoría de entornos Windows modernos, pero algunas herramientas y hábitos aún utilizan la pila antigua.
La vista Red del Explorador es deliberadamente conservadora en Windows moderno. No es un directorio canónico; es una UI de conveniencia que prioriza seguridad y reducir ruido.

Principios básicos: perfil, firewall, servicios, nombres, SMB

1) El perfil de red decide la postura de seguridad por defecto

Si tu interfaz de red está en Público, Windows bloqueará o limitará el tráfico usado para descubrimiento y uso compartido. Puedes alternar “Descubrimiento de red” en Configuración todo el día y seguir obteniendo resultados inconsistentes si el perfil subyacente es incorrecto.

2) Las reglas del firewall importan más que la aplicación Configuración

Windows tiene grupos de reglas de firewall como Network Discovery y File and Printer Sharing. Si están deshabilitados, el descubrimiento no funcionará. Si están habilitados en el perfil equivocado, podrías anunciar tu máquina en redes donde no deberías.

3) Los servicios son la sala de máquinas

Dos servicios son culpables frecuentes:

Function Discovery Provider Host (FDPHost)
Function Discovery Resource Publication (FDResPub)

Si están detenidos/deshabilitados, tu equipo puede no publicarse y puedes no descubrir otros de forma fiable.

4) La resolución de nombres es una bestia de muchas cabezas

Cuando escribes \\TARGET, Windows puede resolver ese nombre usando:

DNS (la mejor opción en redes gestionadas)
LLMNR
mDNS
Servicio de nombres NetBIOS (legado)
Archivo hosts (anulación manual)

Diferentes entornos deshabilitan distintos métodos (a menudo por buenas razones de seguridad). Necesitas saber de cuál dependes.

5) Compartir SMB puede funcionar incluso cuando el descubrimiento está roto

El descubrimiento sirve para encontrar cosas. SMB sirve para conectarse. No confundas ambos. Si puedes acceder a \\IP\Share, tu recurso compartido está bien. Estás ante un problema de nombres o de navegación.

Broma #1: El descubrimiento de red de Windows es como el cotilleo de oficina: rápido, poco fiable y se detiene cuando aparece Legal (también conocido como el firewall).

Tareas prácticas con comandos: diagnosticar y decidir

Estas son tareas reales que puedes ejecutar. Cada una incluye: un comando, qué significa la salida y qué decisión tomar a continuación. Ejecútalas en un PowerShell con privilegios cuando sea posible.

Tarea 1: Comprobar el perfil de red (Público vs Privado)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-List Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name            : Corp-WiFi
InterfaceAlias  : Wi-Fi
NetworkCategory : Public
IPv4Connectivity: Internet

Significado: NetworkCategory : Public explica por qué el descubrimiento y SMB pueden estar bloqueados por defecto.

Decisión: Si esto es tu LAN de confianza, cámbialo a Privado. Si es realmente no confiable, deja de esperar que el descubrimiento funcione y usa VPN + DNS en su lugar.

Tarea 2: Cambiar una red a Privada (solo si procede)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetConnectionProfile -InterfaceAlias 'Wi-Fi' -NetworkCategory Private; Get-NetConnectionProfile -InterfaceAlias 'Wi-Fi' | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Wi-Fi          Private

Significado: La interfaz de red ahora es Privada, por lo que Windows permitirá las reglas de descubrimiento (si están habilitadas) en ese perfil.

Decisión: Vuelve a probar descubrimiento/SMB. Si funciona ahora, estabas luchando contra la política, no contra la pérdida de paquetes.

Tarea 3: Confirmar configuración IP básica

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias      : Ethernet
IPv4Address         : {192.168.10.21}
IPv4DefaultGateway  : {192.168.10.1}
DnsServer           : {192.168.10.10}

Significado: Tienes IP, gateway y DNS. Bien. Si el DNS es una IP aleatoria del router, la resolución de nombres puede ser débil.

Decisión: Si el DNS apunta a un lugar incorrecto (o está vacío), arregla DHCP/DNS antes de hacer cualquier cosa sofisticada.

Tarea 4: Probar resolución de nombres (ruta DNS)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FILES01 -ErrorAction SilentlyContinue | Select-Object Name,IPAddress"
Name   IPAddress
----   ---------
FILES01 192.168.10.50

Significado: DNS puede resolver el hostname. Eso es ideal.

Decisión: Si esto falla, necesitas DNS funcional o recurrirás a LLMNR/NetBIOS/mDNS (que puede estar deshabilitado). Decide si arreglas DNS (recomendado) o aceptas soluciones puntuales entre pares.

Tarea 5: Probar accesibilidad al puerto SMB 445 (por nombre y por IP)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection FILES01 -Port 445 | Select-Object ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName     RemoteAddress   TcpTestSucceeded
------------     -------------   ---------------
FILES01          192.168.10.50   True

Significado: TCP/445 es accesible. Firewall y enrutamiento probablemente permiten SMB.

Decisión: Si False, para. Arregla reglas de firewall en el objetivo, aislamiento de VLAN o ajustes de “red de invitados” del router. El descubrimiento no arreglará SMB bloqueado.

Tarea 6: Si el nombre falla pero la IP funciona, demuéstralo

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 192.168.10.50 -Port 445 | Select-Object RemoteAddress,TcpTestSucceeded"
RemoteAddress   TcpTestSucceeded
-------------   ---------------
192.168.10.50   True

Significado: El servicio es accesible; tu problema es resolución de nombres o identidad (SPNs/credenciales), no conectividad.

Decisión: Arregla DNS o usa una entrada hosts como parche temporal. No enseñes a los usuarios a escribir IPs para siempre.

Tarea 7: Comprobar servicios de descubrimiento requeridos

cr0x@server:~$ powershell -NoProfile -Command "Get-Service FDResPub,FDPHost,SSDPSRV,upnphost | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Stopped Manual
FDPHost  Running Automatic
SSDPSRV  Stopped Manual
upnphost Stopped Manual

Significado: Si FDResPub está detenido, tu máquina puede no publicarse para el descubrimiento. Algunos entornos no necesitan SSDP/UPnP; no los actives a ciegas.

Decisión: En una LAN pequeña donde quieras descubrimiento, configura FDResPub en Automático (Inicio retrasado) y arráncalo. En una red corporativa restringida, comprueba la política primero.

Tarea 8: Iniciar y configurar Function Discovery Resource Publication correctamente

cr0x@server:~$ powershell -NoProfile -Command "Set-Service FDResPub -StartupType Automatic; Start-Service FDResPub; Get-Service FDResPub | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Running Automatic

Significado: El servicio está en ejecución y persistirá tras reinicios.

Decisión: Revisa la vista Red tras un minuto. Si sigue vacía, el firewall o el perfil siguen mal—or la red bloquea multicast.

Tarea 9: Verificar que los grupos de reglas del firewall están habilitados para el perfil Privado

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Network Discovery' | Select-Object -First 5 DisplayName,Enabled,Profile | Format-Table -Auto"
DisplayName                                              Enabled Profile
-----------                                              ------- -------
Network Discovery (NB-Name-In)                            True    Private
Network Discovery (NB-Datagram-In)                        True    Private
Network Discovery (NB-Session-In)                         True    Private
Network Discovery (SSDP-In)                               True    Private
Network Discovery (UPnP-In)                               True    Private

Significado: Las reglas de descubrimiento están habilitadas para Privado. Bien. Si están deshabilitadas, Windows no puede “ver” dispositivos usando esos métodos.

Decisión: Habilita el grupo para Privado si quieres descubrimiento; mantenlo apagado para Público.

Tarea 10: Habilitar los grupos de reglas del firewall (Network Discovery + File and Printer Sharing)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayGroup 'Network Discovery' -Enabled True; Set-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Enabled True; 'done'"
done

Significado: Esto activa un gran conjunto de reglas entrantes. Por eso solo debes hacerlo en redes Privadas/Dominio en las que confíes.

Decisión: Si al habilitar esto “se arregla todo”, has identificado el cuello de botella: configuración del firewall, probablemente gestionada por GPO en entornos empresariales.

Tarea 11: Confirmar que el servidor SMB está habilitado en la máquina objetivo

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess"
EnableSMB1Protocol EnableSMB2Protocol RejectUnencryptedAccess
------------------ ------------------ ------------------------
False              True               True

Significado: SMB2 está activado (bien). SMB1 está desactivado (también bien, normalmente). Algunos dispositivos muy antiguos requieren SMB1; trátalo como un problema de contención, no como una petición de característica.

Decisión: No actives SMB1 a menos que estés aislando ese dispositivo/red y entiendas el riesgo. Prefiere actualizar el dispositivo o usar otro protocolo.

Tarea 12: Listar recursos compartidos y validar que no persigues una ruta inexistente

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select-Object Name,Path,Description | Format-Table -Auto"
Name   Path                 Description
----   ----                 -----------
IPC$                        Remote IPC
Public C:\Shares\Public     Common drop

Significado: El recurso compartido existe. Si los usuarios no pueden acceder, eso es permisos o autenticación—no descubrimiento.

Decisión: Confirma permisos del recurso y ACLs NTFS; confirma que el usuario se autentica con la identidad esperada.

Tarea 13: Verificar que puedes enumerar el objetivo vía SMB (lado cliente)

cr0x@server:~$ powershell -NoProfile -Command "net view \\FILES01"
Shared resources at \\FILES01

Share name  Type  Used as  Comment
----------  ----  -------  -------
Public      Disk           Common drop
The command completed successfully.

Significado: La negociación SMB, la autenticación y la enumeración de recursos funcionaron por nombre. Si la vista Red del Explorador aún no lo muestra, ignora el Explorador. Estás operativo.

Decisión: Enseña a los usuarios a anclar/montar por ruta UNC o a mapear unidades vía GPO/script. No dependas de la navegación.

Tarea 14: Comprobar estado de credenciales/sesiones si el acceso es raro

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use'"
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK                     \\FILES01\Public          Microsoft Windows Network
The command completed successfully.

Significado: Hay una sesión existente. Si se usaron credenciales erróneas antes, Windows las reutilizará y seguirá fallando de manera confusa.

Decisión: Elimina la sesión y reconecta con la identidad correcta si es necesario.

Tarea 15: Borrar conexiones SMB (usar con cuidado)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use \\FILES01\Public /delete'"
\\FILES01\Public was deleted successfully.

Significado: La conexión en caché ha sido eliminada.

Decisión: Reintenta el acceso. Si ahora funciona, tu “problema de descubrimiento” era en realidad un problema de autenticación/sesión.

Tarea 16: Revisar características/servicios de Windows que suelen romper el descubrimiento en imágenes “endurecidas”

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer,LanmanWorkstation,Browser | Select-Object Name,Status,StartType"
Name            Status  StartType
----            ------  ---------
LanmanServer    Running Automatic
LanmanWorkstation Running Automatic
Browser         Stopped Disabled

Significado: Los servicios Server y Workstation están en ejecución (requeridos para SMB). El antiguo Computer Browser está deshabilitado (normal en Windows moderno).

Decisión: No intentes resucitar el servicio Browser como solución. Resuelve la resolución de nombres y la accesibilidad SMB en su lugar.

Tarea 17: Confirmar que tu máquina realmente escucha SMB (lado objetivo)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 5 LocalAddress,LocalPort,State"
LocalAddress LocalPort State
------------ --------- -----
0.0.0.0      445       Listen
::           445       Listen

Significado: SMB escucha en IPv4 e IPv6. Si nada escucha, el uso compartido de archivos no funcionará independientemente del descubrimiento.

Decisión: Si no escucha, revisa el servicio LanmanServer y la configuración del servidor; verifica que el uso compartido de archivos esté habilitado y no bloqueado por seguridad en el endpoint.

Tarea 18: Revisar los registros de eventos por fallos de publicación de descubrimiento

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.ProviderName -match 'FDResPub|FDPHost'} | Select-Object -First 3 TimeCreated,ProviderName,Id,Message | Format-List"
TimeCreated  : 2/5/2026 9:10:22 AM
ProviderName : FDResPub
Id           : 7023
Message      : The Function Discovery Resource Publication service terminated with the following error: Access is denied.

Significado: El servicio falla; “Access is denied” a menudo apunta a permisos, hardening o interferencia de un producto de seguridad endpoint.

Decisión: Deja de alternar ajustes. Arregla la falla del servicio (baseline de imagen, GPO o política del producto de seguridad) o acepta que el descubrimiento está deshabilitado intencionalmente.

Tres micro-historias corporativas desde el terreno

Micro-historia #1: El incidente causado por una suposición equivocada

Teníamos una pequeña oficina con un servidor de archivos, unas pocas máquinas con Windows 10 y un requisito “simple”: todo el mundo debía ver el servidor en el Explorador bajo Red. Llegó un ticket: “El servidor desapareció. Debe estar caído.” Los usuarios estaban en pánico. La dirección pedía ETA.

El servidor estaba bien. SMB por IP funcionaba de inmediato. Incluso SMB por hostname funcionaba desde PowerShell. Solo la vista Red estaba vacía, y eso era en lo que los usuarios confiaban.

La suposición equivocada fue creer que la vista Red es autorizativa. No lo es. Es una UI de descubrimiento oportunista. Cuando explicamos “conéctate por ruta UNC; no navegues”, la urgencia bajó. Pero aún había que arreglar el problema de percepción.

La causa real fue que una actualización de baseline de seguridad cambió el perfil de NIC a Público tras reinstalar un driver de Wi‑Fi. Ese interruptor silencioso deshabilitó las reglas de firewall de descubrimiento. El sistema no se rompió; simplemente dejó de anunciarse.

Arreglamos el perfil vía política, nos aseguramos de que las reglas de descubrimiento estuvieran habilitadas solo en Dominio/Privado, y publicamos un acceso directo al escritorio a \\FILES01\Public. La interrupción terminó en cuanto dejamos de tratar el comportamiento de la UI como salud del servicio.

Micro-historia #2: La “optimización” que salió mal

En otro entorno intentaron “limpiar el ruido de la red”. Alguien leyó que LLMNR y NetBIOS son inseguros (y pueden serlo) y aplicó una GPO de hardening: deshabilitar LLMNR, deshabilitar NetBIOS sobre TCP/IP y restringir agresivamente reglas entrantes. La intención era reducir la superficie de ataque.

Dos semanas después la mesa de ayuda se llenó de “no encuentro el equipo”, “no puedo mapear la unidad” e “impresora desaparecida”. La clave: DNS no estaba configurado de forma consistente para los puestos en sitios pequeños. Habían estado apoyándose en resolución por broadcast/multicast sin darse cuenta.

Así que la “optimización” eliminó los mecanismos de fallback sin proporcionar el reemplazo. La red no se volvió más segura; se volvió más caótica. Los usuarios empezaron a compartir direcciones IP en chats como si se intercambiasen cromos.

La solución no fue “volver a activarlo todo”. Fue terminar el trabajo: hacer DNS fiable (incluyendo actualizaciones dinámicas donde convenga), asegurar que los clientes usen los DNS correctos vía DHCP y documentar el método de conexión soportado (nombres host, no navegación). Entonces pudimos dejar LLMNR desactivado en la mayoría de redes y seguir teniendo una experiencia predecible.

Las mejoras de seguridad que rompen operaciones básicas no se adoptan—se eluden en silencio. Construye la pista antes de pedir a los pilotos que aterricen.

Micro-historia #3: La práctica aburrida y correcta que salvó el día

Un departamento financiero tenía un pequeño “archivo en un escritorio” (sí, todavía) que estábamos migrando a un servidor adecuado. Sabíamos que el descubrimiento sería frágil porque la oficina tenía Wi‑Fi segmentado, múltiples VLAN y un router que trataba el multicast como una ofensa personal.

Así que no aspiramos a la navegación en absoluto. Hicimos tres cosas aburridas: registros DNS estables, una única ruta UNC que nunca cambia y unidades mapeadas desplegadas vía política. También nos aseguramos de que los grupos de reglas del Firewall de Windows estuvieran explícitamente configurados para perfiles Dominio/Privado en lugar de “lo que sea por defecto”.

Meses después, alguien cambió el router. El descubrimiento se volvió raro en varias subredes. La vista Red del Explorador se convirtió otra vez en una casa encantada. Pero nadie lo notó, porque la vía operativa—mapear unidades y acceso UNC directo—siguió funcionando. Los tickets se mantuvieron bajos. La migración pareció “mágicamente suave”.

No es magia. Es elegir sistemas deterministas en lugar de sensaciones. Navegar es sensación.

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

Aquí es donde se quema la mayor parte del tiempo. No lo hagas.

1) Síntoma: La carpeta Red está vacía, pero internet funciona

Causa raíz: Perfil de red en Público, o reglas de descubrimiento deshabilitadas para el perfil activo.

Solución: Poner la red en Privada (si es de confianza). Habilitar el grupo de firewall “Network Discovery” para Privado. Confirmar que FDResPub esté en ejecución.

2) Síntoma: Puedes acceder a `\\IP\Share` pero no a `\\HOST\Share`

Causa raíz: Fallo de resolución de nombres (DNS ausente/incorrecto; LLMNR/NetBIOS deshabilitado; multicast bloqueado).

Solución: Hacer DNS autoritativo (preferido). Para triaje temporal, añadir entrada en hosts o usar la IP mientras arreglas DHCP/DNS.

3) Síntoma: Ping funciona, pero SMB falla (puerto 445 cerrado)

Causa raíz: Firewall en el objetivo bloqueando SMB entrante, o la red está segmentada (aislamiento Wi‑Fi de invitados, ACLs de VLAN).

Solución: Habilitar reglas de File and Printer Sharing en Privado/Dominio. Arreglar aislamiento de red. No “arregles descubrimiento” cuando SMB está bloqueado.

4) Síntoma: Un PC ve a otros, pero otros no lo ven a él

Causa raíz: El PC “invisible” no se está publicando (FDResPub detenido/deshabilitado), o su firewall bloquea tráfico de descubrimiento entrante.

Solución: Inicia/habilita FDResPub. Habilita reglas de Network Discovery en el PC que debe publicarse para Privado/Dominio.

5) Síntoma: Funcionaba hasta una actualización de Windows o refresco de imagen

Causa raíz: Servicios cambiados a Manual/Disabled, reglas de firewall revertidas, perfil de NIC cambiado o aplicado un baseline de seguridad.

Solución: Hacer el estado deseado aplicable (GPO/Intune). Deja de depender de ajustes locales que las actualizaciones pueden deshacer.

6) Síntoma: Entorno de dominio, pero el descubrimiento es irregular entre subredes

Causa raíz: Los protocolos de descubrimiento suelen depender de broadcast/multicast y no cruzan routers bien.

Solución: Usar DNS + rutas UNC directas. Si necesitas comportamiento tipo directorio, usa AD, espacios de nombres DFS o inventario gestionado—no navegación.

7) Síntoma: “No tienes permiso” o avisos repetidos de credenciales

Causa raíz: Desajuste de credenciales, sesiones en caché, restricciones NTLM o desajuste de permisos de recurso/NTFS ACL.

Solución: Borra sesiones existentes con net use y reconecta; valida permisos del recurso y ACLs NTFS. Alinea la política de autenticación con la realidad.

8) Síntoma: PC nuevo con Windows 11 no accede a un NAS antiguo

Causa raíz: El NAS requiere SMB1 o autenticación débil; Windows moderno lo bloquea por defecto.

Solución: Actualiza firmware/configuración del NAS a SMB2/3. Si debes habilitar SMB1, aisla ese dispositivo/red y acepta el riesgo explícitamente.

Broma #2: Activar SMB1 en 2026 para “arreglar descubrimiento” es como arreglar un grifo que gotea instalando una manguera de incendios.

Listas de verificación / plan paso a paso (hacer que funcione de forma fiable)

Lista A: Hogar o pequeña oficina (grupo de trabajo) donde realmente quieres navegación

Poner dispositivos en la misma LAN (no Wi‑Fi de invitados, no SSID aislados). Si el router tiene “AP isolation” o “client isolation”, desactívalo para la red de confianza.
Configurar el perfil de red como Privado en cada PC Windows que deba compartir/descubrir.
Habilitar Network Discovery + File and Printer Sharing (grupos de reglas del firewall) para el perfil Privado.
Asegurar que FDResPub y FDPHost estén en ejecución (Automático está bien para una LAN doméstica).
Confirmar que SMB funciona directamente: acceder a \\HOST\Share y \\IP\Share.
Arreglar resolución de nombres:
- Mejor: tu router provee entradas DNS (algunos lo hacen), o ejecutas un pequeño servidor DNS.
- Aceptable: entradas en hosts para un par de máquinas.
- Evita: confiar en “lo que Windows descubra hoy”.
Hacer el acceso amigable: crear accesos directos o mapear unidades; enseña a los usuarios a usarlos en lugar de navegar.

Lista B: LAN corporativa (dominio) donde la fiabilidad importa más que los iconos

Decidir la UX soportada: rutas UNC directas, unidades mapeadas, espacios de nombres DFS o SharePoint/OneDrive. Elige una y estandariza.
Hacer DNS correcto y completo: los clientes deben usar DNS corporativo (vía DHCP) y los servidores deben tener nombres estables.
Imponer la política del Firewall de Windows:
- Habilitar File and Printer Sharing entrante solo en el perfil Dominio (y a veces Privado para Wi‑Fi gestionado).
- Mantenerlo desactivado en Público, siempre.
Configurar servicios requeridos explícitamente vía GPO/Intune. No dependas de valores por defecto que imágenes y actualizaciones cambian.
No depender de descubrimiento broadcast/multicast entre subredes. Es frágil y a menudo bloqueado por buenas razones.
Monitorizar la accesibilidad SMB (puerto 445) y fallos de autenticación. Esa es la salud real del servicio, no el Explorador.

Lista C: Cuando necesitas probar dónde está la falla (nombres vs puertos vs auth)

Por nombre: Resolve-DnsName, luego Test-NetConnection -Port 445.
Por IP: Test-NetConnection IP -Port 445.
Por enumeración SMB: net view \\HOST.
Por ruta directa: abrir \\HOST\Share.
Si falla auth: comprobar sesiones con net use; borrar y reconectar; validar ACLs.

Preguntas frecuentes (FAQ)

1) ¿Por qué puedo hacer ping a un PC pero no verlo en Red?

Ping es ICMP. El descubrimiento es una mezcla de multicast/broadcast y publicación de servicios. Windows puede bloquear el descubrimiento mientras aún permite ping (o al revés). Trátalos como pruebas separadas.

2) Si la carpeta Red está vacía, ¿significa que el uso compartido está roto?

No. La carpeta Red no es una fuente de verdad. Prueba SMB directamente con \\HOST\Share o Test-NetConnection -Port 445.

3) ¿Qué servicios son realmente necesarios para el descubrimiento de Windows?

Los comunes: FDResPub y FDPHost. SSDP/UPnP puede jugar un papel en algunos escenarios, pero habilitarlos en todas partes no es automáticamente “lo mejor”.

4) ¿Debería habilitar SMB1 para arreglar esto?

Casi nunca. SMB1 es un protocolo heredado con larga historia de problemas de seguridad. Si un dispositivo lo requiere, aísla ese dispositivo/red y planifica su reemplazo.

5) ¿Por qué `\\192.168.x.x\share` funciona pero `\\hostname\share` falla?

Porque la resolución de nombres falla. Arregla DNS (lo mejor), o temporalmente usa una entrada en hosts. Deshabilitar LLMNR/NetBIOS sin preparar DNS es un error clásico.

6) ¿Por qué algunos PCs aparecen y desaparecen aleatoriamente?

El descubrimiento depende de anuncios periódicos y protocolos que no siempre sobreviven al modo suspensión, roaming Wi‑Fi, clientes VPN, reinicios de drivers o filtrado multicast. Usa unidades mapeadas y acceso basado en DNS para estabilidad.

7) Estoy en Wi‑Fi de invitados. ¿Puedo hacer que el descubrimiento funcione?

Normalmente no, y eso es intencional. Las redes de invitados suelen aislar a los clientes entre sí. Si necesitas acceso, usa un SSID/VLAN de confianza o una VPN a una red donde DNS y SMB sean soportados.

8) ¿Cómo sé si el Firewall de Windows es el problema?

Comprueba si el puerto 445 es accesible (Test-NetConnection -Port 445) y si los grupos de reglas del firewall Network Discovery y File and Printer Sharing están habilitados para el perfil activo.

9) ¿Por qué funciona por Ethernet pero no por Wi‑Fi?

Perfiles diferentes (Privado vs Público), postura de firewall diferente o aislamiento del cliente Wi‑Fi/filtrado multicast en el punto de acceso. Además, algunos productos de seguridad aplican políticas más estrictas en Wi‑Fi.

10) ¿Cuál es la “mejor práctica” en un entorno empresarial?

Deja de depender de la navegación. Usa DNS + rutas UNC directas, unidades mapeadas vía política y configuración explícita de firewall/servicios. Hazlo determinista.

Siguientes pasos (mantenerlo funcionando)

Si quieres que esto siga funcionando, haz lo operacional, no lo esperanzador:

Estandariza rutas de acceso (UNC, unidades mapeadas o DFS) para que los usuarios no dependan de la vista Red.
Haz DNS fiable. Si los hostnames importan, el DNS debe ser correcto—punto.
Imponer políticas (GPO/Intune) para:
- Expectativas de perfil de red (donde sea posible)
- Grupos de reglas del firewall en Dominio/Privado
- Inicio de FDResPub/FDPHost como servicio
Probar lo que importa: accesibilidad al puerto 445 y acceso real a los recursos compartidos. El Explorador es un extra agradable.
Sé explícito sobre la postura de seguridad: descubrimiento y compartición solo en redes de confianza; todo lo demás cerrado.

La victoria no es dejar bonita la carpeta Red. La victoria es hacer que el acceso a archivos sea predecible—hoy, después de la próxima actualización de Windows y durante el próximo cambio de router cuando todos juran “no cambió nada”.