Upgrade_WSUS

Da molti anni il servizio WSUS (Windows Server Update Services, ex SUS, Software Update Services) rappresenta il modo più utilizzato nelle aziende per gestire gli aggiornamenti dei Computer Windows.

Il prodotto esiste dall’anno 2005 e a partire da Windows Server 2008 R2 è diventato un Ruolo installabile sui Server.

WSUS gestisce il catalogo degli aggiornamenti per le componenti di Windows e degli altri prodotti Microsoft, il ciclo di approvazione, la messa a disposizione in rete locale, ma non ha alcun controllo su quando e come tali aggiornamenti vengono applicati sui Computer destinatari: pur con questo limite, WSUS viene preferito perché gratuito e più facile da gestire rispetto al System Center Configuration Manager, prodotto che invece può forzare e controllare centralmente l’invio degli aggiornamenti.

Problemi legati al servizio WSUS

Fin dalle prime versioni, il servizio WSUS ha richiesto un significativo spazio disco per funzionare, almeno 100 GB. Nel tempo la situazione è ulteriormente peggiorata principalmente con l’aumentare dei prodotti Microsoft gestiti da WSUS e soprattutto a causa della frequenza del rilascio degli aggiornamenti, principalmente per questioni legate alla Sicurezza.

Quello che si osserva dal Monitoraggio è un aumento costante nel tempo dello spazio disco occupato da WSUS:

WSUS1

Lo spazio disco è occupato dagli aggiornamenti che vengono approvati (manualmente o automaticamente) dalla Console di WSUS.

Inoltre si manifesta un problema ancora più grave: il servizio WSUS risponde nel tempo sempre più lentamente fino ad arrivare, anche nel giro di pochi mesi, alla Console che si disconnette ad intermittenza o non risponde più ai comandi e, ancora più grave, ai Client che non riescono più a scaricare gli aggiornamenti da applicare.

Questo secondo fenomeno è dovuto alla gestione non ottimizzata del database che WSUS utilizza per memorizzare tutte le informazioni sugli aggiornamenti e sui Client che stanno utilizzando il suo servizio.

Dalle ultime versioni di WSUS il Database utilizzato di default è WID (Windows Internal Database): nel path C:\Windows\WID\Data è possibile trovare il database di WSUS. Curiosamente il Database ha ancora il vecchio nome del prodotto, ovvero SUSDB !

WSUS2

È importante tenere controllata la dimensione del database SUSDB in quanto quando questo cresce già sopra i 7…8 GB si cominciano a riscontrare i primi problemi a WSUS.

Cause della crescita del Database

Ci sono tre cause principali che provocano la crescita del Database SUSDB:

  • La tabella tbEventInstance che raccoglie eventi di sistema
  • La mancata dismissione degli aggiornamenti superati da altri più nuovi (Superseeded) e di quelli per i processori Itanium
  • La mancata pulizia di WSUS

La tabella tbEventInstance può arrivare a contenere un numero molto elevato di righe in mancanza di una pulizia periodica di WSUS. Qui sotto si vede una situazione normale con qualche migliaio di righe:

WSUS3

Un fattore sicuramente importante da considerare è la dismissione degli aggiornamenti superati (Superseeded) e di quelli per i processori Itanium (sempre che uno non disponga in casa della tecnologia Itanium !): purtroppo WSUS non offre un modo semplice per effettuare questa operazione, conviene ricorrere a script Powershell.

Solo dopo aver esplicitamente dismesso (Declined) questi aggiornamenti inutili, verrà liberato sia lo spazio nel database e soprattutto lo spazio disco occupato da questi dati !

La pulizia del WSUS può essere effettuata sia dalla Console con il Server Cleanup Wizard o via script Powershell:

WSUS4

Per un WSUS sempre efficiente

Per avere un servizio WSUS sempre efficiente è quindi necessario:

  • Tenere monitorati sia la crescita dello spazio disco sia quella del database SUSDB
  • Schedulare degli script Powershell per la dismissione (Decline) degli aggiornamenti superati
  • Schedulare degli script Powershell per la pulizia del WSUS, con ricompattazione del Database SUSDB e liberazione dello spazio disco occupato dagli aggiornamenti

Solo così è possibile contenere lo spazio disco occupato da WSUS sotto i 100 GB ed un database sempre efficiente sotto i 5 GB.

Alessandro Romboli

Alessandro Romboli

System Integration Consultant at Würth Phoenix
My name is Alessandro and I joined Würth-Phoenix early in 2013. I have over 20 years of experience in the IT sector: For a long time I've worked for a big Italian bank in a very complex environment, managing the software provisioning for all the branch offices. Then I've worked as a system administrator for an international IT provider supporting several big companies in their infrastructures, providing high availability solutions and disaster recovery implementations. I've joined the VMware virtual infrastructure in early stage, since version 2: it was one of the first productive Server Farms in Italy. I always like to study and compare different technologies: I work with Linux, MAC OSX, Windows and VMWare. Since I joined Würth Phoenix, I could also expand my experience on Firewalls, Storage Area Networks, Local Area Networks, designing and implementing complete solutions for our customers. Primarily, I'm a system administrator and solution designer, certified as VMware VCP6 DCV, Microsoft MCP for Windows Server, Hyper-V and System Center Virtual Machine Manager, SQL Server, SharePoint. Besides computers, I also like photography, sport and trekking in the mountains.
Tags: , ,