MENU
  1. Accueil
  2. Windows
  3. troubleshooting
  4. SCCM : Comprendre et corriger le mode « Internet » vs « Intranet » du client

SCCM : Comprendre et corriger le mode « Internet » vs « Intranet » du client

troubleshooting

Apprenez à diagnostiquer et à résoudre les scénarios où un poste Configuration Manager (SCCM) bascule en « Internet » alors qu’il devrait rester en « Intranet », ou inversement ; optimisez ainsi la disponibilité de vos services de déploiement et la sécurité de votre parc.

Sommaire

Comment le client SCCM décide s’il est « Internet » ou « Intranet » ?

Vue d’ensemble du processus de décision

Le client Configuration Manager évalue continuellement son environnement réseau pour choisir le bon comportement : contacter les rôles internes (MP, DP, SUP, CRP) ou passer par la passerelle Cloud / CMG. Cette auto‑détection s’appuie sur plusieurs couches : disponibilité des points de gestion, appartenance au domaine, limites réseau, certificat X.509, et paramètres WinHTTP. Le schéma suivant résume les interactions majeures :

MécanismeRôle dans la décisionPoints de contrôle / journal
Points de gestion (MP)Interroge d’abord les MP marqués « Intranet ». Si l’appel HTTPS répond, le client se déclare « Intranet ». En cas d’échec, il teste la liste « Internet » puis passe en mode Cloud.LocationServices.log
Cache SLM (Service Location Management)Mémorise la dernière topologie valide pour accélérer les cycles suivants et limiter le trafic réseau.ClientLocation.log
Network Location Awareness (NLA)Si l’interface réseau appartient à un domaine Active Directory joint, le client privilégie l’intranet.Événements NLA + ClientLocation.log
Groupes de limites (Boundary Groups)Regroupe sous‑réseaux, plages IP, préfixes IPv6 et sites AD. L’appartenance du client à l’un de ces éléments ouvre l’accès aux rôles intranet.Console → Administration → Boundary Groups
Fallback Status Point (FSP)Fournit une route de secours et confirme la capacité à joindre au moins un rôle on‑premises.StateMessage.log
Paramètres client / certificatLe mode HTTPS Only exige un certificat client valide (Client Authentication) ; sinon, le client part en mode Internet.ccmexec.log, CcmMessaging.log

Étapes détaillées d’évaluation côté client

  1. Détermination du site : le client lit HKLM\SOFTWARE\Microsoft\CCM pour identifier le AssignedSiteCode.
  2. Construction de la liste de rôles : LocationServices.log montre les MPs, DPs et SUPs extraits de WMI (SMS_Authority).
  3. Ping / handshake HTTPS : un HEAD ou GET sur /ccm_system/request depuis chaque MP teste la connectivité.
  4. Consultation du cache SLM : si un MP intranet a répondu depuis <15 minutes, le client saute la phase de découverte complète.
  5. NLA : si la carte réseau reçoit un SID de domaine AD, le client inscrit « DomainJoined = 1 » dans ClientLocation.log.
  6. Consolidation : l’algorithme GetLocationPriorities() pèse les résultats et inscrit la ligne Client type is set to: [Intranet|Always Internet|Internet].

Bonnes pratiques de dépannage

  • Analysez d’abord LocationServices.log pour suivre chaque tentative de connexion à un MP, puis ClientLocation.log pour la décision finale.
  • Validez la propriété Type = Internet/Intranet de chaque MP dans la console, et assurez‑vous que le DNS interne ne renvoie pas de FQDN publics.
  • Maintenez à jour vos Boundary Groups : une seule plage IP manquante peut exclure des clients et provoquer le mode Internet.
  • Vérifiez la chaîne de certificats et l’accessibilité du CRL (Certificate Revocation List).
  • Sur un réseau interne sans proxy, forcez netsh winhttp reset proxy pour éviter des bascules intempestives.

Clients qui se croient à tort sur Internet après la mise à niveau 2403

Contexte

Après la mise à jour de votre site en version 2403 (mode HTTPS Only), environ 20 % de vos serveurs Windows Server 2022 affichent dans ccmsetup.log le message :
Client is on internet — trying to find proxy
Ils refusent dès lors de télécharger la politique, bloquant vos déploiements de correctifs et d’applications.

Analyse multifacteurs des causes probables

