Ci sono alcune situazioni in cui i client durante l’aggiornamento tramite WSUS, possono manifestare problemi di performance come l’elevato utilizzo della CPU e/o del disco fisso. Questi problemi sono dovuti generalmente all’elevato numero di update che i client devono valutare.

Per prevenire questo tipo di inconvenienti basta ottimizzare la lista degli update approvati.

Come ben sapete per ogni update è possibile specificare diverse azioni:

  • Approve for Install
  • Approve for removal (se supportato dall’update)
  • Not approved
  • Declined

Quando un client contatta il server WSUS, gli viene restituita una lista di aggiornamenti da controllare; una lista specifica per il suo sistema operativo e per la sua lingua. Il client provvederà a scansionare localmente, tutto l’elenco, e per ogni aggiornamento trovato ne controllerà l’applicabilità.

In questa lista sono presenti tutti gli update sia approvati che non. Gli unici aggiornamenti che non sono inseriti sono quelli nello stato “declined”.

Con questa tecnica, il server WSUS è in grado di aggiornare correttamente il contatore “Needed Count” anche per gli aggiornamenti non approvati.

La regola alla base dell’ottimizzazione è quella di declinare tutti gli aggiornamenti non necessari, per diminuire la dimensione di tale lista.

Con il tempo, possono venire rilasciate diverse versioni di uno stesso update e/o diversi update che sovrascrivono aggiornamenti più datati. Per questo motivo all’interno di WSUS gli aggiornamenti sono organizzati in gerarchie di successione (catene).

Un update può trovarsi in uno di questi stati:

Unico update della gerarchia

 

Superseded

un aggiornamento più recente dello stesso componente è stato rilasciato ed è presente in WSUS

Superseding

Questo aggiornamento essendo più recente sovrascrive un altro aggiornamento

Superseding AND Superseded

Questo aggiornamento non è il più datato, ma nemmeno l’ultimo aggiornamento disponibile

Possiamo immaginare delle catene di aggiornamenti, in cui troviamo, il primo della gerarchia, tanti aggiornamenti nel “mezzo” che sovrascrivo sempre il precedente, ed infine l’ultimo aggiornamento disponibile.

Per esempio questa può essere una catena creatasi col tempo:

image

Un client che installa l’ultimo aggiornamento di una catena (KB N), non necessiterà delle precedenti KB. Tuttavia, anche se non verranno mai installate, tutte le KB sovrascritte presenti nella lista vengono scansionate ugualmente lato client.

Come già detto l’unico modo di eliminare dalla lista un aggiornamento è la sua declinazione.

Quindi a meno di situazioni particolari, il consiglio è di declinare tutti gli aggiornamenti che sono “superseded” e che non sono più necessari a nessun client.

All’interno di WSUS è abbastanza semplice questa operazione, basta aggiungere le colonne “Supersedence” e “Needed Count”, ed ordinare per la prima:

imageTutti gli update che sono in ordine di rilascio gli ultimi di una catena, presentano questa icona:

imageQuesti update dovrebbero essere gli unici “approved” o “not approved”.

Scorrendo ulteriormente la lista troviamo questa icona

image

che simboleggia un aggiornamento che è stato sovrascritto ma non è il primo della catena, quindi sta nel “mezzo”. Questi aggiornamenti dovrebbero essere declinati.

Tutti gli aggiornamenti marcati con l’icona

image

sono i primi update di una catena, quindi posseggono almeno 2 aggiornamenti che li sovrascrivono. Questi aggiornamenti dovrebbero essere declinati.

Un aggiornamento senza icona, rappresenta una catena di un solo elemento, quindi l’aggiornamento non deve venire declinato.

IMPORTANTE: prima di declinare un aggiornamento, bisogna assicurarsi che esso non sia più necessario a nessun computer. Per far questo bisogna controllare il contatore “Needed Count”, se il valore è pari a 0 allora è possibile declinarlo senza problemi. Nel caso l’update sia nello stato “superseded”, bisogna prima approvare l’update “superseeding” ed aspettare un ciclo di aggiornamento di tutti i client. Quando tutti i client avranno installato l’aggiornamento più recente, e quindi il contatore “Needed Count” del update “superseded” avrà raggiunto il valore 0, esso potrà essere declinato.

Tutta questa logica, è in linea di massima la “best practice” da seguire per un ottimizzato utilizzo del server WSUS, va sottolineato però che ogni update andrebbe valutato singolarmente.

Riassumendo, possiamo considerare un WSUS in uno stato ottimizzato, quando sono “approvati” o “non approvati” solamente gli update al top della gerarchia e quelli che non hanno nessun aggiornamento che li sovrascrive (senza icona). Tutto questo a meno di esigenze particolari, in cui ad esempio un aggiornamento datato serve ad alcune macchine/gruppi particolari.

Vi ricordo che questa operazione non può essere eseguita in automatico, ma va effettuata manualmente e periodicamente. Inoltre periodicamente va effettuato il “clean up” del server tramite l’apposito wizard; esso provvederà a cancellare dal database e dal disco fisso tutti gli aggiornamenti declinati che non servono a nessun client (contatore “needed” pari a 0).

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support