ConfigMgr/SCCM: como o cliente decide Intranet vs Internet e correções após atualização 2403

Entenda, passo a passo, como o cliente do SCCM/Configuration Manager decide entre Intranet e Internet, por que alguns servidores passam a “achar” que estão na Internet após uma atualização e como corrigir isso rapidamente sem adivinhações.

Índice

Como o cliente do ConfigMgr decide se está na Intranet ou na Internet

Para o cliente do SCCM/Configuration Manager (doravante “ConfigMgr”), o estado Intranet ou Internet não é uma simples flag local. Ele é inferido dinamicamente a partir do que a máquina consegue alcançar e autenticar no momento. Em outras palavras, não há “mágica”: o cliente observa o seu ambiente (rede, autenticação, certificados, proxies, pontos de gestão) e decide.

Fluxo mental do cliente

Consegue falar com um Management Point (MP) de intranet? Se sim, comporta‑se como Intranet.
Não alcança MPs de intranet, mas chega a um MP/CMG exposto à Internet? Mantém estado Internet.
Não encontra serviços nem via intranet nem via Internet? Regista erros e tenta fallback; a lógica é visível nos logs (LocationServices.log, ClientLocation.log).

O papel dos Management Points

O MP é o pilar da decisão. Ele aparece para o cliente por meio de service location e políticas. Três considerações práticas:

MP de intranet: FQDN interno, portas internas (tipicamente 443 em HTTPS). Se alcançável e confiável, o cliente fica Intranet.
MP/CMG: exposto à Internet. Se for o único MP alcançável, o cliente fica Internet.
Seleção e fallback: todo o processo está minuciosamente documentado em LocationServices.log.

Boundaries e Boundary Groups

Sem boundaries corretos, o cliente não “descobre” os serviços internos certos:

O IP/sub-rede/Site do AD do cliente precisa cair em um Boundary associado a um Boundary Group.
Esse Boundary Group deve referenciar o MP de intranet e, quando aplicável, estar marcado para site assignment.
Se o cliente não entra em nenhum Boundary útil, pode ficar sem rotas internas e “assumir” Internet.

Sinais de rede típicos de intranet

O cliente também observa sinais do próprio Windows:

NLA (Network Location Awareness) classifica o perfil como DomainAuthenticated quando a máquina consegue autenticar no domínio.
Resolução de DNS internos e conectividade a controladores de domínio (Kerberos/LDAP/DNS) reforçam o estado Intranet.
Quando esses sinais falham, é comum a máquina comportar‑se como Internet.

Proxy e WPAD no WinHTTP

O cliente ConfigMgr usa a pilha WinHTTP. Se ele “acredita” estar na Internet, tentará usar proxy (configurado manualmente ou via autodetecção/WPAD). Um proxy inesperado ou mal configurado pode bloquear MPs internos e perpetuar o estado Internet.

Certificados em ambientes HTTPS‑apenas

Em modo HTTPS only, falhas de TLS mútua (cadeia incompleta, CRL inacessível, EKU incorreta) impedem o handshake com o MP interno. Resultado: o cliente não valida o MP de intranet e acaba operando como Internet (se houver CMG) ou sem gestão.

Logs essenciais para diagnosticar

LocationServices.log: descoberta e seleção de MP/DP, preferência de rotas, alternância entre intranet/Internet.
ClientLocation.log: decisões de localização.
ccmsetup.log: mensagens durante a instalação/repair.
CertificatesMaintenance.log: seleção de certificado do cliente para mTLS.

Importante: o Fallback Status Point (FSP) não decide Intranet/Internet; ele serve para receber estados quando o cliente não consegue contactar o MP.

Tabela de sinais e onde validar

Sinal observado	Indício de Intranet	Indício de Internet	Onde validar
Contato com MP interno	Consegue resolver e estabelecer TLS mTLS no FQDN interno	Falha no handshake interno e só alcança CMG	`LocationServices.log`, `ClientLocation.log`
Perfil de rede (NLA)	`DomainAuthenticated`	`Public` ou `Private`	`Get-NetConnectionProfile`
WinHTTP Proxy/WPAD	`Direct access (no proxy)` ou proxy esperado	Proxy inesperado; bloqueio a MPs internos	`netsh winhttp show proxy`
PKI do cliente	EKU Client Authentication, cadeia/CRL válidas	EKU incorreto, CRL inacessível	`CertificatesMaintenance.log`, MMC Certificados
Boundaries	IP/Site AD no Boundary certo; BG com MP e site assignment	Sem Boundary eficaz ou BG sem MP	Consola do ConfigMgr; `LocationServices.log`

Clientes que passam a pensar que estão na Internet após atualização

Cenário real: após atualizar o ambiente para a versão 2403 (modo HTTPS‑apenas com PKI interna), um subconjunto de servidores Windows Server 2022 (ex., 15 de 78) começa a registar no ccmsetup.log a mensagem “Client is on internet” e a procurar proxy, falhando porque o MP aceita apenas ligações de intranet. Outros servidores no mesmo subnet seguem normais. Certificados e boundaries parecem corretos à primeira vista.

Esse padrão quase sempre indica uma combinação de três classes de causas: perfil de rede/NLA divergente, proxy WinHTTP/WPAD aplicado seletivamente e/ou cadeia/CRL de certificados inconsistente em máquinas específicas. A seguir, um plano prático e objetivo para remediar.

Prioridade de rede e perfil de ligação

Confirme o perfil de rede: Get-NetConnectionProfile O valor esperado é DomainAuthenticated. Se aparecer Public ou Private, reinicie o NLA e limpe NICs antigas: sc stop nlasvc sc start nlasvc Remova/adapte NICs ocultas ou desativadas conforme necessário Garanta reachability aos DCs (DNS/Kerberos/LDAP). Uma perda intermitente aqui faz o cliente oscilar para Internet.
Teste nome e porta do MP interno: Resolve-DnsName mp01.contoso.com Test-NetConnection mp01.contoso.com -Port 443 Falhas de resolução indicam DNS interno incorreto; falhas de porta 443 podem indicar firewall, TLS ou proxy interferindo.

Prioridade de proxy e autodetecção

Verifique e limpe o proxy WinHTTP: netsh winhttp show proxy netsh winhttp reset proxy Se houver GPO de proxy ou Detectar definições automaticamente (WPAD), desative temporariamente para teste. Um WPAD “silencioso” é especialista em causar falso estado de Internet.

Prioridade de TLS e PKI

No cliente: certificado com EKU Client Authentication, cadeia completa, CRL/OCSP acessíveis. Verifique também a seleção automática em: C:\Windows\CCM\Logs\CertificatesMaintenance.log
No MP: certificado com EKU Server Authentication, Subject/SAN coerentes com o FQDN usado pelos clientes.
Teste mTLS fim a fim: valide que o handshake mutuamente autenticado na 443 funciona sem alertas de cadeia.

Prioridade de boundaries e site assignment

Confirme as VLANs/IPs dos servidores problemáticos nos Boundaries corretos e que o Boundary Group:
- Está marcado para Use this boundary group for site assignment.
- Referência explicitamente o MP de intranet esperado.

Reinstalação dirigida quando necessário

Forçe MP de intranet na reinstalação para “trazer” a máquina ao estado certo (faça após reset do proxy WinHTTP): ccmsetup.exe /mp:mp01.contoso.com SMSMP=mp01.contoso.com SMSSITECODE=ABC /UsePKICert Se persistir, tente ccmrepair ou ccmsetup /uninstall seguido de reinstalação com os parâmetros acima.

Configuração herdada e armadilhas ocultas

Garanta que CCMHOSTNAME (CMG) não foi deixado nesses clientes e que nenhuma definição de Always Internet foi aplicada via política/imagem.
Uma mensagem comum no ccmsetup.log: IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Costuma significar chave/valor ausente durante o bootstrap; foque no “Client is on internet” e nas verificações de rede/proxy/TLS/boundaries acima para achar a causa real.

Sintomas típicos nos logs e como interpretá‑los

LocationServices.log mostra tentativas sequenciais de MPs; quando o cliente rejeita MPs internos por falha de TLS ou de resolução e, em seguida, tenta CMG, verá entradas de fallback e mudança de current management point.
ClientLocation.log explicita a decisão de localização (Internet/Intranet) e as razões (MP reachable, proxy in use, no boundary, etc.).
CertificatesMaintenance.log detalha thumbprints avaliados, EKU e cadeias; mensagens de no suitable client certificate apontam direto para PKI/CRL.

Checklist rápido de diagnóstico

Perfil de rede: Get-NetConnectionProfile deve retornar DomainAuthenticated.
Proxy WinHTTP: netsh winhttp show proxy deve indicar Direct access (ou o proxy esperado).
DNS e 443 para MP interno: Resolve-DnsName e Test-NetConnection -Port 443 devem passar.
Certificados: cliente com EKU Client Auth; cadeia completa; CRL acessível. MP com EKU Server Auth e FQDN correto.
Boundaries: IP do host presente; Boundary Group com site assignment e MP associados.
Logs: LocationServices.log deve mostrar seleção de MP de intranet sem quedas para Internet.
Se necessário: reinstalar forçando /mp: + SMSMP= + /UsePKICert.