PisteDétailsActions proposées
Cache SLM corrompu / obsolèteLa mise à niveau peut laisser des entrées vers d’anciens MPs qui n’existent plus ou sont désormais « Internet ».Exécutez ccmrepair.exe, puis lancez manuellement le cycle Machine Policy Retrieval & Evaluation.
Changement dans la détection de certificat (2403)L’erreur IsSslClientAuthEnabled – 80070002 indique un certificat manquant ou non‑conforme.1) Vérifiez que le certificat client possède l’usage « Client Authentication ».
2) Ré‑enrôlez le certificat via GPO/PKI si besoin.
AutoProxy / WinHTTPLa recherche d’un serveur proxy fait croire au client qu’il est hors du LAN.netsh winhttp reset proxy puis redémarrage du service ccmexec.
Limite ou Boundary Group non mis à jourLes nouveaux sous‑réseaux vLAN n’ont pas été ajoutés après la migration.Confirmez l’inclusion des préfixes IPv6 ou plages IPv4 concernés.
Résolution DNS ambiguëUn enregistrement public renvoyé depuis le DNS interne redirige vers un MP exposé en DMZ.1) nslookup <mpfqdn> depuis une machine impactée.
2) Implémentez un split‑DNS ou corrigez la zone interne.
Bogue 2403 connuLes clients installés en Provisioning Mode restent bloqués en « Internet ».Appliquez le Hotfix KB XXXXX ou planifiez une mise à niveau vers la version suivante.

Plan d’action pas‑à‑pas

  1. Supprimer toute configuration proxy :
    netsh winhttp reset proxy Restart-Service ccmexec -Force
  2. Réinitialiser le client :
    ccmrepair.exe Forcer ensuite > Actions > Machine Policy Retrieval & Evaluation.
  3. Vérifier la couche certificat :
    certutil -store My Assurez‑vous de voir Intended Purposes : Client Authentication; sinon, ré‑enrôlez automatiquement via GPO.
  4. Contrôler les Boundary Groups : dans la console, vérifiez que chaque préfixe IP/IPv6 est bien mappé et cliquez Update Distribution Points si des modifications sont faites.
  5. Appliquer le correctif Microsoft : surveillez le canal « Hotfix 2403 » et installez le patch KB XXXXX le cas échéant.
  6. Surveiller les logs après chaque étape : concentrez‑vous sur ClientIDManagerStartup.log, LocationServices.log et CcmMessaging.log. Cherchez la ligne :
    Client is NOT on internet indiquant le retour au mode intranet.

Automatisation PowerShell proposée

Pour accélérer le diagnostic sur plusieurs serveurs, le script suivant exporte l’état du mode client, le résultat du test de certificat et du proxy :

Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
    $mode = (Get-Content 'C:\Windows\CCM\Logs\ClientLocation.log' -Last 50) |
            Select-String -Pattern 'Client type is set to' |
            Select-Object -Last 1
    $proxy = netsh winhttp show proxy
    $cert  = (Get-ChildItem Cert:\LocalMachine\My |
              Where-Object { $_.EnhancedKeyUsageList |
                             Where-Object { $_.FriendlyName -eq 'Client Authentication' } }).Thumbprint
    [PSCustomObject]@{
        ComputerName = $env:COMPUTERNAME
        Mode         = $mode.Line
        Proxy        = $proxy
        CertThumb    = $cert
    }
} | Export-Csv .\SCCM_Client_Status.csv -NoTypeInformation

Outils & ressources complémentaires

  • Clé de Registre essentielle : HKLM\SOFTWARE\Microsoft\CCM\Security\ClientAlwaysOnInternet (valeur 0 = mode automatique).
  • Paramètre de ligne ccmsetup : SMSMP=<fqdn_mp_intranet> force temporairement le client à un MP précis lors d’une réparation.
  • Rapport SQL recommandé : requêtez v_GS_LOCATION_SERVICES pour identifier les clients « Always Internet » et agir de façon proactive.
  • Configuration du CMG : si vous utilisez une passerelle Cloud Management Gateway, vérifiez que la propriété Allow intranet clients to use CMG n’est activée que si nécessaire.
  • Stratégie GPO WinHTTP : bloquez la détection automatique de proxy sur les VLAN internes pour prévenir les bascules indésirables.

FAQ – Questions fréquentes

Le client peut‑il être en mode « Internet » et installer des mises à jour logicielles on‑premises ?

Oui, si votre Software Update Point (SUP) est publié via CMG ou si l’option « Allow intranet clients to scan against CMG » est activée. Toutefois, le téléchargement des mises à jour se fera via le point de distribution configuré pour le Cloud, ce qui peut saturer votre bande passante Azure.
Comment forcer un retour immédiat en intranet sans attendre la prochaine évaluation ?

Utilisez ccmexec /resync puis Machine Policy Retrieval & Evaluation Cycle. Le redémarrage du service SMS Agent Host (ccmexec) peut également accélérer la prise en compte.
La désactivation du proxy dans Internet Options suffit‑elle ?

Non : SCCM lit la configuration WinHTTP, distincte du proxy IE/Edge. Utilisez netsh winhttp reset proxy.

Conclusion

Identifier la logique qui conduit un client SCCM à se déclarer « Internet » ou « Intranet » permet de réduire drastiquement les interruptions de service et d’augmenter la conformité de votre parc. Suivez l’ordre de diagnostic proposé — Mécanismes, Logs, Certificats, Proxy, Boundaries — et automatisez la remédiation avec PowerShell pour un gain de temps significatif.

troubleshooting
troubleshooting Windows Server Intranet Configuration Manager SCCM Internet
Sommaire