Liberado Update Rollup 1 para Exchange Server 2010 SP3

Ayer teníamos una revisión de nuestro entorno de correo, lo que Microsoft define como Exchange Risk Assessment Program (ExRAP), y me pregunta  el Ingeniero, ¿Qué versión teneis de Exchange?, le respondo, 2010 con SP3. Y, me dice, pues ayer salió el Update Rollup 1!!! … y me vuelvo a quedar con cara de #%#@&$

ex2010sp3ur10001

El UP1 corrige los siguientes errores detectados ya sea por los propios técnicos de Microsoft como reportados por clientes:

ex2010sp3ur10004

Os dejo toda la información que he podido recabar en los siguientes links:

Por cierto, hay que tener en cuenta esta peculiaridad a la hora de instalarlo sobre Exchange 2010 que funcionen sobre Windows Server 2012 con versión DBCS, o sea, Double-Byte Character Set o caracteres extendidos :

ex2010sp3ur10003

Buen fin de semana.

Hyper-V Performance – Parte I – Consumo de CPU.

Aprovechando que hace poco estube en un Workshop en Microsoft sobre el rendimiento de nuestros servidores con el rol de Hyper-V, adelanto esta serie de Posts sobre “cómo medir dicho rendimiento así cómo detectar posibles cuellos de botella en nuestro entorno de virtualización”.

Para empezar, me gustaría recordar este Post sobre “10 errores típicos en una revisión de salud de un entorno de Virtualización“, que considero indispensable releer cada vez que me meto en un proyecto de virtualización, independientemente del tipo de Hypervisor que se vaya a utilizar.

 

0001

i) Host Processor.- Normalmente en cualquier servidor, si queremos verificar el consumo de nuestro procesador lo que haremos será cargar los siguientes contadores de rendimiento:

 

  • \Processor(*)\% Processor Time
  • Task Manager (ver imagen =>)
  • \System\Processor Queue Lenght

 

Pues en nuestro caso, para saber qué consumo tiene la partición padre, que no hay que olvidar que es una máquina virtual (VM) en si misma, ya sea Hyper-V Server 2012 o Windows Server 2012 con el rol de Hyper-V, serán los mismos.

 

Veamos en que rangos de consumo de tiempo de procesador nos movemos:

0003

En el caso de que hayamos visto o intuyamos que pueda haber un problema de rendimiento en la CPU, o sea, nos hayemos en la zona de Caution o Critical, utilizaremos el contador de la Longitud de la cola del procesador, como referente inicial disponemos de la siguiente horquilla de valores que nos puede ayudar:

0002

Siempre hay que tener en cuenta que si ocurre en un momento puntual, no pasa nada. Otra cosa es que estos valores se alcancen durante un tiempo continuado. En cuanto a la horquilla de valores, éstos son orientativos, hay que saber extrapolarlos a las situaciones reales, a la carga del servidor, a los roles que tengamos instalados en el mismo, etc., no cogerlos como una regla de tres o lo que dice el KB de Microsoft va a Misa.

 

ii) Logical processor.- Para medir el total del consumo de procesador por parte del Host y todas las VM, utilizaremos los siguientes contadores de rendimiento:

  • \Hyper-v Hypervisor Logical Processor(*)\% Total Runtime
  • \Hyper-v Hypervisor Logical Processor(*)\Context Switches /Sec

% Total Runtime, con su consiguiente horquilla de valores indicativos (si os fijais son los mismos que en el punto anterior):

0003

Para el caso de los Content Switches, ocurren cuando el kernel cambia el procesador asignado de un subproceso a otro, verificaremos cuántos se producen por procesador y por segundo, con la consiguiente horquilla de valores indicativos:

0004

Cuando detectamos que estamos en zona Critical, suele venir motivado por:

  • Adaptadores del tipo Legacy Network.
  • Mal diseño de aplicaciones.
  • Drivers mal instalados.

 

ii)  Virtual processor.- Determinar el consumo de procesador de cada VM:

  • \Hyper-v Hypervisor Virtual Processor(*)\% Guest Runtime

Con la misma o muy parecida horquilla de valores indicativos que en el punto anterior:

0005

