Microsoft Connected Cache for Enterprise

Présentation et objectifs du Microsoft Connected Cache

Microsoft Connected Cache (MCC) pour l’entreprise est une extension de la stratégie de Microsoft pour optimiser la livraison de contenu. Si WUDO est une solution entièrement distribuée entre postes, Microsoft Connected Cache introduit un élément de cache dédié (centralisé) au sein du réseau local de l’entreprise. L’idée est de déployer un ou plusieurs serveurs (ou appliances) faisant office de nœuds de cache qui stockent de manière transparente le contenu téléchargé depuis le cloud Microsoft, afin de le redistribuer localement aux clients qui en ont besoin. Connected Cache vise le même objectif que WUDO – à savoir réduire la consommation de bande passante Internet et accélérer les déploiements – mais en offrant un point de cache persistant avec davantage de contrôle administrateur.

Pour imager, on peut dire que Delivery Optimization (WUDO) + Connected Cache = équivalent moderne de BranchCache/WSUS, où WUDO correspond à la mise en cache distribuée peer-to-peer et Connected Cache à un serveur cache centralisé. Microsoft présente d’ailleurs ces deux solutions comme complémentaires, WUDO étant la source distribuée de contenu et Connected Cache la source dédiée gérée par l’entreprise (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn). Les bénéfices attendus de Connected Cache en entreprise sont : des économies de bande passante encore plus grandes (puisqu’un cache peut alimenter même des clients qui n’étaient pas allumés en même temps pour se partager entre eux), une fiabilité accrue (le cache dédié étant toujours disponible, contrairement à un PC qui peut être éteint ou hors ligne) et la possibilité de servir de nombreux clients à très haut débit local. Microsoft annonce plus de 90% d’économies de trafic WAN chez les clients combinant WUDO et Connected Cache pour des scénarios comme les upgrades de Windows 11, les installations d’apps Intune ou les mises à jour mensuelles (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn).

MCC pour Enterprise est proposé comme une solution logicielle (pas un boîtier matériel imposé) et flexible : on peut l’installer sur des serveurs Windows ou Linux existants, des machines virtuelles, etc., et autant d’instances que nécessaire. Le service est géré via le cloud Azure (portail ou Azure CLI) pour la partie enregistrement et configuration, ce qui facilite le déploiement à grande échelle. En résumé, l’objectif de Microsoft Connected Cache est d’offrir aux entreprises un moyen d’héberger localement un cache des contenus Microsoft (Windows Update, Microsoft Store, Office updates, etc.) de manière officielle et supportée, afin d’améliorer encore la distribution de ces contenus sur leurs réseaux internes.

Architecture technique et fonctionnement

Sur le plan technique, Microsoft Connected Cache se compose de deux éléments principaux : un service de gestion dans Azure et un module de cache déployé sur site. Le module de cache s’exécute sous forme d’un conteneur (container Docker/Linux) hébergé soit sur un serveur Windows via WSL2, soit sur une machine Linux directement (Microsoft Connected Cache for Enterprise and Education Overview | Microsoft Learn) (Microsoft Connected Cache for Enterprise and Education Overview | Microsoft Learn). L’utilisation de conteneurs permet une installation relativement simple et isolée, gérée par Microsoft via les services Azure IoT Edge (pour la distribution du conteneur) et un compte de service géré (ou compte local) pour le faire tourner sur la machine hôte (Microsoft Connected Cache for Enterprise and Education Overview | Microsoft Learn).

Le fonctionnement peut être décomposé ainsi :

Déploiement du cache : L’administrateur crée dans le portail Azure une instance de Connected Cache resource (préversion) associée à son abonnement Azure. Il définit un ou plusieurs nœuds de cache (cache nodes) en spécifiant par exemple l’emplacement (région, site). Ce processus génère les configurations nécessaires. Ensuite, sur le serveur cible dans l’entreprise (par ex. un serveur Windows 11 ou Ubuntu), on exécute un script de provisioning fourni par Microsoft. Ce script va installer le runtime nécessaire (par exemple Docker via WSL2 sur Windows), puis récupérer l’image du conteneur Connected Cache depuis Microsoft et l’exécuter avec les paramètres (identifiants) qui l’enregistrent auprès du service Azure (Deploy Smarter: Microsoft Connected Cache for Enterprise) (Deploy Smarter: Microsoft Connected Cache for Enterprise). Le cache est alors « branché » : il sait à quel tenant/ID d’entreprise il appartient et peut communiquer avec le service de gestion.
Annonce aux clients : Pour que les clients Windows utilisent ce cache, on configure une stratégie Delivery Optimization (via Intune ou GPO) indiquant la présence d’un cache local. Typiquement, on active l’option Use Connected Cache sur les clients et éventuellement on fournit l’adresse du cache ou on configure DHCP. Dans le cas d’Intune, Microsoft gère la découverte : Intune sait quels endpoints de cache sont associés au tenant, et les clients recevront une policy contenant l’URL de connexion au cache. Alternativement, en Configuration Manager, on coche l’option pour que les clients utilisent le DP en mode Connected Cache (Microsoft Connected Cache – Configuration Manager | Microsoft Learn), ou on configure des options DHCP (234/235) pointant vers l’IP du cache pour les clients co-gérés.
Téléchargement via le cache : Une fois le cache en place et les clients configurés, le flux de téléchargement change légèrement du point de vue WUDO. Quand un client doit télécharger un contenu, il contacte d’abord le service Delivery Optimization cloud comme d’habitude. Mais ce dernier, sachant via le tenant Azure AD que l’entreprise a un cache enregistré, peut répondre au client en lui fournissant non seulement des pairs, mais aussi l’adresse du cache (en fait, le cache est traité comme une source HTTP tierce). De ce fait, le client va tenter de télécharger depuis le cache en priorité. Cela se traduit par une requête HTTP du client directement vers le serveur cache (qui écoute sur un port spécifique, souvent 80/443). Si le cache possède déjà le fichier demandé, il le renvoie immédiatement – le client l’obtient donc en LAN au lieu d’aller sur Internet. Si le cache ne l’a pas encore, deux choses se passent en parallèle : le cache commence à télécharger le fichier depuis le CDN Microsoft (il agit comme un proxy-cache, en gros) et le client peut soit attendre, soit simultanément continuer à télécharger des portions manquantes depuis Microsoft/CDN de son côté. Dans l’implémentation actuelle, le client DO contacte à la fois le cache et le CDN en parallèle (What is Delivery Optimization? | Microsoft Learn). Le premier qui fournit chaque segment “gagne”. Idéalement, le cache fournit tout (après un premier téléchargement initial).
Stockage et mise à jour du cache : Le cache stocke sur son disque local les contenus servis. Il applique des politiques d’éviction (taille du disque allouée, LRU) similaires à un cache HTTP classique. L’admin peut surveiller l’utilisation du cache (espace utilisé, taux de hit). Connected Cache prend en charge les mêmes types de contenu que WUDO supporte : mises à jour Windows, mises à jour Office 365 (Click-to-Run), applications Microsoft Store et Intune, mises à jour Defender, etc. (Deploy Smarter: Microsoft Connected Cache for Enterprise). Lorsqu’un client demande un contenu déjà présent et à jour dans le cache, c’est un cache hit rapide. Si le contenu a expiré (par ex, une nouvelle version du package est sortie), le cache peut soit le rejeter soit le retélécharger. À noter que le cache ne sert qu’en lecture pour les clients – un client n’y envoie pas ses propres données (ce n’est pas un peer upload vers cache). Seule exception, dans ConfigMgr Peer Cache on avait ça, mais ici Connected Cache est un proxy, il se remplit depuis Internet uniquement, pas depuis les clients.
Coordination cloud : Tout ceci est supervisé par le cloud Azure. Le cache communique périodiquement avec Azure (Canal de management IoT Edge) pour indiquer son état, recevoir des mises à jour (nouvelles versions du conteneur, changements de config) (Deploy Smarter: Microsoft Connected Cache for Enterprise). Le service cloud DO, lui, assure de ne fournir l’adresse du cache qu’aux appareils autorisés (votre tenant). D’ailleurs, Connected Cache nécessite des licences Windows E3/E5 et Azure registration – il est uniquement pour clients entreprise légitimes (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn). Ce n’est pas un cache ouvert à tout Internet (contrairement à les caches d’ISP qui existent aussi chez Microsoft, version « pour FAI » de Connected Cache).

En résumé, l’architecture MCC fait intervenir un serveur cache local géré via Azure, auquel les clients Delivery Optimization vont se connecter pour récupérer du contenu à vitesse LAN. Pour le client, le cache est juste une source de plus, prioritaire, traitée comme un CDN local. Pour l’admin, c’est un composant à déployer sur site, mais avec une gestion simplifiée (le gros du contrôle se fait depuis Azure, pas besoin de micro-gérer le serveur une fois configuré).

Intégration avec WUDO dans les environnements professionnels

Microsoft Connected Cache s’intègre étroitement avec WUDO : en réalité, c’est une extension de WUDO. Les clients continuent d’utiliser le service Delivery Optimization pour orchestrer les téléchargements, et le cache se fond dans le mécanisme comme source de contenu supplémentaire. Du point de vue d’un poste Windows, lorsqu’il a l’option Connected Cache activée, il va simplement voir le cache comme un peer spécial (même si techniquement c’est un serveur HTTP). Il n’y a pas deux systèmes distincts qui se concurrencent – WUDO et MCC coopèrent. Microsoft indique que pour la meilleure efficacité, un client peut se connecter en parallèle au cache et aux pairs (What is Delivery Optimization? | Microsoft Learn). Par exemple, si un PC A a le fichier X et que le cache local l’a aussi, un PC B qui en a besoin pourrait télécharger une partie depuis le cache et une partie depuis A en P2P (et éventuellement compléter sur Internet si nécessaire). Tout est géré automatiquement par WUDO.

Dans la pratique en entreprise, plusieurs scénarios d’intégration existent :

Avec Microsoft Intune (Cloud only) : On déploie un ou des caches Connected Cache sur les sites souhaités, on les enregistre dans Azure. Puis via Intune, on configure un profil de stratégie Delivery Optimization pour que les appareils utilisent le mode approprié (généralement LAN ou Groupe) et on active l’utilisation du cache (paramètre Download Mode peut rester 1 ou 2, car même en mode LAN, rappelons que le cache est traité comme source HTTP supplémentaire). Intune va faire en sorte que les PC reçoivent les informations nécessaires (souvent transparent pour l’admin – il suffit d’activer l’option “Use Connected Cache”). Désormais, lorsqu’un PC Intune demande une update, le service DO voit : tenant contoso a un cache ID XYZ sur site, l’appareil est éligible, il lui donne le point de cache. Le PC télécharge via ce cache, etc. Ce scénario convient aux environnements cloud management (pas de ConfigMgr). Il est en préversion actuellement et nécessite Windows 11 ou Windows 10 à jour.
Avec ConfigMgr (co-management ou clients ConfigMgr) : Configuration Manager a introduit dès v2010 la possibilité d’activer Connected Cache sur un Distribution Point (Microsoft Connected Cache – Configuration Manager | Microsoft Learn) (Microsoft Connected Cache – Configuration Manager | Microsoft Learn). Le DP installe alors le service de cache (basé sur la même techno) et les clients ConfigMgr peuvent l’utiliser pour les contenus cloud (par ex Intune Win32 apps, Windows Update for Business, etc.). Dans une co-management, un client Intune peut découvrir le cache ConfigMgr via un mécanisme comme DHCP options 234/235 ou via un token AAD matching. L’intégration est un peu technique mais documentée. En gros, cela permet de réutiliser l’infrastructure SCCM existante comme caches WUDO pour aussi les clients Intune. C’est un cas hybride intéressant pour les grandes organisations en transition.
Avec des appareils sur VPN : Si des télétravailleurs sont connectés en VPN, ils pourraient théoriquement accéder au cache de l’entreprise (selon la configuration VPN). On peut alors décider si on veut qu’ils l’utilisent ou pas. Une stratégie WUDO permet de désactiver l’usage du cache en VPN pour éviter de faire transiter potentiellement beaucoup de données dans le tunnel (What’s new in Delivery Optimization | Microsoft Learn). Cela dépend de la performance du VPN et de la localisation du cache (ex: si le VPN est concentré, ça peut surcharger).
Multiples caches, couverture étendue : On peut déployer plusieurs caches (par ex un par grande agence ou datacenter). Les clients Delivery Optimization sont intelligents : ils choisiront le cache le plus approprié en fonction de leur localisation réseau. Typiquement, Microsoft va associer les caches à des plages IP ou sites, ou s’appuyer sur la même logique que pour le P2P (IP publique). De cette façon, un client ne va pas aller interroger un cache à l’autre bout du monde ; il utilisera celui de son environnement proche. Il est donc tout à fait possible d’avoir une hiérarchie ou plutôt une distribution de caches fédérés via Azure. Chaque cache sert sa zone.

En résumé, l’intégration de Connected Cache en entreprise se fait de manière relativement transparente pour les postes : c’est une source additionnelle qu’ils utiliseront sans nécessiter de nouvel agent ou de modification profonde. Pour l’administrateur, cela requiert un peu de travail initial (installer le cache, configurer Intune/SCCM), mais ensuite le maintien est léger. Il faut surtout monitorer que les caches sont disponibles et efficaces (taux de hit). Notons que si un cache est indisponible, les clients basculent automatiquement sur les sources classiques (pairs ou Internet), donc le mécanisme est robuste. L’intégration de MCC avec WUDO permet vraiment d’optimiser à la fois le pire (intersite, internet) et le dernier mètre (LAN), en conjuguant les forces du P2P et du cache central.

Paramétrage et configuration recommandée

Pour implémenter Microsoft Connected Cache, quelques bonnes pratiques techniques se dégagent :

Choisir la bonne plateforme pour le cache : Si vous avez un petit bureau sans serveur, vous pouvez installer le cache sur un PC Windows 11 costaud (MCC supporte l’installation sur un Windows client). Si vous avez un datacenter ou un hub régional, un serveur (physique ou VM) sous Windows Server ou Linux fera l’affaire. Assurez-vous d’avoir au moins 50 Go d’espace disque disponible pour le cache (Deploy Smarter: Microsoft Connected Cache for Enterprise) (plus si possible, suivant le nombre de contenus que vous anticipez). Le cache peut consommer du CPU/réseau lorsqu’il sert de nombreux clients, donc dimensionnez-le en conséquence (par ex, 4 vCPU et 8 Go RAM minimum).
Réseau et DNS : Donnez au cache une IP/fQDN stable que les clients pourront résoudre. Si possible, configurez un enregistrement DNS facile (par ex cachecontoso.site1.corp) et utilisez-le lors de l’enregistrement. Vous pouvez aussi utiliser DHCP option 234/235 pour annoncer l’IP du cache aux clients non Intune. Vérifiez que les ports nécessaires sont ouverts : le cache communique sortant vers Azure IoT (port 443), et les clients communiquent vers le cache (port 80/443 sur le cache, selon config).
Enregistrement Azure : Suivez scrupuleusement les étapes du portail Azure lors de la création de la ressource Connected Cache. Actuellement, c’est en preview donc l’UI peut changer, mais en gros vous aurez à spécifier la subscription Azure (nécessite un abonnement Pay-as-you-go, même si la ressource est gratuite en soi (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn)), un resource group, et créer une ressource Connected Cache. Ensuite, utiliser l’ID ou script fourni pour installer sur le serveur. N’oubliez pas de satisfaire les prérequis (par ex activer WSL2 sur Windows, ou installer Docker sur Linux).
Configuration clients : Via Intune, créez une Delivery Optimization profile en mode Advanced où vous activez Use Connected Cache = Yes, et configurez le Download Mode souhaité (mode 2 Groupe généralement). Déployez ce profil sur vos appareils Windows 10/11. Côté ConfigMgr, activez l’option sur le DP et dans les Client Settings activez l’utilisation du cache. Pensez aussi aux clients co-managés : ConfigMgr sait passer l’info du cache via sa politique client si l’option est cochée (Microsoft Connected Cache – Configuration Manager | Microsoft Learn).
Licences : Assurez-vous que votre organisation dispose des licences Windows 10/11 Enterprise E3/E5, ou Education A3/A5, qui sont requises pour pouvoir légalement utiliser Connected Cache (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn). Sans cela, vous risquez de ne pas être en règle (bien que techniquement rien ne bloque pendant la preview, il vaut mieux respecter les conditions).
Surveiller le cache : Une fois en place, utilisez les outils de monitoring (Azure Monitor, journaux du conteneur, ou même un simple check d’URL) pour confirmer que le cache fonctionne. Vous pouvez tester avec la commande Get-DeliveryOptimizationStatus -Verbose sur un client et voir s’il y a des bytes en BytesFromCacheServer (Monitor Delivery Optimization | Microsoft Learn) (Monitor Delivery Optimization | Microsoft Learn). Azure devrait également vous fournir des métriques (taux de hit, bande passante économisée).

En configuration recommandée, on peut imaginer : un cache par site principal (par ex >50 PC) ou par région, installé sur une VM Windows Server avec 200 Go de stockage cache, tenu à jour via Azure. Tous les clients Intune en mode DO Groupe/AAD sur ce site utiliseront d’abord ce cache. Continuez à utiliser WUDO P2P en parallèle, ça ne peut qu’aider. Ne désactivez pas WUDO en pensant que le cache suffit – le mieux est vraiment la combinaison. Le cache sert de “seed” local costaud, puis les PC se partagent entre eux éventuellement.

Il faut aussi considérer les cas d’usage : si vous avez des machines qui ne voient jamais le LAN (100% télétravail), un cache sur site ne les aidera pas, concentrez WUDO via cloud. Par contre, des labos, salles de classe, open spaces avec beaucoup de machines similaires bénéficient énormément d’un cache local : les déploiements simultanés iront quasi tous chercher sur le cache après le premier.

Analyse des performances et cas d’usage techniques

Lorsque Microsoft Connected Cache est en place, il est intéressant d’analyser ses performances : combien de trafic il sert, quels sont les taux de cache hits, etc. Les entreprises qui ont adopté cette solution rapportent des améliorations significatives. Par exemple, lors d’un déploiement Windows 11 sur plusieurs centaines de machines, le cache a pu fournir la majorité des fichiers d’installation localement, entraînant une économie de bande passante Internet de l’ordre de 90% et une réduction du temps de déploiement grâce au débit LAN (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn). De même, pour l’installation d’applications Office 365 ou Intune (qui peuvent être volumineuses), le cache accélère le processus après le premier téléchargement.

Un cas d’usage technique notable est le scénario Windows Autopilot : quand de nouveaux PC sont provisionnés via Autopilot, ils téléchargent dès la sortie de boîte de nombreuses mises à jour et applications. Avec un cache en réseau local (par exemple dans l’agence où se trouve l’utilisateur), ces téléchargements initiaux sont beaucoup plus rapides et n’encombrent pas le lien WAN. Microsoft cible d’ailleurs explicitement Autopilot comme un des scénarios tirant parti de Connected Cache (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn). On peut donc préconiser de déployer un cache dans les sites où l’on fait souvent du renouvellement de PC ou des déploiements massifs.

Un autre cas est les environnements à connectivité limitée (ex: sites distants avec satellite, bases militaires…) : dans ces cas, chaque octet compte. Avoir un cache local qui évite de retélécharger plusieurs fois la même mise à jour depuis un Internet coûteux est un énorme atout. Même avec un lien intermittent, un cache peut accumuler progressivement les données quand le lien est up, et les clients locaux peuvent ensuite y accéder même si la connexion externe est lente à ce moment-là. C’est un peu une bouée de sauvetage pour des sites mal connectés.

D’un point de vue technique, il faut garder à l’esprit que Connected Cache ne supprime pas la nécessité du service Delivery Optimization cloud : les clients ont toujours besoin de contacter le service DO (pour découvrir le cache, valider les métadonnées). Donc un environnement complètement fermé sans Internet nécessiterait toujours une autre solution (ex: WSUS offline). Néanmoins, MCC permet de minimiser fortement la dépendance en bande passante : une fois le cache “chauffé”, la plupart des demandes sont locales.

Mesures à analyser : on peut mesurer le taux de succès du cache en examinant le compteur BytesFromCacheServer sur un échantillon de clients ou via les rapports Windows Update for Business qui incluent la distribution entre cache/peers/CDN (Monitor Delivery Optimization | Microsoft Learn). Idéalement, ce compteur devrait être élevé. Si ce n’est pas le cas, peut-être que les clients n’arrivent pas à joindre le cache (vérifier DNS/DHCP, firewall), ou que la stratégie n’est pas appliquée correctement. On peut aussi regarder la latence : le temps de téléchargement depuis le cache (souvent quelques secondes pour un patch de quelques centaines de Mo) vs depuis Internet (peut-être minutes). Cela donne une idée du gain utilisateur.

Enfin, mentionnons un cas d’usage technique particulier : les fournisseurs d’accès (ISP). Microsoft Connected Cache existe aussi en version pour ISP, où des opérateurs déploient des caches dans leurs réseaux pour servir de nombreux clients (c’est la même technologie de base) (What’s new in Delivery Optimization | Microsoft Learn). Cela montre la robustesse du moteur de cache – utilisé à grande échelle Internet. En entreprise, nous utilisons cette même robustesse pour nos propres clients. Le fait que le moteur soit déployé chez des centaines d’ISP assure qu’il est éprouvé et peut monter en charge (Microsoft Connected Cache for Enterprise and Education Frequently Asked Questions | Microsoft Learn).

En conclusion, Microsoft Connected Cache est un composant puissant pour qui veut optimiser au maximum la distribution de contenu Microsoft. Combiné avec le peer-to-peer de WUDO, il offre un multi-couches de cache (cache serveur + caches clients) qui se traduit par des économies réseau et des gains de temps considérables dans de nombreux scénarios. Les cas d’usage techniques allant du site à faible débit aux déploiements massive en passant par le provisioning initial démontrent la valeur de cette approche hybride. Il convient de planifier soigneusement où placer ses caches et de surveiller leurs performances, mais une fois en place, c’est un vrai atout pour l’organisation IT.