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