Acerca de las Preguntas más frecuentes sobre el acceso remoto
DESCRIPCIÓN BREVE
Contiene preguntas y respuestas sobre cómo ejecutar comandos remotos en Windows PowerShell.
DESCRIPCIÓN LARGA
Cuando trabaja de forma remota, escribe comandos en Windows PowerShell en un equipo (conocido como "equipo local"), pero los comandos se ejecutan en otro equipo (conocido como "equipo remoto"). La experiencia de trabajar de forma remota debe ser tan parecida a trabajar directamente en el equipo remoto como sea posible.
Nota: Para usar Windows PowerShell comunicación remota, el equipo remoto debe configurarse para la comunicación remota. Para obtener más información, consulte about_Remote_Requirements.
¿AMBOS EQUIPOS DEBEN TENER INSTALADO WINDOWS POWERSHELL?
Sí. Para trabajar de forma remota, los equipos locales y remotos deben tener Windows PowerShell, Microsoft .NET Framework y el protocolo Web Services for Management (WS-Management). Los archivos y otros recursos necesarios para ejecutar un comando determinado deben estar en el equipo remoto.
Los equipos que ejecutan Windows PowerShell 3.0 y los equipos que ejecutan Windows PowerShell 2.0 pueden conectarse entre sí de forma remota y ejecutar comandos remotos. Sin embargo, algunas características, como la capacidad de desconectar de una sesión y volver a conectarse a ella, solo funcionan cuando ambos equipos ejecutan Windows PowerShell 3.0.
Debe tener permiso para conectarse al equipo remoto, permiso para ejecutar Windows PowerShell y permiso para acceder a almacenes de datos (como archivos y carpetas) y el registro en el equipo remoto.
Para obtener más información, consulte about_Remote_Requirements.
¿CÓMO FUNCIONA LA COMUNICACIÓN REMOTA?
Al enviar un comando remoto, el comando se transmite a través de la red al motor de Windows PowerShell en el equipo remoto y se ejecuta en el cliente Windows PowerShell en el equipo remoto. Los resultados del comando se devuelven al equipo local y aparecen en la sesión de Windows PowerShell en el equipo local.
Para transmitir los comandos y recibir la salida, Windows PowerShell usa el protocolo WS-Management. Para obtener información sobre el protocolo WS-Management, vea WS-Management Protocol en la documentación de Windows.
A partir de Windows PowerShell 3.0, las sesiones remotas se almacenan en el equipo remoto. Esto le permite desconectar de la sesión y volver a conectarse desde una sesión diferente o un equipo diferente sin interrumpir los comandos o perder el estado.
¿ES SEGURO LA COMUNICACIÓN REMOTA DE WINDOWS POWERSHELL?
Cuando se conecta a un equipo remoto, el sistema usa las credenciales de nombre de usuario y contraseña en el equipo local o las credenciales que proporcione en el comando para iniciar sesión en el equipo remoto. Las credenciales y el resto de la transmisión se cifran.
Para agregar protección adicional, puede configurar el equipo remoto para que use Capa de sockets seguros (SSL) en lugar de HTTP para escuchar las solicitudes de Administración remota de Windows (WinRM). A continuación, los usuarios pueden usar los parámetros UseSSL de los cmdlets Invoke-Command, New-PSSession y Enter-PSSession al establecer una conexión. Esta opción usa el canal HTTPS más seguro en lugar de HTTP.
¿TODOS LOS COMANDOS REMOTOS REQUIEREN COMUNICACIÓN REMOTA DE WINDOWS POWERSHELL?
No. Varios cmdlets tienen un parámetro ComputerName que permite obtener objetos del equipo remoto.
Estos cmdlets no usan Windows PowerShell comunicación remota. Por lo tanto, puede usarlos en cualquier equipo que ejecute Windows PowerShell, incluso si el equipo no está configurado para Windows PowerShell comunicación remota o si el equipo no cumple los requisitos para Windows PowerShell comunicación remota.
Estos cmdlets incluyen lo siguiente:
- Get-Process
- Get-Service
- Get-WinEvent
- Get-EventLog
- Get-WmiObject
- Test-Connection
Para buscar todos los cmdlets con un parámetro ComputerName, escriba:
Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName
Para determinar si el parámetro ComputerName de un cmdlet determinado requiere Windows PowerShell comunicación remota, consulte la descripción del parámetro. Para mostrar la descripción del parámetro, escriba:
Get-Help <cmdlet-name> -Parameter ComputerName
Por ejemplo:
Get-Help Get-Process -Parameter Computername
Para todos los demás comandos, use 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.
Incluya el comando entre llaves ( {} ) para convertirlo 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 a un equipo remoto (una sesión) y, a continuación, usar el parámetro Session de Invoke-Command para ejecutar el comando en la sesión.
Por ejemplo, los siguientes comandos ejecutan un comando de Get-Process de forma remota.
Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}
# - OR -
Invoke-Command -Session $s -ScriptBlock {Get-Process}
Para interrumpir un comando remoto, escriba CTRL+C. La solicitud de interrupción se pasa al equipo remoto, donde finaliza el comando remoto.
Para obtener más información sobre los comandos remotos, consulte about_Remote y los temas de Ayuda de los cmdlets que admiten la comunicación remota.
¿PUEDO SIMPLEMENTE "TELNET EN" UN EQUIPO REMOTO?
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 <ComputerName>
El símbolo del sistema cambia para mostrar que está conectado al equipo remoto.
<ComputerName>\C:>
Ahora, los comandos que escriba se ejecutan en el equipo remoto igual que si los escribe directamente en el equipo remoto.
Para finalizar la sesión interactiva, escriba:
Exit-PSSession
Una sesión interactiva es una sesión persistente que usa el protocolo WS-Management. No es lo mismo que usar Telnet, pero proporciona una experiencia similar.
Para obtener más información, consulte Enter-PSSession.
¿PUEDO CREAR UNA CONEXIÓN PERSISTENTE?
Sí. Puede ejecutar comandos remotos especificando el nombre del equipo remoto, su nombre NetBIOS o su dirección IP. O bien, puede ejecutar comandos remotos especificando una sesión de Windows PowerShell (PSSession) 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 usa la conexión para ejecutar solo el comando actual y, a continuación, cierra la conexión. Se trata de un método muy eficaz para ejecutar un solo comando o varios comandos no relacionados, incluso en muchos equipos remotos.
Cuando se usa el cmdlet New-PSSession para crear una PSSession, Windows PowerShell establece una conexión persistente para PSSession. A continuación, puede ejecutar varios comandos en PSSession, incluidos los comandos que comparten datos.
Normalmente, se crea una PSSession para ejecutar una serie de comandos relacionados que comparten datos. De lo contrario, 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, consulte about_PSSessions.
¿PUEDO EJECUTAR COMANDOS EN MÁS DE UN EQUIPO 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.
Al ejecutar un comando Invoke-Command, Windows PowerShell ejecuta los comandos en todos los equipos especificados o en todas las PSSession especificadas.
Windows PowerShell puede administrar cientos de conexiones remotas simultáneas. Sin embargo, el número de comandos remotos que puede enviar podría estar 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 Invoke-Command Ayuda.
¿DÓNDE ESTÁN MIS PERFILES?
Windows PowerShell perfiles no se ejecutan automáticamente en sesiones remotas, por lo que los comandos que agrega el perfil no están presentes en la sesión. Además, el $profile variable automática no se rellena en sesiones remotas.
Para ejecutar un perfil en una sesión, use el Invoke-Command cmdlet .
Por ejemplo, el siguiente comando ejecuta el perfil CurrentUserCurrentHost desde el equipo local de la sesión en $s.
Invoke-Command -Session $s -FilePath $profile
El siguiente comando ejecuta el perfil CurrentUserCurrentHost desde el equipo remoto de la sesión en $s. Dado que la variable $profile no se rellena, el comando usa la ruta de acceso explícita al perfil.
Invoke-Command -Session $s {
. "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}
Después de ejecutar este comando, los comandos que el perfil agrega a la sesión están disponibles en $s.
También puede usar un script de inicio en una configuración de sesión para ejecutar un perfil en cada sesión remota que use la configuración de sesión.
Para obtener más información sobre los perfiles de Windows PowerShell, consulte about_Profiles. Para obtener más información sobre las configuraciones de sesión, consulte Register-PSSessionConfiguration.
¿CÓMO FUNCIONA LA LIMITACIÓN EN COMANDOS REMOTOS?
Para ayudarle a administrar los recursos en el equipo local, Windows PowerShell incluye una característica de limitación por comando que le permite limitar el número de conexiones remotas simultáneas que se establecen para cada comando.
El valor predeterminado es 32 conexiones simultáneas, pero puede usar los parámetros ThrottleLimit de los cmdlets para establecer un límite personalizado para determinados comandos.
Al usar la característica de limitación, recuerde que se aplica a cada comando, no a toda la sesión o al equipo. Si ejecuta comandos simultáneamente en varias sesiones o PSSessions, el número de conexiones simultáneas es la suma de las conexiones simultáneas en todas las sesiones.
Para buscar cmdlets con un parámetro ThrottleLimit, escriba:
Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit
¿LA SALIDA DE LOS COMANDOS REMOTOS ES DIFERENTE DE LA SALIDA LOCAL?
Cuando se usa Windows PowerShell localmente, se envían y reciben objetos de .NET Framework "activos" ; Los objetos "dinámicos" son objetos asociados a programas reales o componentes del sistema. Al invocar los métodos o cambiar las propiedades de los objetos dinámicos, los cambios afectan al programa o componente real. Además, cuando cambian las propiedades de un programa o componente, también cambian las propiedades del objeto que las representan.
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 comandos remotos, es decir, convierte cada objeto en una serie de elementos de datos XML (Lenguaje de restricción en 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 es "activo", es decir, ya no está asociado directamente con el componente. Además, los métodos se quitan porque ya no son eficaces.
Normalmente, puede usar objetos deserializados igual que usaría objetos dinámicos, pero debe tener en cuenta sus limitaciones. Además, los objetos devueltos por el cmdlet Invoke-Command tienen propiedades adicionales que le ayudan a determinar el origen del comando.
Algunos tipos de objetos, como los objetos DirectoryInfo y los GUID, se convierten de nuevo en objetos activos cuando se reciben. Estos objetos no necesitan ningún control ni formato especiales.
Para obtener información sobre cómo interpretar y dar formato a la salida remota, consulte about_Remote_Output.
¿PUEDO EJECUTAR TRABAJOS EN SEGUNDO PLANO DE FORMA REMOTA?
Sí. Un trabajo en segundo plano Windows PowerShell es un comando de Windows PowerShell que se ejecuta de forma asincrónica sin interactuar con la sesión. Al iniciar un trabajo en segundo plano, el símbolo del sistema se devuelve inmediatamente y puede continuar trabajando en la sesión mientras se ejecuta el trabajo aunque se ejecute durante un período de tiempo prolongado.
Puede iniciar un trabajo en segundo plano incluso mientras se ejecutan otros comandos porque los trabajos en segundo plano siempre se ejecutan de forma asincrónica en una sesión temporal.
Puede ejecutar trabajos en segundo plano en un equipo local o remoto. De forma predeterminada, un trabajo en segundo plano se ejecuta en el equipo local. Sin embargo, puede usar el parámetro AsJob del cmdlet Invoke-Command para ejecutar cualquier comando remoto como un trabajo en segundo plano. Además, puede usar Invoke-Command para ejecutar un comando de Start-Job de forma remota.
Para obtener más información sobre los trabajos en segundo plano en Windows PowerShell , vea [about_Jobs(about_Jobs.md)] y [about_Remote_Jobs(about_Remote_Jobs.md)].
¿PUEDO EJECUTAR PROGRAMAS DE WINDOWS EN UN EQUIPO REMOTO?
Puede usar Windows PowerShell comandos remotos para ejecutar programas basados en Windows en equipos remotos. Por ejemplo, puede ejecutar Shutdown.exe o Ipconfig en un equipo remoto.
Sin embargo, no puede usar comandos Windows PowerShell para abrir la interfaz de usuario de cualquier programa en un equipo remoto.
Cuando se inicia un programa de Windows en un equipo remoto, el comando no se completa y el símbolo del sistema de Windows PowerShell no devuelve, hasta que finalice el programa o hasta que presione CTRL+C para interrumpir el comando. Por ejemplo, si ejecuta el programa IpConfig en un equipo remoto, el símbolo del sistema no devuelve hasta que IpConfig se complete.
Si usa comandos remotos para iniciar un programa que tiene una interfaz de usuario, se inicia el proceso de programa, pero la interfaz de usuario no aparece. El comando Windows PowerShell no se completa y el símbolo del sistema no vuelve hasta que detiene el proceso del programa o hasta que presione CTRL+C, lo que interrumpe el comando y detiene el proceso.
Por ejemplo, si usa un comando Windows PowerShell para ejecutar el Bloc de notas en un equipo remoto, el proceso del Bloc de notas se inicia en el equipo remoto, pero la interfaz de usuario del Bloc de notas no aparece. Para interrumpir el comando y restaurar el símbolo del sistema, presione CTRL+C.
¿PUEDO LIMITAR LOS COMANDOS QUE LOS USUARIOS PUEDEN EJECUTAR DE FORMA REMOTA EN MI EQUIPO?
Sí. Cada sesión remota debe usar una de las configuraciones de sesión en el equipo remoto. Puede administrar las configuraciones de sesión en el equipo (y los permisos para esas configuraciones de sesión) para determinar quién puede ejecutar comandos de forma remota en el equipo y qué comandos pueden ejecutar.
Una configuración de sesión configura el entorno de la sesión. Puede definir la configuración 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 opciones que protegen el equipo, como la configuración que limita la cantidad de datos que la sesión puede recibir de forma remota en un solo objeto o comando. También puede especificar un descriptor de seguridad que determine los permisos necesarios para usar la configuración.
El cmdlet Enable-PSRemoting crea las configuraciones de sesión predeterminadas en el equipo: Microsoft.PowerShell, Microsoft.PowerShell.Workflow y Microsoft.PowerShell32 (solo sistemas operativos de 64 bits). Enable-PSRemoting establece el descriptor de seguridad para la configuración para permitir que solo los miembros del grupo Administradores del equipo los usen.
Puede usar los cmdlets de configuración de sesión para editar las configuraciones de sesión predeterminadas, crear nuevas configuraciones de sesión y cambiar los descriptores de seguridad de todas las configuraciones de sesión.
A partir de Windows PowerShell 3.0, el cmdlet New-PSSessionConfigurationFile permite crear configuraciones de sesión personalizadas mediante un archivo de texto. El archivo incluye opciones para establecer el modo de idioma y para especificar los cmdlets y módulos que están disponibles en las sesiones que usan la configuración de sesión.
Cuando los usuarios usan los cmdlets Invoke-Command, New-PSSession o Enter-PSSession, pueden usar el parámetro ConfigurationName para indicar la configuración de sesión que se usa para la sesión. Además, pueden cambiar la configuración predeterminada que usan sus sesiones cambiando el valor de la variable de preferencia $PSSessionConfigurationName en la sesión.
Para obtener más información sobre las configuraciones de sesión, consulte la Ayuda para los cmdlets de configuración de sesión. Para buscar los cmdlets de configuración de sesión, escriba:
Get-Command *PSSessionConfiguration
¿QUÉ SON LAS CONFIGURACIONES DE FAN-IN Y FAN OUT?
El escenario de comunicación remota Windows PowerShell más común que implica varios equipos es la configuración uno a varios, en la que un equipo local (el equipo del administrador) se ejecuta Windows PowerShell comandos en numerosos equipos remotos. Esto se conoce como el escenario de "distribución ramificada".
Sin embargo, en algunas empresas, la configuración es de varios a uno, donde muchos equipos cliente se conectan a un único equipo remoto que ejecuta Windows PowerShell, como un servidor de archivos o un quiosco. Esto se conoce como la configuración de "fan-in".
Windows PowerShell comunicación remota admite configuraciones de distribución ramificada y de ventilador.
Para la configuración de distribución ramificada, Windows PowerShell usa 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 usa un complemento para 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 de "fan-in", Windows PowerShell usa Internet Information Services (IIS) para hospedar WS-Management, para cargar el complemento 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 host.
El hospedaje de IIS y la administración remota de ventilador no se admiten en Windows XP ni en Windows Server 2003.
En una configuración de ventilador, el usuario puede especificar un URI de conexión y un punto de conexión HTTP, incluido el transporte, el nombre del equipo, el puerto y el nombre de la aplicación. IIS reenvía todas las solicitudes con un nombre de aplicación especificado a la aplicación. El valor predeterminado es WS-Management, que puede hospedar Windows PowerShell.
También puede especificar un mecanismo de autenticación y prohibir o permitir el redireccionamiento desde puntos de conexión HTTP y HTTPS.
¿PUEDO PROBAR LA COMUNICACIÓN REMOTA EN UN SOLO EQUIPO (NO EN UN DOMINIO)?
Sí. Windows PowerShell comunicación remota está disponible incluso cuando el equipo local no está en un dominio. Puede usar las características de comunicación remota para conectarse a sesiones y crear sesiones en el mismo equipo. Las características funcionan igual que cuando se conecta a un equipo remoto.
Para ejecutar comandos remotos en un equipo de un grupo de trabajo, cambie la siguiente configuración de Windows en el equipo.
Precaución: esta configuración afecta a todos los usuarios del sistema y puede hacer que el sistema sea más vulnerable a un ataque malintencionado. Tenga cuidado al realizar estos cambios.
Windows XP con SP2:
Use la configuración de seguridad local (Secpol.msc) para cambiar la configuración de la directiva "Acceso a la red: uso compartido y seguridad para cuentas locales" en Configuración de seguridad\Directivas locales\Opciones de seguridad a "Clásico".
Windows Vista, Windows 7, Windows 8:
Create la siguiente entrada del Registro y, a continuación, establezca su valor en 1: LocalAccountTokenFilterPolicy en HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Puede usar el siguiente comando Windows PowerShell para agregar esta entrada:
$parameters = @{ Path='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' Name='LocalAccountTokenFilterPolicy' propertyType='DWord' Value=1 } New-ItemProperty @parametersWindows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2:
No se necesitan cambios porque la configuración predeterminada del "Modelo de acceso a la red: uso compartido y seguridad para cuentas locales" es "Clásico". Compruebe la configuración en caso de que haya cambiado.
¿PUEDO EJECUTAR COMANDOS REMOTOS EN UN EQUIPO DE OTRO DOMINIO?
Sí. Normalmente, los comandos se ejecutan sin errores, aunque es posible que tenga que usar el parámetro Credential de los Invoke-Commandcmdlets , New-PSSessiono Enter-PSSession para proporcionar las credenciales de un miembro del grupo Administradores en el equipo remoto. Esto a veces es necesario incluso cuando el usuario actual es miembro del grupo Administradores en los equipos locales y remotos.
Sin embargo, si el equipo remoto no está en un dominio en el que confía el equipo local, es posible que el equipo remoto no pueda autenticar las credenciales del usuario.
Para habilitar la autenticación, use el siguiente comando para agregar el equipo remoto a la lista de hosts de confianza para el equipo local en WinRM. Escriba el comando en el símbolo del sistema de Windows PowerShell.
Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>
Por ejemplo, para agregar el equipo Server01 a la lista de hosts de confianza en el equipo local, escriba el siguiente comando en el símbolo del sistema de Windows PowerShell:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01