Intune Windows : autoriser le nouvel endpoint des notifications push
Intune 2610 annonce une évolution des notifications push utilisées par les actions à distance, les applications Win32, les scripts PowerShell et les Remediations sur Windows. Les équipes dont les sorties réseau sont filtrées doivent contrôler l’autorisation du nouvel endpoint, puis vérifier la réception et l’exécution sur un poste représentatif.
- Impact
- appareils Windows gérés par Intune derrière un pare-feu ou un proxy à liste d’autorisation restrictive.
- Action
- autoriser si nécessaire
*.trouter.communications.svc.cloud.microsoften TCP 443, en conservant les dépendances Intune existantes, puis contrôler un déploiement de test. - Statut
- À déployer
Un changement de connectivité, pas une garantie d’exécution immédiate
Dans la rubrique semaine du 26 octobre 2026, service release 2610, Microsoft recommande d’ajouter cet endpoint pour les scénarios de notifications Windows. La même rubrique annonce une remise plus rapide des scripts après des changements administrateur ou côté service, sans nouveau parcours d’administration.
La table des exigences réseau confirme le domaine, TCP 443 et le périmètre All regions pour les scripts et applications Win32. Ce domaine figurait déjà dans cette documentation : l’annonce 2610 ne prouve pas qu’il a été créé cette semaine.
Microsoft ne fournit ici ni délai maximal de réception ni gain chiffré. Une notification peut accélérer le contact du client avec le service ; elle ne garantit pas que le script réussira.
Contrôler le réseau puis le résultat applicatif
- Comparer les autorisations effectives. Avec l’équipe réseau, vérifier les règles du pare-feu et du proxy empruntés par les postes, y compris en VPN. Ajouter le domaine si absent. Il s’agit d’un complément : ne pas retirer les endpoints régionaux IME ni les dépendances WNS déjà documentées.
- Déclencher une modification maîtrisée. Sur des appareils de test déjà gérés, utiliser un script interne inoffensif et validé. Relever l’heure de modification et le réseau utilisé. Garder identiques le contexte d’exécution et les affectations pour comparer le comportement avant et après l’ajustement réseau.
- Vérifier deux résultats. Dans le script Intune, consulter Monitor > Device status ou User status, puis contrôler sur le poste l’effet attendu du script. Les traces réseau doivent permettre de vérifier les connexions autorisées vers les hôtes concernés ; une résolution DNS seule ne suffit pas.
Si le résultat manque, distinguer un refus réseau d’une erreur de script ou de ciblage. Un statut de réussite doit correspondre au résultat local attendu ; sinon, examiner les journaux IME indiqués dans la documentation.
La recommandation est de déployer l’autorisation réseau sur les périmètres qui en ont besoin. Elle ne consiste pas à relancer tous les scripts du parc : leur logique d’exécution reste distincte, et un script déjà exécuté ne devient pas périodique du seul fait de cette annonce.
Les mises à jour de service Intune sont déployées progressivement. Vérifier la disponibilité dans votre tenant ; cette veille ne constate pas un déploiement universel.