Compartir a través de

about_Remote_Troubleshooting

  • Artículo

Descripción breve

Describe cómo solucionar problemas de operaciones remotas en PowerShell.

Descripción larga

Antes de usar la comunicación remota de PowerShell, consulte about_Remote y about_Remote_Requirements para obtener instrucciones sobre la configuración y el uso básico.

Debe tener derechos administrativos para ver o cambiar la configuración del equipo local en la WSMan: unidad. Esto incluye cambios en la configuración de sesión, los hosts de confianza, los puertos o los agentes de escucha.

Debe ejecutar PowerShell con la opción Ejecutar como administrador .

Ejecución como administrador

Para el error:

ERROR: Se deniega el acceso. Debe ejecutar este cmdlet desde un proceso con privilegios elevados.

Para iniciar Windows PowerShell con la opción Ejecutar como administrador , haga clic con el botón derecho en el icono de PowerShell en el menú Inicio y seleccione Ejecutar como administrador.

Cómo habilitar la comunicación remota

Para errores:

  • ERROR: SE DENIEGA EL ACCESO
  • ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se está ejecutando en el host remoto y configurado para escuchar las solicitudes en el puerto correcto y la dirección URL HTTP.

Para recibir comandos remotos, la comunicación remota de PowerShell debe estar habilitada en el equipo. La comunicación remota de Windows PowerShell está habilitada de forma predeterminada en Windows Server 2012 y versiones más recientes de Windows Server. Puede ejecutar Enable-PSRemoting para volver a habilitar la comunicación remota si se deshabilitó. Para obtener más información, consulte Enable-PSRemoting.

Habilitación de la comunicación remota en una empresa

Para errores:

  • ERROR: SE DENIEGA EL ACCESO
  • ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se está ejecutando en el host remoto y configurado para escuchar las solicitudes en el puerto correcto y la dirección URL HTTP.

Para permitir que un único equipo reciba comandos remotos de PowerShell y acepte conexiones, use el Enable-PSRemoting cmdlet .

Para habilitar la comunicación remota para varios equipos de una empresa, puede usar las siguientes opciones escaladas.

  • Habilite la directiva de grupo Permitir la configuración automática de agentes de escucha para configurar agentes de escucha para la comunicación remota.
  • Configure y habilite la directiva de grupo Firewall de Windows: Permitir excepciones de puerto local.
  • Establezca el tipo de inicio del servicio WinRM en Automatic e inicie el servicio.

Cómo habilitar agentes de escucha mediante una directiva de grupo

Para errores:

  • ERROR: SE DENIEGA EL ACCESO
  • ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se está ejecutando en el host remoto y configurado para escuchar las solicitudes en el puerto correcto y la dirección URL HTTP.

Habilite la directiva Permitir la configuración automática de agentes de escucha para configurar los agentes de escucha para todos los equipos de un dominio.

La directiva se encuentra en la siguiente ruta de acceso de directiva de grupo:

Computer Configuration\Administrative Templates\Windows Components
    \Windows Remote Management (WinRM)\WinRM service

Habilite la directiva y especifique los filtros IPv4 e IPv6. Se permiten caracteres comodín (*).

Habilitación de la comunicación remota en redes públicas

Enable-PSRemoting devuelve este error cuando la red local es pública y el parámetro SkipNetworkProfileCheck no se usa en el comando .

ERROR: No se puede comprobar el estado del firewall

En las versiones de servidor de Windows, Enable-PSRemoting se realiza correctamente en todos los perfiles de red. Crea reglas de firewall que permiten el acceso remoto a redes privadas y de dominio ("Inicio" y "Trabajo"). En el caso de las redes públicas, crea reglas de firewall que permiten el acceso remoto desde la misma subred local.

En las versiones de cliente de Windows, Enable-PSRemoting se realiza correctamente en redes privadas y de dominio. De forma predeterminada, se produce un error en las redes públicas, pero si usa el parámetro SkipNetworkProfileCheck , Enable-PSRemoting se realiza correctamente y crea una regla de firewall que permite el tráfico desde la misma subred local.

Nota:

En Windows PowerShell 2.0, en equipos que ejecutan versiones de servidor de Windows, Enable-PSRemoting crea reglas de firewall que permiten el acceso remoto en redes públicas, privadas y de dominio. En los equipos que ejecutan versiones de cliente de Windows, Enable-PSRemoting crea reglas de firewall que permiten el acceso remoto solo en redes privadas y de dominio.

Para quitar la restricción de subred local en redes públicas y permitir el acceso remoto desde cualquier ubicación, ejecute el siguiente comando:

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any

El Set-NetFirewallRule módulo NetSecurity exporta el cmdlet .

Nota:

El nombre de la regla de firewall puede ser diferente para diferentes versiones de Windows. Use Get-NetFirewallRule para ver una lista de reglas. Antes de habilitar la regla de firewall, vea la configuración de seguridad de la regla para comprobar que la configuración es adecuada para su entorno.

Habilitación de una excepción de firewall mediante una directiva de grupo

Para errores:

  • ERROR: SE DENIEGA EL ACCESO
  • ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se está ejecutando en el host remoto y configurado para escuchar las solicitudes en el puerto correcto y la dirección URL HTTP.

Usar firewall de Windows: permitir que la directiva de excepciones de puerto local habilite una excepción de firewall para en todos los equipos de un dominio.

La directiva se encuentra en la siguiente ruta de acceso de directiva de grupo:

Computer Configuration\Administrative Templates\Network
    \Network Connections\Windows Firewall\Domain Profile

Esta directiva permite a los miembros del grupo Administradores crear una excepción de firewall para el servicio administración remota de Windows (WinRM).

Si la configuración de la directiva es incorrecta, puede recibir el siguiente error:

El cliente no puede conectarse al destino especificado en la solicitud. Compruebe que el servicio del destino se está ejecutando y que acepta solicitudes.

Un error de configuración en la directiva da como resultado un valor vacío para la propiedad ListeningOn . Use el comando siguiente para comprobar el 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           : {}

Establecimiento del tipo de inicio del servicio WinRM

Para el error:

ERROR: SE DENIEGA EL ACCESO

La comunicación remota de PowerShell depende del servicio administración remota de Windows (WinRM). El servicio debe ejecutarse para admitir comandos remotos.

En las versiones de servidor de Windows, el tipo de inicio del servicio WinRM es Automatic. Sin embargo, en las versiones de cliente de Windows, el servicio WinRM está deshabilitado de forma predeterminada.

Use el ejemplo siguiente para establecer el tipo de inicio del servicio WinRM en Automatic e iniciar el servicio. El parámetro ComputerName acepta varios valores.

$invokeCimMethodSplat = @{
    ComputerName = 'Server01', 'Server02'
    Query = 'Select * From Win32_Service Where Name = "WinRM"'
    MethodName = 'ChangeStartMode'
    Arguments = @{StartMode  = 'Automatic'}
}
Invoke-CimMethod @invokeCimMethodSplat

Cómo volver a crear las configuraciones de sesión predeterminadas

Para el error:

ERROR: SE DENIEGA EL ACCESO

Cuando se usa Enable-PSRemoting, crea configuraciones de sesión predeterminadas en el equipo local. Los usuarios remotos usan estas configuraciones de sesión siempre que un comando remoto no incluya el parámetro ConfigurationName .

Si las configuraciones predeterminadas de un equipo no se registran o eliminan, use el Enable-PSRemoting cmdlet para volver a crearlas. Puede usar este cmdlet repetidamente. No genera errores si ya está configurada una característica.

Si cambia las configuraciones de sesión predeterminadas y desea restaurar las configuraciones de sesión originales, puede eliminar y volver a crear las configuraciones.

Use el Unregister-PSSessionConfiguration cmdlet para eliminar las configuraciones de sesión modificadas. Use Enable-PSRemoting para restaurar las configuraciones de sesión originales. Enable-PSRemoting no cambia las configuraciones de sesión existentes.

Nota:

Cuando Enable-PSRemoting restaura la configuración de sesión predeterminada, no crea descriptores de seguridad explícitos para las configuraciones. En su lugar, las configuraciones heredan el descriptor de seguridad de RootSDDL, que es seguro de forma predeterminada.

Para ver el descriptor de seguridad RootSDDL , escriba:

Get-Item wsman:\localhost\Service\RootSDDL

Para cambiar rootSDDL, use el Set-Item cmdlet en la WSMan: unidad. Para cambiar el descriptor de seguridad de una configuración de sesión, use el Set-PSSessionConfiguration cmdlet con los parámetros SecurityDescriptorSDDL o ShowSecurityDescriptorUI .

Para obtener más información sobre la WSMan: unidad, consulte about_WSMan_Provider.

Cómo proporcionar credenciales de administrador

Para el error:

ERROR: SE DENIEGA EL ACCESO

Debe ser miembro del grupo Administradores conectarse a los puntos de conexión de sesión remotos predeterminados. Puede usar el parámetro Credential de los New-PSSessioncmdlets , Enter-PSSession o Invoke-Command para conectarse a puntos de conexión remotos mediante credenciales alternativas.

En el ejemplo siguiente se muestra cómo proporcionar las credenciales de un usuario administrador.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

Para obtener más información sobre el parámetro Credential , consulte la ayuda de New-PSSession, Enter-PSSession o Invoke-Command.

Habilitación de la comunicación remota para usuarios no administrativos

Para el error:

ERROR: SE DENIEGA EL ACCESO

De forma predeterminada, solo los miembros del grupo Administradores de un equipo tienen permiso para usar las configuraciones de sesión predeterminadas. Por lo tanto, solo los miembros del grupo Administradores pueden conectarse al equipo de forma remota.

Para permitir que otros usuarios se conecten al equipo local, asigne al usuario permisos Ejecutar a las configuraciones de sesión predeterminadas en el equipo local.

En el ejemplo siguiente se abre una hoja de propiedades que permite cambiar el descriptor de seguridad de la configuración de sesión predeterminada Microsoft.PowerShell en el equipo local.

Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI

Para obtener más información, consulte about_Session_Configurations.

Habilitación de la comunicación remota para administradores en otros dominios

Para el error:

ERROR: SE DENIEGA EL ACCESO

Cuando un usuario de otro dominio es miembro del grupo Administradores en el equipo local, el usuario no puede conectarse al equipo local de forma remota con privilegios de administrador. De forma predeterminada, las conexiones remotas de otros dominios se ejecutan solo con tokens de privilegios de usuario estándar.

Puede usar la entrada del Registro LocalAccountTokenFilterPolicy para cambiar el comportamiento predeterminado y permitir que los usuarios remotos que sean miembros del grupo Administradores se ejecuten con privilegios de administrador.

Precaución

La entrada LocalAccountTokenFilterPolicy deshabilita las restricciones remotas de control de cuentas de usuario (UAC) para todos los usuarios de todos los equipos afectados. Tenga en cuenta las implicaciones de esta configuración cuidadosamente antes de cambiar la directiva.

Use el siguiente comando para establecer el valor del Registro LocalAccountTokenFilterPolicy en 1.

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

Uso de una dirección IP en un comando remoto

Para el error:

ERROR: El cliente winRM no puede procesar la solicitud. Si el esquema de autenticación es diferente de Kerberos o si el equipo cliente no está unido a un dominio, se debe usar el transporte HTTPS o se debe agregar la máquina de destino a la configuración de TrustedHosts.

El parámetro ComputerName de los New-PSSessioncmdlets , Enter-PSSession y Invoke-Command acepta una dirección IP como un valor válido. Sin embargo, dado que la autenticación Kerberos no admite direcciones IP. Al especificar una dirección IP, se usa la autenticación NTLM.

Para admitir la autenticación NTLM, debe cumplir los siguientes requisitos:

  • Configure el equipo para el transporte HTTPS o agregue las direcciones IP de los equipos remotos a la lista TrustedHosts en el equipo local.
  • Use el parámetro Credential en todos los comandos remotos. Esto es necesario incluso cuando se conecta como usuario actual.

Conexión remota desde un equipo basado en grupo de trabajo

Para ver el error

ERROR: El cliente winRM no puede procesar la solicitud. Si el esquema de autenticación es diferente de Kerberos o si el equipo cliente no está unido a un dominio, se debe usar el transporte HTTPS o se debe agregar la máquina de destino a la configuración de TrustedHosts.

Cuando el equipo local no está en un dominio, debe cumplir los siguientes requisitos:

  • Configure el equipo para el transporte HTTPS o agregue las direcciones IP de los equipos remotos a la lista TrustedHosts en el equipo local.
  • Compruebe que una contraseña está establecida en el equipo basado en grupo de trabajo. Si no se establece una contraseña o el valor de la contraseña está vacío, no puede ejecutar comandos remotos.
  • Use el parámetro Credential en todos los comandos remotos. Esto es necesario incluso cuando se conecta como usuario actual.

Cómo agregar un equipo a la lista de hosts de confianza

El elemento TrustedHosts puede contener una lista separada por comas de nombres de equipo, direcciones IP y nombres de dominio completos. Se permiten los caracteres comodín.

Para ver o cambiar la lista de hosts de confianza, use la WSMan: unidad . El elemento TrustedHost está en el WSMan:\localhost\Client nodo. Solo los miembros del grupo Administradores del equipo tienen permiso para cambiar la lista de hosts de confianza en el equipo.

Precaución

El valor establecido para el elemento TrustedHosts afecta a todos los usuarios del equipo.

Para ver la lista de hosts de confianza, use el siguiente comando:

Get-Item wsman:\localhost\Client\TrustedHosts

En el ejemplo siguiente se usa el carácter comodín (*) para agregar todos los equipos a la lista de hosts de confianza.

Set-Item wsman:localhost\client\trustedhosts -Value *

También puede usar un carácter comodín (*) para agregar todos los equipos de un dominio determinado a la lista de hosts de confianza. Por ejemplo, el siguiente comando agrega todos los equipos del dominio Fabrikam.

Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com

En el ejemplo siguiente se establece la lista de hosts de confianza en un solo equipo.

$server = 'Server01.Domain01.Fabrikam.com'
Set-Item wsman:\localhost\Client\TrustedHosts -Value $server

Para agregar un nombre de equipo a una lista existente de hosts de confianza, guarde primero el valor actual en una variable. A continuación, establezca el valor en una cadena que contenga una lista separada por comas que incluya los valores actuales y nuevos.

En el ejemplo siguiente se agrega Server01 a una lista existente de hosts de confianza.

$newServer = 'Server01.Domain01.Fabrikam.com'
$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).Value
Set-Item wsman:\localhost\Client\TrustedHosts -Value "$curValue, $newServer"

Para agregar las direcciones IP de equipos concretos a la lista de hosts de confianza, use el siguiente formato de comando:

Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>

Por ejemplo:

Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0

Para agregar un equipo a la lista TrustedHosts de un equipo remoto, use Connect-WSMan para conectarse al WSMan: equipo remoto que use Set-Item para agregar el equipo.

Para obtener más información, consulte la ayuda de Connect-WSMan.

Configuración de la comunicación remota en puertos alternativos

Para el error:

ERROR: Se rechazó la conexión con el host remoto especificado. Compruebe que el servicio WS-Management se está ejecutando en el host remoto y configurado para escuchar las solicitudes en el puerto correcto y la dirección URL HTTP.

La comunicación remota de PowerShell usa el puerto 80 para el transporte HTTP de forma predeterminada. El puerto predeterminado se usa siempre que el usuario no especifica los parámetros ConnectionURI o Port en un comando remoto.

Use Set-Item el cmdlet para cambiar el valor de Puerto en el nodo hoja del agente de escucha.

Por ejemplo, el siguiente comando cambia el puerto predeterminado a 8080.

Set-Item wsman:\localhost\listener\listener*\port -Value 8080

Configuración de la comunicación remota con un servidor proxy

Para el error:

ERROR: El cliente no puede conectarse al destino especificado en la solicitud. Compruebe que el servicio del destino se está ejecutando y que acepta solicitudes.

Dado que la comunicación remota de PowerShell usa el protocolo HTTP, se ve afectado por la configuración del proxy HTTP. En las empresas que tienen servidores proxy, los usuarios no pueden acceder directamente a un equipo remoto de PowerShell.

Para resolver este problema, use las opciones de configuración de proxy en el comando remoto.

  • Use los parámetros ProxyAccessType, ProxyAuthentication y ProxyCredential del New-PSSessionOption cmdlet para crear una variable que contenga un objeto PSSessionOption con la configuración de proxy de la empresa.
  • Utilice la variable que contiene el objeto PSSessionOption con el parámetro SessionOption de un New-PSSessioncomando , Enter-PSSessiono Invoke-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 obtener más información sobre el New-PSSessionOption cmdlet, consulte New-PSSessionOption.

Para establecer estas opciones para todos los comandos remotos de la sesión actual, establezca la $PSSessionOption variable de preferencia en el objeto PSSessionOption que creó. Para obtener más información, consulte about_Preference_Variables.

Para establecer estas opciones para todos los comandos remotos de todas las sesiones de PowerShell en el equipo local, agregue la $PSSessionOption variable de preferencia al perfil de PowerShell. Para obtener más información sobre los perfiles de PowerShell, consulte about_Profiles.

Detección de una sesión de 32 bits en un equipo de 64 bits

Para el error:

ERROR: El término <nombre de> la herramienta no se reconoce como el nombre de un cmdlet, una función, un archivo de script o un programa operable. Compruebe si escribió correctamente el nombre o, si incluyó una ruta de acceso, compruebe que dicha ruta es correcta e inténtelo de nuevo.

Si el equipo remoto ejecuta una versión de 64 bits de Windows y el comando remoto usa una configuración de sesión de 32 bits, como Microsoft.PowerShell32, WinRM carga un proceso WOW64. Windows redirige automáticamente todas las referencias al $env:Windir\System32 $env:Windir\SysWOW64 directorio.

Como resultado, no se pueden encontrar herramientas en ejecución en el System32 directorio que no tienen homólogos en el SysWow64 directorio.

Para buscar la arquitectura del procesador que se usa en la sesión, use el valor de la variable de entorno PROCESSOR_ARCHITECTURE .

$s = New-PSSession -ComputerName Server01 -ConfigurationName CustomShell
Invoke-Command -Session $s {$env:PROCESSOR_ARCHITECTURE}

x86

Para obtener más información, consulte about_Session_Configurations.

Solución de problemas de directiva y preferencias

En esta sección se describen los problemas de comunicación remota relacionados con las directivas y preferencias establecidas en los equipos locales y remotos.

Cómo cambiar la directiva de ejecución para Import-PSSession e Import-Module

Para el error:

ERROR: Import-Module: no se puede cargar el nombre de archivo <> porque la ejecución de scripts está deshabilitada en este sistema.

Los Import-PSSession cmdlets y Export-PSSession crean módulos que contienen archivos de script sin firmar y archivos de formato.

Para importar los módulos creados por estos cmdlets, la directiva de ejecución de la sesión actual no puede ser Restricted ni AllSigned. Para obtener más información, vea about_Execution_Policies.

Para importar los módulos sin cambiar la directiva de ejecución del equipo local, use el parámetro Scope de Set-ExecutionPolicy para establecer una directiva de ejecución menos restrictiva para un único proceso.

Por ejemplo, en el ejemplo siguiente se establece la directiva RemoteSigned de ejecución en para el proceso actual. El cambio solo afecta al proceso actual.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

También puede usar el parámetro ExecutionPolicy de PowerShell.exe para iniciar una sola sesión con una directiva de ejecución menos restrictiva.

pwsh.exe -ExecutionPolicy RemoteSigned

Establecimiento y cambio de cuotas

Puede usar cuotas para proteger el equipo local y el equipo remoto frente al uso excesivo de recursos, tanto accidental como malintencionado. Cuando las cuotas entran en conflicto con un comando, PowerShell genera el siguiente error.

ERROR: El total de datos recibidos del cliente remoto superó el máximo permitido.

El proveedor WSMan tiene la siguiente configuración de cuota:

  • La configuración de MaxEnvelopeSizeKB y MaxProviderRequests en el WSMan:<ComputerName> nodo y la configuración MaxConcurrentOperations, MaxConcurrentOperationsPerUser y MaxConnections en el WSMan:<ComputerName>\Service nodo.
  • Puede usar los parámetros MaximumReceivedDataSizePerCommand y MaximumReceivedObjectSize del New-PSSessionOption cmdlet y la $PSSessionOption variable de preferencia para proteger el equipo local.
  • Para proteger el equipo remoto, agregue restricciones a las configuraciones de sesión mediante los parámetros MaximumReceivedDataSizePerCommandMB y MaximumReceivedObjectSizeMB del Register-PSSessionConfiguration cmdlet.

Para resolver el error, cambie el comando remoto para cumplir con la cuota o aumentar la cuota para permitir que el comando se complete.

Por ejemplo, el siguiente comando aumenta la cuota de tamaño de objeto en la configuración de sesión de Microsoft.PowerShell en el equipo remoto de 10 MB (el valor predeterminado) a 11 MB.

$setPSSessionConfigurationSplat = @{
    Name = 'Microsoft.PowerShell'
    MaximumReceivedObjectSizeMB = 11
    Force = $true
}
Set-PSSessionConfiguration @setPSSessionConfigurationSplat

Para obtener más información sobre las cuotas de WS-Management, consulte about_WSMan_Provider.

Cómo resolver errores de tiempo de espera

Puede usar tiempos de espera para proteger el equipo local y el equipo remoto frente al uso excesivo de recursos, tanto accidental como malintencionado. Cuando se establecen tiempos de espera en el equipo local y remoto, PowerShell usa la configuración de tiempo de espera más corta.

Cuando un valor de tiempo de espera no permite que se complete una operación, PowerShell finaliza la operación y genera el siguiente error.

ERROR: El servicio WS-Management no puede completar la operación dentro del tiempo especificado en OperationTimeout.

El proveedor WSMan tiene la siguiente configuración de tiempos de espera.

  • Configuración de MaxTimeoutMs en el WSMan:<ComputerName> nodo y enumerationTimeoutMs y MaxPacketRetrievalTimeSeconds en el WSMan:<ComputerName>\Service nodo.
  • Puede proteger el equipo local mediante los parámetros CancelTimeout, IdleTimeout, OpenTimeout y OperationTimeout del New-PSSessionOption cmdlet y la $PSSessionOption variable de preferencia.
  • También puede proteger el equipo remoto estableciendo valores de tiempo de espera mediante programación en la configuración de sesión de la sesión.

Para resolver el error, cambie el comando para que se complete dentro del intervalo de tiempo de espera o aumente el intervalo de tiempo de espera para permitir que el comando se complete.

En el ejemplo siguiente se crea una opción de sesión con un valor OperationTimeout de 4 minutos (en MS) y, a continuación, se usa la opción de sesión para crear una sesión remota.

$pso = New-PSSessionOption -OperationTimeout 240000
New-PSSession -ComputerName Server01 -SessionOption $pso

Para obtener más información sobre los tiempos de espera de WS-Management, consulte about_WSMan_Provider.

Cómo interrumpir un comando que no responde

Algunos programas nativos, como programas con una interfaz de usuario, aplicaciones de consola que solicitan entrada y aplicaciones de consola que usan la API de consola Win32, no funcionan correctamente en el host remoto de PowerShell.

Al usar estos programas, es posible que vea un comportamiento inesperado, como ninguna salida, salida parcial o un comando remoto que no se complete.

Para finalizar un programa que no responde, escriba Ctrl+c. Use Get-Error en el host local y la sesión remota para ver los errores que podrían haberse notificado.

Recuperación de un error de operación

Se devuelve el siguiente error cuando se finaliza una operación antes de que se complete.

ERROR: La operación de E/S se ha anulado debido a una salida de subproceso o a una solicitud de aplicación.

Normalmente, esto ocurre cuando el servicio WinRM se detiene o se reinicia mientras otras operaciones de WinRM están en curso.

Para resolver este problema, compruebe que el servicio WinRM se está ejecutando e inténtelo de nuevo.

  1. Inicie PowerShell con la opción Ejecutar como administrador .

  2. Ejecute el siguiente comando:

    Start-Service WinRM

  3. Vuelva a ejecutar el comando que generó el error.

Limitaciones de Linux y macOS

La comunicación remota de PowerShell es Linux y macOS mediante comunicación remota a través de SSH. Para más información, consulte Comunicación remota de PowerShell a través de SSH.

Consulte también