Como consejo final, si detectamos que \Hyper-V Hypervisor Virtual Processor (_Total)\% Total Run Time (Virtual Procesor Total Run Time – VPTR) está muy alto y \Hyper-V Hypervisor Logical Processor (_Total)\% Total Run Time (Logical Procesor Total Run Time – LPTR) es bajo, consideremos en asignar procesadores adicionales a esa VM.

El próximo día la memoria RAM.

Cluster Hyper-V – Configuración del tipo de Quorum.

Ya estamos terminando de configurar nuestro Failover Cluster para Hyper-V. Hoy nos toca la configuración del tipo de Quorum. Este punto sería uno de los primeros a tratar pero por diversos motivos, hoy es un buen dia para hablar de él.

Al generar el Failover cluster nodo a nodo, inicialmente se genera una configuración de disco Quorum: Node Majority o mayoría de nodos, automáticamente, ya que sólo tenemos un único nodo. Una vez añadimos un segundo nodo a nuestro Cluster, nos surge el dilema de dónde poner un tercer nodo o, mejor dicho, dónde poner un tercer voto a nuestro Cluster, ¿en una carpeta compartida?, ¿en un disco?

Accedemos a la configuración del cluster Quorum desde la consola:

Quorum00001

Nos lanza un asistente de configuración que nos da tres distintas posiblidades iniciales:

Quorum00003opcion1

  1. Típica (recomendada).
  2. Agregar o cambiar el testigo del quorum
  3. Configuración Avanzada.

Si seleccionamos la opción 1, nos hace la siguiente recomendación:

Quorum00004opcion1

Pero hoy tenemos un mal dia y no hacemos caso a nadie, así que probamos con la última opción, la 3, Configuración Avanzada, y continuamos con el asistente, nos pide qué nodos vamos a asignar y cuales no, si es que hay alguno:

Quorum00006opcion3_2_bis

Llegamos al seiguiente paso, donde vamos a configurar el tipo de testigo, apareciendo,  nuevamente,  tres opciones:

  1. Configuración de un disco como testigo (recomendada).
  2. Configuración de un directorio compartido como testigo.
  3. No configurar un testigo.

Quorum00008opcion3

En nuestro caso, añadiremos un disco FC de Quorum de 512 MB formateado en NTFS o ReFS al Cluster para que haga de testigo. No hace falta asignarle una unidad de red:

Quorum00009opcion3opcion3

Nos informan de la configuración seleccionada:

Quorum00010opcion3opcion3

Y nos muestra una ventana final del tipo sumario, con nuestro consiguiente reporte en formato html:

Quorum00011opcion3

Y final. Desde la consola de nuestro Failover Cluster queda de la siguiente manera:

Quorum00012opcion3

La situación final de nuestros discos será la siguiente:

Quorum00013

Nos vemos.

Migrar una Máquina Virtual desde Virtual PC a Hyper-V v3.

Esta situación nos puede aparecer, por ejemplo, a la hora de migrar máquinas virtuales (VM) desde un Windows 7 a un Windows 8, o sea, desde un Virtual PC a Hyper-V, versión 3, ambas son plataformas de virtualización.

Lo primero procederemos a desinstalar las Virtual Machine Additions, o sea, a deshacernos de los últimos resquicios de Virtual PC, desde agregar o quitar programas (fijaos que el sistema operativo que tengo virtualizado en un Wndows XP SP3):

WindowsXPSP3enW800001

Una vez reiniciada la VM, nos aparecerá el siguiente mensaje:

WindowsXPSP3enW800002

Despues de este primer reinicio, procedmos a la instalación de los Componentes de Ingregración de Hyper-V. Empezando por actualizar la capa ce abstracción de hardware (HAL), obligatoriamente, y, nuevamente, una vez reiniciada la VM, empezará a detectar nuevos dispositivos:

WindowsXPSP3enW800003

Nos vuelve a pedir que reiniciemos la VM para actualizar cambios:

WindowsXPSP3enW800004

Retoma la instalación de los servicios de integración, ahora con nuevos controladores de Windows:

WindowsXPSP3enW800005

Y, posteriormente, con la instalación de componentes de invitado:

WindowsXPSP3enW800006

Para, terminar, detectando nuevos dispositivos:

WindowsXPSP3enW800007

Una vez finalizado este proceso, procedemos a reiniciar, nuevamente, la VM

WindowsXPSP3enW800008

Ahora tenemos nuestro XP SP3 sobre nuestro Hyper-V versión 3 (Windows 8), pero ahhhh, nos faltan parches. Nos vemos, ya no reinicio mas la VM.

WindowsXPSP3enW800009

Cluster Hyper-V – Configuración del Almacenamiento.

Continuamos con la configuración de nuestro Failover Cluster para Hyper-V. Hoy configuración del Almacenamiento.

Una vez asignados los discos por parte del grupo que gestiona el almacenamiento, que en pequeñas empresas seremos nosotros mismos y en empresas grandes existirá un departamento solo para las cabinas de discos, lo visualizaremos la consola de gestión de discos de cualquiera de los nodos del Cluster.

Como podemos ver, son dos discos de 500 Gb de una cabina HITACHI, y se ven perfectamente en el gestor de discos del Server Manager de cada uno de los dos nodos del Failover Cluster, asi que los añadimos al Cluster:

FailOverCluster000006

Los ponemos On line y los formateamos convenientemente:

FailOverCluster000007

Posteriormente, desde la consola de Failover Cluster procederemos a añadirlos a nuestro Failover Cluster:

FailOverCluster000007b

El siguiente paso será añadir dichos discos en formato Cluster Shared Volumes (CSV), formato especial de disco de Microsoft para Hyper-V exclusivamente:

FailOverCluster000009

Apareciéndonos el cambio de asignación de discos:

FailOverCluster000008

Asimismo, podemos apreciar la creación de este tipo de discos CSV en nuestra unidad C:

FailOverCluster000010

Pues ya tenemos nuestro almacenamiento compartido en formato CSV. Ya nos queda muy poquito.

Ghost In The Shell: Arise border 1: Ghost Pain.

No se si lo sabreis pero me encanta la animación en general aunque siento especial predilección por el Anime.

Ayer me enteré que una de las películas/series que mas me han impresionado y gustado, Ghost in The Shell, estrenará en los cines una nueva película muy pronto, el 22 de junio.

Personajes tan carismático como la Teniente Kusanagi, Batou, el jefe de la sección Daisuke Aramaki, ya están en acción de nuevo. Os dejo el Trailer que he podido ver:

 

Espero que os guste y que salga la emitan pronto por estos lares.

Instalación de WebMatrix 3.

Ya vimos en el post “Actualización a WebMatrix 3” de principios de mes, que había salido una actualización de este producto. Hoy vamos a proceder a instalarlo.

Para empezar, para los que no lo sepais ¿Qué es Webmatrix? Es una herramienta de desarrollo web creado por Microsoft, especialmente dirigido al Cloud Computing.

webmatrix3_00008

Una vez descargado el software, lanzamos su instalación:

webmatrix3_00001

Nos encontraremos con el asistente de rigor que se descargará lo necesario y nos irá informando, paso a paso, de lo que está instalando:

webmatrix3_00002

Cuando termina el proceso de instalación, nos aparecerá el siguiente mensaje:

webmatrix3_00003

Posteriormente, podemos proceder a instalar todos aquellos productos que podemos gestionar desde este entorno de desarrollo web, en nuestro caso vamos a instalar Windows Azure SDK para PHP:

webmatrix3_00004

Añadirmos el componente:

webmatrix3_00005

Nos pedirá una serie de requisitos o paquetes adicionales a instalar (dependencias), en este caso .Net Framework 3.5 SP1, etc.:

webmatrix3_00006

Nuevamente volvemos a ver a nustro amigo el asistente:

webmatrix3_00007

Finalizando con éxito. Ahora probamos a conectarnos:

webmatrix3_00009

Una vez introducidas nuestras credenciales, ya vemos nuestro Site de CiudadanoCero en PHP:

webmatrix3_00010

Besos y abrazos, hoy solo es martes.

Cluster Hyper-V – Configuración proceso Live Migration.

En este caso, la configuración es muy sencilla. Sólo tenemos que configurar qué redes van a ser utilizadas para la migración de Máquinas Virtuales (VM) entre los diferentes nodos del Cluster. Posteriormente si tendremos que configurar qué VM podrán realizarlo pero hoy toca solo configuración del Cluster Failover.

Vamos pues a configurarlo. Desde nuestra consola, dentro de las redes definidas en el post anterior (ver aqui):

FailOverCluster000003

Seleccionaremos configurar “Live Migration” y definiremos las redes que este proceso va a utilizar:

FailOverCluster000004

En nuestro caso tenemos tres redes. Utilizaremos como red primaria la definida para el HeartBeat y el proceso de Live Migration, y como red secundaria la propia red de producción y acceso a las VM (esto es menos recomendable y no entraría en unas Buenas Prácticas).

Hasta el próximo Post.

Cluster Hyper-V – Configuración de redes.

Seguimos con la configuración de nuestro Failover Cluster de Hyper-V. Hoy la configuración de nuestras redes.

 

Tenemos que definir las siguientes redes virtuales entre todas las redes físicas que tengamos en nuestro Failover Cluster:

  • Red de acceso de los Clientes a las Máquinas Virtuales (VM) del Failover Cluster.
  • Red para Live Migratión o migración de VM en vivo.
  • Red para el Heartbeat del Failover Cluster.
  • Red para el Almacenamiento.- En el caso de utilizar iSCSI.

 

En nuestro caso, el resultado final es el siguiente:

  • Red de acceso de los Clientes a las Máquinas Virtuales (VM) del Failover Cluster. Esta red la hemos denominado VM:

FailOverCluster000001

  • Red para Live Migratión o migración de VM en vivo y Red para el Heartbeat del Failover Cluster.- Por falta de medios y, sobre todo, de tarjetas de red las hemos unificado.

FailOverCluster000002

Este dibujo cambiará cuando tengamos mas tarjetas de red disponibles.

FailOverCluster000003

Hasta la próxima.

Rotura de claves WPA en Router de Telefonica y Jazztel.

En un Post de hace unos meses, os comenté uno de los últimos libros que me había leido “Hacker Epico“. En uno de los capítulos hablan de lo fácil (para un hacker) que es crackear una Wi-Fi securizada con WPA, en concreto en determinados Routers Wi-Fi de Telefónica y Jazztel, los que tienen una denominación del tipo: WLAN_XXXX, o sea, el mio.

liberadaWifi0002

Concretamente lo que se había descubierto era que el mecanismo de generación de claves, dicho algoritmo estaba basado en el BSSID (la dirección MAC del router WiFi), y el ESSID ( lo que se conoce como el nombre de la red WiFi, en nuestro caso WLAN_XXXX) del router. Estos datos son públicos en conexiones a redes WiFi.

Ya sabeis el dicho, “en casa del herrero, …..”. Me puse manos a la obra con mi Router de Telefónica recien instalado para ver si era cierto …… mediante herramientas de Snifer conseguí la dirección MAC de mi Router ….

img-000007Vaya, el ESSID de mi Router termina en 2E4C y la MAC del mismo router, o sea, el BSSID, ….. también!!!! Sospechoso.

Pues nada, me descargué de Google Play el siguiente programa “Liberad a Wifi Revolution”:

liberadaWifi0001

el cuál, hace todo el trabajo por mi, jejeje

Lanzamos el aplicativo:  SC20130513-225903

Nos detecta todas las redes Wi-Fi a nuestro alrededor, y, en concreto, la que nos interesa:

liberadaWifi00001

Y, para finalizar, nos hace el cálculo a través del citado algoritmo, de nuestra clave WPA:

liberadaWifi00002

Os confirmo que no es la que tengo asignada. Uf!! primera prueba superada.

Si quieres hacerlo a través de una web (aqui), lo ejecutamos en nuestro navegador y nos aparece la siguiente pantalla:

Una vez introducidos los datos que hemos obtenido y pulsando a “Calcular key”, nos aparece la siguiente clave:

WPAWIFI0001Que, nuevamente, no corresponde con la nuestra. Uf! menos mal, de momento, hemos pasado el primer filtro.

Bibliografia: Creo que de estos temas hay mucha, pero que mucha bibliografía, y muy buena, en este caso, producto ibérico, de pata negra: