Windows PowerShellPermanezca colocada.
Don Jones
Contenido
La solución
Vea IT en acción
Servicios remotos de uno a varios
IT poner fuera de su opinión
Es la administración remota, escuela nuevo estilo
Siempre he frustrado por el mensaje dual que viene a veces fuera de Microsoft sobre administración de servidores: por on un lado, está rightly dijimos para instalar las herramientas de administración en nuestros equipos cliente y utilizar estas herramientas para administrar nuestros servidores.No está deberían incluirse en el Centro de datos y incluso mediante Escritorio remoto es trampa técnicamente ya que es básicamente sólo va en el Centro de datos sin realizar el recorrido.Por otro lado, sin embargo, hay muchas servidor de administración tareas que no pueden realizarse fácilmente mediante las herramientas remotas existentes, cambiar direcciones IP o nada con la configuración de red, por ejemplo.
Windows PowerShell preguntas y respuestas
P¿Una secuencia de comandos de Windows PowerShell se puede utilizar como una secuencia de comandos de inicio de sesión?
A Sí, pero no puede haber cualquier punto de hacerlo.Simplemente no puede arrastrar la secuencia de comandos en un objeto de directiva de grupo (GPO) de la forma que puede que un archivo VBScript.En su lugar, tiene que crear básicamente un archivo por lotes se ejecuta el Powershell.exe, pasando el parámetro de línea de comandos que indica lo qué secuencia de comandos para ejecutar.Es difícil.También debe instalar Windows PowerShell en cada equipo donde se ejecutará esa secuencia de comandos inicio de sesión.En el extremo, tenga en cuenta que Windows PowerShell es un poco más independiente de VBScript o el shell Cmd.exe.¿Por ejemplo, no afectará asignar una unidad mediante el cmdlet PSDrive de nuevo al explorador de Windows, deberá hacer retroceder el comando net use para realmente asignar una unidad en Windows y, si se va a hacerlo por qué no sólo utilice un archivo por lotes tradicional, que es más fácil incluir en un objeto de directiva de grupo?
P¿Secuencias de comandos de Windows PowerShell se pueden programar?
A absoluta.Realmente, podrá programar PowerShell.exe (que se encuentra en la carpeta % systemroot %, en /WindowsPowerShell) y darle un parámetro de línea de comandos que especifica la secuencia de comandos que desee ejecutar.Asegúrese de que la tarea programada se ha configurado para utilizar una cuenta de usuario que tenga los permisos necesarios para realizar lo que realiza la secuencia de comandos y asegúrese de que la directiva de ejecución de shell está configurada para permitir la ejecución de secuencias de comandos (prefiero la directiva AllSigned yo mismo, lo que significa la secuencia de comandos deberá firmarse digitalmente; ejecutar "Ayuda about_signing" en el shell para obtener información detallada sobre esto).
P¿Hay una forma fácil de trabajar con permisos de archivos y carpetas en Windows PowerShell?
A que.Tienes los comandos Get-ACL y Set-ACL, para empezar, Get-ACL es fantástico si todo lo que necesita hacer es informe sobre permisos.Francamente, es poco práctico utilizar estos comandos para realmente cambiar permisos, permisos de Windows son bestias muy complicados y la programación que debe hacer para establecer las listas de control (ACL) de acceso es igualmente complicada.Pero, ¿quién dice que tiene que utilizar cmdlets?El shell es excelente al ejecutar herramientas de línea de comandos más tradicionales y gran desde dentro de Windows PowerShell de trabajo de las distintas iteraciones de cacls.exe (incluidos los como DSACLS para Active Directory).Utilizan siempre ellos cuando necesarios para modificar o establecer permisos de archivos y carpetas.
La configuración de una nueva instalación de Server Core es otro ejemplo excelente.Agregar funciones, configurar la red, incluso activar Windows deben todas realizarse desde una ventana de consola local o a través de escritorio remoto, mediante las herramientas de línea de comandos.¿Qué herramientas existen actualmente son soluciones punto escrita personalizada que controlar una sola tarea o soluciones que requieren la experiencia con (WMI).Me gusta WMI, pero para ser sinceros, es demasiado compleja para la mayoría de los administradores de dedicamos mucho tiempo de aprendizaje y por lo tanto, no a menudo se utiliza.
Windows PowerShell se comprometió a facilitar todo esto, realizando un poco más fáciles de controlar WMI, pero lo que es más importante, por las tareas administrativas en los cmdlets más fácil de utilizar que se corresponden aproximadamente con las utilidades de línea de comandos que hemos utilizado para los años de ajuste.Problema del shell es que, aparte de WMI, es esencialmente un shell local.Muchos de sus cmdlets de configuración del sistema operativo principal no proporcionan compatibilidad con cualquier para ponerse en contacto con un equipo remoto.El shell también no soluciona uno de los problemas más egregious de WMI: su uso de llamadas a procedimiento remoto (RPC) para la conectividad remota.RPC son un jaleo en entornos que utilizan los servidores de seguridad locales (y quién no estos días?), a menudo hace que WMI quede inservible para cualquier tipo de administración remota.
La solución
Microsoft ha sido consciente de estos defectos durante bastante tiempo, pero que tomó algún tiempo para todos los corrige el necesario para alinear un único producto.Ese producto es Windows PowerShell v2, que incluye una nueva versión de Windows Remote Management (WRM).Ambos se distribuirá por primera vez en Windows 7 y Windows Server 2008 R2 y ambos será preinstalados en esos sistemas operativos de forma predeterminada.
Las tecnologías también estarán disponibles para versiones anteriores de Windows, posiblemente hasta fondo como Windows XP.Pero como de escribir este documento, no oficial anuncio ha se hayan hecho sobre exactamente qué sistemas operativos anteriores serán compatibles (el anterior el sistema operativo, tarea de Microsoft más difícil, porque las versiones anteriores pueden carecen de algunas el necesario principales tecnologías auxiliares).
WinRM es realmente la tecnología de clave que permite todo este.Es una implementación de Microsoft de WS-MAN o servicios Web para administración y, como el nombre implica, usa HTTP y HTTPS para comunicarse, lo que significa que es fácil obtener el tráfico a través de un servidor de seguridad.A diferencia de RPC, que se inicie en un único punto conocido y mueva su conversación a un puerto aleatoriamente seleccionado, utilizar un único puerto HTTP y HTTPS, 80 y 443 de forma predeterminada, pero puede configurar si no le gustan los.WinRM permite muchas aplicaciones diferentes para que "escuche" las conexiones entrantes de administración y Windows PowerShell v2 es una aplicación capaz de hacerlo.(Personalmente, Creo que WMI podría migrar finalmente para usar WinRM.)
Básicamente, puede sentarse en el equipo cliente y pedirle que realice una conexión de shell a un equipo remoto.WinRM que activa en el equipo remoto, que gira en vez de una instancia de Windows PowerShell v2 en el equipo remoto.Esa instancia del shell es capaz de ejecutar los comandos y entregar los resultados a su equipo.
Vea IT en acción
Las versiones beta pública de Windows 7 fueron la primera vez el mundo en grande podría probar esta: abrir una sesión de Windows PowerShell en el servidor, o en varios servidores, y ejecuta habilitar PSRemoting para configurar WinRM e iniciar el servicio WinRM.A continuación, vaya al equipo cliente, también se ejecuta Windows PowerShell v2, y ejecuta la sesión de $ = nuevo PSSession NombreDeEquipo, proporcionar el nombre del servidor que acaba de configurar para acceso remoto.El cmdlet New PSSession también puede aceptar credenciales alternativas, si es necesario y indicará utilizar puertos no estándar si eso es lo que haya configurado.
Si ve un mensaje de error largo como la Figure 1 , es de la forma autentica de WinRM.Utiliza Kerberos de forma predeterminada, pero en un entorno que no sea de dominio (como del equipo de laboratorio ilustrado), Kerberos no es una opción.Cuando Kerberos no está disponible, WinRM exige el uso del transporte HTTPS, que requiere que esté instalado un certificado SSL en el equipo servidor.Esto se hace para proporcionar autenticación mutua entre usted y el servidor para que sepa que está conectado el equipo que desea.Autenticación básica o implícita incluso si se especifica en el parámetro –auth no ayuda, porque WinRM desea utilizar HTTPS para cifrar tráfico.¿La solución más fácil?Estar en un dominio de Active Directory!
Figura 1 autentica un mensaje de error larga como éste puede producirse because of el wayWinRM.
Con la sesión activada, está listo para empezar a utilizarlo.Sesión de $ PSSession escriba conectará, live, con el servidor remoto.Por arte de magia, que está escribiendo en su instancia de Windows PowerShell.Comandos interactiva y verá inmediatamente los resultados, no a diferencia de SSH o tecnologías similares que se utiliza a menudo en equipos UNIX.
Windows PowerShell tiene incluso algunas cifrado predeterminado, por lo que si no utiliza HTTPS, todavía es bastante protegidos contra interceptores.Ejecute salir PSSession para desasociar de la consola remota y volver a su consola local.El shell pedirá incluso los cambios cuando está conectado a un equipo remoto, que le recuerde dónde se encuentra.
Servicios remotos de uno a varios
¿Para poder ejecutar comandos en un equipo es excelente, pero frecuencia es necesario lo uno en un servidor?Más comúnmente, encuentro que necesito para ejecutar un comando o un conjunto de comandos, en un montón completo de equipos.Lo que hemos utilizado hasta ahora en v1 de Windows PowerShell se denomina remoting de uno a uno (1: 1), lo que significa que un único administrador administrar un único equipo remoto.Pero el shell también ofrece uno a muchos remoting (1: n), donde un solo administrador puede administrar varios equipos.El truco está en el parámetro – computername de PSSession de nuevo.
Permitirme repita Mi comando anterior, pero esta vez va realmente deletrear el parámetro que permite el shell se supone: equipo de nuevo PSSession – computername.Porque – computername es un parámetro posicional, no era necesario especificar el nombre de parámetro real anteriormente, pero hacerlo ahora es más fácil comprender este truco: $ sesiones = nuevo PSSession – computername (Get-Content c:\names.txt).Suponiendo que el archivo C:\names.txt contiene una lista de nombres de equipo, uno nombre de equipo por línea, el shell creará una sesión remota para cada uno de ellos, almacenar la lista completa de sesiones en la variable de sesiones de $.
De forma predeterminada, las sesiones se crean mediante cualquier credenciales propio Windows PowerShell se ejecuta bajo, por lo tanto, mi cuenta de inicio de sesión o una cuenta utiliza con ejecutar como al iniciar el shell.Una palabra de precaución: si tiene habilitado control de cuentas de usuario (UAC), asegúrese de iniciar explícitamente el shell "como administrador" haciendo clic en su icono.Como alternativa, puede especificar un nombre de usuario diferente para las sesiones utilizando el parámetro – credential del comando.
Una vez que esta colección de comandos, podrá trabajar con ellos en la forma de 1: 1: PSSession escriba $ sesiones [0] conectarán a instancia de shell del primer equipo, por ejemplo.Pero la verdadera eficacia se ejecuta un comando todas ellas a la vez: Invoke-Command –scriptblock {ipconfig} –session 0 $ sesiones.Que ejecuta el comando Ipconfig en cada equipo al que ha conectado una sesión y devuelve los resultados a su equipo.Realmente se conectará a los equipos en paralelo, hasta 32 a la vez; puede cambiar ese acelerador de ejecución en paralelo mediante el parámetro –throttlelimit.
IT poner fuera de su opinión
Por supuesto, a veces se va activar desactivar los comandos que tardar en ejecutarse y es posible que no desee sentarse esperando a todo completar.En tales casos, ¿por qué no permiten el shell de seguir trabajando en segundo plano?Simplemente agregue el parámetro –AsJob a Invoke-Command y el shell creará un trabajo de fondo.
Recuerde que su copia del shell realmente no es mucho trabajo; se ejecutan los comandos que haya especificado en instancias remotas de Windows PowerShell.Sólo se esperando su shell para que todos ellos finalizar y recopilar los resultados envían.Esos resultados se almacenan como parte del trabajo.Ejecutar Get-trabajo para ver todos los trabajos actuales y su estado (si está aún ejecutando, por ejemplo).Utilice recepción trabajo para capturar los resultados out of un trabajo completado.Por lo tanto, todo este aspecto:
$sessions = New-PSSession –computerName (Get-Content c:\names.txt)
$job = Invoke-Command –scriptblock { your command(s) } –AsJob
Get-Job (to check the status)
$results = Receive-Job $job
Puede, a continuación, mostrar resultados de $, filtrarla, ordenarlo y así sucesivamente. Cada resultado tendrá información adjunta a ayudarle a ver qué equipo procede. Hablaré sobre trabajos de fondo (que incluso pueden tener otro subtrabajo que tiene que tratar con) en un próximo artículo.
Es la administración remota, escuela nuevo estilo
Olvidar la forma de escuela antiguo de administración "remota" que implica excursionismo al Centro de datos o con un escritorio remoto "trampa". Características de Windows PowerShell v2 interacción remota son una forma eficaz y sencilla para ejecutar comandos, los comandos, en equipos remotos. Aunque Mi enfoque personal en Administración de servidores, estas mismas técnicas son excelentes para tareas de administración de equipos de escritorio, así, que es un motivo por el Windows PowerShell v2 está preinstalada en Windows 7, así como Windows Server 2008 R2.
Don Jones es cofundador de Tecnología concentra, donde le blogs semanalmente sobre App-V de Windows PowerShell, SQL Server y otros temas. Póngase en contacto con él a través de su sitio Web.