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

En esta sección se describen algunos de los problemas que puede encontrar al usar las características de comunicación remota de PowerShell basadas en WS-Management tecnología y sugiere soluciones a estos problemas.

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. Además, los temas de Ayuda de cada uno de los cmdlets de comunicación remota, especialmente las descripciones de parámetros, tienen información útil diseñada para ayudarle a evitar problemas.

Nota

Para ver o cambiar la configuración del equipo local en la unidad WSMan: , incluidos los cambios en las configuraciones de sesión, los hosts de confianza, los puertos o los agentes de escucha, inicie PowerShell con la opción Ejecutar como administrador .

Solución de problemas de permisos y autenticación

En esta sección se describen los problemas de comunicación remota relacionados con los permisos de usuario y equipo y los requisitos de comunicación remota.

Ejecución como administrador

ERROR: Access is denied. You need to run this cmdlet from an elevated
process.

Para iniciar una sesión remota en el equipo local, o para ver o cambiar la configuración del equipo local en la unidad WSMan: , incluidos los cambios en las configuraciones de sesión, los hosts de confianza, los puertos o los agentes de escucha, inicie Windows PowerShell con la opción Ejecutar como administrador.

Para iniciar Windows PowerShell con la opción Ejecutar como administrador:

  • Haga clic con el botón derecho en un icono de Windows PowerShell (o Windows PowerShell ISE) y, a continuación, haga clic en Ejecutar como administrador.

    Para iniciar Windows PowerShell con la opción Ejecutar como administrador en Windows 7 y Windows Server 2008 R2.

  • En la barra de tareas de Windows, haga clic con el botón derecho en el icono de Windows PowerShell y, a continuación, haga clic en Ejecutar como administrador.

    En Windows Server 2008 R2, el icono de Windows PowerShell se ancla a la barra de tareas de forma predeterminada.

Habilitación de la comunicación remota

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.

No se requiere ninguna configuración para permitir que un equipo envíe comandos remotos. Sin embargo, para recibir comandos remotos, la comunicación remota de PowerShell debe estar habilitada en el equipo. Habilitar incluye iniciar el servicio WinRM, establecer el tipo de inicio del servicio WinRM en Automático, crear agentes de escucha para conexiones HTTP y HTTPS y crear configuraciones de sesión predeterminadas.

Windows PowerShell comunicación remota está habilitada en Windows Server 2012 y versiones más recientes de Windows Server de forma predeterminada. En todos los demás sistemas, ejecute el Enable-PSRemoting cmdlet para habilitar la comunicación remota. También puede ejecutar el Enable-PSRemoting cmdlet para volver a habilitar la comunicación remota en Windows Server 2012 y versiones más recientes de Windows Server si la comunicación remota está deshabilitada.

Para configurar un equipo para recibir comandos remotos, use el Enable-PSRemoting cmdlet . El siguiente comando habilita todas las opciones remotas necesarias, habilita las configuraciones de sesión y reinicia el servicio WinRM para que los cambios sean efectivos.

Enable-PSRemoting

Para suprimir todas las solicitudes del usuario, escriba:

Enable-PSRemoting -Force

Para obtener más información, vea Enable-PSRemoting.

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

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

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.

  • Para configurar agentes de escucha para la comunicación remota, habilite la directiva de grupo Permitir la configuración automática de los agentes de escucha .

  • Para establecer el tipo de inicio de Administración remota de Windows (WinRM) en Automático en varios equipos, use el Set-Service cmdlet .

  • Para habilitar una excepción de firewall, use la directiva de grupo Firewall de Windows: Permitir excepciones de puerto local .

Habilitación de agentes de escucha mediante una directiva de grupo

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

Para configurar los agentes de escucha para todos los equipos de un dominio, habilite la directiva Permitir la configuración automática de agentes de escucha 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

ERROR:  Unable to check the status of the firewall

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

En las versiones de servidor de Windows, Enable-PSRemoting se realiza correctamente en todos los tipos de ubicación 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.

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.

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 privadas, de dominio y públicas. En 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.

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

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

Para habilitar una excepción de firewall para en todos los equipos de un dominio, habilite la directiva Firewall de Windows: Permitir excepciones de puerto local en la siguiente ruta de acceso directiva de grupo:

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

Esta directiva permite a los miembros del grupo Administradores del equipo usar firewall de Windows en Panel de control crear una excepción de firewall para el servicio de administración remota de Windows.

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

The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests.

Un error de configuración en la directiva da como resultado un valor vacío para la propiedad ListeningOn . Use el siguiente comando para comprobar el valor.

PS> 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           : {}

Cómo establecer el tipo de inicio del servicio WinRM

ERROR:  ACCESS IS DENIED

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 Administración remota de Windows (WinRM) es Automático.

Sin embargo, en las versiones de cliente de Windows, el servicio WinRM está deshabilitado de forma predeterminada.

Para establecer el tipo de inicio de un servicio en un equipo remoto, use el Set-Service cmdlet .

Para ejecutar el comando en varios equipos, puede crear un archivo de texto o un archivo CSV de los nombres de equipo.

Por ejemplo, los siguientes comandos obtienen una lista de nombres de equipo del Servers.txt archivo y, a continuación, establece el tipo de inicio del servicio WinRM en todos los equipos en Automático.

$servers = Get-Content servers.txt
Set-Service WinRM -ComputerName $servers -startuptype Automatic

Para ver los resultados, use el Get-WMIObject cmdlet con el objeto Win32_Service . Para obtener más información, vea Set-Service.

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

ERROR:  ACCESS IS DENIED

Para conectarse al equipo local y ejecutar comandos de forma remota, el equipo local debe incluir configuraciones de sesión para comandos remotos.

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 predeterminadas originales, use el Unregister-PSSessionConfiguration cmdlet para eliminar las configuraciones de sesión modificadas y, a continuación, use el Enable-PSRemoting cmdlet para restaurarlas. 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 unidad WSMan: . 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 unidad WSMan: , consulte el tema ayuda del proveedor WSMan ("Get-Help wsman").

Cómo proporcionar credenciales de administrador

ERROR:  ACCESS IS DENIED

Para crear una PSSession o ejecutar comandos en un equipo remoto, de forma predeterminada, el usuario actual debe ser miembro del grupo Administradores en el equipo remoto. A veces, las credenciales son necesarias incluso cuando el usuario actual ha iniciado sesión en una cuenta que sea miembro del grupo Administradores.

Si el usuario actual es miembro del grupo Administradores en el equipo remoto, o puede proporcionar las credenciales de un miembro del grupo Administradores, use el parámetro Credential de los New-PSSessioncmdlets , Enter-PSSession o Invoke-Command para conectarse de forma remota.

Por ejemplo, el siguiente comando proporciona las credenciales de un administrador.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

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

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

ERROR:  ACCESS IS DENIED

Para establecer una PSSession o ejecutar un comando en un equipo remoto, el usuario debe tener permiso para usar las configuraciones de sesión en el equipo remoto.

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, conceda al usuario permisos Ejecutar a las configuraciones de sesión predeterminadas en el equipo local.

El siguiente comando abre una hoja de propiedades que permite cambiar el descriptor de seguridad de la configuración de sesión predeterminada de 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

ERROR:  ACCESS IS DENIED

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.

Sin embargo, puede usar la entrada del Registro LocalAccountTokenFilterPolicy para cambiar el comportamiento predeterminado y permitir que los usuarios remotos que son 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.

Para cambiar la directiva, use el siguiente comando para establecer el valor de la entrada del Registro LocalAccountTokenFilterPolicy en 1.

New-ItemProperty -Name LocalAccountTokenFilterPolicy `
  -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
  -PropertyType DWord -Value 1

Uso de una dirección IP en un comando remoto

ERROR: The WinRM client cannot process the request. If the authentication
scheme is different from Kerberos, or if the client computer is not joined to a
domain, then HTTPS transport must be used or the destination machine must be
added to the TrustedHosts configuration setting.

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, la autenticación NTLM se usa de forma predeterminada siempre que se especifica una dirección IP.

Al usar la autenticación NTLM, se requiere el procedimiento siguiente para la comunicación remota.

  1. Configure el equipo para el transporte HTTPS o agregue las direcciones IP de los equipos remotos a la lista TrustedHosts del equipo local.

  2. Use el parámetro Credential en todos los comandos remotos.

    Esto es necesario incluso cuando se envían las credenciales del usuario actual.

Cómo conectarse de forma remota desde un equipo basado en grupo de trabajo

ERROR: The WinRM client cannot process the request. If the authentication
scheme is different from Kerberos, or if the client computer is not joined to a
domain, then HTTPS transport must be used or the destination machine must be
added to the TrustedHosts configuration setting.

Cuando el equipo local no está en un dominio, se requiere el procedimiento siguiente para la comunicación remota.

  1. Configure el equipo para el transporte HTTPS o agregue los nombres de los equipos remotos a la lista TrustedHosts del equipo local.

  2. 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.

    Para establecer la contraseña de la cuenta de usuario, use Cuentas de usuario en Panel de control.

  3. Use el parámetro Credential en todos los comandos remotos.

    Esto es necesario incluso cuando se envían las credenciales del 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 unidad WSMan: . 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

También puede usar el Set-Location cmdlet (alias = cd) para navegar por la unidad WSMan: a la ubicación. Por ejemplo:

cd WSMan:\localhost\Client; dir

Para agregar todos los equipos a la lista de hosts de confianza, use el siguiente comando, que coloca un valor de * (todos) en computerName.

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 a la lista de hosts de confianza.

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

Para agregar los nombres de equipos concretos a la lista de hosts de confianza, use el siguiente formato de comando:

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

donde cada valor <ComputerName> debe tener el formato siguiente:

<Computer>.<Domain>.<Company>.<top-level-domain>

Por ejemplo:

$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, primero debe guardar el valor actual en una variable y, a continuación, establecer el valor en una lista separada por comas que incluya los valores actuales y nuevos.

Por ejemplo, para agregar el equipo Server01 a una lista existente de hosts de confianza, utilice el comando siguiente.

$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).value

Set-Item wsman:\localhost\Client\TrustedHosts -Value `
  "$curValue, Server01.Domain01.Fabrikam.com"

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 el Connect-WSMan cmdlet para agregar un nodo para el equipo remoto a la unidad WSMan: en el equipo local. A continuación, use un Set-Item comando para agregar el equipo.

Para obtener más información sobre el Connect-WSMan cmdlet, consulte Connect-WSMan.

Solución de problemas de configuración del equipo

En esta sección se describen los problemas de comunicación remota relacionados con configuraciones concretas de un equipo, dominio o empresa.

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

ERROR: The connection to the specified remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

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 especifique los parámetros ConnectionURI o Port en un comando remoto.

Para cambiar el puerto predeterminado que usa PowerShell, use Set-Item el cmdlet en la unidad WSMan: 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

ERROR: The client cannot connect to the destination specified in the request.
Verify that the service on the destination is running and is accepting
requests.

Dado que la comunicación remota de PowerShell usa el protocolo HTTP, se ve afectada 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. Las siguientes configuraciones están disponibles:

  • ProxyAccessType
  • ProxyAuthentication
  • ProxyCredential

Para establecer estas opciones para un comando determinado, use el procedimiento siguiente:

  1. Use los parámetros ProxyAccessType, ProxyAuthentication y ProxyCredential del New-PSSessionOption cmdlet para crear un objeto de opción de sesión con la configuración del proxy para su empresa. Guardar el objeto de opción es una variable.

  2. Use la variable que contiene el objeto option como valor del parámetro SessionOption de un New-PSSessioncomando , Enter-PSSessiono Invoke-Command .

Por ejemplo, el comando siguiente crea un objeto de opción de sesión con opciones de sesión de proxy y, a continuación, usa el objeto para crear una sesión remota.

$SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01

New-PSSession -ConnectionURI https://www.fabrikam.com

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, use el objeto de opción que New-PSSessionOption crea en el valor de la $PSSessionOption variable de preferencia. Para obtener más información, consulte about_Preference_Variables.

Para establecer estas opciones para todos los comandos remotos, todas las sesiones de PowerShell en el equipo local, agregue la variable de $PSSessionOption preferencia al perfil de PowerShell. Para 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

ERROR: The term "<tool-Name>" is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.

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, la administración remota de Windows (WinRM) carga un proceso WOW64 y Windows redirige automáticamente todas las referencias al $env:Windir\System32 directorio al $env:Windir\SysWOW64 directorio.

Como resultado, si intenta usar herramientas en el directorio System32 que no tienen homólogos en el directorio SysWow64, como Defrag.exe, no se pueden encontrar las herramientas en el directorio .

Para buscar la arquitectura del procesador que se usa en la sesión, use el valor de la variable de entorno PROCESSOR_ARCHITECTURE . El siguiente comando busca la arquitectura del procesador de la sesión en la $s variable .

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

x86

Para obtener más información sobre las configuraciones de sesión, consulte about_Session_Configurations.

Solución de problemas de directivas 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 de Import-PSSession y Import-Module

