Durante los últimos años he estado involucrado en mayor o menor medida en diferentes proyectos dirigidos a ofrecer “escritorios en la nube” o plataformas de “Desktop as a Service”. Si bien aplicar un modelo de pago por uso es particularmente complicado en un entorno en el que hay que considerar cosas tan diversas como dispositivos de acceso, datos de usuario, aplicaciones varias, sistemas operativos, servidores, hypervisores, almacenamiento, redes, etc. y tan poco cuantificables como son operaciones y mantenimientos, todo esto ha chocado siempre con un pequeño pero importante matiz legal. Correr Windows Cliente, es decir, Windows XP/Vista/7/8/8.1 sobre una infraestructura compartida entre varios clientes es simplemente ilegal. Dicho de otra manera Windows Client (o la famosa VDA) no se puede adquirir a través de contratos SPLA (Service Provider License Agreement) que es lo mismo que decir que no se puede utilizar en un modelo de pago por uso. Nada impide que te montes una infraestructura de VDI en tu casa, nada impide que montes una infraestructura de VDI dedicada para un tercero, pero no puedes montar una infraestructura de VDI que vaya a ser compartida por diferentes clientes. Y esto obviamente afecta a cualquier Hoster/Service Provider/Cloud Provider, lo que incluye al propio Windows Azure.

Por otro lado, sabemos que existe una alternativa mucho más barata y escalable de ofrecer Escritorios Virtuales y/o Aplicaciones Remotas a usuarios que los vayan a consumir desde diferentes tipos de dispositivos que una despliegue de VDI. Los clásicos Terminal Services / Remote Dektop Services, que además mediante la característica de “Desktop Experience” pueden disfrazarse perfectamente como sus versiones equivalentes de Windows Client (es decir Windows Server 2008 R2 –> Windows 7, Windows Server 2012 –> Windows 8, y Windows Server 2012 R2 –> Windows 8.1). E incluso pueden usarse en un modelo muy similar a un pool de VDI, con un único usuario por escritorio. Esto es además curiosamente mas barato desde el punto de vista de licenciamiento, y por último es perfectamente legal en entornos de hosting compartido a través de las licencias de SPLA de Windows Server y de la CAL de Remote Desktop Services (RDS SAL).

Todo esto esta mucho mejor explicado aquí:

• Providing Microsoft Desktop as a Service licensing guide

Por último, Microsoft anunció hace unas semanas coincidiendo con en lanzamiento de Windows Server 2012 R2 que las RDSCALs adquiridas a través de los diferentes contratos de volumen con Software Assurance otorgan derechos de uso de este tipo de escritorios no solamente en local sino también en la nube.

Tras estos antecedentes, se trata entonces de montar un escenario completo de escritorios virtuales basados en RDS/Windows Server directamente sobre los servicios de IaaS en Windows Azure. Básicamente la arquitectura no cambia mucho con respecto a cómo se haría en una infraestructura propia, con la salvedad de que nos despreocupamos del montaje de toda la plataforma de virtualización y nos aprovechamos de un modelo de facturación que puede llegar al pago por minuto de uso. Los escenarios de aplicación pueden llegar a ser extraordinariamente variados.

La solución está descrita aquí:

• Con una solución 100% nativa Microsoft:

• Windows Azure Desktop Hosting Reference Architecture Guide

• Con Citrix XenApp
• Design Guide for Service Provider hosted desktops on Windows Azure
• Design Guide for XenDesktop 7 on Windows Azure (esta es un curioso caso particular donde los servidores de infraestructura están en la nube, y los pools de VDI on premise)

• Con Dell vWorkspace:

• https://microsoftplatform.blogspot.com.es/2013/09/running-dell-vworkspace-in-windows-azure.HTML
• https://www.microsoftentrepreneur.com/operating-dell-vworkspace-in-windows-azure/

Sobre la viabilidad práctica de este tipo de arquitecturas para esta solución, los principales factores a tener en cuenta son que están orientadas sobre todo para el consumo de escritorios y/o aplicaciones a través de Internet, y por supuesto las dependencias que tengan las aplicaciones que vayan a correr aquí con los servicios de back-end. Aquí tendríamos dos escenarios, con una gran variedad de posibles puntos medios:

