TEMA
about_Remote_FAQ
DESCRIPCIÓN BREVE
Contiene preguntas y respuestas referentes a la ejecución de
comandos remotos en Windows PowerShell.
DESCRIPCIÓN DETALLADA
Cuando se trabaja de forma remota, se escriben los comandos de
Windows PowerShell en un equipo (denominado "equipo local"),
pero los comandos se ejecutan en otro equipo (denominado "equipo
remoto"). En la medida de lo posible, la experiencia a la hora de
trabajar de forma remota debería ser similar a la de trabajar
directamente en el equipo local.
Nota: para poder utilizar la comunicación remota de Windows
PowerShell, el equipo remoto debe estar configurado para ella.
Para obtener más información, vea about_Remote_Requirements.
¿AMBOS EQUIPOS DEBEN TENER INSTALADO WINDOWS POWERSHELL?
Sí. Para poder trabajar de forma remota, el equipo local y el
equipo remoto deben tener Windows PowerShell, Microsoft .NET
Framework 2.0 y el protocolo Web Services for Management
(WS-Management). Los archivos y otros recursos necesarios para
ejecutar un comando concreto deben estar en el equipo remoto.
El usuario debe tener permiso para conectarse al equipo remoto,
permiso para ejecutar Windows PowerShell y permiso para obtener
acceso a los almacenes de datos (por ejemplo, archivos y carpetas)
y al Registro en el equipo remoto.
Para obtener más información, vea about_Remote_Requirements.
¿CÓMO FUNCIONA LA COMUNICACIÓN REMOTA?
Cuando se envía un comando remoto, este se transmite a través de
la red al motor de Windows PowerShell en el equipo remoto y se
ejecuta en el cliente de Windows PowerShell en dicho equipo.
Los resultados del comando se envían al equipo local y aparecen en
la sesión de Windows PowerShell en dicho equipo.
Para transmitir los comandos y recibir los resultados, Windows
PowerShell utiliza el protocolo WS-Management. Para obtener
información sobre el protocolo WS-Management, vea el artículo
referente a este protocolo en MSDN (Microsoft Developer Network)
Library, en https://go.microsoft.com/fwlink/? LinkId=144634
(puede estar en inglés).
¿LA COMUNICACIÓN REMOTA DE WINDOWS POWERSHELL ES SEGURA?
Cuando un usuario se conecta a un equipo remoto, el sistema
utiliza el nombre de usuario y la contraseña del equipo local o
las credenciales que se proporcionan en el comando para
conectarse al equipo remoto. Las credenciales y el resto de la
transmisión están cifrados.
Para agregar protección adicional, se puede configurar el equipo
remoto de modo que use Capa de sockets seguros (SSL) en lugar de
HTTP para escuchar las solicitudes de la Administración remota de
Windows (WinRM). De este modo, los usuarios pueden utilizar los
parámetros UseSSL de los cmdlets Invoke-Command, New-PSSession y
Enter-PSSession al establecer una conexión. Esta opción utiliza
el canal HTTPS, que es más seguro, en lugar de HTTP.
¿TODOS LOS COMANDOS REMOTOS REQUIEREN LA COMUNICACIÓN REMOTA DE
WINDOWS POWERSHELL?
No. Varios cmdlets tienen un parámetro ComputerName que permite
obtener objetos de equipos remotos.
Estos cmdlets no utilizan la comunicación remota de Windows
PowerShell. Por lo tanto, dichos cmdlets se pueden usar en
cualquier equipo en el que se ejecute Windows PowerShell, incluso
si el equipo no está configurado para la comunicación remota de
Windows PowerShell o no cumple los requisitos referentes a la
comunicación remota de Windows PowerShell.
Estos cmdlets son los siguientes:
Get-Process
Get-Service
Get-WinEvent
Get-EventLog
Get-WmiObject
Test-Connection
Para obtener todos los cmdlets con un parámetro ComputerName, escriba:
get-help * -parameter ComputerName
Para determinar si el parámetro ComputerName de un cmdlet concreto
requiere la comunicación remota de Windows PowerShell, vea la
descripción del parámetro. Para mostrar la descripción del
parámetro, escriba:
get-help <nombre del cmdlet> -parameter ComputerName
Por ejemplo:
get-help get-process -parameter Computername
Para todos los demás comandos, utilice el cmdlet Invoke-Command.
¿CÓMO SE EJECUTA UN COMANDO EN UN EQUIPO REMOTO?
Para ejecutar un comando en un equipo remoto, use el cmdlet
Invoke-Command.
Escriba el comando entre llaves ( {} ) para que se convierta en un
bloque de script. Use el parámetro ScriptBlock de Invoke-Command
para especificar el comando.
Puede usar el parámetro ComputerName de Invoke-Command para
especificar un equipo remoto. O bien, puede crear una conexión
persistente con un equipo remoto (sesión) y, a continuación,
utilizar el parámetro Session de Invoke-Command para ejecutar el
comando en la sesión.
Por ejemplo, los comandos siguientes ejecutan un comando
Get-Process de forma remota.
invoke-command -computername Servidor01, Servidor02 -scriptblock {get-process}
- O BIEN,
invoke-command -session $s -scriptblock {get-process}
Para interrumpir un comando remoto, presione CTRL+C. La solicitud
de interrupción se pasa al equipo remoto, donde termina el comando remoto.
Para obtener más información sobre los comandos remotos, vea
about_Remote y los temas de Ayuda referentes a los cmdlets que
admiten la comunicación remota.
¿SE PUEDE USAR TELNET PARA TRABAJAR DE FORMA REMOTA?
Se puede usar el cmdlet Enter-PSSession para iniciar una sesión
interactiva con un equipo remoto.
En el símbolo del sistema de Windows PowerShell, escriba:
Enter-PSSession <nombreDelEquipo>
El símbolo del sistema cambia para indicar que se ha conectado al
equipo remoto.
<nombreDelEquipo>\C:>
Ahora, los comandos que escriba se ejecutarán en el equipo remoto
como si los hubiera escrito directamente en el equipo remoto.
Para finalizar la sesión interactiva, escriba:
Exit-PSSession
Una sesión interactiva es una sesión persistente que utiliza el
protocolo WS-Management. No es lo mismo que utilizar Telnet, pero
proporciona una experiencia similar.
Para obtener más información, vea Enter-PSSession.
¿SE PUEDE CREAR UNA CONEXIÓN PERSISTENTE?
Sí. Para ejecutar comandos remotos, debe especificar el nombre
del equipo remoto, su nombre NetBIOS o su dirección IP. O bien,
debe especificar una sesión de Windows PowerShell (PSSession) que
esté conectada al equipo remoto.
Cuando se usa el parámetro ComputerName de Invoke-Command o
Enter-PSSession, Windows PowerShell establece una conexión
temporal. Windows PowerShell utiliza la conexión para ejecutar
únicamente el comando actual y, a continuación, cierra la
conexión. Es un método muy eficaz para ejecutar un solo comando o
varios comandos no relacionados, incluso en varios equipos remotos.
Cuando se usa el cmdlet New-PSSession para crear una PSSession,
Windows PowerShell establece una conexión persistente para la
PSSession. A continuación, se pueden ejecutar varios comandos en
la PSSession, incluidos comandos que comparten datos.
Se suele crear una PSSession para ejecutar una serie de comandos
relacionados que comparten datos. En otros casos, la conexión
temporal creada por el parámetro ComputerName es suficiente para
la mayoría de los comandos.
Para obtener más información sobre las sesiones, vea about_PSSessions.
¿SE PUEDEN EJECUTAR COMANDOS EN VARIOS EQUIPOS A LA VEZ?
Sí. El parámetro ComputerName del cmdlet Invoke-Command acepta
varios nombres de equipo y el parámetro Session acepta varias
PSSessions.
Cuando se ejecuta un comando Invoke-Command, Windows PowerShell
ejecuta los comandos en todos los equipos especificados o en todas
las PSSessions especificadas.
Windows PowerShell puede administrar cientos de conexiones remotas
simultáneas. Sin embargo, el número de comandos remotos que se
pueden enviar puede verse limitado por los recursos del equipo y
su capacidad para establecer y mantener varias conexiones de red.
Para obtener más información, vea el ejemplo en el tema de Ayuda
referente a Invoke-Command.
¿DÓNDE SE ENCUENTRAN LOS PERFILES?
Los perfiles de Windows PowerShell no se ejecutan automáticamente
en las sesiones remotas, por lo que los comandos que los perfiles
agregan no están presentes en las sesiones. Además, la variable
automática $profile no se rellena en las sesiones remotas.
Para ejecutar un perfil en una sesión, utilice el cmdlet
Invoke-Command.
Por ejemplo, el comando siguiente ejecuta el perfil
CurrentUserCurrentHost del equipo local en la sesión en $s.
invoke-command -session $s -filepath $profile
El comando siguiente ejecuta el perfil CurrentUserCurrentHost del
equipo remoto en la sesión en $s. Dado que no se rellena la
variable $profile, el comando utiliza la ruta de acceso explícita
al perfil.
invoke-command -session $s {. "$home\Documentos\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"}
Después de ejecutarse este comando, los comandos que el perfil
agrega a la sesión estarán disponibles en $s.
Asimismo, se puede utilizar un script de inicio en una
configuración de sesión para ejecutar un perfil en cada sesión
remota que utiliza la configuración de sesión.
Para obtener más información sobre los perfiles de Windows
PowerShell, vea about_Profiles. Para obtener más información sobre las
configuraciones de sesión, vea Register-PSSessionConfiguration.
¿CÓMO FUNCIONA LA LIMITACIÓN EN LOS COMANDOS REMOTOS?
Para poder administrar los recursos en el equipo local, Windows
PowerShell incluye una característica de limitación por comando
que permite limitar el número de conexiones remotas simultáneas
que se establecen para cada comando.
El valor predeterminado está establecido en 32 conexiones
simultáneas, pero se puede utilizar el parámetro ThrottleLimit de
los cmdlets a fin de establecer un límite personalizado para
comandos concretos.
Cuando utilice esta característica, recuerde que se aplica a cada
comando; no se aplica a la sesión ni al equipo. Si ejecuta
comandos en varias sesiones o PSSessions a la vez, el número de
conexiones simultáneas es la suma de las conexiones simultáneas en
todas las sesiones.
Para obtener los cmdlets con un parámetro ThrottleLimit, escriba:
get-help * -parameter ThrottleLimit
¿HAY DIFERENCIAS ESPECÍFICAS DEL SISTEMA EN LA COMUNICACIÓN REMOTA?
Cuando ejecute comandos en varios equipos, tenga en cuenta las
diferencias entre los equipos remotos, como diferencias en materia
de sistema operativo, estructura del sistema de archivos y Registro.
Cuando se establece una conexión con un equipo remoto en el que se
ejecuta Windows Vista o Windows Server 2003, la ubicación inicial
predeterminada es el directorio particular del usuario actual, que
está almacenado en la variable de entorno %homepath%
($env:homepath) y la variable $home de Windows PowerShell. En
Windows Vista, el directorio particular suele ser C:\Users\<nombreD
eUsuario>. En Windows Server 2003, el directorio particular suele
ser C:\Documents and Settings\<nombreDeUsuario>.
Cuando se establece una conexión con un equipo remoto en el que se
ejecuta Windows XP, la ubicación inicial predeterminada es el
directorio particular del usuario predeterminado, que está
almacenado en la variable de entorno %homepath% ($env:homepath)
del usuario predeterminado. El directorio particular suele ser
C:\Documents and Settings\Default User.
¿EL RESULTADO DE LOS COMANDOS REMOTOS ES DIFERENTE DEL RESULTADO LOCAL?
Cuando se usa Windows PowerShell localmente, se envían objetos
"activos" de .NET Framework. Los objetos "activos" son objetos que
están asociados a programas o componentes del sistema reales.
Cuando se invocan los métodos o se cambian las propiedades de los
objetos activos, los cambios afectan al programa o componente
real. Y, cuando cambian las propiedades de un programa o
componente, también cambian las propiedades del objeto.
Sin embargo, dado que la mayoría de los objetos activos no se
pueden transmitir a través de la red, Windows PowerShell
"serializa" la mayoría de los objetos enviados en los comandos
remotos, es decir, convierte cada objeto en una serie de elementos
de datos XML (Constraint Language in XML [CLiXML]) para la transmisión.
Cuando Windows PowerShell recibe un objeto serializado, convierte
el XML en un tipo de objeto deserializado. El objeto deserializado
es un registro preciso de las propiedades del programa o
componente en un momento anterior, pero ya no está "activo", es
decir, ya no está asociado directamente al componente. Además, se
quitan los métodos porque ya no son efectivos.
Normalmente, los objetos deserializados se pueden usar de la misma
manera que los objetos activos, pero se han de tener en cuenta sus
limitaciones. Además, los objetos devueltos por el cmdlet
Invoke-Command tienen propiedades adicionales que ayudan a
determinar el origen del comando.
Algunos tipos de objeto, como objetos DirectoryInfo y GUID, se
convierten de nuevo en objetos activos en el momento de
recibirlos. Estos objetos no necesitan ningún tratamiento o
formato especial.
Para obtener información sobre cómo interpretar y dar formato a
los resultados remotos, vea about_Remote_Output.
¿SE PUEDEN EJECUTAR TRABAJOS EN SEGUNDO PLANO DE FORMA REMOTA?
Sí. Un trabajo en segundo plano de Windows PowerShell es un
comando de Windows PowerShell que se ejecuta asincrónicamente sin
interactuar con la sesión. Cuando se inicia un trabajo en segundo
plano, el símbolo del sistema vuelve a aparecer inmediatamente y
se puede continuar trabajando en la sesión mientras se ejecuta el
trabajo, incluso si tarda mucho tiempo en ejecutarse.
Se puede iniciar un trabajo en segundo plano durante la ejecución
de otros comandos porque los trabajos en segundo plano siempre se
ejecutan asincrónicamente en una sesión temporal.
Se pueden ejecutar trabajos en segundo plano en un equipo local o
en un equipo remoto. De forma predeterminada, los trabajos en
segundo plano se ejecutan en el equipo local. Sin embargo, se
puede usar el parámetro AsJob del cmdlet Invoke-Command para
ejecutar cualquier comando remoto como un trabajo en segundo
plano. Además, se puede utilizar Invoke-Command para ejecutar un
comando Start-Job de forma remota.
Para obtener más información sobre los trabajos en segundo plano
en Windows PowerShell, vea about_Jobs y about_Remote_Jobs.
¿SE PUEDEN EJECUTAR PROGRAMAS BASADOS EN WINDOWS EN UN EQUIPO REMOTO?
Se pueden utilizar comandos remotos de Windows PowerShell para
ejecutar programas basados en Windows en un equipo remoto. Por
ejemplo, se puede ejecutar Shutdown.exe o Ipconfig en un equipo remoto.
Sin embargo, no se pueden usar comandos de Windows PowerShell
para abrir la interfaz de usuario de ningún programa en un equipo remoto.
Cuando se inicia un programa basado en Windows en un equipo
remoto, el comando no se completa y no vuelve a aparecer el
símbolo del sistema de Windows PowerShell hasta que finalice el
programa o se presionen las teclas CTRL+C para interrumpir el
comando. Por ejemplo, si ejecuta IpConfig en un equipo remoto, el
símbolo del sistema no vuelve a aparecer hasta que se complete IpConfig.
Si se usan comandos remotos para iniciar un programa que tiene
una interfaz de usuario, se inicia el proceso del programa pero
no aparece la interfaz de usuario. El comando de Windows
PowerShell no se completa y el símbolo del sistema no vuelve a
aparecer hasta que se detenga el proceso del programa o se presionen
las teclas CTRL+C para interrumpir el comando y detener el proceso.
Por ejemplo, si utiliza un comando de Windows PowerShell para
ejecutar Bloc de notas en un equipo remoto, se inicia el proceso
de Bloc de notas en el equipo remoto pero no aparece la interfaz
de usuario de este programa. Para interrumpir el comando y
restaurar el símbolo del sistema, presione CTRL+C.
¿SE PUEDEN LIMITAR LOS COMANDOS QUE LOS USUARIOS PUEDEN EJECUTAR DE
FORMA REMOTA EN UN EQUIPO LOCAL?
Sí. Cada sesión remota debe utilizar una de las configuraciones
de sesión en el equipo remoto. Se pueden administrar las
configuraciones de sesión en el equipo local (y los permisos para
dichas configuraciones de sesión) a fin de determinar quién puede
ejecutar comandos de forma remota en el equipo local y qué
comandos se pueden ejecutar.
Una configuración de sesión configura el entorno de la sesión.
La configuración se puede definir mediante un ensamblado que
implemente una nueva clase de configuración o mediante un script
que se ejecute en la sesión.
La configuración puede determinar los comandos que están
disponibles en la sesión. Además, la configuración puede incluir
valores que protegen el equipo, como valores que limitan la
cantidad de datos que la sesión puede recibir de forma remota en
un solo objeto o comando. Asimismo, se puede especificar un
descriptor de seguridad que determine los permisos necesarios
para utilizar la configuración.
El cmdlet Enable-PSRemoting crea una configuración de sesión
predeterminada en el equipo, Microsoft.PowerShell (y
Microsoft.PowerShell32 en los sistemas operativos de 64 bits).
Enable-PSRemoting establece el descriptor de seguridad de la
configuración de modo que solo los miembros del grupo
Administradores en el equipo puedan usar dicha configuración.
Se pueden usar los cmdlets de configuración de sesión para
modificar las configuraciones de sesión predeterminadas, crear
configuraciones de sesión y cambiar los descriptores de seguridad
de todas las configuraciones de sesión.
Cuando se usan los cmdlets Invoke-Command, New-PSSession o
Enter-PSSession, se puede utilizar el parámetro ConfigurationName
para indicar la configuración de sesión que se usa para la
sesión. Además, se puede cambiar la configuración predeterminada
utilizada por las sesiones modificando el valor de la variable de
preferencia $PSSessionConfigurationName en la sesión.
Para obtener más información sobre las configuraciones de sesión,
vea la Ayuda referente a los cmdlets de configuración de sesión.
Para obtener los cmdlets de configuración de sesión, escriba:
get-command *pssessionconfiguration
¿EN QUÉ CONSISTEN LAS CONFIGURACIONES DENOMINADAS FAN-IN Y FAN-OUT?
El escenario más común de la comunicación remota de Windows
PowerShell con varios equipos es la configuración uno a varios,
donde un solo equipo local (equipo del administrador) ejecuta
comandos de Windows PowerShell en varios equipos remotos. Este
escenario se conoce como "fan-out".
Sin embargo, en algunas empresas, la configuración utilizada es la
de varios a uno, donde varios equipos cliente se conectan a un
solo equipo remoto en el que se ejecuta Windows PowerShell, como
un servidor de archivos o un quiosco multimedia.
Esta configuración se conoce como "fan-in".
La comunicación remota de Windows PowerShell admite tanto la
configuración fan-out como la configuración fan-in.
Para la configuración fan-out, Windows PowerShell utiliza el
protocolo Web Services for Management (WS-Management) y el
servicio WinRM que admite la implementación de Microsoft de
WS-Management. Cuando un equipo local se conecta a un equipo
remoto, WS-Management establece una conexión y utiliza un
complemento de Windows PowerShell para iniciar el proceso de host
de Windows PowerShell (Wsmprovhost.exe) en el equipo remoto. El
usuario puede especificar un puerto alternativo, una configuración
de sesión alternativa y otras características para personalizar la
conexión remota.
Para admitir la configuración fan-in, Windows PowerShell utiliza
Internet Information Services (IIS) para hospedar WS-Management,
cargar el complemento de Windows PowerShell e iniciar Windows
PowerShell. En este escenario, en lugar de iniciar cada sesión de
Windows PowerShell en un proceso independiente, todas las sesiones
de Windows PowerShell se ejecutan en el mismo proceso de host.
Windows XP y Windows Server 2003 no admiten el hospedaje a través
de IIS ni la administración remota del tipo fan-in.
En la configuración fan-in, el usuario puede especificar un
identificador URI de conexión y un extremo HTTP, incluidos el
transporte, el nombre de equipo, el puerto y el nombre de
aplicación. IIS envía a la aplicación todas las solicitudes con el
nombre de aplicación especificado. De forma predeterminada, es
WS-Management, que puede hospedar Windows PowerShell.
También se puede especificar un mecanismo de autenticación y
prohibir o permitir la redirección desde extremos HTTP y HTTPS.
¿SE PUEDE PROBAR LA COMUNICACIÓN REMOTA EN UN SOLO EQUIPO (QUE NO
ESTÉ EN UN DOMINIO)?
Sí. La comunicación remota de Windows PowerShell está disponible
incluso si el equipo local no está en un dominio. Se pueden usar
las características de comunicación remota para conectarse a
sesiones y crear sesiones en el mismo equipo. Las características
funcionan de la misma manera que cuando se establece una conexión
con un equipo remoto.
Para ejecutar comandos remotos en un equipo de un grupo de
trabajo, cambie las siguientes configuraciones de Windows en
dicho equipo.
Precaución: estas configuraciones afectan a todos los usuarios
del sistema y pueden dar lugar a que el sistema sea más
vulnerable a ataques malintencionados. Actúe con precaución a la
hora de realizar estos cambios.
-- Windows XP con SP2:
Utilice la configuración de seguridad local (Secpol.msc) para
cambiar a "Clásico" la configuración de la directiva "Acceso
a redes: modelo de seguridad y uso compartido para cuentas
locales" en Configuración de seguridad\Directivas
locales\Opciones de seguridad.
-- Windows Vista:
Cree la siguiente entrada en el Registro y, a continuación,
establezca su valor en 1:
LocalAccountTokenFilterPolicy en
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Puede utilizar el siguiente comando de Windows PowerShell
para agregar esta entrada:
new-itemproperty `
-path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
-name LocalAccountTokenFilterPolicy -propertyType DWord -value 1
-- Windows 2003:
No es preciso realizar ningún cambio porque la configuración
predeterminada de la directiva "Acceso a redes: modelo de
seguridad y uso compartido para cuentas locales" es
"Clásico". Compruebe la configuración por si ha cambiado.
¿SE PUEDEN EJECUTAR COMANDOS REMOTOS EN UN EQUIPO DE OTRO DOMINIO?
Sí. Normalmente, los comandos se ejecutan correctamente, aunque
es posible que haya que usar el parámetro Credential de los
cmdlets Invoke-Command, New-PSSession o Enter-PSSession para
proporcionar las credenciales de un miembro del grupo
Administradores en el equipo remoto. En algunas ocasiones se
requieren dichas credenciales incluso si el usuario actual es
miembro del grupo Administradores en el equipo local y en el
equipo remoto.
No obstante, si el equipo remoto está en un dominio en el que no
confíe el equipo local, es posible que no pueda autenticar las
credenciales del usuario.
Para habilitar la autenticación, utilice el comando siguiente a
fin de agregar el equipo remoto a la lista de hosts de confianza
del equipo local en WinRM.
Escriba el comando en el símbolo del sistema de Windows PowerShell.
set-item WSMan:\localhost\Client\TrustedHosts -value <nombre del equipo remoto>
Por ejemplo, para agregar el equipo Servidor01 a la lista de
hosts de confianza en el equipo local, escriba el comando
siguiente en el símbolo del sistema de Windows PowerShell:
set-item WSMan:\localhost\Client\TrustedHosts -value Servidor01
VEA TAMBIÉN
about_Remote
about_Profiles
about_PSSessions
about_Remote_Jobs
Invoke-Command
New-PSSession