MENU
  1. ホーム
  2. PowerShell
  3. Rename‑Computer e errore “The RPC server is unavailable”: guida completa per risolvere in domini AD

Rename‑Computer e errore “The RPC server is unavailable”: guida completa per risolvere in domini AD

PowerShell

Stai cercando di rinominare un PC con PowerShell e “Rename‑Computer” ti risponde con The RPC server is unavailable? In questa guida completa e pratica vediamo perché accade in ambienti Active Directory On‑Premise e come risolvere in modo strutturato, con test, comandi e alternative sicure.

Indice

Panoramica del problema

Un amministratore, in un dominio AD On‑Premise, esegue:

Rename-Computer -ComputerName "A" -NewName "A1" -DomainCredential (Get-Credential) -Force -Restart

e riceve:

Cannot establish the WMI connection to the computer 'A'.
The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

La causa più frequente è che la chiamata remota DCOM/WMI non riesce a raggiungere il servizio RPC del computer di destinazione, o viene bloccata da firewall, risoluzione nomi errata, servizi non in esecuzione, problemi di tempo/Kerberos o permessi insufficienti. Quando Rename‑Computer viene lanciato con -ComputerName, PowerShell utilizza WMI su RPC/DCOM: contatta l’Endpoint Mapper alla porta TCP 135, quindi negozia una porta dinamica nel range elevato (Windows moderni: 49152‑65535). Se una di queste fasi fallisce, otterrai 0x800706BA.

Come funziona la rinomina remota

Comprendere il percorso di rete aiuta a concentrare la diagnosi:

  • Quando usi -ComputerName: PowerShell chiama WMI/DCOM. Flusso tipico:
    1. TCP 135 (Endpoint Mapper) per chiedere quale porta dinamica usare.
    2. Connessione alla porta dinamica assegnata (in genere 49152‑65535 su Windows recenti) verso il servizio WMI sul client.
  • Quando usi PowerShell Remoting (Invoke‑Command): il trasporto è WS‑Man (WinRM) su 5985 HTTP o 5986 HTTPS. Questo spesso aggira i problemi RPC/DCOM perché non richiede l’apertura del range dinamico.

Di conseguenza hai due grandi strategie: aprire correttamente RPC e far funzionare WMI/DCOM, oppure spostare l’operazione su WinRM/WS‑Man per evitare le porte dinamiche.

Checklist rapida

  • Verifica raggiungibilità IP e porte: 135 e porte RPC dinamiche.
  • Controlla DNS: il nome “A” risolve l’IP corretto (record A e PTR coerenti).
  • Assicurati che i servizi RPC/WMI/Remote Registry siano in esecuzione.
  • Controlla l’orario: differenza <= 5 minuti fra client, DC e host di amministrazione.
  • Verifica i permessi in AD per la rinomina dell’oggetto computer.
  • Se possibile, prova con metodo alternativo (WinRM o rinomina locale).

Verifiche di rete e porte RPC

Parti sempre dalla connettività:

# Raggiungibilità IP e latenza
Test-NetConnection -ComputerName A

Verifica porta 135 (Endpoint Mapper)

Test-NetConnection -ComputerName A -Port 135

Facoltativo: verifica WS-Man se vuoi usare Remoting come alternativa

Test-WSMan -ComputerName A </code></pre>

<p>Se <code>TcpTestSucceeded</code> è <strong>False</strong> sulla porta 135, il firewall di rete o Windows Defender Firewall sta bloccando. Per RPC sono richieste:</p>
<ul>
  <li><strong>TCP 135</strong> (Endpoint Mapper)</li>
  <li><strong>Porte dinamiche RPC</strong>:
    <ul>
      <li>Windows Vista/2008 e successivi: <strong>49152‑65535</strong></li>
      <li>Windows più datati: <strong>1024‑65535</strong></li>
    </ul>
  </li>
