Abro este apartado para ir comentando en él las cuestiones que se van planteando sobre este tema durante la Gira TechNet y que no podemos responder en el momento, o las preguntas que nos vayáis haciendo llegar y que complementan las FAQ publicadas en la Web del producto:

Esto es lo que teníamos apuntado hasta el momento:

1.- Reporte unificado del estado de equipos y parches en un escenario con jerarquía, ya sea padre/hijo o con servidores de réplica.

Hoy por hoy, cada servidor de WSUS mantiene su propia base de datos SQL en el que almacena los informes. Por tanto, cada una de ellas ofrece una vista exclusiva de los clientes registrados contra ese servidor.

Existe un ejemplo de una herramienta desarrollada sobre las API de WSUS que recolecta la información de reporting todos los servidores y la consolida. Está también el código fuente por lo que puede ser fácilmente modificada a voluntad. Aquí tenéis los enlaces:

Readme: http://download.microsoft.com/download/8/1/a/81a41962-cff5-4396-a567-0d2f87d8f67a/Readme.htm

WSUSRollupSample: http://download.microsoft.com/download/e/a/c/eac857ba-3051-472b-a8a3-0b4179660dd8/WSUSRollupSample.EXE

2.- ¿Que sucede si elimino un producto, una categoría o un idioma en las opciones de sincronización?. ¿Se elimina el contenido correspondiente del repositorio de ficheros del disco duro del servidor WSUS?

Elegir no sincronizar determinados idiomas, productos o categorías no supone el borrado del contenido del disco ni eliminar la información que hay contenida al respecto en base de datos.

Si teneis cualquier duda o comentario (o solución) sobre Windows Server Update Services, no dudeis en agregar un comentario a este post.

Hola

Hoy contestamos dos preguntas que han salido de forma recurrente durante los eventos en los que hemos estado hablando de Windows Server Update Services (WSUS).

1.- La primera es cómo se puede eliminar el contenido correspondiente a idiomas o productos de los que se haya decidido no continuar sincronizando, o el correspondiente a actualizaciones reemplazadas o que por alguna razón no vayan a ser necesarias (es decir, las que marquemos como "No Aceptada", o "Declined" en inglés, en su estado de aprobación). Para ello usaremos la herramienta WSUSUtil.exe (incluida en la carpeta "Archivos de Programa\Update Services\Tools") y la Server Diagnostic Tool, cuya descripción y sintaxis podéis consultar aqui.

NOTA: Antes de jugar con estas opciones en un servidor en producción, por favor, haced un backup completo del estado del servidor

a) Para eliminar las actualizaciones que no sean necesarias, bien por que hayan sido reemplazadas y estén aprobadas las actualizaciones que las reemplazan, bien porque sean para un producto que ya no utilizamos, bien porque por alguna razón ya no las necesitemos:

   - Las buscamos usando la consola, las seleccionamos y cambiamos su estado de aprobación a "No Aceptada".

   - Eliminamos los archivos correspondientes usando la Server Diagnostic Tool: WsusDebugTool.exe /Tool:PurgeUnnneededFiles

b) Para eliminar las aprobaciones en idiomas que ya no están seleccionados en las opciones de sincronización del servidor

   - Listamos las aprobaciones que tenemos en estado inactivo: WSUSUtil.exe listinactiveapprovals

   - Una vez revisado si el resultado del comando anterior es coherente con lo que nos proponemos hacer, eliminamos las aprobaciones inactivas. Antes de ejecutar este comando, es necesario parar el sitio de Admimistración de WSUS en la consola de IIS: WSUSUtil.exe deleteinactiveapprovals

   - Por último, eliminamos los archivos correspondientes usando la Server Diagnostic Tool: WsusDebugTool.exe /Tool:PurgeUnnneededFiles

2.- ¿Se puede instalar WSUS en un controlador de Dominio?. Por poderse, se puede. No hay nada en la instalación del producto que lo impida, pero no esta recomendado por razones de rendimiento y seguridad. Por ejemplo, para administrar un servidor WSUS basta con agregar al usuario elegido al grupo local "Administradores de WSUS". Es muy posible que no queramos que ese usuario pertenezca a uno de los grupos del dominio que tienen permisos de inicio de sesión local en el servidor.

David Cervigón

Hace tiempo escribí acerca de un problema de Windows Vista a la hora de detectar dispositivos de almacenamiento masivo.

Empezaron a aparecer comentarios de gente que tenía el mismo problema, pero con otros tipos de dispositivos que no tenían nada que ver con los anteriores. No podía ser el mismo problema, pero no por ello dejaba de haberlo, por lo que decidi seguir la sugerencia de alguno de los comentarios y llamar directamente a Bill a ver qué es lo que está pasando.

Parece que el problema sucede al borrarse o corromperse el fichero %WINDIR%\inf\INFCACHE.1, precisamente durante la instalación de algún dispositivo no incluido en el producto. He leido por algún foro que se recomienda borrar este fichero en caso de problemas con la instalacion de dispositivos (ha sido un viejo truco desde los tiempos de Windows 95), pero definitivamente no es una buena idea en Windows Vista. Y no lo es porque Vista tiene un bug por el cual ese fichero no se regenera automáticamente como debería. Esto esta reportado en este artículo:

http://support.microsoft.com/kb/937187

Como se puede leer en el artículo, existe un parche que hay que solicitar a nuestros Servicios de Soporte (si alguien se anima a hacerlo, que pida mejor el del KB 940199, que reemplaza al anterior), y que será incluido en el Service Pack 1. Pero antes, puede probarse una solución sencilla, que consiste en renombrar este fichero y sustituirlo por el de un equipo semejante que funcione correctamente.

Si alguien se ve muy muy agobiado, le puedo facilitar el parche por correo, pero ya advierto que estando de Gira no va a poder ser de hoy para mañana.

Saludos.

David Cervigón

Están las versiones x64 Standard, Enterprise y Datacenter, el Windows Automated Installation Kit 1.1 (WAIK) (x86, x64, ia64) y el Windows Server 2008 Multilingual User Interface Language Pack (x64)

En el próximo par de semanas irán apareciendo las demás ediciones, a saber:

• Windows Server 2008 Datacenter, Enterprise and Standard (x86)
• Windows Web Server 2008 (x86, x64)
• Windows Server 2008 for Itanium-based Systems
• Windows Server 2008 Datacenter, Enterprise and Standard without Hyper-V (x86, x64)
• Windows Server 2008 Multilingual User Interface Language Pack (x86, ia64)

Por cierto, hoy hemos visto y enseñado nuestro primer Hyper-V Server en una sesión en la oficina. Ya hablaremos de ello más adelante.

¿Se entiende ahora lo del avión? ¡Tenemos los binarios finales! ;-)

Saludos

David Cervigón

Hola

Escribo esto porque cada vez es más frecuente recibir a través de este blog todo tipo de solicitudes de ayuda para recuperar la información de buzones de Hotmail correspondientes a cuentas presuntamente perdidas debido a contraseñas y preguntas clave "olvidadas". Y digo presuntamente y "olvidadas" porque justo esto es lo que intentaría hacer cualquier persona que quisiera acceder a la identidad de otra. Crearse una cuenta similar y solicitar amablemente, y por todos los dioses, que le ayudaran a "recuperar" la información ajena.

Por esa razón ningún empleado de Microsoft salvo los del equipo de soporte de Windows Live puede hacer nada por ayudarte. Así es que, por favor, no dejes comentarios aquí ni me envíes un correo solicitándome ayuda para recuperar tu contraseña de Hotmail, porque no puedo hacer nada más que intentar explicar cómo se debe acceder a dicho grupo. Ellos son los únicos que tienen potestad para prestar la ayuda correspondiente, y tomar las decisiones pertinentes tras estudiar el caso.

Este es el proceso que debes seguir si te encuentras en esta situación:

1. Sabiendo tu identidad (que menos), para recuperar la contraseña debería de bastar con:
• En el sitio Web de Windows Live Hotmail, haz clic en ¿Olvidaste la contraseña?.
• Escribe tu dirección de correo electrónico, los caracteres que aparecen en la imagen y, a continuación, haz clic en Continuar.
• Selecciona uno de los siguientes métodos:
• Solicitar que las instrucciones de restablecimiento de la contraseña se te envíen a tu dirección de correo electrónico alternativa
• Contestar la pregunta para comprobar la identidad
2. Si has resultado ser una persona especialmente olvidadiza, debes contactar con el grupo de soporte de Windows Live. No existe otra manera.
1. Accede a http://support.live.com
2. Asegurate de que la configuración de la pagina corresponde a tu país y haz clic en Windows Live Hotmail (Fig. 1)
3. Te saldrá un sistema de ayuda. Haz clic en cualquier tema
4. En la esquina inferior derecha aparecerá la opción "Obtener más ayuda". Haz clic en ese enlace (Fig. 2)
5. En la página resultante haz clic en "Obtener Soporte" (Fig. 3)
6. Saldrá un formulario, que hay que rellenar y enviar, seleccionando el Tipo de Problema correspondiente (Fig.4)

Fig. 1	Fig. 2	Fig. 3	Fig. 4

Yo poco más puedo hacer. Suerte en el proceso

Saludos

David Cervigón

Tino me refiere a un problema existente a la hora de pinchar ciertos dispositivos USB en Windows Vista. El sistema los reconoce como un "USB MASS STORAGE", pero dice no disponer de los drivers para el mismo. La solución que el ha encontrado consiste en forzar que los divers se busquen en la carpeta %systemroot%\system32\driverstore, con lo que la instalación del dispositivo termina correctamente.

Pues bien, buscando buscando resulta que es un problema reportado, que afecta a los dispositivos que requieren del driver Mf.sys (Multifuction Enumerator) para funcionar, ya que este no se extrae por defecto durante la instalación. Este fichero se encuentra en una carpeta que empieza por mf.inf_ y que se cuelga de %systemroot%\system32\driverstore\FileRepository, razón por lo que la solución mencionada funciona estupendamente.

Basta con copiarlo a la carpeta %systemroot%\system32\drivers para que el problema desaparezca. Todo esto esta en su correspondiente KB aqui.

Gracias Tino

Hola

Como veis, he movido el Post original a una nueva categoría para que sea más sencilla de manejar. Veamos las respuestas a vuestras preguntas:

1.- "Compruebe la configuración de su servidor. No se puede establecer contacto con al menos un componente de Update Services. Compruebe el estado del servidor y asegúrese de que Windows Server Update Services se esté ejecutando. Servicios que no están en ejecución: SelfUpdate"

Seguramente esto venga acompañado de un Evento 506 en el Visor de Sucesos, y de una entrada similar a esta en el log de IIS:

W3svc log errors: 2005-08-09 20:25:56 128.231.210.123 GET /selfupdate/iuident.cab - 80 - 128.231.210.123 - 403 6 0

