Extender el periodo de evaluación de Windows Server e Hyper-V Techinical Preview

Buenas

Si estas evaluando Windows server o Hyper-V Vnext, versión que actualmente se encuentra en Technical Preview te habrás dado cuenta que el periodo de evaluación de esta demo la cual fue liberada el octubre del 2014 finaliza mañana 15/04/2015

El mensaje que nos muestra en las máquinas de test que tenemos corriendo esta versión es el siguiente:

Teniendo en cuenta que Microsoft no tiene previsto liberar la próxima versión de la Technical Preview de Vnext hasta Mayo ha lanzado el siguiente parche el cual nos permitirá extender el periodo de evaluación de la Technical Preview que hemos venido usando hasta ahora.

http://www.microsoft.com/en-us/download/details.aspx?id=46447

Espero que os resulte de utilidad.

Un saludo

Microsoft anuncia Hyper-V Containers, Windoows Container y Nano Server

Buenas,
Ayer fue un día repleto de noticias para los amantes de la virtualización, especialmente para todos aquellos que seguimos bastante de cerca los Productos de Microsoft, puesto que ayer Microsoft anuncia de manera oficial que la próximo versión de su sistema operativo servidor incorpora Hyper-V Containers y Nano Server.

Aunque podéis encontrar en los anuncios oficiales en los siguientes links.

http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx

http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx

Me gustaría daros un par de pinceladas acerca de los beneficios que ofrecen estas funcionalidades:

Windows y Hyper-V Containers:

Es un nuevo concepto que está irrumpiendo con fuerza en el mundo de la virtualización especialmente tras el anuncio de partnership que Microsoft y Docker hicieron el paso octubre. Los Containers nos permiten definir una capa de aislamiento a nivel de aplicación y de los procesos dependientes de la misma evitando la necesidad de desplegar un sistema operativo guest por cada container. Como creo que generalmente una imagen suele ser más explicativa que 1000 palabras os dejo la siguiente:

Nano Server

Podemos definir Nano server como un nuevo modo de instalación de Windows server optimizado para correr aplicaciones cloud y containers. La idea principal detrás de nano server es la reducción de recursos necesarios para correr el mismo mientras se mejora la seguridad y la disponibilidad del mismo. Igualmente es importante mencionar que la gestión de este sistema operativo se realizará únicamente por wmi y power Shell y que por supuesto tendrá compatibilidad a nivel API con otras versiones de Windows server y con herramientas de desarrollo como visual studio.

Espero que os resulte de interés.

Seguiré profundizando sobre estas funcionalidades en próximos posts.

Un saludo

Netwrix Auditor – Inactive User Tracking

Buenas

Hoy me gustaría hablaros de la funcionalidad “Inactive user Tracking” incluida la Suite Netwrix Auditor, la cual como su propio nombre indica nos permite identificar los usuarios inactivo en nuestro directorio activo y tomar una serie de acciones tanto de reportes como correctivas que son totalmente personalizables en el asistente de configuración de esta funcionalidad.

Una vez comentada de manera teórica las funcionalidades que nos ofrece “Inactive user tracking” pasamos a ver de manera práctica como ponerlo en funcionamiento.

1- Accedemos a la consola y navegamos hasta nuestro dominio el cual encontramos en Managed Objects

2- Clickamos en Add/remove Systems

3- Seleccionamos inactive user tracking y pulsamos en next

4- Personalizamos el umbral en el que consideraremos un usuarios como inactivo así como la acciones y el ámbito en el que aplicara el mismo. En nuestro ejemplo de demo lo he configurado de la siguiente manera:

5- Finalizamos el asistente de configuración pulsando en Finish.

Esto es todo lo que necesitamos hacer para configurar inactive user tracking, como podéis observar el asitente de configuración es bastante sencillo y la acciones a realizar con los usuarios inactivos son bastante granulares.

Para recopilar información sobre nuestros usuarios inactivos podemos pulsar en run o bien esperar a que se ejecute la captura de datos de manera programada.

Por último para finalizar el post me gustaría enseñaros la información que nos llegara por mail a los administradores sobre los usuarios inactivos.

