WSUS est déprécié, pas arrêté du jour au lendemain
Microsoft ne développe plus de nouvelles fonctionnalités pour WSUS. Le rôle demeure pris en charge pour les déploiements de production et reçoit des mises à jour de sécurité et de qualité selon le cycle de vie du produit. La dépréciation n’est donc ni une date d’arrêt universelle ni une raison de désinstaller précipitamment un serveur qui distribue encore les correctifs.
La vraie décision est de séparer trois besoins : obtenir les mises à jour, décider quand les installer et prouver que les systèmes fonctionnent après leur application. Azure Update Manager répond surtout aux deux derniers. Une transition réussie peut commencer en conservant WSUS comme source.
Ce qu’Azure Update Manager remplace — et ce qu’il ne remplace pas
Update Manager vise les systèmes serveur Windows et Linux. Pour les postes Windows 10/11, prévoyez une stratégie distincte avec Intune ou Windows Autopatch selon l’admissibilité. N’appliquez pas un projet de correctifs serveurs à tout le parc WSUS sans distinguer les populations.
Le service moderne n’exige pas Azure Automation, Log Analytics ou Azure Monitor Agent pour ses fonctions de base. Il utilise des extensions sur les machines; les serveurs hors Azure passent par Azure Arc.
| Composant | Responsabilité | À ne pas confondre |
|---|---|---|
| WSUS | Source locale, approbations et distribution Windows | Une planification Azure ne transfère pas automatiquement ces règles |
| Azure Arc | Rattachement et gestion des serveurs hors Azure | Les VM demeurent sur leur infrastructure actuelle |
| Azure Update Manager | Évaluation et orchestration des correctifs | Ce n’est pas un dépôt ni un cache de téléchargement |
| Windows Update ou gestionnaire Linux | Recherche et installation depuis la source configurée | Les dépôts et leur accessibilité restent nécessaires |
1. Préparer le périmètre et la connectivité
Inventoriez OS, versions, région Azure, applications, redémarrages permis, criticité, source de correctifs et responsable. Vérifiez les systèmes pris en charge dans les prérequis Microsoft; une machine visible dans Arc n’est pas automatiquement admissible à toutes les fonctions Update Manager.
L’agent Connected Machine a besoin des destinations Azure documentées, généralement en HTTPS sortant. Les téléchargements Windows ou Linux utilisent aussi leurs propres destinations. Un proxy fonctionnel pour Arc ne prouve pas que WSUS, Microsoft Update ou les dépôts Linux sont accessibles.
Conservez la console de virtualisation ou un accès de récupération indépendant. Dans un réseau réellement isolé d’Azure, ce modèle de gestion cloud n’est pas un remplacement direct de la gestion locale.
- Vérifier les fournisseurs de ressources nécessaires, notamment Microsoft.HybridCompute et Microsoft.Maintenance, avec l’équipe Azure.
- Tester DNS, proxy, certificats, espace disque et santé du gestionnaire de paquets avant le premier correctif.
- Ne pas ouvrir de port entrant Internet vers un serveur pour le seul besoin de l’agent Arc.
2. Conserver WSUS au début, maîtriser les GPO
Sur un serveur Arc, Update Manager ne remplace pas les réglages Windows Update du registre. Conservez d’abord la source WSUS et ses approbations, tout en confiant la fenêtre d’installation au nouvel outil. Vérifiez les GPO de source, d’installation automatique et de redémarrage : elles peuvent contredire la planification Azure.
La stratégie « Spécifier l’emplacement intranet du service de mise à jour Microsoft » se trouve sous Configuration ordinateur > Modèles d’administration > Composants Windows > Windows Update; les sous-dossiers varient avec les ADMX. Ne retirez cette configuration que dans une phase distincte, avec validation de l’accès à la nouvelle source.
L’absence de ces clés ne suffit pas à identifier toute la configuration effective. Consultez aussi la stratégie résultante et effectuez une évaluation réelle. Si Configuration Manager gère les correctifs, retirez cette responsabilité pour le pilote avant de donner le contrôle à Update Manager; ne laissez pas deux orchestrateurs concurrents.
Get-Service wuauserv,bits | Select-Object Name,Status,StartType
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' `
-ErrorAction SilentlyContinue | Select-Object WUServer,WUStatusServer
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' `
-ErrorAction SilentlyContinue | Select-Object UseWUServer,AUOptions
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" show3. Commencer par l’évaluation, sans installation
Dans Azure Update Manager > Machines, sélectionnez un petit groupe puis lancez Check for updates. Examinez les erreurs avant d’activer Periodic assessment. Cette évaluation périodique recherche les correctifs environ toutes les 24 heures; elle ne constitue pas une autorisation d’installation.
Azure Policy permet d’activer ce réglage à l’échelle. Choisissez la définition destinée aux serveurs Azure Arc, limitez l’affectation au groupe de ressources pilote et examinez les paramètres Windows/Linux. Une tâche de remédiation traite les ressources existantes. Contrôlez les droits de son identité managée plutôt que d’étendre inutilement la portée.
Une évaluation verte signifie que la source consultée ne présente pas de correctifs applicables manquants; elle ne démontre ni l’absence de vulnérabilités ni la santé métier.
4. Créer une fenêtre de maintenance exploitable
Dans Schedule updates, créez une Maintenance Configuration de portée Guest (InGuestPatch). Définissez fuseau horaire, récurrence, durée, classifications ou KB/paquets ciblés et comportement de redémarrage. Pour les VM Azure, Customer Managed Schedules est un prérequis; ce réglage d’orchestration ne s’impose pas aux serveurs Arc.
Une fenêtre n’interrompt pas brutalement une installation déjà commencée. Prévoyez une marge pour les téléchargements, redémarrages et tests; une exécution partielle doit être examinée. Le choix Never reboot ne neutralise pas toutes les autres stratégies de redémarrage du système.
- Exemple de conception : pilote en semaine, serveurs applicatifs après validation, bases et infrastructures critiques dans des fenêtres séparées.
- Ne pas supposer qu’une même planification connaît les dépendances SQL Always On, les clusters ou l’ordre applicatif : organiser explicitement bascule, drainage et contrôles.
- Définir qui autorise la vague suivante et qui intervient si le service ne revient pas.
5. Utiliser les portées dynamiques sans surprises
Une portée dynamique sélectionne les machines selon abonnement, groupe de ressources, emplacement, OS et tags. La sélection est recalculée à l’exécution : la liste prévisualisée n’est pas une liste figée.
Utilisez par exemple PatchRing=Pilot et Owner=Infrastructure. Un changement de tag devient alors un changement opérationnel. Restreignez qui peut le faire, contrôlez les associations statiques et dynamiques, et évitez les fenêtres qui se chevauchent.
resources
| where type =~ 'microsoft.hybridcompute/machines'
| project name, resourceGroup, location,
ArcStatus=tostring(properties.status),
PatchRing=tostring(tags.PatchRing),
Owner=tostring(tags.Owner)
| order by PatchRing asc, name asc6. Déléguer les opérations sans donner Owner à tous
Séparez lecture des résultats, lancement d’une évaluation, installation et modification des fenêtres. Pour Arc, les actions assessPatches/action et installPatches/action relèvent de Microsoft.HybridCompute/machines; les configurations et associations relèvent de Microsoft.Maintenance.
Les rôles intégrés peuvent être plus larges que le besoin. Construisez un rôle personnalisé à partir de la matrice Microsoft lorsque nécessaire, puis testez une opération autorisée et une opération interdite. Protégez aussi les comptes administrateurs Azure par MFA et accès conditionnel adaptés.
7. Prévoir le coût avant l’activation globale
Les VM Azure n’ont pas de supplément Update Manager. Pour les autres serveurs Arc, la facturation dépend des jours connectés et gérés : une évaluation ou une association à une planification peut compter, même sans correctif installé.
Des exemptions existent notamment pour certains scénarios Defender for Servers Plan 2, ESU et licences Windows Server admissibles avec Software Assurance ou abonnement. Validez les conditions exactes, y compris le mode de rattachement et les avantages activés; Arc gratuit ne signifie pas tous ses services gratuits.
Pour budgéter, utilisez : nombre de serveurs facturables × tarif applicable × prorata. Illustration seulement : 40 serveurs à un tarif hypothétique de 5 USD/mois donnent 200 USD/mois, avant autres services et conversion CAD. Confirmez le montant contractuel dans le calculateur Azure et observez Cost Management pendant le pilote.
8. Windows, Linux et limites à documenter
Sous Linux, validez les dépôts configurés, leurs abonnements et les éventuels verrous ou outils automatiques concurrents. Un paquet absent du dépôt ne devient pas disponible parce que le serveur est connecté à Arc. Séparez les anneaux Windows et Linux lorsque leurs tests et contraintes diffèrent.
Update Manager ne distribue pas lui-même les correctifs et ne remplace pas une solution générale de déploiement logiciel. Les mises à jour d’applications dépendent de leur présence dans les sources prises en charge. L’installation de pilotes n’est pas prise en charge; prévoyez un processus distinct pour firmwares, pilotes et mises à niveau majeures.
9. Valider, conserver les preuves et préparer le retour arrière
Le retour à l’ancien orchestrateur consiste à retirer les affectations du pilote, empêcher leur recréation par Policy et rétablir la configuration documentée. Cela ne désinstalle pas les correctifs déjà posés. La désinstallation dépend du correctif et du système; pour une panne majeure, prévoyez une restauration testée et cohérente avec l’application, pas seulement un instantané.
Examinez les erreurs, mises à jour restantes et redémarrages en attente, puis testez l’application. Resource Graph conserve les évaluations pendant 7 jours et les résultats d’installation pendant 30 jours : exportez les preuves si votre politique impose davantage. Un serveur absent du rapport ne doit pas être considéré conforme.
| Phase | Validation | Condition d’arrêt |
|---|---|---|
| Observation | Source et évaluation cohérentes | Agent déconnecté ou inventaire incomplet |
| Pilote | Installation, redémarrage et transaction métier réussis | Erreur applicative ou durée excessive |
| Extension | Vague suivante approuvée par le responsable | Dépendance ou fenêtre non maîtrisée |
| Changement de source | Correctifs accessibles sans WSUS | Blocage réseau ou catégorie absente |
| Retrait de WSUS | Plus aucun client dépendant, preuves conservées | Postes ou serveurs oubliés |
Moderniser le contrôle avant de retirer la source
Le premier jalon peut être modeste : quelques serveurs visibles, une fenêtre fiable et un test métier reproductible. Retirer WSUS vient ensuite si les dépendances, la bande passante et les exigences de contrôle le permettent.
Pour un parc critique, l’accompagnement doit surtout clarifier les responsabilités, les anneaux, les exceptions et la récupération. Le choix du portail ne remplace pas cette préparation.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →