Windows Server 2012 Server Core

Una de las características más ignoradas de Windows Server 2008 y 2008R2 viene con muchos cambios en Windows Server 2012, esta propiedad es la posibilidad de instalar el sistema operativo como Server Core.
Server Core es una forma de instalación que permite utilizar el SO sin interface gráfica, solo por línea de comando. Esto posibilita a utilizar un SO con menos consumo de memoria, con menos superficie de ataque y con menos necesidad de reinicios para aplicar parches.

Estas ventajas son acompañadas con algunas desventajas, como la imposibilidad de administrar el equipo desde una consola MMC local, solo una lista reducida de roles pueden ejecutarse en un Server Core y en caso de necesitar cambiar a una instalación Full, la única manera posible de hacerlo es reinstalando el SO.

Algunos cambios en Windows Server 2012 incluyen:

1ro Una mayor cantidad de roles pueden instalarse en Server Core.

2do Se podrá instalar aplicaciones de servidor como SQL Server 2012.

3ro El cambio de modo Full a Server Core y viceversa se puede hacer con un solo comando de Power-Shell: Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –Restart  (Figura 1)

 Figura 1

4to La posibilidad de utilizar un nuevo estadio llamada MSI (Minimal Server Interface), el cual permitirá ejecutar MMC pero no Windows Explorer ni Internet Explorer (ni otras herramientas implementadas como extensiones de la Shell). También se podrá pasar de este modo de instalación a Core o Full con el mismo comando Power-Shell, donde se puede indicar que componentes remover o a través de Server Manager (Figura 2)

 Figura 2

Los roles soportados en una instalación Server Core incluyen:

Active Directory Certificate Services
Active Directory Domain Services
Active Directory Lightweight Directory Services (AD LDS)
Active Directory Rights Management
ServerDHCP
ServerDNS
ServerFile and Storage Services (incluido File Server Resource Manager)
Hyper-V
Print and Document Services
Remote Desktop Services sub roles

• Remote Desktop Connection
• BrokerRemote Desktop Licensing
• Remote Desktop Virtualization Host
• Routing and Remote Access Server

Streaming Media Services (disponible como una descarga por separado)
Web Server (con un sub-set de ASP.NET)
Windows Server Update Server

Por último podemos afirmar que Server Core es ideal tanto para grandes equipos donde se ejecutan pesadas cargas de trabajo como servidores de VDI, Hyper-V, SQL o Media Server, al igual que lo es para pequeños equipos en donde debemos ejecutar solamente un AD DS, DNS o File Server. Con estas nuevas características seguramente mas administradores se animaran a utilizarlo.

Aviso con tiempo

Para que a nadie le sorprenda la noticia, el 8 de Abril de 2014 se termina el soporte de Windows XP. Algunos pueden creer que 24 meses es mucho tiempo, pero es el promedio de un proyecto de migración de estaciones de trabajo en un ambiente empresarial.

¡Hoy mismo hay que comenzar a preparar la migración!

-Compatibilidad de aplicaciones

-Hardware

-Perfiles de usuario

-Software de terceros

Hay mucho para hacer antes de migrar, después no digan que no les avise.

Para aprender mas...

Deploy de Windows 7 en Technet

El Primer DC Window Server 8 (Ahora Windows Server 2012)

Actualización (11 de Julio de 2013): En este articulo encontraras información útil orientada a crear un nuevo Forest con Windows Server 2012. El blog cuenta con un articulo mas nuevo que describe como actualizar el Forest y Dominio para Windows Server 2012 y otro sobre las opciones de instalación de Domain Controller que tiene Windows Server 2012.


Windows Server 8 introduce una nueva generación de servicio de AD llamada “Simplified Administration”. Como todos los cambios, esta nueva versión nos hará modificar la forma en la que realizamos algunas tareas. Desde los inicios de AD (con Windows 2000 Server), cuando necesitábamos promover un equipo para que sea DC, utilizábamos DCPromo.exe. Con Windows Server 8, DCPromo.exe pasa a estar des-enfatizado, lo que significa que no es el método preferido para crear un DC y que no estará presente en la próxima versión de Windows Sever. Como consecuencia, la única forma de utilizar DCpromo.exe con Windows Server 8 es con un archivo de respuesta, igual que si quisiéramos instalar un DC en un Server Core en Windows Server 2008R2.

