¿Clientes de ConfigMgr que a veces aparecen “en Internet” cuando están sentados en tu red local? En esta guía te explico, con ejemplos y comandos, cómo el cliente decide si está en Internet o Intranet y cómo corregir el clásico falso “Client is on internet” visto tras actualizar a la versión 2403.
Resumen ejecutivo
- El estado Internet/Intranet lo determina la conectividad real del cliente hacia sus Management Points (MP) y, en segundo plano, su caché de ubicación y pertenencia a Boundary Groups.
- Si el cliente puede hablar con un MP de intranet, se clasifica como Intranet. Si solo alcanza un MP expuesto a Internet o un CMG, se clasifica como Internet.
- Tras actualizar a 2403, algunos equipos pueden “creerse” Internet por fallo TLS/PKI, problemas de proxy WinHTTP, DNS/firewall o caché/instalación.
- La dupla de logs LocationServices.log y ClientLocation.log te dice el “por qué”. A partir de ahí, la corrección suele pasar por certificado correcto, CRL accesible, proxy reseteado, Boundary Groups completos y una reparación del cliente.
Cómo decide el cliente su estado de conectividad
Lo realmente determinante no es si el equipo está unido al dominio o si su sufijo DNS “parece” corporativo, sino a qué MPs puede conectarse. El proceso, simplificado, es:
- Consultar su caché de ubicación para saber qué MPs tiene “cerca”.
- Probar primero MPs de intranet (FQDN interno publicados para intranet).
- Si no hay éxito, probar MPs accesibles por Internet/CMG.
- Clasificar el estado según el primer punto al que logre conectarse.
Puntos de administración
El MP es el termómetro. Si el cliente logra sesión HTTPS con el MP interno, queda en Intranet; si no, pero sí puede con el MP publicado en Internet o el CMG, se clasifica Internet. La decisión es binaria y basada en conectividad efectiva.
Caché de ubicación
El cliente mantiene una lista de MPs conocidos y la usa para decidir a quién llamar primero. Este “recuerdo” acelera la detección, pero puede llevar a decisiones equivocadas si una conexión falla de forma intermitente o si cambió la topología.
Grupos de límites
Los Boundary Groups vinculan subredes, sitios de AD o prefijos IPv6 a los Site Systems (MP/DP, etc.). Una pertenencia correcta garantiza que el cliente “vea” su MP de intranet preferente. Sin cobertura de límites, el cliente puede caer en opciones de Internet aunque esté en la LAN.
Señales del sistema operativo
La pertenencia a dominio, NLA, sufijos DNS y similares orientan, pero no deciden. Lo que manda es la posibilidad de establecer sesión con el MP correcto.
Otros roles y configuraciones
El Fallback Status Point (FSP) y diversos ajustes de cliente ayudan a diagnosticar, pero no definen el estado por sí solos. El ajuste de proxy “cuando esté en Internet” solo entra en juego después de que el cliente se haya clasificado como Internet.
| Señal | ¿Determina el estado? | Comentario práctico |
|---|---|---|
| Conectividad HTTPS a MP de intranet | Sí | Si conecta, estado Intranet. |
| Conectividad a MP/CMG de Internet | Sí | Si no hay MP interno pero sí CMG/MP Internet, estado Internet. |
| Miembro de dominio | No | Útil para orientar, no decisivo. |
| Boundary Group correcto | Indirecto | Facilita que encuentre MP correcto, evita falsos Internet. |
| Proxy WinHTTP | Indirecto | Si se cree Internet, intenta usarlo y puede fallar. |
Pseudocódigo explicativo
if canReach(IntranetMP) then
State = Intranet
else if canReach(InternetMPorCMG) then
State = Internet
else
State = Unknown/Offline
end if
Logs clave que debes mirar
| Archivo | Qué explica | Qué buscar |
|---|---|---|
| LocationServices.log | Descubrimiento de MPs y evaluación de rutas | Intentos a MPs de intranet, fallos TLS, cambio a CMG/Internet |
| ClientLocation.log | Cálculo de ubicación y pertenencia a Boundary Group | Asignación de sitio, grupo de límites elegido |
| ccmsetup.log | Instalación/actualización del cliente | Mensajes “Client is on internet”, códigos como 80070002 |
| ClientIDManagerStartup.log | Selección de certificado de cliente | Cert elegido, EKU, errores de cadena de confianza |
Escenario real tras una actualización
Después de actualizar a la versión 2403 en un entorno HTTPS‑only con PKI, un subconjunto de servidores (por ejemplo, 15 de 78) empieza a mostrar en ccmsetup.log el mensaje “Client is on internet”. Acto seguido, los clientes buscan un proxy (por tener habilitado el uso de proxy cuando estén en Internet) y fallan, ya que el MP interno solo acepta tráfico de intranet. Los equipos comparten la misma subred, GPO y límites; los certificados parecen correctos; antes funcionaban sin problema.
Síntomas que suelen acompañar
- Conectividad intermitente o fallida al MP de intranet por 443/TLS.
- Entradas en LocationServices.log descartando MPs internos y probando CMG.
- Proxy WinHTTP configurado o heredado; al entrar en estado Internet, el cliente intenta usarlo y se atasca.
- Errores TLS por certificado no apto o CRL inaccesible.
- Entrada 0x80070002 en ccmsetup.log durante la actualización (no siempre crítica, pero puede dejar un estado transitorio).
Causas más comunes y cómo reconocerlas
| Causa probable | Síntoma visible | Prueba rápida | Corrección típica |
|---|---|---|---|
| El equipo no negocia HTTPS con el MP interno | Errores TLS/Schannel; LocationServices salta directo a CMG | Probar https://<MPinternoFQDN> desde el servidor | Revisar DNS, firewall, SNI/Host Header y bindings IIS; comprobar CRL |
| Selección de certificado de cliente incorrecta | El cliente elige un cert sin EKU “Client Authentication” | Revisar ClientIDManagerStartup.log y almacén “Equipo local > Personal” | Corregir plantilla/cadena; ajustar criterios de selección de cert en Client Settings |
| Proxy WinHTTP definido | En estado Internet, intenta proxy y falla | netsh winhttp show proxy | netsh winhttp reset proxy y deshabilitar uso de proxy si no aplica |
| CRL inaccesible o fuera de alcance | Errores de validación de cadena; handshake abortado | Navegar a CDP/CRL de la CA o usar, solo para aislar, /NoCRLCheck | Publicar CRL en ubicaciones accesibles; no dejar /NoCRLCheck permanente |
| Desfase de hora significativo | Fallos TLS por validez de certificados | w32tm /query /status | Alinear NTP; corregir hora del sistema |
| Bindings HTTPS en IIS del MP | Certificado equivocado o sin clave privada | netsh http show sslcert | Volver a enlazar un cert válido a 0.0.0.0:443 en el sitio correspondiente |
Checklist de diagnóstico rápido
- Nombre y ruta correctos al MP.
nslookup MPinterno.contoso.localdebe resolver a IP interna. Evita “split‑DNS” mal resuelto. - Sin proxy WinHTTP a menos que esté previsto.
netsh winhttp show proxy netsh winhttp reset proxy - Prueba TLS directa. Desde el equipo afectado, abre
https://<MPinternoFQDN>. No debe haber advertencias de certificado. - Revisa los logs correctos: LocationServices.log y ClientLocation.log. Observa qué MP prueba primero y por qué lo descarta.
- Boundary Groups. Confirma que la subred, sitio de AD o prefijo IPv6 está en el grupo de límites que referencia a ese MP y con asignación de sitio habilitada.
- Certificado de cliente. En “Equipo local > Personal > Certificados”, verifica:
- Clave privada presente.
- EKU “Client Authentication”.
- Vigencia y cadena completa hasta la CA de la organización.
- Hora del sistema. Un desfase rompe TLS.
Comandos útiles para copiar y pegar
| Comando | Para qué sirve |
|---|---|
netsh winhttp show proxy | Ver el proxy WinHTTP efectivo |
netsh winhttp reset proxy | Eliminar proxy WinHTTP |
nslookup MPinterno.fqdn | Validar resolución DNS del MP |
certutil -store -enterprise my | Listar certificados con clave privada en el almacén de equipo |
netsh http show sslcert | Comprobar bindings SSL a nivel de HTTP.sys |
w32tm /query /status | Comprobar sincronización horaria |
ccmrepair | Reparar componentes del cliente |
ccmsetup.exe /UsePKICert /mp:<MPintranetFQDN> SMSSITECODE:<SiteCode> | Reinstalar forzando MP de intranet y uso de cert PKI |
ccmsetup.exe /NoCRLCheck (solo para aislar) | Descartar CRL como causa durante la prueba (no permanente) |
Qué verás en los logs cuando está mal
- LocationServices.log: secuencia de intentos a MPs internos con errores de conexión o TLS, seguida de cambio a CMG. Frases como “Failed to get DP locations from MP” o “SSL connect error”.
- ClientIDManagerStartup.log: selección de un certificado que no cumple EKU o cadena de confianza; mensajes sobre no certificate matching criteria.
- ccmsetup.log: “Client is on internet”, código 0x80070002 en fases iniciales de la actualización.
Acciones correctivas que funcionan
- Volver a la Intranet por la vía rápida: limpia proxy WinHTTP, confirma DNS correcto y reintenta conexión con el MP interno.
netsh winhttp reset proxy ipconfig /flushdns - Reparar el cliente en los equipos afectados:
ccmrepair rem o si prefieres reinstalar apuntando al MP de intranet ccmsetup.exe /UsePKICert /mp:MPinterno.fqdn SMSSITECODE:ABC - Validar el certificado de cliente:
- Que el certificado elegido tenga EKU “Client Authentication”.
- Que la cadena de confianza y CRL sean accesibles desde el servidor.
- Si hay múltiples certificados, restringe los criterios de selección en las Client Settings.
- Revisar bindings en IIS/HTTP.sys del MP:
- Asegúrate de que el FQDN del MP coincide con el Subject/SAN del certificado enlazado al sitio.
- Si hay balanceador con SNI, que el nombre solicitado coincida con el certificado presentado.
- CRL: si sospechas problemas de CRL, prueba solo para aislar con
/NoCRLCheck. Si confirma la causa, publica adecuadamente la CRL y restablece la validación normal. - Boundary Groups: revisa cobertura de subredes (incluso segmentos nuevos) y que el grupo referencie el MP interno con asignación de sitio habilitada.
- Hora del sistema: sincroniza contra la fuente oficial de tu dominio.
Comparativa con un equipo sano
Elegir un “equipo bueno” del mismo segmento acelera el hallazgo de diferencias. Compara:
- ipconfig /all: sufijos DNS, servidores DNS, DHCP Options.
- netsh winhttp show proxy: debe coincidir.
- Versión del cliente de ConfigMgr y Component Status.
- Cadena de certificados y presencia de clave privada en “Equipo local > Personal”.
- Hora y zona horaria.
Buenas prácticas para prevenir regresiones
- Boundary Groups al día: automatiza la incorporación de subredes nuevas.
- Supervisa reachability de MPs: prueba 443/TLS desde varios segmentos, no solo desde el datacenter.
- PKI higiénica: caducidades, CRL/OCSP accesibles, plantillas sin EKU sobrantes que confundan la selección.
- Política de proxy clara: evita herencias de WinINET hacia WinHTTP sin control.
- Checklist post‑upgrade: verifica bindings IIS, certificados del MP y que los clientes siguen alcanzando el FQDN interno.
Preguntas frecuentes
¿Puede un cliente estar en Intranet y aun así usar CMG para contenido? Sí, para contenido puede haber fallback al CMG si habilitas esa opción, pero el estado de red lo marca la conectividad al MP. Que use CMG para descargar no implica que se clasifique como Internet.
¿Pertenecer al dominio garantiza estado Intranet? No. Si el cliente no logra sesión con el MP de intranet (por ejemplo, un error TLS), se clasificará como Internet aunque esté unido al dominio.
¿Desinstalar y reinstalar siempre arregla? No. Antes de reinstalar, identifica si el problema es proxy, certificado, DNS o límites. Reinstalar sin arreglar la causa solo retrasa el diagnóstico.
Guía rápida de resolución paso a paso
- DNS: que el FQDN interno del MP resuelva a IP interna correcta desde el equipo afectado.
- Proxy:
netsh winhttp reset proxy. Repite la prueba. - TLS: comprueba navegación a
https://<MPinternoFQDN>y ausencia de alertas de certificado. - Boundary Groups: confirma que la subred aparece en el grupo de límites que referencia al MP.
- Certificado: valida EKU, cadena y selección del cliente en ClientIDManagerStartup.log.
- Reparación:
ccmrepairoccmsetup.exe /UsePKICert /mp:<MPintranet> SMSSITECODE:<Site>. - CRL: si sigue fallando y sospechas de PKI, usa temporalmente
/NoCRLCheckpara aislar.
Glosario mínimo
- MP: Management Point. Servicio con el que el cliente conversa para políticas, estado, etc.
- CMG: Cloud Management Gateway. Punto expuesto en la nube para clientes en Internet.
- Boundary Group: Grupo que asocia ubicaciones de red con Site Systems preferidos.
- SLM: Service Location Management. Caché de ubicaciones en el cliente.
- CRL: Certificate Revocation List. Lista de revocación usada en validación PKI.
Conclusiones accionables
El estado Internet/Intranet del cliente de SCCM/ConfigMgr no es un misterio: es la consecuencia directa de la conectividad hacia el MP adecuado. Cuando, tras una actualización como la 2403, un grupo limitado de equipos empieza a verse “en Internet”, casi siempre hay una combinación de fallo TLS/PKI, proxy heredado, DNS/boundary o bindings en el MP. Con la ruta de diagnóstico aquí propuesta (DNS → Proxy → TLS → Límites → Certificado → Reparación), deberías poder devolverlos a Intranet de manera rápida y reproducible.
Anexo de referencia rápida
Decisión de estado en una línea
“Si alcanzo MP interno → Intranet; si no, pero alcanzo CMG/MP Internet → Internet; si no alcanzo nada → Unknown.”
Tabla de verificación final
| Punto | Comprobado | Observaciones |
|---|---|---|
| Resolución DNS de MP interno | ☐ | |
| Proxy WinHTTP limpio | ☐ | |
| Handshake TLS hacia el MP | ☐ | |
| Boundary Group correcto | ☐ | |
| Certificado con EKU Client Authentication | ☐ | |
| CRL accesible | ☐ | |
| Hora del sistema correcta | ☐ | |
| Cliente reparado o reinstalado | ☐ |
Resumen de la solución propuesta para el caso descrito
- Valida que los 15 servidores resuelven y alcanzan el FQDN del MP interno por 443 sin pasar por proxy.
- Revisa y limpia WinHTTP. Si el estado es Internet, desactiva el uso de proxy en el cliente hasta corregir la detección.
- Comprueba en ClientIDManagerStartup.log que el certificado elegido tiene EKU Client Authentication y cadena válida.
- Confirma que la subred pertenece al Boundary Group que referencia el MP de intranet con asignación habilitada.
- Si hubo cambios en 2403, revisa bindings IIS/HTTP.sys del MP y accesibilidad de la CRL.
- Ejecuta
ccmrepairo reinstala con/UsePKICertapuntando al MP interno. Usa/NoCRLChecksolo si necesitas aislar PKI. - Compara con un servidor sano del mismo segmento para detectar diferencias sutiles.
Al completar estos pasos, lo esperable es que los clientes vuelvan a clasificar su estado como Intranet y dejen de insistir en el uso de proxy o rutas de Internet/CMG.