Domande frequenti sulla comunicazione remota di PowerShell

Sì. Per funzionare in modalità remota, i computer locali e remoti devono avere PowerShell, Microsoft .NET Framework e il protocollo Servizi Web per la gestione (WS-Management). Tutti i file e altre risorse necessarie per eseguire un comando specifico devono trovarsi nel computer remoto.

I computer che eseguono Windows PowerShell 3.0 e i computer che eseguono Windows PowerShell 2.0 possono connettersi tra loro in remoto ed eseguire comandi remoti. Tuttavia, alcune funzionalità, ad esempio la possibilità di disconnettersi da una sessione e riconnettersi, funzionano solo quando entrambi i computer eseguono Windows PowerShell 3.0.

È necessario disporre dell'autorizzazione per connettersi al computer remoto, l'autorizzazione per eseguire PowerShell e l'autorizzazione per accedere agli archivi dati (ad esempio file e cartelle) e al Registro di sistema nel computer remoto.

Per altre informazioni, vedere about_Remote_Requirements.

Quando si invia un comando remoto, il comando viene trasmesso attraverso la rete al motore di PowerShell nel computer remoto e viene eseguito nel client PowerShell nel computer remoto. I risultati del comando vengono inviati al computer locale e visualizzati nella sessione di PowerShell nel computer locale.

Per trasmettere i comandi e ricevere l'output, PowerShell usa il protocollo WS-Management. Per informazioni sul protocollo WS-Management, vedere WS-Management Protocol nella documentazione di Windows.

A partire da Windows PowerShell 3.0, le sessioni remote vengono archiviate nel computer remoto. In questo modo è possibile disconnettersi dalla sessione e riconnettersi da una sessione diversa o da un altro computer senza interrompere i comandi o perdere lo stato.

Quando ci si connette a un computer remoto, il sistema usa le credenziali di nome utente e password nel computer locale o le credenziali fornite nel comando per accedere al computer remoto. Le credenziali e il resto della trasmissione vengono crittografate.

Per aggiungere ulteriore protezione, è possibile configurare il computer remoto per l'uso di Secure Sockets Layer (SSL) anziché HTTP per l'ascolto delle richieste di Gestione remota Windows (WinRM). Gli utenti possono quindi usare il parametro UseSSL dei Invoke-Commandcmdlet , New-PSSessione Enter-PSSession quando si stabilisce una connessione. Questa opzione usa il canale HTTPS più sicuro anziché HTTP.

No. Alcuni cmdlet hanno un parametro ComputerName che consente di ottenere oggetti dal computer remoto.

Questi cmdlet non usano la comunicazione remota di PowerShell. È quindi possibile usarli in qualsiasi computer che esegue PowerShell, anche se il computer non è configurato per la comunicazione remota di PowerShell o se il computer non soddisfa i requisiti per la comunicazione remota di PowerShell.

Questi cmdlet includono quanto segue:

• Get-Hotfix
• Rename-Computer
• Restart-Computer
• Stop-Computer

Per trovare tutti i cmdlet con un parametro ComputerName , digitare:

Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName

Per determinare se il parametro ComputerName di un cmdlet specifico richiede la comunicazione remota di PowerShell, vedere la descrizione del parametro. Per visualizzare la descrizione del parametro, digitare:

Get-Help <cmdlet-name> -Parameter ComputerName

Ad esempio:

Get-Help Get-Hotfix -Parameter ComputerName

Per tutti gli altri comandi, usare il Invoke-Command cmdlet .

Per eseguire un comando in un computer remoto, usare il Invoke-Command cmdlet .

Racchiudere il comando tra parentesi graffe ({}) per renderlo un blocco di script. Usare il parametro ScriptBlock di Invoke-Command per specificare il comando .

È possibile utilizzare il parametro ComputerName di Invoke-Command per specificare un computer remoto. In alternativa, è possibile creare una connessione permanente a un computer remoto (una sessione) e quindi usare il parametro Session di Invoke-Command per eseguire il comando nella sessione.

Ad esempio, i comandi seguenti eseguono un Get-Process comando in modalità remota.

Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}

#  - OR -

Invoke-Command -Session $s -ScriptBlock {Get-Process}

Per interrompere un comando remoto, digitare CTRL+C. La richiesta di interruzione viene passata al computer remoto, in cui termina il comando remoto.

Per altre informazioni sui comandi remoti, vedere about_Remote e gli argomenti della Guida per i cmdlet che supportano la comunicazione remota.

È possibile usare il Enter-PSSession cmdlet per avviare una sessione interattiva con un computer remoto.

Al prompt di PowerShell digitare:

Enter-PSSession <ComputerName>

Il prompt dei comandi cambia per indicare che si è connessi al computer remoto.

<ComputerName>\C:>

Ora, i comandi digitati vengono eseguiti nel computer remoto esattamente come se li digitassero direttamente nel computer remoto.

Per terminare una sessione interattiva, digitare:

Exit-PSSession

Una sessione interattiva è una sessione persistente che usa il protocollo WS-Management. Non è uguale all'uso di Telnet, ma offre un'esperienza simile.

Per ulteriori informazioni, vedere Enter-PSSession.

Sì. È possibile eseguire comandi remoti specificando il nome del computer remoto, il relativo nome NetBIOS o il relativo indirizzo IP. In alternativa, è possibile eseguire comandi remoti specificando una sessione di PowerShell (PSSession) connessa al computer remoto.

Quando si usa il parametro ComputerName di Invoke-Command o Enter-PSSession, PowerShell stabilisce una connessione temporanea. PowerShell usa la connessione per eseguire solo il comando corrente e quindi chiude la connessione. Si tratta di un metodo molto efficiente per l'esecuzione di un singolo comando o di diversi comandi non correlati, anche in molti computer remoti.

Quando si usa il New-PSSession cmdlet per creare una sessione PSSession, PowerShell stabilisce una connessione permanente per la sessione PSSession. È quindi possibile eseguire più comandi nella sessione PSSession, inclusi i comandi che condividono i dati.

In genere, si crea una sessione PSSession per eseguire una serie di comandi correlati che condividono dati. In caso contrario, la connessione temporanea creata dal parametro ComputerName è sufficiente per la maggior parte dei comandi.

Per altre informazioni sulle sessioni, vedere about_PSSessions.

Sì. Il parametro ComputerName del Invoke-Command cmdlet accetta più nomi di computer e il parametro Session accetta più sessioni PSSession.

Quando si esegue un Invoke-Command comando, PowerShell esegue i comandi in tutti i computer specificati o in tutte le sessioni PSSession specificate.

PowerShell può gestire centinaia di connessioni remote simultanee. Tuttavia, il numero di comandi remoti che è possibile inviare potrebbe essere limitato dalle risorse del computer e dalla sua capacità di stabilire e gestire più connessioni di rete.

Per altre informazioni, vedere l'esempio nell'argomento della Invoke-Command Guida.

I profili di PowerShell non vengono eseguiti automaticamente nelle sessioni remote, quindi i comandi aggiunti dal profilo non sono presenti nella sessione. Inoltre, la $profile variabile automatica non viene popolata nelle sessioni remote.

Per eseguire un profilo in una sessione, usare il Invoke-Command cmdlet .

Ad esempio, il comando seguente esegue il profilo CurrentUserCurrentHost dal computer locale nella sessione in $s.

Invoke-Command -Session $s -FilePath $profile

Il comando seguente esegue il profilo CurrentUserCurrentHost dal computer remoto nella sessione in $s. Poiché la $profile variabile non viene popolata, il comando usa il percorso esplicito del profilo.

Invoke-Command -Session $s {
  . "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}

Dopo aver eseguito questo comando, i comandi aggiunti dal profilo alla sessione sono disponibili in $s.

È anche possibile usare uno script di avvio in una configurazione di sessione per eseguire un profilo in ogni sessione remota che usa la configurazione della sessione.

Per altre informazioni sui profili di PowerShell, vedere about_Profiles. Per altre informazioni sulle configurazioni di sessione, vedere Register-PSSessionConfiguration.

Per gestire le risorse nel computer locale, PowerShell include una funzionalità di limitazione per comando che consente di limitare il numero di connessioni remote simultanee stabilite per ogni comando.

Il valore predefinito è 32 connessioni simultanee, ma è possibile usare il parametro ThrottleLimit dei cmdlet per impostare un limite di limitazione personalizzato per determinati comandi.

Quando si usa la funzionalità di limitazione, tenere presente che viene applicata a ogni comando, non all'intera sessione o al computer. Se si eseguono comandi simultaneamente in più sessioni o SESSIONI PSSession, il numero di connessioni simultanee è la somma delle connessioni simultanee in tutte le sessioni.

Per trovare i cmdlet con un parametro ThrottleLimit , digitare:

Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit

Quando si usa PowerShell in locale, si inviano e si ricevono oggetti .NET Framework in tempo reale; Gli oggetti "live" sono oggetti associati a programmi o componenti di sistema effettivi. Quando si richiamano i metodi o si modificano le proprietà degli oggetti attivi, le modifiche influiscono sul programma o sul componente effettivo. Inoltre, quando cambiano le proprietà di un programma o di un componente, cambiano anche le proprietà dell'oggetto che le rappresentano.

Tuttavia, poiché la maggior parte degli oggetti live non può essere trasmessa in rete, PowerShell "serializza" la maggior parte degli oggetti inviati in comandi remoti, ovvero converte ogni oggetto in una serie di elementi di dati XML (Constraint Language in XML [CLiXML]) per la trasmissione.

Quando PowerShell riceve un oggetto serializzato, converte il codice XML in un tipo di oggetto deserializzato. L'oggetto deserializzato è un record accurato delle proprietà del programma o del componente in un momento precedente, ma non è più "attivo", ovvero non è più associato direttamente al componente. E i metodi vengono rimossi perché non sono più efficaci.

In genere, è possibile usare oggetti deserializzati esattamente come si userebbero oggetti attivi, ma è necessario tenere presente le relative limitazioni. Inoltre, gli oggetti restituiti dal Invoke-Command cmdlet hanno proprietà aggiuntive che consentono di determinare l'origine del comando.

Alcuni tipi di oggetto, ad esempio oggetti DirectoryInfo e GUID, vengono convertiti nuovamente in oggetti attivi quando vengono ricevuti. Questi oggetti non richiedono alcuna gestione o formattazione speciale.

Per informazioni sull'interpretazione e la formattazione dell'output remoto, vedere about_Remote_Output.

Sì. Un processo in background di PowerShell è un comando di PowerShell che viene eseguito in modo asincrono senza interagire con la sessione. Quando si avvia un processo in background, il prompt dei comandi viene restituito immediatamente ed è possibile continuare a lavorare nella sessione durante l'esecuzione del processo anche se viene eseguito per un lungo periodo di tempo.

È possibile avviare un processo in background anche mentre altri comandi sono in esecuzione perché i processi in background vengono sempre eseguiti in modo asincrono in una sessione temporanea.

È possibile eseguire processi in background in un computer locale o remoto. Per impostazione predefinita, un processo in background viene eseguito nel computer locale. Tuttavia, è possibile usare il parametro AsJob del Invoke-Command cmdlet per eseguire qualsiasi comando remoto come processo in background. È anche possibile usare Invoke-Command per eseguire un Start-Job comando in modalità remota.

Per altre informazioni sui processi in background in PowerShell, vedere about_Jobs e about_Remote_Jobs.

È possibile usare i comandi remoti di PowerShell per eseguire programmi basati su Windows in computer remoti. Ad esempio, è possibile eseguire Shutdown.exe o Ipconfig.exe in un computer remoto.

Tuttavia, non è possibile usare i comandi di PowerShell per aprire l'interfaccia utente per qualsiasi programma in un computer remoto.

Quando si avvia un programma Windows in un computer remoto, il comando non viene completato e il prompt dei comandi di PowerShell non viene restituito fino al termine del programma o fino a quando non si preme CTRL+C per interrompere il comando. Ad esempio, se si esegue il Ipconfig.exe programma in un computer remoto, il prompt dei comandi non viene restituito fino al Ipconfig.exe completamento.

Se si usano comandi remoti per avviare un programma con un'interfaccia utente, il processo del programma viene avviato, ma l'interfaccia utente non viene visualizzata. Il comando di PowerShell non viene completato e il prompt dei comandi non viene restituito fino a quando non si arresta il processo del programma o finché non si preme CTRL+C, che interrompe il comando e arresta il processo.

Ad esempio, se si usa un comando di PowerShell per l'esecuzione Notepad in un computer remoto, il processo di Blocco note viene avviato nel computer remoto, ma l'interfaccia utente Blocco note non viene visualizzata. Per interrompere il comando e ripristinare il prompt dei comandi, premere CTRL+C.

Sì. Ogni sessione remota deve usare una delle configurazioni di sessione nel computer remoto. È possibile gestire le configurazioni di sessione nel computer e le autorizzazioni per tali configurazioni di sessione per determinare chi può eseguire i comandi in remoto nel computer e quali comandi possono eseguire.

Una configurazione di sessione configura l'ambiente per la sessione. È possibile definire la configurazione usando un assembly che implementa una nuova classe di configurazione o usando uno script eseguito nella sessione. La configurazione può determinare i comandi disponibili nella sessione. Inoltre, la configurazione può includere impostazioni che proteggono il computer, ad esempio le impostazioni che limitano la quantità di dati che la sessione può ricevere in remoto in un singolo oggetto o comando. È anche possibile specificare un descrittore di sicurezza che determina le autorizzazioni necessarie per usare la configurazione.

Il Enable-PSRemoting cmdlet crea le configurazioni di sessione predefinite nel computer: Microsoft.PowerShell, Microsoft.PowerShell.Workflow e Microsoft.PowerShell32 (solo sistemi operativi a 64 bit). Enable-PSRemotingimposta il descrittore di sicurezza per la configurazione per consentire l'uso solo dei membri del gruppo Amministrazione istrators nel computer.

È possibile usare i cmdlet di configurazione della sessione per modificare le configurazioni di sessione predefinite, creare nuove configurazioni di sessione e modificare i descrittori di sicurezza di tutte le configurazioni di sessione.

A partire da Windows PowerShell 3.0, il New-PSSessionConfigurationFile cmdlet consente di creare configurazioni di sessione personalizzate usando un file di testo. Il file include opzioni per impostare la modalità lingua e per specificare i cmdlet e i moduli disponibili nelle sessioni che usano la configurazione di sessione.

Quando gli utenti usano i Invoke-Commandcmdlet , New-PSSessiono Enter-PSSession , possono usare il parametro ConfigurationName per indicare la configurazione di sessione usata per la sessione. E possono modificare la configurazione predefinita usata dalle sessioni modificando il valore della $PSSessionConfigurationName variabile di preferenza nella sessione.

Per altre informazioni sulle configurazioni di sessione, vedere la Guida per i cmdlet di configurazione della sessione. Per trovare i cmdlet di configurazione della sessione, digitare:

Get-Command *PSSessionConfiguration

Lo scenario di comunicazione remota di PowerShell più comune che coinvolge più computer è la configurazione uno-a-molti, in cui un computer locale (computer dell'amministratore) esegue i comandi di PowerShell in numerosi computer remoti. Questo scenario è noto come "fan-out".

In alcune aziende, tuttavia, la configurazione è molti-a-uno, in cui molti computer client si connettono a un singolo computer remoto che esegue PowerShell, ad esempio un file server o un chiosco multimediale. Questa configurazione è nota come configurazione "fan-in".

La comunicazione remota di PowerShell supporta sia configurazioni fan-out che fan-in.

Per la configurazione fan-out, PowerShell usa il protocollo Web Services for Management (WS-Management) e il servizio WinRM che supporta l'implementazione Microsoft di WS-Management. Quando un computer locale si connette a un computer remoto, WS-Management stabilisce una connessione e usa un plug-in per PowerShell per avviare il processo host di PowerShell (Wsmprovhost.exe) nel computer remoto. L'utente può specificare una porta alternativa, una configurazione di sessione alternativa e altre funzionalità per personalizzare la connessione remota.

Per supportare la configurazione "fan-in", PowerShell usa Internet Information Services (IIS) per ospitare WS-Management, per caricare il plug-in PowerShell e per avviare PowerShell. In questo scenario, invece di avviare ogni sessione di PowerShell in un processo separato, tutte le sessioni di PowerShell vengono eseguite nello stesso processo host.

L'hosting IIS e la gestione remota della ventola non sono supportati in Windows XP o in Windows Server 2003.

In una configurazione fan-in, l'utente può specificare un URI di connessione e un endpoint HTTP, inclusi il trasporto, il nome computer, la porta e il nome dell'applicazione. IIS inoltra tutte le richieste con un nome di applicazione specificato all'applicazione. Il valore predefinito è WS-Management, che può ospitare PowerShell.

È anche possibile specificare un meccanismo di autenticazione e impedire o consentire il reindirizzamento dagli endpoint HTTP e HTTPS.

Sì. La comunicazione remota di PowerShell è disponibile anche quando il computer locale non si trova in un dominio. È possibile usare le funzionalità di comunicazione remota per connettersi alle sessioni e per creare sessioni nello stesso computer. Le funzionalità funzionano allo stesso modo quando ci si connette a un computer remoto.

Per eseguire comandi remoti in un computer in un gruppo di lavoro, modificare le impostazioni di Windows seguenti nel computer.

Attenzione: queste impostazioni influiscono su tutti gli utenti del sistema e possono rendere il sistema più vulnerabile a un attacco dannoso. Prestare attenzione quando si apportano queste modifiche.

• Windows Vista, Windows 7, Windows 8:

  Creare la voce del Registro di sistema seguente e quindi impostarne il valore su 1: LocalAccountTokenFilterPolicy in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  Per aggiungere questa voce, è possibile usare il comando di PowerShell seguente:

  $parameters = @{
    Path='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
    Name='LocalAccountTokenFilterPolicy'
    propertyType='DWord'
    Value=1
  }
  New-ItemProperty @parameters
  

• Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2:

  Non sono necessarie modifiche perché l'impostazione predefinita del criterio "Accesso alla rete: condivisione e sicurezza per gli account locali" è "Classica". Verificare l'impostazione nel caso in cui sia stata modificata.

Sì. In genere, i comandi vengono eseguiti senza errori, anche se potrebbe essere necessario usare il parametro Credential dei Invoke-Commandcmdlet , New-PSSessiono Enter-PSSession per fornire le credenziali di un membro del gruppo Amministrazione istrators nel computer remoto. Ciò è talvolta necessario anche quando l'utente corrente è membro del gruppo Amministrazione istrators nei computer locali e remoti.

Tuttavia, se il computer remoto non si trova in un dominio attendibile dal computer locale, il computer remoto potrebbe non essere in grado di autenticare le credenziali dell'utente.

Per abilitare l'autenticazione, usare il comando seguente per aggiungere il computer remoto all'elenco di host attendibili per il computer locale in WinRM. Digitare il comando al prompt di PowerShell.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>

Ad esempio, per aggiungere il computer Server01 all'elenco di host attendibili nel computer locale, digitare il comando seguente al prompt di PowerShell:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01

Sì. Per altre informazioni, vedere Comunicazione remota di PowerShell su SSH.

Vedi anche

about_Remote

about_Profiles

about_PSSessions

about_Remote_Jobs

about_Remote_Variables

Invoke-Command

New-PSSession