Espero que os resulte de utilidad

Un saludo

Crear un File Share en Azure y conectarse desde Local (2 de 2)

Buenas tardes

Primero que todo me gustaría recomendaros la lectura de la primera entrada de la serie la cual podéis encontrar aquí. En esta primera entrada explicaba como configurar el servicio de file share en Azure y como conectar una unidad de red al mismo desde una máquina virtual corriendo en Azure.

En esta segunda entrada de la serie me gustaría explicar como configurar una máquina virtual azure mediante webdav y usarla de pasarela para conectarnos al file share desde una máquina que se encuentra on-promises, para ello seguiremos los siguientes pasos:

1- Nos conectamos por rdp a nuestra máquina de Azure

2- Iniciamos el server manager e instalamos un IIS con los servicios de WebDav

3- Una vez instalado el role abimos el IIS Manager, seleccionamos el sitio web por defecto y hacemos doble clic sobre Web Dav Authorization rules

4- Seguidamente hacemos click en “enable web dav”

5- Creamos un usuario local con net user cuyo nombre de usuario será el nombre del almacenamiento de azure y la password será las clave de acceso al storage en azure

6- Retornamos al iis manager, seleccionamos el sitio por defecto y clickamos en basic settings. Seguidamente definiremos el path de acceso al file share que creamos en el post anterior y como credenciales de usuario las que hemos creado recientemente.

Estos serían todos los pasos que deberíamos realizar para configurar nuestra máquina de pasarela. Para conectar desde local simplemente debemos mapear una unidad de red a la dirección de la máquina virtual. Como credenciales usaremos los del usuario que hemos definido que son los mismos que los de la cuenta de almacenamiento, igualmente es importante recordar que debemos crear un endpoint a la máquina de pasarela por el 80 para poder alcanzarla por http.

Espero que os resulte de utilidad.

Un saludo

Crear un File Share en Azure y conectarse desde Local (1 de 2)

Buenas tardes

Con este post doy comienzo una serie de dos artículos en la que explicare como crear un file share en azure y posteriormente como conectarnos al mismo desde una máquina que tenemos on-promises usando una máquina virtual de azure como pasarela.

En esta primera entrada de la serie detallaré el procedimiento para crear el file share en azure y en la segunda explicare los pasos que debemos seguir para conectarnos al mismo desde local, el motivo por el cual usaré una máquina virtual en azure como pasarela es porque los file share de azure están pensados simplemente para ser compartidos entre máquinas virtuales que se encuentran en el mismo azure.

Antes de empezar con la parte técnica y el paso a paso de la configuración de la configuración del file share en azure, simplemente recordar que actualmente esta funcionalidad se encuentra aún en preview y para poder usarla debemos inscribirnos en el test de la misma desde el siguiente portal.

http://azure.microsoft.com/en-us/services/preview

Una vez nos hemos registrado para testear la funcionalidad debemos logarnos en el portal de azure y crear un storage. Adjunto dejo pantallazo.

Con el storage creado abriremos Azure Power Shell y ejecutamos los siguiente pasos.

1- Conectamos a nuestra subcripcion ejecutando el siguiente comando e introduciendo nuestras credenciales:
Add-AzureAccount

2- Cremos un contexto para la cuenta de almacenamiento ejecutando el siguiente comando
$FSContext=New-AzureStorageContext storage_name

3- Creamos un share partiendo del context ejecutando el siguiente comando.
$FS = New-AzureStorageShare sampleshare -Context $FSContext

4- Por ultimo crearemos un directorio en el share ejecutando el siguiente comando
New-AzureStorageDirectory -Share $FS -Path sharedir

Llegados a este punto simplemente nos conectaremos por rdp a la máquina de pasarela que usaremos en azure y probaremos que somos capaces de conectarnos al directorio compartido para ello:

1- Definimos unas credenciales persistentes de acceso al share en la máquina virtual de azure lo cual nos permitirá reconectarlos al recurso automáticamente cuando reiniciemos dicha máquina. Para ello ejecutaremos el siguiente comando en el power Shell de la máquina virtual de azure.
cmdkey /add:storagename.file.core.windows.net /user:storagename /pass:

2- Conectamos una unidad de red al share recientemente creado ejecutando el siguiente comando
net use z: \\storagename.file.core.windows.net\sharename

Espero que os resulte de utilidad, atendiendo a lo prometido en el próximo post verenmos configurar la máquina en azure como pasarela para conectarnos desde una máquina on-premises.

Un saludo

Sorteo licencia Netwrix Auditor for Windows Server

Buenas,

Escribo hoy este post tan cortito para informaros que la gente de Netwrix va a realizar un sorteto de una licencia de Netwrix Auditor for Windows Server con una validez de 2 años, la participación en el sorteo es totalmente gratuita por lo que me gustaría recomendaros que os inscribais en el mismo haciendo click en el siguiete Link.

Un saludo

Netwrix Password Expiration Alerting

Buenas

Hoy me gustaría hablaros sobre esta herramienta de Netwrix que nos permite controlar tanto a nivel usuario como a nivel administrador mediante alertas los cambios de password en Directorio Activo de los usuarios. Por supuesto, dicho herramienta contribuye de una manera muy notable en la reducción de llamadas al helpdesk por este motivo ya que notifica igualmente sobre la expiración de password a los usuarios que no logan habitualmente en el dominio como pueden ser usuarios de vpn o de portales web basados en autenticación de Windows (versiones a partir de la 2003).

El funcionamiento de la herramienta en si es bastante sencillo, la mima comprueba de manera periódica la expiración de password a nivel de dominio o unidad organizativa y envía un reporte via mail directamente al usuario cuya password caduca dentro de un umbral definido. La herramienta manda igualmente un reporte con los usuarios afectados por el cambio de password a los administradores.

Igualmente es importante mencionar que Netwrix ofrece esta solución tanto de manera gratuita como de manera comercial para los clientes de Netwrix Auditor que van a utilizar Netwrix Auditor for Active Directory. Podréis descargar la versión gratuita de la herramienta pasando por este link link.

Una vez hecha esta introducción un poco más teórica y con la plataforma de Netwrix Auditor 6.5 ya instalada en nuestro entorno siguiendo los pasos detallados en este post procederemos a configurar Password Expiration Alerting siguiendo los siguientes pasos.

1- Accedemos a la consola y navegamos hasta nuestro dominio el cual encontramos en Managed Objects

2- Clickamos en Add/remove Systems

3- Seleccionamos Password Expiration Alerting y pulsamos en Next

4- Definimos como queremos configurar las alertas de caducidad de password, en nuestro caso de la siguiente manera:

5- Por último hacemos clikc en Finish para terminar el asistente de configuración

6- Una vez añadido el managed objects seleccionamos password expiration alert y pulsamos run para ejecutar la tarea de captura de datos

Una vez ejecutada la captura de datos tan solo nos queda acceder a nuestro buzón de correo para ver las alertas generadas.

Este sería un ejemplo de mail enviado al usuario.

Y este sería un mail enviando al administador.

Espero que os resulte de utilidad y prometo seguir escribiendo más artículos técnico sobre las funcionalidades de la plataforma Netwrix Auditor.

Un saludo

Docker Containers – ¿Que son?, despliegue en local y Azure (3 de 3)

Buenas

Primero que todo me gustaría dejaros un enlace a los dos primeros artículos de la serie los cuales podéis encontrar en los siguientes enlaces.
Post 1 – Definición de containers y diferencias con las máquinas virtuales
Post 2 – Despliegue de una aplicacion dockerizada en local

En esta tercera entrada con la que concluimos esta serie de tres explicaremos como desplegar un Ubuntu en Azure el cual ya incorpora el engine de docker y como desplegar una aplicación dockerizada en el mismo. Para ello seguiremos los siguientes pasos.

1 – Nos logamos en el portal nuevo de azue accesible desde la url https://portal.azure.com

2- Pinchamos en new everything y tecleamos docker como criteria de búsqueda.