</ul>
<p>In ambienti restrittivi, è pratica comune <strong>limitare il range</strong> delle porte RPC consentite sul client e aprire solo quel sotto‑insieme sul firewall. Questa impostazione si realizza via Registro su <code>HKLM\SOFTWARE\Microsoft\Rpc\Internet</code> definendo voci come <code>Ports</code> (REGMULTISZ con <code>5000-5200</code> ad esempio), <code>PortsInternetAvailable</code> (<code>Y</code>) e <code>UseInternetPorts</code> (<code>Y</code>). Valuta attentamente la change e testala su un gruppo pilota prima di estenderla tramite GPO.</p>
<p>Alternativa più semplice (e spesso più sicura): evitare DCOM aprendo solo WinRM 5985/5986 e usare il metodo con <code>Invoke‑Command</code> illustrato più avanti.</p>

<h2>DNS e risoluzione nomi</h2>
<p>La risoluzione errata del nome è una delle cause più sottovalutate di 0x800706BA. Esegui test dal tuo host e dal DC:</p>
<pre><code class="language-powershell"># Dal tuo host di amministrazione
nslookup A
Resolve-DnsName A

Dal DC (o da una sessione PowerShell sul DC)

nslookup A
Resolve-DnsName A

Pulisci cache locale e registra nuovamente

ipconfig /flushdns
ipconfig /registerdns </code></pre>

<p>Interventi tipici:</p>
<ul>
  <li><strong>Rimuovere record obsoleti</strong> (A e PTR) per “A”.</li>
  <li><strong>Correggere host multi-homed</strong> (più NIC) che pubblicano più record A: assicurati che l’indirizzo raggiungibile sia quello usato dall’amministrazione.</li>
  <li><strong>Verificare il suffisso DNS primario</strong> del client: il FQDN deve riflettere il dominio AD.</li>
  <li>Nei siti con VPN/NAT, controlla che la risoluzione riporti l’IP “interno” e non quello di uscita.</li>
</ul>

<h2>Servizi richiesti attivi</h2>
<p>I seguenti servizi devono essere <em>Automatici</em> e in esecuzione sul client “A”:</p>
<ul>
  <li><strong>Remote Procedure Call (RPC)</strong> (<code>RpcSs</code>)</li>
  <li><strong>Windows Management Instrumentation</strong> (<code>Winmgmt</code>)</li>
  <li><strong>Remote Registry</strong> (spesso necessario per operazioni di rinomina remota)</li>
  <li><strong>TCP/IP NetBIOS Helper</strong> (<code>lmhosts</code>) nelle reti legacy o con risoluzioni NetBIOS</li>
</ul>
<p>Verifica ed eventuale avvio (localmente o via Remoting, se disponibile):</p>
<pre><code class="language-powershell"># Da console locale su "A" o via Invoke-Command
Get-Service RpcSs, Winmgmt, RemoteRegistry, lmhosts | Format-Table -Auto

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service -Name RemoteRegistry </code></pre>

<h2>Sincronizzazione oraria e Kerberos</h2>
<p>Se la differenza oraria supera i 5 minuti fra host di amministrazione, DC e client, Kerberos può fallire e, di conseguenza, le operazioni RPC non si autenticano. Controlla lo stato:</p>
<pre><code class="language-powershell">w32tm /query /status
w32tm /query /configuration
</code></pre>
<p>Per forzare un riallineamento rapido:</p>
<pre><code class="language-powershell">w32tm /resync
Se necessario, imposta manualmente i peer NTP sul PDC Emulator del dominio e aggiorna:
w32tm /config /manualpeerlist:"ntp1.contoso.local ntp2.contoso.local" /syncfromflags:manual /update
net stop w32time &amp; net start w32time
</code></pre>

<h2>Permessi e contesto di esecuzione</h2>
<p>Assicurati che l’account passato a <code>-DomainCredential</code> abbia i diritti per rinominare gli oggetti computer nell’OU in cui risiede “A”. In AD questo privilegio è tipicamente concesso a <em>Domain Admins</em> e <em>Account Operators</em>, ma molte organizzazioni delegano in modo granulare a specifiche OU. Se hai dubbi, prova in primis la rinomina <strong>locale</strong> con un account amministrativo adeguato.</p>
<p>Nota importante: se il computer è <em>già</em> nel dominio, il metodo più affidabile è eseguire il comando direttamente sul client (localmente o via Remoting). L’uso di <code>-ComputerName</code> forza DCOM e aumenta le dipendenze da rete/firewall.</p>

<h2>Metodo alternativo con PowerShell Remoting</h2>
<p>WinRM/WS‑Man usa porte stabili (5985/5986) e spesso supera ostacoli RPC. Procedi così:</p>
<pre><code class="language-powershell"># Abilita WinRM sul client (puoi farlo con GPO o localmente)
Enable-PSRemoting -Force

Test del canale WS-Man

Test-WSMan A

Rinomina eseguendo il comando direttamente sul client tramite remoting

Invoke-Command -ComputerName A -Credential (Get-Credential) -ScriptBlock {
Rename-Computer -NewName "A1" -Force -Restart
} </code></pre>

<p>Se il client non è nel dominio o non esiste SPN, potresti dover impostare <code>TrustedHosts</code> sul tuo host di amministrazione:</p>
<pre><code class="language-powershell">Set-Item WSMan:\localhost\Client\TrustedHosts -Value "A" -Force
</code></pre>
<p>Per la massima sicurezza, preferisci HTTPS su 5986 con certificato valido e restrizioni d’accesso.</p>

<h2>Policy firewall di Windows</h2>
<p>Controlla che le regole integrate per la gestione remota siano abilitate sul client:</p>
<pre><code class="language-powershell"># WMI
Get-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" | 
  Where-Object Enabled -eq False | Enable-NetFirewallRule

Remote Service Management

Get-NetFirewallRule -DisplayGroup "Remote Service Management" |
Where-Object Enabled -eq False | Enable-NetFirewallRule

Remote Event Log Management (utile per diagnosi)

Get-NetFirewallRule -DisplayGroup "Remote Event Log Management" |
Where-Object Enabled -eq False | Enable-NetFirewallRule </code></pre>

<p>Prova anche una <strong>disattivazione temporanea</strong> (su entrambe le macchine) per isolare l’origine del problema. Se la rinomina riuscisse a firewall disattivato, riattivalo subito e apri solo le eccezioni minime necessarie (RPC/WMI o WinRM).</p>

<h2>Diagnostica con WMI e test mirati</h2>
<p>Verifica se il canale WMI remoto risponde, perché <code>Rename‑Computer</code> si appoggia proprio a WMI:</p>
<pre><code class="language-powershell"># Test WMI con Win32_OperatingSystem
Get-WmiObject -Class Win32_OperatingSystem -ComputerName A

Oppure prova WBEMTEST (GUI)

wbemtest > Connect to \A\root\cimv2 e tenta la connessione

</code></pre>

<p>Se fallisce con lo stesso errore RPC, la causa è quasi certamente firewall/porte DNS o servizi WMI. Se <code>Get-WmiObject</code> funziona ma <code>Rename‑Computer</code> fallisce, sospetta permessi o problemi del repository WMI/Remote Registry.</p>

<h2>Event Viewer e log utili</h2>
<ul>
  <li><strong>WMI‑Activity</strong> (Applications and Services Logs → Microsoft → Windows → WMI‑Activity → Operational): eventi con dettagli di client, namespace e codice errore.</li>
  <li><strong>RPC‑Events</strong> (Microsoft → Windows → RPC‑Events → Operational): errori RPC lato server e mapping delle porte.</li>
  <li><strong>System/Security</strong>: eventi Kerberos/NTLM (fallimenti di autenticazione indicano mismatch orario o credenziali).</li>
</ul>
<p>Per debug di rete, abilita il logging firewall locale:</p>
<pre><code class="language-powershell">netsh advfirewall set currentprofile logging filename %systemroot%\system32\LogFiles\Firewall\pfirewall.log
netsh advfirewall set currentprofile logging droppedconnections enable
</code></pre>

<h2>Rinominare in sicurezza: approcci consigliati</h2>
<h3>Rinomina locale</h3>
<p>Il percorso più semplice quando hai accesso alla console o Remoting operativo:</p>
<pre><code class="language-powershell">Rename-Computer -NewName "A1" -Restart
</code></pre>
<p>Se il PC è nel dominio e vuoi mantenere il join, fornisci credenziali di dominio con privilegi adeguati:</p>
<pre><code class="language-powershell">Rename-Computer -NewName "A1" -DomainCredential (Get-Credential) -Restart
</code></pre>

<h3>Rinomina remota via WinRM</h3>
<p>Già visto in alto, è il metodo preferibile per reti con firewall stretti:</p>
<pre><code class="language-powershell">Invoke-Command -ComputerName A -Credential (Get-Credential) -ScriptBlock {
    Rename-Computer -NewName "A1" -Force -Restart
}
</code></pre>

<h3>Rinomina remota via WMI/DCOM</h3>
<p>Funziona bene solo con regole firewall appropriate e DNS impeccabile. Se devi restare su DCOM, considera la restrizione del range di porte con change controllata e apertura mirata sul firewall.</p>

<h2>Prove rapide di isolamento</h2>
<ul>
  <li><strong>Firewall off</strong> temporaneamente su admin host e su “A”. Se la rinomina va, il problema è nelle regole: riaccendi e configura eccezioni.</li>
  <li><strong>Rinomina locale</strong> per escludere problemi interni a WMI: 
    <pre><code class="language-powershell">Rename-Computer -NewName "A1" -Restart</code></pre>
  </li>
  <li><strong>Test WS‑Man</strong> per verificare l’alternativa WinRM:
    <pre><code class="language-powershell">Test-WSMan A</code></pre>
  </li>
</ul>

<h2>Risoluzione avanzata</h2>
<h3>Repository WMI danneggiato</h3>
<p>Intervieni solo se gli altri tentativi falliscono e dopo un backup:</p>
<pre><code class="language-powershell">winmgmt /verifyrepository
winmgmt /salvagerepository
</code></pre>
<p>In casi estremi, si può riparare e ricompilare i MOF, ma è un’operazione invasiva da pianificare in finestra di manutenzione.</p>

<h3>Reset dello stack di rete</h3>
<p>Se sospetti driver o TCP/IP corrotti:</p>
<pre><code class="language-powershell">netsh int ip reset
netsh winsock reset
Restart-Computer
</code></pre>

<h3>Canale sicuro di dominio</h3>
<p>Se il computer ha perso il canale sicuro con il dominio, possono emergere errori di autenticazione (che si manifestano anche come problemi RPC):</p>
<pre><code class="language-powershell">Test-ComputerSecureChannel -Server &lt;DC_FQDN&gt; -Verbose
Se necessario sul client:
Reset-ComputerMachinePassword -Server &lt;DC_FQDN&gt; -Credential (Get-Credential)
</code></pre>

<h3>GPO e restrizioni NTLM</h3>
<p>In domini con “Restrict NTLM”, assicurati di poter usare Kerberos (tempo, SPN, DNS) o prevede eccezioni adeguate. Verifica il ticket con:</p>
<pre><code class="language-powershell">klist get host/A
klist
</code></pre>

<h2>Attenzioni speciali</h2>
<ul>
  <li><strong>Non rinominare Domain Controller con <code>Rename‑Computer</code></strong>. Per i DC usa procedure dedicate (<em>netdom computername</em> o processi di rinomina del DC) e verifica la replica AD/DNS.</li>
  <li><strong>VPN e NAT</strong>: RPC/DCOM soffrono molto dietro NAT. In questi scenari è preferibile WinRM su 5986 (HTTPS) con certificati validi.</li>
  <li><strong>Cluster e ruoli</strong>: prima di rinominare nodi in cluster, pianifica l’impatto su ruoli, SPN e dipendenze applicative.</li>
