WSUS (feat. quelle blague).

[Ryu_wm]

Depuis peu j'administre un certain nombre de WSUS qui tournent sous Windows 2019 (des VM en fait).
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

[dsebire]

hello,

tes index sur la base WSUS doivent etre complètement en vrac.
ya un script dispo chez crosoft pour reindexer la base.
en général c'est suffisant pour que le script de maintenance passe

[Ryu_wm]

Je pense que c'est ça.
https://deployadmin.com/2019/06/14/re-i ... s-de-wsus/

pour des serveurs qui ont 1 mois de fonctionnement je trouve que ce n'est pas sérieux d'avoir ce type de dysfonctionnement.

vais tester

//edit : 404 chez MS

pour les autres : https://learn.microsoft.com/en-us/sql/t ... s=cs1-bash
https://gist.github.com/emnavarro02/0ff ... 732fd73aa8

Code : Tout sélectionner

This sample T-SQL script performs basic maintenance tasks on SUSDB  
1. Identifies indexes that are fragmented and defragments them. For certain  
   tables, a fill-factor is set in order to improve insert performance.  
   Based on MSDN sample at http://msdn2.microsoft.com/en-us/library/ms188917.aspx  
   and tailored for SUSDB requirements  
2. Updates potentially out-of-date table statistics.  
******************************************************************************/  
  
   
  
USE SUSDB;  
GO  
SET NOCOUNT ON;  
  
   
  
-- Rebuild or reorganize indexes based on their fragmentation levels  
DECLARE @work_to_do TABLE (  
    objectid int  
    , indexid int  
    , pagedensity float  
    , fragmentation float  
    , numrows int  
)  
  
   
  
DECLARE @objectid int;  
DECLARE @indexid int;  
DECLARE @schemaname nvarchar(130);   
DECLARE @objectname nvarchar(130);   
DECLARE @indexname nvarchar(130);   
DECLARE @numrows int  
DECLARE @density float;  
DECLARE @fragmentation float;  
DECLARE @command nvarchar(4000);   
DECLARE @fillfactorset bit  
DECLARE @numpages int  
  
   
  
-- Select indexes that need to be defragmented based on the following  
-- * Page density is low  
-- * External fragmentation is high in relation to index size  
PRINT 'Estimating fragmentation: Begin. ' + convert(nvarchar, getdate(), 121)   
INSERT @work_to_do  
SELECT  
    f.object_id  
    , index_id  
    , avg_page_space_used_in_percent  
    , avg_fragmentation_in_percent  
    , record_count  
FROM   
    sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'SAMPLED') AS f  
WHERE  
    (f.avg_page_space_used_in_percent < 85.0 and f.avg_page_space_used_in_percent/100.0 * page_count < page_count - 1)  
    or (f.page_count > 50 and f.avg_fragmentation_in_percent > 15.0)  
    or (f.page_count > 10 and f.avg_fragmentation_in_percent > 80.0)  
  
   
  
PRINT 'Number of indexes to rebuild: ' + cast(@@ROWCOUNT as nvarchar(20))  
  
   
  
PRINT 'Estimating fragmentation: End. ' + convert(nvarchar, getdate(), 121)  
  
   
  
SELECT @numpages = sum(ps.used_page_count)  
FROM  
    @work_to_do AS fi  
    INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id  
    INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id  
  
   
  
-- Declare the cursor for the list of indexes to be processed.  
DECLARE curIndexes CURSOR FOR SELECT * FROM @work_to_do  
  
   
  
-- Open the cursor.  
OPEN curIndexes  
  
   
  
-- Loop through the indexes  
WHILE (1=1)  
BEGIN  
    FETCH NEXT FROM curIndexes  
    INTO @objectid, @indexid, @density, @fragmentation, @numrows;  
    IF @@FETCH_STATUS < 0 BREAK;  
  
   
  
    SELECT   
        @objectname = QUOTENAME(o.name)  
        , @schemaname = QUOTENAME(s.name)  
    FROM   
        sys.objects AS o  
        INNER JOIN sys.schemas as s ON s.schema_id = o.schema_id  
    WHERE   
        o.object_id = @objectid;  
  
   
  
    SELECT   
        @indexname = QUOTENAME(name)  
        , @fillfactorset = CASE fill_factor WHEN 0 THEN 0 ELSE 1 END  
    FROM   
        sys.indexes  
    WHERE  
        object_id = @objectid AND index_id = @indexid;  
  
   
  
    IF ((@density BETWEEN 75.0 AND 85.0) AND @fillfactorset = 1) OR (@fragmentation < 30.0)  
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';  
    ELSE IF @numrows >= 5000 AND @fillfactorset = 0  
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 90)';  
    ELSE  
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';  
    PRINT convert(nvarchar, getdate(), 121) + N' Executing: ' + @command;  
    EXEC (@command);  
    PRINT convert(nvarchar, getdate(), 121) + N' Done.';  
END  
  
   
  
-- Close and deallocate the cursor.  
CLOSE curIndexes;  
DEALLOCATE curIndexes;  
  
   
  
  
IF EXISTS (SELECT * FROM @work_to_do)  
BEGIN  
    PRINT 'Estimated number of pages in fragmented indexes: ' + cast(@numpages as nvarchar(20))  
    SELECT @numpages = @numpages - sum(ps.used_page_count)  
    FROM  
        @work_to_do AS fi  
        INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id  
        INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id  
  
   
  
    PRINT 'Estimated number of pages freed: ' + cast(@numpages as nvarchar(20))  
END  
GO

[Ryu_wm]

aie, passe pas avec SQLCMD



alea jacta est (après sauvegarde bdd)

[Ryu_wm]

plop, 90 minutes après



mais ...



pas mieux.

[Ryu_wm]

Bon, et bien maintenant on attaque en dur, je vais voir si je peux limiter la taille de la BDD malgré que sa taille est déjà au delà de la limite que je souhaite fixer. Dommage on ne peut pas changer l'emplacement des fichiers, ça aurait été excellent.



bon ben échec, requête time out.

[dsebire]

le scritp n'est pas fait pour faire le ménage mais pour refaire les index de la base pour conserver des perfs "correctes"
du coup, faut faire le ménage après (soit avec l'autre script SQL, soit avec par la console comme tu as fait au début)
cette fois le nettoyage ne devrait plus planter

normalement, ça devrait faire de la place dans la base et donc tu pourras ensuite lancer un shrink sur le fichier.

tu synchronise quoi comme produit/classifications ? ça joue beaucoup aussi !

[gizmo78]

faut pas tout cocher c'est ça?

[Ryu_wm]

la réindexation n'a pas permis au script de "nettoyage" de fonctionner correctement.
Mais via le gestionnaire SQL j'ai pu demander que le moteur de BDD consomme moins de RAM.
Conjointement à une réduction des ressources utilisables pas IIS/WSUS il reste un pouillème de ressources disponibles sur la VM
Depuis la console MMC/WSUS l'option de nettoyage en ne prenant qu'un truc à la fois a fonctionné, sauf pour la première option, suppression des trucs inutiles justement :/

tu synchronise quoi comme produit/classifications ? ça joue beaucoup aussi !

KB Win 7 Pro x64, Win 10 Pro/enterprise x64 (>=1909 car on part de loin), Office 2016 x86 x64, Server 2019
Plus quelques fioritures MS comme .Net framework.

Bientôt j'aurais réussi à éradique tous les postes en Win7 mais il m'en reste encore...

[dsebire]

ok pour les produits.
quelles classifications ?
si t'as les drivers sélectionnés, cherche pas plus loin.

[Ryu_wm]

pardon "classification" là je ne vois pas ?
pas de pilotes, notre parc n'est pas homogène et je ne veux pas avoir à gérer des dysfonctionnements suite à maj de pilotes (comme avec le pc portable avec lequel j'écris qui vient de perdre le Wifi suite à maj, obligé de désinstaller pilote et matériel et redécouvrir).

J'ai fait une sélection de produits, je regarde (pour l'instant) régulièrement quels PC ont besoin de quelle maj ou alors ce qui m'est proposé en MAJ critiques/sécu, je fais une recherche sur 'ARM' je refuse, je fais des recherches diverses comme "Windows 11" ou "Skype business" ou "Sharepoint server" et d'autres et je refuse, je ne laisse passer que ce que j'ai annoncé plus tôt.

Du fait que les machines des réseaux privés n'avaient jamais vu une MAJ depuis ... le SP1 de Win7, ou alors j'ai un réseau qui il y a encore 3 ans avait des serveurs sous 2000 que j'ai passé à 2012R2 puis 2019 il y a quelques mois. Bref, j'ai un total de téléchargement de 60 Go.
L'export/import s'est bien passé, j'ai 2 frontaux raccordés à internet, un des deux est malade l'autre se content de planter sa console mmc.

[dsebire]

ya un second onglet dans les options de synchro

celui par défaut c'est produits, ya classifications juste à coté.

[Ryu_wm]

ha bah merci
là je suis en mission et quand je rentre je suis en congés, ne verrai ça qu'à compter de début octobre (premiers congés de l'anné je prends tout septembre).

//edit

ha bah si, j'y suis passé d'après ce que je lis là https://www.it-connect.fr/wsus-classifi ... 0-choisir/
car j'ai pris soin pour Win10 de ne prendre qu'à partir de 1909 et pas 1503 par exemple, et comme on est en Enterprise, on doit avoir le Long Term Service, pareil pour les language packs, FR uniquement.

me souvenais plus.