• Solución “autocontenida”: Es decir, ya que nos embarcamos nos subimos el back-end también a la red virtual de Azure. Frontales, aplicaciones, ficheros, bases de datos funcionan independientemente con pocas o ninguna dependencia de los servicios on-premise.
• Solución conectada mediante una VPN. En este caso, las aplicaciones corriendo en los escritorios virtuales se conectan con el back-en a través de una VPN que conecta la red virtual de Azure con on-premise. Obviamente esto será viable solamente si los requisitos de ancho de banda y latencias son los adecuados, y si el numero de usuarios que hacen uso de ellos de forma simultánea no es elevado. Y lógicamente esto permite que el usuario acceda a la granja de escritorios y aplicaciones desde la propia intranet, a través del túnel, lo cual quizás no tenga demasiado sentido.

Por tanto, y en resumen:

• Ventajas:
• Legal
• Fácil de desplegar
• Capacidad de despliegue en diferentes localizaciones geográficas dependiendo de la ubicación de los usuarios
• Geo-tolerancia a fallos
• Pago por minuto de los recursos
• Independencia de las redes propias o anchos de banda
• Inconvenientes:
• Peor escalabilidad que una arquitectura equivalente on premise
• Poco viable para aplicaciones con fuertes dependencias del back-end
• Menor flexibilidad o restricciones en los modelos de despliegue
• Posibles limitaciones legales o en la soportabilidad  de algunas aplicaciones

Saludos

David Cervigón

Coincidiendo con el lanzamiento de las últimas versiones de Windows 8.1 y Windows Server 2012 R2, Microsoft ha liberado por primera vez un cliente de Remote Desktop Services (RDP) para sistemas operativos no Microsoft, en particular para IOS, Mac OSX y Android.

Tenéis el anuncio aquí:

• https://blogs.msdn.com/b/rds/archive/2013/10/21/microsoft-remote-desktop-apps-for-ios-mac-os-x-and-android-available-for-download.aspx

Y las apps pueden descargar desde las correspondientes stores:

• https://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417 
• https://play.google.com/store/apps/details?id=com.microsoft.rdc.Android (como veréis, muy similar en aspecto a la propia App “Modern UI” que se incluye en Windows 8.1 y Windows 8.1 RT)

Por tanto, queda únicamente por resolver el asunto del Linux. En este ámbito existen varias soluciones que principalmente descansan en las implementaciones de rdesktop (como sería el caso de KRDC, Gnome –RDP) y FreeRDP (Remmina, Vinagre, etc.). Al final, estos desarrollos suelen estar desfasadas en una o dos versiones con respecto a la ultima, y en ocasiones no incluyen todas las funcionalidades posibles (RemoteFX, RD Gateway…). Son los desarrollos comerciales los que si que lo hacen, generalmente dentro del mundo de soluciones completas de virtualización del escritorio o Thin/Zero Clients basados en diferentes sabores de Linux.

Saludos

David Cervigón

Para todos aquellos que os gusta aprender tocando:

Hands On Labs de Windows Server 2012 R2

• Desired State Configuration with Windows Server 2012 R2
• Enhancements with Windows Server 2012 R2 Hyper-v Replica
• Windows Server 2012 R2 - Enabling Windows Server Work Folders
• Windows Server 2012 R2: Implementing Claims-Aware Applications
• Exploring Hyper-V Server 2012 R2
• Network Automation using IP Address Management (IPAM)
• Windows Server 2012 R2 – Storage Infrastructure
• Introduction to Windows Server 2012 R2 Essentials
• Windows Server 2012 R2 – Configuring and Managing Servers
• Windows Server 2012 R2 – Windows PowerShell Desired State Configuration
• Windows Server 2012 R2 - Windows PowerShell Fundamentals
• Windows Server 2012 R2– RemoteApp and Remote Desktops
• Windows Server 2012 R2 - Windows Server Update Services

Hands On Labs de System Center Virtual Machine Manager 2012 R2