Teste	Comando	Resultado esperado	Ação quando falha
Perfil NLA	`Get-NetConnectionProfile`	`DomainAuthenticated`	Reiniciar NLA, corrigir trust no AD, revisar NICs
Proxy WinHTTP	`netsh winhttp show/reset proxy`	Direct access (ou proxy válido)	Remover proxy inesperado, desativar WPAD temporariamente
DNS interno	`Resolve-DnsName mp01.contoso.com`	Resolve para IP interno	Corrigir DNS/sufixos de pesquisa
TLS 443	`Test-NetConnection mp01.contoso.com -Port 443`	Conectividade estabelecida	Checar firewall, inspeção TLS, certificados e CRL
Certificado do cliente	MMC Certificados, `CertificatesMaintenance.log`	EKU Client Auth e cadeia OK	Reemitir/instalar cadeia, validar CRL/OCSP
Boundary Group	Consola do ConfigMgr	BG com MP e site assignment	Associar IP/VLAN e MPs corretos

Boas práticas para evitar recidivas

Padronize proxy no sistema (WinHTTP) e navegação (WinINET). Documente GPOs e evite WPAD “acidental”.
Automatize verificação de certificados: script que confere EKU, cadeia e CRL em lote, especialmente antes de ondas de atualização.
Higiene de boundaries: versionar a configuração de Boundaries/Groups e revisar ao introduzir novas VLANs.
Monitorize logs críticos: ingestão de LocationServices.log/ClientLocation.log em SIEM para alertar sobre quedas em massa para Internet.
Documente MPs e FQDNs esperados, tanto internos quanto na CMG, para uso em ccmsetup de emergência.

Perguntas frequentes

O FSP determina o estado de Intranet ou Internet?

Não. O FSP apenas recebe estados quando o cliente não consegue comunicar com o MP. A decisão de Intranet/Internet é feita a partir da conectividade e seleção de MPs, boundaries, NLA e, em HTTPS, do êxito do mTLS.

Existe uma chave para forçar “sempre Internet” no cliente?

Sim, há configurações que podem direcionar o cliente para CMG/Internet, mas devem ser usadas com cuidado e não para mascarar um problema real. Revise imagens, tarefas de OSD e GPOs para garantir que nenhuma opção herdada esteja setando comportamento “Always Internet” em servidores que deveriam ser intranet.

Como saber rapidamente se a falha é PKI?

Se a resolução DNS e a porta 443 funcionam para o MP interno, mas o LocationServices.log mostra rejeição ou fallback logo após tentativa de contacto, abra o CertificatesMaintenance.log. Mensagens como “no matching client certificate” ou “chain building failed” denunciam cadeia/CRL.

Por que máquinas no mesmo subnet se comportam de forma diferente?

Porque sinais locais diferem: perfil NLA, caches de proxy/WPAD, NICs ocultas, cadeias de certificados parcializadas, horário/tempo de vida de CRL, ou até drivers que interferem na pilha de rede. Os passos do checklist isolam rapidamente qual fator está divergente.

Dica final

Quando duas máquinas idênticas se comportam de forma distinta no mesmo subnet, aposte primeiro em três alvos: NLA (perfil de rede), WinHTTP/WPAD (proxy sistémico) e cadeia/CRL (PKI). Em geral, os logs LocationServices.log e ClientLocation.log apontam exatamente onde a decisão “Internet” acontece. Resolver a causa na fonte é mais sustentável do que reinstalar o cliente às cegas.

Apêndice de comandos úteis

# Perfil de rede
Get-NetConnectionProfile

Reiniciar NLA

sc stop nlasvc
sc start nlasvc

Proxy WinHTTP

netsh winhttp show proxy
netsh winhttp reset proxy

DNS e 443 para MP interno

Resolve-DnsName mp01.contoso.com
Test-NetConnection mp01.contoso.com -Port 443

Reinstalar cliente forçando MP interno e uso de PKI

ccmsetup.exe /mp\:mp01.contoso.com SMSMP=mp01.contoso.com SMSSITECODE=ABC /UsePKICert

Resumo prático em uma página

Decisão Intranet/Internet: é resultado de conectividade real com MPs, boundaries, NLA e mTLS (quando aplicável).
Logs‑chave: LocationServices.log, ClientLocation.log, ccmsetup.log, CertificatesMaintenance.log.
Quando “de repente” vira Internet: olhe NLA, proxy/WPAD e PKI antes de qualquer outra coisa.
Conserto rápido: limpe proxy WinHTTP, restabeleça DomainAuthenticated, valide DNS/443, corrija cadeia/CRL e, se preciso, reinstale com /mp: + SMSMP= + /UsePKICert.
Evite reincidência: padronize proxy, automatize verificação de certificados e mantenha boundaries versionados.

Nota final sobre terminologia: SCCM e Configuration Manager referem‑se ao mesmo produto (Microsoft Endpoint Configuration Manager/ConfigMgr). Termos como MP (Management Point), CMG (Cloud Management Gateway), DP (Distribution Point), SUP (Software Update Point) e BG (Boundary Group) são usados de forma consistente com a prática de campo.