ERROR: Import-Module: File <filename> cannot be loaded because the
execution of scripts is disabled on this system.

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, ya sea mediante Import-PSSession o Import-Module, la directiva de ejecución de la sesión actual no puede ser Restringido o AllSigned. Para obtener información sobre las directivas de ejecución de PowerShell, consulte about_Execution_Policies.

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

Por ejemplo, el siguiente comando inicia un proceso con la directiva de RemoteSigned ejecución. El cambio de directiva de ejecución afecta solo al proceso actual y no cambia la configuración del Registro ExecutionPolicy de PowerShell.

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.

PowerShell.exe -ExecutionPolicy RemoteSigned

Para más información sobre la directiva de ejecución, consulte about_Execution_Policies. Para obtener más información, escriba PowerShell.exe -?.

Establecimiento y cambio de cuotas

ERROR: The total data received from the remote client exceeded allowed
maximum.

Puede usar cuotas para proteger el equipo local y el equipo remoto frente al uso excesivo de recursos, tanto accidental como malintencionado.

Las cuotas siguientes están disponibles en la configuración básica.

  • El proveedor WSMan (WSMan:) proporciona varias opciones de cuota, como la configuración MaxEnvelopeSizeKB y MaxProviderRequests en el WSMan:<ComputerName> nodo y la configuración de MaxConcurrentOperations, MaxConcurrentOperationsPerUser y MaxConnections en el WSMan:<ComputerName>\Service nodo.

  • Puede proteger el equipo local mediante los parámetros MaximumReceivedDataSizePerCommand y MaximumReceivedObjectSize del New-PSSessionOption cmdlet y la variable de $PSSessionOption preferencia.

  • Puede proteger el equipo remoto agregando restricciones a las configuraciones de sesión, como mediante los parámetros MaximumReceivedDataSizePerCommandMB y MaximumReceivedObjectSizeMB del Register-PSSessionConfiguration cmdlet.

Cuando las cuotas entran en conflicto con un comando, PowerShell genera un error.

Para resolver el error, cambie el comando remoto para cumplir con la cuota. O bien, determine el origen de la cuota y, a continuación, aumente la cuota para permitir que se complete el comando.

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.

Set-PSSessionConfiguration -Name microsoft.PowerShell `
  -MaximumReceivedObjectSizeMB 11 -Force

Para obtener más información sobre el New-PSSessionOption cmdlet , vea New-PSSessionOption.

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

Cómo resolver errores de tiempo de espera

ERROR: The WS-Management service cannot complete the operation within
the time specified in OperationTimeout.

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.

Los siguientes tiempos de espera están disponibles en la configuración básica.

  • El proveedor WSMan (WSMan:) proporciona varias opciones de tiempo de espera del lado cliente y del lado del servicio, como la configuración MaxTimeoutms en el WSMan:<ComputerName> nodo y la configuración 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 variable de $PSSessionOption preferencia.

  • También puede proteger el equipo remoto estableciendo los valores de tiempo de espera mediante programación en la configuración de sesión de la sesión.

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

Para resolver el error, cambie el comando para que se complete dentro del intervalo de tiempo de espera o determine el origen del límite de tiempo de espera y aumente el intervalo de tiempo de espera para permitir que se complete el comando.

Por ejemplo, los siguientes comandos usan el New-PSSessionOption cmdlet para crear un objeto de opción de sesión con un valor OperationTimeout de 4 minutos (en MS) y, a continuación, usar el objeto de 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, vea el tema ayuda del proveedor WSMan (tipo Get-Help WSMan).

Para obtener más información sobre el New-PSSessionOption cmdlet, consulte New-PSSessionOption.

Solución de problemas de comportamiento no responde

En esta sección se describen los problemas de comunicación remota que impiden que un comando se complete y evite o retrase la devolución del símbolo del sistema de PowerShell.

Cómo interrumpir un comando

Algunos programas nativos de Windows, como programas con una interfaz de usuario, aplicaciones de consola que solicitan entradas 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. Para ver los errores que podrían haberse notificado, escriba $error el host local y la sesión remota.

Recuperación de un error de operación

ERROR: The I/O operation has been aborted because of either a thread exit
or an  application request.

Este error se devuelve cuando finaliza una operación antes de que se complete. Normalmente, se produce 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

Autenticación

Solo la autenticación básica funciona en macOS e intentar usar otros esquemas de autenticación puede provocar el bloqueo del proceso.

Consulte las instrucciones de autenticación de OMI .

Consulte también