• Configuring Networking with System Center Virtual Machine Manager 2012 R2
• Storage Management with System Center Virtual Machine Manager 2012 R2
• Managing Linux Servers with System Center 2012 R2
• Managing your Datacenter devices with Windows Server and System Center 2012 R2

Saludos

David Cervigón

Al actualizar la App de la Posterpedia, veo que se ha publicado el poster de arquitectura de Hyper-V 2012 R2 que esta disponible aquí:

• https://www.microsoft.com/en-us/download/details.aspx?id=40732 

Como cada vez va quedando más y mas denso, han liberado también mini-posters individuales para cada una de las seis secciones que se aprecian en la imagen anterior y que están disponibles también en el enlace de descarga anterior:

• Generation 2 Virtual Machines
• Hyper-V and Failover Clustering
• Hyper-V Storage
• Hyper-V Virtual Hard Disk Sharing
• Live Migration
• Session Modes
• Upgrading Your Private Cloud

Saludos

David Cervigón

Se pueden descargar de aquí:

• https://www.microsoft.com/en-us/download/details.aspx?id=39296

Con ellas se pueden administrar servidores Windows Server 2012 y Windows Server 2012 R2 desde clientes Windows 8.1

Saludos

David Cervigón

Me preguntan por ahí si esto es factible. Ciertamente, es algo que no creía yo que iba a llegar a ver en mi carrera profesional. Esto de la nube nos empieza a dejar cosas sorprendentes.

A modo de recapitulación, Microsoft y Oracle llegan a un acuerdo por el cual Microsoft ofrece el software de Oracle en Windows Azure, y Oracle soporte oficialmente su software no solamente sobre Azure sino también sobre Hyper-V:

• https://blogs.oracle.com/cloud/entry/oracle_and_microsoft_join_forces
• https://www.oracle.com/technetwork/topics/cloud/faq-1963009.HTML

A modo de prueba de concepto rápida:

1.- Creamos un VM en Azure con Oracle Linux (podéis animaros a hacerlo igualmente con cualquier otra)

2.- Dejamos que la máquina se aprovisione y se arranque. Accedemos al panel y cuando esté lista, la apagamos y nos quedamos con el path a su disco virtual (en la siguiente imagen, abajo a la derecha)

3.- Usando la PowerShell de Windows Azure, que habremos tenido que configurar convenientemente para que apunte a nuestra subscripción, usamos el cmdlet Save-AzureVHD para descargárnoslo a local.

cosa que en mi caso ha hecho en unos 18 minutos (10 Gb de fichero a través de una línea de fibra a 50Mb)

4.- Copiamos el fichero al almacenamiento de un servidor/cluster de Hyper-V y componemos una nueva VM a la que enchufamos el VHD

5.- Arrancamos y entramos con el mismo usuario que pusimos cuando hicimos la provisión sobre Azure en el primer paso

6.- La personalizamos a voluntad. Por ejemplo, lo mas inmediato será la configuración IP. Por defecto lo intentará por DHCP, cosa que en nuestro caso ha logrado sin problemas

Lógicamente, el camino inverso también es posible. Hay que ser cuidadoso en algunos aspectos a la hora de hacer la preparación de los discos virtuales de modo que la VM que se derive de ellos funcione ahí arriba, pero está todo documentado aquí:

• Creating and Uploading a Virtual Hard Disk that Contains the Windows Server Operating System
• Creating and Uploading a Virtual Hard Disk that Contains the Linux Operating System

Saludos

David Cervigón

El pasado viernes 18 de octubre se llevó a cabo el lanzamiento/anuncio conjunto de Windows Server 2012 R2, System Center 2012 R2 y Windows 8.1. El software se puede descargar desde MSDN y la Web de Licencias por Volumen, así como las versiones de evaluación directamente desde la Web

Descarga del Software de Evaluación:

• Windows Server 2012 R2: https://technet.microsoft.com/en-US/evalcenter/dn205286.aspx
• System Center 2012 R2: https://technet.microsoft.com/en-Us/evalcenter/dn205295
• Windows 8.1 Enterprise: https://technet.microsoft.com/en-us/evalcenter/hh699156.aspx

Resulta complicado hacer un resumen de todas las novedades de todos los productos incluidos en el lanzamiento, e incluso hacerlo a nivel de roles o funcionalidades individuales como podría ser Hyper-V 2012 R2, del que ya hablaremos en breve. Os dejo por tanto los enlaces a los puntos principales de información, formación y documentación, a partir de los cuales se abre toda la maraña de enlaces al respecto

Información / Formación:

• Virtual Labs: https://technet.microsoft.com/en-us/virtuallabs
• Resumen de novedades en cada uno de los roles de Windows Server 2012 R2: https://technet.microsoft.com/library/dn250019
• Resumen de novedades en cada uno de los roles de Windows Server 2012 R2 en Virtual Academy: https://www.microsoftvirtualacademy.com/training-courses/new-windows-server-2012-r2-jump-start#fbid=mhpCCbxSVpV
• Resumen de novedades de Windows 8.1: https://technet.microsoft.com/en-us/windows/dn140266

Documentación:

• Windows Server 2012 R2 en la TechNet Library: Windows Server 2012 R2 and Windows Server 2012
• System Center 2012 R2 en la TechNet Library: https://technet.microsoft.com/en-us/library/hh546785.aspx
• Windows 8.1 en la TechNet Library: https://technet.microsoft.com/en-us/library/hh832030.aspx

Saludos

David Cervigón

Alguien se ha entretenido en coleccionarlos y publicarlos en esta Wiki de TechNet

• E-Book Gallery for Microsoft Technologies

Saludos

David Cervigón

Aprovechando la efeméride del 12/12/12, haremos un evento que hemos llamado “Las 12 horas de Datacenter 2012”, donde, como su nombre indica, estaremos haciendo sesiones desde las 10:00 hasta las 22:00, con temas relacionados con Windows Server 2012, System Center 2012, SQL Server 2012 y Windows Azure

El evento es virtual y gratuito. Os podéis ver la agenda y registraros aquí:

• Las 12 Horas De DATACENTER 2012

Saludos

David Cervigón

En Windows Server 2012 podemos elegir en el momento de la instalación si queremos un servidor en modo “Server Core” o con toda la interfaz gráfica:

Sin embargo, al contrario de lo que sucedía en el caso de su antecesor Windows Server 2008 R2, la elección no nos compromete y se puede cambiar de un modo a otro a posteriori simplemente agregando o quitando características, y además tenemos un modo intermedio, conocido como MinShell (estrictamente Minimal Server Interface), en el que tendremos disponibles el Server Manager y las consolas de gestión pero no el resto de la GUI:

Además, también tenemos a la herramienta SCONFIG, no solamente en server Core, sino también en MinShell y con el escritorio completo:

Para más información sobre que incluye cada opción podéis consultar la tabla del final de esta página: https://technet.microsoft.com/en-us/library/hh831786(v=ws.11).aspx.

Vamos a ver como cambiar de un modo a otro, cómodamente con el Server Manager, o por línea de comando mediante Powershell o el Deployment Image Service Manager (DISM):

Usando el Server Manager

Mediante el Server Manager podemos hacer los cambios simplemente agregando o quitando características, bien sobre el servidor local, bien en remoto:

• De Server con GUI a MinShell: Desmarcamos “Server Graphical Shell”
• De Server con GUi a Server Core: Desmarcamos “Server Graphical Shell” y “Graphical Management Tools and Infrastructure”
• De MinShell a Server Core: Desmarcamos “Graphical Management Tools and Infrastructure” (tendremos “Server Graphical Shell” ya desmarcado)
• De MinShell a Server con GUI: Marcamos “Server Graphical Shell”
• De Server Core a MinShell: Marcamos “Graphical Management Tools and Infrastructure”
• De Server Core a Server con GUI: Marcamos “Server Graphical Shell” y “Graphical Management Tools and Infrastructure”

Debido a que Server Core no tiene el server Manager, no podremos realizar los dos últimos desde el propio servidor objetivo, pero si remotamente desde cualquier otro equipo que tenga las herramientas de gestión instaladas.

Mediante DISM:

Para hacer los cambios anteriores por línea de comandos tenemos que saber cuales son los nombres de los paquetes de Windows equivalentes a las opciones que se muestran en el Server Manager:

• Graphical Management Tools and Infrastructure –->Server-Gui-Mgmt-Infra
• Server Graphical Shell –> Server-Gui-Mgmt

Con lo que nos quedaría:

• De Server con GUI a MinShell:
• DISM /Online /disable-feature /featurename:Server-Gui-Mgmt
• De Server con GUi a Server Core:
• DISM /Online /disable-feature /featurename:Server-Gui-Mgmt /featurename:Server-Gui-Mgmt-Infra
• De MinShell a Server Core:
• DISM /Online /disable-feature /featurename:Server-Gui-Mgmt-Infra
• De MinShell a Server con GUI:
• DISM /Online /enable-feature:Server-Gui-Mgmt
• De Server Core a MinShell:
• DISM /Online /enable-feature:Server-Gui-Mgmt-Infra
• De Server Core a Server con GUI:
• DISM /Online /enable-feature:Server-Gui-Mgmt-Infra /enable-feature:Server-Gui-Mgmt

Mediante PowerShell:

Muy similar al método anterior, pero usando los cmdlets Install-WindowsFeature y Uninstall-WindowsFeature, o sus alias Add-WindowsFeature y Remove-WindowsFeature. El nombre de los módulos es igual que en el caso anterior y si la operación implica a mas de uno simplemente los separaremos por comas.

• De Server con GUI a MinShell:
• Uninstall-WindowsFeature Server-Gui-Mgmt –Restart
• De Server con GUi a Server Core:
• Uninstall-WindowsFeature Server-Gui-Mgmt,,Gui-Mgmt-Infra –Restart
• De MinShell a Server Core:
• Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –Restart
• De MinShell a Server con GUI:
• Install-WindowsFeature Server-Gui-Mgmt –Restart
• De Server Core a MinShell:
• Install-WindowsFeature Server-Gui-Mgmt-Infra –Restart
• De Server Core a Server con GUI:
• Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Mgmt –Restart

¿Cual opción elegir?

Las diferencias entre las tres opciones se reducen a dos aspectos. La gestionabilidad local (que no remota) del servidor y la compatibilidad de algunas aplicaciones que pudiéramos necesitar instalar en el, y el thumprint de la instalación. Esto último más que al rendimiento afecta sobre todo a la necesidad de actualizar los componentes que agregamos o eliminamos (por poner un ejemplo, Internet Explorer). Sin embargo, dado que podemos cambiar de un modo a otro, la elección no es tan crítica como en la versión anterior.

Esto es una mera opinión personal:

• Server con GUI: Para pruebas, formación, generación de maquetas, toma de contacto con nuevo hardware del que no conozcamos completamente todos sus componentes, escenarios de solución de problemas complejos, o, simplemente, como estación avanzada de trabajo
• Server Core: Despliegue de grandes plataformas homogéneas y estandarizadas, generalmente automatizadas, cargas de trabajo muy especializadas y estables, servidores que requieran de un uptime continuado debido a que su carga de trabajo no puede ser desplazada a otro servidor, etc.
• MinShell: en escenarios en los que la costumbre nos arrastre a hacer conexiones remotas a cada servidor para ejecutar las consolas de administración localmente, pero donde no necesitemos correr otro tipo de aplicaciones. En estos casos eliminar posibles vectores de ataque y reducir los ciclos de actualizaciones al máximo puede resultar muy interesante.

Y, ¿qué es eso de Desktop Experience?

No hemos cubierto esta opción que se usa, siempre por encima de la “Server con GUI”, principalmente en dos escenarios. El primero, mencionado anteriormente, es cuando queremos usar un Windows Server como estación de trabajo, y queremos tener una experiencia de Windows Cliente, en este caso de Windows 8. El otro, muy cercano al anterior, es el tradicional de Remote Desktop Services, donde los usuarios se van a conectar a un servidor de sesiones, o a una colección (granja) de ellos, con experiencia de escritorio completo, y les queremos dar la experiencia de un Windows 8 completo, con su Aero, su Store, etc.. Activando esta opción, nos queda una cosa así:

Saludos

David Cervigón