La forma recomendada de instalar un DC es hacerlo a través de Power-Shell, por lo tanto, lo primero que debemos hacer es cargar el módulo de AD DS en Power-Shell (Figura 1).

Fig 1

Install-WindowsFeatures ad-domain-services –IncludeManagementTools

Opcionalmente podemos cargar las herramientas de administración.

Ahora ya estamos listos para configurar un DC desde Power-Shell, pero antes como paso opcional podemos especificar el comando con “-WhatIf” para tener un informe de lo que realizará la operación (Figura 2).

Fig 2

Install-ADDSDomainController –DomainName main.labemd.com –installdns –SiteName MainOffice -WhatIf

En la figura 2 se puede ver que el Nuevo DC será GC, DNS, no será RODC, se instalara en el site MainOffice, etc. Cuando estamos listos seguros que esas son las opciones que queremos utilizar para nuestro nuevo DC, podemos ejecutar el comando de instalación.

Install-ADDSDomainController –Credential (get-credential) –DomainName main.labemd.com installdns –SiteName MainOffice

En este caso quitamos la opción “-WhatIf” y agregamos “-Credential (get-credential)” para poder especificar de forma interactiva una cuenta de usuario con permisos suficientes (Figura 3). Este parámetro solo es necesario si estamos autenticados con un usuario que no cuenta con los permisos necesarios y debemos utilizar una cuenta alternativa.

Fig 3

El proceso también nos preguntara por la password de Administrador para DSRM (Llamada Safe Mode Administrator Password) y nos pide una confirmación final (Figura 4).

 Fig 4

Tal vez alguno se pregunte si es necesario actualizar el Schema, o el Dominio, ¿Como se si estoy ejecutando el comando en el equipo que tiene el FSMO correspondiente?, etc. En Windows Server 8 AD DS realiza todas esas tareas en una verificación previa (Figura 5). De ser necesario AD DS, realiza un Forest Prep, Domain Prep, se conecta a los FSMO correspondientes, etc. Si el administrador lo decide, estas tareas aún pueden ser ejecutadas en forma separada.

Fig 5

En resumen:

¿Puedo utilizar DCPromo.exe en Windows Server 8? Solo en forma desatendida con un archivo de respuesta como si fuese una instalación de un DC en un Windows Server 2008R2 Server Core.

¿Cuál es la forma preferida de instalar un DC en Windows Server 8? Utilizando Power-Shell con “Install-ADDSDomainController”. De esta forma se puede instalar en un equipo con instalación full, con instalación Server Core o con MSI (Minimal Server Interface, que es una nueva forma de  instalación en Windows Server 8).

¿Existe alguna herramienta gráfica para instalar un DC? Si, puede instalarse con Server Manager pero solo en equipos con instalación Full o MSI. Server Manager no puede utilizarse en equipos con instalación Server Core.

Usando DCpromo.exe en un Server Core

Desde hace más de 10 años la forma de promocionar un DC es utilizando Dcpromo.exe. Este comando nos muestra un asistente gráfico que nos guía para configurar el nuevo DC. Con Windows Server 2008 y versiones posteriores tenemos la posibilidad de instalar un servidor con la opción de Server Core, la cual no tiene interface gráfica, por lo tanto, cuando utilizamos DCpromo no podemos visualizar el asistente gráfico.

Para instalar un DC en Server Core debemos utilizar DCpromo junto con un archivo de respuesta para que se realice toda la configuración de forma desatendida. La creación de un archivo de respuesta la podemos realizar desde un servidor con instalación Full de la siguiente forma.

1-      Nos validamos con usuario de administrador local del equipo y ejecutamos dcpromo.exe

2-      Después de verificar si los binarios fueron previamente cargados, se inicia el asistente (Fig 1)

Fig1

3- Seleccionamos “Existing Forest” y “Add a domain controller to an existing domain” porque deseamos agregar un nuevo servidor como DC (Fig 2)

Fig 2

4- Nuestro server no se encuentra aún unido al dominio (como tampoco lo está el Server Core que vamos a unir luego), por lo que debemos suministrar credenciales alternativas (Fig 3).

 Fig 3

5- Seleccionamos las opciones necesarias para este nuevo equipo (site AD, si será DNS, si será Global Catalog o RODC, ubicación de la base de datos de AD y carpeta Sysvol y password para DSRM)

6- Cuando se nos presenta el Summary (Fig 4) tenemos la opción de seleccionar “Export settings…” con lo que grabaremos un archivo .txt con todas las configuraciones que hemos elegido previamente.

Fig 4

7- Pulsamos “Cancel” para salir del asistente.

Ahora debemos autentificarnos en nuestro equipo Server Core con credenciales de Administrador local y ejecutar DCpromo pero con el parámetro /unattend con el cual indicaremos donde está el archivo que creamos previamente (Fig 5).

Fig 5

Luego de que la instalación comience, nos solicitara credenciales del dominio para poder realizar la operación (Fig 6). Al terminar la operación se reiniciara el equipo y cuando vuelva a iniciarse será un nuevo DC.

Fig 6

En Windows Server 8, la única forma posible de instalar un DC con DCpromo es junto a un archivo de respuesta. DCpromo.exe pasa a estar des-enfatizado para darle paso a Power-Shell y Server Manager como herramientas de instalación de un DC. En la versión que continúe a Windows Server 8, DCpromo.exe no estará disponible.

DNS .local

Desde hace varios años, configurar un dominio de AD con el sufijo “.local” es una práctica habitual.  Inclusive en un Windows SBS (Small Business Server) ese sufijo es el que se le agrega al AD en forma predeterminada. Pero pocos tienen presente que esta acción no está recomendada.

En multicast DNS (mDNS) se utiliza ".local" como un pseudo-sufijo top level domain (TLD), eso permite resolver nombre de equipos sin un servidor DNS. Aunque la utilización de mDNS es muy limitada, es empleada principalmente en equipos Apple.

El uso de este sufijo puede traer diversos problemas:

a-Problemas al unir equipos Apple en un dominio AD con sufijo “.local”
b-Problemas con DirSync para sincronizar directorios en la nube con directorios propios de la empresa con Office 365. (Debido a que el UPN de los usuarios debe ser un top Top Level Domain registrado en la web)

¿Por qué Microsoft utiliza “.local” en SBS? Porque la RFC que especifica el estándar mDNS es posterior a la creación de Active Directory.

La recomendación es que ante una nueva instancia de un AD se realice como un subdominio con un sufijo registrable en Internet sobre el cual tengamos autoridad. Para ejemplificar, si tenemos un dominio en Internet que se llama “miempresa.com”, el nombre DNS de nuestro AD puede ser “casacentral.miempresa.com”

¿Que tiene ese 7 que no tengo yo?

Adquirir Windows 7 Professional OEM preinstalado en los equipos, permite a las organizaciones utilizar muchas características de este sistema operativo, pero no todas. Numerosas veces me han preguntado las razones para comprar (y pagar por segunda vez por el Windows que utilizarán las PC), Windows 7 Enterprise. No es fácil responder a esto, ya que son muchas características y derechos adicionales que tenemos sobre el sistema operativo con la versión Enterprise.


Nuevas Características

BranchCache: Permite reducir el tiempo de espera en la descarga de documentos en Servers centralizados desde una ubicación remota, compartiendo entre los equipos la información previamente cacheada.

DirectAccess: Les da movilidad a los usuarios permitiendo (según defina el Administrador) el acceso a la red corporativa cuando están conectados a Internet, sin necesidad de iniciar una conexión VPN. También permite a los Administradores configurar o actualizar el equipo como si estuviera en la red corporativa.

Bitlocker y BitlockerToGo: Ayuda a proteger la información en los HD o discos removibles encrestándolos. Además permite la administración de claves de recuperación almacenándolas en Active Directory.

AppLocker: Especifica qué software puede ejecutar el usuario en el equipo. Permite ser configurado por GPO, lo que le da facilidad de configuración y flexibilidad. 

Soporte Multilenguaje: Ofrece la posibilidad de crear una única imagen del sistema operativo pudiendo ser distribuida en diferentes lenguajes.

Inicio desde VHD: El sistema operativo puede iniciar desde VHD (Virtual Hard Disk) nativamente en lugar de utilizar un HD.

VDI Rights: Con Windows 7 Enterprise están cubiertas las licencias de Sistema Operativo Desktop que ejecutemos en el datacenter como parte de una infraestructura de VDI


Sumando SA

Cuando se adquiere Windows 7 Enterprise, podemos sumarle Software Assurance (SA). El beneficio directo de SA, es que si una nueva versión de Windows Client es lanzada al mercado, podremos utilizarla sin costo adicional. Otro beneficio de SA es la posibilidad de utilizar Windows ThinPC. Windows TPC es una versión reducida de Windows 7 optimizada para usarse como ThinClient en PC antiguas que forman parte de la infraestructura de VDI. Al tener SA tenemos la posibilidad de adquirir MDOP (Microsoft Desktop Optimization Pack), un conjunto de 6 aplicaciones que nos permiten reducir los costos de mantenimiento, extender la flexibilidad y simplificar la administración de nuestros desktops mediante la virtualización de aplicaciones, el manejo avanzado de GPO y la utilización de herramientas de recuperación.

Clonado de equipos

Para poder realizar clonado de equipos es necesario poseer lo que se llama “ReimagingRights”, que se adquiere junto a la versión Enterprise de Windows 7. Adicionalmente, para realizar el clonado de un equipo con Windows, es necesario ejecutar Sysprep. No está de más recordar que la ejecución de Sysprep en un equipo OEM no está soportada.

Simplicidad en el manejo de claves de activación

Con Windows 7 Enterprise, podemos utilizar la activación KMS con la cual automáticamente se activan los equipos del dominio conectados en nuestra red. También podemos desactivarlos si pasado un cierto tiempo no se comunican con nuestra infraestructura. La clave de producto deja de estar unida al equipo físico (Como ocurre en los equipos OEM), por lo que podemos sumar equipos a la organización sin preocuparnos por la activación y la clave que utiliza cada uno.

Flexibilidad de utilización

Con los equipos OEM, la licencia esta unida al hardware físico para el cual se compra esa licencia. Si el equipo es robado o destruido, la licencia corre la misma suerte ya que no puede ser transferida a otro hardware. Con Windows 7 Enterprise, podemos renovar nuestro parque de PC y continuar utilizando las mismas licencias.


No hay duda de que Windows 7 tiene varias características avanzadas, pero para aprovechar por completo la flexibilidad, seguridad, simplicidad de administración y despliegue, es necesario contar con Windows 7 Enterprise.Para aprender mas...

MDOP
Windows ThinPC
Windows 7 Enterprise
Reimaging Rights

Casos no soportados de DFS

Existen dos casos de uso frecuente con DFS (Distributed File System), aunque ninguno de ellos está soportado.

Con DFS-R (Replication) es habitual querer configurar una de las dos réplicas como de solo lectura, pero esa práctica no está soportada en Windows Server 2008 o versiones anteriores. Realizar este tipo de configuraciones puede llevar a problemas de verificación de topología, stagging o problemas en la base de datos de la replicación.

En caso de que se necesite soporte por problemas de replicación, es frecuente que uno de los primeros pasos a realizar sea habilitar la replicación en ambos sentidos, una de las prácticas más acostumbradas cuando se quiere dejar una réplica de lectura solamente.

Con Windows Server 2008R2 se permite crear una réplica DFS-R ReadOnly, por lo que esta práctica queda soportada a partir de esta versión.

En el caso de un Windows Server 2008 RODC, en el que la carpeta SYSVOL está replicada por DFS-R en lugar de FRS, los cambios se permiten en la carpeta SYSVOL pero son sobrescritos cuando un DC replica dicha carpeta. En un Windows Server 2008R2 RODC, la carpeta SYSVOL es de solo lectura, de modo que no pueden realizase cambios.

Con DFS-N (Namespaces) es usual utilizar un mismo nombre para la ubicación en la red en la cual se guardan los perfiles de usuarios, lo que posibilita que si un usuario cambia de ubicación geográfica puede ir a buscar su perfil de red al servidor que tenga la copia más cercana.  Esta práctica no está soportada, ya que si se permite al sistema operativo que localice el perfil en dos ubicaciones diferentes (que probablemente no estén del todo sincronizadas por problemas de replicación o por la propia demora configurada en DFS-N), puede corromperse el perfil del usuario. 

Para aprender más…
DFS-R en Technet

DFS-N en el blog de Askds