about_Remote_Troubleshooting
Se aplica a: Windows PowerShell 2.0, Windows PowerShell 3.0, Windows PowerShell 4.0
TEMA
about_Remote_Troubleshooting
DESCRIPCIÓN BREVE
Describe cómo solucionar problemas de operaciones remotas en Windows PowerShell®.
DESCRIPCIÓN LARGA
En esta sección, se describen algunos de los problemas que pueden surgir al usar las características de comunicación remota de Windows PowerShell que se basan en la tecnología de WS-Management y se sugieren soluciones para dichos problemas.
Antes de usar la comunicación remota de Windows PowerShell, consulte about_Remote y about_Remote_Requirements para ver 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, contienen información útil diseñada para ayudarle a evitar problemas.
Las versiones actualizadas de este tema y otros temas de ayuda de Windows PowerShell pueden descargarse mediante el cmdlet Update-Help y pueden encontrarse en línea en Microsoft TechNet Library, en https://technet.microsoft.com/library/hh847850(v=wps.630).aspx.
NOTA: Para ver o cambiar la configuración del equipo local en la unidad WSMan:, entre lo que se incluyen los cambios en la configuración de sesión, los hosts de confianza, los puertos o los agentes de escucha, inicie Windows PowerShell con la opción "Ejecutar como administrador".
SOLUCIONAR PROBLEMAS DE PERMISOS Y AUTENTICACIÓN
En esta sección se describen los problemas de comunicación remota que están relacionados con los permisos de usuario y de equipo y con los requisitos de comunicación remota.
CÓMO EJECUTAR 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:, entre lo que se incluyen los cambios en la configuración 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 de Windows PowerShell ISE) y, luego, 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".
Nota: En Windows Server 2008 R2, el icono de Windows PowerShell está anclado a la barra de tareas de forma predeterminada.
CÓMO HABILITAR 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 es necesaria llevar a cabo ninguna configuración para habilitar un equipo para que envíe comandos remotos. Sin embargo, para recibir comandos remotos, la comunicación remota de Windows PowerShell debe estar habilitada en el equipo. Para habilitarla es necesario iniciar el servicio WinRM, establecer el tipo de inicio del servicio WinRM en Automático, crear agentes de escucha para las conexiones HTTP y HTTPS y crear configuraciones de sesión predeterminadas.
La comunicación remota de Windows PowerShell está habilitada de forma predeterminada en Windows Server 2012 y en versiones más recientes de Windows Server. En todos los demás sistemas, debe ejecutar el cmdlet Enable-PSRemoting para habilitar la comunicación remota. También puede ejecutar el cmdlet Enable-PSRemoting para volver a habilitar la comunicación remota en Windows Server 2012 y en versiones más recientes de Windows Server si la comunicación remota está deshabilitada.
Para configurar un equipo para que reciba comandos remotos, use el cmdlet Enable-PSRemoting. El siguiente comando habilita todas las configuraciones remotas necesarias, habilita las configuraciones de sesión y reinicia el servicio WinRM para que los cambios surtan efecto.
Enable-PSRemoting
Para suprimir todos los mensajes de usuario, escriba:
Enable-PSRemoting -Force
Para obtener más información, consulte Enable-PSRemoting.
CÓMO HABILITAR 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 habilitar un solo equipo para que reciba comandos remotos de Windows PowerShell y acepte las conexiones, use el cmdlet Enable-PSRemoting.
Para habilitar la comunicación remota en varios equipos de una empresa, puede usar las siguientes opciones escaladas.
-- Para configurar los agentes de escucha para la comunicación remota, habilite la directiva de grupo "Permitir configuración automática de escuchas". Para consultar las instrucciones, vea más abajo "Cómo habilitar los agentes de escucha mediante una directiva de grupo".
-- Para establecer en Automático el tipo de inicio de Administración remota de Windows (WinRM) en varios equipos, use el cmdlet Set-Service. Para consultar las instrucciones, vea más abajo "Cómo establecer el tipo de inicio del servicio WinRM".
-- Para habilitar una excepción de firewall, use la directiva de grupo "Firewall de Windows: permitir excepciones de puerto local". Para consultar las instrucciones, vea más abajo "Cómo crear una excepción de firewall mediante una directiva de grupo" (más abajo).
CÓMO HABILITAR LOS 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 configuración automática de escuchas" 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 los caracteres comodín (*).
CÓMO HABILITAR LA COMUNICACIÓN REMOTA EN REDES PÚBLICAS
ERROR: Unable to check the status of the firewall
El cmdlet Enable-PSRemoting devuelve este error cuando la red local es pública y no se usa el parámetro SkipNetworkProfileCheck en el comando.
En versiones de servidor de Windows, Enable-PSRemoting se ejecuta 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 (doméstica y del trabajo). Para 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 ejecuta correctamente en las redes privadas y de dominio. De forma predeterminada, se produce un error en las redes públicas, pero si se usa el parámetro SkipNetworkProfileCheck, Enable-PSRemoting se ejecuta 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 lugar, ejecute el comando siguiente:
Set-NetFirewallRule –Name "WINRM-HTTP-In-TCP-PUBLIC" –RemoteAddress Any
El módulo NetSecurity exporta el cmdlet Set-NetFirewallRule.
NOTA: En Windows PowerShell 2.0, en los 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 los equipos que ejecutan versiones de cliente de Windows, Enable-PSRemoting crea reglas de firewall que permiten el acceso remoto únicamente en redes privadas y de dominio.
CÓMO HABILITAR 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 todos los equipos de un dominio, habilite la directiva "Firewall de Windows: permitir excepciones de puerto local" en la siguiente ruta de acceso de directiva de grupo:
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
Esta directiva permite que los miembros del grupo Administradores del equipo usen el Firewall de Windows en el Panel de control para crear una excepción de firewall para el servicio de Administración remota de Windows.
CÓMO ESTABLECER EL TIPO DE INICIO DEL SERVICIO WINRM
ERROR: ACCESS IS DENIED
La comunicación remota de Windows PowerShell depende del servicio Administración remota de Windows (WinRM). El servicio debe estar ejecutándose para que admita 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 cmdlet Set-Service.
Para ejecutar el comando en varios equipos, puede crear un archivo de texto o un archivo CSV con los nombres de equipo.
Por ejemplo, los comandos siguientes obtienen una lista de nombres de equipo a partir del archivo Servers.txt y, a continuación, establecen en Automático el tipo de inicio del servicio WinRM en todos los equipos.
C:\PS> $servers = Get-Content servers.txt
C:\PS> Set-Service WinRM -ComputerName $servers -startuptype Automatic
Para ver los resultados, use el cmdlet Get-WMIObject con el objeto Win32_Service. Para más información, consulte Set-Service.
CÓMO VOLVER A CREAR LAS CONFIGURACIONES DE SESIÓN PREDETERMINADAS
ERROR: ACCESS IS DENIED
Para conectarse con el 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, se crean configuraciones de sesión predeterminadas en el equipo local. Los usuarios remotos usan estas configuraciones de sesión cada vez que un comando remoto no incluye el parámetro ConfigurationName.
Si se anula el registro de las configuraciones predeterminadas de un equipo o si se eliminan, use el cmdlet Enable-PSRemoting para volver a crearlas. Este cmdlet se puede usar varias veces. No genera errores si una característica ya está configurada.
Si cambia las configuraciones de sesión predeterminadas y desea restaurar las configuraciones de sesión predeterminadas originales, use el cmdlet Unregister-PSSessionConfiguration para eliminar las configuraciones de sesión modificadas y, a continuación, use el cmdlet Enable-PSRemoting 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 cmdlet Set-Item en la unidad WSMan: . Para cambiar el descriptor de seguridad de una configuración de sesión, use el cmdlet Set-PSSessionConfiguration con los parámetros SecurityDescriptorSDDL o ShowSecurityDescriptorUI.
Para obtener más información sobre la unidad WSMan:, vea el tema de ayuda del proveedor de 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 pertenecer al grupo Administradores del equipo remoto. A veces, se necesitan credenciales incluso cuando el usuario actual ya inició sesión en una cuenta que pertenece al grupo Administradores.
Si el usuario actual pertenece al grupo Administradores del equipo remoto, o si puede proporcionar las credenciales de un miembro del grupo Administradores, use el parámetro Credential de los cmdlets New-PSSession, Enter-PSSession o Invoke-Command para conectarse de forma remota.
Por ejemplo, el comando siguiente 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.
CÓMO HABILITAR 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 del 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 remotamente al equipo.
Para permitir que otros usuarios se conecten al equipo local, otorgue al usuario permisos de ejecución para las configuraciones de sesión predeterminadas del equipo local.
El comando siguiente 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 más información, consulte about_Session_Configurations.
CÓMO HABILITAR LA COMUNICACIÓN REMOTA PARA LOS ADMINISTRADORES DE OTROS DOMINIOS
ERROR: ACCESS IS DENIED
Cuando un usuario de otro dominio pertenece al grupo Administradores del 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 solo se ejecutan 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 pertenecen al grupo Administradores ejecuten con privilegios de administrador.
Precaución: La entrada LocalAccountTokenFilterPolicy deshabilita las restricciones remotas del Control de cuentas de usuario (UAC) para todos los usuarios de todos los equipos afectados. Considere detenidamente las implicaciones de esta configuración antes de cambiar la directiva.
Para cambiar la directiva, use el siguiente comando para establecer en 1 el valor de la entrada del Registro LocalAccountTokenFilterPolicy.
C:\PS> New-ItemProperty -Name LocalAccountTokenFilterPolicy -Path `
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -PropertyType `
DWord -Value 1
CÓMO USAR 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.
Los parámetros ComputerName de los cmdlets New-PSSession, Enter-PSSession e Invoke-Command aceptan una dirección IP como valor válido. Sin embargo, dado que la autenticación Kerberos no es compatible con las direcciones IP, se usa la autenticación NTLM de forma predeterminada siempre que se especifica una dirección IP.
Cuando se usa la autenticación NTLM, es necesario 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.
Para consultar las instrucciones, vea más abajo "Cómo agregar un equipo a la lista TrustedHosts".
2. Use el parámetro Credential en todos los comandos remotos.
Esto es necesario incluso si va a enviar las credenciales del usuario actual.
CÓMO CONECTARSE DE FORMA REMOTA DESDE UN EQUIPO BASADO EN UN 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, es necesario 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.
Para consultar las instrucciones, vea más abajo "Cómo agregar un equipo a la lista TrustedHosts".
2. Compruebe que hay una contraseña establecida en el equipo basado en un grupo de trabajo. Si no está establecida una contraseña o si su valor está vacío, no se puede ejecutar comandos remotos.
Para establecer la contraseña de su cuenta de usuario, use Cuentas de usuario en el Panel de control.
3. Use el parámetro Credential en todos los comandos remotos.
Esto es necesario incluso si va a enviar 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 con nombres de equipos, 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 se encuentra en el nodo WSMan:\localhost\Client.
Solo los miembros del grupo Administradores del equipo tienen permiso para cambiar la lista de hosts de confianza del equipo.
Precaución: el valor que establezca para el elemento TrustedHosts afecta a todos los usuarios del equipo.
Para ver la lista de hosts de confianza, use el comando siguiente:
Get-Item wsman:\localhost\Client\TrustedHosts
También puede usar el cmdlet Set-Location (alias = cd) para desplazarse por la unidad WSMan: hasta la ubicación. Por ejemplo: "cd WSMan:\localhost\Client; dir".
Para agregar todos los equipos a la lista de hosts de confianza, use el comando siguiente, que coloca el valor * (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 concreto a la lista de hosts de confianza. Por ejemplo, el comando siguiente 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 comando siguiente:
Set-Item wsman:\localhost\Client\TrustedHosts -Value <ComputerName>[,<ComputerName>]
donde cada valor <ComputerName> debe tener el formato siguiente:
<Computer>.<Domain>.<Company>.<top-level-domain>
Por ejemplo:
Set-Item wsman:\localhost\Client\TrustedHosts -Value Server01.Domain01.Fabrikam.com
Para agregar un nombre de equipo a una lista existente de hosts de confianza, primero guarde el valor actual en una variable y, a continuación, establezca 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, use 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 determinados a la lista de hosts de confianza, use el comando siguiente:
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 cmdlet Connect-WSMan para agregar un nodo para el equipo remoto a la unidad WSMan: del equipo local. A continuación, use un comando Set-Item para agregar el equipo.
Para obtener más información sobre el cmdlet Connect-WSMan, vea Connect-WSMan.
SOLUCIONAR PROBLEMAS DE CONFIGURACIÓN DEL EQUIPO
En esta sección se describen los problemas de comunicación remota que están relacionados con las configuraciones específicas de un equipo, dominio o empresa.
CÓMO CONFIGURAR 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 Windows PowerShell usa el puerto 80 para el transporte HTTP de forma predeterminada. El puerto predeterminado se usa cuando el usuario no especifica los parámetros ConnectionURI o Port en un comando remoto.
Para cambiar el puerto predeterminado que usa Windows PowerShell, utilice el cmdlet Set-Item en la unidad WSMan: para cambiar el valor Port en el nodo hoja del agente de escucha.
Por ejemplo, el comando siguiente cambia el puerto predeterminado a 8080.
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
CÓMO CONFIGURAR 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 Windows 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 a un equipo remoto de Windows PowerShell directamente.
Para resolver este problema, use las opciones de configuración de proxy en el comando remoto. Están disponibles las opciones siguientes:
--ProxyAccessType
--ProxyAuthentication
--ProxyCredential
Para establecer estas opciones para un comando concreto, use el procedimiento siguiente:
1. Use los parámetros ProxyAccessType, ProxyAuthentication y ProxyCredential del cmdlet New-PSSessionOption para crear un objeto de opción de sesión con la configuración de proxy de la empresa. Guarde el objeto de opción como una variable.
2. Use la variable que contiene el objeto de opción como valor del parámetro SessionOption de un comando New-PSSession, Enter-PSSession o Invoke-Command.
Por ejemplo, el comando siguiente crea un objeto de opción de sesión con las opciones de sesión del proxy y, a continuación, usa el objeto para crear una sesión remota.
C:\PS> $SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01
C:\PS> New-PSSession -ConnectionURI https://www.fabrikam.com
Para obtener más información sobre el cmdlet New-PSSessionOption, 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 variable de preferencia $PSSessionOption. Para más información sobre la variable de preferencia $PSSessionOption, consulte about_Preference_Variables.
Para establecer estas opciones en todos los comandos remotos de todas las sesiones de Windows PowerShell del equipo local, agregue la variable de preferencia $PSSessionOption a su perfil de Windows PowerShell. Para más información sobre los perfiles de Windows PowerShell, consulte about_Profiles.
CÓMO DETECTAR 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 redirecciona automáticamente al directorio %windir%\SysWOW64 todas las referencias al directorio %Windir%\System32.
Como resultado, si intenta usar las herramientas del directorio System32 que no tienen equivalentes en el directorio SysWow64, como Defrag.exe, las herramientas no se encontrarán 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 comando siguiente busca la arquitectura del procesador de la sesión en la variable $s.
C:\PS> $s = New-PSSession -ComputerName Server01 -configurationName CustomShell
C:\PS> invoke-command -session $s {$env:PROCESSOR_ARCHITECTURE}
x86
Para más información sobre las configuraciones de sesión, consulte about_session_configurations.
SOLUCIONAR PROBLEMAS DE DIRECTIVAS Y PREFERENCIAS
En esta sección se describen los problemas de comunicación remota que están relacionados con las directivas y las preferencias establecidas en los equipos locales y remotos.
CÓMO CAMBIAR LA DIRECTIVA DE EJECUCIÓN DE IMPORT-PSSESSION E IMPORT-MODULE
ERROR: Import-Module: File <filename> cannot be loaded because the
execution of scripts is disabled on this system.
Los cmdlets Import-PSSession 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 Restricted o AllSigned. (Para obtener información sobre las directivas de ejecución de Windows PowerShell, consulte about_Execution_Policies).
Para importar los módulos sin cambiar la directiva de ejecución del equipo local que está establecida en el Registro, use el parámetro Scope de Set-ExecutionPolicy para establecer una directiva de ejecución menos restrictiva para un solo proceso.
Por ejemplo, el comando siguiente inicia un proceso con la directiva de ejecución RemoteSigned. El cambio en la directiva de ejecución solo afecta al proceso actual y no cambia la configuración del Registro de ExecutionPolicy de Windows 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 obtener más información sobre los cmdlets, consulte Import-PSSession, Export-PSSession e Import-Module. Para obtener más información sobre las directivas de ejecución, vea about_Execution_Policies. Para obtener más información sobre las opciones de ayuda de la consola de PowerShell.exe, escriba "PowerShell.exe -?".
CÓMO ESTABLECER Y CAMBIAR LAS 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 a un uso excesivo de recursos, ya sea malintencionado o accidental.
Las cuotas siguientes están disponibles en la configuración básica.
-- El proveedor de WSMan (WSMan:) proporciona varios valores de cuota, como los valores MaxEnvelopeSizeKB y MaxProviderRequests en el nodo WSMan:\<ComputerName> y los valores MaxConcurrentOperations, MaxConcurrentOperationsPerUser y MaxConnections en el nodo WSMan:\<ComputerName>\Service.
-- Puede proteger el equipo local mediante los parámetros MaximumReceivedDataSizePerCommand y MaximumReceivedObjectSize del cmdlet New-PSSessionOption y la variable de preferencia $PSSessionOption.
-- Puede proteger el equipo remoto agregando restricciones a las configuraciones de sesión, por ejemplo usando los parámetros MaximumReceivedDataSizePerCommandMB y MaximumReceivedObjectSizeMB del cmdlet Register-PSSessionConfiguration.
Cuando las cuotas entran en conflicto con un comando, Windows PowerShell genera un error.
Para resolver el error, cambie el comando remoto para cumplir la cuota. También puede determinar el origen de la cuota y, a continuación, aumentarla para permitir que el comando se complete.
Por ejemplo, el comando siguiente aumenta la cuota de tamaño del objeto de 10 MB (el valor predeterminado) a 11 MB en la configuración de sesión de Microsoft.PowerShell en el equipo remoto.
Set-PSSessionConfiguration -Name microsoft.PowerShell `
-MaximumReceivedObjectSizeMB 11 -Force
Para obtener más información sobre el cmdlet New-PSSessionOption, vea New-PSSessionOption.
Para obtener más información sobre las cuotas de WS-Management, vea el tema de ayuda del proveedor de WSMan (tipo "Get-Help WSMan").
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 a un uso excesivo de recursos, ya sea malintencionado o accidental. Cuando los tiempos de espera están establecidos en el equipo local y el equipo remoto, Windows PowerShell usa la configuración de tiempo de espera más corta.
Los tiempos de espera siguientes están disponibles en la configuración básica.
-- El proveedor de WSMan (WSMan:) proporciona varias opciones de tiempo de espera de cliente y de servicio, como la configuración MaxTimeoutms en el nodo WSMan:\<ComputerName> y la configuración EnumerationTimeoutms y MaxPacketRetrievalTimeSeconds en el nodo WSMan:\<ComputerName>\Service.
-- Puede proteger el equipo local mediante los parámetros CancelTimeout, IdleTimeout, OpenTimeout y OperationTimeout del cmdlet New-PSSessionOption y la variable de preferencia $PSSessionOption.
-- También puede proteger el equipo remoto estableciendo los valores de tiempo de espera mediante programación en la configuración de la sesión.
Cuando un valor de tiempo de espera no permite que se complete una operación, Windows PowerShell finaliza la operación y genera un error.
Para resolver el error, cambie el comando para que se complete en el intervalo del tiempo de espera, o bien determine el origen del límite del tiempo de espera y aumente su intervalo para permitir que el comando se complete.
Por ejemplo, los comandos siguientes usan el cmdlet New-PSSessionOption para crear un objeto de opción de sesión con un valor OperationTimeout de 4 minutos (en milisegundos) y, a continuación, usan el objeto de opción de sesión para crear una sesión remota.
C:\PS> $pso = New-PSSessionoption -OperationTimeout 240000
C:\PS> New-PSSession -ComputerName Server01 -sessionOption $pso
Para obtener más información sobre los tiempos de espera de WS-Management, vea el tema de ayuda del proveedor de WSMan (escriba "Get-Help WSMan").
Para obtener más información sobre el cmdlet New-PSSessionOption, vea New-PSSessionOption.
SOLUCIONAR PROBLEMAS DE UN COMPORTAMIENTO QUE NO RESPONDE
En esta sección, se describen los problemas de comunicación remota que impiden que un comando se complete y que impiden o retrasan la devolución del símbolo del sistema de Windows PowerShell.
CÓMO INTERRUMPIR UN COMANDO
Algunos programas nativos de Windows, como los programas con interfaz de usuario, las aplicaciones de consola que solicitan que se introduzca información y las aplicaciones de consola que usan la API de la consola Win32, no funcionan correctamente en el host remoto de Windows PowerShell.
Al usar estos programas, podría ver un comportamiento inesperado, como un comando remoto que no se completa, la generación de resultados parciales o la falta de resultados.
Para finalizar un programa que no responde, presione CTRL+C. Para ver los errores que se notificaron, escriba "$error" en el host local y la sesión remota.
CÓMO RECUPERARSE DE UN ERROR DE FUNCIONAMIENTO
ERROR: The I/O operation has been aborted because of either a thread exit
or an application request.
Este error se devuelve cuando se termina una operación antes de que finalice. 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 y vuelva a intentar el comando.
1. Inicie Windows PowerShell con la opción "Ejecutar como administrador".
2. Ejecute el comando siguiente:
Start-Service WinRM3. Vuelva a ejecutar el comando que generó el error.
VEA TAMBIÉN
Versión en línea: https://technet.microsoft.com/library/hh847850(v=wps.630).aspx
about_Remote
about_Remote_Requirements
about_Remote_Variables