Vous avez un Cloud PC qui refuse de provisionner, un Win32 qui ne descend jamais, une session qui rame sans raison apparente, et vous passez trois jours à interroger Intune alors que le coupable est une règle de pare-feu écrite il y a deux ans ? Cet article est fait pour vous. On part d’une VM Windows toute neuve et on va dérouler, capture après capture, un diagnostic réseau complet de vos endpoints Microsoft Intune, Windows 365 et Azure Virtual Desktop, puis on va casser le réseau exprès pour vérifier que l’outil dit bien la vérité.
L’outil en question s’appelle Microsoft Cloud Endpoint Network Health Check. Il est écrit et maintenu par Daniel Bowker, Microsoft MVP sur Windows 365, et publié sous licence MIT sur GitHub:
Il ne s’agit pas d’un produit commercial ni d’un module à installer : c’est un script PowerShell unique, sans dépendance, qui teste en un seul run l’ensemble des prérequis réseau que Microsoft publie sur quatre pages de documentation différentes.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
- 1. Le vrai problème : des prérequis réseau éparpillés
- 2. D’où vient l’outil et ce qu’il couvre
- 3. Workload et Mode : la distinction que tout le monde rate
- 4. Étape 0 : les prérequis avant de lancer quoi que ce soit
- 5. Étape 1 : le premier run et la baseline tout verte
- 6. Lire les résultats : OK, FAIL, DNS!, TLS!, INSP, ZONE, INFO
- 7. Le lab de pannes : on casse le réseau exprès
- 8. Du symptôme utilisateur au correctif réseau
- 9. Ce que l’outil ne fait pas
- 10. Conclusion et pièges à retenir
1. Le vrai problème : des prérequis réseau éparpillés
Le problème, ce n’est pas la difficulté technique, c’est le périmètre. La documentation Windows 365 le dit noir sur blanc : les prérequis se répartissent sur quatre familles distinctes, l’appareil physique, le service Microsoft Intune, la machine virtuelle session host Azure Virtual Desktop et le service Windows 365.
Although most of the configuration is for the Cloud PC network, end user connectivity occurs from a physical device. Therefore, you must also follow the connectivity guidelines on the physical device network.
Source : Network requirements for Windows 365, Microsoft Learn
Valider le réseau d’un déploiement Cloud Endpoint voulait dire donc ouvrir quatre onglets de documentation Microsoft en parallèle :
- les prérequis réseau Windows 365
- les prérequis réseau Intune
- les prérequis réseau Azure Virtual Desktop
- les prérequis réseau côté client physique
Puis extraire à la main les FQDN, les recopier dans un tableur, et lancer une boucle de Test-NetConnection maison en espérant n’avoir rien oublié…
Concrètement, ça donne quoi ? Ça donne un Cloud PC parfaitement provisionné dont l’utilisateur n’arrive pas à se connecter, parce que le poste physique dans l’agence de Lyon sort par un proxy qui ne connaît pas les endpoints du client Windows App. Vous avez validé le réseau Azure, vous n’avez pas validé le réseau du poste. Deux périmètres, deux jeux de règles, deux équipes différentes.
2. D’où vient l’outil et ce qu’il couvre
Le script a une histoire. Il démarre comme un vérificateur réseau Windows 365, publié en février 2026 sous le nom The Ultimate Windows 365 Network Validation Script. Daniel Bowker l’a ensuite élargi bien au-delà de son périmètre initial, et la version 4 marque le vrai basculement : Microsoft Intune obtient sa propre validation dédiée, à côté de Windows 365 et d’Azure Virtual Desktop.
Résultat, la version 4.1 s’appelle désormais Test-CloudEndpointNetworkHealth.ps1. L’ancien nom Test-W365NetworkHealth.ps1 reste disponible comme lanceur de compatibilité, pour ne pas casser les scripts et les runbooks écrits avant le renommage.
| Élément | Valeur |
|---|---|
| Nom du script | Test-CloudEndpointNetworkHealth.ps1 |
| Version couverte ici | v4.1 |
| Auteur | Daniel Bowker, Microsoft MVP Windows 365 |
| Licence | MIT |
| Dépendances | Aucune, PowerShell seul |
| Jeu d’endpoints | 445 entrées, cloud Microsoft commercial |
| Périmètre | Microsoft Intune, Windows 365, Azure Virtual Desktop |
| Fichier de données | Endpoints.csv, téléchargé automatiquement |
Le point qui m’a le plus intéressé n’est pas le nombre d’endpoints, c’est la nature des tests. Un script de validation réseau naïf fait un Test-NetConnection sur le port 443 et affiche un joli vert. Celui-ci va nettement plus loin :
- vrai handshake TLS avec SNI, pas un simple socket ouvert sur 443
- détection de l’inspection SSL probable via l’analyse de la chaîne de certificats
- échecs DNS remontés séparément des échecs de port
- endpoints wildcard réellement testés quand c’est possible
- test UDP réel pour RDP Shortpath
- test SNTP/NTP, avec mesure de la dérive d’horloge
- vérification d’Azure IMDS et de WireServer
- test de connectivité IPv6
- mesure de la latence de connexion
- détection d’interception par ZTNA ou Secure Web Gateway
- validation du port 80 là où Microsoft exige 80 et 443
- tests parallélisés et déduplication des couples hôte/port
Cette liste compte douze améliorations, et chacune correspond à un faux positif que vous avez probablement déjà rencontré en production sans le savoir.
3. Workload et Mode : la distinction que tout le monde rate
Au lancement, le script pose deux questions. Elles se ressemblent, elles n’ont rien à voir. C’est le point de design le plus important de l’outil et c’est aussi celui qui provoque le plus de mauvaises interprétations.
La première question, c’est le workload, autrement dit ce que vous validez :
[1] All Cloud Endpoint requirements
[2] Microsoft Intune
[3] Windows 365
[4] Azure Virtual Desktop
Workload égale QUOI, Mode égale OÙ. Retenez ces deux mots et vous ne vous tromperez plus. Un même workload Intune se teste indifféremment depuis un Cloud PC ou depuis un poste physique managé, parce que les prérequis Intune sont des prérequis d’appareil, pas des prérequis de datacenter.
| Workload | Ce qui est validé |
|---|---|
| All | Tout ce qui suit. C’est la valeur par défaut. |
| Intune | Les prérequis réseau Microsoft Intune publiés pour les appareils Windows |
| Windows365 | Les endpoints du service Windows 365, plus les dépendances AVD, Intune et plateforme Azure sur lesquelles il repose |
| AVD | Les prérequis Azure Virtual Desktop côté session host et côté client |
Le choix de conception à saluer se trouve dans la ligne Windows365. Sélectionner ce workload ne teste pas seulement les FQDN du service Windows 365. Un Cloud PC est un poste managé par Windows 365 qui s’appuie sur Intune, sur les composants de connectivité Azure Virtual Desktop et sur des services de plateforme Azure. Ne tester que les endpoints *.infra.windows365.microsoft.com vous donnerait un résultat entièrement vert alors qu’une vraie dépendance reste bloquée.
Symétriquement, le workload Windows365 exclut volontairement les fonctionnalités Intune optionnelles dont un Cloud PC n’a pas besoin pour être provisionné, managé ou joignable, comme Remote Help et le Microsoft Store. Vous ne verrez donc pas de rouge sur des services que vous n’utilisez pas.
La seconde question, c’est le mode, autrement dit d’où vous testez :
[1] Host / Cloud Network
(Cloud PC, AVD session host, or Azure VNet VM)
[2] Physical Client Device
(Intune-managed Windows device, or device connecting to a
Cloud PC or AVD session host using Windows App)
[3] Both
4. Étape 0 : les prérequis avant de lancer quoi que ce soit
Avant la moindre commande, trois règles.
- Règle 1, lisez le script avant de l’exécuter. L’auteur documente lui-même la procédure, et c’est tout à son honneur. Un
irm | iexexécute du code distant sans que vous ne l’ayez vu, et cette pratique n’a rien à faire dans un environnement de production sans revue préalable :
Invoke-WebRequest https://bowker.cloud/endpointcheck -OutFile .\Test-CloudEndpointNetworkHealth.ps1
notepad .\Test-CloudEndpointNetworkHealth.ps1
.\Test-CloudEndpointNetworkHealth.ps1
Règle 2, exécutez en session élevée. Certaines vérifications de la fabric Azure se comportent différemment hors élévation et peuvent apparaître injoignables alors que tout va bien. Administrateur local suffit, pas besoin d’aller plus loin.
Règle 3, PowerShell 7 de préférence. Windows PowerShell 5.1 fonctionne, mais 7 est la cible recommandée par l’auteur. Pour lancer le script, rien de plus simple et aucune dépendance à installer :
irm https://bowker.cloud/endpointcheck | iex
Ce dernier point mérite d’être souligné : le script ne demande aucun rôle Entra ID, aucun consentement d’application, aucune permission Graph. Il ne lit pas votre tenant. Il teste des sockets. C’est ce qui le rend utilisable par une équipe réseau qui n’a aucun droit dans Intune, et c’est précisément le genre de cloisonnement qu’on rencontre dans les grandes structures.
Voici les paramètres disponibles, tels que documentés dans le dépôt :
| Paramètre | Description | Défaut |
|---|---|---|
| -Workload | All, Intune, Windows365, AVD | Demandé, puis All |
| -Mode | 1 = Host / Cloud Network, 2 = Physical Client Device, 3 = Both | Demandé, puis 1 |
| -EndpointsCSV | Chemin vers un Endpoints.csv local | Téléchargement auto |
| -OutputPath | Export des résultats en CSV | Aucun |
| -NoTlsCheck | Ignore le handshake TLS, TCP uniquement | Off |
| -NoIntuneIPFilter | Désactive le filtrage optionnel des plages IP Intune. Alias : -NoRegionFilter | Off |
| -SkipRegionPicker | Ancien nom de paramètre, conservé pour compatibilité | Off |
| -MaxParallel | Nombre de sondes concurrentes | 12 |
-MaxParallel à l’aveugle. Douze sondes concurrentes, c’est déjà un profil de trafic qui ressemble beaucoup à du scan sortant. Sur un site protégé par un IPS ou une solution ZTNA agressive, vous risquez de déclencher une alerte SOC ou de vous faire jeter au bout de trente secondes, et vos résultats seront faussés. Prévenez l’équipe sécurité avant le run.5. Étape 1 : le premier run et la baseline tout verte
Toute la démarche de cet article repose sur une idée simple : un diagnostic ne vaut rien sans point de comparaison. On commence donc par un run de référence sur une machine dont on sait que le réseau est sain, et on garde le résultat sous le coude.
Depuis une console PowerShell élevée :
irm https://bowker.cloud/endpointcheck | iexOu, depuis CMD ou la boîte de dialogue Exécuter :
pwsh -ExecutionPolicy Bypass -Command "irm https://bowker.cloud/endpointcheck | iex"
Et pour la baseline de cet article, la version explicite avec export CSV, celle que je vous recommande parce qu’elle vous laisse une trace exploitable à lancer depuis une fenêtre PowerShell :
& ([scriptblock]::Create((irm https://bowker.cloud/endpointcheck))) -Workload All -Mode 2 -OutputPath .\baseline-saine.csv
-OutputPath, même quand tout est vert. Le jour où un utilisateur remonte un problème, la comparaison entre le CSV du jour et celui de la mise en service vaut mille suppositions. C’est la même logique qu’un baseline de performance, appliquée au réseau.6. Lire les résultats : OK, FAIL, DNS!, TLS!, INSP, ZONE, INFO
C’est ici que l’outil se distingue vraiment des scripts maison. La plupart des validations réseau que j’ai vues chez des clients renvoient deux états : ça passe ou ça ne passe pas. Or un problème DNS, un blocage de pare-feu et une inspection SSL cassent tous les trois le service, mais appellent trois correctifs radicalement différents, portés par trois équipes différentes.
| Statut | Signification |
|---|---|
| [ OK ] | Connecté. Sur le port 443, cela signifie un handshake TLS complet avec SNI là où c’est supporté |
| [FAIL] | Le DNS a résolu, mais la connexion a échoué |
| [DNS!] | Le nom d’hôte n’a pas résolu |
| [TLS!] | Le TCP est établi, mais le handshake TLS a échoué |
| [INSP] | Le TLS aboutit, mais la chaîne de certificats suggère une inspection SSL probable |
| [ZONE] | Le wildcard n’a pas de nom d’hôte public stable, la zone DNS parente a été validée à la place |
| [INFO] | Plage IP publiée, vérification propre à Azure, entrée de référence ou autre résultat informatif |
Cette granularité change la nature de la conversation. Avec un simple rouge, vous ouvrez un ticket réseau et vous attendez. Avec un [DNS!], vous savez que le pare-feu n’est pas en cause et vous allez voir l’équipe qui gère la résolution de noms. Avec un [INSP], vous savez qu’il faut demander une exclusion d’inspection, pas une ouverture de flux : le flux est déjà ouvert.
Sur ce dernier point, Microsoft est parfaitement explicite dans la documentation Windows 365 :
These traffic interception technologies can cause issues with running Azure network connection checks or Cloud PC provisioning. Make sure no network interception is enforced for Cloud PCs provisioned within the Windows 365 service.
Source : Network requirements for Windows 365, Microsoft Learn
Autrement dit, un environnement où l’inspection SSL est appliquée aux Cloud PC est un environnement hors des rails documentés, et le statut [INSP] est le seul moyen simple que je connaisse de le prouver en une capture d’écran devant l’équipe sécurité.
Deux subtilités à connaître, et elles évitent des faux diagnostics :
- Certains endpoints CDN de Windows Update et Delivery Optimization sont volontairement exclus de la validation TLS, parce que les certificats renvoyés par le CDN ne couvrent pas de façon fiable le nom d’hôte Microsoft. Ces entrées sont testées en TCP seul, pour éviter de générer un faux
[TLS!]. - Les wildcards ne sont plus systématiquement ignorés. Quand il n’existe pas de nom d’hôte public stable derrière, c’est la zone DNS parente qui est validée, d’où le statut
[ZONE]. Ce n’est ni un succès complet ni un échec, c’est une validation partielle assumée.
7. Le lab de pannes : on casse le réseau exprès
Le moment de vérité. Un outil de diagnostic qui affiche du vert quand tout va bien, ce n’est pas un exploit. Ce qu’on veut savoir, c’est s’il dit la vérité quand ça va mal, et surtout s’il désigne la bonne cause. J’ai donc monté une VM Windows jetable et j’ai cassé le réseau, panne par panne, avec un run du script après chaque manipulation.
Voici le rendu du script avant toute modification de la configuration :
Cas n°1 : la résolution DNS est cassée
Le scénario réel derrière ce cas : un serveur DNS interne injoignable, un forwarder mal configuré, ou un split-brain DNS où la zone publique Microsoft n’est plus résolue depuis le réseau interne. C’est fréquent, et c’est très mal diagnostiqué, parce que l’utilisateur décrit un symptôme applicatif alors que le problème est au niveau de la résolution.
La manipulation, dans une console élevée sur la VM de test. On note d’abord la configuration DNS actuelle pour pouvoir la remettre :
Get-DnsClientServerAddress -AddressFamily IPv4
# On pointe la carte vers un resolveur qui n'existe pas
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
Clear-DnsClientCachePuis on relance le script. Le résultat attendu est une avalanche de [DNS!], et surtout aucun [FAIL] : le script doit dire que rien n’a résolu, pas que les ports sont bloqués.
Et là, magie : là où un script maison basé sur Test-NetConnection vous aurait affiché un mur de rouge indifférencié, envoyant l’équipe réseau chercher une règle de pare-feu inexistante pendant deux jours, vous avez immédiatement la bonne piste.
Pour restaurer, remettez l’adresse notée à l’étape précédente, ou repassez en DHCP :
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses
Clear-DnsClientCache
Cas n°2 : DNS partiellement cassé, une seule zone tombe
Le cas précédent est brutal et facile à diagnostiquer même sans outil. Le cas vicieux, celui qui coûte vraiment des journées, c’est la panne partielle : tout résout, sauf une famille de noms. Un enregistrement de blocage laissé dans le DNS interne, une entrée hosts oubliée par un collègue en test, une politique de filtrage DNS qui sinkhole une zone.
On simule ça proprement avec le fichier hosts, en pointant un endpoint Windows 365 vers une adresse inexploitable :
notepad C:\Windows\System32\drivers\etc\hostsAjouter la ligne suivante, puis enregistrer
- 192.0.2.1 rdbroker.wvd.microsoft.com
Lancer la commande suivante pour purger le cache :
Clear-DnsClientCacheIci le nom résout, mais vers une adresse qui ne mène nulle part. Le comportement attendu n’est donc pas le même que dans le cas n°1, et c’est tout l’intérêt de la démonstration. La ligne concernée doit basculer en [FAIL], pas en [DNS!], pendant que le reste du run reste vert :
Le piège classique : sur ce genre de panne, l’utilisateur vous dira que « AVD ne marche pas », alors que le provisioning, l’authentification et Intune fonctionnent parfaitement. Seul le broker de connexion est injoignable. Sans un test endpoint par endpoint, vous cherchez au mauvais endroit.
Pensez à retirer la ligne du fichier hosts et à vider le cache DNS avant de continuer, sinon elle va polluer tous vos runs suivants.
Cas n°3 : le port 5671 bloqué, le grand classique du provisioning
Si vous ne deviez retenir qu’un seul cas de cet article, c’est celui-là. La documentation Windows 365 exige que les endpoints d’enregistrement IoT Hub soient joignables sur deux ports, 443 et 5671, en sortie :
global.azure-devices-provisioning.net (443 & 5671 outbound)
hm-iot-in-prod-prap01.azure-devices.net (443 & 5671 outbound)
hm-iot-in-prod-prau01.azure-devices.net (443 & 5671 outbound)
hm-iot-in-prod-preu01.azure-devices.net (443 & 5671 outbound)
hm-iot-in-prod-prna01.azure-devices.net (443 & 5671 outbound)Or, dans la vraie vie, une équipe réseau qui reçoit une demande d’ouverture pour Windows 365 ouvre le 443 et considère le travail terminé. Le 5671, c’est de l’AMQP, ça ne ressemble pas à du web, et ça passe très souvent à la trappe. Résultat : le Cloud PC ne s’enregistre jamais auprès du service de santé, le provisioning échoue ou reste bloqué, et tous les tests web que vous ferez à la main répondront correctement.
On reproduit la panne avec une règle de pare-feu sortante :
New-NetFirewallRule -DisplayName "LAB Block AMQP 5671" `
-Direction Outbound `
-Action Block `
-Protocol TCP `
-RemotePort 5671
Puis on relance, en ciblant le workload Windows 365 pour aller droit au but :
.\Test-CloudEndpointNetworkHealth.ps1 -Workload Windows365 -Mode 1
Voilà la démonstration que je cherchais. Le script teste le couple hôte et port, pas seulement l’hôte. Vous voyez le même FQDN en vert sur une ligne et en rouge sur l’autre, et la conversation avec l’équipe réseau devient triviale : le flux existe, il manque un port.
Nettoyage de la règle une fois la capture prise :
Remove-NetFirewallRule -DisplayName "LAB Block AMQP 5671"Cas n°4 : l’UDP coupé, la session qui rame sans jamais tomber
Celui-ci est le plus sournois de tous, parce qu’il ne produit aucune erreur. Rien ne tombe. L’utilisateur se connecte, travaille, et vous dit simplement que « c’est mou ». Vous regardez les logs, tout est vert, et vous concluez à un problème de perception.
Ce qui se passe réellement, la documentation Azure Virtual Desktop l’explique très bien. RDP démarre sur un transport TCP en reverse connect, puis tente d’établir la session en UDP. Si l’UDP réussit, le TCP est abandonné. Sinon, le TCP sert de solution de repli :
By default, the Remote Desktop Protocol (RDP) begins a TCP-based reverse connect transport, then tries to establish a remote session using UDP. If the UDP connection succeeds the TCP connection drops, otherwise the TCP connection is used as a fallback connection mechanism.
Source : RDP Shortpath for Azure Virtual Desktop, Microsoft Learn
Ce mécanisme de repli est une excellente idée pour la disponibilité, et une catastrophe pour le diagnostic : il transforme une panne franche en dégradation silencieuse. C’est exactement la raison pour laquelle le test UDP réel de RDP Shortpath est, à mon sens, la fonctionnalité la plus sous-estimée de ce script.
Pour reproduire, on bloque l’UDP sortant sur la VM de test. Lancez d’abord un run normal et relevez dans la sortie le port UDP effectivement testé par le script pour Shortpath, puis créez la règle correspondante :
New-NetFirewallRule -DisplayName "LAB Block UDP Shortpath" `
-Direction Outbound `
-Action Block `
-Protocol UDP `
-RemotePort 3478
Relancez ensuite en mode client, puisque c’est le poste physique qui initie la négociation Shortpath :
.\Test-CloudEndpointNetworkHealth.ps1 -Workload AVD -Mode 2
Regardez bien cette capture. C’est le seul rouge de tout le run. Sans ce test, votre validation réseau aurait été déclarée conforme à 100 %, et vous auriez cherché la cause du côté du dimensionnement du Cloud PC ou de la carte graphique. Une ligne rouge, quelques secondes de lecture, et vous savez qu’il faut aller ouvrir l’UDP sortant.
Remove-NetFirewallRule -DisplayName "LAB Block UDP Shortpath"Les cas que je n’ai pas provoqués, mais que le script sait détecter
Par souci d’honnêteté, je ne décris ici que ce que j’ai réellement cassé et observé. Trois autres capacités de l’outil méritent d’être connues, même si je ne les ai pas mises en scène dans ce lab :
- l’inspection SSL, qui remonte en
[INSP]lorsque la chaîne de certificats renvoyée ne correspond pas à ce que Microsoft présente normalement - le handshake TLS qui échoue alors que le TCP passe, qui remonte en
[TLS!], typiquement quand un Secure Web Gateway accepte le socket puis refuse le nom d’hôte au moment du SNI - la dérive d’horloge, mesurée via le test SNTP/NTP, cause classique et rarement soupçonnée d’échecs d’authentification
Si vous disposez d’un proxy d’inspection dans votre environnement de test, ces trois cas se provoquent facilement et feraient un excellent complément à ce lab.
8. Du symptôme utilisateur au correctif réseau
Voici la table de correspondance que j’ai construite à partir de ce lab. C’est elle que je garderais sous le coude en support N2, parce qu’elle part de ce que l’utilisateur dit, pas de ce que la console affiche.
| Ce que dit l’utilisateur | Statut renvoyé par le script | Où aller chercher |
|---|---|---|
| Plus rien ne fonctionne depuis ce matin | [DNS!] massif | Résolution de noms, forwarders, serveurs DNS de la carte réseau |
| Windows 365 ne marche pas, mais je reçois mes mails | [FAIL] isolé sur un endpoint | Filtrage DNS, entrée hosts, sinkhole sur une zone précise |
| Mon Cloud PC est resté en cours de provisioning | [FAIL] sur azure-devices.net en 5671 | Pare-feu sortant, port AMQP non ouvert |
| C’est lent, mais ça marche | Échec du test UDP Shortpath | UDP sortant bloqué, repli TCP en cours |
| Ça marche à Paris, pas à Lyon | Résultats divergents entre deux runs | Breakout Internet local, profil de proxy par site |
| Je n’arrive pas à me connecter mais le Cloud PC est vert dans Intune | Échecs en Mode 2 uniquement | Réseau du poste physique, pas le réseau Azure |
La dernière ligne mérite un mot. C’est le scénario le plus courant et le plus mal traité, parce que les deux équipes concernées regardent chacune leur périmètre et le déclarent sain. Lancer le script en Mode 2 depuis le poste de l’utilisateur qui se plaint tranche le débat en trois minutes.
9. Ce que l’outil ne fait pas
Un article qui ne présente que les qualités d’un outil ne vous sert à rien. Voici les limites, et elles sont d’ailleurs documentées honnêtement par l’auteur, ce qui est suffisamment rare pour être signalé.
- Le jeu d’endpoints couvre le cloud Microsoft commercial. Si vous êtes en GCC, GCC High ou dans un cloud souverain, les FQDN diffèrent et ce jeu de données ne vous concerne pas.
- Le workload Intune valide les prérequis réseau publiés par Microsoft pour les appareils Windows. Il ne prétend pas tester tous les endpoints de tous les produits qui s’intègrent à Intune.
- Les produits qui disposent de leur propre documentation réseau, comme Microsoft Defender for Endpoint ou Security Copilot, ont des prérequis supplémentaires non couverts ici.
- Le script teste la connectivité, pas la configuration du tenant. Un flux ouvert ne garantit pas qu’une stratégie Intune soit correctement ciblée.
- Il ne mesure pas la bande passante ni la qualité de la liaison sous charge. La latence est reportée, mais ce n’est pas un outil de capacity planning.
Cinq limites, aucune n’est rédhibitoire, et toutes sont assumées par le périmètre annoncé. C’est un outil de diagnostic de connectivité, il fait ce qu’il dit.
-EndpointsCSV, sinon vous allez diagnostiquer l’absence d’accès à GitHub plutôt que votre problème réel.10. Conclusion et pièges à retenir
Voilà, en une commande et quatre pannes provoquées, nous avons vérifié qu’un script PowerShell gratuit, sans dépendance et sans le moindre droit sur le tenant, sait faire la différence entre un DNS cassé, un port fermé et un transport UDP absent. C’est exactement ce qu’on demande à un outil de diagnostic.
Concrètement, ça donne quoi ? Vous gagnez la capacité de qualifier un incident réseau avant de l’escalader. Vous arrivez devant l’équipe réseau avec une ligne précise, un hôte, un port, un protocole et un statut, au lieu d’un « Windows 365 ne marche pas » qui va tourner en boucle pendant une semaine.
Les cinq pièges à retenir :
- Ne confondez pas Workload et Mode. Le premier dit ce que vous validez, le second dit d’où vous testez. Un run en Mode 1 ne vous apprend rien sur le poste de l’utilisateur.
- Exécutez en session élevée, sans quoi les vérifications de la fabric Azure peuvent apparaître en échec alors qu’elles vont bien.
- Le port 5671 n’est pas optionnel pour Windows 365. Un pare-feu qui n’ouvre que le 443 casse le provisioning sans jamais produire d’erreur web.
- Un run entièrement vert en TCP ne prouve rien sur la qualité de session. Si l’UDP est bloqué, RDP bascule silencieusement sur son repli TCP et l’utilisateur subit sans que rien ne remonte.
- Gardez une baseline. Exportez en CSV le jour de la mise en service, c’est ce qui vous permettra de comparer le jour où ça se dégrade.
Foncez tester. Le script est sous licence MIT, il ne demande aucun droit, il tourne sur une VM jetable en trois minutes, et le pire qui puisse vous arriver est de découvrir que votre réseau n’est pas aussi conforme que vous le pensiez. Ce qui, précisément, est le but recherché.
Tout le mérite revient à Daniel Bowker, qui écrit, maintient et documente cet outil. Le code se trouve sur le dépôt GitHub du projet.
