Windows Server 2025 / Utiliser la communication à distance PowerShell avec WinRM

La communication à distance PowerShell envoie des commandes à un autre serveur ou ouvre un shell interactif sur celui-ci. Pour Windows Server 2025, vérifiez le point de terminaison Windows Remote Management (WinRM) et l'authentification avant d'utiliser Enter-PSSession ou Invoke-Command.

Séparez la configuration de la cible des commandes de connexion client

Exécutez la configuration de l’écouteur sur la console FS1 et les commandes de connexion sur le PC de gestion. Inverser ces emplacements peut exposer des écouteurs inutiles ou interroger le mauvais ordinateur. Cet exercice utilise la communication à distance Windows PowerShell via WinRM, pas la communication à distance PowerShell 7 via SSH.

• Identifiez FS1 et un compte administrateur valide.
• Utilisez le réseau de gestion isolé prévu.
• Gardez la console cible disponible pour la récupération.

Vérifiez l'état actuel de la cible dans Windows PowerShell ouvert en tant qu’administrateur ; la gestion à distance peut déjà être configurée :

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Configurez la cible uniquement si nécessaire

Si elle n'est pas configurée, exécutez ce qui suit sur FS1. La commande peut affecter les écouteurs, la configuration de session et les paramètres de pare-feu, il est donc recommandé de vérifier d'abord le nom de l'ordinateur.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Limitez l'accès au PC de gestion requis ou au sous-réseau. Pour les échecs liés au profil, examinez le contexte réseau réel plutôt que de désactiver le pare-feu. Les ports WinRM par défaut sont TCP 5985 pour HTTP et 5986 pour HTTPS.

Le nom d'un écouteur HTTP ne signifie pas à lui seul que le trafic de messages authentifiés est non protégé. Consultez Authentification et sécurité des messages WinRM lors de la conception de la vérification d'identité et de la protection des informations d'identification.

Utilisez des noms de serveur dans un domaine fonctionnel

Cet exemple suppose que le PC et FS1 ont rejoint le même domaine, que le DNS et l'heure fonctionnent, et que le compte dispose des autorisations nécessaires. Ne vous attendez pas à ce que cela réussisse avant que le domaine n'existe. Exécutez ces lignes une par une dans une console interactive. Après Enter-PSSession, attendez que l’invite indique le serveur distant avant de saisir les commandes suivantes ; n’exécutez pas ce bloc comme un script complet.

Test-WSMan -ComputerName 'fs1.ad.example.test'
Enter-PSSession -ComputerName 'fs1.ad.example.test'
hostname
whoami
Exit-PSSession

Les commandes saisies après Enter-PSSession s’exécutent sur la cible. Exit-PSSession permet de revenir au PC de gestion. Une adresse IP modifie les conditions d'authentification par rapport à un nom de domaine utilisant Kerberos ; privilégiez le nom de domaine complet (FQDN) lorsque le DNS du domaine est disponible.

Limitez TrustedHosts dans un groupe de travail

Les connexions basées sur un groupe de travail ou une IP nécessitent des conditions supplémentaires, telles que HTTPS ou une entrée TrustedHosts spécifique. Voir les conseils de dépannage de la communication à distance. TrustedHosts n'authentifie pas l'identité d'un serveur ; envisagez l'utilisation de HTTPS avec certificat de confiance pour un usage opérationnel.

Pour ce laboratoire isolé, vérifiez l’IP de FS1 sur sa console. Sur le PC de gestion, conservez la valeur originale et ajoutez uniquement cette cible. Remplacez le compte par l’administrateur serveur prévu ; n’utilisez pas de caractère générique pour tous les hôtes. Si la valeur existante contient déjà *, l’ajout de cette cible ne réduit pas la portée de la confiance : examinez cette configuration avant de poursuivre. Exécutez également les lignes de ce bloc une par une et attendez l’invite distante après Enter-PSSession.

$previousHosts = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$labTargets = (@($previousHosts -split ',') + '172.24.50.20' | Where-Object { $_ } | Sort-Object -Unique) -join ','
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $labTargets
$labCredential = Get-Credential -UserName 'FS1\Administrator'
Enter-PSSession -ComputerName '172.24.50.20' -Credential $labCredential
hostname
Exit-PSSession

Les comptes administrateurs locaux personnalisés peuvent rencontrer des restrictions de contrôle de compte d’utilisateur (UAC) à distance. Reconsidérez la conception de l’authentification au lieu de désactiver largement ces protections. Dans la même session sur le PC de gestion, restaurez la valeur précédente après le laboratoire :

if ([string]::IsNullOrEmpty($previousHosts)) {
    Clear-Item WSMan:\localhost\Client\TrustedHosts
} else {
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value $previousHosts
}

Exécutez une seule requête et fermez la session

Une fois que les prérequis du domaine sont satisfaits, collectez les informations sur le système d’exploitation de la cible en une seule opération :

Invoke-Command -ComputerName 'fs1.ad.example.test' -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
}

Vérifiez PSComputerName et le système d'exploitation renvoyé afin qu'un résultat local ne soit pas confondu avec un résultat distant. Résolvez séparément les problèmes de DNS, de disponibilité des ports, de réponse WinRM, d'authentification et d'autorisation de session. Une réponse Test-WSMan seule n'établit pas les droits d'exécution des commandes. Avant d'inverser les modifications des écouteurs, vérifiez si d'autres outils de gestion dépendent de WinRM et comparez avec les paramètres d'origine.