Welcome to Delicate template
Header
Just another WordPress site
Header

Una vez establecido la URL de StoreFront, si no se establecio inicialmente con Https no es posible realizar la modificación desde la consola.

Para modificar-lo deberemos tirar de PowerShell.

Y como lo hacemos. Veamos-lo.

Requerimientos:

  • Correr PowerShell como Administrador y como Unrestricted

Se asume que el Administrador, ha creado un enlace HTTPS en IIS y que ha sido generado e instalado el correcto certificado para el Site.

1

Continua leyendo aquí

PowerShell Jobs – Basic

mayo 10th, 2013 | Posted by cristiansan in CLI | Microsoft | PowerShell - (0 Comments)

Los objetivos de automatizar procesos, son los de facilitar tus tareas cotidianas y repetitivas.  Podemos automatizar los procesos de forma que no sea necesario realizar las acciones de forma manual.

PowerShell por eso, tiene un inconveniente en este punto. Cuando se inicia una secuencia de comandos PowerShell, pueden necesitar de un tiempo determinado para su finalización, si además realizamos las tareas sobre maquinas remotas, como vimos en el anterior post “basics”, el tiempo puede aumentar. Su pompt de powerShell no estará disponible hasta la finalización de las mismas. Una forma de solucionar este problema es utilizar varios prompt PowerShell o lanzar los procesos en Background, como Job.

Los trabajos en PowerShell se ejecutan de forma asíncrona. Cabe tener en cuenta, que los resultados no son persistentes, con lo cual, si cerramos una sesión con un Job, los datos del mismo se perderán.

Podemos crear Jobs de dos formas:

Cmdlets Jobs

Cmdlets específicos para la generación de trabajos. Podemos ver un listado con el comando Get-Command .

Get-Command -Name *job* | Format-Wide -Column 3

Veamos como ejecutar un proceso Job con Cmdlets.

Start-Job –name PrimerJob –scriptblock {Get-Service WinRM}

Generamos un segundo Job

Start-Job –name SegundoJob –scriptblock {Get-Service WSService}

Para comprobar los Jobs y su estado, ejecutaremos

Get-job

1

Parametro -AsJob

Algunos cmdlets permiten el parámetro –asjob el cual nos permite ejecutar el mismo como trabajo. Veamos un ejemplo.

Invoke-command –computername vm1 –scriptblock {get-Service WinRm} -asJob

En este caso, es el propio sistema el que nombra el trabajo.

2

En este caso, la maquina VM1 no existe, con lo cual podemos ver el estado “Failed” en su ejecución.

Resultados

Como podemos ver en los dos primeros trabajos, disponemos en la columna HAsMoreData del valor TRUE. Esta columna indica si han sido devueltos resultados.

Este es el momento de poder ver el resultado de la operación. Para ello utilizaremos el comando “receive-Job”.

Receive-Job –name PrimerJob –keep

3

Aquí vemos la salida de Get-Service en la salida del primer Job.  El modificador –keep evita que los datos sean borrados y que podamos accedamos a ellos nuevamente posteriormente.  Recordad, que si cerramos el prompt, los datos se pierden.

Borrar Jobs

Para borrar un Job, basta con obtener el Job deseado con “Get-Job –id X” y redirigir el mismo hacia el cmdlet “Remove-Job”

-Computername

PowerShell permite la gestión de maquinas remotas mediante el uso del parámetro ­–Computername. Solo algunos comandos son capaces de trabajar con este parámetro. Podemos utilizar una el siguiente comando para obtener la lista de cmdlets capaces de trabajar con este paramétro.

Get-Help * -Parameter computername | Format-Wide -Column 2

Nota: Cmdlets PSSESION requieren de PowerShell v2

Recordard que el firewall debe estar configurado para aceptar las conexiones. Podemos habilitar el mismo para ello, ejecutando:

netsh firewall set service RemoteAdmin

netsh advfirewall set currentprofile settings remotemanagement enable

Ejemplo.

Local: Get-Service winRM

Remoto: Get-Service –name winRM –computername Win2008Lab

Para realizar la consulta sobre un grupo concreto de maquinas, podemos utilizar el siguiente código:

#$computers = Get-content c:\Path\file.txt

$computers = @(“VM1”, “VM2”, “VM3”);

Get-wmiObject –class win32_Service –Filter “name=’winrm’” –computername $computers

PSSesion

PowerShell puede utilizar el servicio WinRM para crear conexiones remotas (ver WS-management). Debemos tener en cuenta que para utilizar los cmdlets pssesion debemos…

  • WinRM debe estar instalado y corriendo en los servidores
  • PowerShell v2 debe estar instalado en los servidores
  • Debe ejecutar-se en cada máquina Enable-PSremoting, este configura WinRM el firewall y los elementos necesarios para el acceso remoto.

Para crear una conexión remota ejectuaremos:

$session = New-PSSession -ComputerName VM1, VM2

Podemos ver entornos las sesiones establecidas con “Get-PSsesion”

Una vez establecida la conexión, para ejecutar un comando de forma remota ejecutaremos:

Invoke-command –Session $session –ScriptBlock {get-service}

Si abrimos varias conexiones, cada conexión dispone de un ID, visible desde get-session. Para ejecutar un comando remoto sobre una conexión concreta…

Definimos el ID en una variable

$idS = Get-Pssesion –id 2

Ejecutamos el comando invoke-command utilizando $ids como argumento para el parámetro –session.

Para cortar/finalizar la conexión ejecutaremos:

Get-PSsesion | remove-PSSesion

Get-PSSesion –id 2 | remove-PSSesion

Realizar un reinicio programado en maquinas Microsoft no es un tarea difícil. Tampoco lo es realizar un reinicio de forma remota.

En el primer caso, bastaría, por ejemplo, en realizar un batch con las ordenes de shutdown e incluir-lo en las tareas programadas de todos los servidores. No es un problema con pocos servidores, pero puede resultar tedioso con entornos sumamente grandes.

El poder realizar un shutdown de las maquinas remotas, nos permitiría por ejemplo, realizar un único script de reinicio que llame al resto de maquinas para enviar las instrucciones definidas.

Para incluir el reinicio programado, bastará entonces con la creación de una única tarea programada en una única máquina que se encargará del reinicio de todas las maquinas remotas.

En caso de necesitar modificaciones o alterar las horas de reinicio, la modificación únicamente se realizará sobre la maquina que gestiona dicho script y no en todas las máquinas a reiniciar.

El primer ejemplo, realizar el reinicio de todas las maquinas que son almacenadas en el array “computer”.  En el segundo, podremos utilizar un reinicio de maquinas dada una lista de nombres en un fichero de texto.

Ejemplo 1.

$computers = @(“VM1” “VM2” “VM3”)

$csesion = New-PSSession –computername $computers

invoke-command –session $csesion –scriptblock {restart-computer -force}

NOTA1: Cabe recordar, que es necesario disponer del servicio de WS-management activo en los servidores remotos.

NOTA2: Para el uso de New-PSSession  se debe activar inicialmente el uso de sesiones remotas en los servidores remotos. Ello se establece con el comando enable-PSRemoting

 

 

 

Gpupdate masivo

marzo 22nd, 2013 | Posted by cristiansan in ActiveDirectory | CLI | Microsoft | PowerShell - (0 Comments)

Durante la integración y/o administración de una plataforma pueden aparecer necesidades constantes de actualizar GPOs en los servidores.

Modificar una GPO y realizar un gpupdate en los servidores no es una tarea complicada, pero cuando son unos cuantos los servidores a actualizar, puede ser un poco tedioso.

Las pruebas se realizarán sobre un servidor donde validaremos su correcto funcionamiento, pero confirmado el proceso, si queremos aplicar de forma inmediata estos cambios al resto de servidores, no nos quedará mas remedio que ir conectando uno por uno para forzar el update o esperar a que estas sean aplicadas de forma automática.

PowerShell permite a los administradores Windows automatizar tareas que solemos utilizar o que es necesario realizar de forma común o repetitiva.

Este pequeño script en PowerShell se encargará de actualizar mediante gpupdate una lista de servidores concreto. Para ello, nos son necesarias 3 cosas.

  1. Lista de servidores a actualizar
  2. Procedimiento para lanzar gpupdate de forma remota
  3. PShell Script que incluya el script

El primer punto se solventa con un fichero .txt en el cual incluimos el nombre de maquina (fqdn). Ejecutar el comando en mas o menos servidores, implica únicamente modificar el fichero con mas o menos servidores a actualizar.

Para el segundo punto, busque la solución mas rápida. Y esta vino de Sysinternals con “psexec.exe” el cual nos posibilita la ejecución de comandos de forma remota.

Por último, solo quedaba generar el script. Y este es sin duda el punto mas sencillo 😉 Ahí os dejo el código:

$ListComputers = gc .\Servers.list.txt

# Creamos variable $ListComputers con el contenido del fichero servers.list.txt

Foreach ($strComputer in $ListComputers)

# Por cada elemento, asignar valor a la variable $strComputer y realizar:

{.\psexec.exe \\$strComputer gpupdate.exe /target:computer /force}

#Ejecuta de forma remota mediate psexec.exe sobre la maquina $strComputer, un gputdate.exe y actualiza las GPOs de maquina.

Modificando el target por :user las gpo de usuario serán actualizadas, pero tened en cuenta que las directivas de usuario en algunos casos requieren de un logoff de usuario. Para forzar este logoff utilizaríamos el modificador /Logoff.

$ListComputers = gc .\Servers.list.txt

Foreach ($strComputer in $ListComputers)

{.\psexec.exe \\$strComputer gpupdate.exe /target:user /forcé /Logoff}

 Recursos:

Psexec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Gpupdate: http://technet.microsoft.com/en-us/library/cc739112%28v=ws.10%29.aspx

 

 

 

 

Para aquellos que me conocen, saben que mis inicios profesionales empezarón en los mundos de Unix. De aquellos amores quedan siempre profundas heridas, y aunque mi foco profesional actual se basa en entornos Citrix/Microsoft, hay amores que dejan huella :P.

Quizás de aquellos amores venga mi pasión por Xen, y en especial por XenServer. Para aquellos que no lo conocen, XenServer es el hypervisor proporcionado por Citrix basado en el proyecto XenSource.

De mis antiguos amores y de mis nuevos amores, surge la inquietud por PowerShell. PowerShell proporcionó a Windows aquello que los amantes de los sistemas Unix encontrábamos a faltar en los sistemas de Gates. Un entorno de comandos, potente, flexible que permita al administrador realizar cualquier tarea que podamos imaginar.

Hoy vamos a ver en este post, como usar PowerShell para hablar con XenServer.

Cmdlets a tutiplén

Los cmdlets vienen a ser los comandos disponibles en nuestro entorno de PowerShell. Windows provee multitud de ellos para la gestión de nuestro sistema, pero para poder utilizar Pshell sobre XenServer, deberemos en primer instancia instalar el conjunto de cmdlets creados para su integración con Xen. Para ello, bastará con conectar-nos con el Site de Citrix, y descargar el SDK de XenServer, el cual contiene cmdlets, recursos Python, recursos .Net, Java y librerías.

Una vez descargado e instalados los modulos de PowerShell, disponemos de todo en nuestra maquina para empezar a hablar con nuestro hypervisor Xen.

Ola q ase Xen?

Este manual no pretende ser un manual de PowerShell, existen muchos en la red y muy buenos. Si quereis aprender PowerShell este no es vuestro Post y os recomendamos un primer acercamiento al mismo antes de proceder.

El primer paso para hablar con Xen desde PowerShell, como habréis adivinado, va a ser la carga de los nuevos cmdlets reciente creados. Para ello realizaremos lo siguiente:

  • Abrimos Windows PowerShell
  • Ejecutamos: Add-PSSnapin Xen*

Con esto ejecutado, ya disponemos de los cmdlets de XenServer cargados. Veamos inicialmente los comandos disponibles desde PowerShell

  • Get-Command –Module Xen*

Existen una serie de comandos básicos para establecer la conexión. Una vez ejecutados y obtenida la conexión, nuestro limite es nuestra mente.

Para establecer la conexión con XenServer, ejecutaremos:

connect-Xenserver -Url http://XenServer_URL -UserName root –Password xxxx

Con ello procederemos a realizar la conexión con nuestro Host. Yo prefiero utilizar este modelo:

Get-Credential | connect-Xenserver -Url http://XenServer_URL

De este modo obtenemos un prompt de Windows para validación evitando escribir la contraseña en text plano desde la CLI.

Con ello, ya disponemos de una conexión abierta con Xen. Veamos algunas de las cosas que podemos hacer…

Listando maquinas en nuestro host

Get-XenServer:VM | select name_label

Parar y arrancar VMs desde la CLI:

Invoke-XenServer:VM.Start -VM «HOST-LS»
Invoke-XenServer:VM.CleanShutdown -VM  «HOST-LS»

Creemos una nueva tarjeta de red.

Create-XenServer:Network -NameLabel «CTXDOM_ITPROs Network»

Para eliminar-la podemos usar Destroy-XenServer:Network –Network “CTXDOM_ITPROs Network»

Para finalizar, el comando de desconexión 😛

Disconnect-XenServer

>> Disconnect-Post y hasta otra!

Recurso Adicional: http://community.citrix.com/display/xs/Citrix+XenServer+6.0+CmdLet+Poster