Windows 10 1607 e WSUS
Sui sistemi con Windows 10 versione 1607 (Anniversary Update) può accadere che questi non riescano a sincronizzarsi con il server WSUS per scaricare gli aggiornamenti. Le cause di questo problema possono essere molteplici e i comportamenti i più disparati, può infatti capitare che nessun client riesca a sincronizzarsi, che solo alcuni client riescano a sincronizzarsi o addirittura che alcuni client che non riescono a sincronizzarsi talvolta riescano a farlo.
In ogni caso si tenga presente che talvolta il blocco della sincronizzazione può generare sul client delle situazioni inconsistenti che richiedono il reset dei componenti di Windows Update, a riguardo si veda il mio post Windows 10 script per il reset del Windows Update Client.
Di seguito analizzeremo le varie cause che possono portare alla mancata sincronizzazione con un server WSUS evidenziati anche nel thread Windows 10 Anniversary Update (1607), sui forum Microsoft dedicati a WSUS, valutando per ogni scenario tipico quali possono essere le operazioni da eseguire per tentare di ripristinare la funzionalità della sincronizzazione.
Scenario 1: WSUS 3.0 SP2 su WS08R2 SP1 o su WS2012/R2 senza le opportune patch non riesce a scaricare i file ESDs
Di questo scenario Steve Henry [MSFT] nel thread Windows 10 Anniversary Update (1607), sui forum Microsoft dedicati a WSUS, riporta quanto segue:
1. WSUS 3.0 SP2 on WS08R2 SP1 (or unpatched WS12/R2) cannot download ESDs
This is by design. WSUS 3.2 cannot sync or distribute ESDs, and WS12/R2 can only do so if both KB3095113 and KB3159706 are installed on the machine, and all necessary post-install steps from KB3159706 have been followed. As folks have noted, these post-install steps [and the general way that this update was released] caused unnecessary pain and confusion. We’ll choose a less disruptive strategy for future WSUS updates.
[Friday, August 26, 2016 10:09 PM]
Io avevo discusso di questo scenario nei post Supporto di Windows 10 in WSUS e Mancato avvio della console di WSUS dopo istallazione KB3159706.
In sintesi per eseguire gli aggiornamenti di client Windows 10 occorre un WSUS su WS2012 o successivo, inoltre nel caso di WS2012/R2 occorre installare le seguenti:
- KB3095113 Update to enable WSUS support for Windows 10 feature upgrades
- KB3159706 Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2
Si veda inoltre la KB3194588 “0xc1800118” error when you push Windows 10 Version 1607 by using WSUS che descrive come risolvere un’eventuale incoerenza nel database di WSUS relativa agli aggiornamenti criptati basati su file ESD. A riguardo si veda anche il post Steps to resolve error 0xc1800118.
Se WSUS è installato su Windows Server 2012 R2 potrebbe essere necessario aggiungere tramite IIS Admin nella virtual directory Content del sito Amministrazione di Windows Server Update i seguenti Tipi Mime
- Mame Extention: = .esd con MIME type: application/vnd.ms-cab-compressed
- Mame Extention: = .msu con MIME type: application/octet-stream
Scenario 2: I client con Windows 10 1607 (Anniversary Update) non riescono ad installare Cumulative Updates bloccando l’intero processo di aggiornamento
Circa questo scenario Steve Henry [MSFT] nel thread Windows 10 Anniversary Update (1607), sui forum Microsoft dedicati a WSUS, riporta quanto segue in vari post successivi
2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates
This is a bug in the Windows client that will be fixed in an upcoming cumulative update. In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it. The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you’ve waited several days and haven’t seen any download success in that time.
[Friday, August 26, 2016 10:09 PM]
To clarify, scenario #2 is a problem with the Windows Update client when it downloads from WSUS, and it affects all updates (not just cumulative). Service crashes are expected when this occurs; however, because it is nondeterministic, the download should eventually succeed. Alternatively, you can have your clients scan against Windows Update directly, or download and install directly from the Microsoft Update Catalog. A fix is scheduled for September’s Patch Tuesday (9/13). Given the bootstrapping issue that some have mentioned, you may want to deploy the September cumulative update directly to expedite resolution.
[Tuesday, August 30, 2016 9:08 PM]
there is a new feature in 1607 called Dual Scan that is intended to allow you to connect to Windows Update for Business and still get third-party/other updates from WSUS as needed. This mode automatically goes into effect when WU for Business policy is enabled and the machine is configured to be managed by WSUS–we wanted to avoid creating a whole new policy for this scenario, so we used a combination of existing policies.
The confusion came when folks were [reasonably] using the Defer Upgrades setting in a WSUS environment. Running 1511, there is no impact; however, as soon as you upgrade to 1607 with these settings active, your machine begins scanning both WU and WSUS.
In short, this is a known issue, and we’ll be shipping a patch to the client to correct it.
[Thursday, September 22, 2016 10:35 PM]
On 1607 (after successful upgrade), you’re seeing 0% downloaded–this IS a known issue, and it is patched on the WU client with the September monthly update.
[Saturday, October 08, 2016 1:19 AM]
Quindi sintetizzando la problematica del mancato aggiornamento dei client Window 10 versione 1607 è dovuta alla funzionalità Dual Scan introdotta appunto nella Anniversary Update che esegue la connessione sia al server WSUS che ai server internet che erogano il servizio Windows Update for Business (a riguardo si veda Manage updates using Windows Update for Business).
In questa situazione i client non riescono a sincronizzarsi o impiegano diversi tentativi per riuscirci (ad esempio una temporanea mancanza di connessione a Internet potrebbe permettere la corretta sincronizzazione con WSUS).
I client su cui sia presente l’aggiornamento cumulativo del 29 settembre 2016 per Windows 10 1607 (KB319449) invece non dovrebbero avere problemi a sincronizzarsi infatti nell’elenco delle migliorie e delle correzioni disponibile al September 29, 2016 — KB3194496 (OS Builds 14393.222) viene riportato:
Improved reliability of the Windows Update Agent, shared drives, virtual private network (VPN), clustering, HTTP downloads, Internet Explorer 11, Hyper-V platform, multimedia playback, and Microsoft Edge.
Ciò significa che per ovviare al problema di sincronizzazione si potrebbe pensare di aggiornare i client con Windows 10 versione 1607 tramite Windows Update o di installare almeno la KB3194496 e poi mettere a dominio i client e gestire quindi gli aggiornamenti tramite WSUS.
In alternativa è possibile disabilitare la funzionalità di Dual Scan introdotta nella Anniversary Update impostando le seguenti due Group Policy:
Configurazione Computer /Modelli Amministrativi / Componenti di Windows / Windows Update / Non connetterti a percorsi Internet di Windows Update impostandola su Attivata.
Di seguito la descrizione della Group Policy:
Anche se Windows Update è configurato per ricevere gli aggiornamenti da un servizio di aggiornamento Intranet, periodicamente recupererà informazioni dal servizio Windows Update pubblico per consentire future connessioni a Windows Update e ad altri servizi come Microsoft Update o Windows Store.
Abilitando questo criterio, si disabilita tale funzionalità, pertanto la connessione a servizi pubblici come Windows Store potrebbe smettere di funzionare.
Nota: questo criterio si applica solo quando il computer è configurato per la connessione a un servizio di aggiornamento Intranet mediante il criterio “Specifica il percorso del servizio di aggiornamento Microsoft nella rete Intranet”.
Configurazione Computer /Modelli Amministrativi / Componenti di Windows / Windows Update / Non includere i driver con gli aggiornamenti di Windows impostandola su Attivata.
Di seguito la descrizione della Group Policy:
Abilita questo criterio per non includere i driver con gli aggiornamenti qualitativi di Windows.
Ovviamente impostando il blocco all’accesso a server di Windows Update i client non potranno più eseguire la verifica degli aggiornamenti manuale sfruttando Windows Update e se si tenterà di eseguire tale verifica si riceverà un errore.
Se si desidera utilizzare ancora BITS per la distribuzione degli aggiornamenti è possibile impostare la Group Policy Configurazione Computer /Modelli Amministrativi / Componenti di Windows / Ottimizzazione recapito / Modalità download impostandola su Bypass per Windows 10 versione 1607 o su HTTP per Windows 10 versione 1511.
Di seguito la descrizione della Group Policy:
Specifica il metodo di download che Ottimizzazione recapito può usare nei download di aggiornamenti di Windows, app e aggiornamenti di app. Di seguito sono elencati i valori supportati: 0=solo HTTP, nessun peering. 1=HTTP misto con peering nella stessa NAT. 2=HTTP misto con peering in un gruppo privato. Per impostazione predefinita, il peering avviene tra i dispositivi nello stesso sito di Active Directory (se presente) o nello stesso dominio. Quando questa opzione è selezionata, il peering attraversa le NAT. Per creare un gruppo personalizzato, usa l’ID gruppo in combinazione con la modalità 2. 3=HTTP misto con peering Internet. 99=modalità di download semplice senza peering. Ottimizzazione recapito esegue il download usando solo HTTP e non tenta di contattare i servizi cloud di Ottimizzazione recapito. 100=modalità Bypass. Invece di Ottimizzazione recapito viene usato BITS.
A riguardo si vedano alche i seguenti: