Vous renommez un PC joint au domaine avec PowerShell et tombez sur « RPC server is unavailable (0x800706BA) » ? Voici un guide terrain, concret et actionnable pour diagnostiquer rapidement la cause (réseau, DNS, services) et appliquer la meilleure correction, y compris via WinRM.
Symptôme
Le renommage à distance d’un poste via PowerShell échoue avec une erreur RPC lors de l’utilisation du paramètre -ComputerName
:
Rename-Computer -ComputerName "A" -NewName "A1" -DomainCredential (Get-Credential) -Force -Restart
# Erreur typique :
# Cannot establish the WMI connection… The RPC server is unavailable (0x800706BA)
Le code 0x800706BA
signifie que la pile RPC n’a pas pu joindre ou établir une session avec l’hôte distant. Dans le contexte PowerShell, Rename-Computer
avec -ComputerName
s’appuie sur WMI/DCOM, qui lui-même dépend d’RPC.
Pourquoi cette erreur survient
Le transport WMI/DCOM ouvre une session via l’Endpoint Mapper RPC sur le port TCP 135, puis négocie un port dynamique côté cible. Sur Windows récents, ce sont généralement des ports dans l’intervalle 49152–65535/TCP (anciens OS : 1024–65535/TCP). Si le pare‑feu ou un équipement intermédiaire filtre ces flux, vous obtenez « RPC server is unavailable ».
Essentiel : dans l’immense majorité des cas, le problème est (1) une règle de pare-feu manquante, (2) une résolution DNS défaillante, (3) des services RPC/WMI arrêtés, ou (4) une dérive d’horloge cassant l’authentification.
Vue d’ensemble : composants & ports
Composant | Port(s) TCP | Rôle |
---|---|---|
RPC Endpoint Mapper | 135 | Point d’entrée RPC pour négocier un port dynamique |
RPC dynamique (DCOM/WMI) | 49152–65535 (récents) / 1024–65535 (anciens) | Canal de données pour les appels WMI/DCOM |
WinRM (alternative) | 5985 (HTTP), 5986 (HTTPS) | Transport WSMan, ne dépend pas de DCOM |
Check‑list de diagnostic rapide
Exécutez les tests suivants depuis votre poste d’administration (remplacez A
par le nom ou l’IP de la cible) :
Connectivité & ports
# Le 135 doit répondre (Endpoint Mapper)
Test-NetConnection A -Port 135
# (En environnement filtré) Vérifiez aussi qu’un flux entrant 49152–65535/TCP est autorisé vers A
# Ce test se fait côté réseau/pare-feu ; côté PowerShell, un test WMI est plus parlant :
Get-WmiObject Win32\_OperatingSystem -ComputerName A
DNS correct
# Résolution directe
Resolve-DnsName A
# Résolution inverse (PTR)
# Remplacez \ par l'adresse de la machine A
Resolve-DnsName \ -Type PTR
# Vérifier le DC de référence & l'appartenance au domaine (optionnel)
nltest /dsgetdc\:domain.local
WMI / RPC fonctionnels
# Appel WMI de contrôle (si cela échoue avec 0x800706BA, le transport DCOM est bloqué)
Get-WmiObject Win32_OperatingSystem -ComputerName A
# État du dépôt WMI sur A (à exécuter localement ou via session distante)
winmgmt /verifyrepository
Horloge & Kerberos
# L'écart d'horloge doit rester < 5 min
w32tm /query /status
Tableau des tests rapides
Test | Commande | Attendu | Si KO |
---|---|---|---|
Port 135 | Test-NetConnection A -Port 135 | Succeeded | Ouvrir port 135/TCP vers A |
WMI à distance | Get-WmiObject Win32_OperatingSystem -ComputerName A | Retourne l’OS de A | Ouvrir groupes WMI/DCOM, vérifier services |
DNS A | Resolve-DnsName A | IP correcte | Corriger enregistrements A/AAAA |
PTR | Resolve-DnsName <IP_dA> -Type PTR | Nom FQDN de A | Créer/mettre à jour l’enregistrement PTR |
Horloge | w32tm /query /status | Décalage faible (< 5 min) | w32tm /resync , NTP/DC |
Correctifs — ordre recommandé
Ouvrir les règles Pare‑feu Windows sur la cible
Activez les groupes de règles dédiés plutôt que de couper le pare‑feu. Sur la machine A (ou via GPO) :
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"
Enable-NetFirewallRule -DisplayGroup "COM+ Network Access"
Enable-NetFirewallRule -DisplayGroup "Remote Service Management"
Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management"
Si un NGFW intermédiaire existe, autorisez TCP 135 et 49152–65535/TCP depuis vos hôtes d’administration vers A. Sur des environnements très verrouillés, envisagez de contourner DCOM (voir WinRM ci‑dessous) plutôt que d’ouvrir un large éventail de ports.
Vérifier/relancer les services indispensables
# Sur la cible A
Get-Service RpcEptMapper, RpcSs, DcomLaunch, Winmgmt | Format-Table Name, Status, StartType
# Redémarrer WMI si nécessaire
Restart-Service Winmgmt -Force
Les services ci‑dessus doivent être en Running avec un démarrage Automatic.
Corriger la résolution DNS
- La carte réseau de A doit pointer vers les DNS du domaine (contrôleurs de domaine).
- Purger/renouveler si doute :
ipconfig /flushdns
ipconfig /registerdns
Synchroniser l’heure
w32tm /resync /rediscover
Un écart important d’horloge (skew) casse Kerberos et peut faire échouer l’authentification nécessaire au renommage.
Alternative recommandée : basculer vers WinRM (WSMan)
Plutôt que d’ouvrir des milliers de ports pour DCOM, utilisez WinRM : un transport moderne, sécurisé et stable, écoutant sur 5985/5986.
- Sur A (ou via GPO) :
Enable-PSRemoting -Force
(ouvre automatiquement les règles « Windows Remote Management »). - Depuis le poste d’administration :
# Vérification de la connectivité WSMan
Test-WSMan A
# Renommage via session distante (ne dépend pas de DCOM)
Invoke-Command -ComputerName A -ScriptBlock {
Rename-Computer -NewName 'A1' -Force -Restart
} -Credential (Get-Credential)
# Variante CIM/WSMan (recommandée pour des scripts)
\$cim = New-CimSession -ComputerName A # par défaut WSMan
Rename-Computer -CimSession \$cim -NewName 'A1' -Force -Restart
Remove-CimSession \$cim
Avantages : exposition réseau minimale (5985/5986), authentification Kerberos intégrée en environnement AD, auditabilité.
Méthode locale (si accès interactif possible)
Si le réseau bloque les appels distants, exécutez la commande sur la machine cible :
Rename-Computer -NewName 'A1' -DomainCredential (Get-Credential) -Force -Restart
Scripts prêts à l’emploi
Renommer un lot de machines via WinRM
$todo = @(
@{Old='A'; New='A1'}
@{Old='B'; New='B1'}
@{Old='C'; New='C1'}
)
\$cred = Get-Credential
foreach (\$item in \$todo) {
try {
Write-Host "Renommage \$(\$item.Old) → \$(\$item.New)"
Invoke-Command -ComputerName \$item.Old -Credential \$cred -ScriptBlock {
param(\$targetName)
Rename-Computer -NewName \$targetName -Force -Restart
} -ArgumentList \$item.New -ErrorAction Stop
} catch {
Write-Warning "Échec sur \$(\$item.Old) : \$($\_.Exception.Message)"
}
}
Audit express des prérequis (diagnostic)
La fonction ci‑dessous exécute un audit minimal et renvoie un objet synthétique. Pratique pour des rapports rapides :
function Test-RemoteRenamePrereqs {
[CmdletBinding()]
param(
[Parameter(Mandatory)]
[string]$ComputerName
)
\$result = \[ordered]@{
ComputerName = \$ComputerName
DnsA = \$false
DnsPtr = \$false
Rpc135 = \$false
WmiRemote = \$false
WsMan = \$false
TimeDriftOk = \$null
Notes = @()
}
try {
\$a = Resolve-DnsName -Name \$ComputerName -ErrorAction Stop
if (\$a) { \$result.DnsA = \$true }
} catch { \$result.Notes += "DNS A introuvable: \$($\_.Exception.Message)" }
try {
\$ip = (Resolve-DnsName -Name \$ComputerName -Type A -ErrorAction Stop |
Where-Object { \$*.IPAddress } | Select-Object -First 1 -ExpandProperty IPAddress)
if (\$ip) {
\$ptr = Resolve-DnsName -Name \$ip -Type PTR -ErrorAction Stop
if (\$ptr) { \$result.DnsPtr = \$true }
}
} catch { \$result.Notes += "PTR manquant/incohérent: \$(\$*.Exception.Message)" }
try {
\$rpc = Test-NetConnection -ComputerName \$ComputerName -Port 135 -InformationLevel Detailed
\$result.Rpc135 = \[bool]\$rpc.TcpTestSucceeded
if (-not \$result.Rpc135) { \$result.Notes += "Port 135/TCP fermé" }
} catch { \$result.Notes += "Test 135 en erreur: \$($\_.Exception.Message)" }
try {
\$wmi = Get-WmiObject -Class Win32\_OperatingSystem -ComputerName \$ComputerName -ErrorAction Stop
\$result.WmiRemote = \$true
} catch { \$result.Notes += "WMI/DCOM inaccessible: \$($\_.Exception.Message)" }
try {
\$ws = Test-WSMan -ComputerName \$ComputerName -ErrorAction Stop
\$result.WsMan = \$true
} catch { \$result.Notes += "WSMan/WinRM indisponible: \$($\_.Exception.Message)" }
try {
\$status = & w32tm /query /status 2>&1
\$skew = (\$status | Select-String -Pattern 'Phase Offset:\s\*(\[-\d.,]+)s').Matches.Groups\[1].Value
if (\$skew) {
\$offset = \[double]\(\$skew -replace ',', '.')
\$result.TimeDriftOk = \[math]::Abs(\$offset) -lt 300
if (-not \$result.TimeDriftOk) { \$result.Notes += "Décalage d'horloge > 5 min" }
}
} catch { \$result.Notes += "Impossible de lire l'état temps local: \$($\_.Exception.Message)" }
\[pscustomobject]\$result
}
Exemple d’usage :
Test-RemoteRenamePrereqs -ComputerName A | Format-List
Points d’attention fréquents
- GPO / EDR : certaines politiques ou agents de sécurité bloquent WMI/DCOM. Documentez des exceptions dédiées pour l’OU des postes à administrer.
- Profil de pare‑feu : assurez‑vous que la cible utilise le profil Domaine (et pas Public). Un poste isolé du DC peut basculer en Public et refuser la gestion distante.
- Droits AD : un manque de droits se traduit plutôt par « Access denied » que par
0x800706BA
. Vérifiez néanmoins que le compte utilisé est autorisé à renommer l’objet ordinateur. - VPN / segmentation : le split‑tunneling ou une ACL latérale peuvent autoriser 135 mais pas les ports dynamiques. Résultat : 0x800706BA persiste. Envisagez WinRM (5985/5986) pour contourner DCOM.
- Oldies : avec des OS très anciens, l’intervalle de ports dynamiques peut différer. Tenez compte de l’âge du système dans vos ACL.
Procédure « post‑rename »
Après redémarrage de A (devenu A1) :
hostname # Doit afficher A1
Resolve-DnsName A1 # Vérifier la MAJ DNS
Get-ADComputer -Identity A1 -Properties * | Select-Object Name, DNSHostName, IPv4Address, whenChanged
Arbre de décision pratique
- 135/TCP OK ? Si non → ouvrir 135.
- WMI à distance OK ? Si non → ouvrir groupes WMI/DCOM et vérifier
Winmgmt
. - DNS OK ? Si non → corriger A/PTR, purger caches.
- Horloge OK ? Si non → resynchroniser (
w32tm
). - Toujours KO ? Basculer sur WinRM et utiliser
Invoke-Command
ou-CimSession
.
FAQ express
Faut‑il obligatoirement -DomainCredential
?
Oui pour un poste déjà joint au domaine, afin de mettre à jour l’objet AD et éviter des décalages entre le nom NetBIOS/DNS local et l’annuaire.
Pourquoi Get-WmiObject
pour tester ?
Parce que Get-WmiObject
utilise DCOM/RPC : s’il échoue avec 0x800706BA, vous confirmez un blocage RPC côté réseau ou services.
Et Get-CimInstance
?
Par défaut, il s’appuie sur WSMan (WinRM). Si WinRM n’est pas configuré, le test sera négatif même si DCOM fonctionnait : utilisez‑le pour valider l’alternative WSMan.
En bref : plan d’action recommandé
- Tester 135/TCP et la résolution DNS → ouvrir/ajuster pare‑feu si nécessaire.
- Vérifier services RPC/WMI et l’heure du système.
- Si l’environnement bloque les ports dynamiques, basculer vers WinRM pour exécuter
Rename-Computer
sans DCOM.
Annexe : appliquer via GPO (optionnel)
Pour industrialiser l’ouverture des ports nécessaires ou l’activation de WinRM :
- Pare‑feu : créez une GPO « Activer WMI/DCOM pour administration » qui active les groupes de règles cités plus haut.
- WinRM : dans les Modèles d’administration → Composants Windows → Windows Remote Management (WinRM), activez le service et configurez l’écoute. Ajoutez les règles « Windows Remote Management » au pare‑feu.
Cette approche évite les interventions manuelles machine par machine et stabilise vos opérations de renommage en continu.
Conclusion
« RPC server is unavailable (0x800706BA) » lors d’un Rename-Computer
distant signale quasi toujours un problème transport : ports RPC/Dynamic filtrés, DNS cassé, services à l’arrêt, ou décalage d’horloge. Le diagnostic pas à pas ci‑dessus permet d’isoler la cause en minutes. Et lorsque l’ouverture large de ports RPC n’est pas souhaitable, la solution WinRM/WSMan offre un chemin fiable et sécurisé pour renommer vos machines, au cas par cas ou à grande échelle.