El problema radicará seguramente en la configuración del directorio virtual correspondiente en IIS. Habría que comprobar las restricciones de IP y los permisos de ese directorio virtual (IUSR_MACHINENAME deberá poder acceder y tener derechos de inicio de sesión local). Resumiendo, el problema es de la configuración de IIS en lo tocante a los directorios virtuales que monta WSUS

2.- No se detectan las actualizaciones de Office

Lo más probable es que estemos hablando de una instalación Administrativa de Office. Por el momento, WSUS no es capaz de actualizar este tipo de instalaciones. También puede suceder que tengas un servicio de Office deshabilitado (Ose.exe). En este par de artículos están las opciones que podemos seguir para resolver la situación:

903773 No updates are displayed when you scan for updates by using Microsoft
http://support.microsoft.com/?id=903773

903774 Some Microsoft Office updates are not successfully installed on certain
http://support.microsoft.com/?id=903774

3.- Ordenadores que no salen en los reportes de WSUS

La causa más frecuente de este problema es que los clientes hayan sido desplegados usando técnicas de clonación. En ese caso, hay unas claves del registro que serán comunes a todos los clientes. Una de ellas se llama y que se llama SUSClientID. Te imaginarás lo que pasa cuando el servidor recibe el estado de todos esos equipos con claves comunes... no los distingue.

La solución pasa por borrar esas ramas. Está todo documentado en:

903262 A Windows XP-based computer that was set up by using a Windows XP image
http://support.microsoft.com/?id=903262

4.- Esta pregunta nos la hicieron ayer en directo en Vigo al término de la presentación. ¿Es posible que los servidores de réplica no almacenen el contenido de las actualizaciones en local y que en su lugar redirijan a los clientes a descargarse las actualizaciones directamente de MIcrosoft Update?

Bien, cuando un servidor está en modo réplica, hereda parte de la configuración y opciones de administración del "servidor de arriba". Sin embargo seguimos teniendo libertad de especificar:

- Membresía de los equipos a los Target Groups. Aunque estos vienen predefinidos, tenemos libertad de distribuir los equipos que ataquen al servidor de réplica como queramos

- Agenda de sincronización y servidor Proxy a utilizar

- Por supuesto, opciones de monitorización y generación de informes

- Puede cambiarse la fuente desde la que se descargan las actualizaciones, que puede ser otro servidor que aquel del cual somos réplica.

Sin embargo, este último punto no implica que podamos cambiar la estrategia de almacenamiento de las actualizaciones, es decir, si las queremos descargar o dejar en Microsoft Update. Mientras estamos en modo réplica, no podemos especificar nada en este sentido y seguimos la directiva establecida en el servidor principal. Para más información, consultad la Guía de Operaciones de WSUS

Seguiremos contestando aquí las dudas que vayan surgiendo

Hola

Hace unos dias comentábamos por aqui la disponibilidad de la Beta 2 de WSUS 3.0, acompañada de alguna documentación. Aunque los más fácil hubiera sido reusar alguna de las máquinas virtuales que ya tenia con Windows Server 2003 R2 y WSUS 2.0 para actualizarlo, me he animado a probarlo sobre la también Beta 2 de Longhorn Server, montándolo todo desde el principio.  Pongo aqui los pantallazos comentados del proceso de instalación, que he realizado vía Remote Desktop desde mi XP:

La descarga es el habitual ejecutable autodescomprimible que lanza el ejecutable de la instalación al final:

Lo primero que nos pregunta la instalacion es en que unidad y carpeta queremos llevar a cabo la instalación de WSUS. Es recomendable al menos tener 6 GB libres para almacenar la base de datos y las actualizaciones, pero esta cantidad puede crecer en función de la cantidad de productos e idiomas en los que vayamos a querer dar servicio a los clientes de la red. En mi caso la unidad elegida no dispone de tal espacio disponible, por lo que la instalación alerta explícitamente sobre este hecho.

Los siguientes pasos de la instalación es la configuración de la base de datos que se va a utilizar para almacenar toda la lógica de la solución y el sitio Web donde se configurará el  servicio que utilizaran los clientes para obtener las actualizaciones disponibles y reportar su estado. En mi caso, ya que estoy usando Longhorn, WSUS 3.0 requiere tener instalado SQL 2005 SP1. En Windows Server 2003, o en Windows 2000, puede o bien usarse una instancia de SQL ya presente en el equipo o en otro servidor de la red, o si no el propio asistente instalará y configurara SQL Server 2005 Embedded Edition. Por otro lado, se nos da a elegir configurar el servicio Web en el Sitio Web Predeterminado en el puerto 80, o crear uno nuevo dedicado en el ya tradicional puerto 8530:

Tras estas opciones, se nos informa de los cambios que se van a realizar en función de las opciones elegidas y se lleva a cabo la copia de archivos y la configuración del sistema:

Una de las novedades de WSUS 3.0 es un asistente de configuración del servicio, que puede lanzarse justo después  de la instalacién o en cualquier momento después a través de la consola basada en la MMC 3.0. La idea del asistente es configurar todos los parámetros necesarios para tener el servidor operativo, y que en WSUS 2.0 había que especificar en diferentes lugares de la consola.

Con este asistente podremos:

• Elegir desde donde queremos descargarnos las actualizaciones. Podrá ser desde un WSUS que haga de "upstream proxy" o directamente desde Microsoft Update. WSUS 2.0 puede descargarse actualizaciones desde un WSUS 3.0, pero no al revés.

• Configurar el servidor proxy que nos separa de Microsoft Update o del WSUS upsteam proxy.

• Una vez hecho esto, se nos permite conectarnos al servidor elegido para descargarnos el esquema de productos soportados y las categorías de actualizaciones existentes para los mismos. Es un buen momento para comprobar si la conectividad es correcta, según los parámetros elegidos en los pasos anteriores.

• Especificar los idiomas en los que queremos bajarnos las actualizaciones. Ojo, porque por defecto el asistente nos marca todos los idiomas , lo que en la mayoría de los casos no es en absoluto necesario.

• Elegir los productos y sistemas Operativos para los cuales nos descargaremos las actualizaciones. Como en el caso anterior, es conveniente detenerse a pensar que es lo que tenemos desplegado en la organización. Siempre es posible marcar otro producto posteriormente.

• Seleccionar las categorías o clasificaciones de actualizaciones que nos descargaremos. Por defecto aparecen seleccionadas las actualizaciones críticas y de seguridad.

• Elegir si la sincronización de las actulizaciones elegidas para los productos especificados se llevará a cabo de forma manual por el administrador (no recomendado) o todos los días a una cierta hora.

• Por último, podemos lanzar la sincronización inicial, que nos descargará todas las categorías de actualizaciones especificadas para los productos elegidos durante las fases anteriores.

Una vez terminados todos estos pasos, el servidor WSUS 3.0 estará listo para dar servicio a los clientes. La nueva consola de administración nos permitirá administrar el servicio y sacar informes de manera distinta a como lo hacíamos en WSUS 2.0. Pero esa es otra historia, y ahora estamos en el último cuarto del España-Argentina.

Saludos

David

En los últimos días me han llegado noticias sobre increíbles mejoras de rendimiento de Windows XP Service Pack 3, lógicamente catalogadas como algo muy positivo. Pero la cosa estaba clara. Es simplemente la enésima estrategia para intentar desprestigiar Windows Vista contra el que ha sido erigido su "enemigo" natural. Una estrategia, como veremos, nada nueva.

Por supuesto, no descarto en absoluto que Windows XP SP3 vaya mejor. Es más, espero que asi sea, porque si para algo se soportan los productos que tienes en el mercado es para mejorarlos. Me he animado a escribir esto porque el otro dia estuve mirando algo de información acerca de lo que se incluía en el Service Pack 3 a petición de mi compañero Jose Murillo, y además de la consabida colección de actualizaciones de seguridad y funcionalidad aparecidas desde el SP2, las nuevas funcionalidades que se han incluido son en su mayor parte implementaciones de algunas de las ya incluidas en Windows Vista, como por ejemplo el cliente de NAP o la "Black Hole Router Detection" por citar dos escogidas al azar. Asi es que lo primero que me he preguntado es que si Vista es tan malo, cómo es posible que el rendimiento haya mejorado y no empeorado.

Por lo tanto me he puesto a leer.

La "blogosfera amarilla" reza que, usando Office, el rendimiento de XP SP3 mejora en un 10% con respecto al SP2 y que por supuesto deja en pañales a Windows Vista SP1, que es malo malísimo, situándole entre los 10 peores productos de todos los tiempos.

Mi cabeza de físico se pregunta automáticamente de dónde habrán salido tales datos, y me asombro ante la brillante mente ha conseguido usar Office como herramienta de benchmarking. Parece que la fuente es Computerworld. Vamos para alla:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9048658

Un simple vistazo basta para comprobar que esta tampoco era la fuente. Pero ya sabemos algo más. No, no se utilizo Office para las pruebas de rendimiento. Se utilizó algo llamado Officebench, desarrollado por una empresa antiguamente denominada CSA Research y actualmente con un nombre verdaderamente maligno, aunque eso si, Office 2007 estaba instalado en el equipo. Uno de sus jefes si que parece ser la raiz de toda la historia:

http://exo-blog.blogspot.com/2007/11/windows-xp-sp3-yields-performance-gains.html

Me asombra comprobar que se preocupa de mencionar que ha utilizado dos modelos exactos de un único modelo de equipo para hacer el estudio. De hecho la mayoría de los comentarios de la gente son bastante críticos, pero a mi me basta con la unicidad de la muestra. Me quedo con las ganas de saber exactamente en qué consiste las batería de pruebas de dicho producto. 

Pero la cosa no termina ahi. Tirando de histórico (juro no haber usado Google) me encuentro que la herramienta en cuestión fué utilizada hace algunos años para demostrar exactamente lo mismo, pero con Windows XP respecto a Windows 2000. Cambia el nombre de los productos por los de hoy y...:

http://www.infoage.idg.com.au/index.php/id;1157573402;fp;32768;fpid;179647284

Executive summary: Performance isn't the only factor that goes into the decision to upgrade desktop operating systems. But if capitalising on the benefits of Windows XP requires investing in new PC hardware, then a company-wide upgrade could be cost-prohibitive.

Test centre perspective: The results of our benchmark tests indicate that Windows XP is significantly slower than Windows 2000, especially under heavy load. Unless investing in new hardware for demanding users is an option, companies should stick with Windows 2000.

El otro dia un chaval muy majo de tan solo 16 años se me acercó en Valencia para que le aconsejara qué carrera debía estudiar para poder entrar algún día en una empresa como Microsoft. Además de lo que le contesté por correo, aqui van algunas recomendaciones más, que no le mencioné por obvias pero que me gustaría recordarle aqui y ahora (un buen jefe mio me solía decir que lo obvio es lo que más hay que explicar, porque el sentido común es el menos común de los sentidos).

