TEMA about_Remote_Troubleshooting DESCRIPCIÓN BREVE Describe cómo solucionar problemas de las operaciones remotas en Windows PowerShell. DESCRIPCIÓN DETALLADA En esta sección se describen algunos de los problemas que podrían surgir al usar las características de comunicación remota de Windows PowerShell que están basadas en la tecnología WS -Management, y se incluyen sugerencias para solucionar estos problemas. Antes de utilizar la comunicación remota de Windows PowerShell, vea about_Remote y about_Remote_Requirements para obtener directrices sobre la configuración y el uso básico. Además, los temas de Ayuda para cada uno de los cmdlets de comunicación remota, particularmente las descripciones de parámetros, contienen información de utilidad que se ha diseñado para ayudarle a evitar problemas. Las versiones actualizadas de este tema, y otros temas de Ayuda de Windows PowerShell, se pueden encontrar en línea en Microsoft TechNet Library. Para ver la versión en pantalla de este tema de Ayuda, pegue la dirección URL siguiente en su explorador de Internet: https://go.microsoft.com/fwlink/?LinkID=135188 NOTA: en Windows Vista, Windows Server 2008 y versiones posteriores de Windows, para ver o cambiar la configuración del equipo local en la unidad WSMan:, incluidos los cambios a 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". SOLUCIONAR PROBLEMAS RELACIONADOS CON PERMISOS Y AUTENTICACIÓN En esta sección se analizan los problemas de comunicación remota relacionados con los requisitos de comunicación remota y los permisos de usuarios y equipos. CÓMO EJECUTAR COMO ADMINISTRADOR -------------------------------- ERROR: Acceso denegado. Debe ejecutar este cmdlet desde un proceso elevado. 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 a 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 secundario en un icono de Windows PowerShell (o ISE de Windows PowerShell) 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 secundario en el icono de Windows PowerShell y, a continuación, haga clic en "Ejecutar Windows PowerShell 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: ACCESO DENEGADO - O bien - ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se esté ejecutando en el host remoto y que esté configurado para escuchar solicitudes en el puerto y la dirección URL HTTP correctos. No se requiere ninguna configuración para que un equipo pueda enviar comandos remotos. Sin embargo, para recibir comandos remotos, el equipo debe estar configurado para la comunicación remota. La configuración incluye iniciar el servicio WinRM, establecer en Automático el tipo de inicio del servicio WinRM, crear agentes de escucha para las conexiones HTTP y HTTPS, y crear configuraciones de sesión predeterminadas. Para configurar un equipo de modo que pueda recibir comandos remotos, use el cmdlet Enable-PSRemoting. El comando siguiente habilita la configuración remota requerida y las configuraciones de sesión, y reinicia el servicio WinRM para que los cambios surtan efecto. enable-psremoting Para suprimir todas las confirmaciones de usuario, escriba: enable-psremoting -force Para obtener más información, vea Enable-PSRemoting. CÓMO HABILITAR LA COMUNICACIÓN REMOTA EN UNA EMPRESA ---------------------------------------------------- ERROR: ACCESO DENEGADO - O bien - ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se esté ejecutando en el host remoto y que esté configurado para escuchar solicitudes en el puerto y la dirección URL HTTP correctos. Para habilitar un equipo de modo que pueda recibir comandos remotos de Windows PowerShell y aceptar conexiones, utilice los cmdlets Enable-PSRemoting. Para habilitar la comunicación remota en varios equipos de una empresa, puede utilizar las opciones escaladas siguientes. -- Para configurar los agentes de escucha para la comunicación remota, habilite la directiva de grupo "Permitir la configuración automática de agentes de escucha". Para obtener instrucciones, vea "Cómo habilitar los agentes de escucha mediante una directiva de grupo (más adelante)". -- Para establecer en Automático el tipo de inicio de Administración remota de Windows (WinRM) en varios equipos, utilice el cmdlet Set-Service. Para obtener instrucciones, vea "Cómo establecer el tipo de inicio del servicio WinrM" (más adelante). -- Para habilitar una excepción de firewall, utilice la directiva de grupo "Firewall de Windows: Permitir excepciones de puertos locales". Para obtener instrucciones, vea "Cómo crear una excepción de firewall mediante una directiva de grupo (más adelante)". CÓMO HABILITAR LOS AGENTES DE ESCUCHA MEDIANTE UNA DIRECTIVA DE GRUPO --------------------------------------------------------------------- ERROR: ACCESO DENEGADO - O bien - ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se esté ejecutando en el host remoto y que esté configurado para escuchar solicitudes en el puerto y la dirección URL HTTP correctos. Para configurar los agentes de escucha en 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 la directiva de grupo: Configuración del equipo\Plantillas administrativas \Componentes de Windows\Administración remota de Windows (WinRM)\Servicio WinRM Habilite la directiva y especifique los filtros de IPv6 e IPv4. Se permite el uso de caracteres comodín (*). CÓMO HABILITAR UNA EXCEPCIÓN DE FIREWALL MEDIANTE UNA DIRECTIVA DE GRUPO ------------------------------------------------------------------ ERROR: ACCESO DENEGADO - O bien - ERROR: Se rechazó la conexión al host remoto. Compruebe que el servicio WS-Management se esté ejecutando en el host remoto y que esté configurado para escuchar solicitudes en el puerto y la dirección URL HTTP correctos. Para habilitar una excepción de firewall en todos los equipos de un dominio, habilite la directiva "Firewall de Windows: Permitir excepciones de puertos locales" en la siguiente ruta de acceso de la directiva de grupo: Configuración del equipo\Plantillas administrativas\Red \Conexiones de red\Firewall de Windows\Perfil de dominio Esta directiva permite a los miembros del grupo Administradores en el equipo utilizar Firewall de Windows en Panel de control para crear una excepción de firewall para el servicio Administración remota de Windows. CÓMO ESTABLECER EL TIPO DE INICIO DEL SERVICIO WINRM ---------------------------------------------------- ERROR: ACCESO DENEGADO La comunicación remota de Windows PowerShell depende del servicio WinRM (Administración remota de Windows). El servicio debe estar ejecutándose para admitir comandos remotos. En Windows Server 2003, Windows Server 2008 y Windows Server 2008 R2, el tipo de inicio del servicio WinRM (Administración remota de Windows) es Automático. Sin embargo, en Windows XP, Windows Vista y Windows 7, el servicio WinRM está deshabilitado de forma predeterminada. Para establecer el tipo de inicio de un servicio en un equipo remoto, utilice el cmdlet Set-Service. 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 comandos siguientes obtienen una lista de nombres de equipo del archivo Servers.txt y, a continuación, establecen en Automático el tipo de inicio del servicio WinRM de todos los equipos. C:\PS> $servers = get-content servers.txt C:\PS> set-service WinRM -computername $servers -startuptype Automatic Para ver los resultados, utilice el cmdlet Get-WMIObject 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: ACCESO DENEGADO 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 utiliza Enable-PSRemoting, crea configuraciones de sesión predeterminadas en el equipo local. Los usuarios remotos utilizan estas configuraciones de sesión cada vez que un comando remoto no incluye el parámetro ConfigurationName. Si se han eliminado las configuraciones predeterminadas en un equipo o no están registradas, utilice el cmdlet Enable-PSRemoting para volver a crearlas. Puede utilizar este cmdlet repetidamente. 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, utilice el cmdlet Unregister-PSSessionConfiguration para eliminar las configuraciones de sesión cambiadas y, a continuación, utilice 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 de RootSDDL, escriba: get-item wsman:\localhost\Service\RootSDDL Para cambiar RootSDDL, utilice el cmdlet Set-Item en la unidad WSMan:. Para cambiar el descriptor de seguridad de una configuración de sesión, utilice 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 correspondiente al proveedor de WS-Management ("get-help wsman"). CÓMO PROPORCIONAR CREDENCIALES DE ADMINISTRADOR ----------------------------------------------- ERROR: ACCESO DENEGADO 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. En algunas ocasiones se requieren credenciales aunque el usuario actual haya iniciado sesión en una cuenta que es 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, utilice 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: ACCESO DENEGADO Para establecer una PSSession o ejecutar un comando en un equipo remoto, el usuario debe tener permiso para utilizar las configuraciones de sesión en el equipo remoto. De forma predeterminada, solo los miembros del grupo Administradores en un equipo tienen permiso para utilizar las configuraciones de sesión predeterminadas. Por consiguiente, solo los miembros del grupo Administradores pueden conectarse al equipo de forma remota. Para que otros usuarios puedan conectarse al equipo local, debe proporcionarles permisos de ejecución a las configuraciones de sesión predeterminadas en el 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 Microsoft.PowerShell en el equipo local. Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI Para obtener más información, vea about_Session_Configurations. CÓMO HABILITAR LA COMUNICACIÓN REMOTA PARA ADMINISTRADORES EN OTROS DOMINIOS ------------------------------------------------------------- ERROR: ACCESO DENEGADO 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 desde otros dominios se ejecutan con sólo símbolos (token) de privilegio de usuario estándar. Sin embargo, puede utilizar la entrada del Registro LocalAccountTokenFilterPolicy para cambiar el comportamiento predeterminado y permitir a los usuarios remotos que son miembros del grupo Administradores la ejecución de comandos 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. Analice con cuidado las implicaciones de esta configuración antes de cambiar la directiva. Para cambiar la directiva, utilice el comando siguiente 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 UTILIZAR UNA DIRECCIÓN IP EN UN COMANDO REMOTO --------------------------------------------------- ERROR: El cliente WinRM no puede procesar la solicitud. Si el esquema de autenticación es distinto de Kerberos, o si el equipo cliente no está unido a un dominio, se debe usar el transporte HTTPS o agregar el equipo de destino al valor de configuración TrustedHosts. 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 admite direcciones IP, se utiliza la autenticación NTLM de forma predeterminada cada vez que se especifica una dirección IP. Cuando se utiliza la autenticación NTLM, se requiere el procedimiento siguiente para la comunicación remota. 1. Configure el equipo para transporte HTTPS o agregue las direcciones IP de los equipos remotos a la lista TrustedHosts en el equipo local. Para obtener instrucciones, vea "Cómo agregar un equipo a la lista TrustedHosts" (más adelante). 2. Utilice el parámetro Credential en todos los comandos remotos. Esto es necesario aunque se estén enviando las credenciales del usuario actual. CÓMO CONECTARSE DE FORMA REMOTA DESDE UN EQUIPO BASADO EN UN GRUPO DE TRABAJO ------------------------------------------------------------------ ERROR: El cliente WinRM no puede procesar la solicitud. Si el esquema de autenticación es distinto de Kerberos, o si el equipo cliente no está unido a un dominio, se debe usar el transporte HTTPS o agregar el equipo de destino al valor de configuración TrustedHosts. Cuando el equipo local no está en un dominio, se requiere el procedimiento siguiente para la comunicación remota. 1. Configure el equipo para transporte HTTPS o agregue los nombres de los equipos remotos a la lista TrustedHosts en el equipo local. Para obtener instrucciones, vea "Cómo agregar un equipo a la lista TrustedHosts" (más adelante). 2. Compruebe que se ha establecido una contraseña en el equipo basado en un grupo de trabajo. Si no se ha establecido una contraseña o el valor de la contraseña está en blanco, no se pueden ejecutar comandos remotos. Para establecer una contraseña para la cuenta de usuario, utilice Cuentas de usuario en Panel de control. 3. Utilice el parámetro Credential en todos los comandos remotos. Esto es necesario aunque se estén enviando 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 permite el uso de caracteres comodín. Para ver o cambiar la lista de hosts de confianza, utilice la unidad WSMan:. El elemento TrustedHost está en el nodo WSMan:\localhost\Client. Solo los miembros del grupo Administradores en el equipo tienen permiso para cambiar la lista de hosts de confianza en el equipo. Precaución: el valor que se establezca para el elemento TrustedHosts afectará a todos los usuarios del equipo. Para ver la lista de hosts de confianza, utilice el comando siguiente: get-item wsman:\localhost\Client\TrustedHosts También puede utilizar el cmdlet Set-Location (alias = cd) para navegar por la unidad WSMan: en la ubicación. Por ejemplo: "cd WSMan:\localhost\Client; dir". Para agregar todos los equipos a la lista de hosts de confianza, utilice el comando siguiente, que coloca el valor * (todos) en ComputerName set-item wsman:localhost\client\trustedhosts -value * También puede utilizar 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, utilice el formato de comando siguiente: set-item wsman:\localhost\Client\TrustedHosts -value <nombreDeEquipo>[,<nombreDeEquipo>] donde cada valor <nombreDeEquipo> debe tener el formato siguiente: <equipo>.<dominio>.<compañía>.<dominioDeNivelSuperior> 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 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, utilice el formato de comando siguiente: set-item wsman:\localhost\Client\TrustedHosts -value <direcciónIP> 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, utilice el cmdlet Connect-WSMan para agregar un nodo para el equipo remoto a la unidad WSMan: en el equipo local. A continuación, utilice un comando Set-Item para agregar el equipo. Para obtener más información acerca del cmdlet Connect-WSMan, vea Connect-WSMan. SOLUCIONAR PROBLEMAS RELACIONADOS CON LA CONFIGURACIÓN DE EQUIPOS En esta sección se analizan los problemas de comunicación remota relacionados con configuraciones concretas de un equipo, dominio o empresa. CÓMO CONFIGURAR LA COMUNICACIÓN REMOTA EN PUERTOS ALTERNATIVOS -------------------------------------------------------------- ERROR: Se rechazó la conexión al host remoto especificado. Compruebe que el servicio WS-Management se esté ejecutando en el host remoto y que esté configurado para escuchar solicitudes en el puerto y la dirección URL HTTP correctos. La comunicación remota de Windows PowerShell utiliza de forma predeterminada el puerto 80 para el transporte HTTP. El puerto predeterminado se utiliza siempre que el usuario no especifica los parámetros ConnectionURI o Port en un comando remoto. Para cambiar el puerto predeterminado que Windows PowerShell utiliza, use el cmdlet Set-Item en la unidad WSMan: para cambiar el valor Port en el nodo hoja de agentes 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: El cliente no puede conectarse con el destino especificado en la solicitud. Compruebe que el servicio del destino se esté ejecutando y que acepte solicitudes. Dado que la comunicación remota de Windows PowerShell utiliza el protocolo HTTP, se verá afectada por la configuración de proxy HTTP. En empresas que tienen servidores proxy, los usuarios no pueden tener acceso directo a un equipo remoto de Windows PowerShell. Para resolver este problema, utilice las opciones de configuración de proxy en el comando remoto. La configuración siguiente está disponible: -- ProxyAccessType -- ProxyAuthentication -- ProxyCredential Para establecer estas opciones para un comando concreto, utilice el procedimiento siguiente: 1. Utilice 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 para su empresa. Guarde el objeto de opción como una variable. 2. Utilice la variable que contiene el objeto de opción como el 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 opciones de sesión de proxy y, a continuación, utiliza 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 acerca del cmdlet New-PSSessionOption, vea New-PSSessionOption. Para establecer estas opciones para todos los comandos remotos en la sesión actual, utilice el objeto de opción que New -PSSessionOption crea en el valor de la variable de preferencia $PSSessionOption. Para obtener más información sobre la variable de preferencia $PSSessionOption, vea about_Preference_Variables. Para establecer estas opciones para todos los comandos remotos de todas las sesiones de Windows PowerShell en el equipo local, agregue la variable de preferencia $PSSessionOption a su perfil de Windows PowerShell. Para obtener más información sobre los perfiles de Windows PowerShell, vea about_Profiles. CÓMO DETECTAR UNA SESIÓN DE 32 BITS EN UN EQUIPO DE 64 BITS ------------------------------------------------------------ ERROR: El término "<nombreDeHerramienta>" no se reconoce como nombre de un cmdlet, función, archivo de script o programa ejecutable. 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 está ejecutando una versión de 64 bits de Windows y el comando remoto está utilizando una configuración de sesión de 32 bits, como Microsoft.PowerShell32, Administración remota de Windows (WinRM) cargará un proceso WOW64 y Windows redirigirá automáticamente al directorio %windir%\SysWOW64 todas las referencias al directorio %Windir%\System32. Como consecuencia, si intenta utilizar en el directorio System32 herramientas que no tengan homólogas en el directorio SysWow64, como Defrag.exe, dichas herramientas no se podrán encontrar en el directorio. Para buscar la arquitectura de procesador que se está usando en la sesión, utilice el valor de la variable de entorno PROCESSOR _ARCHITECTURE. El comando siguiente busca la arquitectura de 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 obtener más información sobre las configuraciones de sesión, vea about_session_configurations. SOLUCIONAR PROBLEMAS RELACIONADOS CON DIRECTIVAS Y PREFERENCIAS En esta sección se analizan 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 ------------------------------------------------------------ ERROR: Import-Module: No se puede cargar el archivo <nombreDeArchivo> porque en el sistema está deshabilitada la ejecución de scripts. Los cmdlets Import-PSSession y Export-PSSession crean módulos que contienen archivos de formato y archivos de script no firmados. Para importar los módulos creados por estos cmdlets, ya sea utilizando Import-PSSession o Import-Module, la directiva de ejecución en la sesión actual no puede ser Restricted ni AllSigned. Para obtener más información sobre las directivas de ejecución de Windows PowerShell, vea about_Execution_Policies. Para importar los módulos sin cambiar la directiva de ejecución del equipo local que está establecida en el Registro, utilice el parámetro Scope de Set-ExecutionPolicy con el fin de 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 de la directiva de ejecución sólo afecta al proceso actual y no cambia la configuración del Registro ExecutionPolicy de Windows PowerShell. set-executionpolicy -scope process -executionpolicy RemoteSigned También puede utilizar el parámetro ExecutionPolicy de PowerShell.exe para iniciar una única sesión con una directiva de ejecución menos restrictiva. powershell.exe -executionpolicy RemoteSigned Para obtener más información acerca de los cmdlets, vea Import -PSSession, Export-PSSession e Import-Module. Para obtener más información acerca de las directivas de ejecución, vea about_Execution_Policies. Para obtener más información acerca de las opciones de Ayuda de consola PowerShell.exe, escriba "powershell.exe -?". CÓMO ESTABLECER Y CAMBIAR CUOTAS -------------------------------- ERROR: El total de datos recibidos del cliente remoto supera el máximo permitido. Puede utilizar cuotas para proteger el equipo local y el equipo remoto del uso excesivo de recursos, tanto accidental como malintencionado. Las cuotas siguientes están disponibles en la configuración básica. -- El proveedor de WS-Management (WSMan:) proporciona varias configuraciones de cuotas, como las configuraciones MaxEnvelopeSizeKB y MaxProviderRequests en el nodo WSMan:\<nombreDeEquipo>, y las configuraciones MaxConcurrentOperations,MaxConcurrentOperationsPerUser y MaxConnections en el nodo WSMan:\<nombreDeEquipo>\Service. -- Puede proteger el equipo local utilizando los parámetros MaximumReceivedDataSizePerCommandMB y MaximumReceivedObjectSizeMB del cmdlet New-PSSessionOption y la variable de preferencia $PSSessionOption. -- Puede proteger el equipo remoto agregando restricciones a las configuraciones de sesión, como por ejemplo, utilizando 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 de modo que cumpla con la cuota. O bien, determine el origen de la cuota y, a continuación, auméntela para permitir que el comando se complete. Por ejemplo, el comando siguiente aumenta la cuota de tamaño de objeto en la configuración de sesión Microsoft.PowerShell en el equipo remoto de 10 MB (valor predeterminado) a 11 MB. Set-PSSessionConfiguration -name microsoft.powershell ` -MaximumReceivedObjectSizeMB 11 -Force Para obtener más información acerca del cmdlet New-PSSsessionOption, vea New-PSSessionOption. Para obtener más información sobre las cuotas de WS-Management, vea el tema de Ayuda correspondiente al proveedor de WS -Management (escriba "get-help WSMan"). CÓMO RESOLVER ERRORES DE TIEMPO DE ESPERA ----------------------------------------- ERROR: El servicio WS-Management no puede completar la operación en el tiempo especificado en OperationTimeout. Puede utilizar tiempos de espera para proteger el equipo local y el equipo remoto del uso excesivo de recursos, tanto accidental como malintencionado. Cuando se establecen tiempos de espera tanto en el equipo local como en el equipo remoto, Windows PowerShell utiliza la configuración de tiempo de espera más breve. Los tiempos de espera siguientes están disponibles en la configuración básica. -- El proveedor de WS-Management (WSMan:) proporciona varias configuraciones de tiempo de espera del lado de cliente y del lado de servicio, como la configuración MaxTimeoutms en el nodo WSMan:\<nombreDeEquipo> y las configuraciones EnumerationTimeoutms y MaxPacketRetrievalTimeSeconds en el nodo WSMan:\<nombreDeEquipo>\Service. -- Puede proteger el equipo local utilizando 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 mediante programación valores de tiempo de espera en la configuración de sesión para la sesión. Cuando un valor de tiempo de espera no permite que una operación se complete, Windows PowerShell finaliza la operación y genera un error. Para resolver el error, cambie el comando para completar la operación 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 el comando se complete. Por ejemplo, los comandos siguientes utilizan el cmdlet New -PSSessionOption para crear un objeto de opción de sesión con un valor OperationTimeout de 4 minutos (en MS) y, a continuación, utilizan 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 correspondiente al proveedor de WS-Management (escriba "get-help WSMan"). Para obtener más información acerca del cmdlet New-PSSsessionOption, vea New-PSSessionOption. SOLUCIONAR PROBLEMAS RELACIONADOS CON EL COMPORTAMIENTO SIN RESPUESTA En esta sección se analizan los problemas de conexión remota que evitan que un comando se complete y que evitan o retrasan la devolución del símbolo del sistema de Windows PowerShell. CÓMO INTERRUMPIR UN COMANDO -------------------------- Algunos programas de Windows nativos, como los programas con una interfaz de usuario, las aplicaciones de consola que solicitan datos y las aplicaciones de consola que utilizan la API de consola Win32, no funcionan correctamente en el host remoto de Windows PowerShell. Cuando se utilizan estos programas, es posible que se observe un comportamiento inesperado, como que no se produzcan resultados, que se produzca un resultado parcial o que no se complete un comando remoto. Para finalizar un programa que no responde, escriba CTRL + C. Para ver los errores que se hayan podido notificar, escriba "$error" en el host local y la sesión remota. VEA TAMBIÉN Versión en pantalla: https://go.microsoft.com/fwlink/?LinkID=135188 about_remote about_remote_requirements