Supporto Tecnico Enterprise : Gianluca Bertelli

Windows Server 2008 - Impossibile installare il Service Pack 2

itentblg — Mon, 12 Oct 2009 02:00:00 GMT

Può capitare che la Service Pack 2 per Windows Server 2008 fallisca la sua installazione per via di una corruzione del deposito degli update, o per la mancanza di alcuni file ritenuti essenziali ai fini dell’installazione. Un effetto collaterale di questa corruzione può essere rappresentato dall’impossibilità di aprire e gesitre i ruoli nella finestra “Server Manager”.

La risoluzione di questa situazione, è abbastanza semplice, si tratta di individuare I file corrotti e sostituirli o eventualmente aggiungerli al deposito nel caso mancassero.

I passi da seguire per la risoluzione sono I seguenti:

Individuare I file oggetto del problema con “System Update Readiness Tool”
Recuperare I file originali
Copiare i file nel deposito degli update

Vediamo in maggiore dettaglio ogni passo.

Individuare

Il tool da utilizzare è scaricabile a questo indirizzo http://support.microsoft.com/kb/947821

Una volta scaricato ed eseguito, esso produrrà un file di log (CheckSUR.log) all’interno della cartella “%SYSTEMROOT%\Logs\CBS\”; questo log è di primaria importanza per il resto della soluzione in quanto contiene l’elenco dei file mancanti e/o corrotti, che dovranno essere sostituiti nei prossimi passi.

Un esempio del log prodotto è il seguente:

=================================
Checking System Update Readiness.
Binary Version 6.0.6001.22375
Package Version 5.0
2009-10-01 11:24
Checking Deployment Packages
Checking Package Manifests and catalogs.
Checking package watchlist.
Checking component watchlist.
Checking packages.
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_80_for_KB967723~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723_server_0~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723_server~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723~31bf3856ad364e35~amd64~~6.0.1.7.mum
Checking component store
Summary:
Seconds executed: 401
Found 4 errors
CBS MUM Missing Total Count: 4
=================================

Recuperare

Il nome del file che sta causando il problema, contiene il numero della KB a cui appartiene, quindi è sufficiente scaricare l’aggiornamento corrispondente per avere una copia corretta del file. Rinominando l’eseguibile da .msu a .cab è possibile accedere ai file mum senza dover installare il pacchetto (installazione che molto probabilmente fallirebbe).

Ogni file .mum, può avere associato un file di catalogo (.cat) con lo stesso nome; sebbene questi tipi di file non siano menzionati nel log del passo precedente, essi vanno sempre copiati assieme ai file .mum.

Bisogna eseguire l’operazione per ogni KB elencata all’interno del log precedente, in modo che al termine di questo passaggio si disponga di tutti I file .mum e .cat necessari per procedere con il punto successivo

Copiare

Questa è la parte che richiede un pò più di lavoro, ma è comunque abbastanza semplice. Si tratta di copiare tutti I file raccolti all’interno della cartella %windir%\servicing\package sostituendo quelli eventualmente già presenti.

Questa cartella di sistema è però bloccata e l’utente, seppur amministratore, non ha i diritti di scrittura, per poter procedere bisogna prendere l’ownership di tale cartella. Una volta presa l’ownership è possibile aggiungere l’utente corrente ed assegnargli i permessi necessari per la copia dei file al suo interno.

Copiati i file, rieseguire nuovamente il punto 1 ed ispezionare il file di log, se nel log non risultano errori è possibile procedere con l’installazione della Service Pack 2.

Nel caso invece in cui compaiano altri file mancanti (possbili nuove dipendenze) ripetere tutta la procedura dall’inizio, fino a che nel log del tool di Readiness verrano riportati errori.

Una nota finale, per non incorrere in futuri problemi legati all’installazione degli aggiornamenti, ricordatevi di riassegnare l’ownership della cartella %windir%\servicing\package al servizio di update (utente NT SERVICE\TrustedInstaller).

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platform Support

Windows Server 2008 - Impossibile raggiungere la seconda scheda di rete se non è specificato il default gateway

itentblg — Mon, 07 Sep 2009 02:00:00 GMT

