Une évolution discrète, mais importante
Avec la version 2610 de Microsoft Intune, annoncée pendant la semaine du 26 octobre 2026, Microsoft améliore la connectivité des appareils Windows pour les opérations utilisant des notifications push.
Les scénarios concernés comprennent notamment les actions à distance sur les appareils, les applications Win32, les scripts PowerShell et les remédiations.
Pour bénéficier de ces améliorations, Microsoft recommande d'autoriser le nouveau point de terminaison :
*.trouter.communications.svc.cloud.microsoft
Ce changement peut sembler mineur. Pourtant, dans les entreprises où les communications Internet passent par un proxy ou un pare-feu restrictif, les dépendances réseau constituent une cause fréquente de dysfonctionnements difficiles à diagnostiquer.
Pourquoi les notifications push sont-elles importantes ?
Microsoft Intune dispose de mécanismes de communication permettant aux appareils de récupérer leurs stratégies et leurs tâches.
Les notifications push jouent un rôle particulier : elles permettent de prévenir un appareil qu'une action doit être traitée, sans attendre uniquement son prochain cycle normal de synchronisation.
Prenons un exemple.
Un administrateur modifie un script PowerShell affecté à un groupe de postes Windows. Grâce aux notifications push, les appareils concernés peuvent être invités à vérifier plus rapidement si une nouvelle action est disponible.
Cela ne signifie pas que l'exécution devient instantanée. Le résultat dépend toujours de la disponibilité du poste, de ses communications réseau et du traitement effectué par les composants Intune.
Quels problèmes peut-on rencontrer ?
Dans un environnement restrictif, un point de terminaison nécessaire qui n'est pas autorisé peut perturber les communications associées.
Les symptômes à examiner peuvent notamment être :
-
Des actions distantes qui tardent à s'exécuter.
-
Des scripts PowerShell dont la prise en compte semble anormalement lente.
-
Des remédiations qui ne démarrent pas dans le délai attendu.
-
Des déploiements Win32 dont la progression semble incohérente.
Ces symptômes ne prouvent pas à eux seuls que ce nouveau domaine est bloqué. Ils peuvent également provenir d'autres dépendances Intune, du poste client ou du mécanisme de déploiement.
Que doivent vérifier les administrateurs ?
La première étape consiste à consulter la documentation officielle des points de terminaison Microsoft Intune.
Ensuite, il convient de contrôler les équipements qui filtrent le trafic sortant :
-
Vérifier la présence de *.trouter.communications.svc.cloud.microsoft dans les règles autorisées.
-
Confirmer que les connexions HTTPS nécessaires sont prises en charge.
-
Examiner les restrictions DNS, proxy et pare-feu.
-
Contrôler les journaux de blocage sur les postes et équipements réseau.
-
Effectuer un essai sur quelques appareils représentatifs avant de généraliser les modifications.
Le domaine utilise un caractère générique. Il ne faut donc pas essayer de tester directement le nom contenant * comme s'il s'agissait d'un serveur unique.
Pour un diagnostic PowerShell, on peut utiliser un nom d'hôte réellement observé dans les journaux :
$HostName = "hote-reel-observe.example"
Resolve-DnsName $HostName
Test-NetConnection $HostName -Port 443
L'adresse de l'exemple est volontairement fictive : il faut la remplacer par un véritable nom d'hôte relevé dans l'environnement.
Un test TCP réussi ne garantit pas que la communication applicative Intune fonctionne. Il permet seulement d'en vérifier une partie.
Attention également à l'inspection TLS : Microsoft documente des restrictions spécifiques pour certains domaines Intune. Les exclusions doivent suivre les recommandations officielles, et non être appliquées indistinctement à tous les services Microsoft.
Quel intérêt pour AuditMS ?
Pour AuditMS, cette évolution met en évidence un sujet intéressant : la connectivité des appareils vers les services Microsoft.
Un éventuel contrôle pourrait aider les administrateurs à identifier les dépendances réseau à vérifier pour les services Intune utilisés dans leur environnement.
Il faut toutefois garder une limite importante : Microsoft Graph ne permet pas, à lui seul, de confirmer qu'un poste distant peut joindre un domaine Internet à travers son pare-feu local.
Un diagnostic fiable nécessiterait une mesure côté appareil ou depuis un environnement réseau représentatif.
Cette fonctionnalité constituerait donc une extension spécifique, plutôt qu'un simple contrôle de configuration Microsoft 365.
Conclusion
La version 2610 de Microsoft Intune rappelle que le bon fonctionnement d'une solution de gestion cloud dépend aussi de la configuration du réseau.
L'ajout d'un point de terminaison ne nécessite pas de revoir toute son architecture, mais il mérite une vérification, particulièrement dans les entreprises utilisant des proxys, des pare-feu filtrants ou des mécanismes d'inspection HTTPS.