Di recente mi è capitato di imbattermi in un problema con i Windows Update su dei PC Windows 7 e sui dei Server Windows 2012 R2.

In pratica ho notato che sia i PC che i server non riuscivano a connettersi al server WSUS centralizzato dando l’errore:

Windows could not search for new updates – Error Code 80072EE2

La spiegazione del codice di errore è la seguente:

0x80072EE2 -2147012894 ERROR_INTERNET_TIMEOUT = La richiesta è scaduta.

Dall’Event Viewer vedremo l‘Event ID 25 relativo a questo errore come mostrato nell’immagine sovrastante.

In pratica questo errore è dovuto al fatto che il link web del server WSUS non è raggiungibile e quindi la richiesta va in timeout.

Per risolvere questo problema seguire i workarounds elencati di seguito.

WORKAROUND 1

La prima cosa da verificare sono le impostazioni proxy sul server o sul PC.

Verificare la presenza di un Proxy e quindi la possibilità di raggiungere i siti web Microsoft relativi al Catalog.

Quindi procedere con il workaround 2

WORKAROUND 2

Dopo aver controllato la configurazione del Proxy verificare che il client raggiunga i seguenti link relativi al server WSUS:

http://wsusserver:8530/selfupdate/wuident.cab

http://wsusserver:8530/selfupdate

http://wsusserver:8530/ClientWebService/client.asmx

In caso di WSUS configurato in SSL contattare i seguenti link:

https://wsusserver:8531/selfupdate/wuident.cab

https://wsusserver:8531/selfupdate

https://wsusserver:8531/ClientWebService/client.asmx

Dopo aver verificato la raggiungibilità dei link verificare che la GPO configurata a livello di Domain Controller contenga il link corretto.

Se lato link e lato GPO è tutto Ok ma il client continua a dare lo stesso errore proseguire con il Workaround 3

WORKAROUND 3

Ultima verifica da fare è relativa al Server WSUS e quindi alla configurazione dell’Application Pool di IIS.

Sebbene WSUS possa supportare 100.000 client per server (150.000 client quando si usa Configuration Manager), non è consigliabile avvicinarsi a questo limite.

WSUS implementa una cache interna che recupera i metadati di aggiornamento dal database. Questa operazione è costosa e richiede molta memoria. Può causare il riciclo del pool di applicazioni IIS che ospita WSUS (noto come WSUSPool) quando WSUSPool supera i limiti di memoria privata e virtuale predefiniti.

Quando il pool viene riciclato, la cache viene rimossa e deve essere ricostruita. Non è un grosso problema quando i client sono sottoposti a scansioni delta. Ma se finisci in uno scenario di scansione tempesta, il pool si riciclerà costantemente. E i client riceveranno errori quando si effettuano richieste di scansione, come errori HTTP 503.

Si consiglia di aumentare la lunghezza della coda predefinita e disabilitare sia il limite di memoria virtuale che quello privato impostandoli su 0. IIS implementa un riciclo automatico del pool di applicazioni ogni 29 ore, ping e timeout di inattività, che dovrebbero essere Disabilitato. Queste impostazioni si trovano in Gestione IIS > Pool di applicazioni > scegliere WsusPool e quindi cliccare su Impostazioni avanzate nel riquadro a destra di Gestione IIS.

Di seguito le Impostazioni e le relative configurazioni:

Queue Length: impostare un valore tra 25000 e 40000 (valore predefinito di 1000)
Idle Time-out (minutes): 35 (valore predefinito di 20)
Private Memory Limit (KB): 0 (illimitato, fino al valore predefinito di 1.843.200 KB)
Regular Time Interval (minutes): 35 (per impedire un riciclo e modificato dal valore predefinito di 1740)

Se è tutto OK dovreste avere una configurazione come mostrato nell’immagine sovrastante.

Riavviare l’IIS quindi riprovare la connessione al WSUS eseguendo Check Updates dal client

Il problema dovrebbe essere scomparso lato client e dovremmo vedere sulla console del WSUS il client collegato.