MENU
  1. ホーム
  2. Windows Server
  3. KB5036899 su Windows Server 2016: come risolvere l’errore 1068 dei servizi (Q&A completo)

KB5036899 su Windows Server 2016: come risolvere l’errore 1068 dei servizi (Q&A completo)

Windows Server

Diversi amministratori segnalano che, dopo l’installazione di KB5036899 (Patch Tuesday di aprile 2024) su Windows Server 2016, più servizi non si avviano restituendo l’errore 1068 “The dependency service or group failed to start”. In questa guida trovi sintesi Q&A, procedure rapide, script e checklist operative.

Indice

Panoramica e contesto

KB5036899 è l’aggiornamento cumulativo di aprile 2024 per Windows Server 2016 (Build 14393). In numerosi ambienti, subito dopo l’installazione sono emersi malfunzionamenti: alcuni servizi critici non partono e l’avvio manuale fallisce con Errore 1068, cioè “il servizio di dipendenza o il gruppo di dipendenza non è stato avviato”. La rimozione del cumulativo riporta i servizi alla normalità dopo il riavvio.

Il comportamento è coerente con uno scenario in cui un servizio di base (per esempio RPC, Base Filtering Engine, Network Location Awareness, WMI o servizi di rete) non riesce ad avviarsi e trascina con sé tutti i servizi che dipendono da esso.

Stato ufficiale (riassunto)

  • Nessun riconoscimento del bug sui servizi nelle note “Known issues” di KB5036899: sono menzionati invece problemi su VPN e traffico NTLM.
  • Il cumulativo successivo KB5037763 (14 maggio 2024) corregge i problemi su VPN/NTLM ma non fa riferimento all’errore 1068 sui servizi. È prudente collaudarlo in laboratorio prima di reintrodurre gli aggiornamenti di aprile.
  • Se richiesto dal sistema, installare prima la SSU (Servicing Stack Update) KB5037016 per garantire l’applicazione corretta dei cumulativi.

Che cosa causa l’errore 1068 dopo la patch?

L’errore 1068 non è un difetto “del” servizio che provi ad avviare, ma un errore a cascata: il servizio A dipende dal servizio B (o da più servizi di base), e se B non è in esecuzione, A non può avviarsi. Con KB5036899 diversi amministratori hanno osservato che uno o più servizi di base non partono o entrano in stato di errore. Esempi frequenti di dipendenze che, se bloccate, generano una valanga di 1068:

  • RPC (Remote Procedure Call) e RPC Endpoint Mapper;
  • BFE (Base Filtering Engine) e servizi firewall/criteri IP;
  • NLA (Network Location Awareness), DHCP Client, DNS Client, Workstation e Server;
  • WMI (Windows Management Instrumentation / Winmgmt);
  • Servizi legati alla rete e allo stack di sicurezza (LSASS/NTLM).

Confermare quale “anello debole” non si avvia è la chiave per una correzione mirata quando non puoi disinstallare la patch.

Decisioni rapide: cosa fare subito

  1. Produzione ferma? Se l’impatto è critico, la via più sicura e immediata è disinstallare KB5036899 e riavviare. In genere i servizi tornano operativi subito dopo.
  2. Bloccare la re-installazione finché non viene validato un cumulativo successivo (KB5037763 o più recente) nell’ambiente di staging.
  3. Se non puoi rimuovere la patch, prova ad avviare manualmente le dipendenze di base del servizio critico (RPC, BFE, NLA, ecc.) e verifica i log del Service Control Manager (Event ID 7000/7001/7036) per capire l’ordine giusto di avvio.

Soluzioni pratiche (dal thread e collaudate sul campo)

ObiettivoPassaggi chiaveQuando usarlaNote e rischi
Ripristino immediatoDisinstallare KB5036899 con wusa /uninstall /kb:5036899 (o da Impostazioni → Windows Update → Cronologia) e riavviare.Down di servizi critici, SLA a rischio, finestre di manutenzione brevi.Ripristina rapidamente l’operatività. Va pianificato il rientro in patching con un cumulativo stabile.
Prevenire la reinstallazionea) Pausa di Windows Update oppure disattivare “Configure Automatic Updates” via GPO
b) In ambienti client, nascondere il KB con wushowhide.diagcab (non sempre applicabile ai server)		Per evitare ricadute in attesa dei test su CU successivi o di un fix dedicato.In ambienti gestiti con WSUS/SCCM, declinare/ritirare l’update dalla distribuzione.
Verificare dipendenzeDa services.msc aprire la scheda Dependencies, avviare manualmente i servizi base (RPC, BFE, NLA, ecc.) e riprovare l’avvio.Quando non è possibile rimuovere la patch (sistemi regolamentati, blackout di compliance).Soluzione “tampone”: può richiedere re-order di avvio a ogni boot se la causa permane.
Monitorare fix futuriTenere d’occhio il Windows Health Dashboard; testare in laboratorio KB5037763 o cumulativi successivi (installando prima SSU KB5037016 se richiesto).Pianificazione di rientro in patching e mantenimento della postura di sicurezza.Non c’è menzione ufficiale dell’errore 1068 in KB5037763; test imprescindibile.

Playbook di ripristino passo‑passo

Scenario A – Ripristino rapido (rollback della patch)

  1. Apri una sessione con privilegi elevati.
  2. Esegui: wusa.exe /uninstall /kb:5036899 /quiet /norestart
  3. Pianifica e comunica il riavvio (change window minima). Dopo il riavvio, verifica stato servizi.
  4. Blocca la re-installazione via GPO/WSUS (vedi sezione dedicata).

Scenario B – Non posso disinstallare (tiene su i servizi base)

  1. Individua il servizio critico fermo (es. SQL Server, Print Spooler, DFS, servizi applicativi).
  2. Apri services.msc → scheda Dependencies → annota i servizi dei quali dipende.
  3. Avvia in ordine: RPC → Event Log → BFE → NLA → Workstation/Server → Winmgmt → servizio applicativo.
  4. Se un servizio base non parte, consulta Event Viewer → System:
    • Event ID 7000/7001: avvio fallito per dipendenza mancante.
    • Event ID 7036: cambi di stato utili a ricostruire la sequenza.
  5. Se persistono errori:
    • Esegui sfc /scannow e poi: DISM /Online /Cleanup-Image /RestoreHealth
    • Reimposta lo stack di rete solo se compatibile con la tua baseline: netsh int ip reset netsh winsock reset
    • Verifica repository WMI: winmgmt /verifyrepository REM Se corrotto: winmgmt /salvagerepository

Come evitare che KB5036899 torni a installarsi

Con criteri di gruppo (GPO)

Imposta temporaneamente la sospensione dell’installazione automatica su Server 2016:

  1. Apri l’Editor Criteri di Gruppo (locale o dominio).
  2. Vai a Computer Configuration → Administrative Templates → Windows Components → Windows Update.
  3. Configura Configure Automatic Updates su Disabled oppure su Notify for download and auto install per avere controllo manuale.
  4. In ambienti WSUS, declina esplicitamente KB5036899 per i gruppi di destinazione interessati.

Con WSUS/SCCM/MECM

  • WSUS: crea un gruppo “Quarantena” e sposta i server impattati; Decline l’update KB5036899 per tali gruppi.
  • SCCM/MECM: rimuovi l’aggiornamento dalle Software Update Groups e avvia un ciclo di valutazione delle policy sui server.

Client e server non gestiti

Su endpoint non gestiti, wushowhide.diagcab consente di nascondere temporaneamente lo specifico KB. Sui server è preferibile governare con GPO o WSUS.

Validare KB5037763 o cumulativi successivi

Prima di reintrodurre patch di aprile, esegui un test in laboratorio con KB5037763 (maggio 2024) o un cumulativo ancora più recente:

  1. Applica prima la SSU KB5037016 se richiesta dal sistema.
  2. Installa il cumulativo su un clone o server di staging.
  3. Esegui un post‑patch testbook (vedi sezione Checklist) focalizzato su: autenticazioni NTLM, VPN, servizi che prima cadevano con 1068, backup/monitoring, agent di sicurezza.
  4. Osserva eventi e crash durante almeno un reboot di verifica e un ciclo completo di carico applicativo.

Automazione del rollback in flotta

Su più server, uno script PowerShell consente di rimuovere il KB in modo silenzioso e controllato:

# Disinstalla KB5036899 se presente, senza riavvio automatico
Get-HotFix -Id KB5036899 -ErrorAction SilentlyContinue |
  ForEach-Object {
    Start-Process wusa.exe "/uninstall /kb:5036899 /quiet /norestart" -Wait
  }

Esempio per esecuzione remota su un elenco di host (con WinRM abilitato):

$servers = @("SRVAPP01","SRVDB02","SRVFS03")
Invoke-Command -ComputerName $servers -ScriptBlock {
  if (Get-HotFix -Id KB5036899 -ErrorAction SilentlyContinue) {
    Start-Process wusa.exe "/uninstall /kb:5036899 /quiet /norestart" -Wait
    "KB5036899 rimosso su $env:COMPUTERNAME"
  } else {
    "KB5036899 non presente su $env:COMPUTERNAME"
  }
}

Ricorda di orchestrare il riavvio in finestre controllate e di notificare i team applicativi.

Indagine: trovare la dipendenza che blocca tutto

Per un servizio che non parte (esempio: Spooler), identifica le dipendenze e tentane l’avvio ordinato:

# Elenca i servizi dai quali dipende lo Spooler
(Get-Service -Name Spooler).ServicesDependedOn | Select-Object Name, Status

Prova ad avviarli in sequenza, loggando gli esiti

\$svc = Get-Service -Name Spooler
foreach (\$dep in \$svc.ServicesDependedOn) {
if (\$dep.Status -ne 'Running') {
try { Start-Service -Name \$dep.Name -ErrorAction Stop; "Avviato: \$(\$dep.Name)" }
catch { "Errore avvio: \$(\$dep.Name) - \$($\_.Exception.Message)" }
}
}

Riprova l’avvio del servizio finale

Start-Service -Name Spooler

Event Viewer aiuta a capire il root cause immediato:

# Ultimi eventi SCM rilevanti
Get-WinEvent -LogName System -MaxEvents 200 |
  Where-Object { $_.Id -in 7000,7001,7036 } |
  Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Checklist post‑intervento

  • Servizi: tutti i servizi critici sono in “Running” e con Startup Type corretto.
  • Eventi: assenza di 7000/7001/7036 ripetitivi al riavvio.
  • Rete: test DNS/LDAP/SMB, convalida login interattivi e di servizio, montaggi di share, stampa.
  • Backup: esecuzione job successivo all’intervento.
  • Monitoring: agent e heartbeat OK (AV/EDR, log shipping, APM).
  • Applicazioni: smoke test con i referenti funzionali.
  • Documentazione: aggiorna change log con data/ora, server coinvolti, azioni eseguite e risultati.

Bilanciamento rischio‑sicurezza

Il rollback di KB5036899 riduce temporaneamente il livello di patching e, in teoria, aumenta la superficie di attacco. Valuta il rischio in base a:

  • Esposizione del server (intranet isolata vs Internet‑facing).
  • Controlli compensativi (IPS/IDS, WAF, EDR, segmentazione).
  • Tempo di permanenza senza la patch e piano di rientro su KB5037763 o successivi.

Quando possibile, preferisci un rientro rapido con il cumulativo di maggio 2024 o uno più recente, validato in laboratorio.

Domande frequenti (Q&A)

Il problema colpisce tutti i ruoli di server?

No. Il pattern più insidioso è quando uno dei servizi base (RPC, BFE, NLA, Winmgmt) non si avvia. In quei casi l’impatto si estende a ruota su più ruoli (file/print, applicativi, agent), generando serie di errori 1068. In altri scenari il problema può non manifestarsi.

Disinstallare il KB danneggia la catena SSU/LCU?

No: le SSU (Servicing Stack Update) sono in genere non disinstallabili e restano installate. La rimozione interessa il LCU. Il consiglio è comunque di mantenere la SSU più recente prima di testare e installare un LCU successivo.

Posso “riparare” definitivamente senza rollback?

Non esiste una correzione universale. In alcuni casi l’avvio manuale e l’ordinamento corretto delle dipendenze risolve fino al riavvio. Se l’intoppo è dovuto a corruzione WMI o rete, gli step SFC/DISM e il ripristino dello stack possono aiutare. Per una soluzione stabile, meglio validare e installare un cumulativo successivo.

Come monitorare se Microsoft rilascia un fix specifico?

Controlla regolarmente le note dei cumulativi successivi per Windows Server 2016 e il Windows Health Dashboard. In assenza di menzione esplicita sull’errore 1068, mantieni la prudenza e prosegui con test mirati su ambienti non produttivi.

Modello di procedura operativa standard (SOP)

  1. Prep: snapshot/backup, finestra di manutenzione, comunicazione al business.
  2. Installazione/Disinstallazione: applica o rimuovi KB come da piano; registra versione build prima/dopo.
  3. Convalida: esegui la checklist tecnica e i test applicativi.
  4. Stabilizzazione: monitora 24‑48 ore (log, performance, alert).
  5. Rientro: definisci quando passare a KB5037763 o a un cumulativo più recente, a esito dei test.
  6. Documentazione: aggiorna il registro cambi, gli asset e gli audit trail.

Comandi rapidi utili

# Elencare aggiornamenti installati
wmic qfe list brief /format:table

Verificare se KB5036899 è presente

Get-HotFix -Id KB5036899

Disinstallare KB5036899 (interattivo)

wusa.exe /uninstall /kb:5036899

Disinstallare KB5036899 (silenzioso, senza riavvio)

wusa.exe /uninstall /kb:5036899 /quiet /norestart

Forzare rilevamento aggiornamenti (WSUS/WU)

wuauclt /detectnow
usoclient StartScan

Stato servizi base

sc.exe queryex type= service state= all | more

Dipendenze di un servizio

sc.exe qc \

Avvio forzato di un servizio

sc.exe start \

Log e artefatti da archiviare per l’audit

  • Elenco KB prima/dopo (output di Get-HotFix o wmic qfe).
  • Eventi SCM (7000/7001/7036) e Eventi Applicativi correlati.
  • Export dei servizi con stato e tipo di avvio (Get-Service in CSV).
  • Report di successo/fallimento degli script di disinstallazione/riavvio.
  • Conferma dei test funzionali e dell’approvazione dei referenti.

Conclusioni

Fino all’uscita (e validazione) di un aggiornamento che risolva esplicitamente l’errore 1068 su Windows Server 2016, la strategia più affidabile resta: disinstallare KB5036899, bloccarne la re‑installazione, e monitorare/validare i cumulativi successivi (a partire da KB5037763) in ambiente di laboratorio, rispettando impeccabilmente backup, change management e checklist post‑patch.

Appendice: esempio di script di rollback con log

# Rimuove KB5036899 se presente e scrive un log CSV
$kb = "KB5036899"
$log = "C:\Temp\Rollback$($kb)$(Get-Date -Format yyyyMMdd_HHmmss).csv"
$results = @()

if (Get-HotFix -Id \$kb -ErrorAction SilentlyContinue) {
\$start = Get-Date
\$proc = Start-Process wusa.exe "/uninstall /kb:5036899 /quiet /norestart" -PassThru -Wait
\$end = Get-Date
\$results += \[pscustomobject]@{
ComputerName = \$env\:COMPUTERNAME
KB           = \$kb
ExitCode     = \$proc.ExitCode
StartTime    = \$start
EndTime      = \$end
RebootNeeded = \$true
}
} else {
\$results += \[pscustomobject]@{
ComputerName = \$env\:COMPUTERNAME
KB           = \$kb
ExitCode     = "NotInstalled"
StartTime    = \$null
EndTime      = \$null
RebootNeeded = \$false
}
}

\$results | Export-Csv -NoTypeInformation -Path \$log
Write-Host "Log scritto in \$log"

Appendice: modello di comunicazione

Oggetto: Anomalia servizi (Errore 1068) dopo patch KB5036899 su Windows Server 2016 – Piano di mitigazione
Messaggio: “Abbiamo rilevato su alcuni server un problema di avvio servizi (Errore 1068) correlato a KB5036899. Procediamo con disinstallazione controllata e sospensione dell’update. Nessun impatto dati; i servizi torneranno operativi dopo il riavvio. Seguiranno test su cumulativo successivo.”

In sintesi: finché non sarà disponibile e validato un fix specifico, la soluzione più affidabile è disinstallare KB5036899, impedire la sua re‑installazione e testare sistematicamente i cumulativi successivi in laboratorio per una correzione definitiva.

Windows Server
errore 1068 KB5036899 PowerShell Troubleshooting Windows Server 2016 Windows Update WSUS
Indice