J'ai un frontal connecté sur internet et j'exporte les MAJ manuellement vers d'autres WSUS sur des réseaux privés non raccordés au net.
Au moins, ça ça fonctionne merci Microsoft.
De base la console MMC de WSUS a tendance à perdre la connexion avec le processus IIS WSUS, logiquement vous l'avez tous expérimenté

La solution préconisée est d'augmenter la taille de mémoire alloué à cette appli IIS, bon au bout d'un moment on se rend compte qu'il vaut mieux passer à mémoire illimitée ...

A partir de ce moment la console est "plus stable".
Cependant quelle ne fut pas ma surprise de recevoir une alerte d'occupation d'espace disque élevé sur ces VM :
Partition système C:\ 80 Go -> 1.6 Go libres
Partition WSUS d:\ 1 To -> ok occupé normalement par les MAJ KB.
Je pars donc en quête de la raison d'occupation de la partition système de la VM, non sans avoir auparavant étendu ce disque depuis l'hyperviseur !
Me voici donc avec une partition de 127 Go, ce qui correspond à la valeur par défaut proposée par Hyper-V lors de la création de hdd virtuels.
Sauf que j'ai résolu la conséquence mais pas la cause, alors je cherche. Et je trouve très rapidement le coupable :

Windows Internal Database.
Après lecture je comprends à peu près de quoi il retourne, je tente de faire une maintenance interne à WSUS

mais cela se termine invariablement par un échec quelle que soit la VM.

D'un point vue RAM, je commence à être limité car les VM sont gourmandes (un exemple : )

mais l'hyperviseur n'a plus de marge de manoeuvre car d'autres VM sont en allocation dynamique de ressources et ... on est au bout

Alors oui les serveurs physiques sont un peu légers en RAM, je dispose d'un large stock de barrettes mais allouer autant de RAM n'est pas, à mon sens, une bonne solution. De même que pour l'espace de stockage j'ai pas mal de To de libres mais je trouve ça trop facile d'allouer un espace disque de dingue. Surtout qu'il reste le souci des i/o de cette VM qui impacte quand même pas mal l'hyperviseur.
Donc je me tourne vers la réduction de la taille de la BDD de WSUS.
Si on ne peut pas le faire en graphique pas de souci car Microsoft propose une script PowerShell.
Oui mais (la blague)


ha bah ça c'est du conseil dites donc

Pas grave, internet est plein de retours d'expérience d'autres admins.
Il est conseillé de manipuler directement la BDD.
Installation d'un gestionnaire SQL léger pour faire de la maintenance, "un peu comme sous MS Access" quand on compresse la BDD


Sauf que ça ne fait ... strictement rien quelle que soit l'option choisie (testé sur 4 VM WSUS)

Bon et bien nous y voilà, je vais attendre un plantage définitif de WSUS pour tout réinstaller, j'ai lu un article qui suggère d'installer préalablement un serveur MS SQL, ce qui permet de *choisir* l'endroit où sera stockée la BDD qui servira à WSUS.
Donc il semblerait que pour faire tourner un WSUS il faille au préalable :
- installer un serveur SQL dédié
- avoir une partition pour les BDD
- avoir une partition pour les MAJ téléchargées par WSUS
Cela ne me dérange pas outre mesure car j'avais déjà des VM avec SQL server simplement pour des solutions antivirales ...
Si vous avez des retours d'expérience, comme toujours je prends