3- En nuestro caso crearemos un Ubuntu donde se desplegará el engine de docker, para ello seleccionamos este tipo de virtual machine y pulsamos en créate

4- Definimos los parámetros de nuestra máquina, como son el hostname, usuario, password y tipo de máquina virtual, datacenter de azure en el que alojaremos …. y pulsamos en create. La máquina se arrancará auntomaticamente tras sear creada

5- Abrimos putty y nos conectamos por ssh a la máquina que acabos de crear y nos logamos en la misma

6- Seguimos los pasos detallados en los puntos del 13 al 17 del segundo artículo de la serie el cual podéis encontrar en el siguiente link.

7- Tras ejecutar el comando detallado en el punto 17 tomaremos nota del puerto que usara la aplicación para definirlo como endpoint en nuestra vm de azure, como podéis ver en nuestro caso usa el puerto 49153

8- Creamos el endpoint en azure

9- Abrimos el navegador y probamos la aplicación.

Espero que os resulte de interes.

Un saludo.

Docker Containers – ¿Que son?, despliegue en local y Azure (2 de 3)

Buenas

Primero que todo animaros a leer el primer árticulo de la serie el cual podéis encontrar en el siguiente link. En este primer árticulo empecé la serie explicando de manera teorica que son los containers y su diferencia principal con las máquinas virtuales

Según lo prometido en esta segunda entrada de la serie veremos cómo desplegar una aplicación dockerizada en local usando boot2docker. Para ello seguiremos los siguientes pasos:

1- Descargamos la iso de boot2docker la cual podemos encontrar por ejemplo en el siguiente link

https://github.com/boot2docker/boot2docker/releases

2- Nos creamos una máquina virtual usando nuestro hypervisor favorito, la maquina virtual creada será muy básica en cuanto a hardware teniendo 1 vcp, 512 mb de ram y disco ide de 8 gb igualmente deberá tener dos adaptadores una configurada en bridge para que tenga salida a internet y otra para que sea accesible únicamente por el host. Esta máquina virtual la configuraremos también para que arranque desde el cd donde pincharemos la iso recién descargada y tras arrancar la máquina este será el resultado.

3- Ejecutamos el comando ifconfig el cual nos permitirá ver la configuración tcp/ip de nuestros adaptadores, como podéis ver en el pantallazo adjunto en nuestro caso el adaptador eth1 tiene la ip 192.168.1.19

4- Abrimos un cliente ssh como puede ser putty y conectamos usando este protocolo a nuestra ip. El usuario por defecto es docker y la password tcuser.

5- Una vez conectados por ssh el siguiente paso será configurar el almacenamiento de nuestra vm como persistente, para ello ejecutamos el siguiente comando
fdisk -l /dev/sd?

6- Seguidamente ejecutaremos el siguiente comando para particionar el disco
sudo fdisk /dev/sda

Una vez ejecutado el comando debemos responder a las preguntas con los parámetros que nos proporciona el asistente de creación de particiones, en el pantallazo superior podéis ver la opciones que yo he escogido

7- Tras crear la partición el siguiente paso será formatear la misma ejecutando el siguiente comando:
sudo mkfs.ext4 -L boot2docker-data /dev/sda1

8- El commando ejecutado en el punto 7 nos permitirá tener el disco que usaremos para almacenar las aplicaciones dockerizadas listo, el siguiente paso será reiniciar la máquina virtual y volver a conectarnos por ssh para tener la opción montar el disco

9- Una vez reiniciada la máquina el siguiente paso será montar el disco ejecutando el siguiente comando.
mount | grep sda

10- Llegados a este punto ya tendremos nuestra vm lista para desplegar aplicaciones dockerizadas, para poder asegurarnos que realmente es así ejecutaremos el siguiente comando.
docker version

Con nuestra máquina virtual totalmente preparada para correr aplicaciones dockerizadas ahora procederemos a descargar una aplicación de ejemplo la cual desplegaremos en nuestra máquina virtual siguiendo los siguientes pasos:

11- Descargamos el paquete de aplicación de ejmeplo en formato zip desde la siguiente página
https://github.com/tutumcloud/docker-hello-world

12- Descomprimimos el contenido del zip

13- Seguidamente debemos copiar los archivos descargados en la máquina virtual. Esta opción se puede realizar de diferentes maneras pero para mi las mas cómoda es usar filezilla para crear una conexión ssh de transferencia de ficheros, la cual nos permitirá copiar los archivos a la máquina virtual.

14- Posteriormente navegamos en nuestra sesión ssh al directorio donde hemos copiado la aplicación y ejecutamos el siguiente comando para crear la imagen de aplicación dockerizada:
docker build -t tutum/hello-world .

15- Una vez desplegada la imagen ejecutaremos el siguiente commando para hacer un push de la misma en el registro.
sudo docker push tutum/hello-world

16- Llegados a este punto debemos ejecutar la aplicación con el siguiente comando
sudo docker run -d -p 80 tutum/hello-world

17- La ejecución del comando anterior nos mostrará un container ID el cual referenciaremos en el siguiente comando para asignarle un puerto externo
sudo docker port container_id 80

18- Ya tenemos todos listo. Como podemos observar en el pantallazo anterior nuestra aplicación está corriendo por el puerto 49153. Para testear que la misma funciona correctamente abriremos una navegador y nos conectaremos por http a la ip de la máquina virtual y puerto indicado.

Todos estos serían los pasos necesarios para desplegar una aplicación dockerizada en local usando boot2docker, en el siguiente post de la serie veremos como desplegarla en azure.

Espero que os resulte de interés

Un saludo

Docker Containers – ¿Que son?, despliegue en local y Azure (1 de 3)

Buenas,

Tras la reciente anuncio de partnership que Microsoft Corp y Docker Inc hicieron el paso 15 de octubre de 2014 el termino containers irrumpiendo con fuerza tanto en el mundo itpro como en el de desarrollo.

En este primer artículo de la serie que hoy comienzo me gustaría explicar ¿Qué son los costainers? y en que se diferencian de las máquinas virtuales. En el segundo artículo de la serie explicaremos como desplegar localmente una aplicación web basada en containers usando boot2docker y terminaremos la serie explicando como desplegar esta misma aplicación en Azure.

Una vez hecha esta pequeña introducción sobre el contenido que cubriremos en la serie pasaremos a explicar que es Docker.

Docker nace como una plataforma abierta basada en Linux y que está especialmente pensada para ejecutar aplicaciones distribuidas. La plataforma docker está formada por un engine, un runtime, un herramienta de packaging, un hub y un cloud service que nos permite compartir aplicaciones y automatizar workflows. Entre las principales virtudes de la plataforma cabe destacar las siguientes:

– Las aplicaciones dockerizadas se crean con una capa de abstracción que aísla totalmente la capa de aplicación y sus dependencias del sistemas operativo en el que se ejecuta lo que nos permite crear entornos standard de desarrollo, calidad y producción sin demasiados esfuerzos

– Las aplicaciones dockerizadas están basadas en un engine standard dándonos total flexibilidad a la hora de elegir donde correr nuestras aplicaciones ya sea en on-promise o en cualquier nube pública.

– La infraestructura que soporta las aplicaciones basadas en docker es fácilmente escalable dependiendo de la demanda.

– Las aplicaciones basadas en docker se pueden desarrollar usando cualquier lenguaje de desarrollo y son totalmente portables.

– Docker ofrece un hub con más 13.000 aplicaciones que puede ser un punto de partida perfecto para los profesionales que empiezan a tomar contacto con esta tecnología

Referente a las diferencias principales entre máquinas virtuales y containers basados en docker creo que queda bastante bien explicada en la siguiente imagen.

Como se puede observar las aplicaciones basadas en docker comparten únicamente el engine y cada aplicación y sus dependencias corre en procesos aislados y hace uso de recursos dedicados aunque comparten el kernel del host con otros containers.

Espero que os resulte de utilidad, en el siguiente post veremos como usar boot2docker y desplegaremos una aplicación dockerizada en local.

Un saludo.