GpUpdate/Invoke‑GPUpdate: errore “RPC server is unavailable (1722)” o “remote procedure call was cancelled” – guida completa e soluzioni

Stai ricevendo “RPC server is unavailable (1722)” o “Remote procedure call was cancelled” quando esegui GpUpdate/Invoke‑GPUpdate da GPMC su un DC o su un’OU? Questa guida pratica spiega cause, porte e servizi coinvolti, con una check‑list operativa e script per risolvere rapidamente l’errore.

Indice

Panoramica del problema

Quando si lancia GpUpdate o Invoke‑GPUpdate verso computer remoti (da un controller di dominio, dalla tua workstation amministrativa o dalla GPMC), l’operazione può fallire con i messaggi:

  • Remote procedure call was cancelled
  • RPC server is unavailable (Errore 1722)

In entrambi i casi la causa è una sessione RPC che non riesce a instaurarsi o viene interrotta tra il mittente (il computer che avvia il comando) e la destinazione (client o server).

Cosa succede dietro le quinte

Invoke‑GPUpdate non “spinge” direttamente i criteri. Crea invece, via RPC/DCOM, una attività pianificata remota sul computer di destinazione (servizio Task Scheduler, servizio Schedule), che a sua volta esegue gpupdate /force. Questo processo si appoggia a:

  • RPC Endpoint Mapper su TCP 135 per individuare l’endpoint del servizio remoto;
  • porte RPC dinamiche (Windows Server 2008+ tipicamente TCP 49152‑65535) per i canali dati;
  • servizi ausiliari come WMI (winmgmt), Remote Registry, DCOM, e naturalmente Task Scheduler (Schedule);
  • autenticazione Kerberos/NTLM e risoluzione DNS affidabile.

Se una di queste componenti è bloccata o non disponibile, riceverai 1722 o “call was cancelled”.

Sintomi e messaggi correlati

  • Timeout su Invoke‑GPUpdate o su “Group Policy Update…” in GPMC;
  • Eventi 1722 (RPC server is unavailable) nel registro System del client o del mittente;
  • Eventi 1058/1006 in Application durante l’elaborazione dei criteri;
  • Impossibile connettersi a WMI (Get-WmiObject/Get-CimInstance in errore);
  • Risoluzione DNS incerta (hostname che punta a IP errato o record mancanti).

Cause più frequenti

#CategoriaDettagli principali
1Servizi RPC inattiviRemote Procedure Call (RPC) o RPC Endpoint Mapper non in esecuzione o avvio non automatico.
2Firewall / porte bloccateTCP 135 (Endpoint Mapper) o intervallo dinamico TCP 49152‑65535 (Windows Server 2008+ *) filtrati su host o firewall di rete.
3Connettività di reteNessun routing tra subnet, VPN inattiva, MTU incompatibile, latenze elevate, NAT non hairpin.
4Risoluzione nomiDNS/WINS non risolvono correttamente FQDN/NetBIOS del computer di destinazione o conflitti IPv4/IPv6.
5AutenticazioneL’account non è amministratore locale o non ha la delega “Remote Group Policy Update”.
6Disallineamento orario / KerberosSkew orario > 5 min o canale sicuro del computer rotto (trust relationship failed).
7Servizi ausiliari mancantiWMI (winmgmt), Remote Registry, DCOM o Task Scheduler disabilitati: richiesti da Invoke‑GPUpdate.

* Se avete limitato l’intervallo dinamico, aprite solo le porte configurate con netsh int ipv4 show dynamicport tcp.

Check‑list rapida di rimedio

  1. Verificare i servizi RPC sc query rpcss sc query RpcEptMapper Devono risultare Running e Automatic; in caso contrario, avviarli e impostare l’avvio automatico.
  2. Test di rete mirati ping <NomeComputer> Test-NetConnection -ComputerName <IP> -Port 135 # verifica Endpoint Mapper Test-NetConnection -ComputerName <IP> -Port 445 # opzionale, SMB verso DC
  3. Aprire le porte nel firewall
    • TCP 135 (Endpoint Mapper)
    • Intervallo dinamico TCP 49152‑65535 (o quello aziendale ristretto)
    • Se usate PowerShell Remoting: 5985 (HTTP) / 5986 (HTTPS)
    # Su un client/ server Windows abilitare i gruppi predefiniti: Enable-NetFirewallRule -DisplayGroup "Remote Scheduled Tasks Management" Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" Enable-NetFirewallRule -DisplayGroup "Remote Service Management" Nota: i nomi dei gruppi dipendono dalla lingua del sistema. In caso di localizzazioni diverse, filtrare per parola chiave: Get-NetFirewallRule | Where-Object {$_.DisplayGroup -match "Scheduled|WMI|Service"} | Format-Table DisplayName, Enabled, Profile
  4. Convalidare il DNS ipconfig /flushdns nslookup <NomeComputer> # verifica FQDN ping -4 <NomeComputer>; ping -6 <NomeComputer> # differenze IPv4/IPv6 Assicurarsi che i client puntino solo ai DNS interni del dominio e che non esistano record duplicati/obsoleti.
  5. Usare credenziali corrette Provare con un account di Domain Admins o delegare “Remote Group Policy Update” sull’OU. L’account deve essere amministratore locale sul target o possedere la delega.
  6. Sincronizzare l’orologio e verificare Kerberos w32tm /query /status nltest /sc_verify:<DOMINIO> Test-ComputerSecureChannel -Server <DC> -Verbose
  7. Verificare servizi ausiliari e Task Scheduler Get-Service winmgmt, remoteregistry, schedule -ComputerName <PC> Devono essere Running (Automatico consigliato)
  8. Riavvio mirato Se l’errore persiste dopo le correzioni, non tentare di arrestare RpcSs (servizio critico e protetto). Riavvia invece i servizi di supporto o, in ultima istanza, la macchina: Restart-Service schedule -Force Restart-Service winmgmt -Force Restart-Service remoteregistry -Force come ultima risorsa shutdown /r /t 0