• Aprende bien a leer
• Aprende bien a buscar
• Aprende a pensar por ti mismo
• Y por supuesto, no utilices Officebench para hacer benchmarking

Saludos

David Cervigón

NOTA: Escrito originalmente el 31/10/2008 y modificado el 15/10/2009 para incluir los cambios introducidos en Windows Server 2008 R2 y las dudas más frecuentes que nos han transmitido acerca de este tema en el último año.

Hola

Cuando uno adquiere una licencia de Windows Server 2008 R2, esta adquiriendo los siguientes derechos:

• Standard: Los derechos de ejecución de una instancia física de Windows Server 2008 R2 Standard y los derechos de ejecución de una instancia virtual de Windows Server 2008 R2 Standard sobre el servidor licenciado 
• Enterprise: Los derechos de ejecución de una instancia física de Windows Server 2008 Enterprise y los derechos de ejecución de cuatro instancias virtuales de Windows Server 2008 R2 Enterprise sobre el servidor licenciado 
• Datacenter: Los derechos de ejecución de una instancia física de Windows Server 2008 R2 Datacenter y los derechos de instalación de ilimitadas instancias virtuales de Windows Server 2008 R2 Datacenter sobre el servidor cuyos procesadores hemos licenciado

Nótese que la diferencia entre Standard/Enterprise y Datacenter es que los dos primeros se licencian por servidor, y el segundo se licencia por procesador (físico, no por número de cores). Es importante recalcar que Microsoft no licencia sus sistemas operativos para otra cosa que no sean dispositivos físicos, bien sean servidores o procesadores. En otras palabras, no se puede asignar una licencia de Windows (Server o Client) a una máquina virtual.

Otro error frecuente en torno a todo esto es confundir los derechos que os otorga el licenciamiento con las capacidades técnicas del producto. Hyper-V tiene exactamente las mismas capacidades en las tres ediciones de Windows Server y no está limitado a la ejecución de un número particular de máquinas virtuales. Las diferencias radican solamente en las capacidades de la edición de Windows, en lo tocante al soporte de número de procesadores, cantidad de memoria RAM, o funcionalidades de alta disponibilidad no presentes en la Standard

Consideraciones importantes:

• Este modelo de licenciamiento es independiente del software de virtualización utilizado.
  • Cualquier servidor físico que sobre el que vaya a correr una instancia virtual de Windows Server debe ser licenciado independientemente del Hypervisor que se vaya a utilizar. En este caso no estamos ejerciendo nuestros derechos de instalación física y solamente se hace uso de los derechos de ejecución de las instancias virtuales a las que la edición licenciada de derecho.
  • El derecho de ejecución de la instancia física no se puede intercambiar por una instancia virtual. Es decir, no puedo usar mis derechos de instalación física para instalar dos instancias virtuales en Standard o cinco en Enterprise sobre un dispositivo que corra un hypervisor independiente de Windows Server.
• Derechos de Downgrade. Siempre puede instalarse en las máquinas virtuales una versión o edición inferior a la que hayamos licenciado.
• Un servidor físico puede tener asociadas varias licencias de Windows Server, incluso de diferentes versiones. Por ejemplo si en un servidor licenciado con Windows Server Enterprise queremos sobrepasar las 4 instancias incluidas en la licencia, podemos adquirir otra licencia de Enterprise para ese servidor y utilizar los derechos de sus cuatro instancias virtuales para la quinta, sexta, séptima y octava máquinas virtuales.
• En un sistema con alta disponibilidad, es posible que un movimiento de una o varias máquinas virtuales entre servidores nos deje en un estado irregular desde el punto de vista de licenciamiento.
• Las derechos de uso se aplican únicamente a instancias en ejecución. Esto es obvio para la instalación física pero no así para las instancias virtuales. Una máquina virtual que no esté en ejecución no computa, lo cual aplica al gran número de máquinas virtuales paradas que pueden permanecer pre-configuradas en una librería. Solo computan a efectos de licencias en cuanto se pongan en marcha sobre un cierto servidor físico.

Después de todo esto, la duda suele ser qué edición nos conviene más, si la edición Enterprise, o olvidarnos del licenciamiento y adquirir Datacenter. La clave es, por supuesto, el número de procesadores de los servidores físicos que vamos a utilizar como hosts de virtualización, el ratio de servidores virtuales por servidor físico, y también la situación de partida. Si partimos de una situación en la que vamos a empezar a crecer en servicios virtualizados, si vamos a consolidar servidores físicos con Windows Server, o incluso si no vamos a virtualizar Windows Server.

Escenarios de licenciamiento

• Nuevos entornos. La siguiente calculadora nos ayuda a hacer las cuentas para salir de dudas. Lo que no incluye lógicamente son nuestros planes de crecimiento. Así es que ante la duda, o unos pocos euros de diferencia, lo preferible es usar Datacenter y olvidarse de las instancias que queramos echarle encima al host. Para hacernos una idea:
  • En equipos con 2 procesadores físicos, nos sale mas barato Datacenter a partir de 8 instancias virtuales de Windows Server. Para menos, asignaremos una o dos licencias de Enterprise al servidor físico.
  • En equipos con 4 procesadores físicos, nos sale mas barato Datacenter a partir de 16 instancias virtuales de Windows Server. Para menos, asignaremos entre una o cuatro licencias de Enterprise al servidor físico.

• Consolidaciones: Lo normal en una organización que vaya a abordar un proyecto de consolidación mediante virtualización de servidores es que parta de una base de un cierto número de servidores con Standard, una menor cantidad de servidores con Enterprise (en función de escalabilidad o roles no incluidos en Standard como por ejemplo el cluster o las entidades certificadores) y pocos o ningún servidor con Datacenter. Si consolidamos, por ejemplo, 12 servidores departamentales con Standard en 12 VMs sobre un host hay que tener en cuenta que, según lo explicado anteriormente, las 12 licencias Standard pasan a estar asociadas a dicho host, no al cada una de las VMs. Lo que se puede hacer en estos casos es actualizar alguna de las licencias Standard a Enterprise o Datacenter, asociarlas al nuevo host y prescindir de las licencias que ya no necesitamos. Esto además posiblemente nos permita aumentar sin coste alguno las instancias virtuales de Windows Server sobre el servidor licenciado. Es importante tener en cuenta que este ejercicio depende mucho del tipo de licencias que se hayan adquirido en función de la modalidad de contrato que se tenga establecido con Microsoft. Dependiendo de ello, este modelo de licenciamiento puede suponer una inversión o incluso en ocasiones un ahorro de costes.

En este tipo de ejercicios de consolidación se suele uno encontrar ante un problema adicional. ¿Que sucede con las versiones OEM?. ¿Es legal hacer un P2V de una versión OEM de Windows Server?. El razonamiento es sencillo. Las versiones OEM “nacen y mueren” con el servidor físico con el que las adquirimos, ya que no pueden ser traspasadas a otro ni siquiera del mismo fabricante. Dado que si lo virtualizamos la licencia pasará a estar asociada al servidor físico que aloje la VM resultante, estaremos violando el acuerdo de licencia. Pero por otro lado es posible que en el servidor destino, licenciado con Enterprise o Datacenter, tengamos derecho a correr nuevas instancias de Windows Server. Estrictamente hablando deberíamos reinstalar esa VM con una versión de Windows Server para usar diferente clave y podríamos tener problemas con los sistemas de activación, pero ahí queda la cosa.

Hyper-V como role de Windows Server vs. Microsoft Hyper-V Server 2008 R2

De todo lo anterior se extrae un conclusión importante. A la hora de virtualizar Windows Server, Microsoft gana exactamente lo mismo virtualices con Hyper-V o con cualquier otra solución del mercado, ya que precios y licenciamiento son independientes del hypervisor elegido. Al incluir un hypervisor como un role dentro de Windows Server 2008 y Windows Server 2008 R2, Microsoft permite que virtualizar o no sea una decisión en manos exclusivamente del cliente, y que además dicha decisión no suponga una inversión adicional en software, al estar incluida dentro del sistema operativo.

Adicionalmente, y siguiendo esta misma línea, Microsoft pone gratuitamente a disposición de todo el mundo Microsoft Hyper-V Server 2008 R2, que incluye todo lo necesario para montar un host de virtualización, con toda la funcionalidad de Hyper-V R2, incluyendo HA, Live Migration, CSVs y el mismo soporte de hardware que un Windows Server 2008 R2 Enterprise. Sin embargo, al tratarse se una descarga gratuita, no otorga ninguna clase de derecho adicional desde el punto de vista de licenciamiento, por lo que todo lo que corra por encima debe licenciarse acorde. Así es que desde un punto de vista exclusivamente de licencias:

• Usaremos el role de Hyper-V de una edición Enterprise/Datacenter para virtualizar Windows Server
• Usaremos Microsoft Hyper-V Server 2008 R2 para virtualizar cualquier cosa que no se beneficie de este modelo de licenciamiento. En particular Windows Client o distribuciones comerciales de Linux

Sin embargo desde un punto de vista técnico, operativo y de arquitectura, la nube interna debe ir licenciada con Windows Server 2008 Datacenter. En este tipo de entornos el ejercicio consiste simplemente en contar procesadores, licenciarlos, y disfrutar no solo de la virtualización sino de todas las funcionalidades incluidas en el sistema operativo Windows Server

¿Tiene sentido este modelo?. ¿Es realmente más sencillo de lo que parece?. Yo creo que si. Parece que la tendencia a futuro en el datacenter es pagar en base al consumo de recursos, bien los alberguemos dentro de la organización, bien sea un tercero el que nos los preste. Al llevarlo a una simple cuenta de CPUs, este modelo de licenciamiento es definitivamente mucho más compatible con este esquema que el tradicional pago por instalación del sistema operativo.

Saludos

David Cervigón

Hola

Últimamente nos preguntan amenudo por este pequeño inconveniente y si buscas por ahi encontrarás que la culpa es, como no, de Windows Vista. Afortunadamente nosotros ya nos lo hemos preguntado antes, porque nos ha sucedido en todos los portátiles que tenemos y en algún sobremesa, asi es que esta es la respuesta.

Antes de nada, recordar la tabla de máxima memoria soportada por las ediciones de Windows

Como se puede observar, salvo que se trate de una edición de Vista Starter, no debería haber problema alguno. Con sistemas de 32-bit el máximo de memoria es 4Gb (2^32) y por tanto tampoco debería ser necesario pasarse a x64 si no tenemos más de 4Gb.

Para ilustrar un poco más el problema, en nuestro caso, con Windows Server 2008 x64, nos sucede lo siguiente. Las propiedades del sistema lee la cantidad de memoria física instalada,marcando los 4Gb correspondientes a los dos módulos de 2Gb instalados, aunque realmente disponible para el sistema tenemos una cantidad considerablemente menor. Esa cantidad varía según la máquina y la versión de la BIOS:

Por tanto, el "problema" es independiente del sistema operativo y se debe a la actual arquitectura de algunos equipos, en particular de los portátiles, en la que los dispositivos del sistema reservan direcciones de memoria justo por debajo de los 4Gb. En algunas BIOS hay opciones para configurar las "memory mapped IO reservations" e intentar paliar la situación, pero como digo es independiente del software.

Hay información tecnica y una exlicación más detallada aqui:

http://blogs.msdn.com/hiltonl/archive/2007/04/13/the-3gb-not-4gb-ram-problem.aspx

http://www.asisupport.com/ts_4GB_memory_info.htm

David Cervigón

Hola de nuevo

Antes de nada, existen dos versiones de Virtual Server 2005 R2:

1. La versión final, disponible para descarga gratuita aqui
2. La Beta 2 de  Virtual Server 2005 R2 SP1 que se puede conseguir vía Connect aqui

Dado que si vamos a instalar Virtual Server en un Windows Vista asumo que es para hacer pruebas, esta última es lo suficientemente estable como para poder ser usada para dicho propósito o para realizar pilotos. Además si tenemos procesadores que soporten virtualización asistida por hardware (AMD-V o Intel-VT) nos podremos beneficiar de esta ventaja ya que en el SP1 está soportada. Recordar también que de ambas versiones existen los correspondientes binarios para i386 y x64.

Al grano. Lo primero es tener instalado IIS7 en Windows Vista, que está disponible como una característica (por cierto, si lo estas buscando, el comando Telnet también). Es necesario agregar los siguientes componentes de IIS7.

• Herramientas de Administración Web
• Compatibilidad con la Administración de IIS 6
• Compatibilidad con la configuracion de IIS 6 y Metabase de IIS
• Consola de administración de IIS
• Servicios World Wide Web
• Características de Desarrollo de Apliciaciones
• CGI
• Característcas HTTP Comunes (Todas menos "Redirección HTTP")
• Estado y Diagnóstico
• Registro HTTP
• Seguimiento
• Características de Rendimiento
• Compresión de contenido estático
• Seguridad
• Autenticación de Windows

Lo segundo es conectarse a la consola Web de Virtual server usando elevación en Internet Explorer. Es decir, clic con el botón de la derecha en el enlace a la consola, y seleccionar "Ejecutar como administrador".

Saludos

Hola

Corriendo el riesgo de no ser muy original en la temática escogida, vamos a dedicar este post a ver algunas de las funcionalidades del nuevo Virtual PC, al que parece que habíamos enterrado antes de tiempo. Últimamente, la evolución de Kidaro hacia MED-V ponía de manifiesto la necesidad de evolucionar el motor de virtualización en el lado cliente, pero su inclusión como una funcionalidad de Windows 7 es algo que se ha sabido hace poco, incluso internamente.

Windows Virtual PC aparece en los últimos días íntimamente relacionado a “Windows XP Mode”, que en resumidas cuentas consiste en una máquina virtual preconfigurada con un Windows XP SP3. Lo que hace especial a esa máquina es que será directamente descargable por el usuario que haya adquirido las versiones de Windows 7 que dan derecho a ello, y que gracias a las nuevas funcionalidades de Windows Virtual PC, permite ejecutar en ella las aplicaciones incompatibles con Windows 7 pero con sus ventanas  integradas en el escritorio del usuario. Por supuesto, podremos también usar la tradicional ventana que nos muestre todo el escritorio de la máquina virtual con sus aplicaciones corriendo.

Como digo, esta funcionalidad no es propia de la imagen ya preconfigurada, sino que se puede hacer lo mismo con cualquier VM con Windows XP SP3, Windows Vista SP1 o Windows 7. Basta con crear la VM e instalar el sistema operativo, instalar los nuevos Componentes de Integración y hacer algunos ajustes. Todos los detalles están aquí:

• Windows Virtual PC Evaluation Guide

Tras haber estado con Fernando parte de la mañana trasteando, os dejo algunos trucos para ahorrar tiempo:

1. Windows Virtual PC no se muestra como una aplicación, sino integrado en el menú ”Todos los Programas” del botón de inicio. Ahí tenemos:
• Algunas de las máquinas virtuales que tenemos definidas
• Un enlace a una carpeta donde almacenamos las definiciones de las máquinas virtuales que vamos creando
• Las aplicaciones que están instaladas en esas máquinas virtuales
2. La carpeta “Máquinas Virtuales, hace las veces de herramienta de gestión. Se de uno que se ha pasado algunos minutos blasfemando por no encontrar la forma de crear una nueva máquina virtual o por ver la configuración ya existente. Para los más frikis, echad un vistazo al desktop.ini.
3. Los .vmcx son un ficherillo que indica dónde esta el .vmc, que a su vez contiene las propiedades y configuración de la VM, el path al .vhd, al .vsv, etc. Como curiosidad, no todas las VMs de esta carpeta aparecen debajo de Windows Virtual PC en el menú de Todos los Programas. Por defecto solo lo hace la correspondiente Virtual Windows XP. Para los muy caprichosos (como yo) les recomiendo usar el botón derecho del ratón y jugar con “Explorar todos los usuarios”. Comprobareis que todo depende de los accesos directos (.lnk) que se creen en C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Virtual PC:
4. La capacidad de publicar aplicaciones en el escritorio depende de tres cosas:
• De los Integration Components (C:\Program Files (x86)\Windows Virtual PC\Integration Components)
• De esta casilla en las propiedades de la VM:
• De que este o no habilitada esta opción en la VM, a gusto del consumidor:
5. Las aplicaciones publicadas son igualmente meros accesos directos, que pueden borrarse si no nos interesan, y sospecho que incluso se pueden generar a voluntad. Si alguien averigua lo que significa el numerajo que me lo cuente.
• %SystemRoot%\system32\rundll32.exe %SystemRoot%\system32\VMCPropertyHandler.dll,LaunchVMSal "App-V Sequencer (XPSP3)" "||12152d0f" "Forefront Client Security"

Lo del soporte de USB parece que puede llegar bastante lejos. Estoy probando lo más friki que se me ha ocurrido, y ya os contaré. Anticipándome a la pregunta, Windows Virtual PC soporta USB pero no VMs x64. Justo al contrario que Hyper-V, que no soporta USB, pero si VMs x64. A ver si un día los de los grupos de producto salen a cenar y se obra el milagro.

Lo de las ventanas, opciones y menús en español es obra del Language Pack. Por ahora mi decisión es usar Windows 7 x64 y Office 2007 en ingles y usar los paquetes de idioma en castellano, lo que da la opción de cambiar la interfaz de idioma cuando así se desee.

Saludos

David Cervigón

Hola

Hoy toca hablar de cluster. Lo cierto es que el término es a veces un poco confuso, porque se refiere a un grupo de diferentes máquinas trabajando juntas por alguna razón determinada. En éste artículo de la Wikipedia creo que se explica muy bien, y distingue entre clústeres de Alta Disponibilidad (HA clusters), clústeres de balanceo de carga (Load Balancing clusters) y clústeres de computación (Grids)

En particular, en el mundo Microsoft existen tres tecnologías diferentes para cada uno de estos tipos de clustering. Dos de ellas están incluidas en Windows Server, y la otra en una edición especial. Ésta es una presentación al respecto, un poco arcaica ya, pero es mía :-)

• Failover Cluster: Conocido también como MSCS o de almacenamiento compartido. Se utiliza para dotar de alta disponibilidad por tolerancia a fallos de servicios que por lo general tienen una dependencia del almacenamiento. Ejemplos de esto serían bases de datos, buzones de correo, máquinas virtuales, etc.
• Clústeres de NLB (Network Load Balancing): Pensados para dotar de alta disponibilidad por tolerancia a fallos y escalabilidad a servicios de red. El ejemplo más frecuente son granjas Web o de Terminal Services. Se asume que todos los frontales tienen la información que sirven a los clientes correctamente replicada o en un repositorio central o back-end (generalmente este en Failover Cluster).
• Clústeres HPC o de High Performance Computing: A "grosso modo" un nodo cabecera recibe un trabajo que paraleliza entre los diferentes nodos de computación, y estos le devuelven los resultados de vuelta para componer el resultado total. Esto se usa generalmente para hacer sumas y restas de esas que con una calculadora resultaría extremadamente tedioso realizar.

Todos y cada uno de estos tipos de cluster tienen algo que ver con el mundo de la virtualización. Todos pueden montarse en un entorno puramente virtual allí donde tenga sentido hacerlo (Clústeres virtuales, NLB entre VMs, o nodos de HPC virtuales), y los hosts físicos de Hyper-V pueden funcionar tanto con Failover Clustering como con NLB, si bien esto último es raro y me costaría imaginar algún entorno en el que fuera aplicable.

En adelante nos vamos a centrar únicamente en Failover Clustering y su relación tanto con los hosts de hyper-V como con las VMs que montemos encima. Distinguimos entonces:

• Host Clustering: de 2 a 16 nodos con Hyper-V funcionando conjuntamente de modo que las Máquinas Virtuales puedan pivotar entre ellos, según sea necesario:
  • Bien por una caída no planificada del Host que la alberga. En este caso la VM reiniciará en alguno de los hosts del cluster automáticamente
  • Bien de manera manual o automática, por un mantenimiento planificado del host, o porque queramos redistribuir de forma diferente las cargas de trabajo entre los nodos del cluster. Esto es lo que hoy en día conocemos por Quick Migration, y en Windows Server 2008 R2 podremos hacer también con Live Migration.
• Guest Clustering: Esto se refiere a un Failover Cluster en el que los diferentes nodos del mismo son máquinas virtuales corriendo en Hyper-V. Rizando el rizo puedes tener guest clustering en HA, es decir que las VMs que componen el cluster virtual, estén albergadas a su vez en un host cluster de Hyper-V

Vamos a tratar de aclarar las dudas más frecuentes que suelen surgir sobre todo esto:

Host Clustering

Creo que esto se entiende fácilmente simplemente diciendo que es la combinación de la característica (role) de Hyper-V y la funcionalidad (feature) de Failover  Cluster incluidos en Windows Server 2008 x64 Enterprise y Datacenter. La configuración hardware más típica para montar esto consiste en:

• Almacenamiento compartido (típicamente SAN, con Fiber Channel, iSCSI o SAS, aunque este tipo de tecnologías proliferan). Muy importante en este punto y en lo que sigue: Windows Server 2008 NO SOPORTA Failover Clustering usando el tradicional bus SCSI
• De 2 a 16 servidores que tienen la capacidad de acceder a un cierto numero de LUNs expuestas a todos ellos por el almacenamiento compartido
• Dos o tres subredes diferentes para gestión, acceso publico y heartbeat.

Por suerte, puedo ahorrarme el hacer un paso a paso de la creación de un cluster de Hyper-V porque abundan. Si que creo que es importante referenciar la documentación que considero "autoritativa" para ello:

• Design for a Failover Cluster in Which All Nodes Run Hyper-V  
• Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V
• Checklist: Failover Cluster in Which the Servers Run Hyper-V
• Step-by-Step Guide for Testing Hyper-V and Failover Clustering

Para los interesados en probar esto y que no cuenten con este tipo de sistemas de almacenamiento compartido, queda la friki-opción de usar uno o varios File Shares (y si ya nos queremos complicar aún más la vida, que sean por NFS). Todo esto, y mucho más, está detallado en este post de mi compañero José Barreto. De hecho él tiene publicado un post mucho mas curado que éste que estas leyendo, y que se titula Windows Server 2008 Hyper-V Failover Clustering Options.

Un tipo particular de Failover Clusters son los clústeres geográficamente dispersos, multi-site clusters o GeoClusters. Y están de moda. Espero poder dedicar algún tiempo a dar más detalles sobre ellos (aprovechando que Dani Matey, con nocturnidad y en compañía de otros, hace poco que ha estado montando un par de ellos en sendos clientes de esos cuyo nombre conocemos sin excepción todos los españolitos). Mientras tanto, vayan por delante algunas consideraciones:

• Estrictamente hablando, el almacenamiento debe estar replicado en las diferentes localizaciones. La idea es que el sitio físico donde reside el almacenamiento no sea un punto único de fallo.
• El Failover Cluster de Windows Server 2008 ha sido rediseñado a nivel de almacenamiento y red para soportar este tipo de entornos. En particular sus modelos de quorum permiten una arquitectura del almacenamiento "shared nothing", en la que la replicación de la información se realiza por algún medio más o menos ajeno al cluster. En un extremo tendríamos las soluciones tipo Database Mirroring, Log-shipping etc. (como la de los clústeres CCR de Exchange 2007) y en el otro la pura replicación hardware. En este último caso hay que tener en cuenta una máxima de cajón. La velocidad de la replicación debe ser mayor o igual que la velocidad a la que el nodo escribe datos en el almacenamiento.
• Debe existir un componente software que medie entre el cluster y el almacenamiento para decidir en que sentido debe realizarse la réplica, y tomar la acciones necesarias en caso de fallo o movimiento manual de los recursos.
• La arquitectura de Hyper-V le hace agnóstico de toda esta película. Mientras que en el otro nodo el almacenamiento sea a todos los niveles idéntico, todo lo que espera Hyper-V es que alguien le presente los ficheros necesarios para continuar moviendo la máquina virtual.
• Esta solución es cara. Y hay quien pregunta por algo similar, pero sin el coste asociado. Existen diferentes soluciones de replicación de datos a nivel software (podríamos imaginar, solo imaginar, una replicación de datos a base de robocopys :-) ), pero dudo muchas de ellas lleguen a cumplir todas y cada una de las condiciones anteriores. Por tanto, se parecerán mucho más a una solución de backup que a un geocluster. Y en estos casos conviene preguntarse quién y como garantiza la consistencia de los datos copiados. Prometo investigar.

Para hacernos una idea de soluciones de este tipo, he aquí una lista, que francamente no he repasado y no sé cuantas de ellas pueden aplicar a Hyper-V y Windows Server 2008.

Guest Clustering

Llegados a este punto, cabe preguntarse acerca de la necesidad o no de montar un cluster virtual. Por un lado, si el failover cluster se inventó principalmente para proteger a las cargas de trabajo ante un eventual fallo del hardware físico, y no solamente ya no tenemos hardware físico que se rompa sino que además ese "hardware virtual" se puede beneficiar de las tolerancia a fallos del host de virtualización que lo sustenta, ¿que ganamos?. Si la VM ya tiene alta disponibilidad, ¿para que rizar el rizo?. Pero por otro, ¿quien nos defiende ante un fallo que suceda a nivel de sistema operativo o aplicación dentro de la máquina virtual?. Y además, si tengo clusteres físicos en producción, ¿por qué no beneficiarme de las ventajas de la virtualización en los entornos de pre-producción y pruebas y desarrollo equivalentes?. Resumiendo, el "host clustering" de VMs reduce pero no elimina la necesidad de usar "guest clustering".

Antes de meternos a ver cómo se montan en Hyper-V, es conveniente repasar la manera en que hace en Virtual Server y en otras soluciones de virtualización. En esos entornos se emular una controladora SCSI que soporte bus sharing (la Adaptec 7870 para mas señas en el caso de Virtual Server, y en otros casos LSI, BusLogic, etc.), y que, en resumidas cuentas, pueda realizar las operaciones descritas en este artículo de la Knowledge Base. Pues bien, el diseño del Failover Cluster de Windows Server 2008 se lleva a cabo teniendo en cuenta las necesidades de los modernos entornos de almacenamiento compartido, y no soporta más el tradicional bus SCSI. Me sorprendería mucho que alguien montara un cluster virtual de Windows Server 2008 (que efectivamente funcione, no que termine el el proceso de configuración) usando las controladoras emuladas arriba citadas.

La controladora SCSI que se usa en Hyper-V no es una emulada sino sintética, es decir, no es una implementación software de una ninguna controladora SCSI que exista o existió en el mercado. Y no soporta bus sharing, lo que la hace incapaz de soportar un cluster de Windows 2000 Server o Windows Server 2003. Mis sospechas (personales) es que si el clustering a través de SCSI no se soporta en Windows Server 2008, simplemente no se ha invertido en este sentido en la controladora SCSI sintética de Hyper-V.

¿Cómo se hace pues un cluster virtual en Hyper-V?. Pues a través de una tecnología bien soportada en Windows 2000, 2003 y 2008. Usando iSCSI. Para ello necesitamos dos piezas:

• El iSCSI Initiator en el sistema operativo de la máquina virtual. Windows Server 2008 lo lleva de serie, y para Windows 2000 SP4 y Windows 2003 se puede descargar de aquí.
• Almacenamiento que sea capaz de exponer sus LUNs mediante iSCSI o un "iSCSI Target" por software. Muchas de las cabinas modernas soportan tanto Fiber Channel con iSCSI, y hay también servidores de especializados de almacenamiento que exponen su almacenamiento a través de iSCSI. Tal es el caso de Windows Unified Data Storage Server 2003 (Windows Server Storage Server 2003 R2), que incluye una evolución de Wintarget que comercializaba String Bean Software.

Esto tiene bajo mi punto de vista una ventaja y un inconveniente. La ventaja es que el almacenamiento se le presenta directamente a la VM, y solo nos tendremos que preocupar de optimizar las tarjetas de red virtuales y las del host físico, ya que obviamente estamos encapsulando comandos SCSI sobre Ethernet lo que debe ser tenido en cuenta a la hora de dimensionar la solución. El inconveniente es que a fecha de hoy el almacenamiento iSCSI no es tan frecuente como el Fiber Channel, y los buenos iSCSI targets gratuitos escasean. En este sentido creo que vamos a asistir en los próximos años a la competencia entre la fibra y el cobre también en el campo del almacenamiento.

Bueno, menudo ladrillo. Y lo peor es que tengo la sensación de dejarme un montón de cosas en el tintero. Espero que al menos a alguien le resulte aclaratorio.

Saludos

David Cervigón

Hola

En esta guía podéis encontrar las configuraciones de OCS 2007 que están probadas y soportadas en entornos virtualizados, así como recomendaciones para instalarlo y configurarlo de modo que la solución tenga un buen funcionamiento.

Running Microsoft Office Communications Server 2007 R2 in a Virtualized Topology: Best Practices and Performance Considerations

Esta bastante bien detallada la arquitectura de la solución que se ha probado, con datos de escalabilidad y todo.

Saludos

David Cervigón

Durante los meses de verano una de nuestras principales ocupaciones es planificar parte de las actividades que haremos durante el curso y preparar el contenido de las mismas. Giras, eventos, webcasts, screencasts, guías, etc. Los ciclos de vida de los productos y lanzamientos marcan una buena parte de dicho contenido, pero tampoco es extraño que a lo largo del año la gente nos solicite más o menos cosas de determinadas tecnologías que no se habían previsto a priori.

Lo que tenemos en la cabeza para este año es, principalmente:

• Los lanzamientos de SQL 2008, Small Business Server 2008 y Essentials Business Server 2008,
• Temas de virtualización (Hyper-V, SCVMM2008, Virtualización de Aplicaciones, Virtualización del escritorio, Virtualización de la presentación)
• Despliegue de Vista SP1 y 2008
• Gestión (System Center, MDOP)
• Seguridad

Sin embargo, como cualquier idea es siempre bienvenida, me gustaría que propusierais lo que se os ocurra como contenido de este tipo de actividades.

• Temas o series para dejar grabados en Webcast (PPT + Audio + Video + Demo)
• Vídeos cortos o series de ellos (Audio + Video + Demo, sin PPT)
• Screencast con tutoriales básicos o avanzados sobre preocupaciones frecuentes
• Sesiones para ser impartidas en eventos presenciales
• Cosas de las que hablar en este blog

Simplemente dejad un comentario aquí o mandadme un correo dándole al botoncito de "email" de arriba a la izquierda. A las mejores ideas/propuestas ya les enviaré algo (camisetas, copias pata negra de Windows Vista, o le que vaya pillando de los almacenes de los de marketing). Y a los que se animen a llevarse el premio gordo y quieran a participar como ponentes y/o creadores de contenido, los recibiremos con los brazos abiertos.

Saludos

David Cervigón

Y además, nada menos que por una fuente oficial. Es la anunciadísima hecatombe, la decadencia, el fin del imperio.

La metodología es sencilla. Dos máquinas virtuales ejecutándose simultáneamente sobre le mismo host. Mismo hardware virtual, mismos recursos para cada sistema operativo. Pero eso no es todo. Para mayor mofa y escarnio, la de Windows 95 tiene 16 veces menos memoria RAM y 6 veces menos tamaño de disco. Eso sin contar que Windows Vista tiene instaladas las Vitual Machine Additions para darle alegría, cosa que no es posible en Windows 95, porque no existen.

En este vídeo se puede comprobar claramente que Windows 95 arranca y apaga más rápido, reaccionando de manera más veloz ante un doble clic en cualquier elemento. De paso también pone de manifiesto que la web de Microsoft ni siquiera funciona bien con Internet Explorer.

Even Windows 95 performs faster than Windows Vista

Teniendo en cuanta además que Windows 95 es mucho más seguro, porque no necesita parches del Windows Update, ni antivirus ante la inexistencia de malware activo para dicho sistema operativo, "Quod Eram Demostrandum". ¡Descárgatelo ya del bittorrent!. ¡Pásalo!.

Si todo esto tiene sentido para ti, y después de haberle tirado tres huevos al primer tipo de Microsoft que se cruce en tu camino mientras le exiges que te devuelva tu dinero, tienes tres opciones:

1. Si eres un gran técnico, con profundos conocimientos, casi un gurú, crea tu propia distro de Linux para desbancar definitivamente a Windows. Aquí tienes unas sencillas instrucciones, de una fuente más que fiable por su tremendo apoyo al mundo del software libre: http://www-128.ibm.com/developerworks/library/os-lfs/
2. Si por el contrario prefieres las últimas tendencias y liberarte poco a poco del software de Microsoft (sin minar por ello la fortuna de Bill Gates), cómprate un Mac y descubre por qué Boot Camp y VirtualBox son particularmente útiles en OS X.
3. Instalarte XP SP3, pese a necesitar cientos, no, miles de parches para poder ser estable, aunque todavía inseguro (NOTA: Si, también va peor que Windows 95, lo que confirma la tendencia a la baja del monopolio de Redmond)

Por otro lado, puede que esta prueba de concepto te parezca una soberbia tontería. No te entiendo, la verdad. ¿Lo dices porque se nota a la legua que he utilizado realmente la versión OSR2.5 de Windows 95?. ¿Porque la metodología que he utilizado no garantiza la veracidad del resultado?. ¿Quizás porque debería haberme leído la Guía "Measuring Performance in Windows Vista"?. Como sois los escépticos. Seguro que os pagan por pensar así.

Si no estas muy seguro de a qué atenerte, si todavía tienes tus dudas de que esta demoledora e irrefutable prueba tenga alguna validez, tal vez las siguientes preguntas te ayuden a centrar un poco más tu opinión.

1. Si dirigieras una empresa de software, ¿diseñarías tus productos pensando en el hardware  que estaba presente en el mercado hace cinco años, o en el que se comercializará durante los años venideros?
2. Si fueras a crear un nuevo sistema operativo, en tus objetivos de diseño te plantearías:
• La compatibilidad con todas y cada una de las aplicaciones existentes en el mercado.
• Que fuera simplemente más rápido que tus productos anteriores.
• Introducir novedades y más funcionalidades que puedan ser utilizadas por tus usuarios y aprovechadas por otros desarrolladores para crear nuevas aplicaciones.
3. ¿Que es para ti la innovación?
• Cualquier cosa bajo licencia GPL.
• No hacer nunca nada que no haya hecho alguien antes (por ejemplo, crear un Walkman que reproduzca MP3, pero tope guay, y revolucionar el mundo del ocio digital, o montar un buscador que encuentra hasta el dato más recóndito, forrándose de paso gracias a la publicidad, NO es innovar)
• Lo que dice la RAE: “Mudar o alterar algo, introduciendo novedades” (Jose lo explica mucho mejor que yo).

NOTA 1: Yo personalmente, nunca debí dejar de usar NetBSD 1.3, desde el que pretendía crear el virus definitivo que destruyera Windows para siempre. Mira que me iba bien en el 386. Mucho mejor que el Windows pirata, donde va a parar.

NOTA 2: Como, ¿no usas Hyper-V para esto?. No, estamos jugando...

NOTA 3: Si te sueles acercar a este blog en busca de otras cosas, mis disculpas.

Hola

Con este abro una serie de posts dedicados al tema de la virtualización del escritorio, en el que explicaré cual es la foto final que se pretende alcanzar. En los sucesivos daré información más detallada de cada una de las piezas que conforman el escenario.

Antes de nada, aclarar el título. Como ya expliqué en este otro post, es frecuente confundir la virtualización del escritorio con lo que hoy conocemos como VDI. Como decía entonces, existen mas posibilidades que la mera creación de una máquina virtual en el Datacenter para lograr que un usuario tenga sus aplicaciones o todo su “botón de inicio” en un lugar diferente al dispositivo físico que tiene en sus manos.

En este escenario vamos a combinar tres tecnologías diferentes:

• Windows Server 2008 Hyper-V R2 o Microsoft Hyper-V 2008 R2, que nos ofrecerán el hypervisor y la funcionalidad de alta disponibilidad y movimientos de máquinas virtuales
• Windows Server 2008 R2 Remote Desktop Services, que nos permitirán:
  • Servir a los clientes escritorios y/o aplicaciones individuales mediante el Remote Desktop Session Host
  • Ofrecer la infraestructura necesaria para conectarnos cómodamente desde cualquier lugar a través del Remote Desktop Web Access y Remote Desktop Gateway
  • Repartir las conexiones RDP de los clientes a las máquinas virtuales individuales o “pools” de ellas y a los Remote Desktop Services Hosts, o granjas de ellos, y/o las aplicaciones que publican mediante el Remote Desktop Connection Broker
  • Hablar con la capa de virtualización para gestionar la máquinas virtuales mediante el Remote Desktop Virtualization Host.
• Microsoft Application Virtualization (App-V), que nos permitirá virtualizar aplicaciones individuales para desplegarlas a clientes y/o servidores de Remote Desktop, bien sean estos físicos o virtuales.

Por ahora, dejaremos fuera la posibilidad de virtualizar clientes (o incluso servidores) en el propio equipo cliente, si bien esto abre nuevas posibilidades. Esto lo haríamos con Windows Virtual PC y/o Microsoft Enterprise Desktop Virtualization (MED-V).

El escenario sería este:

Los clientes físicos, portátiles, sobremesas o thin-clients, reciben algunas aplicaciones virtualizadas con App-V, y las ejecutan junto con las que pudieran estar ya instaladas físicamente. En este caso la ejecución es local, si bien las aplicaciones virtualizadas viven en su propia burbuja, sin “manchar” el Sistema Operativo base y sin “pelearse” unas con otras. Podemos llegar a tener ejecutándose simultáneamente diferentes versiones de la misma aplicación.

Estos los usuarios trabajando en estos clientes pueden necesitar en un momento dado ejecutar una aplicación específica que no este presente en su equipo, o incluso tener que conectarse a otro escritorio donde se ejecuta un entorno de aplicaciones específicas. Para lo primero puede acceder a una “Remote App” publicada en un servidor de terminales y para lo segundo puede, o abrir una sesión contra un servidor de terminales, o bien conectarse a una máquina virtual corriendo un sistema operativo cliente.

En este caso, los RD Web Access ofrecen un portal donde el usuario puede elegir lo que quiere hacer. Lanzar una aplicación remota, conectarse a un terminal server, conectarse a su máquina virtual personal (no dibujada), o conectarse a una máquina virtual de un pool de ellas configuradas de forma idéntica. Una vez hecha a difícil selección, será el Connection Broker quien se encargue de redirigir esa petición a buen puerto, en función del usuario y el destino. En ultima instancia, será el cliente el que hablará directamente con el destino asignado, y puede hacerlo de manera segura a través de un Gateway (no dibujado) en caso de que se encuentre en una localización remota.

El servidor de App-V se encarga de mandar las aplicaciones virtualizadas mediante streaming a los clientes físicos, a los servidores de terminal y a las máquinas virtuales, yéndose estas a sumar a las que pudieran estar instaladas directamente sobre el sistema operativo. He de decir que App-V soporta otros métodos de distribución de las aplicaciones, pero no quiero complicar esto mucho más de la necesario.

Tenemos por tanto:

• Tres posibilidades de tener un escritorio, uno físico y dos virtuales: El del equipo, el de los terminales y el de las máquinas virtuales.
• Tres posibilidades de tener las aplicaciones: Instaladas físicamente, virtualizadas con App-V y las Remote App del Terminal. estas a su vez pueden estar instaladas sobre el sistema operativo o virtualizadas con App-V.

Reiterando que me dejo fuera Windows Virtual PC y MED-V, solo hace falta aplicar un poco de combinatoria para darnos cuenta de lo rico que es todo esto, y de lo complicado que puede ser atinar con una estrategia de virtualización del escritorio adecuada. No conozco ninguna empresa que pueda presumir de haberse quedado única y exclusivamente con una de las combinaciones. Generalmente hay que analizar casuísticas en función de tipología de usuarios, aplicaciones que deben utilizar, datos que deben manejar y localizaciones en las que tienen que trabajar. Todo esto sumado a la infraestructura necesaria y al coste de la misma.

Llevo toda la semana montando dos escenarios que enseñan todo esto. Yo mismo me he sorprendido de haberlo podido montar todo en un único portátil. ¡Y me sobran 3-4 Gb de RAM para meter más cosas!:

Utilizo un portátil de 8 GB de RAM con Windows Server 2008 R2 con Hyper-V como estación de trabajo. Como siempre, uno de los principales trucos para mejorar el rendimiento de una solución de virtualización pasa por repartir bien el IO. Uso el disco interno para correr una VM que contiene el DC y el Bróker y tengo un par de discos USB externos conde corro las máquinas virtuales del pool y el servidor de terminal. Este contiene además tanto la parte cliente como servidora de App-V, consumiendo las propias aplicaciones que publica y sirviéndolas por Remote App. Hace además las veces de máquina virtual personal del administrador.

Todo esto puede y debe escalar mucho más. He pasado algunas horas esta semana montando todo sobre una infraestructura con un par de clústeres y algún que otro servidor más por debajo. Y he contemplado mi primera Geo-LiveMigration entre dos cabinas que replican alguna de sus LUNs de manera síncrona. La semana que viene tengo que repetir la instalación en otro entorno en la oficina. Si alguien se anima…

Tengo pendiente montar System Center Operations Manager 2007 R2 y System Center Virtual Machine Manager 2008 R2 RC en cuanto estén disponibles para enriquecer todo lo anterior con gestión / monitorización avanzada del entorno.

Sin embargo todo lo que os he contado hoy está incluido en Windows.

Saludos

David Cervigón

Hola

Hoy he estado viendo uno de estos en la oficina:

• http://www.microsoft.com/windows/multipoint/
• http://www.microsoft.com/windows/multipoint/experience-it.aspx

Cada conjunto de monitor, teclado y ratón se conectan a una cajita USB que a su vez se conecta a HUBs USB conectados a los puertos del propio servidor. Por lo que se puede observar en fotos y vídeos, los requerimientos de hardware no son como para tirar cohetes a la luna.

Esta orientado al entorno educativo, donde, no nos olvidemos, lo importante deberían ser los contenidos y el para qué de las herramientas, mas que las propias herramientas.

Saludos

David Cervigón

Ayer, en mi paseo habitual por la blogosfera amarilla leí una estupidez tal que me entraron ganas de enfundarme la navajilla McGiver y desenfundar de una vez la katana. Pero gracias de nuevo a la lectura de aquellos a los que de verdad parece quedarles algo de sentido común, a la refrescante visión del futuro de la web que nos vislumbra Alfredo de Hoces, y comoquiera que parece que al correo electronico le queda todavía una larga vida por delante antes de ser cien veces maldito por su capacidad de implementar tecnologías DRM para la protección de su contenido, me vuelvo a mis cosas.

Antes del parón navideño, Eduardo Montes me preguntaba la forma de instalr Exchange 2007 sobre Windows Server 2007. Me lo apunté en las tareas pendientes y aprovechando la reconstrucción de mi maltrecho entorno de demos, incluí en él tres nuevas VMs basadas en Windows Server 2008. Una con el DC y todos los roles de Exchange Server 2007 (menos el Edge, obviamente), y dos nodos de un Failover Cluster con un modelo de quorum "Node y File Share Mayority), sin nigún tipo de almacenamiento compartido, con dos Exchange Server 2007 SP1 funcionando pura Cluster Continuous Replication de una Base de datos de buzones.

No voy a hacer una guía paso a paso con mucho detalle, porque los enlaces que os pongo tienen información muy precisa. A grandes rasgos hay que:

• Montar el SO de las tres VMs, promocionar una como DC y hacer miembros del dominio a las otras dos. How to Prepare Active Directory and Domains 
• Instalar en las tres máquinas todos los roles y funcionalidades de Windows Server 2008 que son requisitos para cada uno de los roles de Exchange server 2007 SP1: How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008
• Instalar Exchange 2007 SP1 (si no es SP1 no funciona, por lo que use el ISO que trae el SP1 integrado que me bajé de mi suscripción a TechNet)

• Montar el con el modelo de quorum mencionado arriba (utilicé un file share creado en el DC) e instalar Exchange en cada uno de los nodos, uno como activo y otro como pasivo: Installing Cluster Continuous Replication on Windows Server 2008

¿Hay algun valiente que se atreva a montar algo de esto en piloto, preproducción o incluso producción?. Si es asi, que por favor nos lo cuente.

Saludos

David Cervigón

Estos son los prerequisitos y los pasos a seguir:

Prerequisitos

• Windows Server virtualization requiere un procesador que soporte:
• x64
• Virtualización asisitida por hardware (AMD-V or Intel VT)
• Data Execution Protection.
• No Execute (NX) bit en sistemas AMD
• Execute Disable (XD) bit en sistemas Intel
• En la BIOS debemos asegurarnos de que las opciones anteriores estén habilitadas. Además tras realizar cualquier cambio en este sentido es necesario apagar la máquina completamente. Reiniciarla no es suficiente
• En este post de hace unos meses contaba cómo averigüar si tu sistema tiene todas estas capacidades.

Instalación:

1. Instalar Windows Server 2008 Enterprise x64 Edition RC0. Por ahora no puede hacerse con la opción de instalacion "Core". También es posible usar las versiones Datacenter y Standard, pero por ahora el testeo se esta realizando sobre las version Enterprise y es sobre el papel la configuración más estable. Las URLs de descarga las tenéis en el post anterior.
2. Una vez instalado el sistema, ir a la carpeta C:\Windows\wsv, donde encontraremos dos ficheros .msu
1. Instalamos Windows6.0-KB939853-x64.msu
2. Instalamos Windows6.0-KB939854-x64.msu
3. A partir de este momento, podemos agregar el nuevo role Windows Server Virtualization que nos aparecerá disponible en el Server Manager
4. Seguimos el asistente y reininiciamos cuando nos lo solicite. Tras el reinicio, la instalacion continuará configurando las actualizaciones instaladas.
5. Una vez haya finalizado la instalación podremos ver la nueva consola Windows Virtualization Management brillando en las Herramientas Administrativas.
6. IMPORTANTE: El role de Windows Server Virtualization es, en esta release, incompatible con el de Domain Controller. En caso de que ambos roles estén instalados en el mismo equipo, cualquier intento de arrancar una máquina virtual se traducirá en un Stop 0x7D en vmbus.sys.

Tras estos sencillos pasos, ya podemos empezar a probar el resto de funcionalidades de Windows Server 2008 creando máquinas virtuales. No está de más probar a crear algunas que sean a su vez x64 y multi-procesador.

Pero esa es otra historia que merece ser contada en otro momento.

Que lo disfruteis.

Hola de nuevo

Hoy hemos terminado con los dos eventos de lanzamiento de Windows Server 2003 R2. Hoy en Barcelona, tras nuestra demo en la que clusterizabamos una máquina virtual de Windows Storage Server 2003 R2 en dos Blades de HP x64, hemos anunciado en directo que Virtual Server 2005 R2 Enterprise es ahora gratis, descargable desde la Web y lo que es aún más divertido, que damos soporte a algunas versiones de Linux (RedHat y SuSe), para las cuales se han desarrollado las Virtual Machine Additions correspondientes.

Toda la información en detalle está aqui:

http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/news/bulletins/vs05pricing.mspx

David

NOTA: Escrito originalmente el 18/12/2008 y modificado el 15/10/2009 para incluir las nuevas VDI Suites y las dudas más frecuentes que nos han transmitido acerca de este tema en el último año

Hola

Como de costumbre cuando escribo sobre estos temas, es importante aclarar que dada la naturaleza perecedera de un blog y lo complejos que resultan en ocasiones los modelos de licenciamiento, la información que sigue debe tomarse como una mera referencia y acudir a nuestro distribuidor o contacto comercial habituales en busca de la última información y precios.

Cuando se habla de virtualizar escritorios Windows y llevárselos en forma de máquinas virtuales a vivir sobre un host en el datacenter, es importante tener en cuenta el modelo de licenciamiento que aplica a estos entornos. Al igual que sucede con Windows Server esto también es cierto a la hora de licenciar Windows Client:

• Los sistemas operativos Windows se licencian por dispositivo. Dado que una máquina virtual no lo es, tenemos que licenciar el dispositivo en el que corre dicha máquina virtual, o el dispositivo desde el que se accede a ella.
• Su licenciamiento es independiente del fabricante de la solución de virtualización que sustente la solución.

Pongamos, y perdonad la “maldad”, que somos usuarios de un Mac o un Linux pero tenemos una máquina virtual con Windows para trabajar. En ese caso, seguimos teniendo adquirir una licencia de Windows para ese dispositivo y estaremos en situación perfectamente legal. Según el EULA de Windows (si nunca leíste un EULA, aquí están los End User License Agreements de todos los productos de Microsoft):

En lugar de usar el software directamente en el dispositivo con licencia, podrá instalar y usar el software solamente en un sistema de hardware virtual (o emulado de cualquier otro modo) en el dispositivo con licencia.

Pero, ¿que sucede si queremos llevarnos las instancias virtuales de Windows XP, Vista o 7 a correr sobre un hypervisor en el datacenter?. En este caso tenemos dos opciones:

• Adquirir tantas versiones FPP (Full Product Package), o “cajas”, de Windows como máquinas virtuales se vayan a montar e instalar las una a una en cada máquina virtual con su propia clave y activación independiente. Además de ser caro y tedioso, las licencias irían a parar no a las VMs si no al servidor físico, de donde no podrían moverse. Adicionalmente a esto, el EULA dice que no se pueden licenciar dispositivos con más de dos procesadores. Esta vía no es desde luego nada recomendable en casi todos los escenarios.
• Adquirir una licencia de Windows Virtual Enterprise Centralized Desktop (VECD) para el dispositivo desde el cual vamos a acceder a esa instancia virtual de Windows Client. VECD resulta más barato y otorga derechos adicionales que detallaremos a continuación.

Virtual Enterprise Centralized Desktop (VECD)

VECD es una suscripción anual que se asocia al dispositivo desde el que vamos a acceder a la infraestructura de VDI. En función de la naturaleza de dicho dispositivos podemos optar entre dos tipos de licencias VECD:

• VECD para Software Assurance: Válido para dispositivos que estén cubiertos por Software Assurance como parte del contrato que el cliente tenga suscrito con Microsoft
• Windows VECD: Para dispositivos que no estén cubiertos por SA, lo cual incluye las versiones OEM de Windows y los Thin Clients

Los precios de estas suscripciones dependen nuevamente del tipo de contrato que tenga el cliente, pero se puede estimar que Windows VECD es entre 4 y 5 veces más caro que VECD for SA, donde ya se reconoce la inversión el cliente en la plataforma Windows.

En ambos casos, la suscripción anual es re-asignable a otro dispositivo de acceso de las mismas características pasados 90 días, y nos da derecho a acceder desde dicho dispositivo a hasta 4 instancias virtuales concurrentes de Windows corriendo en máquinas virtuales en el datacenter. Además estas instancias virtuales pueden moverse libremente entre diferentes hosts de virtualización. Toda la información la tenemos aquí:

• http://www.microsoft.com/windows/enterprise/solutions/virtualization/licensing.aspx
• VDI Licensing brochure

El proceso para licenciar VDI no consiste por tanto en el recuento de máquinas virtuales, sino en el de los dispositivos físicos desde el que se accede. Solo tenemos que clasificarlos entre cubiertos o no con Software Assurance y adquirir las versiones de VECD que correspondan a cada uno de los dos grupos.

Durante el último año, estamos detectando una grave confusión en la venta de soluciones basadas en VDI. Si alguien durante el hipotético análisis del ahorro de costes de la centralización del escritorio con VDI te dice que puedes usar “el Windows que ya tienes” para instalar las máquinas virtuales, invítale amablemente a abandonar tus oficinas, porque, o no sabe de lo que habla, o sencillamente te está queriendo engañar. En estos casos, “el Windows que ya tienes” se refiere a las licencias que el cliente adquiere mediante un contrato de volumen. Como es bien sabido, dichas licencias solo otorgan derechos de actualización a la versión de Windows adquirida, siendo ilegal instalarlos en equipos sin sistema operativo, como es el caso de una máquina virtual. Generalmente se adquieren equipos a través de un fabricante determinado con sus licencias OEM de Windows, y se usa la licencia de actualización para plataformarlos con la imagen corporativa deseada. Y dado que las versiones OEM van asociadas al equipo, tampoco pueden utilizarse para instalar la máquina virtual.

Una vez analizado el requisito clave del licenciamiento de VDI, vamos a ver en qué consisten las VDI Suites que Microsoft a anunciado en Octubre de 2009 para complementar (no sustituir) VECD.

Las VDI Suites

Las nuevas VDI Suites son una pieza opcional, y adicional a VECD. Son también subscripciones anuales asociadas al dispositivo de acceso a la máquina virtual. Esto es lo que incluyen:

• VDI Suite Standard
• Microsoft Hyper-V Server 2008 R2 como hypervisor (que en cualquier caso es una descarga gratuita)
• Los derechos de gestionar la infraestructura sobre la que corren las máquinas virtuales desde System Center Virtual Machine Manager, System Center Operations Managers y System Center Configuration Manager. Dicho de otro modo, incluye las Client Management Licenses de SCVMM, y las Server Managemen Licenses de SCOM y SCCM para el host Hyper-V Server 2008 R2.
• Dado que para pasar por el Connection Broker que se incluye en los Remote Desktop Services de Windows Server 2008 R2 es necesario una RDS CAL, esta se se incluye, pero limitada única y exclusivamente a acceder a la infraestructura de VDI.
• Microsoft Desktop Optimization Pack. Entre todas las herramientas que este paquete incluye, lo más atractivo en entornos de VDI es que aquí va incluido Microsoft Application Virtualization
• VDI Suite Premium. Además de todo lo incluido en la VDI Suite Standard se incluye:
• Una RDS CAL para acceder de forma ilimitada a los Remote Desktop Services de Windows Server 2008 R2 (el clásico Terminal Server), bien a escritorios completos, bien a aplicaciones remotas.
• El uso del Microsoft Application Virtualization para Terminal Services, con lo que las aplicaciones corriendo en las sesiones del servidor pueden a su vez estar virtualizadas con App-V

Obviamente, la versión Premium está pensada para aquellos clientes que deseen combinar las dos estrategias de centralización de escritorios más frecuentes. Hosted Virtual Desktops (VDI) y Server Based Based Desktops (Remote Desktop Services) y que en ambos casos quieran potenciar la solución con la virtualización de aplicaciones. La inclusión de las licencias de los productos mencionados de la familia de System Center tienen como propósito no descuidar la gestión del sistema sobre el que estan corriendo las máquinas virtuales.

¿Puede usarse una VDI Suite para soluciones basadas en otras soluciones de virtualización que no sean Hyper-V?. Por supuesto que si, solo que en ese caso necesitaremos un desembolso adicional, en el hypervisor, en el broker, y en otros componentes.

Conclusión:

Como ya hemos comentado por aquí en más de una ocasión, Virtualización del Escritorio es mucho más que VDI, siendo este último una de las opciones para alcanzar el objetivo. Si queremos montar una solución de virtualización del escritorio que incluya VDI necesitaremos:

• Mandatorio: VECD for SA o Windows VECD para los dispositivos de acceso (o la mencionada opción de las versiones FPP, con sus limitaciones)
• Opcional: VDI Suite Standard y/o Premium

Y lo anterior es independiente del fabricante de la solución de virtualización elegida. Lamentablemente, sospecha de cualquiera que te diga que no necesitas VECD para una infraestructura de VDI

Referencias:

• http://www.microsoft.com/windows/enterprise/solutions/virtualization/improve-flexibility.aspx
• http://www.microsoft.com/virtualization/en/us/products-desktop.aspx
• http://www.microsoft.com/licensing/
• http://www.microsoft.com/windows/enterprise/products/mdop/default.aspx 
• http://ladylicensing.spaces.live.com/Blog/cns!87F95F1B5B21B01E!1965.entry
• Antiguo, pero útil:
• http://download.microsoft.com/download/e/4/4/e4442c9f-30d9-41f3-9876-82bbfc5aa4e6/windows_vista_enterprise_centralized_desktop.pdf
• http://download.microsoft.com/download/d/5/f/d5f15b1e-a8e4-4e2c-b85f-d69d3f132cb1/VECD_Licensing_Guide_090208.pdf
• Este último lo han traducido mis compañeros de marketing y contiene una lista de escenarios de uso más frecuentes. Os lo dejo a continuación:

Saludos

David Cervigón

Posts anteriores:

• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Objetivo y consideraciones generales
• Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualización: Requerimientos: El Directorio Activo
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Requerimientos: Red
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Requerimientos: Almacenamiento
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Instalación de los hosts de Hyper-V y el cluster

Hola

Hasta el momento hemos tratado diferentes aspectos de los requisitos e instalación de Hyper-V. Con lo que tenemos hasta ahora ya podemos empezar a crear máquinas virtuales y a moverlas entre los hosts del cluster siempre que contemos con las consolas correspondientes instaladas en algún servidor Windows server 2008 R2 o un Windows 7 con las Remote Server Administration Tools (RSAT). En este post vamos a ver como realizar una instalación y configuración inicial de System Center Virtual Machine Manager 2008 R2. Por no llenarlo de pantallazos, he decidido simplemente publicar los mas relevantes. En este PDF he incluido todos.

La instalación de Virtual Machine Manager es bastante sencilla y rápida, y simplemente nos pedirá tomar una decisión por cada uno de los componentes de su arquitectura. Lo mas sencillo es instalar todo sobre el mismo servidor, pero pueden también instalarse por separado den diferentes equipos. Un servidor para la base de datos, otro para el servicio, otro para el portal, la consola de gestión en los clientes y file servers para la biblioteca. Los agentes son necesarios en  los host que se gestionarán, en el servidor que alberga el servicio, y en los servidores que conformen la biblioteca:

• Opción VMM Server.
  • La base de datos. VMM se apoya en una base de datos SQL. Durante el proceso de instalación nos solicitará elegir una instancia ya existente en la red, o podemos también usar el SQL Express  2005 SP3 que viene incluido en el producto. En este último caso, la instalación y configuración de SQL y la creación de la base de datos se realizan de manera completamente desatendida.

•  
  • La librería. Este componente de VMM es el encargado de mantener el conjunto de “ingredientes” que necesitaremos para desplegar nuevas máquinas virtuales, y constituye un almacén para plantillas y VMs que no es necesario que estén desplegadas en los hosts. ISOs, VHDs, perfiles de hardware, perfiles de software, scripts, etc. se alojan en file shares disponibles en la red, a los que se despliega el agente de Virtual Machine Manager. Es obligatorio que exista al menos una carpeta compartida en la máquina en la que se instala el servicio, por lo que tendremos que elegir donde reside su path por defecto, o proporcionar una carpeta compartida local ya existente. Si no se van a usar otro servidores para la biblioteca, y si VMM se esta montando virtualizado, hay que tener en cuenta que esa carpeta crecerá según vayamos definiendo plantillas, VHDs y máquinas virtuales. En estos casos es interesante asignar por pass-thought o por iSCSI una LUN del almacenamiento, para evitar que el VHD de la propia VM de Virtual Machine Manager crezca indiscriminadamente.

•  
  • El servicio de VMM. El motor principal de Virtual Machine Manager es este servicio, con su capa de PowerShell por encima. Aquí tenemos que decidir cuales son los puertos que se utilizarán (por defecto el 8100, el 80 y el 443) y especificar si correrá con la cuenta LocalSystem (defecto) o con una cuenta de usuario del directorio activo, que tendremos que hacer administradora local del equipo. Los criterios para elegir entre una u otra opción están listados en estos enlaces, pero será más fácil la integración con SCOM, y, sobre todo, habilitar la posibilidad de compartir ISOs remotamente (How to Enable Shared ISO Images for Hyper-V Virtual Machines in VMM) si se utiliza una cuenta del directorio activo.
    • When should I consider running my VMM Service by using a domain account?
    • Hardening the VMM Server

• Opción VMM Administrator Console: La instalación del servicio no incluye la consola gráfica de administración. Deberá instalarse separadamente sobre el servidor, si así se desea, y sobre los equipos cliente desde los cuales se quiera administrar Virtual Machine Manager. Lo único que nos pregunta la instalación es el puerto que se utilizará para conectarse con el servicio, que será el que hayamos especificado arriba. Al lanzar la consola también puede cambiarse, ya que se usa el clásico formato server:puerto:

• Opción VMM Self Service Portal: El Portal de Autoservicio se instala sobre un servidor que tenga instalado un IIS con los componentes que se citan como requisitos en el pantallazo de abajo. Tendremos que indicar cual es el servidor donde esta corriendo el servicio de VMM y su puerto, y especificar las opciones del servidor Web. Si, como es lo más frecuente, se encuentra con un site ya definido en el puerto 80, dará un error y tenemos tres opciones para salir del paso:
  • Usar otro puerto
  • Usar host headers, para lo que habrá que definir el nombre elegido como alias en el DNS
  • Si no se va a utilizar ese servidor Web para otros menesteres, simplemente borramos o desactivamos el Default Web Site

Llegados a este punto ya tenemos una instalación funcional de System Center Virtual Machine Manager:

Para poder empezar a hacer cosas con el, será necesario:

• Desplegar los agentes a los hosts con Hyper-V (http://blogs.technet.com/b/davidcervigon/archive/2008/11/21/instalaci-n-de-un-servidor-de-gesti-n-y-monitorizaci-n-de-entornos-f-sicos-y-virtuales-ii.aspx)
• Conectar con un VMware Virtual Center, si lo hubiera
• Definir los perfiles de hardware que tendrán nuestras máquinas virtuales
• Definir los perfiles de sistema operativo (esto representa ficheros de respuesta desatendidos de sysprep)
• Definir plantillas
• Definir Administradores delegados
• Definir Usuarios de Autoservicio
• Etc.etc.

Mas información (http://blogs.technet.com/b/davidcervigon/p/systemcenter.aspx)

• TechCenter de System Center Virtual Machine Manager 2008 and Virtual Machine Manager 2008 R2

Saludos

David Cervigón

Hola

Al igual que en las versiones anteriores, Microsoft Hyper-V Server 2012 tiene exactamente las mismas funcionalidades y máximos de escalabilidad que el role de Hyper-V incluido en Windows Server 2012 Standard o Datacenter, y puede descargarse de manera gratuita desde aquí:

• http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx 

Como dice en la página anterior, esta será la versión de Hyper-V a utilizar en el caso de que no nos vayamos a beneficiar de los derechos virtualización incluidos en la propia licencia de Windows Server 2012. Los tres casos más típicos serían:

• Como base de despliegues de VDI, donde las licencias necesarias van asignadas al dispositivo de acceso en forma de Windows SA o VDA
• Virtualización de Linux, donde no son necesarias ningún tipo de licencias de Microsoft
• Escenarios de consolidación de servidores donde no sean necesarias nuevas licencias de Windows Server, y donde las licencias existentes permitan su movilidad a otro servidor (es decir, no OEM)

El proceso de instalación es muy similar al de un Windows Server 2012, con la diferencia de que el role de Hyper-V ya esta activado por defecto al final de la misma y solo nos queda el proceso de ponerle nombre al servidor, configurarle la red, el escritorio y administración remotas, meterlo o no en el dominio, etc.

El resultado final es este. Teníamos nuestras dudas de que se hubiera incluido el Server Manager para facilitar la administración, pero no, tenemos la tradicional interfaz de línea de comandos y el SCONFIG. Eso si, podemos lanzar Powershell donde tendremos a nuestra disposición todos los nuevos cmdlets de Hyper-V:

Obviamente, una vez instalado y configurado mínimamente el servidor, pasaremos a gestionarlo remotamente, con las consolas del Hyper-V Manager y el Failover Cluster Manager, o preferiblemente de System Center Virtual Machine Manager.

Saludos

David Cervigón