about_Remote_Troubleshooting
Descrição breve
Descreve como solucionar problemas de operações remotas no PowerShell.
Descrição longa
Antes de usar a comunicação remota do PowerShell, consulte about_Remote e about_Remote_Requirements para obter orientação sobre configuração e uso básico.
Você deve ter direitos administrativos para exibir ou alterar as configurações do computador local na WSMan: unidade. Isso inclui alterações na configuração da sessão, hosts confiáveis, portas ou ouvintes.
Você deve executar o PowerShell com a opção Executar como administrador .
Como executar como administrador
Para erro:
ERRO: Acesso negado. Você precisa executar esse cmdlet a partir de um processo elevado.
Para iniciar o Windows PowerShell com a opção Executar como administrador , clique com o botão direito do mouse no ícone do PowerShell no Menu Iniciar e selecione Executar como administrador.
Como ativar a comunicação remota
Para erros:
- ERRO: ACESSO NEGADO
- ERRO: A conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta e URL HTTP corretas.
Para receber comandos remotos, a comunicação remota do PowerShell deve estar habilitada no computador. A comunicação remota do Windows PowerShell é habilitada por padrão no Windows Server 2012 e em versões mais recentes do Windows Server. Você pode executar Enable-PSRemoting para reativar a comunicação remota se ela tiver sido desabilitada. Para obter mais informações, consulte Enable-PSRemoting.
Como habilitar a comunicação remota em uma empresa
Para erros:
- ERRO: ACESSO NEGADO
- ERRO: A conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta e URL HTTP corretas.
Para permitir que um único computador receba comandos remotos do PowerShell e aceite conexões, use o Enable-PSRemoting cmdlet.
Para habilitar a comunicação remota para vários computadores em uma empresa, você pode usar as seguintes opções dimensionadas.
- Habilite a diretiva de grupo Permitir configuração automática de ouvintes para configurar ouvintes para comunicação remota.
- Configure e habilite a diretiva de grupo Firewall do Windows: Permitir Exceções de Porta Local.
- Defina o tipo de inicialização do serviço WinRM para
Automatice inicie o serviço.
Como habilitar ouvintes usando uma diretiva de grupo
Para erros:
- ERRO: ACESSO NEGADO
- ERRO: A conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta e URL HTTP corretas.
Habilite a diretiva Permitir configuração automática de ouvintes para configurar os ouvintes para todos os computadores em um domínio.
A diretiva é encontrada no seguinte caminho de Diretiva de Grupo:
Computer Configuration\Administrative Templates\Windows Components
\Windows Remote Management (WinRM)\WinRM service
Habilite a política e especifique os filtros IPv4 e IPv6. Curingas (*) são permitidos.
Como habilitar a comunicação remota em redes públicas
Enable-PSRemoting retorna esse erro quando a rede local é pública e o parâmetro SkipNetworkProfileCheck não é usado no comando.
ERRO: Não é possível verificar o status do firewall
Em versões de servidor do Windows, Enable-PSRemoting é bem-sucedido em todos os perfis de rede. Ele cria regras de firewall que permitem o acesso remoto a redes privadas e de domínio ("Home" e "Work"). Para redes públicas, ele cria regras de firewall que permitem o acesso remoto da mesma sub-rede local.
Em versões de cliente do Windows, Enable-PSRemoting é bem-sucedido em redes privadas e de domínio. Por padrão, ele falha em redes públicas, mas se você usar o parâmetro SkipNetworkProfileCheck , Enable-PSRemoting terá êxito e criará uma regra de firewall que permita o tráfego da mesma sub-rede local.
Observação
No Windows PowerShell 2.0, em computadores que executam versões de servidor do Windows, Enable-PSRemoting cria regras de firewall que permitem o acesso remoto em redes privadas, de domínio e públicas. Em computadores que executam versões de cliente do Windows, Enable-PSRemoting cria regras de firewall que permitem acesso remoto somente em redes privadas e de domínio.
Para remover a restrição de sub-rede local em redes públicas e permitir o acesso remoto de qualquer local, execute o seguinte comando:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
O Set-NetFirewallRule cmdlet é exportado pelo módulo NetSecurity .
Observação
O nome da regra de firewall pode ser diferente para diferentes versões do Windows. Use Get-NetFirewallRule para ver uma lista de regras. Antes de habilitar a regra de firewall, exiba as configurações de segurança na regra para verificar se a configuração é apropriada para seu ambiente.
Como habilitar uma exceção de firewall usando uma diretiva de grupo
Para erros:
- ERRO: ACESSO NEGADO
- ERRO: A conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta e URL HTTP corretas.
Use a diretiva Firewall do Windows: Permitir exceções de porta local para habilitar uma exceção de firewall em todos os computadores de um domínio.
A diretiva está localizada no seguinte caminho de Diretiva de Grupo:
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
Essa diretiva permite que os membros do grupo Administradores criem uma exceção de firewall para o serviço WinRM (Gerenciamento Remoto do Windows).
Se a configuração da diretiva estiver incorreta, você pode receber o seguinte erro:
O cliente não pode se conectar ao destino especificado na solicitação. Verifique se o serviço no destino está em execução e está aceitando solicitações.
Um erro de configuração na política resulta em um valor vazio para a propriedade ListeningOn . Use o comando a seguir para verificar o valor.
Get-WSManInstance winrm/config/listener -Enumerate
cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
Source : GPO
lang : en-US
Address : *
Transport : HTTP
Port : 5985
Hostname :
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {}
Como definir o tipo de inicialização do serviço WinRM
Para erro:
ERRO: ACESSO NEGADO
A comunicação remota do PowerShell depende do serviço de Gerenciamento Remoto do Windows (WinRM). O serviço deve estar em execução para oferecer suporte a comandos remotos.
Em versões de servidor do Windows, o tipo de inicialização do serviço WinRM é Automatic.
No entanto, em versões de cliente do Windows, o serviço WinRM está desabilitado por padrão.
Use o exemplo a seguir para definir o tipo de inicialização do serviço WinRM e Automatic iniciar o serviço. O parâmetro ComputerName aceita vários valores.
$invokeCimMethodSplat = @{
ComputerName = 'Server01', 'Server02'
Query = 'Select * From Win32_Service Where Name = "WinRM"'
MethodName = 'ChangeStartMode'
Arguments = @{StartMode = 'Automatic'}
}
Invoke-CimMethod @invokeCimMethodSplat
Como recriar as configurações de sessão padrão
Para erro:
ERRO: ACESSO NEGADO
Quando você usa Enable-PSRemotingo , ele cria configurações de sessão padrão no computador local. Os usuários remotos usam essas configurações de sessão sempre que um comando remoto não inclui o parâmetro ConfigurationName .
Se as configurações padrão em um computador não forem registradas ou excluídas, use o Enable-PSRemoting cmdlet para recriá-las. Você pode usar esse cmdlet repetidamente. Ele não gera erros se um recurso já estiver configurado.
Se você alterar as configurações de sessão padrão e quiser restaurar as configurações de sessão originais, poderá excluir e recriar as configurações.
Use o Unregister-PSSessionConfiguration cmdlet para excluir as configurações de sessão alteradas. Use Enable-PSRemoting para restaurar as configurações de sessão originais. Enable-PSRemoting não altera as configurações de sessão existentes.
Observação
Quando Enable-PSRemoting restaura a configuração de sessão padrão, ela não cria descritores de segurança explícitos para as configurações. Em vez disso, as configurações herdam o descritor de segurança do RootSDDL, que é seguro por padrão.
Para ver o descritor de segurança RootSDDL , digite:
Get-Item wsman:\localhost\Service\RootSDDL
Para alterar o RootSDDL, use o Set-ItemWSMan: cmdlet na unidade. Para alterar o descritor de segurança de uma configuração de sessão, use o Set-PSSessionConfiguration cmdlet com os parâmetros SecurityDescriptorSDDL ou ShowSecurityDescriptorUI .
Para obter mais informações sobre a WSMan: unidade, consulte about_WSMan_Provider.
Como fornecer credenciais de administrador
Para erro:
ERRO: ACESSO NEGADO
Você deve ser membro do grupo Administradores conectar-se aos pontos de extremidade de sessão remota padrão. Você pode usar o parâmetro Credential do , Enter-PSSession ou Invoke-Command cmdlets para se conectar a pontos de New-PSSessionextremidade remotos usando credenciais alternativas.
O exemplo a seguir mostra como fornecer as credenciais para um usuário administrador.
Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01
Para obter mais informações sobre o parâmetro Credential , consulte a ajuda para New-PSSession, Enter-PSSession ou Invoke-Command.
Como habilitar a comunicação remota para usuários não administrativos
Para erro:
ERRO: ACESSO NEGADO
Por padrão, somente os membros do grupo Administradores em um computador têm permissão para usar as configurações de sessão padrão. Portanto, somente membros do grupo Administradores podem se conectar ao computador remotamente.
Para permitir que outros usuários se conectem ao computador local, conceda ao usuário permissões Executar para as configurações de sessão padrão no computador local.
O exemplo a seguir abre uma folha de propriedades que permite alterar o descritor de segurança da configuração de sessão padrão Microsoft.PowerShell no computador local.
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
Para obter mais informações, consulte about_Session_Configurations.
Como habilitar a comunicação remota para administradores em outros domínios
Para erro:
ERRO: ACESSO NEGADO
Quando um usuário em outro domínio é membro do grupo Administradores no computador local, o usuário não pode se conectar ao computador local remotamente com privilégios de Administrador. Por padrão, as conexões remotas de outros domínios são executadas apenas com tokens de privilégio de usuário padrão.
Você pode usar a entrada do Registro LocalAccountTokenFilterPolicy para alterar o comportamento padrão e permitir que usuários remotos que são membros do grupo Administradores sejam executados com privilégios de Administrador.
Cuidado
A entrada LocalAccountTokenFilterPolicy desabilita as restrições remotas do UAC (controle de conta de usuário) para todos os usuários de todos os computadores afetados. Considere cuidadosamente as implicações dessa configuração antes de alterar a política.
Use o comando a seguir para definir o valor do Registro LocalAccountTokenFilterPolicy como 1.
$newItemPropertySplat = @{
Name = 'LocalAccountTokenFilterPolicy'
Path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
PropertyType = 'DWord'
Value = 1
}
New-ItemProperty @newItemPropertySplat
Como usar um endereço IP em um comando remoto
Para erro:
ERRO: O cliente WinRM não é possível processar a solicitação. Se o esquema de autenticação for diferente do Kerberos ou se o computador cliente não estiver ingressado em um domínio, o transporte HTTPS deverá ser usado ou o computador de destino deverá ser adicionado à configuração TrustedHosts.
O parâmetro ComputerName do New-PSSessioncmdlets e Enter-PSSessionInvoke-Command e aceita um endereço IP como um valor válido. No entanto, porque a autenticação Kerberos não oferece suporte a endereços IP. Quando você especifica um endereço IP, a autenticação NTLM é usada.
Para oferecer suporte à autenticação NTLM, você deve atender aos seguintes requisitos:
- Configure o computador para transporte HTTPS ou adicione os endereços IP dos computadores remotos à lista TrustedHosts no computador local.
- Use o parâmetro Credential em todos os comandos remotos. Isso é necessário mesmo quando você se conecta como o usuário atual.
Como conectar-se remotamente a partir de um computador baseado em grupo de trabalho
Para erro
ERRO: O cliente WinRM não é possível processar a solicitação. Se o esquema de autenticação for diferente do Kerberos ou se o computador cliente não estiver ingressado em um domínio, o transporte HTTPS deverá ser usado ou o computador de destino deverá ser adicionado à configuração TrustedHosts.
Quando o computador local não está em um domínio, você deve atender aos seguintes requisitos:
- Configure o computador para transporte HTTPS ou adicione os endereços IP dos computadores remotos à lista TrustedHosts no computador local.
- Verifique se uma senha está definida no computador baseado em grupo de trabalho. Se uma senha não estiver definida ou o valor da senha estiver vazio, você não poderá executar comandos remotos.
- Use o parâmetro Credential em todos os comandos remotos. Isso é necessário mesmo quando você se conecta como o usuário atual.
Como adicionar um computador à lista de hosts confiáveis
O item TrustedHosts pode conter uma lista separada por vírgulas de nomes de computador, endereços IP e nomes de domínio totalmente qualificados. Caracteres curinga são permitidos.
Para exibir ou alterar a lista de hosts confiáveis, use a WSMan: unidade. O item TrustedHost está no WSMan:\localhost\Client nó. Somente os membros do grupo Administradores no computador têm permissão para alterar a lista de hosts confiáveis no computador.
Cuidado
O valor definido para o item TrustedHosts afeta todos os usuários do computador.
Para exibir a lista de hosts confiáveis, use o seguinte comando:
Get-Item wsman:\localhost\Client\TrustedHosts
O exemplo a seguir usa o caractere curinga (*) para adicionar todos os computadores à lista de hosts confiáveis.
Set-Item wsman:localhost\client\trustedhosts -Value *
Você também pode usar um caractere curinga (*) para adicionar todos os computadores em um domínio específico à lista de hosts confiáveis. Por exemplo, o comando a seguir adiciona todos os computadores no domínio da Fabrikam.
Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com
O exemplo a seguir define a lista de hosts confiáveis como um único computador.
$server = 'Server01.Domain01.Fabrikam.com'
Set-Item wsman:\localhost\Client\TrustedHosts -Value $server
Para adicionar um nome de computador a uma lista existente de hosts confiáveis, primeiro salve o valor atual em uma variável. Em seguida, defina o valor como uma cadeia de caracteres que contém uma lista separada por vírgulas que inclui os valores atuais e novos.
O exemplo a seguir adiciona Server01 a uma lista existente de hosts confiáveis.
$newServer = 'Server01.Domain01.Fabrikam.com'
$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).Value
Set-Item wsman:\localhost\Client\TrustedHosts -Value "$curValue, $newServer"
Para adicionar os endereços IP de determinados computadores à lista de hosts confiáveis, use o seguinte formato de comando:
Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>
Por exemplo:
Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0
Para adicionar um computador à lista TrustedHosts de um computador remoto, use o Connect-WSMan para conectar para WSMan: conduzir o computador remoto o uso Set-Item para adicionar o computador.
Para obter mais informações sobre, consulte a ajuda do Connect-WSMan.
Como configurar a comunicação remota em portas alternativas
Para erro:
ERRO: A conexão com o host remoto especificado foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta e URL HTTP corretas.
A comunicação remota do PowerShell usa a porta 80 para transporte HTTP por padrão. A porta padrão é usada sempre que o usuário não especifica os parâmetros ConnectionURI ou Port em um comando remoto.
Use Set-Item cmdlet para alterar o valor Portno nó folha do ouvinte.
Por exemplo, o comando a seguir altera a porta padrão para 8080.
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
Como configurar a comunicação remota com um servidor proxy
Para erro:
ERRO: O cliente não pode se conectar ao destino especificado na solicitação. Verifique se o serviço no destino está em execução e está aceitando solicitações.
Como a comunicação remota do PowerShell usa o protocolo HTTP, ela é afetada pelas configurações de proxy HTTP. Em empresas que têm servidores proxy, os usuários não podem acessar um computador remoto do PowerShell diretamente.
Para resolver esse problema, use opções de configuração de proxy no comando remoto.
- Use os parâmetros ProxyAccessType, ProxyAuthentication e ProxyCredential do cmdlet para criar uma variável contendo um objeto PSSessionOption com as configurações de
New-PSSessionOptionproxy para sua empresa. - Use a variável que contém o objeto PSSessionOption com o parâmetro SessionOption de um
New-PSSessioncomando ,Enter-PSSessionouInvoke-Command.
$newPSSessionOptionSplat = @{
ProxyAccessType = 'IEConfig'
ProxyAuthentication = 'Negotiate'
ProxyCredential = 'Domain01\User01'
}
$SessionOption = New-PSSessionOption @newPSSessionOptionSplat
$newPSSessionSplat = @{
ConnectionUri = 'https://www.fabrikam.com'
SessionOption = $SessionOption
}
New-PSSession @newPSSessionSplat
Para obter mais informações sobre o New-PSSessionOption cmdlet, consulte New-PSSessionOption.
Para definir essas opções para todos os comandos remotos na sessão atual, defina a $PSSessionOption variável de preferência como o objeto PSSessionOption que você criou. Para obter mais informações, consulte about_Preference_Variables.
Para definir essas opções para todos os comandos remotos em todas as sessões do PowerShell no computador local, adicione a $PSSessionOption variável de preferência ao seu perfil do PowerShell. Para obter mais informações sobre perfis do PowerShell, confira about_Profiles.
Como detectar uma sessão de 32 bits em um computador de 64 bits
Para erro:
ERRO: O termo <tool-name> não é reconhecido como o nome de um cmdlet, função, arquivo de script ou programa operável. Verifique a ortografia do nome ou se um caminho foi incluído, verifique se ele está correto e tente novamente.
Se o computador remoto estiver executando uma versão de 64 bits do Windows e o comando remoto usar uma configuração de sessão de 32 bits, como Microsoft.PowerShell32, o WinRM carregará um processo WOW64. O Windows redireciona automaticamente todas as referências para $env:Windir\System32 o $env:Windir\SysWOW64 diretório.
Como resultado, não System32 é possível encontrar ferramentas em execução no diretório que não tenham contrapartes no SysWow64 diretório.
Para localizar a arquitetura do processador que está sendo usada na sessão, use o valor da variável de ambiente PROCESSOR_ARCHITECTURE .
$s = New-PSSession -ComputerName Server01 -ConfigurationName CustomShell
Invoke-Command -Session $s {$env:PROCESSOR_ARCHITECTURE}
x86
Para obter mais informações, consulte about_Session_Configurations.
Solução de problemas de política e preferência
Esta seção discute problemas de comunicação remota relacionados a diretivas e preferências definidas nos computadores locais e remotos.
Como alterar a política de execução para Import-PSSession e Import-Module
Para erro:
ERRO: Import-Module: O <nome do arquivo> não pode ser carregado porque a execução de scripts está desabilitada neste sistema.
Os Import-PSSession cmdlets e Export-PSSession criam módulos que contêm arquivos de script não assinados e arquivos de formatação.
Para importar os módulos criados por esses cmdlets, a política de execução na sessão atual não pode ser Restricted ou AllSigned. Para mais informações, veja about_Execution_Policies.
Para importar os módulos sem alterar a diretiva de execução do computador local, use o parâmetro Scope de para definir uma diretiva de Set-ExecutionPolicy execução menos restritiva para um único processo.
Por exemplo, o exemplo a seguir define a diretiva de execução como RemoteSigned para o processo atual. A mudança afeta apenas o processo atual.
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Você também pode usar o parâmetro ExecutionPolicy de para iniciar uma única sessão com uma diretiva de PowerShell.exe execução menos restritiva.
pwsh.exe -ExecutionPolicy RemoteSigned
Como definir e alterar cotas
Você pode usar cotas para proteger o computador local e o computador remoto contra o uso excessivo de recursos, tanto acidental quanto malicioso. Quando as cotas entram em conflito com um comando, o PowerShell gera o seguinte erro.
ERRO: O total de dados recebidos do cliente remoto excedeu o máximo permitido.
O provedor WSMan tem as seguintes configurações de cota:
- As configurações MaxEnvelopeSizeKB e MaxProviderRequests no
WSMan:<ComputerName>nó e as configurações MaxConcurrentOperations, MaxConcurrentOperationsPerUser e MaxConnections noWSMan:<ComputerName>\Servicenó. - Você pode usar os parâmetros MaximumReceivedDataSizePerCommand e MaximumReceivedObjectSize do cmdlet e a
$PSSessionOptionvariável deNew-PSSessionOptionpreferência para proteger o computador local. - Para proteger o computador remoto, adicione restrições às configurações de sessão usando os parâmetros MaximumReceivedDataSizePerCommandMB e MaximumReceivedObjectSizeMB do
Register-PSSessionConfigurationcmdlet.
Para resolver o erro, altere o comando remoto para cumprir com a cota ou aumente a cota para permitir que o comando seja concluído.
Por exemplo, o comando a seguir aumenta a cota de tamanho de objeto na configuração de sessão do Microsoft.PowerShell no computador remoto de 10 MB (o valor padrão) para 11 MB.
$setPSSessionConfigurationSplat = @{
Name = 'Microsoft.PowerShell'
MaximumReceivedObjectSizeMB = 11
Force = $true
}
Set-PSSessionConfiguration @setPSSessionConfigurationSplat
Para obter mais informações sobre as cotas do WS-Management, consulte about_WSMan_Provider.
Como resolver erros de tempo limite
Você pode usar tempos limite para proteger o computador local e o computador remoto contra o uso excessivo de recursos, tanto acidental quanto malicioso. Quando os tempos limite são definidos no computador local e remoto, o PowerShell usa as configurações de tempo limite mais curto.
Quando um valor de tempo limite não permite a conclusão de uma operação, o PowerShell encerra a operação e gera o seguinte erro.
ERRO: O serviço WS-Management não pode concluir a operação dentro do tempo especificado em OperationTimeout.
O provedor WSMan tem as seguintes configurações de tempo limite.
- MaxTimeoutMs no
WSMan:<ComputerName>nó e as configurações EnumerationTimeoutMs e MaxPacketRetrievalTimeSeconds noWSMan:<ComputerName>\Servicenó. - Você pode proteger o computador local usando os parâmetros CancelTimeout, IdleTimeout, OpenTimeout e OperationTimeout do
New-PSSessionOptioncmdlet e da$PSSessionOptionvariável de preferência. - Você também pode proteger o computador remoto definindo valores de tempo limite programaticamente na configuração da sessão para a sessão.
Para resolver o erro, altere o comando para concluir dentro do intervalo de tempo limite ou aumente o intervalo de tempo limite para permitir que o comando seja concluído.
O exemplo a seguir cria uma opção de sessão com um valor OperationTimeout de 4 minutos (no MS) e usa a opção de sessão para criar uma sessão remota.
$pso = New-PSSessionOption -OperationTimeout 240000
New-PSSession -ComputerName Server01 -SessionOption $pso
Para obter mais informações sobre os tempos limite do WS-Management, consulte about_WSMan_Provider.
Como interromper um comando que não responde
Alguns programas nativos, como programas com uma interface de usuário, aplicativos de console que solicitam entrada e aplicativos de console que usam a API de console do Win32, não funcionam corretamente no host remoto do PowerShell.
Quando você usa esses programas, você pode ver um comportamento inesperado, como nenhuma saída, saída parcial ou um comando remoto que não é concluído.
Para encerrar um programa que não responde, digite Ctrl+c. Use Get-Error no host local e na sessão remota para exibir quaisquer erros que possam ter sido relatados.
Como se recuperar de uma falha de operação
O erro a seguir é retornado quando uma operação é encerrada antes de ser concluída.
ERRO: A operação de E/S foi anulada devido a uma saída de thread ou uma solicitação de aplicativo.
Normalmente, isso ocorre quando o serviço WinRM pára ou reinicia enquanto outras operações WinRM estão em andamento.
Para resolver esse problema, verifique se o serviço WinRM está em execução e tente o comando novamente.
Inicie o PowerShell com a opção Executar como administrador .
Execute o comando a seguir:
Start-Service WinRMExecute novamente o comando que gerou o erro.
Limitações do Linux e macOS
A comunicação remota do PowerShell é Linux e macOS usando comunicação remota sobre SSH. Para obter mais informações, consulte PowerShell Remoting Over SSH.
Confira também
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de