Diagnostica approfondita

Verifica lato controller di dominio o workstation amministrativa

  • Dcdiag e repadmin (sui DC) per diagnosticare canali RPC e replica AD:
dcdiag /test:rpc
repadmin /replsummary
  • Event Viewer: cercare Event ID 1722 (RPC), 1058/1006 (GroupPolicy) nei registri System e Application.
  • Traffico bloccato: ispezionare firewall per deny su TCP 135 o sulle porte dinamiche.

Verifica lato computer di destinazione

  • Task Scheduler: in Microsoft > Windows > GroupPolicy verifica la creazione dell’attività forzata.
  • WMI/DCOM: prova una query WMI e l’accesso remoto ai servizi:
Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName <PC>
Invoke-Command -ComputerName <PC> -ScriptBlock { gpupdate /force } -ErrorAction Stop
  • Risoluzione nomi: controlla host multipli con lo stesso nome o record A/AAAA non coerenti.
  • Profili firewall: assicurarsi che il profilo Domain sia attivo (non Public) quando il PC è in LAN:
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory

Connessioni e porte essenziali

Porta/ProtocolloServizioQuando serve
TCP 135RPC Endpoint MapperSempre, per iniziare la sessione RPC
TCP 49152‑65535RPC dinamiche (DCOM/WMI/Task Scheduler)Tra mittente e target per i canali dati
TCP 5985 / 5986WinRM (PowerShell Remoting)Opzionale, utile per diagnosi/azioni alternative
TCP 445SMBApplicazione dei criteri lato client verso i DC (lettura SYSVOL)
UDP/TCP 88, 389, 636, 3268, 3269Kerberos / LDAP / GCAutenticazione e query directory durante il GPUpdate
UDP/TCP 53DNSRisoluzione nomi del dominio e dei target

Script rapidi per amministratori

Ping parallelo e verifica 135/dinamiche

$targets = @("PC01","PC02","PC03")
$report = foreach($t in $targets){
  [pscustomobject]@{
    Computer = $t
    Ping     = Test-Connection -Count 1 -Quiet -ComputerName $t
    RPC135   = (Test-NetConnection -ComputerName $t -Port 135).TcpTestSucceeded
    WinRM5985= (Test-NetConnection -ComputerName $t -Port 5985).TcpTestSucceeded
  }
}
$report | Format-Table -Auto

Abilitare regole firewall richieste via remoting

Invoke-Command -ComputerName <PC> -ScriptBlock {
  Enable-NetFirewallRule -DisplayGroup "Remote Scheduled Tasks Management" -ErrorAction SilentlyContinue
  Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -ErrorAction SilentlyContinue
  Enable-NetFirewallRule -DisplayGroup "Remote Service Management" -ErrorAction SilentlyContinue
  Set-Service -Name winmgmt, remoteregistry, schedule -StartupType Automatic
  Start-Service -Name winmgmt, remoteregistry, schedule
}

Controllo delega “Remote Group Policy Update”

Verifica se il tuo account è membro di un gruppo autorizzato o se la delega è stata conferita sull’OU target. In alternativa, prova con un account di Domain Admins e verifica con:

whoami /groups

Scenari tipici e come risolverli

VPN o sedi remote

Sulle VPN con MTU ridotto, l’handshake RPC può frammentarsi e fallire. Imposta l’MTU coerente (ad es. 1400‑1472) e verifica con ping -f -l <size>. Assicurati che il firewall della VPN consenta TCP 135 e le porte dinamiche in entrambe le direzioni.

Firewall di rete “stateful”

Alcuni firewall ispezionano DCE/RPC e richiedono una application rule dedicata (helper RPC). In assenza di deep inspection, apri il range dinamico completo o quello aziendale ristretto e mantieni sessioni persistenti.

DNS non autorevole o record stantii

Client configurati con DNS pubblici o record vecchi in AD‑DNS generano connessioni verso IP inesatti. Correggi i DNS sui client (solo DNS interni), ripulisci i record obsoleti e rinfresca la cache (ipconfig /flushdns).

Disallineamento orario o canale sicuro rotto

Kerberos rifiuta ticket con skew > 5 minuti. Sincronizza con la gerarchia di dominio (PDC Emulator) e, se il canale sicuro fallisce, riparalo:

Test-ComputerSecureChannel -Repair -Credential <DOMINIO\Admin>

Servizi locali disabilitati

Molte baseline “hardening” disattivano Remote Registry o bloccano DCOM. Invoke‑GPUpdate richiede DCOM abilitato (EnableDCOM=Y) e i servizi in esecuzione. Applica una GPO che imposti avvio automatico per winmgmt, remoteregistry e schedule.

Strumenti diagnostici utili

ComandoScopo
dcdiag /test:rpcConvalida i canali RPC dei controller di dominio.
repadmin /replsummaryIndividua errori di replica AD legati a RPC.
Event ViewerEvent ID 1722, 1058, 1006 in System e Application.
Test‑NetConnectionVerifica porte specifiche (sostituisce Telnet).

Buone pratiche preventive

  • Standardizzare le porte RPC dinamiche tramite DCOM o criteri e creare regole firewall coerenti per il range scelto.
  • Firewall di Windows gestito da GPO: abilita i gruppi Remote Scheduled Tasks Management, WMI e Remote Service Management.
  • Replica AD e salute DNS: monitora periodicamente con dcdiag e repadmin (task schedulati) e correggi tempestivamente i record obsoleti.
  • Documentazione: elenca in modo chiaro i requisiti di porta per GPUpdate, WMI e PowerShell Remoting; condividili con i team di rete.
  • Allineamento orario: assicurati che il PDC Emulator sia la fonte di tempo interna e che tutti i membri di dominio si sincronizzino correttamente.
  • Baselines hardening testate: prima del rollout, verifica che le regole non blocchino DCOM/RPC richiesti da Invoke‑GPUpdate.

Appendice: esempio di GPO per abilitare i prerequisiti

  1. Servizi: Computer Configuration > Policies > Windows Settings > Security Settings > System Services
    Imposta Automatic e Started per Windows Management Instrumentation, Remote Registry, Task Scheduler.
  2. Firewall: Computer Configuration > Policies > Windows Defender Firewall with Advanced Security
    Usa “Predefined Rules” per Remote Scheduled Tasks Management (RPC + RPC‑EPMAP) e per Windows Management Instrumentation (WMI) nei profili Domain.
  3. DCOM: assicurati che Enable Distributed COM resti abilitato (criteri di sicurezza locali o preferenze).

Appendice: domande frequenti

Serve aprire la porta 445 per far funzionare “Invoke‑GPUpdate”?
Non per la creazione dell’attività remota (che usa RPC). Tuttavia, il client durante gpupdate deve raggiungere i DC per leggere SYSVOL e criteri: se 445 è bloccata tra client e DC, l’aggiornamento fallirà comunque.

Posso riavviare il servizio “RPC” per sbloccare la situazione?
No. RpcSs è un servizio critico: Windows ne impedisce l’arresto. Se necessario, riavvia l’host o i servizi di supporto (schedule, winmgmt, remoteregistry).

Ho ristretto il range di porte dinamiche, quale devo aprire?
Apri esattamente il range configurato in azienda. Verifica la configurazione locale con netsh int ipv4 show dynamicport tcp (porte effimere). Se hai configurato porte RPC statiche tramite DCOM/registro, usa quelle.

Conclusioni operative

Nella maggior parte dei casi, gli errori 1722 e remote procedure call was cancelled si risolvono garantendo tre condizioni:

  1. i servizi RPC, Task Scheduler, WMI e Remote Registry sono in esecuzione;
  2. il percorso di rete tra mittente e target consente TCP 135 e le porte dinamiche RPC;
  3. DNS, orologio e autenticazione di dominio sono coerenti.

Se dopo la check‑list l’errore persiste, esegui un packet capture (es. Wireshark) per verificare la three‑way handshake su 135 e l’eventuale scambio Bind/BindAck RPC. L’esito di quel test ti dirà in modo definitivo se il problema è rete/firewall o servizio/identità.


Riepilogo “prendi e vai”

  • Porte: 135/TCP + 49152‑65535/TCP (o tuo range) aperte tra mittente e target.
  • Servizi: RpcSs, RpcEptMapper, Schedule, winmgmt, RemoteRegistry = Running, avvio Automatic.
  • DNS: record corretti, niente DNS pubblici sui client, cache pulita.
  • Auth & Time: membership e deleghe corrette, canale sicuro OK, orologio sincronizzato.
  • Log: Eventi 1722/1058/1006 per tracciare esattamente dove fallisce.
Indice