Una configurazione molto comune per un server è avere più di una scheda di rete, ed essere collegato a più reti simultaneamente nonostante il server non funga da forwarder/router. Un server con questa caratteristica viene etichettato come multihomed.

Un server multihomed è caratterizzato da un’elevata connettività di rete, in quanto può essere connesso simultaneamente a più reti, siano esse Intranet e/o Internet. Questa connessione multipla introduce alcune problematiche di sicurezza, che normalmente non sono presenti in un ambiente con una sola connessione. I servizi che girano in un server multihomed potrebbero essere vulnerabili ad attacchi provenienti dalle diverse reti connesse.

Per ovviare a questo problema l’RFC 1122 (sez 3.3.4.2) specifica due modelli comportamentali per gli host multihomed:

Strong ES Model
Weak ES Model

Nel primo modello l’host scarta un pacchetto in ingresso se il suo indirizzo di destinazione non corrisponde a quello dell’interfaccia in cui è stato ricevuto ed invia un pacchetto IP solamente attraverso l’interfaccia che corrisponde all’IP sorgente del pacchetto. Il modello weak invece è più permissivo, e permette di compiere le azioni inibite dal modello precedente.

Una differenza sostanziale tra I due modelli è nella scelta della scheda su cui inviare un pacchetto, il modello weak tiene conto solamente dell’IP di destinazione mentre il modello strong utilizza anche l’IP sorgente come parametro per la scelta della scheda da utilizzare. Da notare che il modello strong preferisce l’utilizzo di un default gateway per ogni scheda.

In Windows Server 2008 di default è abilitato il modello strong, che aumenta il livello di sicurezza della macchina. In alcune configurazioni particolari la seconda scheda di rete, senza gateway, riceve correttamente i pacchetti ma non invia le risposte per via delle restrizioni di sicurezza introdotte dal modello strong.

Per ovviare a questo inconveniente ci sono due modi:

Aggiungere un default gateway sulle NIC che ne sono prive
Passare dal modello strong al modello weak

Il primo punto è di facile implementazione, mentre per mettere in pratica il secondo punto bisogna utilizzare i seguenti comandi:

netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled
netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled

Per maggiori informazioni, e una dettagliata descrizione degli algoritmi utilizzati nei vari modelli potete fate riferimento al seguente articolo.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Update - Panoramica dei log d’installazione degli aggiornamenti

itentblg — Mon, 31 Aug 2009 02:00:00 GMT

Come abbiamo visto nell’articolo precedente, nei nuovi sistemi operativi il processo di aggiornamento di una macchina è basato su di una tecnica transazionale, che garantisce la corretta installazione di tutti gli aggiornamenti scaricati.

Come accennato, gli eventi di sistema sono la prima fonte di informazione nel caso ci siano problemi durante l’installazione degli aggiornamenti. Le informazioni contenute nella descrizione degli eventi sono però ad alto livello, ovvero a livello di pacchetto.

Con questo articolo vi illustro dove reperire ulteriori informazioni riguardo un’installazione fallita.

I principali posti da cui recuperare le informazioni relative all’installazione dei componenti, oltre agli eventi di sistema, sono:

%windir%\WindowsUpdate.log
%Windir%\logs\CBS.log

Mentre nel caso di errori di installazione al reboot della macchina:

%WinDir%\WinSxS\pending.xml
%WinDir%\WinSxS\poqexec.log

Seguendo l’ordine sopra descritto, si può tracciare una completa attività del processo di aggiornamento, in ordine crescente di dettagli.

Nel log di WindowUpdate troviamo tutta l’interazione con il server di aggiornamento, sia esso WSUS oppure il sito web Microsoft, ed inoltre troviamo lo stato finale dell’installazione come riportato dal servizio CBS. Nel caso di errori specifici all’installazione la sola consultazione di questo file non è sufficiente.

Nel secondo log della lista - CBS.log - troviamo tutte le operazioni effettuate dai componenti CBS, quindi la creazione delle transazioni e la valutazione delle regole di applicabilità. Il log non è “user-friendly” però a volte uno sguardo sommario può dare qualche indicazione in più sull’errore occorso durante l’installazione e fare puntare il dito verso una determinata risorsa (file, registro, permesso, ect.)

Gli ultimi due file sono strettamente legati tra loro, e servono per individuare l’errore quando l’installazione subisce problemi in fase di riavvio della macchina.

Addentriamoci ulteriormente nell’architettura CBS.

Possiamo pensare ad un pacchetto di aggiornamento come una serie/lista di operazioni da effettuare sul sistema; questa lista di operazioni, da eseguire con un ordine ben definito da regole di precedenza e di dipendenza, viene suddivisa in due code differenti:

Coda delle operazioni primitive (Primitive Operations Queue)
Coda delle operazioni avanzate (Advanced Installer Queue)

La prima coda contiene tutte quelle operazioni considerate “facili”, come ad esempio le operazioni sui file o sul registro di sistema; mentre la seconda coda viene riempita con tutte le operazioni che non possono essere modellate come operazioni primitive: ad esempio una modifica alle regole del firewall, l’installazione di una licenza..etc..

Per lo scopo di questo articolo, per semplificare le cose, consideriamo solamente la coda delle operazioni primitive.

Una volta costruita la coda, essa viene passata ad un componente che si occupa di eseguire tutte le operazioni elencate all’interno di una transazione kernel. È frequente che tra tutte queste operazioni alcune non possano essere eseguite durante la sessione di installazione, per i più svariati motivi, primo fra tutti l’accesso a file/risorse attualmente in uso.

Tutte queste operazioni “bloccano” la transazione richiedendo la propria esecuzione in fase di avvio della macchina. Davanti ad una simile richiesta il sistema operativo genera un file XML con il contenuto della coda primitiva (POQ) da eseguire durante il prossimo reboot. Il file generato è pending.xml ed è situato dentro la cartella %windir%\winsxs.

Esempio di file pending.xml:

<PendingTransaction Version="1.0" Identifier="58d5f3e1ca77c80164000000280f4c15">
<POQ>

<BeginTransaction id="TI4.29915082:3359338114:4/Package_for_KB937287" />
<MoveFile source="\SystemRoot\WinSxS\Temp\PendingRenames\b3053de0ca77c80161000000280f4c15 " destination="\SystemRoot\WinSxS\FileMaps\$$_servicing_fc2045b9046cc796.cdf-ms" />
<CreateFile path="\SystemRoot\WinSxS\FileMaps\$$_servicing_version_6.0.6001.18000 " fileAttribute="0x00000000" />
<DeleteFile path="\??\C:\Windows\System32\test.exe" />

</POQ>

Se al prossimo riavvio dovesse capitare un problema, il file verrà rinominato in pending.xml.bad e verrà generato il file poqexec.log all’interno della stessa cartella. Quest’ultimo file è come se contenesse l’indice degli errori occorsi all’interno del file pending.xml.bad. Controllando questo file il più delle volte riusciamo a trovare la specifica operazione primitiva che ha causato la fallita installazione.

Riporto un esempio concreto del file poqexec.log:

1c91429dcbd5e25: 0, 0, 0, 0, StartTime ;
1c91429e0a9e5b1: 0, 0, 0, 0, EndTime ;
1c92edb3b79b5c1: 0, 0, 0, 0, StartTime ;
1c92edb43e8bf82: 0, 0, 0, 0, EndTime ;
1c935d353ff8079: 0, 0, 0, 0, StartTime ;
1c935d3554f2373: 0, 0, 0, 0, EndTime ;
1c948b2d25268d5: 0, 0, 0, 0, StartTime ;
1c948b2d25268d5: 65b, c0190036, 16, 0, DeleteFile ;\??\C:\Windows\System32\test.exe
1c948b2d2787f05: 0, 0, 0, 0, EndTime ;

In caso di errori persistenti, come suggerisce l’articolo KB 949358 è possibile eliminare il file pending.xml per evitare che al successivo riavvio la macchina tenti di eseguire le sempre stesse operazioni che portano al problema.

Ogni errore ha una sua soluzione specifica, ma controllando tutti questi file, possiamo avere maggiori dettagli sugli errori occorsi, ed a volte possiamo anche trovare un work-around per la risoluzione del problema.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Update - TrustedInstaller e l’installazione transazionale

itentblg — Mon, 24 Aug 2009 02:00:00 GMT

Da Windows Vista in avanti è stata rivista gran parte dell’architettura di aggiornamento del sistema operativo. Si è passati da un’installazione “stand-alone” dei singoli aggiornamenti ad un sistema transazionale. Questa tecnica transazionale è molto più robusta e sicura della precedente, in quanto garantisce che il sistema si trovi sempre in uno stato consistente.

In parole più semplici, gli aggiornamenti vengono raggruppati in transazioni, e viene fatto un commit delle operazioni solamente se tutti gli aggiornamenti in una transazione non presentano errori nella propria di installazione. Al contrario se anche un solo aggiornamento fallisce la sua installazione, allora tutta la transazione viene annullata e nessun componente viene aggiornato.

Questa nuova architettura prende il nome di Component-Based Servicing (CBS) , e si basa sul concetto di componente. Un component è un’unità di “cambiamento dello stato del sistema” (file, registry key, settings, risorsa, etc.). Esso possiede un identità ed è trattato come un oggetto atomico. I componenti sono organizzati in deployment che a loro volta sono contenuti all’interno di package, unità di distribuzione. Un componente, così come un deployment ed un pacchetto, può avere delle dipendenze da soddisfare prima della propria installazione.

I principali componenti di questo nuovo sistema sono i seguenti:

Windows Modules Installer (TrustedInstaller.exe, CBS): è il servizio principale che lavora a livello di pacchetto/update ed analizza l’applicabilità di un aggiornamento
Component Servicing Infrastructure (CSI): infrastuttura di base che lavora a livello di deployment e a livello di componente, gestisce l’accesso e l’interazione con lo store dei componenti
Component Store: è formato dalla cartella %WinDir%\WinSxS e da un ramo particolare del registro. Esso è il ripostiglio di tutti i componenti e del loro manifesto (file XML che ne descrive le proprietà e le dipendenze)

In linea generale un pacchetto di aggiornamento viene passato al servizio CBS, che ne valuta l’applicabilità e lo scompatta nei vari deployment. A questo punto ogni deployment viene passato al livello CSI che si occupa di verificare la presenza dei vari componenti, ne controlla le dipendenze ed il loro stato. Infine il componente viene installato sul sistema. Tutte queste operazioni vengono eseguite all’interno di una transazione kernel che ne garantisce la corretta esecuzione.

Negli eventi di sistema vengono loggate tutte le operazioni effettuate, quindi un sguardo agli eventi è sempre il passo base per qualsiasi problema nell’installazione dei componenti. Questi eventi sono autoesplicativi, quindi ometto la loro descrizione. Il provider di tali eventi è Microsoft-Windows-Servicing.

Dopo questa panoramica, che è necessaria per capire la nuova architettura, nel prossimo articolo vi illustrerò dove recuperare maggiori informazioni in caso di errori durante l’installazione di un componente.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

DNS Server – Algoritmi di ordinamento delle risposte

itentblg — Fri, 06 Mar 2009 03:00:00 GMT

Capita spesso, in un server DNS, che per un singolo nome host si abbiano più indirizzi IP corrispondenti. In questa situazione il server DNS restituisce un elenco contenente tutti gli indirizzi associati al nome richiesto in fase di risoluzione.

Quando il DNS ha più record A per un singolo nome, esso applica due algoritmi di ordinamento distinti:

ROUND ROBIN
NETMASK ORDERING

Round Robin

Il primo algoritmo è abbastanza semplice, è un primitive load balancing che in maniera ciclica mette in testa alla risposta sempre un server diverso.
Ad esempio se la lista iniziale è A-B-C, il DNS risponderà con:

A-B-C
B-C-A
C-A-B
A-B-C
...etc...

NetMask Ordering

Il secondo algoritmo, serve per dare priorità alle risorse locali, mettendo in cima alla risposta gli indirizzi che appartengono alla stessa sottorete del client che fa la richiesta.

L’algoritmo utilizza una netmask fissa per individuare la "vicinanza" degli IP, senza tenere conto della netmask dell'IP del client.

Il server utilizza di default una netmask di classe C, che nel caso più semplice, fa si che se un IP della lista ha i primi tre ottetti uguali all'IP del client, allora viene messo in cima alla risposta.

Nel caso di più match positivi, la lista viene sottoposta ulteriormente al Round Robin, sempre però mantenendo il blocco di risorse locali in testa alla risposta.

Riassumendo, il DNS server applica in sequenza questi due algoritmi e ordina la risposta in questo modo:

Risorse locali in Round Robin (se esistono)
Round Robin degli altri record

Come detto, di default è applicata una netmask di classe C (255.255.255.0), ma esiste una chiave per modificare questo comportamento:

[HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LocalNetPriorityNetMask]
type: DWORD
Value: FF -> FFFFFF

Questi sono i valori più comuni:

FFFFFF = 255.0.0.0
FFFF = 255.255.0.0
FF = 255.255.255.0

ma si può settare anche un valore specifico in base alla propria configurazione di rete, utilizzando la logica negata per ricavare il valore della chiave partendo dalla netmask:

netmask (DEC)= 255.255.240.0
netmask (BIN)= 11111111.11111111.11110000.00000000
netmask (HEX)= FF.FF.F0.00

negando la netmask si ottiene il valore della chiave: 00.00.0F.FF

netmask (DEC)= 255.255.252.0
netmask (BIN)= 11111111.11111111.11111100.00000000
netmask (HEX)= FF.FF.FC.00

negando la netmask si ottiene il valore della chiave: 00.00.03.FF

E’ importante sottolineare che il NetMask Ordering non tiene conto delle subnet e dei siti configurati in Active Directory, ma solamente dell'IP del client che fa la richiesta.

Per maggiori informazioni è disponibile la seguente documentazione:

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Estensione della partizione di sistema di Windows Server 2003

itentblg — Mon, 08 Dec 2008 03:00:00 GMT

Durante la fase di installazione di un nuova macchina, si devono fare scelte ben precise sul dimensionamento della partizione di sistema. Può capitare che a posteriori, per ragioni che non erano state prese in considerazione, si debbano rivalutare queste scelte.

Il caso più comune è quello in cui si vuole ripartizionare il disco fisso, aggiungendo o modificando le partizioni esistenti. Nei nuovi sistemi operativi, Windows Server 2008 a Vista sono presenti due comodi comandi nella console di gestione dei dischi:

Shrink
Extend

Il primo comando viene utilizzato per restringere una partizione esistente, liberando spazio che può essere riassegnato ad altre partizioni.

Il secondo comando, invece è utilizzato per ingrandire una partizione. Un requisito necessario per eseguire il comando di estensione è la disponibilità di spazio contiguo non allocato, in coda alla partizione. Per fare un esempio pratico:

Nei nuovi sistemi operativi questi comandi sono utilizzabili su tutte le partizioni esistenti, senza limitazioni di sorta. Gli stessi comandi sono disponibili dalla console tramite il comando diskpart.

Il comando di estensione è presente anche su Windows Server 2003 SP2, ma non può essere utilizzato sulla partizione di sistema. Per ovvi motivi questa partizione, in cui è installato il sistema operativo, non può essere soggetta a questo tipo di operazioni. Esiste però un work-around per aggirare questa limitazione.

Il meccanismo è semplice, basta procurasi il CD di installazione di Vista o Windows Server 2008, e procedere con una finta installazione. Il programma di installazione di questi nuovi sistemi operativi, contiene la nuova versione del tool di partizionamento, che incorpora il comando di estensione.

Durante questa fase d’installazione, il sistema operativo presente sul disco non è attivo, quindi la partizione di sistema è accessibile e modificabile.

Vediamo in dettaglio come procedere:

Boot della macchina con il CD di installazione
Premere un tasto per Iniziare l’installazione
Inserire il codice della licenza a scegliere l’installazione “custom”
Quando viene mostrata la schermata che permette di scegliere la partizione su cui installare il sistema operativo, scegliere le opzioni avanzate. A questo punto comparirà il pulsante che permetterà di effettuare l’operazione di estensione.

Una volta terminato il nuovo layout del disco potete abbandonare l’installazione.

Al successivo riavvio della macchina, il disco avrà il nuovo layout senza nessun tipo di danno alle componenti del sistema operativo.

L’operazione di shrink al contrario non è stata inserita nel programma di installazione.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Cancellare la cronologia degli aggiornamenti in WSUS 3.0 SP1

itentblg — Fri, 31 Oct 2008 02:00:00 GMT

Ciao a tutti, come primo post vado ad illustrarvi una piccola procedura non documentata, per eliminare lo storico delle connessioni di WSUS.

Come ben sapete WSUS si sincronizza con il server di Upstream (o windows update) ad intervalli più o meno regolari per verificare la presenza di nuovi aggiornamenti. Uno storico di questi aggiornamenti è memorizzato all'interno del database e mostrato all'amministratore del sistema nell'apposita maschera. Può capitare che in un server attivo da molto tempo, oppure con un periodo di riposo tra le sincronizzazioni troppo breve, che questo storico cresca troppo velocemente e contenga così tanti elementi che il caricamento della lista rallenti l'esecuzione della console. Conseguentemente una lista così lunga risulta illegibile e pressochè inutile. All'interno della console non esiste un tasto o un parametro che permetta di cancellare o ridurre questo storico (synchronization history); per questo motivo l'unica strada è rapresentata dall'accesso diretto al database di WSUS.

WSUS può essere utilizzato sia con "Windows Internal Database", opzione di default, che con un "Microsoft Sql Server" preesistente. La procedura si compone sostanzialmente di una query in formato standard SQL quindi funzionerà correttamente su entrambe le configurazioni.
Per eseguire le query, chi utilizza un Sql Server potrà usufruire di "Microsfot SQL Server Management Studio"; mentre chi usufruisce di Windows Internal Database potrà utilizzare "Microsoft SQL Server Management Studio Express" oppure il tool da linea di comando "sqlcmd"

La sintassi del comando "sqlcmd" è molto semplice, per eseguire una query sul database di WSUS basta utilizzare i seguenti parametri:

sqlcmd -S STRINGA_DI_CONNESSIONE -E -b -Q "QUERY_DA_ESEGUIRE"

Vediamo come procedere:

Stoppiamo il servizio di WSUS
net stop WSusService
Colleghiamoci all'istanza del database con NOME_SERVER\SQL_NOME_ISTANZA
Dato che "Windows Internal Database" non permette collegamenti remoti, chi utilizza questo database deve usare la seguente stringa di connessione:
\\.\pipe\SQL_NOME_ISTANZA\sql\query
Facciamo una copia di backup del database
Chi usa "sqlcmd" può utilizzare la seguente query:
"BACKUP DATABASE [NOME_DB_WSUS] TO DISK = N’PATH_DOVE_SALVARE.BAK’ WITH NOFORMAT, INIT, NAME = N’WSUS Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM"
Eseguiamo la sequente query:

"DELETE FROM [NOME_DB_WSUS].[dbo].[tbEventInstance] WHERE [EventID]=381 or [EventID]=382 or [EventID]=384 or [EventID]=386 or [EventID]=387"
Riavviamo il servizio di WSUS
net start WSusService

Naturalmente bisogna sostituire con i valori corretti le variabili all'interno dei comandi, vi ricordo i settagi di default:
SQL_NOME_ISTANZA = mssql$microsoft##ssee
NOME_DB_WSUS = SUSDB

Questa procedura elimina tutti i record relativi alla sincronizzazione tra il server WSUS e la sua fonte. Essendo semplice SQL è possibile aggiungere più criteri alla query per discriminare i record da eliminare.

Vi ricordo che l'accesso diretto al database di WSUS non è una procedura supportata ufficialmente, ed in caso di errori si può compromettere l'intera stabilità del sistema di distribuzione degli aggiornamenti.

Per finire vorrei segnalare un importantissima risorsa, alla quale potete trovare le risposte alle domande più comuni, ed i futuri aggiornamenti: WSUS Product Team Blog.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support