</ul>

<h2>Playbook operativo passo‑passo</h2>
<ol>
  <li><strong>Ping e 135</strong>
    <pre><code class="language-powershell">Test-NetConnection A
Test-NetConnection A -Port 135
</code></pre>
  </li>
  <li><strong>DNS</strong>
    <pre><code class="language-powershell">nslookup A
Resolve-DnsName A
ipconfig /flushdns
ipconfig /registerdns
</code></pre>
  </li>
  <li><strong>Servizi</strong>
    <pre><code class="language-powershell">Get-Service RpcSs, Winmgmt, RemoteRegistry, lmhosts
</code></pre>
  </li>
  <li><strong>Tempo</strong>
    <pre><code class="language-powershell">w32tm /query /status
w32tm /resync
</code></pre>
  </li>
  <li><strong>WinRM come alternativa</strong>
    <pre><code class="language-powershell">Enable-PSRemoting -Force
Test-WSMan A
Invoke-Command -ComputerName A -Credential (Get-Credential) -ScriptBlock {
  Rename-Computer -NewName "A1" -Force -Restart
}

Se insisti su WMI/DCOM: apri 135 + range dinamico o limita il range e adegua il firewall.
Se ancora fallisce: verifica log WMI/RPC, prova reset rete e (ultima ratio) ripara repository WMI.

Comandi pronti all’uso

ObiettivoComandoEsito atteso
Porte aperteTest-NetConnection -ComputerName A -Port 135TcpTestSucceeded = True
Verifica WMI remotowbemtest → Connect a \\A\root\cimv2Connessione riuscita
Regole firewall per eventiGet-NetFirewallRule -DisplayGroup "Remote Event Log Management"Regole abilitate
Verifica tempow32tm /query /statusSkew <= 5 minuti
Abilitare WMI‑InEnable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"Stato: Enabled
Abilitare RemotingEnable-PSRemoting -ForceListener WS‑Man attivo
Rinomina localeRename-Computer -NewName "A1" -RestartRiuscito e riavvio

FAQ pratiche

Serve il riavvio?

Sì: la modifica del nome host diventa effettiva dopo il riavvio. Con -Restart PowerShell gestisce automaticamente il reboot al termine dell’operazione.

Che impatto ha su AD e SPN?

Per macchine membro, AD aggiorna nome e SPN del computer. Assicurati che la replica fra DC sia sana per evitare incongruenze temporanee fra siti.

Posso rinominare un DC con Rename‑Computer?

No. Per i Domain Controller usa strumenti e procedure specifiche (ad es. netdom) e pianifica correttamente DNS, registrazioni e replica.

Perché works locally but not remotely?

Localmente non attraversi firewall né endpoint mapper. Se la rinomina in locale va, il problema è quasi certamente in rete/firewall/DNS. Usa WinRM come alternativa remota “a porte stabili”.

Soluzione sintetica consigliata

  1. Conferma DNS corretto e tempo allineato.
  2. Abilita WinRM e prova la rinomina via Invoke‑Command (scorciatoia efficace nella maggior parte dei casi).
  3. Se proprio devi usare WMI/DCOM, apri 135 e le porte dinamiche (o limita il range e adegua il firewall) e assicurati che RPC, WMI e Remote Registry siano avviati.
  4. In caso di persistenza dell’errore, esamina i log WMI/RPC, valuta il reset TCP/IP e, in ultima istanza, la riparazione del repository WMI.

Conclusioni

“The RPC server is unavailable” durante Rename‑Computer è quasi sempre il sintomo di una dipendenza di rete bloccata (porta 135 o dinamiche), di una risoluzione nomi errata o di prerequisiti di servizio/tempo non rispettati. Seguendo l’ordine proposto — rete, DNS, servizi, tempo, permessi — e adottando WinRM/WS‑Man come alternativa moderna a DCOM, nella stragrande maggioranza dei casi la rinomina remota torna a funzionare senza intoppi. Per problemi più rari (repository WMI o stack TCP/IP danneggiati) esistono procedure di riparazione che, sebbene più invasive, risolvono definitivamente. Applicando queste buone pratiche potrai standardizzare il playbook di rinomina e ridurre al minimo i tempi di fermo e i rischi operativi.

Appendice: esempi di script riutilizzabili

# Funzione rapida: verifica prerequisiti per rinomina via DCOM/WMI
function Test-RenameComputerPrereqs {
    param([Parameter(Mandatory)] [string]$ComputerName)
```
$result = [ordered]@{
    ComputerName         = $ComputerName
    PingReachable        = $false
    Port135              = $false
    WsmanReachable       = $false
    DnsResolves          = $false
    RpcService           = $null
    WmiService           = $null
    RemoteRegistry       = $null
    TimeSkewMinutes      = $null
}

$ping = Test-NetConnection -ComputerName $ComputerName -InformationLevel Quiet
$result.PingReachable = [bool]$ping

$t135 = Test-NetConnection -ComputerName $ComputerName -Port 135 -WarningAction SilentlyContinue
$result.Port135 = [bool]$t135.TcpTestSucceeded

try { $ws = Test-WSMan -ComputerName $ComputerName -ErrorAction Stop; $result.WsmanReachable = $true } catch {}

try { $dns = Resolve-DnsName $ComputerName -ErrorAction Stop; $result.DnsResolves = $true } catch {}

# Se hai Remoting, interroga servizi e tempo in modo non intrusivo
try {
    $svc = Invoke-Command -ComputerName $ComputerName -ScriptBlock {
        Get-Service RpcSs, Winmgmt, RemoteRegistry | Select-Object Name,Status,StartType
    } -ErrorAction Stop
    $result.RpcService = ($svc | Where-Object Name -eq 'RpcSs').Status
    $result.WmiService = ($svc | Where-Object Name -eq 'Winmgmt').Status
    $result.RemoteRegistry = ($svc | Where-Object Name -eq 'RemoteRegistry').Status

    $time = Invoke-Command -ComputerName $ComputerName -ScriptBlock { (Get-Date) }
    $skew = [math]::Round((New-TimeSpan -Start $time -End (Get-Date)).TotalMinutes,2)
    $result.TimeSkewMinutes = $skew
} catch {}

[pscustomobject]$result
```
}

Esempio d'uso:

Test-RenameComputerPrereqs -ComputerName 'A' | Format-List

Riepilogo operativo minimo

  • Apri TCP 135 e porte RPC dinamiche oppure usa WinRM 5985/5986.
  • Correggi DNS e cache, verifica record A/PTR e suffisso.
  • RPC/WMI/Remote Registry in automatico ed in esecuzione.
  • Allinea l’orario entro 5 minuti.
  • Usa Invoke‑Command per evitare DCOM quando possibile.

Seguendo l’ordine sopra, nella maggioranza dei casi il problema “RPC server is unavailable” viene risolto e il comando Rename‑Computer funziona correttamente.

Esempio finale “tutto in uno” via WinRM

$cred = Get-Credential  # credenziali con diritti su A
Assicurati che WinRM sia abilitato su A (via GPO o setup una tantum)
Invoke-Command -ComputerName A -Credential $cred -ScriptBlock {
    # Precheck light
    Get-Service RpcSs, Winmgmt, RemoteRegistry | Format-Table -Auto
    # Rinomina
    Rename-Computer -NewName "A1" -Force -Restart
}
PowerShell
Active Directory DNS Firewall PowerShell RPC Windows WinRM WMI
Indice