Windows Server 2025 / Usare PowerShell remoting con WinRM

PowerShell remoting consente di inviare comandi a un altro server o aprirvi una console interattiva. Su Windows Server 2025, controlla il servizio Windows Remote Management (WinRM), il punto di accesso della sessione (endpoint) e l’autenticazione prima di usare Enter-PSSession o Invoke-Command.

Separa la configurazione del server dalla connessione del client

Configura la ricezione delle connessioni dalla console di FS1 ed esegui i comandi di connessione sul PC di gestione. Invertire le posizioni può aprire listener non necessari o interrogare il computer sbagliato. La procedura usa Windows PowerShell 5.1 tramite WinRM e non il trasporto SSH (Secure Shell). Esegui le istruzioni in modo interattivo e per sezioni, senza riunire tutti i blocchi in un solo script.

• Identifica FS1 e un account amministratore valido per quel server.
• Usa la rete di gestione isolata prevista.
• Mantieni disponibile la console di FS1 per verificare lo stato e recuperare l’accesso.

Su FS1, apri Windows PowerShell con Esegui come amministratore e registra lo stato iniziale: il remoting potrebbe essere già configurato. Get-Service mostra lo stato del servizio, Get-PSSessionConfiguration elenca gli endpoint PowerShell e Test-WSMan localhost verifica la risposta WinRM locale. In una configurazione funzionante, attenditi WinRM in stato Running, configurazioni di sessione disponibili e una risposta WS-Management invece di un errore. Questo controllo locale non dimostra la raggiungibilità dal client né il suo diritto a eseguire comandi:

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Configura il server solo se necessario

Se la ricezione remota non è configurata, verifica prima hostname dalla console di FS1, poi esegui Enable-PSRemoting. Il comando può avviare o riavviare WinRM, creare listener, abilitare configurazioni di sessione e modificare le regole del firewall. -Force elimina le richieste di conferma, ma non sostituisce i privilegi necessari e non evita gli effetti di un’esecuzione sul computer sbagliato. Un PC che invia soltanto comandi non richiede questa configurazione per riceverli.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Limita l’origine al PC o alla subnet di gestione necessari. In wf.msc → Regole connessioni in entrata, controlla le regole WinRM, il profilo attivo, la porta e gli indirizzi remoti, comprese eventuali altre regole con ambito più ampio. Non disattivare il firewall e non cambiare arbitrariamente profilo di rete per risolvere un errore. Le porte predefinite WinRM sono TCP 5985 per HTTP e TCP 5986 per HTTPS.

Un listener HTTP non significa da solo che i messaggi autenticati viaggino senza protezione. Con Kerberos o NTLM (NT LAN Manager), WinRM cifra i messaggi dopo l’autenticazione; HTTPS protegge anche il trasporto e richiede configurazione e verifica del certificato. L’identità del server resta un controllo distinto. Consulta la documentazione sulla sicurezza di autenticazione e messaggi WinRM prima di scegliere la configurazione.

Usa il nome del server quando il dominio è pronto

Questa alternativa richiede che PC e FS1 siano già nello stesso dominio, che il sistema dei nomi di dominio (DNS, Domain Name System) e la sincronizzazione dell’ora funzionino e che l’account abbia i permessi necessari. Non aspettarti successo prima di configurare il dominio. Enter-PSSession apre una sessione interattiva: esegui la connessione, attendi il prompt con il nome del server e poi inserisci hostname, whoami ed Exit-PSSession uno alla volta.

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

Dopo una connessione riuscita, hostname deve identificare FS1 e whoami mostrare l’identità prevista. Exit-PSSession riporta al PC di gestione. Quando il DNS di dominio è disponibile, usa il nome di dominio completo (FQDN, Fully Qualified Domain Name): l’indirizzo IP non usa la stessa autenticazione Kerberos del nome del server.

Limita l’elenco di attendibilità nell’alternativa del gruppo di lavoro

Le connessioni tramite IP o gruppo di lavoro richiedono condizioni aggiuntive: HTTPS configurato correttamente oppure una voce specifica TrustedHosts, oltre a credenziali esplicite. La guida alla risoluzione dei problemi di connessione remota illustra i requisiti. TrustedHosts sopprime un errore di verifica dell’identità e non autentica il server. Per l’uso operativo considera HTTPS con un certificato attendibile e rispetta i criteri di autenticazione dell’organizzazione.

Nel laboratorio isolato, verifica l’IP effettivo di FS1 dalla sua console. Sul PC di gestione, apri Windows PowerShell come amministratore e assicurati che WinRM sia disponibile per accedere a WSMan:. L’esempio salva l’elenco precedente e aggiunge una destinazione; i caratteri jolly già presenti restano validi. Controlla quindi il valore iniziale: TrustedHosts influisce su tutti gli utenti del PC. Non sostituire l’elenco con un carattere jolly globale.

Sostituisci FS1\Administrator nell’esempio con l’account amministratore effettivo di FS1, dotato di password non vuota. Get-Credential con -UserName può chiedere prima il parametro obbligatorio Message in Windows PowerShell 5.1. Inserisci una descrizione della richiesta, non la password; immetti poi le credenziali nella richiesta di autenticazione. Avvia Enter-PSSession interattivamente, verifica hostname dopo l’ingresso e torna al PC con Exit-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

Gli account amministratore locali creati manualmente possono essere soggetti alle restrizioni remote del Controllo account utente (UAC, User Account Control). Rivedi autenticazione e permessi senza disabilitare queste protezioni in modo generale. Dopo essere tornato al PC, ripristina il valore iniziale nella stessa finestra PowerShell locale in cui hai salvato $previousHosts. Verifica che non siano sopraggiunte modifiche altrui da conservare. Se hai chiuso la finestra e perso la variabile, non presumere che l’elenco originale fosse vuoto:

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

Esegui una query remota e verifica l’origine del risultato

Quando i prerequisiti del dominio sono soddisfatti, esegui questa query dal PC di gestione per ottenere le informazioni del sistema operativo di FS1 senza aprire una console interattiva:

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

Controlla PSComputerName e i valori restituiti Caption, Version e LastBootUpTime per confermare il server interrogato; non scambiare un risultato locale per uno remoto. Verifica separatamente DNS, raggiungibilità della porta, risposta WinRM, autenticazione e autorizzazione della sessione. Una risposta Test-WSMan non prova il diritto a eseguire comandi. Prima di annullare modifiche a listener o servizio, controlla le dipendenze degli altri strumenti e confronta con lo stato iniziale.