Déploiement de Azure Update Management Center (actuellement en preview)

Jusqu’à encore il y a quelques années, nous déployions tous les composants applicatifs ou métiers directement sur nos infrastructures… Mais aujourd’hui de plus en plus de client ont accepté le cloud comme levier de développement. Ce qui veut aussi dire que de nombreuses entreprises se retrouvent aujourd’hui avec des infrastructures hybrides : certaines VM vont parfois être créées dans votre datacenter on-prem et d’autre fois vous allez les créer directement chez votre fournisseur de Cloud.

Mais alors comment mettre à jour toutes ces machines virtuelles ?

Évidemment dans mon scénario, je m’intéresse surtout au VM Windows Server. En général, vous allez utiliser WSUS pour mettre à jour votre parc. Dans ce cas où allons-nous pouvoir le déployer ? Plusieurs possibilités s’offrent à nous.

Ne perdez pas trop de temps sur mon schéma l’objectif était simplement d’illustrer mon article. 🙂

WSUS uniquement On-Prem ?

Vous utilisez probablement déjà cette approche : vous avez installé 1 (ou plusieurs) serveur WSUS localement dans votre datacenter. Cette approche fonctionne très bien pour gérer le déploiement des mises à jour depuis des années pour votre datacenter.

En revanche, si vous utilisez ce même serveur WSUS pour vos serveurs dans le Cloud cela signifie que vos VM dans Azure vont devoir récupérer depuis votre infrastructure on-prem une copie de tous vos patchs et KB. C’est faisable mais ce n’est pas le mieux car vous allez potentiellement sur-consommer votre lien réseau qui connecte votre datacenter au Cloud (que ce soit via VPN S2S ou ExpressRoute) et donc entraîner un coût additionnel. 😐

WSUS uniquement dans le Cloud ?

D’un autre côté, si on positionne notre serveur WSUS dans le Cloud : nos updates sont disponibles au plus près de nos serveurs dans Azure mais nous devrons encore utiliser le lien réseau pour récupérer ces KB on-premises. Cela peut fonctionner mais on aura toujours besoin d’utiliser la bande passante de notre lien privé entre les 2 mondes : on-prem et Cloud.

Alors que faire ?

Installation de 2 WSUS ?

Alors oui, on peut installer 2 WSUS : 1 qui gère la partie on-prem et 1 qui s’occupe de la partie Cloud. Cela suppose que l’on est capable de faire la différence entre les serveurs qui se trouvent dans l’une ou l’autre zone. C’est faisable mais est-ce optimal ? 🤨

Nous aurons donc besoin de 2 définir – à minima – 2 configurations GPO différentes pour paramétrer nos 2 serveurs WSUS. Mais surtout : nous allons consommer 2 fois l’espace de stockage nécessaire pour stocker toutes les updates qui nous sont envoyées !

Et n’importe qui ayant déjà utilisé un WSUS sait que ce stockage peut vite représenter plusieurs centaines de Go/To selon les OS que vous avez sélectionné. Stockage que vous allez donc consommer 2 fois et surtout que vous allez payer dans Azure ! Là encore, ce n’est pas optimal en termes de coût (mais ça reste faisable).

En fait, le plus logique de distinguer les 2 scénarios. 🤯

On conserve notre WSUS pour gérer l’infrastructure on-prem. Dans ce cas, nous l’avons probablement déjà et la GPO qui permet de définir l’heure et le manière dont on va gérer les updates et les éventuels redémarrages est également configurée.

• D’ailleurs, nous avions déjà eu l’occasion d’aborder lors de mon précédent article où j’avais expliqué comment installer et configurer WSUS dans Windows Server 2019 – voir mon précédent article en cliquant sur ce lien ;

D’ailleurs utiliser WSUS pour gérer la partie Cloud est dommage puisque les services Windows Updates sont opérés par l’infrastructure cloud de Microsoft.

Utilisation de Update Management Center (preview)

Heureusement, il existe d’autres outils pour gérer le patching de nos serveurs dans le Cloud : nous allons utiliser Update Management Center (attention au moment où j’écris cet article la solution n’est pas encore GA). 🤯

Le principe est simple : cette solution va nous permettre de remplacer le WSUS IaaS que nous aurions déployé par une solution SaaS qui sera capable de piloter et suivre le déploiement des patchs de nos serveurs.

L’intérêt étant que cette solution est capable, grâce à l’agent MMA déployé sur nos VM, de gérer à la fois des serveurs Windows mais également Linux (avec les gestionnaires de paquets les plus connus du marché).

Par défaut, nous allons retrouver la liste de toutes nos VM. On voit que pour l’instant elles ne sont pas gérées par la solution. Nous allons remédier à ça : sélectionnez toutes les VM puis cliquez sur le bouton tout en haut Update settings.

Dans la fenêtre ci-dessous, vous pouvez omettre de cocher l’option Hotpatch. Cette fonctionnalité n’est compatible qu’avec Windows Server 2022 Datacenter – Edition Core (ce n’est pas mon cas dans cet exemple). Ensuite, sélectionnez toutes les VM que vous souhaitez prendre en charge (à priori toutes ?).

Après quelques instants, allez donc avoir un statut sur l’ensemble de vos VM afin de savoir quelles sont celles qui sont actuellement à jour ou non. 😮

Si je clique sur une VM en particulier pour obtenir plus d’informations, nous retrouvons alors les détails précis des KB qui sont actuellement manquantes pour cette VM en particulier.

A ce moment-là, si je le souhaite j’ai plusieurs actions possibles (notamment grâce au menu supérieur) :

• On-time update : cela me permet en 1 seul clic de forcer l’application des mises à jour sur cette VM en particulier ;
• Schedule updates : cette option me permet de définir des plages horaires / moment où je vais pouvoir appliquer les updates mais également potentiellement autoriser un redémarrage d’une VM si une KB le nécessite (c’est un peu le pendant de la GPO que vous avez configuré dans votre WSU – version SaaS) ;

Autres éléments intéressants si vous souhaitez aller plus loin :

• Il est possible d’utiliser une Azure Policy pour forcer enrôlement de nos VM à Azure Update Management Center ;

• La solution est encore en preview mais il sera également possible d’utiliser cette solution pour nos VM/serveurs qui seraient on-prem ; 😉

Cette nouvelle solution n’en est encore qu’à ses débuts (en tout cas au moment où j’écris cet article) – mais vous pouvez vous rendre sur la doc officielle en suivant ce lien.