Hola
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: http://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:
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:
Server-Gui-Mgmt-Infra
Con lo que nos quedaría:
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.
Gui-Mgmt-Infra –Restart
Server-Gui-Mgmt-Infra –Restart
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:
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
El próximo jueves 22/11/2012, en el Microsoft Techday que se celebrará en el Teatro Goya de Madrid, Fernando, Miguel y yo estaremos una hora y media en el escenario haciendo demos de Windows Server 2012, una tras otra sin parar.
La dirección del teatro Goya y el registro gratuito los podéis encontrar aquí:
Os esperamos
Todos los posters de arquitectura de Windows Server, Exchange, SharePoint, Lync, etc. en una única aplicación para Windows 8, y con enlaces a la documentación de TechNet y el enlace para su descarga
Os lo podéis descargar de aquí:
y el eBook “Building Hybrid Applications in the Cloud on Windows Azure” desde aquí:
Lamentablemente este ultimo no incluye todavía los servicios de Virtual Machines y Private Networks
Hace algunas semanas se liberó el Microsoft Virtual Machine Converter, un “Solution Accelerator” que nos permite de migrar de manera sencilla máquinas virtuales de hosts VMware a host Hyper-V. Puede obtenerse mas información y los binarios aquí:
Como se puede observar, hay dos sabores de la solución, ambos con idéntico tamaño de descarga (la friolera de 4.3 MB). Una solución stand-alone, y un plug-in para VMware vCenter. Ninguna de ellas tiene como requisito System Center Virtual Machine Manager, que por supuesto podemos seguir usando para estas tareas. Encontrareis además una guía de uso mejor y más extensa que nos podemos permitir aquí.
Vamos a ver cómo funcionan:
Microsoft Virtual Machine Converter Solution Accelerator
Una vez descargado e instalado, lo lanzamos y seguimos el asistente. Nos avisa de los sistemas operativos que pueden convertirse usando este método y nos pide que nos conectemos contra un vCenter, o también existe la posibilidad de hacerlo directamente contra un ESX, ESXi
Se enumeran las máquinas virtuales existentes y seleccionamos nuestro objetivo
Se nos solicitan unas credenciales con permisos de administrador en el Guest, y que queremos hacer con las máquinas virtuales original y destino. Es importante mencionar que la maquina original no desaparece, por lo que el proceso no es en absoluto destructivo
Lo siguiente que se nos pide es una carpeta local donde descargarse el VMDK y convertirlo a VHD, y también el servidor destino de Hyper-V, al que le copiaremos el fichero ya convertido a una carpeta compartida:
un resumen de lo que vamos a hacer por si queremos cambiar algo:
y a trabajar:
Como se puede ver en el pantallazo anterior, el proceso es muy similar a como lo haríamos a mano o dese Virtual Machine Manager. Se saca una snapshot de la VM original (para revertirse al final del proceso), se desinstalan las VMware Tools, se copia el VMDK al equipo donde esta corriendo la herramienta, se convierte el disco y se inyectan los componentes de integración y se despliega ese VHD ya convertido al host de Hyper-V elegido por red. Una vez terminado el proceso se crea una a partir de el (o ellos, si hay mas de un disco) una VM con las mismas características que la original. Tras todo esto se revierten los cambios de la máquina original y se dejan apagadas o encendidas según hayamos elegido.
¿Qué sucede si tengo muchas máquinas virtuales que migrar, o quiero que el proceso de conversión forma parte de un flujo de trabajo más amplio?. No hay problema. La herramienta soporta scripting:
Microsoft Virtual Machine Converter Plug-in for VMware vSphere Client
Este plug-in hay que instalarlo en un equipo donde tengamos ya el cliente de vSphere. Al hacerlo, se registra como tal:
y a partir de ese momento nos sale la opción de migrar la máquina virtual al hacer clic con el botón derecho sobre ella:
Tras ello se lanza el proceso anterior, pero se nos ahorran los pasos de elegir el servidor de vCenter o los host con ESX/ESXi
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í:
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:
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.
Una excelente manera de generar VHDs con una imagen limpia de sistema operativo para usarlos como base de máquinas virtuales o incluso de equipos físicos utilizando “Boot from VHD” es utilizar la herramienta Convert-WindowsImage.ps1 que podéis descargar desde aquí:
Esta herramienta es la heredera para Windows 8 y Windows Server 2012 de Wim2VHD, que tenia una funcionalidad muy similar y que se basa en el mismo principio. El fichero install.wim que se incluye en la carpeta \sources de todo medio de instalación de Windows desde los tiempos de Windows Vista y Windows Server 2008 contiene una o varias imágenes genéricas del Sistema Operativo, que es lo que se vuelca sobre el disco/partición/volumen de destino del equipo que estamos instalando. Ese volcado se lleva a cabo durante esa aburrida fase de la instalación en la que se copian y expanden los ficheros, que es la que nos vamos a ahorrar, entre otras, usando esta técnica. Convert-WindowsImage nos permite generar un VHD o VHDX del tamaño y características que queramos, y aplicarle la imagen de Windows deseada. De ese modo, al arrancar un equipo, físico o virtual, desde ese disco virtual iremos directamente a la fase de personalización del Sistema Operativo, que podemos automatizar también usando un fichero de respuestas.
Aunque el script de Powershell esta pensado para ejecutarse por línea de comandos con sus parámetros correspondientes, tiene uno muy cómodo (-ShowUI) que nos lanza una interfaz gráfica
Vamos a rellenar los campos con un ejemplo. Crearemos un VHDX, de tipo dinámico y con 20 Gb de tamaño, con una instalación de Windows Server 2012 Standard. Como podemos ver, dentro del install.wim de un DVD/ISO de Windows Server 2012 tenemos realmente cuatro imágenes, correspondientes a las ediciones de Standard y Datacenter en sus modos de instalación Full y Server Core. Vamos a aprovechar también para personalizarlo un poco, especificando la contraseña del administrador, la zona horaria, configuración regional la distribución del teclado, o nuestra clave de producto, de modo que nos ahorremos contestar a todo eso al arrancar posteriormente. Podríamos también darle nombre al servidor, meterlo en el dominio, agregarle roles y funcionalidades, habilitar el escritorio remoto, configurar el firewall, etc. Sin embargo, vamos a dejarlo en un punto que nos permita usarlo, por ejemplo como disco padre de diferentes máquinas virtuales o como embrión de una plantilla genérica de máquina virtual:
Abrimos la imagen de Windows Server 2012 del DVD/ISO y agregamos los componentes Microsoft-Windows-Shell-Setup y Microsoft-Windows-Internation-Core que es donde encontraremos las opciones mencionadas arriba:
Con lo que nos quedaría (poned vuestro Product Key, datos de organizacion y los Locales que correspondan a vuestra región si es diferente a España y Español – Internacional):
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ProductKey>XXXXX-XXXXX-XXXXX-XXXXX-XXXXX</ProductKey>
<RegisteredOwner>Microsoft</RegisteredOwner>
<RegisteredOrganization>Microsoft</RegisteredOrganization>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<InputLocale>es-ES</InputLocale>
<SystemLocale>es-ES</SystemLocale>
<UserLocale>es-ES</UserLocale>
<UserAccounts>
<AdministratorPassword>
<Value>VQBBAEIAQQBBAEgATQBBAGMAdwBCADMAQQBEAEEAQQBjAGcAQgBrAEEAQwA0AEEAUQB3AEEAdwBBAEcAMABBAGMAQQBCAHMAQQBLAHcAZwBhAGcAQgBBAEEARQBFAEEAWgBBAEIAdABBAEcAawBBAGIAZwBCAHAAQQBIAE0AQQBkAEEAQgB5AEEARwBFAEEAZABBAEIAdgBBAEgASQBBAFUAQQBCAGgAQQBIAE0AQQBjAHcAQgAzAEEARwA4AEEAYwBnAEIAawBBAEEAPQA9AEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>
<PlainText>false</PlainText>
</AdministratorPassword>
</UserAccounts>
<OOBE>
<HideEULAPage>true</HideEULAPage>
</OOBE>
<cpi:offlineImage cpi:source="wim:d:/sources/install.wim#Windows Server 2012 SERVERDATACENTER" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
Ya podemos generar el VHDX y ver como el script termina el trabajo en la ventana de Powershell:
Y el resultado. Una máquina virtual generada sobre ese VHDX que nos arranca directamente aquí:
NOTA: El script parece tener un bug que produce que no se inyecte el fichero unattend.xml dentro del disco que se genera cuando se especifica dicha opción desde la interfaz gráfica. Tenemos dos workarounds:
Se ha publicado la guía de optimización de rendimiento de Windows Server 2012 y se puede descargar desde aquí:
Dentro podréis encontrar las consideraciones y parámetros de configuración que pueden tener impacto en el rendimiento de algunas cargas de trabajo específicas, y también ofrece pistas de los contadores y objetos del sistema que debemos monitorizar para comprobar si estamos dentro de unos márgenes de rendimiento aceptables para los recursos físicos existentes.
Esta es la tabla de contenidos:
y para los que gocéis de la suma dos tesoros que son tiempo y curiosidad, os recomiendo subir un par de carpetas mas arriba en el site y curiosear toda la documentación que se encuentra en http://msdn.microsoft.com/library/windows/hardware/