Windows Server 2012 R2Administración

avanzada
Este libro está dirigido a aquellos administradores e ingenieros de sistemas que deseen
adquirir conocimientos avanzados sobre Windows Server 2012 R2 y dominarlo en
profundidad.

Responde a la necesidad de disponer de una mayor experiencia por parte del lector,
tratando con profundidad, desde un punto de vista teórico y práctico, roles imprescindibles
tales como Active Directory, DFS, Hyper-V, BitLocker, el reparto de carga o incluso
la VPN. También se describen todas las especificidades de Windows Server 2012 R2
(como, por ejemplo, los avances en términos de virtualización, de seguridad, los Work
Folders, IPAM, Workplace Joint, la Experiencia con Windows Server Essentials,
etc.), para permitirle aprovechar al máximo el potencial de esta versión.

Desde el despliegue, pasando por el clustering, y hasta la virtualización, este libro es el

compañero ideal para aprender hasta el último detalle de esta versión de Windows Server.
Aporta un alto nivel de experiencia y su vocación es convertirse en una obra de referencia.

Los autores ponen a disposición del lector sus conocimientos en tecnologías Microsoft
(MVP, MCSE y/o MCITP, MCSA) y su experiencia, muy significativa, en
infraestructuras integrales y complejas, para proveer un nivel de calidad que respete las
mejores prácticas del mundo profesional de la empresa.

Los capítulos del libro:

Introducción – Dominio Active Directory – Arquitectura distribuida de acceso a los
recursos – Alta disponibilidad – Implementar los servicios de Red de la empresa – La
evolución de la red – Servicios de Escritorio remoto – Acceso remoto – Aplicaciones de
Internet – Reducir la superficie de ataque – Consolidar sus servidores – Despliegue de
servidores y puestos de trabajo – Securizar su arquitectura – El ciclo de vida de su
infraestructura – Prepararse para el futuro

Thierry DEMAN - Freddy ELMALEH - Sébastien NEILD

Thierry DEMAN es Arquitecto de Sistemas y domina las tecnologías Microsoft tras

numerosos años trabajando en el seno de Permis Informatique. Está reconocido como
Microsoft MVP (Most Valuable Professional) en Exchange tras varios años. Está
certificado, entre otros, en MCSE Messaging 2013 y MCSA Windows Server 2008 et
2012.

Freddy ELMALEH es consultor freelance, experto en Seguridad y soluciones de

Infraestructura de Microsoft. Fundador de la empresa Active IT, colabora con muchas
grandes empresas en servicios de consultoría y auditoría de sistemas y seguridad. Está
 reconocido como Microsoft MVP (Most Valuable Professional) en Directory Services
desde 2007 gracias, en particular, a su activa participación en el seno de la comunidad
Microsoft (Foro Technet y laboratorio Microsoft). También está certificado en MCITP
Server Administrator para Windows Server 2012.

Sébastien NEILD es Ingeniero de Sistemas y Redes en una empresa de servicios.

Colabora como responsable de proyectos de Active Directory y Exchange y ha
participado en numerosos proyectos de despliegue y migración de infraestructuras
Windows Server. Está certificado en MCSE y MCITP Server Administrator para
Windows Server 2008.

Maxence VAN JONES es consultor freelance, Arquitecto de sistemas y redes, Jefe de

proyecto, formador MCT y fundador de MVJ CONSULTING. Interviene como experto
en proyectos de diseño de parques informáticos, de virtualización y de securización
siempre en relación con tecnologías Microsoft. Está, entre otros, certificado en MCITP
Enterprise Administrator para Windows Server 2008 y MCSA para Windows Server
2012.

Introducción
Este libro trata sobre la última versión del sistema operativo de la gama Windows Server de
Microsoft

Se trata, evidentemente, de Windows Server 2012 R2.

Microsoft, fiel a su estrategia, busca dinamizar la evolución de sus productos, prefiriendo,

de este modo, definir un ciclo de vida más corto a sus productos para aportar, de manera
regular, mejoras y evolutivos técnicos adaptados al mercado.

Windows Server 2012 no se sale de esta norma, y algunos meses después de la aparición de
la versión R1, ha hecho su aparición Windows Server 2012 R2 y se pone a disposición de
todos los profesionales.

Microsoft ha diseñado Windows Server 2012 para ofrecer una plataforma flexible y
completa que responda a las necesidades, cada vez más exigentes, de las empresas. Esta
versión evoluciona de acuerdo a su tiempo teniendo en cuenta la tendencia hacia la
virtualización de servidores, al Cloud Computing y a la premisa "Bring Your Own Device".
Podrá, de este modo, aprovechar las nuevas funcionalidades, útiles y prácticas, que le
permitirán basar el conjunto de sus Sistemas de Información en una solución Microsoft.

Las distintas ediciones de Windows Server

2012/2012 R2
Como es habitual, Microsoft Windows Server 2012 R2, así como Windows Server 2012,
está disponible en distintas versiones. La elección de una u otra edición dependerá,
especialmente:

• Del rol del servidor que prevé instalar.

• De la estrategia de virtualización empleada.
• Del tipo de licencia utilizado.

Para realizar esta elección, hay disponibles cuatro ediciones de Windows Server 2012 R2:

• Windows Server 2012 R2 Datacenter: se trata de la versión más completa, que

soporta hasta 64 procesadores. Se trata de una versión destinada a servidores
especialmente potentes que sólo está disponible bajo un programa de clave de
licencia por volumen. Su modelo de licencia se calcula en función del número de
procesadores y del número de CAL. Permite alojar un número ilimitado de
máquinas virtuales.
• Windows Server 2012 R2 Standard: se trata de una versión idéntica a la edición
Datacenter, salvo que sólo permite el uso de dos instancias virtuales.
• Windows Server 2012 R2 Essentials: esta versión remplaza a Small Business
Server Essentials. Algunos roles no están disponibles en comparación con una
versión Standard (Server Core, Hyper-V, etc.). Esta edición está limitada a una
única instancia física o virtual, con un máximo de 25 usuarios. Las versiones
Standard y Datacenter permiten utilizar ciertas funcionalidades que, habitualmente,
son propias de la versión Essentials (tales como la copia de seguridad de los equipos
cliente, los cuadros de mando, etc.).
• Windows Server 2012 R2 Foundation: esta edición no ofrece solución de
virtualización (no es posible instalar Hyper-V), y está limitada a 15 usuarios. Es
posible obtener más información sobre las especificaciones (idénticas entre las
versiones 2012 y 2012 R2) de esta versión en la siguiente dirección:
http://technet.microsoft.com/en-us/library/jj679892.aspx

Observe que existe, a su vez, una versión gratuita llamada Hyper-V Server 2012. Está
preconfigurada para ejecutar una versión mínima (Core) de Windows Server 2012 y sólo
puede alojar el rol Hyper-V. Es posible encontrar más información en la siguiente
dirección: http://technet.microsoft.com/es-es/evalcenter/dn205299.aspx

Windows Server 2012 R2 está disponible únicamente en versión 64 bits; las versiones de
32 bits e Itanium ya no están disponibles.

Si desea información más precisa, encontrará una descripción detallada de las distintas
versiones de Windows en la siguiente dirección (en inglés): http://www.microsoft.com/en-
us/server-cloud/windows-server/buy.aspx

La gestión de las licencias se ha rediseñado por completo. Para Windows Server 2012
Standard y Datacenter, el cálculo de licencias "por servidor" cambia por licencias "por
procesador". Preste atención, en adelante, al hardware de sus servidores. Por defecto, estas
versiones parten de una licencia para dos procesadores. La única diferencia entre ambas
versiones reside en el derecho a la virtualización: ilimitado en la versión Datacenter y de
dos máquinas virtuales en la versión Standard.

Encontrará la FAQ oficial (en inglés) correspondiente a las licencias en la siguiente

dirección: http://download.microsoft.com/download/4/D/B/4DB352D1-C610-466A-9AAF-
EEF4F4CFFF27/WS2012_Licensing-Pricing_FAQ.pdf

Se aplica, a su vez, un licenciamiento particular a las máquinas virtuales. Todos estos

detalles se encuentran en la siguiente
documentación:http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-
B75A-A5B04179958B/WindowsServer2012VirtualTech_VLBrief.pdf

Dado que las versiones Foundation y Essentials están mucho menos extendidas en la
empresa, este documento se centra en las ediciones Standard y Datacenter.

Los grandes ejes de Windows Server 2012

R2
Durante el estudio de los ejes principales de esta versión de Windows Server, Microsoft
tiene en consideración la carga de trabajo, la presión creciente sobre el servicio IT de las
empresas y la explosión del Cloud Computing. El sistema operativo deberá, por tanto, dar
respuesta a estas tres exigencias esenciales.

1. Un mejor control de la información

Windows Server 2012 R2 provee un mejor control de la información para garantizar una
mayor eficacia en la administración y, en consecuencia, una mejora en la productividad. La
nueva interfaz, de tipo mosaico, es coherente con el resto de la nueva gama de los OS
Windows. Aunque le pueda resultar algo desconcertante, Microsoft ha rectificado su
estrategia en la versión R2 reintegrando el botón Inicio. Es posible que la toma de control
suponga, todavía, algún problema, por ello le invito a leer la siguiente página, a riesgo de
que no sea capaz de volver a reiniciar su servidor salvo por línea de comando:
http://technet.microsoft.com/es-es/library/hh831491.aspx#BKMK_run

Para aumentar esta calidad en la administración, en Windows Server 2012 R2 se ha

aumentado la capacidad de script y de automatización de tareas gracias al lenguaje de script
Windows PowerShell. La automatización de tareas corrientes de administración se ve, de
este modo, mejorada enormemente gracias a esta nueva funcionalidad. Prácticamente todas
las acciones realizadas en el seno del sistema se pueden automatizar con PowerShell, y
existen muchos asistentes que proponen, como último paso, recuperar la sintaxis
PowerShell equivalente a las acciones realizadas.

El servicio de directorio de Active Directory está dotado, desde Windows Server 2008
R2, de funcionalidades tales como la papelera de reciclaje de Active Directory, la
administración automática de cuentas de servicio o incluso la posibilidad de administrar de
forma gráfica las directivas de contraseñas múltiples, que encantarán a todo administrador.
El control de acceso dinámico permite controlar el acceso a los datos de forma dinámica.
Identifica la criticidad del dato (según los atributos que se hayan definido) y guarda, a
continuación, el control sobre el que se ubican en el seno del Sistema de Información.

La instalación basada en roles y características, gracias a la consola única Administración

del servidor, facilita la administración. Los asistentes disponibles permiten limitar al
máximo los errores de configuración gracias a sus numerosas explicaciones, que guían al
administrador en la etapa de instalación de un componente Windows. La consola permite, a
su vez, instalar y administrar servidores físicos remotos o virtuales, tanto desde un servidor
como desde un puesto de trabajo, mediante las herramientas de administración RSAT. Es,
por tanto, fácil crear un grupo de servidores que tengan que gestionarse de manera
conjunta.

Microsoft ofrece, a su vez, la opción de instalar por defecto una versión mínima de
Windows Server 2012 R2, conocida con el nombre de Windows Server Core. Esta versión
funciona, de hecho, sin una interfaz gráfica y todo debe configurarse por línea de
comandos. La ventaja principal de este tipo de administración reside en el hecho de que la
superficie de ataque se reduce por el hecho de que solamente se instalan en el servidor
aquellos componentes imprescindibles. Los administradores agregarán, a continuación, los
roles que deseen. La interfaz gráfica se considera una característica más que es posible
desinstalar.

Consolas tales como el monitor de confiabilidad y rendimiento de Windows permite

detectar problemas de configuración en sus sistemas operativos, e informar
automáticamente al servicio informático. Ofrece, a su vez, mucha información precisa
sobre el uso de componentes del sistema.

En lo sucesivo, es posible realizar una mejor administración de la impresión. En efecto, es

posible instalar impresoras automáticamente sobre equipos de usuario mediante directivas
de grupo.

La consola MMC le permite gestionar, controlar y resolver mejor los fallos de las
impresoras de su dominio.

Por último, y una buena noticia más para los administradores, las reglas Applocker
permitirán realizar un mejor control de las aplicaciones cuyo uso se autorice con Windows
Server 2008 R2/2012/2012 R2 y Windows 7/8/8.1.

2. Una mejor protección del Sistema de Información orientada a la

movilidad y al Cloud

Microsoft ha rehecho completamente el núcleo de su sistema operativo desde Windows

Server 2008. Existe un núcleo NT 6.x desde Windows Vista/2008 (Windows 2000 y XP se
basaban en el núcleo NT 5.x). Windows 8 y 2012 se basan en el núcleo 6.2.
Este núcleo posee la tecnología Patchguard, desarrollada por Microsoft para proteger al
máximo el sistema operativo y, de este modo, mantener una barrera para los rootkits o
cualquier otro ataque que trate de modificar el núcleo del sistema. Windows Server
2012/2012 R2, igual que Windows 8/8.1, aprovechan la funcionalidad ELAM (Early
Launch Anti-Malware) que permite cargarse únicamente a aquellos drivers firmados, tras el
arranque del sistema.

La protección de acceso a redes (NAP) está, también, accesible y le permite implementar

condiciones de uso de su sistema dentro de la empresa. ¡Se terminaron las personas
externas que llegaban con un ordenador portátil que no cumpliera con las reglas de la
organización y los usuarios sin el antivirus actualizado! El acceso a la red se les denegará
mientras no cumplan con los criterios de conformidad que usted haya juzgado
convenientes.

El acceso a la red de la empresa cobra una nueva dimensión con la simplicidad en la

implementación de DirectAccess, que permite a los administradores aprovechar un control
mayor sobre los equipos, pudiendo, de este modo, administrarlos incluso antes de que se
conecte un usuario (GPO disponibles, etc.). Se terminó la necesidad de tener una
infraestructura IPv6 para aprovechar esta solución, como ocurría con Windows Server
2008 R2.

Los controladores de dominio de solo lectura (RODC) refuerzan la seguridad de sus

dominios Active Directory en la medida en que puede limitar la difusión de ciertas
contraseñas en caso de que se vea comprometido algún controlador de dominio. Éstos
encontrarán, por ejemplo, su lugar en las pequeñas redes de agencia donde la seguridad del
controlador de dominio no puede garantizarse.

El acceso VPN a través de protocolos tales como SSL facilitan el acceso al Sistema de
Información y, también, intercambiar datos con otros equipos. La pasarela sitio-a-sitio
multi-inquilino provee, de este modo, la opción de utilizar una misma pasarela Site To Site
para conectar clientes que posean el mismo plan de direccionamiento IP.

El firewall avanzado de Windows Server 2012 R2 permite limitar la superficie de ataque

de sus servidores realizando un filtrado de los puertos sobre el tráfico de red entrante o
saliente. El firewall analiza el flujo a nivel de aplicación, de modo que puede no autorizar el
tráfico para un servicio específico. Además, la nueva consola de gestión MMC para el
firewall avanzado permite configurar los flujos IPsec para asegurar la integridad o cifrar el
flujo entre equipos. Esto resulta ideal para definir un cifrado entre controladores de dominio
o entre equipos de administración y servidores de administración.

El cifrado del lector de disco se realiza con BitLocker, que permite, a su vez, impedir el
acceso a los datos de su disco duro desde una instalación paralela de otro sistema operativo.

Los servicios asociados a Active Directory refuerzan, a su vez, la seguridad de su

infraestructura informática. El rol AD CS (Active Directory Certificate Services) permite
difundir certificados basados en el nuevo modelo de certificados versión 4. El rol AD RMS
(Active Directory Rights Management Services) le da la posibilidad de controlar la difusión
de los documentos en su empresa. El rol AD FS permite favorecer enormemente los
intercambios de información con equipos asociados externos, o incluso mejorar el uso de
terminales personales para conectarse al Sistema de Información de la empresa (BYOD)
con un control mínimo sobre estos equipos gracias a Workplace Join.

Siempre desde un punto de vista de apetura hacia la movilidad, la funcionalidad de

Carpetas de trabajo permiten sincronizar archivos profesionales entre varios PC o
dispositivos que pertenezcan al mismo usuario, pertenezcan o no a la empresa.

Las funcionalidades de seguridad presentes en Windows Server 2012 R2 permiten, por

tanto, limitar el riesgo de ataque sobre el servidor garantizando una productividad y una
flexibilidad importantes.

3. Una plataforma que evoluciona

Windows Server 2012 R2 es una plataforma capaz de adaptarse y responde a las

necesidades de evolución de una sociedad.

La tecnología hypervisor (Hyper-V) responde a la necesidad, cada vez mayor, de las

empresas que desean virtualizar algunos de sus servidores. Esta tecnología responde, de
este modo, de forma ultra-reactiva a los cambios de trabajo dinámicos y al desarrollo de la
cloud privada. Las réplicas de Hyper-V resultarán interesantes para más de una PYME que
no disponga del presupuesto suficiente para la implementación de una solución de
replicación para responder ante un desastre o siniestro. Una réplica de Hyper V permitirá
replicar una máquina virtual hacia otra, ahorrando el máximo de ancho de banda, gracias a
una compresión y un registro de los cambios en un disco de una máquina virtual.

Un espacio de almacenamiento, novedad funcional desde Windows Server 2012, permite

utilizar discos duros económicos para crear zonas de almacenamiento. Esta zona puede, por
tanto, dividirse en espacios que se utilizarán como discos físicos. Un poco de manera
similar a como ocurre con SAN, aunque de forma mucho menos onerosa, esta
funcionalidad permite incluir discos auxiliares en caliente y utilizar métodos de
redundancia (paridad, mirroring, etc.).

El protocolo SMB (Server Message Block) pasa a la versión 3.0 y se ha visto mejorado
considerablemente. Tiene en cuenta funcionalidades tales como la conmutación automática
SMB, la consideración de SMB, el testigo de carpeta, etc. Tiene en cuenta, también, el
almacenamiento en archivos VHD o un sistema de bases de datos SQL.

Los servicios Terminal Server aportan una gran cantidad de innovaciones que mejorarán
enormemente la experiencia de usuario.

Es posible realizar un acceso centralizado a las aplicaciones de cara a desasociar, poco a

poco, el puesto de trabajo de las aplicaciones que son necesarias para los usuarios.
También puede hacer disponibles aplicaciones (publicación de aplicaciones) sin que tengan
que estar instaladas en el equipo del usuario. El acceso directo de la aplicación aparece,
ahora, en el escritorio del usuario junto a las aplicaciones instaladas de manera local en su
equipo. El usuario no es capaz de distinguir, a primera vista, las aplicaciones locales de
aquellas remotas, lo que le permite ganar tiempo en término de formación de los usuarios.
La funcionalidad RemoteFX, que había hecho su aparición con Windows Server 2008 R2,
se ha visto mejorada y ya no requiere ninguna configuración particular para aprovechar una
calidad gráfica excepcional mediante RDP (lectura de animaciones, webcam, etc.).

Un servicio de pasarela Terminal Services (también llamado RD Gateway) le permite no

tener que multiplicar los puertos a abrir en su red o a implementar una red privada virtual.
Basta con tener un único punto de entrada, a través de un portal Web, que le permite
acceder a su red privada virtual. El tráfico RDP se encapsula, en efecto, de manera
transparente en un flujo SSL (HTTPS).

El acceso Web a los servicios Terminal Server (RD Web Access) es una interfaz Web
que le permite acceder a las aplicaciones RemoteApp que haya decidido publicar. Estas
aplicaciones están, de este modo, accesibles desde su navegador de Internet. Esta solución
se basa en IIS y puede, a su vez, integrarse en un portal SharePoint.

Gracias a Windows Server 2012 puede gestionar la evolución de la empresa y, en

particular, administrar aplicaciones que requieran una alta disponibilidad.

El clúster de servidores tiene como cometido contener varios a servidores con un mismo
rol. Si alguno de los servidores (llamados nodos del clúster) no está disponible, el sistema
de clúster bascula, automáticamente, hacia otro nodo disponible. Esto se realiza sin ninguna
intervención por parte de los administradores, lo que limita la duración de la
indisponibilidad de una aplicación.

El servicio de alta disponibilidad se caracteriza, a su vez, por la posibilidad de hacer un

reparto de la carga de red (llamada, a su vez, NLB por Network Load Balancing). Este
reparto o equilibrado de carga permite repartir la carga de red entre varios servidores que
presenten la misma información. El reparto de carga de red puede, de este modo, responder
a un desarrollo importante de la actividad de un sitio de Internet, por ejemplo,
seleccionando dirigir las demandas de conexión al servidor Web en el servidor IIS menos
ocupado.

Por último, el ciclo de vida de su servidor resulta más sencillo de gestionar gracias a un
conjunto de herramientas adaptadas y útiles.

Entre todas ellas, podemos citar la característica de copia de seguridad que le

permite administrar sus copias de seguridad y restauraciones gracias a asistentes muy
intuitivos. La tecnología de las instantáneas permite realizar copias de seguridad de sus
archivos en ejecución de forma casi inmediata.
El servidor de actualizaciones WSUS3 permite administrar el conjunto de actualizaciones
(correctivos, parches de seguridad) de los sistemas operativos y de algunas aplicaciones
Microsoft en el seno de su red empresarial.

Este libro tiene también como objetivo presentarle las principales funcionalidades de
Windows Server 2012/2012 R2, insistiendo especialmente en aquellas novedades
aparecidas tras el salto tecnológico que separa a Windows Server 2003 de Windows Server
2008.

Está salpicado de consejos y recomendaciones de expertos en herramientas Microsoft y se

dirige, de este modo, a aquellas personas que ya posean cierta experiencia. No obstante,
esta obra también pretende explicar los conceptos básicos de modo que resulte accesible a
aquellas personas que no posean una experiencia notoria con la tecnología de servidor de
Microsoft.

Las numerosas direcciones de Internet provistas en las páginas de este libro se recopilan en
una webografía, disponible en la página Información.

Introducción
Este capítulo está dedicado al directorio de Microsoft Active Directory. El servicio de
directorio de Microsoft resulta indispensable en la gestión de la información en el seno de
una empresa.

En la primera parte, se presenta el servicio de directorio en Windows Server 2012 R2. A

continuación, seguiremos con explicaciones sobre los principales componentes ligados al
servicio de directorio, tales como las directivas de grupo y otros servicios relacionados al
propio directorio.

Presentación del servicio de directorio de

Microsoft: Active Directory Domain
Services
Usted ya conocerá, sin duda alguna, el principio de funcionamiento del directorio Active
Directory. Esta obra no tiene como objetivo volver a explicar lo que ya conoce, de modo
que los principios generales de un directorio Active Directory (también llamado Active
Directory Domain Services o AD DS) se abordan de manera muy breve para, así, poder
centrar su atención en las especificidades aportadas por Windows Server 2012 R2.
1. Definición de un dominio de Active Directory

Active Directory es un servicio de directorio que permite referenciar y organizar objetos

tales como cuentas de usuario, nombres de recursos compartidos, autorizaciones mediante
grupos de dominio, etc. La información puede, así, centralizarse en un directorio de
referencia con el objetivo de facilitar la administración del Sistema de Información.

Desde un punto de vista tecnológico cabe tener en cuenta tres nociones:

• El dominio es la unidad básica encargada de agrupar los objetos que comparten un

mismo espacio de nombres (un dominio debe, en efecto, basarse necesariamente
sobre un sistema DNS que soporte actualizaciones dinámicas y registros de tipo
SRV).
• Una arborescencia de dominios es la agrupación jerárquica de varios dominios
que comparten un mismo espacio de nombres (por ejemplo, los dominios
madrid.MiEmpresa.Priv y barcelona.MiEmpresa.Priv).
• Un bosque trata de reagrupar varias arborescencias de dominio que tienen en común
un catálogo global y que no comparten, obligatoriamente, un espacio de nombres
común.

Desde un punto de vista físico, cabe tener en cuenta tres elementos principales:

• Los controladores de dominio se encargan de almacenar el conjunto de los datos y

de administrar las interacciones entre los usuarios y el dominio (apertura de sesión,
búsquedas en el directorio, etc.). Al contrario que con los antiguos sistemas NT, en
el dominio tiene lugar una replicación multimaestro, lo que permite a cualquier
controlador poder iniciar una modificación (agregar una cuenta de usuario, cambiar
una contraseña de usuario, etc.).
• Cada controlador de dominio contiene, a su vez, particiones. Microsoft ha decidido
compartir la información en varias particiones para, así, limitar la extensión de los
datos que hay que replicar. Cada partición tiene, por tanto, su ámbito de replicación.
Todos los controladores de dominio de un mismo bosque tienen en común las
particiones de esquema y de configuración.

Todos los controladores de dominio de un mismo dominio comparten una partición

de dominio común.

La cuarta partición (presente de forma opcional) es la partición de aplicación. Ésta

almacena los datos sobre las aplicaciones utilizadas en Active Directory y se replica
sobre los controladores de dominio que usted elija que formen parte del mismo
bosque.

• Los sitios Active Directory ponen en evidencia la agrupación física de objetos de un

mismo dominio. Debe, además, asociar uno (o varios) controlador(es) de dominio a
un mismo sitio Active Directory si estos controladores de dominio se comunican
con un enlace de red que tenga una buena velocidad de transferencia. En efecto, los
 controladores de dominio de un mismo sitio dialogan de manera mucho más
frecuente que los controladores de dominio definidos en dos sitios de Active
Directory distintos. Esto le permite, también, reducir de manera importante el
tráfico de red en un enlace que separe a dos sitios remotos.
• Los roles FSMO (Flexible Single Master Operation) son un total de cinco en el seno
de una infraestructura Active Directory. Estos roles deben estar contenidos en
controladores de dominio y son necesarios para el correcto funcionamiento de un
dominio de Active Directory.

Según los roles, son únicos por dominio o bien por bosque. La siguiente tabla
muestra con detalle cada uno de estos cinco roles:

Nombre del rol

Ubicación Rol
FSMO
Maestro de Único en el • Se encarga de inscribir a los
nomenclatura de seno de un dominios en el bosque.
dominios bosque • Gestiona la nomenclatura del
dominio.

Maestro de esquema Único en el • Gestiona la modificación del

seno de un esquema Active Directory.
bosque
Maestro RID Único en el • Distribuye rangos de RID para los
seno de un SID.
dominio
Maestro de Único en el • Gestiona los movimientos de objetos
infraestructura seno de un de un dominio a otro.
dominio
Emulador PDC Único en el • Garantiza una compatibilidad con
seno de un los sistemas operativos anteriores
dominio (NT, en particular).
• Sirve como servidor de tiempo de
referencia para el resto del dominio.
• Sirve como punto de referencia
durante los procesos de cambio de
contraseña y bloqueo de cuentas.
2. Funcionalidades de Active Directory en Windows Server 2012 R2

Windows Server 2012 R2 proporciona un gran número de funcionalidades, las cuales

gustarán tanto a aquellas personas que no tengan un conocimiento previo como a aquellas
que deseen poseer un conocimiento avanzado.

Se le explica cómo instalar un controlador de dominio de Active Directory con Windows

Server 2012 R2, cómo utilizar las directivas de contraseña específicas, etc.

Estas funcionalidades se le presentarán mediante casos prácticos a lo largo de este capítulo

para que pueda constatar, usted mismo, la utilidad de estas últimas.

a. Instalación de un directorio de Active Directory

Desde un punto de vista general, los asistentes de configuración se han visto mejorados
considerablemente a lo largo de las versiones de Windows. Descubrirá, rápidamente, que
estos últimos son muy útiles e intuitivos. Por ejemplo, en lo sucesivo puede hacer
referencia a la mayoría de las opciones avanzadas de instalación del directorio Active
Directory desde el asistente creado a este efecto.

Es necesario agregar un nuevo rol en su servidor Windows Server 2012 R2 para instalar su
directorio Active Directory.

Puede acceder desde el Administrador del servidor. Utilizará, por tanto, esta consola para
agregar el rol Servicios de dominio de Active Directory (también conocido bajo el
nombre AD DS por Active Directory Domain Services). Volveremos un poco más adelante
sobre las etapas detalladas ligadas a esta instalación.

En primer lugar, el conjunto de manipulaciones debe realizarse con una cuenta de usuario
que posea los permisos de Administrador del servidor.

Asegúrese, en primer lugar, que tiene bien definido el nombre NetBIOS de su futuro
controlador de dominio, así como una dirección IP fija válida. Se recomienda, siempre,
definir estos parámetros antes de realizar la promoción de un servidor a controlador de
dominio.
Por defecto, el Administrador del servidor se ejecuta cada vez que inicia Windows, y le
permite configurar su servidor una vez instalado.

Haga clic en Configurar este servidor local (o Servidor local) para visualizar la
configuración propia a este servidor y modificarla si fuera necesario.

Escoja configurar las opciones de red haciendo clic en los enlaces de hipertexto que se
encuentran en la misma fila que Ethernet y Nombre de equipo. Podrá, de este modo,
definir una dirección IPv4 fija, así como un nombre de equipo descriptivo para su servidor.

En nuestro ejemplo, el nombre de equipo será DC2012 (DC por Domain Controller o
controlador de dominio). A continuación deberá reiniciar el servidor.

Vuelva sobre Panel, siempre desde la consola Administrador del servidor.

Haga clic en Agregar roles y características.

 A continuación se abre el Asistente para agregar roles y características. La primera
página aparece, por defecto, con cada ejecución del asistente. Tiene como
objetivo permitirle verificar un conjunto de buenas prácticas antes de continuar con la
instalación de un rol en su servidor (contraseña fuerte, dirección IP estática, parches de
seguridad al día). Haga clic en Siguiente.

Escoja la opción Instalación basada en características o en roles y, a continuación, haga

clic en Siguiente.
 Como es posible instalar, desde este asistente, roles o características sobre un servidor
definido en un grupo de servidores o desde un disco duro virtual, esta etapa le permite
precisar el servidor o el disco duro virtual en cuestión. En nuestro ejemplo, se trata de un
servidor físico. Seleccione la opción Seleccionar un servidor del grupo de servidores y, a
continuación, haga clic en Siguiente.

Observe que todos los comandos de instalación se basan en PowerShell y pueden ejecutarse
de manera remota.
 Seleccione, a continuación, el rol o la característica que desea instalar. Como se trata de la
instalación de un controlador de dominio Active Directory, debe escoger la
opción Servicios de dominio de Active Directory.
 El asistente le invitará a agregar la instalación de varias características necesarias (o, al
menos, útiles) para este rol (Herramientas administrativas, Administración de directivas de
grupo, etc.). Las siguientes etapas del asistente se actualizan de manera dinámica en
función del rol seleccionado. Haga clic en Siguiente.

A continuación se le pregunta si quiere aprovechar para instalar las características

suplementarias de su servidor. No es necesaria ninguna para el buen funcionamiento de
Active Directory, las características necesarias ya se le han presentado en la ventana
anterior. Haga clic en Siguiente.
 El asistente le explica, rápidamente, el rol de los servicios de dominio de Active Directory
así como la principal información a tener en cuenta. Le invita, a su vez, a consultar los
artículos disponibles en la ayuda de Windows para más información. Haga clic en
Siguiente.
 La última etapa consiste en confirmar la instalación del rol en cuestión. Los mensajes de
información le avisan de que el servidor se reiniciará al finalizar la instalación. Reinicio
que puede escoger que se realice automáticamente o no. Haga clic en Instalar. Comienza la
instalación del rol.
Es posible exportar los parámetros de configuración. Esto será útil para poder reutilizarlos
mediante comandos PowerShell si fuera necesario.
Es posible cerrar el asistente y continuar trabajando con el servidor sin que la instalación se
detenga. Puede ver el grado de avance de la instalación en la consola Administración del
servidor, dentro del área marcada con la bandera de notificación.

Una vez terminada la instalación, se dará cuenta rápidamente de la potencia y de la utilidad

de los asistentes de Windows Server 2012 R2. Estos últimos le guiarán de manera muy
intuitiva en las siguientes etapas a realizar.

En el área de notificaciones, puede apreciar, pasados algunos minutos, un signo de

exclamación que se corresponde con la Configuración posterior a la instalación que debe
realizar para continuar con la instalación de Active Directory. Si no apareciera, aunque la
instalación haya terminado, cierre el Administrador del servidor y, a continuación, ábralo
de nuevo (o haga clic en el botón Actualizar que se encuentra justo al lado (a la izquierda)
del icono con forma de bandera de notificación). Haga clic en el enlace Promover este
servidor a controlador de dominio. Si bien sigue existiendo, el comando dcpromo ya no
se utiliza desde Windows Server 2012. Servirá únicamente para facilitar la transición de
algunas empresas que hayan desarrollado scripts con este comando. La norma es, ahora,
utilizar los scripts PowerShell, puesto que, ahora, todo se basa en ellos. Los cmdlets
PowerShell que pueden resultar útiles son Install-ADDSForest, Install-ADDSDomain,
Install-ADDSDomainController y Add-ADDSReadOnlyDomainControllerAccount. Puede
encontrar más información en la siguiente dirección: http://technet.microsoft.com/en-
us/library/hh472162.aspx
Antes de poder instalar un controlador de dominio en Windows Server 2012 R2, el nivel
funcional del bosque deberá ser, como mínimo, Windows Server 2008. A modo de
recordatorio, para que el nivel funcional del bosque sea Windows Server 2008, es preciso
que el nivel funcional de todos los dominios del bosque sean, como mínimo, Windows
Server 2008. Esto implica que ya no será posible tener un controlador de dominio con
Windows Server 2003 en un bosque que tenga un DC con Windows Server 2012 R2.

Si no fuera el caso, deberá, obligatoriamente, extender el esquema a Windows Server 2012

y, a continuación, actualizar el dominio funcional del (o de los) dominio(s) y el bosque
impactados.

Estas etapas resultan, a menudo, temidas por los administradores puesto que la marcha atrás
es compleja (habrá que restaurar, como mínimo, un dominio por bosque). Microsoft ha
optado por simplificar esta etapa integrando directamente la actualización del esquema y
del dominio en el asistente de promoción de un controlador de dominio desde el
Administrador del servidor.

El asistente ejecuta como tarea de fondo el comando adprep. Este comando es necesario
para preparar un bosque y un dominio para la instalación de un controlador de dominio de
una versión superior. Este comando sólo está disponible en versión 64 bits.
Si sus antiguos controladores de dominio ejecutan, todavía, una versión de 32 bits, es
posible ejecutar adprep de manera remota desde un servidor Windows Server 2008 versión
64 bits, Windows Server 2008 R2, Windows Server 2012 o Windows Server 2012 R2
miembro del dominio, incluso aunque no se trate de un controlador de dominio. Adprep se
ubica en la carpeta soporte\adprep del DVD de instalación de Windows Server 2012 R2.
Encontrará mucha más información sobre la instalación manual de adprep en la siguiente
dirección: http://technet.microsoft.com/en-us/library/hh472161.aspx

Si, en el seno de su dominio, todos los controladores de dominio funcionan con Windows
Server 2012 R2, puede aumentar el nivel de su dominio a Windows Server 2012 R2
mediante la consola Dominios y confianzas de Active Directory o mediante el centro de
administración de Active Directory (encontrará más información en la dirección:
http://technet.microsoft.com/es-es/library/cc753104.aspx). Si, en el seno de su bosque,
todos los controladores de dominio funcionan con Windows Server 2012 R2 puede,
también, aumentar el nivel funcional de su bosque, siempre mediante alguna de estas
consolas (encontrará más información en la dirección: http://technet.microsoft.com/es-
es/library/cc730985.aspx)

Existen varios motivos para aumentar el nivel funcional del dominio o del bosque. Aporta,
la mayoría de veces, funcionalidades y características suplementarias. Estas
funcionalidades se resumen en la siguiente dirección: http://technet.microsoft.com/en-
us/library/understanding-active-directory-functional-levels(v=ws.10).aspx

Observe, no obstante, que algunos componentes no requieren más que la preparación del
dominio para agregar nuevas funcionalidades (sin tener, obligatoriamente, que implementar
el nivel funcional del dominio o del bosque). Es el caso, por ejemplo, del proxy web de
aplicación (Web Application Proxy) que se basa únicamente en las clases del esquema
creadas tras la implementación del esquema (mediante el comando adprep /forestprep) para
poder funcionar.

Observe, a su vez, que (siempre y cuando la papelera de reciclaje de Active Directory no

esté activada) es posible disminuir el nivel funcional de un dominio o de un bosque de
Windows Server 2012 o Windows Server 2008 R2 a Windows Server 2008 mediante los
comandos PowerShell siguientes:

Import-Module ActiveDirectory
Set-AdDomainMode -identity MiEmpresa.Priv -server dc2012.MiEmpresa.Priv
-domainmode
Windows2008Domain

Set-AdForestMode -identity MiEmpresa.Priv -server dc2012..MiEmpresa.Priv

-forestmode
Windows2008Forest

Haga clic, a continuación, en el vínculo Promover este servidor a controlador de

dominio disponible en la lista de tareas o, tal y como se ha indicado antes, haga clic en
Promover este servidor como controlador de dominio.
Se inicia el Asistente para instalación de Servicios de dominio de Active Directory.

Seleccione una configuración de despliegue. En nuestro ejemplo, seleccione: Agregar un

nuevo bosque. Observe que el asistente le indica un vínculo hacia el archivo de ayuda en
línea de Windows que trata las distintas configuraciones de despliegue posibles.

Si ha seleccionado agregar un controlador de dominio a un dominio existente, tendrá la

posibilidad, más adelante, de definir la instalación del controlador de dominio a partir de un
medio externo (una copia de seguridad, por ejemplo). Esto resulta bastante útil para sitios
remotos, por ejemplo, para evitar que se produzca un tráfico de red demasiado elevado y se
sature el ancho de banda durante la primera sincronización entre los controladores de
dominio. Puede, si no, definir un controlador de dominio particular para la primera
sincronización del directorio de Active Directory para indicar un controlador de dominio
del mismo sitio y, de este modo, evitar que la sincronización no se realice desde un sitio
remoto que podría tener un ancho de banda limitado.

Dé nombre a la raíz del bosque. En nuestro ejemplo, el nombre del dominio será
miempresa.priv y, a continuación, haga clic en Siguiente.
Se recomienda, en cualquier caso, informar un nombre de dominio con dos niveles.

No cree, por tanto, ningún dominio Active Directory que tenga, por ejemplo, el nombre
Miempresa. Piense, también, en prohibir el uso de un guión bajo (underscore) en su nombre
de dominio. Si se diera el caso, realice una migración a un nombre de dominio sin este
carácter, que le generará una serie de inconvenientes en el futuro, especialmente con
Exchange.

Observe que desde Windows Server 2008 R2, el asistente no le permite crear un nombre de
dominio de un solo nivel, bien sea para un bosque o para un nuevo dominio en un bosque
ya existente. Sí le dejará, por el contrario, agregar un nuevo controlador que se ejecute bajo
2008 R2 o superior en un dominio con un único nivel ya existente. La KB de Microsoft
KB300684 (http://support.microsoft.com/kb/300684) analiza este caso.

De aquí a dos años, los fabricantes de certificados públicos no certificarán más dominios
con extensiones privadas tales como: interna.MiEmpresa.es. Es conveniente disociar los
nombres de dominio interno y externo para evitar, en particular, tener que realizar una
gestión algo más compleja en su zona DNS interna.

Tras hacer clic en Siguiente, el asistente trata de resolver el nombre de dominio para
contactar con un eventual bosque ya existente.
Encontrará más información sobre los distintos tipos de zona DNS y sobre la replicación en
el capítulo Implementar los servicios de red de la empresa - Implementar los sistemas de
resolución de nombres.

Es preciso definir el nivel funcional del bosque. Seleccione Windows Server 2012 R2
dado que, en este ejemplo, se trata de un servidor que es el único controlador de dominio y
del bosque.

Deje marcada la opción Servidor DNS para instalar este rol sobre el futuro controlador de
dominio. La opción Catálogo global aparece marcada obligatoriamente puesto que todavía
no existe ningún catálogo en el dominio, dado que hemos seleccionado la opción de crear
un nuevo dominio en un nuevo bosque.

Defina una contraseña de restauración de servicios de directorio. Se utilizará cuando se

acceda en modo de restauración del directorio Active Directory pulsando la tecla [F8]
durante el arranque del sistema operativo. Esta contraseña deberá responder a la
complejidad requerida por la directiva de contraseña.

Si bien puede resultar tentador, no defina la misma contraseña que para la cuenta de
Administrador actual por motivos de seguridad.

A continuación, haga clic en Siguiente.

Aprovechará automáticamente, de este modo, las ventajas ligadas al nuevo funcionamiento
del dominio de Windows Server 2012 R2, como las directivas de contraseña específica
(disponibles desde el nivel funcional Windows Server 2012 y que verá, también, más
adelante en la sección Directivas de contraseña específica y de bloqueo de cuenta granular
de este capítulo).

El sistema trata, a continuación, de contactar con el servidor DNS definido a nivel de los
parámetros TCP/IP de la tarjeta de red del servidor. Si no responde al nombre de dominio
Active Directory definido, y si no se ha instalado ningún servidor DNS, el asistente
mostrará el siguiente mensaje (haciendo clic en Ver más en la barra de alerta de color
amarillo ubicada en la parte superior del asistente).
Observe, también, que si se define un servidor DNS en las propiedades TCP/IP del
servidor, éste se borrará automáticamente de estas propiedades de modo que el futuro
controlador de dominio será cliente de su propio DNS. El anterior servidor DNS se
informará en la pestaña Reenviadores en las propiedades del servicio DNS.
 Haga clic en Siguiente. Deje el nombre NetBIOS por defecto y, a continuación, haga clic
en Siguiente.

Como se encuentra trabajando en un entorno de pruebas, deje la ruta por defecto para la
base de datos, los archivos de registro y SYSVOL. En un entorno de producción, se
recomienda encarecidamente separar la base de datos y los archivos de registro para, así,
evitar la saturación de I/O (entradas/salidas). Haga clic en Siguiente.

Aparece un resumen que muestra las distintas opciones que ha definido a lo largo de las
etapas del asistente. Es posible exportar estos parámetros para poder reutilizarlos en un
archivo de respuestas.

Podrá, de este modo, desplegar fácilmente otros controladores de dominio reduciendo el

riesgo de error durante la configuración de este rol. El comando que debe utilizarse es, en
este caso, dcpromo /answer:NombreDelArchivoCreado (si no se trata de promover un DC
en Windows Server 2012 R2) o, directamente, mediante PowerShell mediante el script
disponible haciendo clic en la opción Ver script.
 Haga clic en Siguiente. El asistente realiza, a continuación, una verificación de requisitos
previos necesarios para la instalación del rol de controlador de dominio sobre este servidor.
Aparece un mensaje de advertencia que indica los problemas que puede encontrar debido al
enriquecimiento del algoritmo de cifrado utilizado para establecer un canal de seguridad
con un cliente SMB. Por defecto, los anteriores sistemas operativos como, por ejemplo,
Windows NT 4.0 no podrán acceder a los recursos compartidos que se encuentren en un
servidor Windows Server 2008/2008 R2/2012 o 2012 R2.

Recorra esta lista de advertencias y, si no existe ningún punto bloqueante, haga clic en
Instalar.

Observe que puede realizar las acciones correctivas necesarias y, a continuación, hacer clic
en el vínculo que le permite volver a verificar si se cumplen los requisitos previos.

Haga clic en Instalar para arrancar la instalación. El servidor reinicia, automáticamente, al

finalizar la instalación.

¡Enhorabuena! Acaba de instalar con éxito un controlador de dominio en Windows Server

2012 R2.

Le faltará verificar la instalación de Active Directory y realizar las primeras acciones

esenciales. El siguiente enlace le ofrece todos los elementos necesarios:
http://technet.microsoft.com/en-us/library/cc794717(WS.10).aspx
b. Presentación de la auditoría ligada al servicio de directorio

Auditar estos servidores es una actividad que consiste en censar los eventos que se
consideren interesantes en el registro de eventos. Esto le permitirá evidenciar problemas de
configuración o incluso verificar la seguridad de ciertos elementos críticos del sistema
operativo. Preste atención, no obstante, a no definir demasiados objetos a auditar, puesto
que el rendimiento del servidor se verá impactado inmediatamente.

Antes de Windows Server 2008 R2, podía configurar los eventos de auditoría editando su
directiva de grupo (desde el menú Inicio - Herramientas administrativas y Gestion des
Directiva de grupo) a nivel, por ejemplo, de Directiva Default Domain Controllers
Policy (Configuración de equipo - Directivas - Configuración de Windows -
Configuración de seguridad - Directivas locales - Directivas de auditoría).

La información que se muestra es, no obstante, confusa, ¡pues es posible ser mucho más
preciso!

Las directivas de auditoría pueden, en efecto, definirse de forma mucho más precisa y los
parámetros visualizados a nivel de la directiva de grupo más arriba no representan más que
de una forma muy vasta la configuración efectiva.
En Windows XP sólo existen nueve categorías de evento que pueden auditarse. Desde
Windows Vista/Windows Server 2008, puede optar por auditar hasta 53 categorías de
eventos distintos volviendo, de este modo, la creación de objetos mucho más granular.

La visualización y la configuración de estos parámetros no son idénticos entre Windows

Server 2008 R2 y Windows Server 2012 R2.

En Windows Server 2008 (o Vista con las herramientas de administración RSAT), puede
mostrar y aplicar de forma más precisa las directivas de auditoría realmente posibles
únicamente por línea de comandos mediante el comando Auditpol.exe.

El siguiente comando permite mostrar las distintas categorías posibles para la auditoría:

Auditpol.exe /get /Category:*

En Windows Server 2008 R2 y Windows 2012/2012 R2 (o Windows 7 - Windows 8/8.1

con las herramientas de administración RSAT instaladas), es posible configurar, desplegar
y administrar la auditoría detallada desde la consola GPMC. La configuración de la
auditoría detallada se realiza a nivel de Configuración del equipo - Directivas -
Configuración de Windows - Configuración de seguridad - Configuración de directiva
de auditoría avanzada - Directivas de auditoría.

Estas directivas pueden aplicarse, de este modo, sobre OU específicas para controlar la
actividad de las cuentas de administrador, etc. Tenga en mente, no obstante, que esta
configuración definida mediante GPO se ejecutará únicamente en equipos Windows Server
2008 R2/2012/2012 R2 o Windows 7/8/8.1.

Cabe destacar, también, que Microsoft desaconseja la configuración de la auditoría

simultáneamente a nivel de Configuración del equipo - Configuración de Windows -
Configuración de seguridad - Directivas locales - Directivas de auditoría y de
Configuración del equipo - Configuración de Windows - Configuración de seguridad -
Configuración de directiva de auditoría avanzada - Directivas de auditoría. Para ello,
Microsoft recomienda configurar la opción Auditoría: forzar la configuración de
subcategorías de la directiva de auditoría (Windows Vista o posterior) para invalidar
la configuración de la categoría de directiva de auditoría que se define a nivel de
Configuración del equipo - Configuración de Windows - Configuración de seguridad -
Opciones de seguridad. Si este parámetro no está habilitado, las opciones definidas a nivel
de la auditoría básica (las siete categorías históricas) podrían entrar en conflicto con las
definidas de manera más precisa en la directiva de auditoría avanzada.

Para desplegar estos parámetros en Windows Server 2008 o Windows Vista, es preciso
utilizar la opción auditpol.exe. Más adelante se ofrece un enlace a la KB que explica cómo
poner en marcha este despliegue.
Con la llegada de Windows Server 2008 R2 y Windows 7, Microsoft introduce la
posibilidad de auditar el acceso a objetos globales. Tiene, en efecto, la posibilidad de
definir una directiva de auditoría para un usuario particular sobre una acción precisa y para
un conjunto de servidores. Esto puede resultar muy práctico si tiene que justificar, en
particular, la auditoría de la seguridad de un servidor de cara a afrontar una auditoría SOX.

Los eventos generados por las auditorías de acceso a los archivos o al registro estarán
mucho más detalladas si activa la opción Auditar la manipulación de identificadores
puesto que se mostrará el "motivo del acceso", que le permitirá, en particular, poner de
relieve errores de configuración (como, por ejemplo, un usuario que tiene acceso de
escritura en lugar de tener un acceso de sólo lectura).

Con Windows Server 2012/2012 R2 es posible crear directivas de auditoría basadas en

expresiones con el objetivo de precisar mejor la información que se quiere mostrar en
función de varios criterios (usuarios, equipos, recursos, etc.). Este aspecto se aborda en
detalle en el capítulo Securizar su arquitectura.

Encontrará la guía paso a paso para implementar una directiva de grupo avanzada en la
siguiente dirección: http://technet.microsoft.com/es-es/library/dd408940(WS.10).aspx

Observará, entonces, que las opciones de auditoría son mucho más ricas respecto a las
versiones anteriores de Windows.
Se han conservado las principales categorías, y muchas subcategorías enriquecen y
hacen que la recogida de eventos sea mucho más precisa. Su registro de eventos estará, por
tanto, mucho más limpio de eventos inútiles.

Sepa, no obstante, que si utiliza la directiva de grupo para definir las categorías principales
de auditoría, no tendrá la posibilidad de definir de forma más precisa los parámetros de las
subcategorías. Una directiva de auditoría configurada a nivel de las directivas de grupo
activa, automáticamente, las subcategorías.

Para configurar de forma más precisa la auditoría sobre los equipos tendrá que utilizar el
comando auditpol en los equipos o servidores seleccionados a través de un script, por
ejemplo.

Si desea, en cambio, poder administrar la configuración de las subcategorías de sus equipos

Windows Vista/2008 de manera centralizada (y, en consecuencia, tener que utilizar el
comando auditpol en cada equipo), consulte la solución provista en el siguiente artículo de
la Kb de Microsoft: http://support.microsoft.com/kb/921469

Una de estas nuevas subcategorías de auditoría se ha creado especialmente desde Windows

2008 R2 para dar respuesta a una necesidad importante de los administradores de dominio
Active Directory.

Esta nueva subcategoría se denomina Directory Service Changes (categoría hija de DS

Access). Le permitirá registrar los antiguos y los nuevos valores atribuidos a un objeto de
Active Directory y a sus atributos. A título informativo, antes un controlador de dominio en
Windows 2000 o 2003 indicaba simplemente el nombre del objeto o del atributo
modificado, pero no los valores anterior y modificado del mismo.

Una vez configurada la auditoría de esta subcategoría, los eventos se almacenan en el

registro de Seguridad. La siguiente tabla recoge los cuatro tipos de eventos sobre los
objetos de Active Directory:

Número de evento Tipo de evento

5136 Modificación con éxito de un atributo de Active Directory.
5137 Creación de un nuevo objeto de Active Directory.
5138 Restauración de un objeto de Active Directory.
5139 Desplazamiento de un objeto de Active Directory.

Si desea, por ejemplo, activar la auditoría para todas las subcategorías referentes al
acceso al directorio Active Directory, siga el procedimiento siguiente:
 Ejecute, desde una ventana de símbolo del sistema de un controlador de dominio, el
siguiente comando: auditpol /set /category:"Acceso DS" /success:enable. Todas las
subcategorías de auditoría del acceso DS se activarán. Es posible activar únicamente la
subcategoría que nos interese, en nuestro caso, ejecutando auditpol /set
/subcategory:"modificación del servicio de directorio" /success:enable y auditpol /set
/subcategory:"Administración de cuentas de usuario" /success:enable.

Existe un bug en la versión española de auditpol y todas las categorías o subcategorías que
posean un apóstrofe no funcionarán si lo escribe. Existen dos soluciones para evitar este
problema: o bien copia/pega la opción desde una página web codificada correctamente, o
bien utiliza el código ASCII presionando [Alt] y 0146 para proveer la versión esperada del
símbolo.

Modifique, a continuación, la fecha de caducidad de una cuenta de usuario de Active

Directory mediante la consola Centro de administración de Active Directory, también
llamada ADAC (Active Directory Administrative Center) en el resto del libro (desde el
menú Inicio - Ejecutar - dsac.exe).

Abra el registro de eventos de su controlador de dominio (desde el menú Inicio - Ejecutar

- Eventvwr.msc). Puede comprobar que existe un evento 4738 y detalla el o los valores
que acaban de modificarse, en nuestro ejemplo el valor Expiración de cuenta:.
Por otro lado, Windows Server 2012 ha introducido las directivas de auditoría de seguridad
basadas en las expresiones que permiten acotar los eventos a informar utilizando
expresiones basadas en reivindicaciones (claims) de usuario, de equipo y de recurso. Esta
mejora está ligada a otra novedad: el control de acceso dinámico, del que hablaremos con
detalle en el capítulo Securizar su arquitectura.

Tenga en cuenta que, desde ahora, esta funcionalidad le permite auditar todos los usuarios
que traten de acceder a recursos para los que no se ha definido ninguna habilitación o, por
el contrario, administradores que utilicen sus permisos de manera abusiva.

Para ello, a nivel de GPO en el servidor de archivos, siga estas etapas:

Desde Configuración del equipo - Directivas - Configuración de Windows -

Configuración de seguridad - Configuración de directiva de auditoría avanzada -
Directivas de auditoría - Acceso a objetos, a nivel de parámetro Auditar sistema de
archivos y del parámetro Auditar almacenamiento provisional de directiva de acceso
central, active la auditoría Correcto y error.

A nivel de la carpeta a auditar:

 Desde las Propiedades de la carpeta a auditar (una carpeta sensible accesible únicamente
por el servicio financiero de la empresa, por ejemplo), pestaña Seguridad - Opciones
avanzadas - pestaña Auditoría - Agregar - Seleccionar una entidad de seguridad,
escoja un grupo habilitado para acceder a esta carpeta, en nuestro ejemplo GSU-Finanzas-
RW.

Agregue una condición que indique, por ejemplo: Usuario - Grupo - Miembro de cada -
Valor - [Administradores de dominio] y [Administradores].

Si un administrador accede a algún archivo de esta carpeta, se registrará un evento en el

registro de eventos de seguridad.
Los eventos 4656 y 4663 pueden generarse durante la activación de la auditoría de la
manipulación de identificadores o de la SAM. Estos eventos son propios de Windows 2012
R2 y Windows 8/8.1.

Se podría, también, citar como ejemplo la posibilidad de poder auditar todos los
proveedores que traten de acceder a documentos vinculados a proyectos sobre los que no
trabajen. La auditoría sería: Auditar - Todos - Todo - User.EmploymentStatus=Vendor
AND User.Project Not_AnyOf Resource.Project.

Si un usuario del servicio financiero trata de acceder, no se registrará ningún evento en el

registro de seguridad, lo que evitará reportar accesos válidos. También es posible asociar la
auditoría de acceso global a los objetos con directivas de auditoría basadas en expresiones,
lo que permite fusionar las directivas de auditoría múltiples ubicadas en varios clientes.

De este modo el administrador de un perímetro limitado podrá definir una directiva de

auditoría de acceso global a los objetos correspondientes a su perímetro mientras que un
administrador global podrá, por su parte, definir otra directiva de acceso global para un
perímetro más amplio.

Entre las mejoras aportadas por Windows Server 2012 y Windows 8 cabe destacar,
también, que es posible configurar el parámetro Auditar los inicios de sesión
(Configuración de directiva de auditoría avanzada - Inicio y cierre de sesión).

Se genera el evento 4624 cada vez que un usuario inicia una sesión sobre un equipo local o
remoto. Obtendrá más información sobre los nuevos eventos generados en la siguiente
dirección: http://technet.microsoft.com/es-es/library/hh831382.aspx

Estos parámetros pueden acoplarse con el control de acceso dinámico que se aborda en el
capítulo Securizar su arquitectura.

c. Controlador de dominio de solo lectura

Desde Windows Server 2008, es posible crear controladores de dominio de solo lectura
(llamados, también, RODC por Read Only Domain Controller). Un controlador de
dominio de solo lectura contiene toda la información de un controlador de dominio clásico
salvo la contraseña de los usuarios. Esta información se almacena en solo
lectura únicamente y no es posible iniciar ninguna modificación a nivel de dominio desde
un RODC.

Sepa, por otra parte, que si no desea que se replique algún atributo sensible en su RODC es
posible modificar las propiedades del mismo para limitar su replicación únicamente a
aquellos controladores de dominio inscribibles. Para ello, tendrá que modificar el valor
searchFlags del atributo que desee a nivel de partición de esquema. El rol maestro de
esquema tendrá que encontrar, preferentemente, la información sobre algún controlador de
dominio en Windows Server 2008 R2 como mínimo. Encontrará más información a este
respecto en la siguiente dirección (en inglés):
http://technet2.microsoft.com/windowsserver2008/en/library/f62c9720-a5c3-40c9-aa40-
440026f585e91033.mspx?mfr=true
Microsoft ha diseñado una solución adaptada a las necesidades de las empresas que posean
sitios remotos con pocos usuarios para:

• mejorar la seguridad de los sitios;

• mejorar la autenticación de los usuarios de un sitio remoto sin tener que iniciar un
tráfico WAN con el controlador de dominio del sitio principal;
• acceder a los recursos de la red con mayor rapidez.

Aumentar la seguridad de estos sitios

Antes, en efecto era necesario instalar un controlador de dominio suplementario sobre un

sitio remoto si no quería que ciertos usuarios se quejaran de mal rendimiento y una alta
latencia en la autenticación o el acceso a recursos del dominio. El problema que se
planteaba era que estos sitios no tenían los medios o la necesidad de tener un administrador
a tiempo completo, ni podían invertir en un local protegido para dotar de seguridad a su
servidor. En caso de robo o de corrupción del controlador de dominio del sitio, el atacante
podía recuperar, potencialmente, todos los nombres de usuario de la empresa y sus
contraseñas.

En lo sucesivo, es posible limitar las consecuencias de una corrupción de un controlador de

dominio sobre estos sitios puesto que puede definir, con precisión, qué cuentas tienen sus
contraseñas almacenadas sobre este controlador de dominio de solo lectura. Esto se realiza
mediante la pertenencia a uno de los dos grupos de seguridad llamados Grupo con
permiso para replicar contraseñas en RODC (su contraseña se replica en el RODC) y
Grupo sin permiso para replicar contraseñas en RODC (su contraseña no se replica en
el RODC). Tan solo tiene que escoger aquellas cuentas de usuario y agregarlas al grupo que
usted elija. En caso de conflicto (si un usuario perteneciera a ambos grupos, por ejemplo),
el permiso "Sin permiso" es prioritario. Por defecto, se almacenan dos instancias de la
contraseña sobre el RODC. La corres-pondiente a la cuenta krbtgt_xxxx y la
correspondiente a la cuenta de equipo. La cuenta krbtgt_xxxx es propia de cada RODC.
Permite entregar tickets Kerberos a los clientes que realicen la demanda. En caso de robo
del controlador de dominio de un sitio, basta con reinicializar las contraseñas de estas
cuentas, como verá más adelante.

Mejorar la autentificación de los usuarios

Un RODC trata de autentificar una cuenta respecto a las contraseñas que posee en caché. Si
no se encuentra en su caché, contactará con un controlador de dominio inscribible para
autentificar al usuario. Al mismo tiempo, consultará si la directiva de replicación de
contraseñas autoriza que se aloje en la caché del RODC la contraseña de esta cuenta o no.
De este modo, si la directiva lo permite, las consultas de autentificación se ejecutarán
directamente en el RODC.

Tenga en mente que jamás hay que abrir sesión en un RODC con una cuenta miembro del
grupo Administradores de dominio (o equivalente), pues un ataque permitiría obtener estas
credenciales.
Acceder a los recursos de red más rápidamente

Entre las demás especificaciones de un controlador de dominio de solo lectura, sepa que
este último sólo puede, por naturaleza, recibir el tráfico de replicación entrante (replicación
unidireccional). No puede, por tanto, definirse como servidor inicial de una directiva de
replicación de dominio en la medida en que simplemente sufre las modificaciones, sin
poder iniciarlas.

Es, también, posible instalar el servicio DNS sobre el RODC de un sitio. Esto evita tiempos
de latencia repetitivos cuando un usuario trata de realizar una resolución de nombres sin
tener un DNS próximo a él. Este servicio será, también, de solo lectura en un RODC y los
equipos no tendrán la posibilidad de insertar sus propios registros de forma dinámica sobre
este servidor DNS. Sus consultas de escritura se redirigirán a un servidor DNS sobre el que
se permita realizar escrituras. Para limitar la primera replicación de un controlador de
dominio suplementario, es posible instalarlo desde un medio extraíble y, de este modo,
preservar el ancho de banda al máximo. En el caso de un RODC, es posible realizar esta
acción utilizando el comando ntdsutil ifm, que tiene como efecto eliminar las contraseñas
alojadas en caché presentes en el controlador de dominio. Puede obtener más información
acerca de la instalación de un controlador de dominio desde un medio externo en la
siguiente dirección: http://technet.microsoft.com/en-us/library/cc816722(v=ws.10).aspx

Entre los requisitos previos de instalación de un RODC, sepa que:

• El controlador de dominio debe ser capaz de transferir las consultas de

autentificación hacia un controlador de dominio en Windows Server 2008 o
superior.
• El nivel funcional del bosque y del dominio deben estar configurados en Windows
Server 2003 o superior.
• Debe ejecutarse el comando adprep /rodcprep una única vez en el bosque. Permite
actualizar el conjunto de dominios del bosque para modificar los permisos en la
partición del directorio de la aplicación DNS. Será preciso, por tanto, que cada
controlador de dominio con el rol "Maestro de infraestructura" esté disponible en el
momento de ejecutar este comando.

Proceda como se indica a continuación si desea instalar un controlador de dominio de solo

lectura:

La instalación de un RODC es prácticamente idéntica al procedimiento que ha utilizado

durante la instalación de un controlador de dominio clásico. Debe, por tanto, instalar el rol
Servicios de dominio de Active Directory igual que para un controlador de dominio
clásico y, a continuación, ejecutar la configuración post-despliegue seleccionando la opción
Promover este servidor a controlador de dominio.

En nuestro ejemplo, para instalar un RODC, seleccione Agregar un controlador de

dominio a un dominio existente. Haga clic en Siguiente.
 Indique el nombre del dominio existente sobre el que desee instalar un RODC y, a
continuación, haga clic en Seleccionar para especificar la contraseña de un administrador
de dominio o de la empresa. Haga clic en Siguiente (si apareciera algún error, compruebe
su configuración DNS o autorice la apertura de puertos, pues su servidor RODC no llega a
conectarse con el servidor de dominio). Seleccione el dominio y, a continuación, haga clic
en Siguiente.

En esta etapa, marque la opción Controlador de dominio de solo lectura (RODC). Si lo

desea puede atribuir el rol de DNS y de catálogo global a este futuro controlador de
dominio (teniendo, siempre, en mente las limitaciones descritas anteriormente). Haga clic
en Siguiente.
 Especifique a continuación la Directiva de replicación de contraseña agregando o
suprimiendo los grupos y las cuentas de usuario que estarán autorizados a replicar su
contraseña en este controlador de dominio de solo lectura. Seleccione, también, a quién
delegar la administración del servidor RODC. En la práctica, los miembros de este grupo se
encuentran en el sitio remoto que alberga al propio controlador de dominio de solo lectura.
Haga clic en Seleccionar para agregar la cuenta o el grupo que desee. Una vez haya
terminado, haga clic en Siguiente.
 Seleccione Replicar desde para seleccionar un controlador de dominio específico si lo
desea. Haga clic en Siguiente.
 Seleccione una carpeta de destino para los archivos de Active Directory. Para mejorar el
rendimiento, la base de datos de Active Directory y los archivos de registro no deberían
ubicarse en el mismo disco duro. Una vez definidas las carpetas, haga clic en Siguiente.

Aparece un resumen con las distintas opciones que ha seleccionado a lo largo del asistente.
Puede, también, visualizar los comandos PowerShell que se ejecutarán para realizar estas
acciones haciendo clic en Ver script. El archivo de respuestas creado permitirá realizar la
instalación de un servidor RODC por línea de comandos sin intervención por parte del
usuario (observe que la contraseña de restauración del servicio de directorio no se
almacenará directamente en este archivo, y deberá indicarla antes de utilizar el archivo de
instalación sin que el asistente le solicite introducir la contraseña en el momento necesario).
Haga clic en Siguiente para ejecutar el asistente de verificación. Éste le avisará si existe
alguna configuración incorrecta (dirección IP dinámica, etc.). Si bien no es obligatorio
resolver estos errores para ejecutar la instalación del servidor RODC, es muy
recomendable. Haga clic en Instalar. Es necesario reiniciar el servidor para que se tengan
en cuenta las modificaciones. El servidor se agregará automáticamente al dominio como
RODC.

Sepa que es posible Crear previamente una cuenta de controlador de dominio de sólo
lectura desde un controlador de dominio existente. Esta opción está disponible desde la
consola ADAC, seleccionando su dominio en Domain Controllers.

El servidor RODC está instalado. Debe, a continuación, configurar la directiva de

replicación de contraseña desde un controlador de dominio que permita la escritura. En
efecto, cuando un servidor RODC recibe una solicitud de autentificación, consulta la
directiva de replicación de contraseña para determinar si debe o no almacenar en memoria
la contraseña del usuario (o del equipo) que acaba de autentificarse. Por defecto, no se
almacena en memoria ninguna contraseña. Según sus necesidades, puede escoger entre una
directiva de replicación de contraseña más o menos severa.

Para definir una directiva de replicación de contraseña, proceda de la siguiente manera

desde un controlador de dominio (no RODC):

Abra el Centro de administración de Active Directory y vaya al nivel correspondiente a la

unidad organizativa Domain Controllers. Haga clic con el botón derecho del ratón sobre el
controlador de dominio de solo lectura y, a continuación, en Propiedades.

A nivel de Extensiones, haga clic en la pestaña Directiva de replicación de contraseña.

Tal y como hemos visto anteriormente, un servidor RODC almacena únicamente aquellas
contraseñas de cuenta de usuario o grupo que se definen con el valor Autorizar (para estar
autorizados a tener su contraseña replicada en el servidor RODC). Por defecto, la
replicación de la contraseña se rechaza para las cuentas de administración como Operadores
de cuenta, Operadores de copia de seguridad, Administradores, etc. Agregar la cuenta que
desee y seleccione si su contraseña se autoriza o no a replicarse en el servidor RODC y, a
continuación, haga clic en Aceptar para seleccionar la cuenta de usuario o de grupo en su
dominio. Valide haciendo clic en Aceptar.

Haciendo clic en el botón Opciones avanzadas, puede mostrar el nombre de las Cuentas
cuyas contraseñas están almacenadas en este controlador de dominio de sólo lectura.
 Puede, también, seleccionar en la lista desplegable visualizar las Cuentas autenticadas en
este controlador de dominio de sólo lectura. Resulta, en efecto, interesante conocer quién
está autentificado mediante este RODC y, de este modo, modificar la directiva de
replicación de contraseña para alojar en caché la contraseña de estos usuarios y así evitar
consultas inútiles hacia un controlador de dominio de escritura. Puede, también, seleccionar
la opción de Rellenar contraseñas previamente. Esto puede resultar muy útil si instala su
RODC desde su sitio principal y rellena las contraseñas que quiere alojar en caché de los
usuarios del sitio secundario (sobre el que se desplazará, a continuación, el servidor
RODC). Habrá, también, que rellenar las cuentas de equipo utilizadas por los usuarios
agregados. Esto evitará tener que utilizar la conexión WAN entre dos sitios durante la
primera autentificación de los usuarios en el sitio secundario. Es decir, las cuentas
seleccionadas deberá, previamente, agregarse a la directiva de replicación de contraseña,
pues sin ello el rechazo implícito evitará que se almacene la contraseña en caché.

Sepa que es posible rellenar previamente las contraseñas utilizando el siguiente comando:
repadmin /rodcpwdrepl [DSA_List] <Hub DC> <User1 Distinguished Name>
[<Computer1 Distinguished Name> <User2 Distinguished Name> ...]

Exemplo: para rellenar la contraseña de la cuenta de usuario Fernando ROMERO (y de su

equipo portítil LAP_FRO) sobre un servidor RODC llamada RODCSrv01 desde un
controlador de dominio de escritura llamado DCSrv02, el comando sería: Repadmin
/rodcpwdrep1 RODCSrv01 DCSrv02 "CN=FernandoROMERO, OU=Usuarios_IT,
DC=miempresa, DC=priv" "CN=LAP_FRO, OU=Equipos_IT, DC=miempresa, DC=priv"

En caso de robo de un servidor RODC, podrá controlar de manera muy sencilla aquellas
cuentas impactadas y, de este modo, limitar los potenciales riesgos de seguridad debidos al
robo del servidor. Como administrador, aquí se muestra cómo debería reaccionar ante tal
situación:

Desde un controlador de dominio de escritura, abra la consola Usuarios y equipos de

Active Directory (dsa.msc) y vaya al nivel de la unidad organizativa Domain Controllers.
Haga clic con el botón derecho sobre la cuenta de equipo del controlador de dominio de
solo lectura y, a continuación, seleccione Eliminar. Confirme el borrado haciendo clic en
Sí.

Se muestra una ventana que le permite forzar la reinicialización de la contraseña para las
cuentas de usuario y/o equipo. También le permite exportar la lista de cuentas que estaban
en caché. Una vez seleccionadas las opciones, haga clic en Eliminar.

Su controlador de dominio RODC se suprime, incluso si un atacante trata de explotar las

contraseñas almacenadas en el mismo, no tendrán ninguna utilidad puesto que se habrían
modificado rápidamente.
d. Directivas de contraseña específica y de bloqueo de cuenta granular

Una de las principales mejoras esperadas tras varios años por los profesionales de la
informática que utilizan el directorio de Microsoft es, sin duda alguna, la posibilidad de
poder definir directivas de contraseña múltiples sobre un dominio de Active Directoy. No
ha sido, en efecto, posible realizar esta operación hasta Windows Server 2008.

Desde Windows Server 2008, existe una nueva clase de objetos llamada msDS-
PasswordSettings. Hace posible la multiplicación de las directivas de contraseña en el
seno de un mismo dominio. Sobre un dominio de Active Directory existente, anterior a
Windows Server 2008, habrá que actualizar el nivel funcional del dominio al menos a
Windows Server 2008 (todos sus controladores de dominio deberán, por tanto, ejecutar
como mínimo Windows Server 2008).

De este modo, es posible definir un objeto "parámetros de contraseña" (llamado también

PSO por Password Settings Object) distinto entre los usuarios. En la práctica, puede tener
una duración de vida máxima de contraseña de 30 días para las cuentas de
administrador. Las cuentas de servicio tendrán una longitud mínima de contraseña de 36
caracteres que jamás expira.

Por defecto, sólo los miembros del grupo Administradores de dominio tienen la
posibilidad de definir directivas de contraseña múltiples.

Tomemos el ejemplo de la definición de una directiva de contraseña específica para las

cuentas de usuario utilizadas para la administración del sistema de información. Estas
cuentas de usuario forman parte de grupos de seguridad con muchos permisos sobre el
dominio y si se comprometiera la seguridad de su contraseña se permitiría a un potencial
atacante tener acceso prácticamente a todos los servidores. Conviene, por tanto, dotar de
una seguridad especial a este tipo de cuentas de usuario algo especiales. Los parámetros de
contraseña serán los mismos que los definidos a nivel de la directiva Default Domain
Policy, a diferencia de la duración de vida máxima de la contraseña que será de 30 días en
lugar de 42 días. La longitud mínima de la contraseña pasará de 7 a 14 caracteres. La
cuenta se bloqueará, a su vez, tras 10 intentos fallidos. Estos principios limitan los riesgos
de compromiso de la contraseña de los administradores.

Windows Server 2012 ha simplificado enormemente la configuración de una directiva de

contraseña específica. Ya no es necesario utilizar la consola Editor ADSI como ocurría con
las versiones anteriores de Windows.

Ejecutando la consola ADAC (forzosamente desde un servidor Windows Server 2012/2012

R2, o Windows 8/8.1 con las herramientas RSAT instaladas), es posible gestionar las
contraseñas existentes, visualizarlas y aplicarlas a un usuario concreto.

Para configurar una directiva de contraseña específica:

 Abra la consola ADAC (dsac.exe) desde una cuenta de usuario miembro del grupo
"Administradores de dominio". Seleccione el modo Vista de árbol en la parte superior
izquierda y, a continuación, despliegue su dominio y seleccione System - Password
Settings Container.

En la lista de tareas del panel derecho, haga clic en Nuevo y Configuración de

contraseña. Se abre una ventana en la que debe definir los distintos parámetros de su
elección.
La información correspondiente se encuentra en el directorio Active Directory, y es posible
visualizarla con la consola adsiedit.msc, a nivel de
Nombre_FQDN_De_Dominio/CN=System/CN=Password Settings Container.

• Nombre se corresponde con el atributo msDS-PasswordSettings.

• Prioridad se corresponde con el atributo msDS-PasswordSettingsPrecedence.
Debe tener un valor superior a 0 y permite arbitrar en caso de conflicto cuando se
aplican dos objetos PSO sobre el mismo usuario o grupo. Cabe recordar dos reglas
en el caso de que se apliquen varios parámetros a un mismo objeto. Se aplicará el
objeto PSO que disponga del valor de precedencia más débil, y una directiva
aplicada a nivel Usuarios será prioritaria sobre una directiva aplicada a nivel Grupo.

Prevea espaciar la numeración del atributo msDS-PasswordSettingsPrecedence entre cada

directiva PSO para poder jugar con las prioridades en un futuro.

• Longitud mínima de la contraseña: msDS-MinimumPasswordLength es una

cifra entera. El valor por defecto es 7 en el dominio. En nuestro ejemplo, se trata de
un PSO para las cuentas de administrador. El valor mínimo será, por tanto,
de 14 caracteres.
• Exigir historial de contraseñas: msDS-PasswordHistoryLength define el número
de contraseñas anteriores que no pueden utilizarse. Por defecto, su valor es de 24 en
el dominio.
• Las contraseñas deben cumplir con determinados requisitos de complejidad:
msDS-PasswordComplexityEnabled es un valor booleano que activa la
complejidad siempre que su valor sea TRUE (valor aconsejado).
 • Almacenar contraseñas con cifrado reversible: msDS-
PasswordReversibleEncryptionEnabled. Se trata de un valor booleano. Es
preferible indicar el valor FALSE salvo si se tienen necesidades particulares.
• Vigencia mínima de la contraseña: msDS-MinimumPasswordAge es una
duración que indica la duración de vida mínima de la contraseña para impedir al
usuario cambiar su contraseña de forma sucesiva hasta que supera el límite del
histórico de contraseñas para poder volver a utilizar su contraseña. El valor por
defecto es de 1 día. Su formato es 1:00:00:00.
• Vigencia C de la contraseña: msDS-MaximumPasswordAge es una duración que
indica la duración de vida máxima de la contraseña. Por defecto, la contraseña debe
cambiarse cada 42 días. En este ejemplo, seleccione una duración de vida máxima
de 30 días, es decir 30:00:00:00.
• Umbral de bloqueo de cuenta: msDS-LockoutThreshold define el número de
contraseñas erróneas que puede introducir el usuario antes de que se bloquee el
objeto. Se corresponde con el parámetro Umbral de bloqueo de cuenta que es igual
a 0 (lo que indica que la cuenta no se bloquea nunca). Es preferible informar un
número de intentos restringido para evitar ataques sobre la contraseña. Indique el
valor 10, por ejemplo
• Restablecer recuentos de bloqueo de cuenta tras (minutos): msDS-Lockout-
ObservationWindows permite Restablecer el contador de bloqueos de cuenta tras
la duración que usted elija. Indique un valor de 10 minutos, por ejemplo,
escribiendo 10:00:00:00.
• La cuenta se bloqueará: Durante un periodo de (minutos): msDS-Lockout-
Duración indica la duración del bloqueo de la cuenta si el número de contraseñas
erróneas supera el valor de msDS-LockoutThreshold. Indique un valor de
10 minutos, por ejemplo, escribiendo 10:00:00:00 (observe que existen controles de
coherencia que le advierten siempre que trate de implementar una configuración
irrealizable).
• Se aplica directamente a equivalente a configurar el atributo msDS-
PSOAppliesTo, capaz de contener varios valores (y, por tanto, varios usuarios y
grupos). Es preciso seleccionar el o los grupos de seguridad para los que se quiere
aplicar esta directiva haciendo clic en Agregar.

Aplique, preferentemente, una directiva de contraseña a un grupo en lugar de a un usuario

para poder, de este modo, gestionarla más fácilmente. Si desea conocer la directiva que se
aplica a un usuario, vaya a las propiedades de la cuenta en cuestión en la consola Centro de
administración de Active Directory y, a continuación, seleccione la opción Ver
configuración de contraseña resultante. Se lee el atributo msDS-ResultantPSO para
identificar la directiva asociada al usuario.
Si, desde el Centro de administración de Active Directory, edita las propiedades de una
cuenta de usuario, no podrá visualizar la PSO asociada al usuario si la PSO se ha definido
para un grupo. En este lugar verá, únicamente, el o las PSO que se han definido
directamente sobre el usuario.

e. Active Directory como servicio de Windows

Desde Windows Server 2008, es posible detener e iniciar el directorio Active Directory
desde cualquier controlador de dominio, pues se considera como un servicio de Windows.

Puede, por tanto, realizar operaciones de mantenimiento tales como la desfragmentación

offline de la base de datos del directorio Active Directory sin tener que reiniciar el servidor
en modo de Restauración del servicio de directorio.

Las actualizaciones de Windows que impactan al servicio de directorio ya no requieren

sistemáticamente el reinicio completo del servidor. Bastará con un simple reinicio del
servicio Active Directory.

La principal ventaja ligada al funcionamiento de Active Directory como servicio es que los
demás servicios instalados sobre el controlador de dominio ya no estarán inaccesibles
cuando se quiera realizar alguna operación de mantenimiento.

La desfragmentación de la base de datos del directorio Active Directory no volverá al

servicio DHCP (instalador sobre el mismo servidor) inaccesible.
Puede configurar el estado del servicio a nivel de la consola MMC Servicios, disponible en
las herramientas de administración o bien escribiendo services.msc en el menú Ejecutar.

El servicio aparece bajo el nombre completo Servicios de dominio de Active Directory.

El nombre del servicio es NTDS.

Cuando el estado del servicio se define como Detenido, los demás equipos ven al
controlador de dominio como un servidor miembro del dominio sobre el que las directivas
de grupo pueden aplicarse. El controlador de dominio se comporta igual que si estuviera en
modo Restauración de servicio de directorio. Su archivo ntds.dit está libre y si no existe
ningún controlador de dominio disponible para autentificar su apertura de sesión, tendrá
que utilizar la contraseña de la cuenta de administrador de restauración de servicios de
directorio cuando promocione el servidor como controlador de dominio.

Es importante tener en cuenta que si bien el servicio NTDS puede detenerse, hay que tener
en cuenta unas precauciones mínimas:

• El servicio NTDS no debe detenerse durante mucho tiempo. Por ejemplo, detener el
servicio sobre un controlador de dominio diciendo que el directorio se restablecerá
en caso de que falle algún controlador de dominio. En efecto, según la duración de
 la parada del servicio NTDS, los registros podrían considerarse como demasiado
viejos y no se replicarán.
• La parada del servicio NTDS no basta para realizar una restauración del Active
Directory. Es preciso utilizar el modo de Restauración de Servicios de Directorio
(Directory Services Restore Mode) DSRM para realizar una restauración
(autoritaria o no).
• No es posible abrir una sesión con la cuenta Administrador DSRM (que se
corresponde, en realidad, con la cuenta de Administrador local del controlador de
dominio) cuando se detiene el servicio NTDS y no existen más controladores de
dominio disponibles durante el intento de autentificación de cuenta. Es posible
modificar este comportamiento editando la clave
HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior
en su controlador de dominio.

Los posibles valores son los siguientes:

Clave DSRMAdminLogonBehavior
Valor 0 No permite abrir una sesión con la cuenta de administrador DSRM.
(por Para abrir una sesión con esta cuenta, será preciso que otro
defecto) controlador dominio esté disponible en el momento de realizar la
autentificación.
Valor 1 La cuenta de Administrador DSRM puede utilizarse cuando se
detiene el servicio AD DS.

Este valor es especialmente interesante si solo dispone de un

controlador de dominio o si la resolución de nombres definida sobre
el mismo apunta únicamente sobre sí mismo.
Valor 2 La cuenta de Administrador DSRM puede utilizarse para realizar la
autentificación en cualquier situación.

Hay que tener en mente que esta cuenta no se somete a ninguna

directiva de contraseña.

Observe, también, que el reinicio en modo DSRM puede realizarse de varias formas:

• Utilizando el comando shutdown con las opciones -o y -r.

• Utilizando la combinación de teclas [Windows] + C - Configuración -
Iniciar/Apagar - haciendo clic en la tecla [Mayús] haciendo clic en el botón
Reiniciar y seleccionar un motivo del tipo Recuperación.

Durante el reinicio, el servidor le propondrá varias opciones, entre ellas la opción de

Solucionar problemas, que permite recuperar el sistema operativo a partir de una imagen
de sistema, la ejecución de una consola de comandos o bien la opción Configuración que
le permitirá acceder al menú de inicio avanzado pudiendo, en particular, acceder al modo
DSRM.
Hay otro servicio que existe desde la aparición de Windows Server 2012 R2.

Se trata del servicio Servidor de la función de DS (DsRoleSvc), que está configurado, por
defecto, en modo Manual Arrancará automáticamente siempre que se le solicite durante la
configuración de un nuevo controlador de dominio, se agregue un nuevo bosque, un
dominio o un controlador de dominio, se elimine el rol Active Directory en un servidor o
cuando se clone un controlador de dominio.

f. Clonado de un controlador de dominio Active Directory virtualizado

La virtualización se ha convertido, en el espacio de unos pocos años, en un elemento

imprescindible en la mayoría de SI.

El capítulo Consolidar sus servidores está dedicado al hipervisor Hyper-V y sus novedades.

Windows Server 2012 incluye la posibilidad de virtualizar un controlador de dominio,

operación que era técnicamente posible en las versiones anteriores de Windows Server,
aunque estaba fuertemente desaconsejado puesto que Microsoft no daba soporte ni a los
snapshots, ni al clonado de un controlador de dominio (puede obtener más información
sobre estos riesgos en la siguiente dirección: http://support.microsoft.com/kb/888794).

Asociado a la Réplica Hyper-V, permite incluir los controladores de dominio virtualizados

en el plan de recuperación ante desastres (PRD) de las máquinas virtuales.

Un controlador de dominio puede, de este modo:

• Ser clonado sin riesgo alguno.

• Realizar una imagen instantánea (snapshot) de un controlador de dominio sin riesgo
de corromper el conjunto de la base de Active Directory.

Las ventajas de la virtualización de un controlador de dominio son:

• Poder desplegar rápidamente un controlador de dominio en un nuevo bosque o un

nuevo dominio.
• Poder remplazar con varios clics un controlador de dominio.
• Una mejor capacidad de evolución de la infraestructura de Active Directory si fuera
necesario.
• Implementación de manera sencilla de entornos de pruebas.

El controlador de dominio con el rol Emulador PDC debe utilizar Windows Server 2012
para poder implementar un controlador de dominio virtualizado (también llamado vDC).

El controlador de dominio de origen (el que se clonará) y el controlador de dominio

clonado deben tener el rol Hyper-V instalado y deben pertenecer al mismo dominio.
El controlador de dominio de origen debe ser un controlador de dominio virtualizado que se
ejecute como mínimo en un entorno Hyper-V 3 (y, por tanto, bajo Windows Server 2012).

El switch de la red virtual Hyper-V debe tener el mismo nombre en cada servidor Hyper-V.

Si ambos controladores de dominio no tuvieran el mismo procesador, desde el controlador

de dominio de origen, haga clic en su configuración en Hyper-V y, a continuación, en
Procesadores - Compatibilidad y seleccione la opción Migrar a un equipo físico con
una versión de procesador distinta.

Debe existir un servidor Windows Server 2012 R2 con el rol Hyper-V para albergar el
vDC. Si utilizara otro hipervisor, tendrá que ponerse en contacto con su proveedor para
verificar si este hipervisor tiene en cuenta el ID de generación de máquina virtual (también
llamado VM-Generation-ID). Este VM-Generation ID es un identificador único de 128 bits
que gestiona el hipervisor.

El controlador de dominio que quiere virtualizar debe disponer de los permisos suficientes
para ello (formando parte del grupo "Controladores de dominio clonables").

Observe que ciertos roles no pueden estar presentes en un servidor clonado, como por
ejemplo el servicio DHCP, AD CS y AD LDS.

Para crear un clon del controlador de dominio, debe realizar las siguientes etapas:

Desde un controlador de dominio que no se preste a clonarse, preferentemente, abra el

Centro de administración de Active Directory y agregue el controlador de dominio que se
virtualizará al grupo "Controladores de dominio clonables" (los grupos se encuentran en el
contenedor "Usuarios").

Existe un bug en Windows Server 2012 y 2012 R2 que le obligará a renombrar el grupo
"Controladores de dominio clonables" a "Clonable Domain Controllers", cambio sin el cual
el comando PowerShell que se ejecuta más adelante (New-ADDCCloneConfigFile) fallará.

Ejecute el comando Get-ADDCCloningExcludedApplicationList desde el controlador de

dominio que quiere virtualizar para identificar los servicios y programas que no son
clonables. Observe la lista devuelta y tome las medidas necesarias (elimine los elementos
afectados o cree una lista de exclusión) y, a continuación, ejecute el comando Get-
ADDCCloningExcludedApplicationList -Generate - Xml. Esto provoca que se agreguen
los servicios y programas suplementarios que no están presentes por defecto en la lista
provista en el archivo CustomDCCloneAllowList.xml (presente en %windir%\NTDS).

Ejecute el comando New-ADDCCloneConfigFile sobre el controlador de dominio de

origen. Esto provoca la creación del VM-Generation ID y crea un archivo
DCCloneConfig.xml en %windir%\NTDS. Este comando PowerShell permite predefinir
muchos elementos tales como la dirección IP, el nombre del servidor, etc. Todos los
parámetros posibles están disponibles en la siguiente dirección:
http://technet.microsoft.com/en-us/library/jj158947.aspx

Por ejemplo:

New-ADDCCloneConfigFile -Static -IPv4Address "172.16.0.3"

-IPv4DNSResolver "172.16.0.2" -IPv4SubnetMask "255.255.0.0"
-CloneComputerName "VirtualDC2" -IPv4DefaultGateway "172.16.0.254"
-SiteName "MADRID"

Por defecto, el controlador de dominio clonado pertenecerá al mismo sitio de Active

Directory que el controlador de dominio inicial, a menos que lo defina en el archivo
DCCloneConfig.xml.

Copie este archivo en la carpeta donde se encuentra la base de datos de Active Directory
sobre el controlador de dominio de origen (por defecto %windir%\NTDS).

El archivo DCCloneConfig.xml es uno de los componentes que permite iniciar el clonado

de un controlador de dominio.

Un controlador de dominio clonado se basa en dos elementos para detectar que es el

resultado de la copia de otro controlador de dominio:

• El VM-Generation-ID de la máquina virtual es distinto al que hay almacenado en la

base de datos Directory Information Tree (DIT) (%windir%\NTDS).
• Existe un archivo DCCloneConfig.xml presente en la ubicación de la DIT o en la
raíz de algún lector extraíble (lector DVD, por ejemplo).

El controlador de dominio clonado contacta, entonces, con el controlador de dominio que

alberga el rol emulador PDC (Windows Server 2012 como mínimo) utilizando el contexto
de seguridad del controlador de dominio de origen. Éste crea, a continuación, los objetos
necesarios en el Active Directory y, a continuación, el controlador de dominio clonado crea
los archivos de su base de datos y limpia su estado con ayuda del comando sysprep.

Para finalizar la implementación de un vDC:

Deje el vDC inactivo y expórtelo o cópielo (cree un ID único).

Cree una nueva máquina virtual importando la que acaba de exportar. Se configurará
automáticamente como controlador de dominio completo y se integrará perfectamente en su
infraestructura (a título informativo, sepa que en este momento se ejecuta el comando
sysprep sobre el nuevo controlador de dominio y lo instala como lo haría tras una
instalación a partir de un medio extraíble).

Preste atención: realizar un snapshot del vDC no remplaza a la copia de seguridad regular
del Active Directory.
He aquí una lista de los comandos PowerShell utilizados para realizar la gestión de
snapshots: Checkpoint-VM, Export-VMSnapshot, Get-VMSnapshot, Remove-
VMSnapshot, Rename-VMSnapshot y Restore-VMSnapshot.

g. Instantánea de Active Directory

Dejando a un lado los snapshots (o instantáneas) de los vDC; es posible, desde Windows
Server 2008, crear instantáneas de un Active Directory. La tecnología se basa en la API
VSS (Volume Shadow Copy o instantánea de volumen). Para ayudarle con las búsquedas
en inglés en Internet, sepa que esta funcionalidad también se denomina Database Mounting
Tool.

La principal ventaja es que es posible realizar una copia de seguridad de este tipo
incluso sobre archivos bloqueados. No es necesario, por tanto, detener el servicio de Active
Directory (para liberar los archivos asociados) para poder salvaguardar el archivo ntds.dit,
por ejemplo.

Puede acoplar el uso de instantáneas con el uso de la herramienta dsamain.exe para

evidenciar cualquier cambio a realizar en el Active Directory.

Por defecto, sólo los usuarios miembro del grupo Administradores de dominio y
Administradores de empresas están autorizados a acceder a las instantáneas creadas.

Para sacar el máximo provecho a las instantáneas para Active Directory, existen tres
herramientas indispensables:

• El comando ntdsutil para crear, eliminar, enumerar, montar, desmontar una copia de
seguridad (llamada, en esta ocasión, instantánea).
• El comando dsamain que se utiliza para mostrar las diferencias entre dos
instantáneas, por ejemplo.
• La herramienta ldp.exe para visualizar los datos de una instantánea de forma
gráfica.

El usuario solamente podrá acceder a aquellos datos salvaguardados sobre los que disponga
de permisos. Los permisos sobre los objetos de la copia de seguridad no pueden
modificarse, puesto que son de sólo lectura.

Para crear una instantánea del directorio Active Directory, utilice el comando ntdsutil.
Sepa, no obstante, que existen otros muchos programas comerciales que se basan en la
tecnología de instantáneas.

El comando que debe utilizar es:

ntdsutil snapshot "activate instance ntds" create

 Puede planificar la copia de seguridad de estas instantáneas mediante el Programador de
tareas. El comando que debe definir será, en este caso, ligeramente diferente, pues debe
salir del contexto ntdsutil.

ntdsutil snapshot "activate instance ntds" create quit quit

Una vez terminada la instantánea, puede seleccionar la opción de mostrar todas las
instantáneas creadas. Si ya se encuentra en el nivel instantánea, escriba únicamente List All
(en caso contrario el comando completo es ntdsutil snapshot "activate instance ntds" "List
All").

Tendrá, a continuación, que montar la instantánea que desee para poder leer los datos
salvaguardados:

mount x (donde x se corresponde con el número de instantánea).

Una vez montada la instantánea, escriba quit dos veces seguidas para volver a una línea de
comandos clásica.

Creación de una instantánea del directorio Active Directory y montaje de una de sus copias
de seguridad.

A continuación es preciso asociar esta copia de seguridad con un servidor LDAP virtual
mediante el comando dsamain.
Abra una ventana de comandos con una cuenta de usuario miembro del grupo
Administradores de dominio o Administradores de empresas y escriba el siguiente
comando:

dsamain /dbpath <Ruta de la base de datos de AD>

/ldapport <número de puerto no utilizado>

La ruta de la base de datos se encuentra a nivel del comando ejecutado anteriormente y

tiene el formato C:\$SNAP_XXXXXX_VOLUMEC$\ sobre el que deberá agregar la ruta
completa hacia la base de datos de Active Directory, generalmente
WINDOWS\NTDS\NTDS.dit

Si el firewall está activado, obtendrá, probablemente, un mensaje de advertencia para

agregar una regla para el ejecutable dsamain, puesto que pone al puerto LDAP especificado
en escucha.

Si el dominio desde el que había creado la instantánea no existe, tendrá que agregar el
argumento /allowNonAdminAccess.

Su servidor LDAP virtual está, ahora accesible mientras tenga la ventana de comandos
abierta.

Conéctese a través de un cliente capaz de acceder a los datos de este servidor LDAP. En
este ejemplo, utilizará la herramienta ldp.exe, disponible, por defecto, en Windows.

Desde el menú Inicio - Ejecutar, escriba el comando ldp.exe.

Haga clic, a continuación, en Conexión y Conectar. En la dirección del servidor, escriba

la dirección IP del servidor e indique el puerto definido anteriormente en dsamain (51389
en nuestro caso). A continuación, haga clic en OK.
Verifique el tipo de enlace mediante el menú Conexión - Enlazar. Asegúrese de definir
una cuenta de usuario con los permisos suficientes. Una vez configurado, haga clic en
Aceptar para autentificarse sobre este archivo de directorio.

Haga clic, a continuación, en Ver - Árbol, y defina el nombre único de la base de datos
correspondiente con su nombre de dominio; en el ejemplo DC=miempresa, DC=priv.

Puede, a continuación, navegar en la copia de seguridad de su directorio a través de esta

herramienta.

Si le parece que el acceso a los datos no es muy amigable a través de la herramienta

ldp.exe, sepa que puede, si sus necesidades son más limitadas, ver sus datos directamente
desde la consola Usuarios y equipos de Active Directory. Para ello, haga clic con el botón
derecho del ratón en la raíz de la consola y, a continuación, seleccione la opción Cambiar
el controlador de dominio. Haga clic en el mensaje <Escriba aquí un nombre de
servidor de directorio[:puerto]> para informar el nombre de su controlador de dominio y
el puerto definido anteriormente. Accederá, así, a su directorio de forma más sencilla que
con la herramienta ldp.exe. Para complementar esta información, no hay que olvidar la
fabulosa herramienta ADExplorer (http://technet.microsoft.com/en-
us/sysinternals/bb963907.aspx). Le permitirá comparar fácilmente dos instantáneas
(creadas mediante esta herramienta), lo cual puede resultar extremadamente útil.

Una vez haya finalizado, no olvide cerrar la herramienta dsamain ([Ctrl] C dos veces) y
desmontar el directorio mediante el comando ntdsutil snapshot "activate instance ntds"
"unmount x" donde x es el número de instantánea.

Observe que la herramienta DSCT (Directory Service Comparison Tool) será muy útil si
utiliza instantáneas. Le permite, entre otros, comparar un snapshot con la base de datos de
Active Directory actual y visualizar todas las diferencias entre ambos estados (elementos
agregados, eliminados, etc.). No se trata de una herramienta oficial de Microsoft. Está
disponible en la siguiente dirección: http://blog.frli.se/p/dsct.html

h. Las cuentas de servicio administradas

Habitualmente, durante la instalación por defecto de una aplicación, el administrador puede

configurar la misma para ejecutar su servicio asociado como Local System, Local Service o
Network Service.

También es posible informar una cuenta de dominio para ejecutar este servicio, aunque esta
cuenta de dominio debe, generalmente, tener una contraseña que jamás expire. Además, la
seguridad de esta cuenta deja mucho que desear, puesto que la contraseña se encuentra en la
caché LSA, que resulta fácilmente accesible.
Se han creado dos nuevas cuentas de servicio con la salida de Windows Server 2008 R2 (y
Windows 7). Se trata de las "cuentas de servicio administradas autónomas" (también
llamadas Standalone Managed Service Accounts o sMSA) y las cuentas virtuales (virtual
accounts). Un tercer tipo de objeto ha aparecido con Windows Server 2012, las cuentas de
servicio administradas de grupo (Group Managed Service Accounts, o incluso gMSA).

Gracias a estos nuevos tipos de cuenta, puede extender la gestión de las contraseñas puesto
que estos últimos objetos se renovarán automáticamente. Ya no es preciso tener que definir
una cuenta de servicio con una contraseña que no expire jamás, puesto que el sistema la
renovará automáticamente, de forma transparente, sin interrupción en el servicio.

• Las sMSA son dos tipos de cuenta de dominio que se utilizan para ejecutar
servicios. Se utilizan para que su contraseña se cambie automáticamente, de cara a
simplificar la gestión de los SPN (Service Principal Name). Recuerde que el SPN es
necesario para la autenticación Kerberos.

Esto permite, además, mejorar la seguridad de la contraseña de la cuenta de dominio

utilizada para la ejecución de aplicaciones como SQL Server, IIS, Exchange, o
cualquier otro servicio, con la condición de que las cuentas sMSA estén soportadas
por el fabricante de su aplicación asociada.

• Las cuentas de máquinas virtuales son cuentas de servicio locales que no

requieren una gestión de su contraseña. Los identificadores de la cuenta de equipo
se utilizan cuando el servicio debe acceder a los recursos presentes en el dominio.
Estas cuentas se definen a nivel de las propiedades del servicio desde la consola
Servicios (services.msc), pestaña Conexión y, a continuación, indicando el nombre
de usuario NT Service\NombreDeCuenta, sin contraseña. Tras reiniciar el
servicio, se ejecutará con un nombre de usuario que incluirá el nombre del servicio.

El inconveniente de los sMSA y de las cuentas virtuales es que no son capaces de compartir
su cuenta en varios equipos. Observe que son compatibles únicamente con clientes
Windows 7/8/8.1/2008 R2/2012/2012 R2.

• Las gMSA(group Managed Service Account o cuentas de servicio administradas de

grupo) han aparecido con Windows Server 2012 y permiten, a diferencia de las
xMSA, estar asociadas a un servicio (o una tarea programada, o incluso un pool de
aplicaciones IIS, SQL Server, etc.) que se utilizará sobre varios servidores (una
granja de servidores con el servicio de Equilibrio de carga de red, por ejemplo). El
uso de un gMSA está condicionado por el hecho de que todas las instancias de los
servicios utilizan el mismo principal. Para ello, esta nueva tecnología se basa en el
nuevo servicio de distribución de claves de Microsoft, que se encarga de proveer
una clave a una cuenta basada en un secreto compartido con este último. Windows
Server 2012/2012 R2 calcula la contraseña sobre la clave provista y sólo los clientes
Windows 8/8.1/2012/2012 R2 son capaces de obtener los valores de la contraseña
de estas cuentas.
Vamos a centrarnos aquí, en particular, en el uso de las cuentas de servicio administradas
de grupo, pues presentan ventajas importantes en grandes entornos informáticos.

Principio general

La cuenta de servicio administrada utiliza el mismo funcionamiento y la misma frecuencia

de refresco de contraseña que la cuenta de equipo, es decir, cada 30 días, por defecto,
aunque veremos más adelante que esta opción es configurable. No responde a ninguna regla
de su política de contraseña de dominio ni a ningún PSO (directiva de contraseña única).
No puede, tampoco, bloquearse ni es posible abrir una sesión con esta cuenta.

La contraseña auto-generada utiliza un cifrado seguro que permite generar una contraseña
de 240 caracteres aleatorios (120 para una gMSA).

En términos de limitación del uso de esta cuenta, sepa que no puede utilizarse en todos los
servicios de Windows (es posible que obtenga el error 1297 durante el arranque del
servicio, por ejemplo).

Una cuenta sMSA puede utilizarse, únicamente, sobre un equipo cada vez (aunque puede
ejecutar varios servicios sobre este mismo equipo). No será, por tanto, posible utilizar una
MSA para clústeres o servicios de equilibrio de carga de red. En estos casos será preciso
utilizar una cuenta gMSA tal y como se ha visto anteriormente.

El Service Pack 1 de Windows Server 2008 R2 permite, a su vez, definir una MSA
asociada a un servicio instalado sobre un servidor miembro del dominio y que se encuentra
sobre una red delimitada (DMZ, extranet, etc.). Antes del SP1, esta operación fallaba si el
único controlador de dominio presente en la misma red que el servidor que ejecutaba la
MSA era un RODC (controlador de dominio de solo lectura). En lo sucesivo, las MSA
funcionan, pues los RODC están preparados para redirigir la consulta de la MSA hacia un
controlador de dominio de escritura.

Requisitos previos

Los requisitos previos que permiten utilizar las MSA son los siguientes:

• Un dominio Active Directory con, al menos, un controlador de dominio en

Windows Server 2012.
• Una actualización del esquema en versión 2008 R2 para las sMSA y las cuentas de
equipo virtuales. No es preciso tener un nivel funcional de dominio o del bosque en
2008 R2 para que la renovación automática de la contraseña funcione. Por el
contrario, si el nivel funcional es 2003 o 2008, el administrador deberá definir
manualmente el SPN de estas cuentas MSA. Con un nivel funcional 2008 R2 o
superior, el SPN se define automáticamente.
 • Un equipo con Windows Server 2008 (o superior) o Windows 7 (o superior) que
contengan el servicio a configurar, si se trata de una sMSA, o Windows Server
2012/Windows 8 (o posterior) para configurar una gMSA.
• Disponer de las funcionalidades PowerShell, el módulo Active Directory para
PowerShell (disponible en las herramientas de administración RSAT para
Windows 7 en la siguiente dirección: http://www.microsoft.com/es-
es/download/details.aspx?id=7887 y para Windows 8 en:
http://www.microsoft.com/es-es/download/details.aspx?id=28972) y, si fuera
necesario, al menos el .NET Framework 4.5 instalado en los ordenadores
encargados de configurar las cuentas MSA. Con Windows Server 2012/2012 R2, es
posible agregar el módulo Active Directory para PowerShell desde el
Administrador del servidor - Administrar - Agregar roles y características.

En la medida en que la gMSA debe configurarse desde un controlador Windows

Server 2012 (o posterior), el hecho de agregar este módulo sólo es útil en el caso de
que se quiera crear una sMSA desde una versión anterior.

Observe, por último, que un vDC (controlador de dominio virtual) soporta

únicamente las gMSA pero no las sMSA.

• Un servicio de Windows que soporte el uso de una cuenta MSA.

Instalación y configuración
Tras la extensión del esquema a 2008, se crea una nueva clase de objetos. Se trata de la
clase llamada msDS-ManagedServiceAccount. Si quiere delegar la creación de esta
cuenta, tendrá que verificar, previamente, que el usuario que crea la cuenta MSA posee los
permisos Create/Delete msDS-ManagedServiceAccount.

Tras la extensión del esquema en 2012, se crea otra clase de objetos. Se trata de la clase
msDS-GroupManagedServiceAccount.

Viendo los requisitos previos para instalar PowerShell, habrá comprendido que los pasos se
desarrollarán, a continuación, por línea de comandos en lugar de mediante interfaz gráfica.

Veremos, por tanto, las etapas detalladas que permiten crear una cuenta MSA y utilizarla
para ejecutar una tarea programada. Esta tarea programada es un script que debe ejecutarse
sobre todos los controladores de dominio que utilicen una cuenta con los permisos de
Administrador. Antes, era obligatorio definir una cuenta con permisos muy amplios y cuya
contraseña no cambiara jamás. Ahora, es posible utilizar una gMSA para ello. Las etapas
principales son:

• La creación de la clave de raíz principal de los servicios de distribución de claves

(Key Distribution Services KDS Root key).
• La creación de la cuenta MSA en el Active Directory.
• La asociación de la cuenta MSA con un equipo que sea miembro del Active
Directory.
• La instalación de la cuenta MSA sobre el equipo asociado.
• La configuración del servicio para que este último utilice la cuenta MSA.

Para crear, en primer lugar, una cuenta gMSA, conéctese a su controlador de dominio
Windows Server 2012/2012 R2 y cree sus claves de distribución raíz para estar seguro de
poder crear una cuenta gMSA. En efecto, a diferencia de las sMSA, las gMSA las gestiona
y mantiene el KDS (Key Distribution Service) desde un controlador de dominio Windows
Server 2012/2012 R2.

Ejecute la consola PowerShell. El módulo PowerShell Active Directory se cargará

automáticamente. Ejecute el siguiente comando sobre su entorno de producción para
generar una clave raíz, necesaria para la creación de una contraseña para una cuenta gMSA:

Add-KdsRootKey -EffectiveImmediately

Sólo podrá finalizar el resto del procedimiento tras esperar 10 horas, de cara a dejar tiempo
a la clave generada para que se replique sobre todos los controladores de dominio
(evitando, de este modo, que falle la autenticación en caso de que ésta no se replique).

Si se encuentra en un entorno de pruebas, he aquí el comando que puede ejecutar para

poder continuar de inmediato con el resto del procedimiento:

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

 Cree un grupo de seguridad y agregue todas las cuentas de equipo que están autorizadas a
utilizar la gMSA. Se trata de una buena práctica que permite una mejor gestión de estos
accesos. Sepa que si elimina un equipo de este grupo, tendrán que reiniciarlo para que se
tenga en cuenta la modificación.

En nuestro ejemplo, crearemos un grupo "Domain Controllers" y haremos miembros del

mismo a todos los controladores de dominio afectados.

Cree, ahora, la cuenta gMSA desde la consola PowerShell. Tendrá que indicar, al menos,
un nombre (SamAccountName) y un nombre de DNS. Opcionalmente, aunque muy útil, el
parámetro PrincipalsAllowedToRetrieveManagedPassword que le permite especificar el
grupo autorizado a utilizar la cuenta gMSA. Es posible utilizar el SPN, eventualmente.

New-ADServiceAccount -Name <Nombre De Cuenta MSA>

-DNSHostName <Nombre FQDN>
-PrincipalsAllowedToRetrieveManagedPassword <Grupo>
-ServicePrincipalNames <SPN1, SPN2,...>

Por ejemplo:

New-ADServiceAccount MiMSA -DNSHostname MiCuenta.MiEmpresa.Priv

-PrincipalsAllowed-PrincipalsAllowedToRetrieveManagedPassword
"Domain Controllers"

Si quiere definir un intervalo particular para el cambio de la contraseña de la cuenta gMSA,

tendrá que definirla obligatoriamente durante la creación de la cuenta; en caso contrario, se
verá obligado a tener que volver a crear una cuenta con el parámetro conveniente. Por
defecto, el valor es de 30 días, y puede modificarlo mediante el parámetro
ManagedPasswordIntervalInDays.

Para evitar cualquier error a la hora de introducir los comandos en PowerShell, puede
utilizar la opción de auto-completar presionando la tecla [Tab] tras escribir las primeras
letras del comando. Sepa, también, que una vez creada la cuenta MSA, será visible desde la
consola Usuarios y equipos de Active Directory o desde el Centro de administración de
Active Directory a nivel del contenedor Managed Service Accounts.

La cuenta está creada y es posible visualizarla desde la consola ADAC, en la OU Managed

Service Accounts.
Puede agregar esta cuenta MSA a un grupo de seguridad Active Directory. Para ello, edite
el grupo deseado y agregue un miembro. Especifique, a continuación, el nombre de la
cuenta MSA recién creada. El cmdlet PowerShell Add-ADGroupMember o el cmdlet
dsmod también permiten realizar esta acción.

Una vez creada la cuenta MSA, la buena práctica consiste en instalar y probar la cuenta
gMSA. Desde un comando PowerShell sobre el servidor que utilizará la cuenta gMSA:

Install-ADServiceAccount <Nombre de la cuenta MSA creada anteriormente>

Test-ADServiceAccount <Nombre de la cuenta MSA creada anteriormente>

Si obtuviera un mensaje de error, se debe a que hemos integrado nuestros controladores de

dominio (en el marco de este ejemplo, únicamente) con un grupo de seguridad; mientras no
reinicie el controlador de dominio desde el que está realizando la prueba, obtendrá un
mensaje de error siempre que ejecute estos dos comandos.

En nuestro ejemplo, se trata de un controlador de dominio, pero según sus necesidades

podría ser cualquier servidor con Windows Server 2012/2012 R2 o Windows 8/8.1 (para la
gMSA).

Si desea delegar esta etapa sin tener que otorgar permisos de administrador de dominio a su
usuario, puede delegar los permisos sobre la MSA específica mediante el siguiente script,
que debe ejecutarse desde una ventana de línea de comandos:

dsacls "CN=<Nombre de cuenta MSA creada en la etapa anterior>,

CN=Managed
Service Accounts,DC=miempresa,DC=local" /G
"DOMINIO\<Usuario o grupo>:SDRCLCRPLOCA"
"DOMINIO\<Usuario o grupo>:WP;Logon Information"
"DOMINIO\<Usuario o grupo>:WP;Description"
"DOMINIO\<Usuario o grupo>:WP;DisplayName"
"DOMINIO\<Usuario o grupo>:WP;Account Restrictions"
"DOMINIO\<Usuario o grupo>:WS;Validated write to DNS host name"
"DOMINIO\<Usuario o grupo>:WS;Validated write to service principal name"

La cuenta MSA puede, ahora, asociarse al servicio soportado mediante la interfaz gráfica
abriendo la consola services.msc y, a continuación, especificando el nombre de usuario en
la pestaña Iniciar sesión - Esta cuenta. La cuenta que debe indicar debe tener el siguiente
formato: Dominio\NombreDeMSA$ (no olvide el dólar) sin informar ninguna contraseña.

Windows será capaz de asignar el permiso "Abrir una sesión como servicio" a la cuenta, si
no dispone de él.

También es posible asociar esta cuenta MSA mediante un script PowerShell del siguiente
tipo:

$MSA="dominio\NombreDeMSA$"
$ServiceName="’Nombre_Del_Servicio’"
$Password=$null
$Service=Get-Wmiobject win32_service -filter "name=$ServiceName"
$InParams = $Service.psbase.getMethodParameters("Change")
$InParams["StartName"] = $MSA
$InParams["StartPassword"] = $Password
$Service.invokeMethod("Change",$InParams,$null)
Modifique y guarde a continuación este archivo con ayuda de un editor de texto en un
archivo con extensión ps1.

Para ejecutar un script en PowerShell, habrá que disminuir la política de seguridad por
defecto mediante el comando Set-ExecutionPolicy, ejecutar el script y, a continuación,
redefinir la política de seguridad por defecto.

Set-ExecutionPolicy remotesigned
Script.ps1
Set-ExecutionPolicy restricted

En nuestro caso, queremos definir una tarea programada que utilizará una cuenta gMSA
para ejecutarse, proceda de la siguiente manera:

Como la interfaz gráfica no permite definir una cuenta gMSA desde la interfaz gráfica del
programador de tareas, va a ser preciso utilizar PowerShell:

$action = New-ScheduledTaskAction "E:\Scripts\backup.cmd"

$trigger = New-ScheduledTaskTrigger -At 8:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID Dominio\<Nombre de
cuenta
MSA creada anteriormente> -LogonType Password

Action: se corresponde con la acción ejecutada (el script backup.cmd).

Trigger: define la programación de la tarea.

Principal: indica la cuenta utilizada. Aquí, cabe destacar que hay que especificar bien la
contraseña "Password" en el argumento -LogonType. Se trata de la palabra clave que el
sistema reconocerá para ir a buscar la contraseña actual de la gMSA.

De este modo, para crear la tarea programada basándose en estas variables, es preciso
ejecutar el comando:

Register-ScheduledTask BackupViagMSA_Tarea -Action $action -Trigger

$trigger -Principal $principal

No olvide, tampoco, asignar el permiso a la cuenta gMSA para iniciar sesión como
proceso por lotes sobre los servidores (a través de la consola Administración de directivas
de grupo a nivel de Configuración del equipo - Directivas - Configuración de Windows
- Directiva de seguridad - Directiva local - Asignación de derechos de usuario).

A continuación, se creará la tarea y será visible desde las Herramientas administrativas -

Programador de tareas.

Para eliminar una cuenta MSA, tendrá que utilizar el siguiente comando PowerShell:

Remove-ADServiceAccount -identity <Nombre de la cuenta MSA>

Puede, también, eliminarla de Active Directory, mediante la consola Centro de
administración de Active Directory. También es posible eliminar la cuenta MSA del
servidor que la utiliza, mediante el siguiente comando:

Remove-ADComputerServiceAccount -Identity <Nombre NetBIOS del

equipo que utiliza la MSA> -ServiceAccount <Nombre de la cuenta MSA>

El comando Uninstall-AdServiceAccount desinstala la cuenta del servidor aunque no la

elimina de Active Directory, a diferencia del comando anterior.

Acaba de configurar su cuenta MSA para el equipo que lo necesita. De este modo, no
tendrá que preocuparse de la gestión de la contraseña de este servidor.

Puede consultar más información técnica sobre la implementación de las MSA en la

siguiente dirección: http://technet.microsoft.com/es-es/library/dd548356(WS.10).aspx

i. La papelera de reciclaje de Active Directory

Windows Server 2008 R2 introduce una funcionalidad que hará feliz a más un
administrador. ¡Se trata de una papelera de reciclaje para objetos Active Directory!

En efecto, en lo sucesivo, es posible restaurar un objeto de Active Directory que se haya

eliminado sin tener que restaurar la última copia de seguridad, incluso sin tener que detener
el servicio de uno de sus controladores de dominio (teniendo que reiniciarlo en modo
DSRM y utilizando el comando NTDSUTIL). En lo sucesivo, es posible, gracias a esta
funcionalidad, restaurar un objeto creado tras su última copia de seguridad disponible de
Active Directory.

Observe que desde Windows Server 2003 es posible utilizar la reanimación de objetos
eliminados (durante 180 días, por defecto). El inconveniente principal de esta solución es
que no restaura algunos atributos a un valor vinculado sino no vinculado.

En concreto, esto significa que la restauración de una cuenta de usuario siguiendo este
método no restaura su pertenencia a los grupos de seguridad y es preciso, por tanto, conocer
esta información para agregarla a continuación.

¡La papelera de reciclaje de Active Directory le simplificará enormemente esta tarea!

Antes de entrar en detalle a ver cómo puede implementarse, veamos, en primer lugar, su
principio de funcionamiento.

Principio general

La funcionalidad de la papelera de reciclaje Active Directory se basa en cuatro atributos de

Active Directory.

isDeleted
Este atributo existe desde Windows 2000 Server. Está presente sobre todos los objetos del
directorio. Indica si un objeto se ha eliminado pero puede ser restaurado.

isRecycled

Este atributo existe desde Windows Server 2008 R2. Está presente en todos los objetos
eliminados una vez se activa la función de papelera de reciclaje de Active Directory. Indica
que un objeto puede restaurarse utilizando la función de la papelera de reciclaje de Active
Directory.

msDS-DeletedObjectLifetime

Este atributo existe desde Windows Server 2008 R2. Su valor determina el tiempo (en días)
durante el que podrá restaurarse un objeto eliminado. Por defecto, su valor es igual al valor
del atributo TombstoneLifetime.

TombstoneLifetime

Este atributo existe desde Windows 2000 Server. Desde Windows Server 2003 SP1, su
valor por defecto es de 180 días. Este número de días sirve para propagar la información
sobre un objeto eliminado a todos los controladores de dominio.

Veamos, por tanto, qué ocurre cuando se elimina un objeto (una cuenta de usuario, por
ejemplo) de Active Directory:

• Cuando se elimina un objeto, éste se desplaza al contenedor Deleted Objects que se

encuentra en la raíz del dominio (en nuestro ejemplo: CN=Deleted
Objects,DC=miempresa,DC=priv) y el atributo isDeleted toma el valor TRUE. El
administrador dispone, entonces, del número de días definido en el atributo msDS-
deletedOjectLifetime para restaurar el objeto mediante la funcionalidad de la
papelera de reciclaje de Active Directory. Por defecto, su valor es igual al valor del
atributo TombstoneLifetime, es decir, 180 días en la mayoría de situaciones. Dicho
de otro modo, un objeto puede restaurarse mediante la papelera de reciclaje de
Active Directory hasta 180 días después de su borrado, por defecto.
• Una vez superado el número de días definido por el atributo msDS-Deleted-
ObjectLifetime, el atributo isRecycled recibe el valor TRUE. El objeto entra,
entonces, en un nuevo estado disponible desde Windows Server 2008 R2 llamado
"Recycled object" (disculpe el término anglosajón, pero no existe una traducción al
castellano para este término en el momento de escribir estas líneas).

Llegado este momento, el objeto no puede restaurarse por completo (ni a través de la
papelera de reciclaje de Active Directory, ni mediante una restauración completa) y pierde
ciertos atributos cuyo valor estaba vinculado, a un estado no vinculado. El objeto queda,
entonces, en este estado durante el tiempo definido por el valor del atributo
TombstoneLifetime, de nuevo 180 días. El principal interés de este estado es avisar a los
demás controladores de dominio que se ha eliminado un objeto.
 • Una vez superado el número de días definido por el atributo TombstoneLifetime
(un total de 180 + 180 días, es decir, 360 días tras el borrado de la cuenta de
usuario), el objeto se elimina "realmente" de Active Directory.

He aquí un esquema resumen:

Requisitos previos

Los requisitos previos necesarios para utilizar la papelera de reciclaje de Active Directory
no son despreciables. En efecto, es preciso que todos los controladores de dominio del
bosque ejecuten, al menos, Windows Server 2008 R2.

Será necesario, a continuación, extender el esquema a Windows Server 2008 R2 o superior

(hemos explicado cómo hacerlo en la sección Instalación de un directorio de Active
Directory).

Cabe destacar, también, que activando la funcionalidad de papelera de reciclaje de Active

Directory, no será posible disminuir el nivel funcional del dominio ni del bosque sin bajar
del nivel Windows Server 2008 R2.

Activación y uso

La activación de la papelera de reciclaje se realiza mediante PowerShell o desde la consola

Centro de administración de Active Directory.

Mediante PowerShell:

Abra una sesión sobre el controlador de dominio que alberga el rol de Maestro de nombres
de dominio. Ejecute la consola PowerShell con una cuenta miembro del grupo de
Administradores de empresas.

Instale la funcionalidad PowerShell y el módulo PowerShell para Active Directory si no

estuvieran presentes.
 Ejecute, a continuación, los siguientes comandos e indique "S" (Sí) para validar los
comandos.

import-module ActiveDirectory (opcional)

Enable-ADOptionalFeature ’Recycle Bin Feature’

-Scope ForestOrConfigurationSet
-Target <nombre de dominio de la raíz de su bosque>

Si no sabe si la papelera de reciclaje de Active Directory ya se encuentra activa, utilice el

siguiente comando PowerShell: Get-ADOptionalFeature -filter *

Si EnabledScopes posee algún valor, esto significa que la papelera de reciclaje de Active
Directory está activa. Si estuviera vacío { }, significa que la papelera de reciclaje de Active
Directory no se encuentra activa.

También es posible activarla desde el Centro de administración de Active Directory.

Pulse las teclas [Windows] R y ejecute el comando dsac.

Sitúese a nivel de su dominio y haga clic en Habilitar papelera de reciclaje.

 Haga clic en Sí en el mensaje de alerta que indica que una vez activada la papelera de
reciclaje no podrá desactivarse.

Pulse la tecla [F5] en el teclado y compruebe que la opción Habilitar papelera de

reciclaje queda sombreada en gris.

Ahora que la papelera de reciclaje de Active Directory está activa, veamos cómo utilizarla
reproduciendo distintos escenarios posibles en producción.

Restauración de un objeto específico

Tomemos como ejemplo un usuario de Active Directory eliminado por error. La

replicación se realiza sobre todos los controladores de dominio y no ha tenido, en una
situación de trabajo normal, otra opción que utilizar una copia de seguridad de su Active
Directory.

Gracias a la papelera de reciclaje de Active Directory, puede realizar esta operación en

unos pocos minutos sin interrupción del servicio.

En nuestro ejemplo, el usuario eliminado se llama "Fernando ROMERO" y su cuenta se

ubica en la unidad organizativa "Central". Esta cuenta de usuario era, también, miembro de
varios grupos de seguridad.

Utilice PowerShell para visualizar los objetos eliminados que podrían restaurarse.

Get-ADObject -filter ’isdeleted -eq $true -and name -ne "Deleted

Objects"’
-includeDeletedObjects -property * | Format-List
samAccountName,displayName,lastknownParent
La opción | Format-List permite interpretar el resultado del comando Get-Object y
mostrar únicamente ciertos atributos que se devuelven en un formato fácilmente legible. Si
suprime los argumentos del comando anterior tras la barra (carácter "|"), PowerShell le
mostrará todos los atributos que se restaurarán para aquellos objetos que puedan
restaurarse.

Esto puede resultar interesante a título informativo, pero se revela, rápidamente, demasiado
extenso para un entorno de producción en el que tenga varias decenas de objetos
potencialmente restaurables.

Observe que un objeto solo puede restaurarse si se ha eliminado tras activar la papelera de
reciclaje de Active Directory. Si un objeto se hubiera eliminado antes, no podría restaurarse
con la papelera de Active Directory. Tendría, en tal caso, que restaurarlo utilizando una
restauración estándar (mediante la herramienta ntdsutil.exe) partiendo de la última copia de
seguridad que contenga el objeto a restaurar.

Una vez identificado el objeto, puede restaurarlo mediante el comando PowerShell

Restore-ADObject:

Get-ADObject -Filter ’samaccountname -eq "fromero"’

-IncludeDeletedObjects | Restore-ADObject

No aparece ninguna confirmación, aunque si vuelve a su consola Usuarios y equipos de

Active Directory, verá que su cuenta de usuario se ha restaurado correctamente y sus
atributos, tales como la pertenencia a los grupos de seguridad, están presentes.

Windows Server 2012 incluye la posibilidad de restaurar un objeto de Active Directory

mediante una interfaz gráfica. Para ello, es necesario tener instalado el cliente ADAC
Windows 2012.

Abra el Centro de administración de Active Directory (dsac.exe) y, a continuación,

seleccione la visualización por arborescencia (en la parte superior izquierda) para visualizar
y seleccionar el contenedor Deleted Objects.
Escoja la o las cuentas que desea restaurar y seleccione Restaurar o Restaurar en... si
desea especificar un destino de restauración concreto. A continuación, se restaura la cuenta
junto a su pertenencia a los grupos, su directiva de contraseña asociada si la tuviera, etc.

Restauración de una unidad organizativa

Tomemos, ahora, como ejemplo el borrado de una unidad organizativa, así como todos los
objetos contenidos en ella (¡lo cual no habría ocurrido si hubiera estado activa la opción de
protección contra la eliminación accidental estuviera activa sobre esta OU! Le invitamos
no obstante, de manera excepcional, a desmarcar esta opción en las propiedades de la OU
para realizar esta prueba). Podrá restaurar todos los objetos muy fácilmente. Sepa que, para
poder restaurar el contenido, el contenedor debe estar disponible. Dicho de otro modo, si ha
eliminado una OU y sus sub-OUs y quiere restaurar una cuenta concreta de una de las sub-
OUs, tendrá que restaurar previamente la OU madre e hija. A menos, claro está, que escoja
la opción de especificar un contenedor de restauración distinto al que estuviera definido
inicialmente (mediante la opción Restaurar en...).

La restauración se desarrolla en dos etapas.

He aquí un primer método que utiliza PowerShell, para los puristas:

En primer lugar, es necesario restaurar la unidad organizativa en su ubicación original. En

nuestro ejemplo, restauraremos la OU "Central" que se encuentra en la raíz del dominio:

Get-ADObject -filter ’msds-lastKnownRdn -eq

"Central" -and lastKnownParent -eq
"DC=miempresa,DC=priv"’ -includeDeletedObjects | Restore-ADObject
 Una vez restaurada la unidad organizativa, puede ejecutar la restauración de todos los
objetos que contenía a través de este comando:

Get-ADObject -filter ’lastKnownParent -eq

"OU=Central,DC=miempresa,DC=priv"’
-includeDeletedObjects | Restore-ADObject

Veamos ahora cómo realizar esta operación mediante el Centro de administración de Active
Directory:

Abra el Centro de administración de Active Directory y sitúese a nivel del contenedor

Deleted Objects.

La columna Principal último conocido será muy útil para poder clasificar y restaurar los
objetos de una misma OU, por ejemplo.

Seleccione la o las cuentas y OU que desee y haga clic en Restaurar.

Todos los objetos presentes en esta OU (usuarios, equipos, grupos, etc.) se restauran sin
problema alguno.

En lo sucesivo, será capaz de utilizar la papelera de reciclaje de Active Directory en caso de

que se produzca alguna manipulación incorrecta de su directorio Active Directory.

Tenga, no obstante, en mente que esta funcionalidad no debe eximirle de realizar copias de
seguridad periódicas de sus controladores de dominio y habilitar la protección contra la
eliminación accidental de sus objetos de Active Directory (al menos sobre sus OU).
¡Nunca se es demasiado prudente!.
j. Otras especificaciones desde Windows Server 2008 R2

Conforme aparecen nuevas versiones de Windows aparecen funcionalidades muy

interesantes relacionadas con el directorio Active Directory.

He aquí una lista, no exhaustiva, de las principales mejoras que han tenido lugar desde
Windows Server 2008 R2:

• Unirse a un dominio en modo sin conexión (Offline domain join): el comando

djoin permite pre-provisionar una cuenta de equipo sobre un controlador de dominio
y crear el bloque asociado (Binary Large Object). Este bloque podrá, a
continuación, desplegarse en el puesto cliente (mediante el registro o el archivo
VHD) habilitando así una unión al dominio automática del puesto cliente al
dominio (tras su reinicio). Será posible realizar esta unión incluso si el equipo no se
encuentra conectado a la red de la empresa durante su reinicio.
• Windows Server 2012/2012 R2 y Windows 8/8.1 pueden utilizar djoin acoplándolo
a una conexión DirectAccess (conexión VPN transparente que se aborda en el
capítulo Acceso remoto). Encontrará más información sobre esta solución en el
capítulo Despliegue de servidores y puestos de trabajo y, también, en la siguiente
dirección: http://technet.microsoft.com/library/jj574150.aspx
• Centro de administración de Active Directory: con Windows Server 2008 R2
hace su aparición una nueva consola de gestión del directorio Active Directory, con
el objetivo de remplazar a la consola Usuarios y equipos de Active Directory. Esta
consola es una interfaz gráfica para PowerShell. También llamada Active Directory
Administration Center o ADAC, puede ejecutarla a través las herramientas
administrativas desde el administrador del servidor o ejecutando el comando
dsac.exe. Las búsquedas globales permiten, en particular, ejecutar consultas LDAP
predefinidas tales como el listado de usuarios cuya cuenta está desactivada o cuya
contraseña ha expirado.
Esta consola se instala, por defecto, sobre un controlador de dominio igual o posterior a
Windows Server 2008 R2. Requiere la presencia del módulo AD para PowerShell así como
el servidor ADWS (Active Directory Web Service).

• Service Active Directory Web Service (ADWS)

Este servicio está disponible desde Windows Server 2008 R2 y se instala por
defecto tras la promoción de un servidor como controlador de dominio.

Cuando un administrador ejecuta una consulta desde su consola de administración

de Active Directory (dsac.exe), éste la traduce en un comando PowerShell mediante
los cmdlets del módulo Active Directory PowerShell instalado.

El comando PowerShell se transmite, a continuación, al servicio ADWS a través del

puerto 9389/TCP mediante un protocolo WS-* (WS-Transfer, WS-Enumeration).

Observe que existe un servicio equivalente para las versiones anteriores de Windows
Server, a partir de Windows Server 2003 SP2. Para ello, es necesario descargar e instalar el
servicio Active Directory Management Gateway Service (ADMGS), con el que podrá,
también, consultar a sus controladores de dominio utilizando comandos Power-Shell.

Ambos servicios son equivalentes a diferencia de que ADMGS no podrá utilizar una
instancia de instantánea de Active Directory.

• Active Directory Best Practices Analyzer Tool

Tras la instalación del rol Active Directory, Windows Server 2012/2012 R2 instala,
también, la herramienta Best Practice Analyzer Tool. Esta herramienta permite
comprobar todo un conjunto de buenas prácticas a seguir y poner de manifiesto los
errores de configuración de los controladores de dominio de su infraestructura, tanto
para los controladores de dominio con Windows Server 2012 R2 como para los
demás (2000/2003/2008/2008 R2/2012).

Las pruebas se ejecutan desde el Administrador del servidor o mediante comandos

PowerShell.
Mediante PowerShell, ejecute los siguientes comandos para ver el estado de las distintas
Best Practices para cada módulo:

Import-Module ServerManager
Import-Module BestPractices
Get-BpaModel

Este comando permite recuperar el ID necesario para el comando siguiente. Seleccione el

ID correspondiente al rol para el que desea realizar un scan.

Invoke-BPAModel -BestPracticesModelId Microsoft/Windows/DirectoryServices

Este comando permite ejecutar la herramienta de buenas prácticas sobre el rol definido por
su ID.

Get-BpaResult -BestPracticesModelId Microsoft/Windows/DirectoryServices

Este comando permite visualizar los resultados del análisis anterior.

Desde el Administrador del servidor, vaya a AD DS y, a continuación, en la sección
Analizador de procedimientos recomendados Tareas - Iniciar examen BPA.

Tenga en cuenta que esta herramienta también está disponible para los roles Active
Directory Certificate Services (AD CS), DNS, Terminal Server y algunos otros que es
posible visualizar mediante el cmdlet get-BPAModel.

Ahora que se ha familiarizado con la administración del directorio Active Directory,

descubramos una presentación en profundidad de las directivas de grupo.

Las directivas de grupo

Las directivas de grupo se utilizan en el seno de un dominio de Active Directory para
definir parámetros comunes a un conjunto de equipos.

Microsoft provee mejoras muy útiles relativas a la gestión de las directivas de grupo desde
Windows Server 2012. Se ponen a disposición del administrador varias opciones
suplementarias, con esta nueva versión de Windows, cuyo objetivo es mejorar el buen
trabajo que ya se había hecho con Windows Server 2008.

A continuación se presentan las principales evoluciones de las directivas de grupo.

1. Detección de enlaces lentos

La detección de enlaces lentos (también llamados, en ocasiones, "vínculos de baja

velocidad", por Microsoft) permite limitar la aplicación de algunas directivas de grupo
cuando el usuario se encuentra conectado mediante una red con baja tasa de transferencia.

Antes, esta detección se realizaba gracias al protocolo ICMP, con todas las limitaciones que
ello conllevaba. Por este motivo, Microsoft ha desarrollado el servicio de reconocimiento
de ubicación de red (también llamado NLA por Network Location Awareness) para
Windows Vista y Windows Server 2008. Gracias al servicio NLA, el refresco como tarea
de fondo de su directiva de grupo será mucho más fiable, puesto que ya no se basa en el
protocolo ICMP sino en RPC, conocido por su fiabilidad. Si su equipo intenta refrescar las
directivas de grupo (por defecto, esto se produce cada 90 minutos), mientras el controlador
de dominio no está accesible en ese preciso instante (si el usuario no está conectado a la
red, por ejemplo), el refresco no se realizará en el próximo ciclo (90 minutos más tarde)
sino cuando el controlador de dominio vuelva a estar disponible. El servicio NLA permite,
en efecto, detectar muy rápidamente la disponibilidad del controlador de dominio en este
caso concreto.

Por otro lado, se ha optimizado el servicio Cliente de directiva de grupo, presente en un

puesto Windows 8/2012 o versiones posteriores, y estará detenido la mayor parte del
tiempo de cara a optimizar recursos de CPU. El servicio se inicia automáticamente durante
5 minutos y siempre respetando un retardo de 90 minutos, aproximadamente. Este inicio se
controla, en lo sucesivo, mediante una tarea programada que se ejecuta con la cuenta
SYSTEM (no puede, por tanto, visualizarla sino con la cuenta SYSTEM, utilizando el
comando psexec, por ejemplo).

Es posible volver al antiguo método de funcionamiento de este servicio habilitando la

opción Desactivar la optimización de AOAC del servicio Cliente de la directiva de
grupo en Configuración del equipo - Directivas - Plantillas administrativas - Sistema -
Directiva de grupo.

Observe, también, que para los accesos mediante DirectAccess, se define un enlace por
defecto si la velocidad de la conexión no se considera lo suficientemente rápida. De este
modo, el inicio de sesión se ve mejorado, puesto que cuando se detecta un enlace lento, la
aplicación de las GPO funciona de manera asíncrona. Esta configuración también es válida
para conexiones 3G.

Tenga en mente, también, que la opción Fast Startup de Windows 8 (opción que permite
detener parcialmente el sistema operativo, haciéndole ganar tiempo de cara a la parada y el
arranque del equipo) tiene consecuencias en los scripts de inicio y cierre de sesión, que no
se ejecutarán. Será preciso habilitar la opción Fast Startup si desea seguir aprovechando
este tipo de configuración de GPO.
2. Almacenamiento en caché de las directivas de grupo

El almacenamiento en caché de las directivas de grupo está deshabilitado, por defecto, en

Windows 8.1 y Windows Server 2012 R2. La opción no se aplica a las versiones
anteriores de sistema operativo.

La ventaja de esta funcionalidad es que acelera el proceso de inicio de sesión, pues el motor
de directivas de grupo de Windows carga la información de las directivas desde una caché
local, en lugar de descargarlas desde un controlador de dominio.

El parámetro está disponible en Configuración del equipo - Directivas - Plantillas

administrativas - Sistema - Directivas de grupo. Será necesario editar la opción
Configurar almacenamiento en caché de directiva de grupo.

El almacenamiento en caché de las directivas de grupo permitirá, a los usuarios, obtener un

mejor tiempo de inicio de sesión si las directivas se definen para ejecutarse en modo
Síncrono. El modo Síncrono, para una directiva de grupo, permite que su ejecución se
realice en un orden bien definido antes de permitir al usuario iniciar la sesión en Windows.
Esto resulta útil para la redirección de carpetas, la instalación de aplicaciones, la cuota
sobre un disco, etc.

Gracias a este parámetro, la información de las directivas se recuperará de manera local (a

nivel de la carpeta C:\Windows\System32\GroupPolicy\Datastore) y un evento (5216) le
confirmará el correcto funcionamiento de este almacenamiento en caché.

Esta opción será particularmente útil para aquellos equipos conectados a redes con poco
ancho de banda, o desde Internet mediante una conexión DirectAccess, por ejemplo.

3. El formato ADMX

Con Windows Vista y Windows Server 2008 ha aparecido un nuevo formato de archivo, se
trata de los archivos ADMX. Estos archivos se utilizan para mostrar las distintas opciones
de las directivas de grupo.

Poseen numerosas ventajas, en comparación a los formatos de archivos anteriores (los

archivos ADM). Entre las principales ventajas de este nuevo formato, cabe destacar:

• El lenguaje utilizado en los archivos ADMX es el XML. Este formato está

destinado a convertirse en un estándar en el intercambio de información entre
aplicaciones, facilitando la interoperabilidad, etc.
• La creación de un almacén central que permita centralizar los archivos de plantillas
ADMX en la carpeta SYSVOL, mientras que antes los archivos ADM se
almacenaban con cada directiva de grupo de cada controlador de dominio (pudiendo
provocar un gran volumen de datos a replicar, fenómeno que se conoce como
Sysvol Bloat). Basta, entonces, con copiar/pegar los archivos ADMX de un puesto
cliente con Windows Vista o Windows Server 2008 (disponible en la carpeta
c:\Windows\PolicyDefinitions) a la carpeta PolicyDefinitions que habrá creado en
el recurso compartido
\\<nombre_de_dominio>\SYSVOL\<nombre_de_dominio>\Policies. Los
administradores que quieran editar una directiva ya no tendrán que preocuparse por
saber si disponen del archivo correcto de plantilla de directiva, dado que se
recuperarán automáticamente desde el recurso compartido. Deberán, no
obstante, acceder todos ellos a las directivas de grupo desde una misma versión de
Windows y, si es posible, la más reciente para poder visualizar los parámetros del
conjunto de puestos de trabajo. En efecto, si GPMC se ejecuta desde Windows
Vista y se configura para recuperar información desde un almacén central, no le será
posible visualizar los valores REG_MULTI_SZ o REG_QWORD, presentes
únicamente desde Windows 7.
• La independencia del archivo de idioma que contiene el texto de cada una de las
opciones de las directivas de grupo. Se asocia un archivo de idioma con la
extensión. ADML a cada archivo ADMX. Es posible editarlo con ayuda de un
simple editor de texto, puesto que tiene, también, formato XML. El detalle de las
 modificaciones aportadas por el sistema al escoger una directiva no se almacena en
el archivo ADML sino en el archivo ADMX asociado.

Microsoft provee, por defecto, 146 archivos ADMX y otros tantos archivos ADML
correspondientes al idioma del sistema operativo. Si había creado sus propios archivos de
plantilla de directiva, con formato ADM, puede convertirlos al formato ADMX gracias a la
herramienta ADMX Migrator que provee Microsoft en la siguiente
dirección: http://www.microsoft.com/downloads/details.aspx?FamilyId=0F1EEC3D-10C4-
4B5F-9625-97C2F731090C. Esta herramienta le permite, también, crear sus propios
archivos ADMX.

Observe que si el nivel funcional del dominio es, al menos, Windows Server 2008, será
posible modificar la replicación de la carpeta SYSVOL para que utilice DFSR en lugar de
FRS. Encontrará más información acerca de los inconvenientes y, sobre todo, las ventajas
de la replicación mediante DFSR en la siguiente dirección: http://technet.microsoft.com/en-
us/library/cc794837(WS.10).aspx

4. Registro de eventos

En las versiones anteriores a Windows 2008, los registros de eventos relativos a las
directivas de grupo no eran sencillos de interpretar, puesto que el formato era poco
comprensible para un administrador no iniciado.

En adelante, es posible mostrar los eventos relativos a las directivas de grupo directamente
desde el registro de eventos en un puesto con Windows Vista o Windows Server 2008 (o
versiones posteriores).

Windows Server 2012 R2 integra, a este respecto, eventos todavía más precisos, acerca de
la duración de la descarga y la aplicación de una directiva, lo que le resultará muy útil para
analizar la causa de una duración en la ejecución de las GPO anormalmente elevada.

Para ello, haga clic en el menú Administrador del servidor y, a continuación, en

Herramientas y Visor de eventos.

Despliegue, a continuación, el menú Registros de aplicaciones y servicios - Microsoft -

Windows - GroupPolicy - Operativo.
Si utilizaba la herramienta Group Policy Log View para mostrar el archivo de registro de
las directivas de grupo con un formato TXT o similar, sepa que ya no necesitará hacerlo
con Windows Server 2012 R2 pues la opción de registro del sistema de archivos le
permitirá guardarlo en varios formatos (¡en particular CSV o XML!). Escoja, para ello, la
opción Guardar eventos seleccionados....

Puede, de este modo, recuperar mucho más fácilmente una gran cantidad de información
relativa al funcionamiento de los distintos parámetros de las directivas de grupo aplicadas.

5. Parámetros de las directivas de grupo que debe conocer

Con Windows Server 2008, se crearon nuevas categorías de directivas de grupo muy útiles,
tales como, por ejemplo, las Preferencias de directivas de grupo (GPP).

Las Preferencias de directivas de grupo ofrecen una alternativa a los scripts que se utilizan,
muy a menudo, para personalizar el entorno del usuario. Es, en efecto, posible utilizar las
directivas de grupo para configurar los lectores de red, los recursos compartidos, los
usuarios y grupos locales, las opciones de alimentación, las impresoras que se quieren
instalar, las tareas programadas, etc.

Estos parámetros están disponibles en la consola Administración de directivas de grupo

(gpmc.msc). Seleccione la opción de modificar una directiva existente, por ejemplo, en el
nivel Configuración del equipo (o usuario) - Preferencias - Configuración del Panel de
control.

Es posible, para cada parámetro definido, agregar condiciones de aplicación del parámetro
en cuestión. Puede, de este modo, decidir que se apliquen los lectores de red apuntando a
un servidor en particular únicamente para aquellos usuarios con una dirección IP
comprendida en un rango de direcciones que haya definido previamente. Desde Windows
Server 2012 R2, este rango de direcciones puede definirse en formato IPv6.
Obtendrá más información acerca de las opciones de configuración en la siguiente
dirección: http://technet.microsoft.com/es-es/library/cc733022.aspx

Las preferencias de directivas de grupo se han visto mejoradas desde Windows

Server 2012, en particular a la hora de considerar Internet Explorer 10 (disponible,
únicamente, en una GPP "Usuario").
Internet Explorer 11 todavía no está integrado en las GPP, en el momento de escribir estas
líneas, aunque no debería tardar dado que los demás parámetros de configuración de IE 11
ya están disponibles a nivel de Configuración del equipo (o Configuración de usuario) -
Directivas - Plantillas administrativas - Componentes de Windows - Internet
Explorer.

Estas GPO de preferencias pueden modificarse mediante el cmdlet de PowerShell

GPPrefRegistryValue (o GPRegistryValue para los parámetros de GPO basados en
modificaciones del registro). Para ello, será preciso importar el módulo mediante el
comando Import-Module GroupPolicy.

Desde Windows 2008 R2, los parámetros de la directiva de firewall e IPsec se han
consolidado en una única consola MMC, accesible, también, desde cualquier directiva de
grupo. Es, por lo tanto, posible definir reglas de tráfico entrante, tráfico saliente, y de
seguridad de conexión (utilizando el protocolo IPsec) para los clientes con Windows Vista
y Windows Server 2008 o versiones posteriores. Estos parámetros están disponibles en
Configuración del equipo - Directivas - Configuración de Windows - Configuración de
seguridad - Firewall de Windows con seguridad avanzada.

Los parámetros de las directivas para IPsec y el firewall de las anteriores versiones de
Windows están, todavía, disponibles en la antigua ruta Configuración del equipo -
Directivas - Plantillas administrativas - Red - Conexiones de red - Firewall de
Windows.

6. La consola Administración de directivas de grupo

La consola Administración de directivas de grupo (conocida, también, por el nombre

GPMC por Group Policy Management Console) es una herramienta indispensable para
administrar las directivas de grupo de su dominio Active Directory.

Si el equipo desde el que desea editar las directivas de grupo no posee la consola GPMC,
puede instalar dicha característica desde el Administrador del servidor - Agregar roles y
características, haciendo clic en Siguiente hasta llegar a la etapa Características y
marcando la opción Administración de las directivas de grupo.

La herramienta RSAT (por Remote Server Administration Tools) permite desplazar la

configuración de las directivas de grupo (y, de manera general, la administración de roles y
características de su servidor) desde un equipo cliente. Para Windows 8, es posible
descargar esta herramienta en la siguiente dirección: http://www.microsoft.com/es-
es/download/details.aspx?id=28972
 Para acceder a la consola GPMC, abra el Administrador del servidor y, a continuación,
seleccione Herramientas y Administración de directivas de grupo.

La consola le presentará, a continuación, la organización del o de los dominios del bosque

que desee, sus OU y sub-OU, así como los objetos de directiva de grupo definidos.

Esta consola le permite:

• Crear, modificar, eliminar o vincular sus directivas de grupo con los contenedores
de los sitios, dominios o unidades organizativas del bosque que usted elija.
• Forzar la actualización de las directivas a nivel de toda una OU (creando una tarea
programada en cada equipo). Es, también, posible realizar esta tarea mediante el
cmdlet Invoke-GPUpdate.
• Configurar el filtrado de la aplicación de una directiva (mediante el filtro WMI o
mediante la seguridad de la directiva).
• Gestionar la delegación.
• Definir los resultados de la directiva de grupo para simular la aplicación de una
directiva antes de su puesta en producción.
• Realizar copias de seguridad y restauraciones de las directivas de grupo.
• etc.

Entre estas numerosas funcionalidades, no cabe olvidar dos opciones que han aparecido con
Windows Server 2008. Se trata de la posibilidad de realizar búsquedas y definir plantillas
de directivas.

La función Buscar está disponible a dos niveles en la consola GPMC.

Para las grandes empresas que deban gestionar una gran cantidad de objetos de directiva de
grupo, existe la función Buscar que está disponible haciendo clic con el botón derecho
sobre el bosque o el dominio que desee. Es, a continuación, posible mostrar objetos de
directiva de grupo que respondan a ciertos criterios que haya considerado y definido. Es, de
este modo, posible mostrar las directivas para las que se ha definido alguna Configuración
de seguridad.

La otra función Buscar disponible interesará a la mayoría de administradores. Esta función,

accesible desde el editor de administración de directivas de grupo, le permite filtrar la
visualización de las numerosas directivas ubicadas en el nodo Plantillas
administrativas en función de criterios específicos.

Puede, de este modo, encontrar los parámetros de directiva que respondan a sus
necesidades, sin tener que navegar entre los miles de parámetros posibles.

Para utilizar esta opción, realice los siguientes pasos:

 Desde la consola GPMC, haga clic con el botón derecho en el objeto de directiva de grupo
que desea modificar, seleccionando, a continuación, la opción Editar para acceder al
editor.

A continuación se abre el editor de administración de directivas de grupo. Vaya al nodo

Plantillas administrativas: definiciones de directivas... en Configuración del equipo (o
Configuración de usuario) - Directivas. Para iniciar una búsqueda entre todos estos
parámetros, haga clic con el botón derecho en el nodo principal (o en una de las
subcarpetas, aunque la búsqueda se realizará en todos los parámetros del nodo) y, a
continuación, seleccione Opciones de filtro.

Las opciones de filtrado se dividen en tres categorías que le permiten afinar su búsqueda.
Puede, de este modo, seleccionar ver solamente los parámetros de la directiva que están
configurados. También es posible realizar un filtrado por palabras clave. Por último, puede
seleccionar ver los parámetros definiendo filtros de condiciones para mostrar, en unos
pocos segundos, los parámetros aplicables a la familia Windows Vista, por ejemplo.

El siguiente ejemplo define un filtro que muestra todos los parámetros que contienen la
palabra clave activeX en el título del parámetro de la directiva, en el texto de la explicación
o en el comentario (la pestaña comentario le permite, en efecto, agregar el texto que desee
en la creación de una directiva de grupo o en la activación de algún parámetro). Haga clic, a
continuación, en Aceptar para aplicar el filtro.
Una vez validado el filtro, la arborescencia del editor de directivas se actualiza
automáticamente para mostrar únicamente aquellos parámetros que se corresponden con el
filtro definido. Estos parámetros se agrupan, también, en el nodo Todos los valores.
 Para deshabilitar el filtro y volver a una representación completa, haga clic con el botón
derecho del ratón sobre una de las carpetas de Plantillas administrativas: definiciones de
directivas y desmarque la opción Filtro activado (el icono Plantillas administrativas
retomará su apariencia habitual).

Windows 2012 aporta, además, dos funcionalidades importantes. Se trata de un

resultado mejorado en el informe de Resultados de directivas de grupo y una interfaz que
permite verificar el estado de las GPO en el conjunto del dominio.

• El resultado de la directiva de grupo se ha visto mejorado. Permite, como siempre,

verificar las directivas que se aplican a un usuario y/o un equipo específico y aporta
información suplementaria como, por ejemplo, eventuales errores detectados, el tipo
de enlace (lento o rápido), si se ha definido el bucle invertido, el tiempo de
aplicación de cada CSE (un CSE es un motor que se aplica a un conjunto de
directivas).

Esta información está disponible en los Resultados de directivas de grupo.

Seleccione, a continuación, la cuenta y el equipo que quiere analizar y debería ver
todos los parámetros definidos para el mismo.
• La otra novedad interesante de la consola GPMC es la posibilidad de verificar el
estado de un objeto GPO en el seno de todo un dominio Active Directory. En
efecto, ya sabe que puede existir un pequeño retardo entre la modificación de una
directiva en un controlador de dominio y su replicación en el conjunto de los demás
controladores de dominio. En lugar de utilizar la herramienta GPOTool para
 diagnosticar problemas vinculados con un usuario que ha actualizado sus directivas
GPO sobre un controlador de dominio que no ha recibido la última versión,
Microsoft ha mejorado la capacidad para identificar estos problemas integrando una
herramienta de diagnóstico directamente en la consola de administración de
directivas de grupo.

Para ello, haga clic en Objetos de directiva de grupo y, a continuación, haga clic
en el nombre de una de sus directivas.

Se muestra una nueva pestaña, Estado. Puede hacer clic en Detectar ahora en la
zona inferior derecha para iniciar una verificación del estado de esta GPO en el seno
de todos los controladores de dominio del dominio.

El filtrado está, de momento, limitado a los parámetros definidos en las Plantillas

administrativas. Si desea obtener una lista completa (aunque no exhaustiva) de los
parámetros que agrupan la Configuración de seguridad, etc. descargue el archivo Group
Policy Settings Reference for Windows and Windows Server (válido para Windows Server
2003 SP2/2008/2008 R2, 2012 y Windows Vista, Vista SP1, 7 y 8) con formato XLS o
XLSX (sólo disponible en inglés):
http://www.microsoft.com/downloads/details.aspx?familyid=18C90C80-8B0A-4906-
A4F5-FF24CC2030FB&displaylang=en
7. Los objetos GPO Starter

Si es un poco observador, se habrá dado cuenta, sin duda, editando sus directivas de grupo
mediante la consola GPMC desde un puesto de trabajo equipado con Windows Server 2008
o Windows Vista SP1 (o versiones superiores) que ha aparecido un nuevo parámetro. Se
trata del contenedor Objetos GPO Starter.

Esta opción consiste en crear plantillas de directivas de grupo que se refieren a parámetros
disponibles en el nodo Plantillas administrativas únicamente (del lado Usuarios y
Equipos). De este modo, es muy fácil crear varios objetos de directiva de grupo que se
basarán en un conjunto de parámetros comunes, que deben definirse en sus directivas de
grupo.

De este modo, tras la creación de una nueva GPO, puede seleccionar un objeto GPO Starter
Sourcer que haga referencia a un objeto GPO Starter existente.

Microsoft ofrece, por defecto, una lista de GPO Starter relativa a los parámetros
recomendados en su guía de securización de los distintos sistemas operativos. Provee, a su
vez, desde Windows Server 2012, dos GPO Starter que permiten crear reglas de firewall
adecuadas en los equipos cliente para permitir solicitar de manera remota un resultado o
una actualización de directiva de grupo.

Si edita un objeto GPO Starter desde un puesto con Windows Server 2008 R2 o Windows 7
(o versiones superiores) con las herramientas de administración RSAT instaladas obtendrá,
directamente, los parámetros de la directiva de grupo recomendados para los escenarios
descritos en las guías de seguridad de Windows Vista y XP.

Si desea más información, en Windows 2008, puede obtener estos elementos después de
descargarlos en la siguiente dirección:
http://www.microsoft.com/Downloads/details.aspx?familyid=AE3DDBA7-AF7A-4274-
9D34-1AD96576E823&displaylang=en

También es posible exportar estas plantillas de GPO en un archivo CABinet (.CAB) para
importarlas, a continuación, en un entorno totalmente diferente como, por ejemplo, su
entorno de preproducción.

Tras la primera activación de los objetos GPO Starter, se crea una carpeta llamada
StarterGPOs en la carpeta SYSVOL del controlador de dominio. Se crea una nueva
subcarpeta con un GUID asociado a cada nuevo objeto GPO Starter.

Para planificar una copia de seguridad del conjunto de sus directivas, no olvide marcar la
opción Hacer copia de seguridad de todo disponible en el contenedor Objetos de directiva
de grupo y, a continuación, Objetos GPO Starter.
Los demás componentes de Active
Directory
Existen otras cuatro funcionalidades principales nuevas, en lo que respecta a Active
Directory, disponibles en Windows Server 2012 R2.

Se trata de AD LDS, AD FS, AD RMS y AD CS.

1. Active Directory Lightweight Directory Services (o AD LDS)

El rol AD LDS disponible desde Windows Server 2008 R2 con este nombre es el
equivalente a ADAM (Active Directory Application Mode), que apareció con Windows
Server 2003 R2.

Se trata de una versión depurada del Active Directory Domain Services (AD DS, es
decir, el Active Directory "clásico" mencionado a lo largo de todo este capítulo) que
descansa sobre los mismos principios (a saber una replicación multipropósito, un
directorio dividido en particiones, etc.) pero que no almacena ningún componente de
seguridad de Windows (como las cuentas de usuario y ordenadores de dominio), las
directivas de grupo, etc.

El rol AD LDS permite, de este modo, distribuir la información necesaria a las aplicaciones
en un directorio centralizado antes que individualmente en cada aplicación. Las ventajas de
no tener que integrar las aplicaciones en AD DS son diversas.

• Una aplicación podrá actualizar el esquema en AD LDS en lugar de en AD DS, lo

que evitará riesgos inútiles de corrupción del esquema.
• Una aplicación accesible desde la extranet o mediante VPN ya no expondrá el
conjunto del dominio AD DS si tiene como directorio de referencia a AD LDS.

Observe que es posible tener varias instancias de AD LDS en un mismo servidor, igual que
es posible tener el rol AD LDS instalado en un Windows Server 2008 R2/2012 y 2012 R2
con el rol AD DS. El único requisito previo es que los puertos donde escuchan las distintas
instancias sean diferentes.

Encontrará más información acerca de este tema en la siguiente dirección:

http://technet.microsoft.com/es-es/library/cc754361(v=ws.10).aspx

2. Active Directory Federation Services (o AD FS)

El componente Active Directory Federation Services permite implantar una solución de

acceso securizado entre distintas plataformas Windows o no Windows para el acceso de las
aplicaciones Web (sobre una extranet, por ejemplo).
El uso típico de implantar un AD FS en su empresa consiste en permitir a un cliente que
haya firmado recientemente un contrato para conectarse desde otra red (el caso de un
contrato B2C), a una empresa asociada (el caso de un contrato B2B) o a una federación de
empresas (bosques múltiples) acceder a los recursos de su red de una forma simple y sin
tener que autenticarse en su base de datos de cuentas de usuario.

Se crea en efecto una relación de aprobación entre la red asociada y la suya con el
objetivo de proyectar la identidad de los usuarios y sus privilegios de acceso desde su red
hacia los socios reconocidos. De este modo el usuario no tendrá que identificarse de nuevo
(principio de autenticación único también llamado SSO por Single Sign On).

Observe que, desde Windows Server 2012 R2, AD FS soporta el protocolo OAuth 2.0. Este
protocolo lo utilizan cada vez con mayor frecuencia los distintos fabricantes y proveedores
de servicios en Internet, pues permite publicar e interactuar con datos autenticando al
usuario de forma segura. Es, también, el caso de Windows Azure Authentication Library
(AAL), cuyo soporte se ha extendido a los directorios AD FS.

También es conveniente saber que esta solución está limitada únicamente al acceso a través
de aplicaciones Web (con HTTPS) aunque como estas últimas son cada vez más potentes,
las posibilidades abiertas son también enormes. Es el caso por ejemplo con la integración
de SharePoint Server 2007/2010/2013 o de AD RMS, que presentaremos más adelante.

Para poder implantar un AD FS, existe un conjunto de funcionalidades y de servicios que

deben haberse implantado de forma previa:

• El rol AD DS o AD LDS debe estar instalado en, al menos, una de las redes
implicadas.
• Servidor de federación de cuentas/recursos.
• Servidor Web ADFS.
• Cliente.

Encontrará más información acerca del concepto AD FS en la siguiente dirección:

http://technet.microsoft.com/es-es/library/cc755828(v=ws.10).aspx

a. Workplace Join

Workplace Join es una de las mejoras más destacadas de Windows Server 2012 R2.

BYOD (Bring Your Own Device) está al llegar. Consiste, para una empresa, en autorizar a
sus empleados a utilizar sus propios dispositivos personales (ordenadores, smartphones,
etc.) para conectarse a la red de la empresa.

Si bien esto representa un ahorro y una flexibilidad muy importantes para la empresa,
también puede conllevar inconvenientes en la medida en que la empresa no tiene control
sobre los equipos informáticos en cuestión.
Consciente del problema, Microsoft se ha implicado en la cuestión y propone, en adelante,
el uso de los Workplace Join (término que todavía no se ha traducido de manera oficial por
parte de Microsoft en el momento de escribir estas líneas).

De este modo, el equipo en cuestión, si bien es propiedad del empleado, podrá declararse y
administrarse en un directorio AD FS. De este modo, el certificado permitirá al terminal
conectarse a su directorio y autenticarse. Será, entonces, posible solicitar a AD FS que
gestione el acceso a los recursos a través de directivas globales de autenticación, y también
gestionar la autenticación y el control de acceso multipropósito. Observe que, en lo relativo
a smartphones, Microsoft soporta de momento los dispositivos que funcionan con Windows
(2012 R2 y 8.1) e iOS (Android no está soportado en el momento de escribir estas líneas,
aunque debería estarlo en breve).

Los servicios proporcionados por el Workplace Join son los siguientes:

• Una mejor experiencia de usuario puesto que podrá aprovechar el SSO (Single Sign
On) y, de este modo, no tener que volver a autenticarse con cada una de sus
aplicaciones desde su dispositivo personal.
• Una mejor seguridad, puesto que la contraseña no se almacenará en el dispositivo
local sino que circulará mediante un ticket de sesión que se pasará directamente a
las aplicaciones cuando se solicite realizar una autenticación (siempre que se haya
configurado de este modo para utilizar SSO).
• Un mejor manejo de los equipos que se conectan a recursos de la empresa puesto
que, como se ha explicado antes, cada equipo se registrará en AD FS y recuperará
un certificado que le permitirá identificarse de forma única en la red.

Workplace Join utiliza la funcionalidad Device Registration Service. Ligado al proxy web
de aplicación (Web Application Proxy), será posible utilizar Workplace Join con equipos
conectados desde Internet. Encontrará una presentación más completa del proxy web de
aplicación en el capítulo dedicado al Acceso remoto.

Por supuesto, esta funcionalidad no permite tener un control tan importante sobre los
puestos como si fueran miembros de un dominio de Active Directory, pero se trata de un
paso importante para controlar mejor los equipos en el marco de una iniciativa BYOD y
mejorar la experiencia del usuario reforzando la seguridad de acceso a sus aplicaciones.

Es, por otro lado, posible definir una política de bloqueo de las "cuentas utilizadas en la
extranet" y que no se conectan a través del proxy web de aplicación. De este modo, si el
número de intentos de autenticación erróneos supera un valor límite definido mediante el
comando de PowerShell Set-ADFSProperties - ExtranetLockoutThreshold, entonces el
valor BadPassword de AD ya no se incrementará a nivel de controlador de dominio (con el
rol Emulador PDC) del AD vinculado a este AD FS. Esto evitará un gran número de
ataques tales como la denegación de servicio, capaz de bloquear un gran número de cuentas
tras intentos de conexión intencionadamente erróneos desde el exterior de la red de la
empresa.
Por último, uno de los evolutivos más importantes de AD FS con la aparición de Windows
Server 2012 R2 es la autenticación y el control multifactor.

La autenticación multifactor consiste en forzar un método de autenticación suplementario

además del que ya se utiliza por defecto con los terminales que utilizan el Workplace Join.
Esto resulta particularmente útil para dotar de seguridad el acceso a una aplicación sensible
que requiera, por ejemplo, la presencia de un certificado en el equipo de trabajo además de
la contraseña, que seguirá siendo necesaria para acceder a la aplicación. Si posee
únicamente una de estas dos credenciales de autenticación, no podrá acceder a la aplicación
(puede obtener más información en la siguiente dirección: http://technet.microsoft.com/en-
us/library/dn280949.aspx).

El acceso multifactor permite dar acceso a recursos si, y solamente si, se cumplen varias
condiciones por parte del usuario (y no únicamente la tradicional pertenencia a un grupo de
seguridad). Esto mejora, en parte, la gestión de pertenencia que se aborda en el capítulo
Securizar su arquitectura (a nivel del control de acceso dinámico). Para obtener más
información acerca del acceso multifactor: http://technet.microsoft.com/en-
us/library/dn280937.aspx#BKMK_2

Encontrará todos los elementos necesarios para implementar Workplace Join en las
siguientes direcciones: http://technet.microsoft.com/en-us/library/dn280938.aspx y
http://technet.microsoft.com/en-us/library/dn280939.aspx

3. Active Directory Rights Management Services (o AD RMS)

AD RMS (Active Directory Rights Management Services) es un rol que permite limitar la
difusión y proteger archivos, correos electrónicos o sitios Web de su empresa.

AD RMS funciona con aplicaciones compatibles con RMS tales como Microsoft Office
Profesional 2003/2007/2010/2013, Internet Explorer 7.0 o superior, etc.

El principio de uso de las funcionalidades de AD RMS se basa en el principio de una

licencia de publicación que se entrega con el archivo. El usuario indica el conjunto de
privilegios y de condiciones específicas para este documento. Estas propiedades lo
acompañarán protegiéndolo a lo largo de su ciclo de difusión. De este modo será capaz de
controlar las posibles acciones sobre un archivo o su contenido, de definir una duración de
validez (por ejemplo, para un presupuesto), etc.

Así, cuando el archivo difundido se abra por primera vez en una aplicación compatible AD
RMS, éste último contacta con el servidor AD RMS que haya emitido la licencia de
publicación asociada al archivo para pedir autorización de acceso a su contenido.

El servidor AD RMS verifica a continuación si el usuario solicitante está autorizado a

visualizar el contenido del archivo, y en tal caso le envía una licencia de uso que le permita
acceder al contenido del documento. El usuario puede entonces abrir el archivo mediante la
aplicación compatible RMS.
En Windows 2012, la instalación de AD RMS se ha mejorado (es posible desplegarla en
servidores remotos, con permisos de instalación más flexibles, y compatible con SQL 2005
SP3, SQL 2008 SP3, SQL 2008 R2 SP1 y SQL Server 2012). Es, también, posible en lo
sucesivo delegar más fácilmente los permisos de acceso a los documentos compartidos (en
el caso de una secretaria o asistente que deba acceder a los documentos de un responsable,
por ejemplo).

Observe que el rol puede, en lo sucesivo, instalarse en modo Server Core y es totalmente
instalable y configurable mediante PowerShell.

4. Active Directory Certificate Services (o AD CS)

Para completar este apartado, es importante mencionar el único rol que no hemos visto
todavía. Se trata del servicio de certificados de Active Directory (también conocido bajo el
nombre de Active Directory Certificate Server o AD CS).

Este rol le permitirá instalar una entidad emisora de certificados en su red de empresa para
poder emitir certificados de forma sencilla a sus usuarios y equipos. Estos últimos podrán a
su vez acceder a los sitios Web mediante el protocolo SSL sin tener que comprar
certificados (a menudo costosos) a una autoridad de certificación pública.

La ventaja de tener una entidad emisora de certificados de empresa basada en Windows

Server 2012 R2 consiste en el hecho de que el proceso de emisión y de renovación de los
certificados se ve enormemente facilitado mediante la integración de esta autoridad en
Active Directory.

Existen dos tipos de entidades emisoras de certificados.

• Entidad emisora de certificados de empresa: requiere que el servidor que posee el

rol AD CS estén integrado en Active Directory y permite, de este modo, aprovechar
numerosas funcionalidades suplementarias (tales como la auto inscripción) y
administrarse a través de las directivas de grupo.
• Entidad emisora de certificados independiente: que puede instalarse tanto en un
servidor miembro del dominio como en un servidor que no lo sea, aunque no
aprovechará las funcionalidades suplementarias.

La implementación de esta solución supera el alcance de este libro. He aquí, no

obstante algunas de las principales funcionalidades disponibles desde Windows Server
2008 en lo que respecta a este rol.

Desde Windows Server 2008:

• La emisión de certificados a través de su navegador se ha mejorado pues se basa en

un nuevo control llamado CertEnroll.dll.
 • Tiene en cuenta el protocolo NDES (Network Device Enrollment Service) que
permite a los dispositivos periféricos (routers, conmutadores, etc.) obtener
certificados X.509.
• Tiene en cuenta el protocolo OSCP (Online Certificate Status Protocol) que permite
mejorar la gestión de la revocación de los certificados.
• En lo sucesivo, el modelo de certificado en la versión 3 disponible en las entidades
emisoras de certificados de empresa tiene en cuenta la criptografía de nueva
generación (CNG Suite-B).
• Una nueva consola MMC llamada PKIView está disponible para administrar de
forma más eficaz los certificados a lo largo de su ciclo de vida.

Observe también que, desde Windows Server 2008 R2, se han incluido las siguientes
funcionalidades:

• La auto inscripción (es decir, la inscripción automática de una máquina en la

entidad emisora de certificados para obtener un certificado) es posible mediante una
conexión HTTP (con la condición de tener el nivel funcional del esquema Active
Directory en 2008 R2). Esta opción se ha mejorado con Windows Server 2012
(véase más adelante).

Una de las ventajas principales es la posibilidad de solicitar un certificado desde un

bosque diferente al de la entidad emisora de certificados. También es posible
publicar el servicio Web correspondiente sobre un servidor en DMZ para entregar
certificados a los usuarios de Internet. Este servicio Web será el único autorizado a
dialogar con la entidad emisora de certificados que se encuentre en su LAN.
Observe no obstante que tal configuración sólo está aconsejada para renovar los
certificados ya emitidos y no para emitir certificados a los clientes conectados desde
Internet.

Encontrará el manual de uso (en inglés) acerca de esta nueva funcionalidad en la

siguiente dirección: http://download.microsoft.com/download/C/2/2/C229E624-
36E4-4AD8-9D86-
F564ED539A16/Windows%20Server%202008%20R2%20Certificate%20Enrollme
nt%20Web%20Services.doc

y, también,
https://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-
enrollment-web-services-in-active-directory-certificate-services.aspx.

Requisitos previos: para+ permitir la unión desde un bosque diferente, se requiere

una entidad emisora de certificados de empresa en Windows Server
2003/2008/2008 R2/2012 y en versión Entreprise o Datacenter con cualquier
versión de Windows Server 2012/2012 R2; el nivel funcional del bosque debe ser
Windows Server 2008 R2 y los equipos cliente deben trabajar con Windows 7 o
versiones superiores.
 • Consolidación de las entidades emisoras de certificados en el seno de la empresa
que posean varios bosques con relación bidireccional.

En efecto, la entidad emisora de certificados en 2008 R2 soporta el uso de los

"LDAP Referals" lo que permite redirigir la consulta hacia el dominio correcto en el
bosque adecuado.

Requisitos previos: Entidad emisora de certificados de empresa en Windows

Server 2008 R2 o superior Entreprise o Datacenter; nivel funcional del bosque 2003
y relaciones de aprobación inter-bosque bidireccionales.

• Mejora de la entidad emisora de certificados que deba entregar una gran cantidad de
certificados.

Esto es especialmente válido para clientes NAP basados en IPSec. En efecto, los
clientes deben solicitar varios certificados al día.

Si lo desea, puede escoger que no se guarde una copia de seguridad de los

certificados emitidos en la base de datos de la entidad emisora de certificados. La
etapa de copia de seguridad entraña a menudo un crecimiento exponencial de la
base de datos y por consiguiente un coste en su administración.

Si elige no guardar una copia de seguridad de estos registros de certificados en la

base de datos, no le será posible revocarlos. Este riesgo es no obstante aceptable en
la medida en que los certificados afectados tengan un tiempo de vida corto.

Requisitos previos: Entidad emisora de certificados de empresa en Windows

Server 2008 R2 o superior.

Desde Windows Server 2012:

• Administración y despliegue mediante Windows PowerShell (véase

http://go.microsoft.com/fwlink/p/?LinkID=242169 (cmdlets para el despliegue) y
http://go.microsoft.com/fwlink/p/?LinkID=242165 (cmdlets para la
administración)).
• AD CS y sus servicios asociados pueden ejecutarse sobre cualquier versión de
Windows Server 2012.
• El modo Server Core permite instalar AD CS.
• Se tiene en cuenta la renovación automática de los certificados para los equipos que
no son miembros de un dominio. Esta consideración se basa en el nuevo modelo de
certificados (versión 4) y sólo puede utilizarse en Windows 8/2012 y permite, en
particular, importar una renovación de los certificados con la misma clave. Puede
encontrar más información acerca del nuevo modelo de certificado v4 en la
siguiente dirección: http://go.microsoft.com/fwlink/p/?LinkId=242425
 • Se tienen en cuenta los nombres de dominios internacionales (es decir, que no
contengan caracteres que puedan representarse con formato ASCII) en ciertos
escenarios.
• Una mayor seguridad activa por defecto en el servicio de rol Entidad emisora de
certificados; que impone, en particular, el cifrado de la consulta mediante
RPC_C_AUTHN_LEVEL_PKT (parámetro que no está habilitado en las versiones
anteriores de Windows; y que no es compatible con Windows XP).

Conclusión
En este capítulo acaba de descubrir el conjunto de soluciones de gestión de la identidad y
de acceso que proporciona Windows Server 2012 R2. De este modo, podrá abordar de la
mejor forma posible las necesidades en términos de acceso a los recursos, tanto para
implementar una solución de tipo SSO (Single Sign On o "identificación única") como para
controlar la difusión de los archivos en su empresa.

Introducción
En este capítulo se aborda la arquitectura distribuida (DFS) y se presenta la instalación, la
configuración de nodos raíz, los enlaces, la replicación DFS-R y las herramientas.

Descripción de DFS
El acrónimo DFS significa Distributed File Systems.

Se trata de un sistema de archivos único, lógico, jerarquizado, que estructura los

archivos compartidos entre varios equipos de la red bajo la forma de una arborescencia
lógica de recursos de sistema. El principal objetivo de DFS consiste en referenciar a todos
los recursos compartidos que queremos hacer accesibles de manera uniforme y centralizar
los espacios disponibles sobre los distintos espacios.

Esto permite obtener una vista uniforme y permanente de los datos que ya no estarán
vinculados con los servidores físicos sobre los que se encuentran. Además del ahorro en
unidades de red, puesto que una única letra permite alcanzar todos los espacios
compartidos, las aplicaciones pueden configurarse, de una vez por todas, utilizando una
ruta única y definida, que no cambiará, incluso aunque los datos se desplacen entre dos
servidores, en particular en el caso de que evolucione la volumetría necesaria.

Otra posibilidad, muy interesante, consiste en poder replicar los datos de una misma carpeta
sobre varios enlaces de red, es decir, sobre varios espacios compartidos. Esta tolerancia a
fallos aporta una funcionalidad muy próxima a la de un clúster de archivos. Aunque es
preciso, no obstante, estudiar bien su modo de funcionamiento para evitar cualquier
sorpresa.
He aquí cómo organiza DFS los recursos que residen en distintos componentes de la red:

La arborescencia DFS constituye un punto único de referencia. Sea cual sea su ubicación,
los usuarios pueden acceder fácilmente a los recursos de la red. Sobre la red, las unidades
DFS se ven como unidades compartidas de red clásicas y se gestionan, por tanto, mediante
la función de redirección de archivos utilizando los clientes de red clásicos.

Un usuario que navegue en una carpeta compartida DFS no tiene por qué conocer el
nombre ni la localización del servidor sobre el que se encuentra un recurso concreto. El
acceso a los recursos de red se ve, así, simplificado. Tras haberse conectado a una raíz DFS,
puede recorrer la estructura y acceder a todos los recursos ubicados en esta raíz. Un recurso
compartido DFS utiliza una estructura de arborescencia que contiene una raíz y enlaces
DFS.

Para iniciar el uso de DFS, es necesario crear una raíz DFS. Desde Windows Server 2003,
es posible crear varias raíces. Cada raíz puede soportar varios enlaces, y cada una de ellas
puede apuntar a una carpeta compartida en red. Los enlaces DFS de la raíz DFS representan
carpetas compartidas que pueden estar físicamente ubicadas en distintos servidores de
archivos. Las ventajas ligadas a DFS son las siguientes.

Para resumir, he aquí todas las ventajas de esta solución:

 • La administración de la red se ve simplificada. En caso de que caiga algún servidor,
el enlace DFS puede desplazarse hacia otro servidor, modificando así la carpeta
DFS para indicar el nuevo servidor donde se ubican las carpetas compartidas. La
ruta sigue siendo la misma de cara a los usuarios.
• El espacio de nombres permite acceder a todos los recursos utilizando un nombre
único, sin tener que mapear una letra para cada recurso.
• DFS se integra con los clientes Windows y no requiere ningún agente o el uso
suplementario de memoria.
• Los servidores de archivos pueden remplazarse sin verse afectado el espacio de
nombres que utilizan los clientes.
• El reparto de carga y la tolerancia a fallos pueden mejorarse en las raíces y en los
enlaces que se desee proteger indicando varios servidores y espacios compartidos
sobre cada recurso. Existen varios marcos de utilización de estas soluciones.
• El espacio de nombres puede extenderse de manera dinámica para incluir un espacio
de disco complementario y para tener en cuenta nuevos requisitos.
• DFS utiliza todas las autorizaciones existentes. No se necesita ninguna regla o
autorización suplementaria por parte de los usuarios. Las listas de control de acceso
(ACL) asociadas a las carpetas replicadas se replican de la misma manera que los
datos.
• Para acelerar la búsqueda y recorrer más rápidamente la arborescencia DFS, ésta se
aloja automáticamente en caché sobre los clientes tras su primer uso, hasta que
se detiene el cliente o expira la contraseña.

Instalación
A diferencia de las versiones anteriores, los módulos DFS ya no están integrados ni se
inician automáticamente sobre los servidores Windows. La única excepción, aunque
importante, es la referida a los controladores de dominio que utilizan la replicación DFS
para las carpetas compartidas SYSVOL.

Los componentes DFS forman, ahora, parte del rol Servicios de archivos y
almacenamiento:

• El módulo FS-DFS-namespace aparecerá bajo el nombre Espacios de nom-bres

DFS.
• El módulo FS-DFS-Replication aparecerá bajo el nombre Replicación DFS.

¡El comando SERVERMANAGERCMD.EXE ya no existe!

Es posible utilizar ambos módulos por separado de cara a responder a necesidades

diferentes. También es posible replicar carpetas, o publicar espacios de nombres, aunque lo
ideal es utilizar ambas funcionalidades al mismo tiempo.
1. El módulo de espacio de nombres

Como con Windows 2003, es posible crear varios espacios de nombres. Estos espacios se
publican en Active Directory (AD).

La instalación del módulo de espacio de nombres puede realizarse a través de PowerShell

mediante el comando:

Install-WindowsFeature FS-DFS-namespace

2. El módulo de replicación

El módulo de replicación permite crear grupos de replicación de datos. Una replicación

debe contener, al menos, dos recursos compartidos que provengan de dos servidores
diferentes. La instalación del módulo de replicación puede hacerse mediante el comando
PowerShell:

Install-WindowsFeature FS-DFS-Replication

Observe que la replicación mediante las herramientas Microsoft no es obligatoria. Es

posible utilizar enlaces DFS para apuntar sobre varios recursos compartidos. Pero, si desea
un contenedor idéntico, tendrá que replicarlo de manera explícita utilizando las
herramientas o los scripts adecuados.

3. La consola de administración

Si lo requiere, la consola de administración puede instalarse de manera separada a los

demás módulos y funcionalidades.

La consola de administración se encuentra en el Administrador del servidor, en el menú

Herramientas, Administración de DFS.

La instalación puede realizarse también mediante el comando PowerShell:

Install-WindowsFeature RSAT-DFS-Mgmt-con

Tras ejecutar la consola, bastará con preguntar a Active Directory para obtener la lista de
raíces DFS existentes.

4. El caso de los controladores de dominio

Sobre un controlador de dominio, los servicios de espacio de nombres y de replicación se

instalan automáticamente, pero Active Directory gestiona directamente sus propias carpetas
compartidas. No es, por tanto, posible ver o modificar a este nivel la replicación utilizada
por Active Directory para replicar el recurso compartido SYSVOL.
5. El procedimiento de instalación gráfica

La instalación gráfica permite agregar todos los componentes necesarios de una sola vez.
Esto se realiza a partir de la herramienta Administrador del servidor. En la visualización
por defecto del Panel se encuentra el botón Administrar, que da acceso a la opción
Agregar roles y características.

He aquí las distintas etapas:

Haga clic en Siguiente.

Esta etapa puede ignorarse en futuras ocasiones marcando la opción adecuada.

Seleccione la instalación de un rol o una característica. Es posible instalar varios roles o

características de una sola vez.
 Una de las ventajas de Windows Server 2012 es que permite automatizar ciertas
operaciones sobre varios servidores a la vez, tales como el reinicio o la configuración del
reporte de los errores. En cambio, la instalación de un rol o una funcionalidad solo puede
realizarse sobre un único servidor que debe seleccionar. Por defecto, se le propone realizar
la instalación en el servidor local.
 Sitúese en el rol Servicios de archivos y almacenamiento y, a continuación Servicios de
iSCSI y archivo.

Las opciones marcadas y sombreadas indican roles y componentes que ya están presentes
en el servidor.

Basta, a continuación, con seleccionar entre los Servicios de rol los componentes
deseados. Seleccionamos, en primer lugar, el módulo Espacios de nombres DFS.
 El hecho de marcar el componente Espacios de nombres DFS hace que se proponga,
automáticamente, instalar la característica de administración correspondiente. Haga clic en
el botón Agregar características para aceptar y agregar el componente sugerido.
 Marque el servicio de rol Replicación DFS y haga clic, a continuación, en Siguiente para
pasar a la instalación de las características. En este ejemplo, ya está marcado debido a
nuestra selección anterior.
No hay características suplementarias que agregar. Haga clic en Siguiente.
 Haga clic en Instalar. Evitaremos, generalmente, marcar la opción Reiniciar
automáticamente el servidor de destino en caso necesario.
Haga clic en Cerrar cuando le aparezca la opción.
Tras la instalación, los servicios arrancan automáticamente. Si hace clic sobre el icono
Notificaciones en la barra de tareas, obtendrá el estado de la tarea solicitada.
Configuración del servicio DFS
1. Los distintos tipos de raíces distribuidas
a. Las raíces autónomas

Las raíces autónomas permiten crear arborescencias que están vinculadas con un servidor
determinado. Estas raíces no están securizadas, es decir, la raíz DFS no estará accesible, ni
podrá utilizarse, si el servidor que la contiene no funciona correctamente. En cambio, los
accesos directos a los recursos compartidos seguirán funcionando.

Observe que las carpetas (enlaces a recursos compartidos) pueden, no obstante, replicarse y
sincronizarse mediante un grupo de replicación específico.

Por otro lado, si la raíz autónoma se configura sobre un clúster de archivos, la raíz DFS
aprovechará la misma tolerancia a fallos que la compartición de archivos. No obstante sólo
será posible realizar esta operación en un clúster Windows Server 2008 o 2012.

He aquí el procedimiento de creación de una raíz autónoma. La consola Administración de

DFS puede abrirse desde el menú Herramientas del Administrador del servidor.

Utilizando el asistente de creación de un espacio de nombres Nuevo espacio de nombres,

esta operación puede llevarse a cabo muy rápidamente.

Haga clic con el botón derecho en Espacios de nombres para desplegar el menú
contextual. A continuación, haga clic en Nuevo espacio de nombres.

Los servidores de espacios de nombres no pretenden recibir directamente datos. Sólo

contienen, por lo general, carpetas virtuales que apuntan sobre los datos reales. Se trata, a
menudo, de servidores controladores de dominio que se utilizan para seguir este tipo de
información.
Indique el nombre de servidor del espacio de nombres.

Indique el nombre de su espacio de nombres.

Haga clic en Editar configuración... para indicar los permisos que se quiere asignar sobre
la raíz RAÍZ AUTÓNOMA que se verá como un recurso compartido en el servidor
correspondiente.
Hay que prestar atención a los permisos que se asignan a este nivel, pues los elementos
creados en la raíz de este recurso compartido se encontrarán, efectivamente, en la carpeta
local indicada.
La elección del tipo de espacio es relevante, entre una raíz que será específica a este
servidor y una raíz llamada de nombres de dominio que podrá verse y utilizarse en todo el
bosque. La raíz autónoma sólo podrá verse en el servidor donde se aloja.

Seleccione el tipo de espacio de nombres que quiere crear, en este caso Espacio de
nombres independiente.
Esta pantalla resume las decisiones anteriores.

Haga clic en el botón Crear.

Esta pantalla confirma la creación de la raíz DFS. La pestaña Errores da acceso a los
eventuales errores que se produzcan. El registro de eventos ofrecerá información
complementaria.
b. Las raíces de nombres de dominio

Las raíces de nombres de dominio se basan en la resolución DNS del dominio. La principal
ventaja de esta solución es la tolerancia a fallos, que puede asociarse a la raíz mediante el
uso de, al menos, dos servidores vinculados a nivel de la misma raíz.

Las raíces se inscriben en Active Directory, lo que permite a los administradores y a los
usuarios de todo el bosque acceder fácilmente a las unidades DFS.

He aquí el procedimiento de creación de una raíz de nombres de dominio.

Los primeros pasos son idénticos a la creación de una raíz autónoma.

Ejecute el asistente de creación de un Nuevo espacio de nombres.

Indique el servidor que gestionará esta raíz.
 Indique el Nuevo espacio de nombres, teniendo en cuenta que el nombre debe escogerse
de manera lógica puesto que podrán verlo y usarlo todos los usuarios del bosque, o incluso
más.

Haga clic en Editar configuración para acceder a la configuración de las autorizaciones

sobre la raíz.
El espacio de nombres de dominio permite basarse en la resolución del nombre de dominio
Active Directory para acceder a un espacio compartido fácil de encontrar.
Se recomienda utilizar el modo Windows 2008, seleccionado por defecto (siempre que se
lo permita el nivel funcional). El modo Windows 2008 activa el modo ABE (Access Based
Enumeration) y un número mucho mayor de raíces y destinos.

Haga clic en Crear si los parámetros de creación son correctos.

Observe que la creación de la raíz de dominio estará vinculada con el modo de
funcionamiento del domino que lo alberga.

El uso de una raíz de dominio supone que se quiere utilizar tolerancia a fallos y reparto de
carga sobre la raíz DFS. Esto se consigue agregando un servidor de espacios de nombres
suplementario.

Haga clic en el espacio de nombres del tipo de dominio.

Haga clic en Agregar servidor de espacio de nombres.

Puede, también, seleccionar o indicar directamente el nombre del nuevo servidor a utilizar.

De hecho, puede haber más de dos servidores que contengan información sobre los DFS.
2. Creación de enlaces DFS y destinos DFS

El nombre de un enlace se corresponde con el nombre de la carpeta que aparece en el

espacio de nombres distribuido. Un enlace DFS se corresponde con una ruta de red, es
decir, un recurso compartido ubicado sobre no importa qué servidor (o estación del
dominio) y que se asocia a un enlace DFS.

Es posible asociar un enlace DFS con varios destinos y, por tanto, a varios recursos
compartidos diferentes. Será, por tanto, necesario configurar la replicación de estas carpetas
para obtener un contenido idéntico y sincronizado entre los distintos destinos.

He aquí el procedimiento que permite definir un destino sobre los recursos compartidos
CONTAB1 y CONTAB2 definidos sobre dos servidores distintos:

Seleccione el espacio de nombres deseado (autónomo o de dominio) y, a continuación,

haga clic con el botón derecho para desplegar el menú contextual.

Seleccione la opción Nueva carpeta.

Indique el nombre del enlace DFS CONTAB.

Haga clic en Agregar para agregar los destinos asociados a este enlace.

Puede escribir directamente el nombre UNC de acceso al recurso bajo la forma

\\SERVIDOR\RECURSO_COMPARTIDO o hacer clic en Examinar.

En el segundo caso, se recomienda indicar el nombre del servidor y, a continuación, hacer

clic en el botón Ver las carpetas compartidas.

Si se definen varios destinos, el asistente le propone crear un grupo de replicación. A

continuación, se ejecuta automáticamente el asistente de creación de un grupo de
replicación.
En la siguiente sección se describe el procedimiento de implantación de la replicación.

3. Replicación

La replicación se basa en un motor multimaestro que permite tener en cuenta

modificaciones de archivos simultáneas que provengan de varios puntos diferentes y
sincronizar el conjunto. Esta replicación se adapta a los enlaces lentos utilizando una
tecnología de compresión diferencial llamada RDC.

Cada grupo de replicación (conjunto de servidores) es capaz de tener en cuenta varias

carpetas replicadas.

Cada carpeta replicada puede tener sus propios parámetros, en particular filtros de
replicación que permiten limitar los tipos de archivo y las subcarpetas que deben incluirse
en la replicación.

a. Los filtros de replicación

Por defecto, los filtros de archivo excluyen los filtros temporales que comienzan por el
carácter ~ así como las extensiones .BAK y .TMP.

Por otro lado, los siguientes archivos también se excluyen:

• puntos de montaje NTFS;

• archivos cifrados mediante EFS;
• archivos definidos como temporales.

Es posible excluir tanto carpetas como archivos, en función de su nombre. Es posible

utilizar el carácter genérico *.

Las bases de datos, los archivos de vídeo y las imágenes de CD pueden, también, excluirse
de esta replicación.

b. La implementación gráfica de la replicación

He aquí el procedimiento gráfico de implementación de una replicación.

Esta replicación se implementa de la misma manera sobre una raíz autónoma que sobre una
de dominio.

Seleccione el módulo Replicación y, a continuación, haga clic con el botón derecho para
desplegar el menú contextual. Seleccione la opción Nuevo grupo de replicación.

Esta opción permite, principalmente, definir una replicación ligada únicamente a dos
servidores, donde uno de ellos contendrá los datos principales.
Asigne un nombre al grupo de replicación.
Indique los servidores miembros.
 Seleccione la tipología que mejor se adapte a sus necesidades. La topología en malla
completa está bien adaptada a las modificaciones autorizadas que provienen de todos los
servidores miembros.
 Según las características de su red, será posible modular los horarios y la tasa de uso de la
red.
Más adelante podrá modificar fácilmente los parámetros de replicación.

Es preferible iniciar la replicación con carpetas vacías. En caso contrario, esta opción
permite definir el servidor que contiene los datos iniciales.

Seleccione el servidor inicial que contiene los datos de referencia.

Indique el nombre concreto de la carpeta raíz que se quiere replicar.
Es posible agregar otras carpetas a este grupo de replicación de manera inmediata o más
adelante.
 Por cada servidor que contenga una réplica de los datos, active la replicación indicando
una carpeta de destino. Seleccione el servidor y, a continuación, haga clic en Editar.
Cabe destacar la posibilidad de configurar esta réplica en modo de sólo lectura de manera
inmediata.

Esta opción permite indicar el nombre de la carpeta principal y crearla, si fuera necesario.

Seleccione los servidores de destino.

Esta pantalla resume los principales parámetros de la replicación.

He aquí el resultado de la implementación de la replicación.

La implementación efectiva dependerá del funcionamiento de Active Directory y de la
planificación de la replicación que haya configurada entre los sitios.

c. La topología de replicación

Por defecto, se proponen dos tipos de topología.

• El modo Concentrador y radio, llamado en estrella, requiere, como mínimo, tres

miembros. Este modo es particularmente útil cuando existe una fuente definida (el
Concentrador) y la replicación se produce hacia múltiples destinos.
 • El modo malla completa autoriza a cada servidor replicarse hacia los demás. Se
aconseja utilizar este modo en el caso de instalaciones compuestas por una decena
de miembros como máximo.

La implementación de una nueva topología depende de la replicación Active Directory y

puede, por tanto, tomar su tiempo antes de implementarse sobre cada miembro.

En cambio, la replicación local de los archivos (de tamaño razonable) puede resultar muy
rápida y, generalmente, instantánea.

Configuración avanzada
1. Los métodos de ordenación

Los métodos de ordenación son muy importantes y deben tomarse en consideración de cara
a optimizar el rendimiento y evitar futuros disgustos.

En efecto, cuando una misma carpeta está accesible en ubicaciones diferentes, situadas en
servidores distintos, ellos mismos alojados en sitios diferentes, la optimización lógica
consistiría en utilizar el recurso compartido situado sobre el servidor del sitio local. Incluso
en este caso, resulta vital utilizar de forma prioritaria un servidor determinado que sirva
como referencia. En otros casos, será conveniente forzar un servidor remoto que sirva como
referencia única para evitar modificaciones simultáneas sobre un documento.

a. Configuración a nivel de las raíces DFS

La pestaña Referencias en las propiedades de las raíces DFS permite definir el valor por
defecto que se utiliza sobre todos los enlaces que pertenecen a esta raíz.

• Orden aleatorio
• Coste más bajo
• Excluir destinos fuera del sitio cliente
El Orden aleatorio consiste en proveer, de manera aleatoria, todos los servidores situados
en el sitio del cliente y, a continuación, y siempre de forma aleatoria, los demás servidores
presentes en los demás sitios sin tener en cuenta las diferencias de coste.

El Costo más bajo presentará, en primer lugar, aquellos servidores ubicados en el sitio del
cliente de manera aleatoria. A continuación, los servidores remotos se mostrarán según su
coste, del menos elevado al más elevado, aunque aquellos servidores que tengan un coste
idéntico se presentarán aleatoriamente.

El último modo, Excluir destinos fuera del sitio cliente mostrará, únicamente, aquellos
servidores ubicados en el sitio del cliente. Más adelante veremos las posibles excepciones a
esta regla.

Si se fuerza, a este nivel, la restauración automática de clientes sobre los destinos

preferidos, se activará sobre todos los enlaces y destinos que dependan de esta raíz.

En la pestaña Opciones avanzadas es, ahora, posible activar el modo ABE (Access Based
Enumeration) para ocultar aquellas carpetas sobre las que los usuarios no tienen permisos.
b. Configuración a nivel de los enlaces DFS

Sobre cada carpeta que represente un enlace hacia uno o varios destinos, es posible
configurar una exclusión de los sitios remotos, en particular si no se ha indicado
anteriormente. Es posible, también, activar la restauración automática de los clientes hacia
un destino preferente (si no se hubiera configurado en un nivel superior).

c. Configuración a nivel de los destinos DFS

Sobre cada destino, en la pestaña Opciones avanzadas, es posible configurar un

comportamiento particular.

Es posible dar preferencia al uso de un destino definiéndolo como Primero de todos los
destinos o Primero de los destinos de igual costo.

Puede, por el contrario, definir el destino como Último de todos los destinos incluidos en la
selección, o Último de los destinos de igual costo.
Preste atención, estas reglas forzadas (Primero o Último) provocan la visualización
sistemática de los destinos correspondientes.

2. Delegación de la administración

Por defecto, sólo los administradores locales o de dominio pueden administrar los grupos
de replicación. Sobre una raíz de dominio, sólo el grupo administradores de empresas
hereda, automáticamente, permisos de administración. Sobre una raíz autónoma, el grupo
administradores local y la cuenta especial SYSTEM tienen permisos heredados.

Cuando un administrador crea una raíz, éste, y el grupo administradores de dominio,

obtienen permisos explícitos. Esto quiere decir que es posible eliminar estos permisos.

Preste atención, los administradores que reciben una delegación siguen siendo propietarios
de los objetos, incluso aunque se los retire, a continuación, un administrador.

Por otro lado, cualquier administrador de una raíz DFS puede delegar la autorización de la
gestión.
Administración de DFS con PowerShell
Todos los comandos de administración DFSUTIL, DFSCMD, DFSRADMIN, DFSRDIAG,
DFSRMIG siguen existiendo. Aunque está previsto que desaparezcan en la próxima
versión, la administración de todos los componentes y servicios de Windows se están
estandarizando gracias al lenguaje PowerShell, que sirve de referencia.

La primera etapa consiste en importar el módulo que contiene todos los comandos DFS:

Import-module DFSN

Observará que los comandos PowerShell se refieren, únicamente, a la gestión del

espacio de nombres .La gestión de la replicación no se ve afectada. Las herramientas de
programación WMI pueden ser útiles en este caso.

Todos los recursos compartidos basados en nombres de servidores que se utilizan en los
comandos siguientes deben crearse previamente.

• Crear la carpeta
• Crear un recurso compartido

El conjunto de comandos permite definir, mediante un script PowerShell, una

configuración equivalente a la que se ha creado anteriormente mediante la interfaz de
administración.

1. Administración de los espacios de nombres con PowerShell

a. Gestión de raíces

Este comando permite enumerar todas las raíces registradas en el directorio.

Get-DfsnRoot | ft -auto -wrap

Resultado:

Path type Properties TimeToLiveSec State Descripti

on
---- ---- ---------- ------------- ----- ---------
--
\\MiEmpresa.Priv\RAIZ-DOMINIO Domain V2 Site Costing 300 Online

El comando FT utiliza detrás el carácter especial | que permite tabular el resultado y

mejorar su lectura.

Crear una raíz de árbol de dominio nueva llamada RAIZ2-DOM2. Cada recurso
compartido utilizado debe existir previamente.
New-DfsnRoot -Path ’\\MiEmpresa.Priv\RAIZ2-DOM2’ -Targetpath
’\\SRVFIC01\RAIZ2’ -Type domainV2

Resultado:

Path Type Properties TimeToLiveSec State Descripti

on
---- ---- ---------- ------------- ----- ---------
--
\\MiEmpresa.Priv\... Domain V2 300 Online

El parámetro PATH debe indicar el dominio y el nombre de la raíz que utilizarán, a

continuación, los usuarios.

El parámetro TARGETPATH debe apuntar hacia un servidor y un recurso compartido ya

existente.

El parámetro TYPE precisa que la raíz se gestionará en modo 2008. Los demás valores
posibles son Standalone, para una raíz autónoma, y DomainV1 para el modo 2003.

¡Observe que es necesario agregar manualmente la nueva raíz en la herramienta de

administración si queremos gestionarla gráficamente!

Enumerar todos los servidores de nombres que soporten la raíz RAIZE2-DOM2:

Get-DfsnRoot -Path \\MaSociete.Priv\RACINE2-DOM2|Get-DfsnRootTarget |

ft -auto

Resultado:

Path TargetPath State ReferralPriorityClass

ReferralPriorityRank
---- ---------- ----- --------------------- --------------------

\\MiEmpresa.Priv\RAIZ2-DOM2 \\SRVFIC01\RAIZ2 Online sitecost-normal 0

Agregar un nuevo servidor de espacios de nombres en una raíz existente.

Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2|New-DfsnRootTarget

-Targetpath \\DC2012\RAIZ2 -ReferralPriorityClass "sitecostnormal"

Resultado:

Path TargetPath State ReferralPriorityClass

ReferralPriorityRank
---- ---------- ----- --------------------- --------------------

\\MiEmpresa.Priv\RAIZ... \\DC2012\RAIZ2 Online sitecost-normal 0

Preste atención, el parámetro ReferralPriorityClass es obligatorio.

Enumerar y verificar la agregación del servidor que administra una raíz determinada:

Get-DfsnRoot -path \MiEmpresa.Priv\RAIZ2-DOM2|Get-DfsnRootTarget |ft

-auto

Resultado:

Path TargetPath State ReferralPriorityClass ReferralPriorityRank

---- ---------- ----- --------------------- --------------------

\\MiEmpresa.Priv\RAIZ2-DOM2 \\SRVFIC01\RAIZ2 Online sitecost-normal 0

\\MiEmpresa.Priv\RAIZ2-DOM2 \\DC2012\RAIZ2 Online sitecost-normal 0

Para eliminar un servidor que gestiona una de las raíces:

Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2 |Remove-DfsnRootTarget

-TargetPath \\DC2012\RAIZ2 -Confirm:false

La opción -confirm con valor False permite evitar la pregunta, que puede resultar
bloqueante en la ejecución de un script.

Eliminar todos los servidores que gestionan una raíz:

Get-DfsnRoot -Path \\MiEmpresa.Priv\RAIZ2-DOM2 | Get-DfsnRootTarget |

Remove-DfsnRootTarget -Confirm:false

Preste atención, la eliminación de todos los servidores que gestionan una raíz equivale a
suprimir la propia raíz. Por ello, las consolas de administración DFS que contengan esta
raíz obtendrán un error de acceso sobre esta raíz. Si se trata de una raíz que no va a volver a
utilizarse de forma permanente, basta, en tal caso, con eliminarla en la consola de
administración DFS.

b. Gestión de los destinos (de carpetas) y de los accesos

Nunca hay que utilizar directamente las raíces DFS para almacenar datos en ellas.
Estas raíces se alojan, generalmente, en controladores de dominio que no tienen los
mecanismos de copia de seguridad bien adaptados, ni espacio para alojar información.

Crear un destino de carpeta en un espacio de nombres:

New-DfsnFolder -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO -TargetPath

\\SRVFIC1\INFORMATICA -Description "Departamento Informático"
-EnableTargetFailback true

Agregar un destino suplementario en una carpeta existente:

New-DfsnFolderTarger -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO

targetPath \\DC2012\INFORMATICA
Path TargetPath State ReferralPriorityClass ReferralPriorityRank
---- ---------- ----- --------------------- --------------------

\\MiEmpresa.Priv\RAIZ... \\DC2012\INFORMATICA Online sitecost-normal 0

Eliminar un destino:

Remove-DfsnFolderTarget -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO

-TargetPath \\DC2012\INFORMATICA -Force

Eliminar la carpeta y los destinos correspondientes:

Remove-DfsnFolder -Path \\MiEmpresa.Priv\RAIZ2-DOM2\INFO -Force

Ninguna de las instrucciones anteriores elimina los datos de los usuarios, que siguen
estando en los recursos compartidos de los respectivos servidores.

2. Administración de la replicación con PowerShell

Los 42 nuevos comandos están accesibles mediante la siguiente instrucción:

Get-Command -Module DFSR

He aquí un comando que permite obtener detalles sobre cada uno de los comandos:

Get-Command -Module DFSR | Get-Help | Select-Object Name, Synopsis |

Format-Table -Auto

a. Ejemplo de creación de la infraestructura necesaria para un grupo de replicación de

dos servidores

Crear el grupo de replicación:

New-DfsReplicationGroup -GroupName "GrupoReplicacionContabilidad"

Observe que el grupo de replicación no se mostrará en la consola de administración, será

preciso agregarlo para poder gestionarlo desde la consola.

Crear una carpeta en el grupo de replicación:

New-DfsReplicatedFolder -GroupName "GrupoReplicacionContabilidad"

-FolderName "Contabilidad"

Agregar los servidores:

Add-DfsrMember -GroupName "GrupoReplicacionContabilidad"

-ComputerName SRVFIC01, DC2012

Verificar los miembros del grupo de replicación:

Get-DfsrMember -GroupName GrupoReplicacionContabilidad

Agregar las conexiones de replicación:

Add-DfsrConnection -GroupName "GrupoReplicacionContabilidad"

-SourceComputerName SRVFIC01 -DestinationComputerName DC2012

Se agrega una conexión en cada sentido.

Agregar las carpetas a replicar entre los servidores:

Set-DfsrMembership -GroupName "GrupoReplicacionContabilidad"

-FolderName "Contabilidad" -ContentPath "C:\CarpetasContabilidad"
-ComputerName SRVFIC01 -PrimaryMember /$True -force

Este comando agrega el contenido inicial que servirá de referencia.

Set-DfsrMembership -GroupName "GrupoReplicacionContabilidad"

-FolderName "Contabilidad" -ContentPath " C:\CarpetasContabilidad"
-ComputerName DC2012 -force

Este comando agrega un miembro suplementario.

Actualizar los servidores a partir del directorio Active Directory:

Get-DfsrMember -GroupName "GrupoReplicacionContabilidad" |

Update-DfsrConfigurationFromAD

La siguiente etapa consiste en verificar que la replicación está funcionando.

El evento 4104 en el registro específico de la replicación DFS indica que ha finalizado la

replicación inicial.

b. El clonado de la base de DFSR

Se han agregado algunas instrucciones específicas para mejorar la replicación inicial

cuando existe un conjunto importante de archivos iniciales:

He aquí las cuatro instrucciones que se utilizan:

Export-DfsrClone

Import-DfsrClone

Get-DfsrCloneState

Reset-DfsrCloneState
El objetivo de este clonado es ahorrar tiempo en el análisis y la replicación de una
arborescencia importante copiando la base de DFSR y los datos correspondientes en el
sistema de destino.

La primera etapa consiste en exportar la base de DFSR del volumen a una carpeta local.

Cree la carpeta de destino:

MD C:\ClonadoBaseDFSR

Exportar la base de DFSR del volumen E a la carpeta que acaba de crear:

Export-DfsrClone -Volume E: -Path C:\ClonadoBaseDFSR -force | Format-List

Este comando acepta dos opciones:

• La opción -validation, que acepta tres valores:

• None: no se realiza ninguna verificación de los archivos. Este valor no se aconseja,

pues supone que no se realizará ninguna modificación.
• Basic: este valor, por defecto, es el recomendado. Existe una serie de permisos
(ACL) que, junto al tamaño y la fecha, determinan si el archivo se ha modificado.
• Full: es el modo normal, utilizado por DFS, desaconsejado en una replicación con
un volumen muy elevado (superior a 10 TB).

• Por defecto, la exportación funciona únicamente si la carpeta de destino de la base

está vacía. La opción -AllowClober permite borrar los archivos presentes.

Supervisar la ejecución y esperar el estado Ready:

Get-DfsrCloneState

En efecto, el grupo de replicación debe existir antes de realizar la exportación de su

configuración. He aquí las instrucciones mínimas a realizar en el origen para obtener un
grupo de replicación que contenga un único miembro:

• Crear el grupo de replicación:

• New-DfsReplicationGroup -GroupName "GrupoReplicacionContabilidad"

• Agregar la carpeta de datos:

• New-DfsReplicatedFolder -GroupName "GrupoReplicacionDATA"
• -FolderName "DATA"

• Agregar el servidor origen que contiene los datos:

• Add-DfsrMember -GroupName "GrupoReplicacionDATA"
• -ComputerName SRVFIC01
 • Agregar el recurso de datos a la carpeta de datos:
• Set-DfsrMembership -GroupName "GrupoReplicacionDATA"
• -ComputerName "SRVFIC01" -ContentPath E:\DATA
• -PrimaryMember $True -FolderName "DATA" -force

• Actualizar la configuración a partir del directorio:

• Update-DfsrConfigurationFromAD

Una vez exportada la base, la siguiente operación consiste en replicar la base

salvaguardada, y también los datos correspondientes.

Robocopy.exe E:\Data \\DC2012\E$ \DATA /E /B /COPYALL /R:1 /W:1

/MT:64 /XD DfsrPrivate /TEE /LOG+:Precarga.log

• Replicación de la copia de seguridad de la base de DFSR correspondiente al

volumen a replicar:
• Robocopy.exe C:\ClonadoBaseDFSR \\DC2012\C$\ClonadoBaseDFSR /B

• Como precaución, limpiar la base de DFSR que podría residir en el servidor de

destino:
• RD "E:\system volume information\dfsr" -Force -Recurse

Es conveniente no realizar esta acción en el disco que contiene la replicación de las

bases de DFSR de los controladores de dominio, u otras replicaciones de DFS.

• Importar la base de DFSR en el nuevo volumen:

• Import-DfsrClone -Volume E: -Path "C:\ClonadoBaseDFSR" -force

La opción -force permite evitar que pida la confirmación.

• Verificar, a continuación, que la integración de la base está lista, mediante el estado

Ready:
• Get-DfsrCloneState

• Agregar el servidor de destino en el grupo de replicación:

• Add-DfsrMember -GroupName "GrupoReplicacionDATA"
• -ComputerName "DC2012"

• Indicar que el servidor pertenece al grupo de datos DATA, así como la ruta de los
datos en este servidor:
• Set-DfsrMembership -GroupName "GrupoReplicacionDATA"
• -ComputerName "DC2012" -ContentPath E:\DATA -FolderName "DATA"
• -force

• Por último, agregar la conexión de replicación entre los dos servidores:

• Add-DfsrConnection -GroupName "GrupoReplicacionDATA"
• -SourceComputerName "SRVFIC01" -DestinationComputerName "DC2012"
 • Actualizar el servidor de destino a partir de la información del directorio.
• Update-DfsrConfigurationFromAD

Utilizando este método de importación de la base, la verificación inicial puede pasar de 24

días a menos de 8 horas para un volumen de cerca de 10 TB, es decir, para obtener la
convergencia de 14 millones de archivos a verificar, utilizando el nivel de validación "por
defecto".

Uso de DFS y buenas prácticas

El uso de DFS no requiere ninguna adaptación en los puestos cliente.

En efecto, del lado del usuario (y de los clientes Windows), los recursos compartidos DFS
y las raíces se ven como recursos compartidos clásicos. Es frecuente, en el script de
conexión, realizar una conexión con la raíz, a menudo remplazando todas las conexiones
anteriores.

Por otro lado, es importante tener en cuenta que las raíces DFS de dominio están
disponibles para todos los usuarios del bosque. No obstante, todos los permisos asociados a
los recursos compartidos y a las carpetas NTFS siguen estando activos como si se tratase de
un acceso directo.

En cambio, el uso de DFS permite simplificar el número de unidades de disco y de recursos

compartidos utilizados. Esto permite federar el conjunto de espacios disponibles.

Las aplicaciones pueden configurarse sobre una ruta única, que será posible mantener a lo
largo de todo el ciclo de vida del bosque.

DFS, en su configuración Hub & Spoke, se diferencia por la replicación en varios sitios de
información que cambia poco con el tiempo o que tiene un único punto de modificación.
Documentos de referencia, noticias, actas de reunión o información general serán el tipo de
documento entrante en este tipo de configuración.

DFS puede, también, utilizarse para salvaguardar los datos de usuario o los perfiles
itinerantes. Es preciso realizar una configuración particular a nivel de los destinos DFS para
que se utilice siempre el mismo recurso compartido y el mismo servidor. Es decir, es
preciso utilizar el destino principal en primer lugar, y no proponer la copia (salvaguarda)
sino como último destino.

Cuando se utiliza DFS para tareas ofimáticas, con numerosos documentos de tipo Word o
Excel, actualizándose sobre distintos sitios, es importante gestionar bien el versionado de
los documentos para evitar cualquier modificación simultánea del mismo documento. En
efecto, sólo se conservará la última versión escrita. En ciertos casos, será preferible forzar
el uso de un destino determinado que servirá como referencia para las modificaciones de
este tipo, incluso si el sitio del usuario incluye una replicación local de este destino. La
solución ideal, cuando sea posible, consiste en utilizar el modo Solo lectura con todos los
destinos, salvo con el destino de referencia.

Con todo, aunque DFS no es la solución universal, puede proveer muchos servicios que
merece la pena comparar con otras soluciones, por ejemplo, de gestión documental.

Interacción con otros componentes

1. Los espacios de nombres DFS: detección del sitio por parte de los
clientes DirectAccess

Windows Server 2012 ofrece, ahora, la posibilidad a los usuarios remotos conectados
mediante DirectAccess de utilizar el mejor enlace DFS posible, según el sitio.

Los usuarios remotos reciben referencias hacia los servidores de nombres y las carpetas
más próximas a la ubicación de la conexión.

Con las conexiones DFS realizadas por DirectAccess en Windows 7 o Windows

Server 2008 R2, los equipos remotos cuya dirección IP no forma parte de un sitio
específico en Active Directory reciben una sola referencia. Esta referencia contiene
únicamente un nombre de servidor que proviene de cualquier sitio, local o remoto.

Cuando las conexiones DFS se realizan mediante DirectAccess en Windows 8 o Windows

Server 2012, el equipo provee un nombre de sitio en la solicitud de referencia (Request
Referral) que apunta a un servidor de espacios de nombres que utiliza Windows Server
2012. El servidor de espacios de nombres utilizará el sitio transmitido para proveer la
referencia hacia el sitio más próximo disponible.

Para que esta detección funcione, el cliente debe ejecutar Windows 8 o Windows Server
2012, y el servidor trabajar con Windows Server 2012.

Observe que la instalación de varios puntos de acceso basados en DirectAccess está, ahora,
mucho mejor gestionada que con Windows Server 2008, de ahí el interés de apuntar al
servidor DFS mejor adaptado.

2. La replicación DFS soporta los volúmenes sobre los que se ha activado

la desduplicación

De hecho, la desduplicación permite ganar espacio sin tener ningún impacto sobre la
replicación DFS. Cuando se activa la desduplicación sobre un volumen, los archivos se
segmentan en bloques de tamaño variable según el tamaño del archivo. La desduplicación
gestiona un índice sobre estos segmentos para detectar los segmentos idénticos y ocupar
una única vez el espacio correspondiente. Una marca de desduplicación
IO_REPARSE_TAG_DEDUP indicará cada archivo susceptible de incluir elementos
deduplicados.

La replicación seguirá a las marcas de desduplicación de tipo

IO_REPARSE_TAG_DEDUP para reconstruir el archivo completo.

Que un archivo esté desduplicado o no, no supone ninguna replicación puesto que el
archivo, en sí mismo, no cambia. La replicación DFS se basa en el algoritmo RDC (Remote
Differential Compression) y no sobre los fragmentos de los archivos desduplicados, que se
ubican de forma separada. Que los volúmenes estén desduplicados en el origen y/o en el
destino no cambia nada.

3. DFS dispone de un proveedor WMI completo (espacios de nombres y

replicación)

Windows Server 2012 proporciona, ahora, un proveedor WMI que permite acceder y
realizar una configuración completa de la replicación DFS...

gwmi -list | ft name | findstr /I "dfs"

Win32_DfsNode
Win32_DfsTarget
Win32_DfsNodeTarget
Win32_PerfFormattedData_DFSNServerService_DFSNamespace
Win32_PerfRawData_DFSNServerService_DFSNamespace
Win32_PerfFormattedData_DFSNServerService_DFSNamespaceServiceAPIRequests
Win32_PerfRawData_DFSNServerService_DFSNamespaceServiceAPIRequests
Win32_PerfFormattedData_DFSNServerService_DFSNamespaceServiceReferrals
Win32_PerfRawData_DFSNServerService_DFSNamespaceServiceReferrals
Win32_PerfFormattedData_dfsr_DFSReplicatedFolders
Win32_PerfRawData_dfsr_DFSReplicatedFolders
Win32_PerfFormattedData_dfsr_DFSReplicationConnections
Win32_PerfRawData_dfsr_DFSReplicationConnections
Win32_PerfFormattedData_dfsr_DFSReplicationServiceVolumes
Win32_PerfRawData_dfsr_DFSReplicationServiceVolumes

A continuación, se muestra un ejemplo de acceso a la información de una de estas clases:

gwmi -class win32_dfsnode

__GENUS : 2
__CLASS : Win32_DfsNode
__SUPERCLASS : CIM_LogicalElement
__DYNASTY : CIM_ManagedSystemElement
__RELPATH : Win32_DfsNode.Name="\\\\SRVFIC01\\RAIZ-AUTONOMA"
__PROPERTY_COUNT : 8
__DERIVATION : {CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER : SRVFIC01
__NAMESPACE : root\cimv2
__PATH :
\\SRVFIC01\root\cimv2:Win32_DfsNode.Name="\\\\SRVFIC01\\
RAIZ-AUTONOMA"
Caption :
Description :
InstallDate :
Name : \\SRVFIC01\RAIZ-AUTONOMA
Root : True
State : 0
Status :
Timeout : 300
PSComputerName : SRVFIC01
...

Hoy en día, como existen los comandos PowerShell para la parte Espacios de nombres, es,
principalmente, la parte de replicación la que se configurará mediante WMI. Sepa que el
acceso WMI puede invocarse, fácilmente, desde PowerShell, y será posible integrar el
conjunto en un único script.

WMI, a diferencia de PowerShell, permite administrar completamente la replicación

mediante DFS: http://msdn.microsoft.com/en-
us/library/windows/desktop/bb540028(v=vs.85).aspx

He aquí las clases que se utilizan para ello:

• DfsrConfig
• DfsrConflictInfo
• DfsrConnectionConfig
• DfsrConnectionInfo
• DfsrIdRecordInfo
• DfsrIdUpdateInfo
• DfsrInfo
• DfsrLocalMemberConfig
• DfsrLocalMemberInfo
• DfsrMachineConfig
• DfsrReplicatedFolderConfig
• DfsrReplicatedFolderInfo
• DfsrReplicationGroupConfig
• DfsrSyncInfo
• DfsrVolumeConfig
• DfsrVolumeInfo

Una de las principales diferencias es que, ahora, el acceso WMI utiliza el protocolo
WinRM (Windows Remote Management) como protocolo de transporte.

BranchCache
Esta funcionalidad, aparecida con Windows Server 2008 R2, permite optimizar el acceso a
los recursos compartidos alojados en los recursos compartidos de los archivos o en
servidores Web internos de tipo documentario, tales como SharePoint, para los sitios
remotos.

La lógica de funcionamiento se parece bastante a la de los Proxy de Internet. Es decir,

durante la primera recuperación de un documento (archivo o ejecutable), éste pasa una
única vez por el enlace lento. Para los demás clientes de este documento, sobre este sitio,
tras realizar una verificación de los permisos y de la no modificación del documento, se
transmite directamente desde el equipo presente en el sitio que dispone de una copia. El
ahorro se realiza no únicamente en el ancho de banda del enlace, sino también en el tiempo
de acceso a los documentos y aplicaciones remotos que puede resultar muy similar al de un
acceso local.

Esta opción también está disponible a partir de Windows 7 bajo la forma de una caché
repartida entre las distintas máquinas.

A partir de sistemas cliente Windows 7 y servidores 2008 R2, es posible utilizar la

tecnología BranchCache. Para ello, basta con activar la directiva de Windows
correspondiente.

Preste atención, en aquellos servidores de archivos donde quiera activar los recursos
compartidos y utilizar BranchCache, debe agregar un servicio de rol en el rol Servicios de
archivos y almacenamiento.

1. Instalación de BranchCache

La primera etapa consiste en instalar la funcionalidad sobre cada servidor que comparte
recursos.

No obstante, todas las operaciones pueden realizarse a partir de una única máquina que
posea el administrador del servidor 2012 instalado.

El asistente que permite agregar roles y características puede ejecutarse desde

distintos niveles del administrador del servidor. La opción más rápida es, a menudo, el
botón Administrar del menú principal.
La instalación de todos los roles y funcionalidades se realiza con una única selección.
 Seleccione el servidor que desea configurar. Preste atención, por defecto, sólo aparece el
servidor local. Los demás servidores deben agregarse previamente. La administración
remota debe estar autorizada a nivel de firewall.
 Cada servidor accesible por los clientes que utiliza la función de BranchCache debe
habilitar este modo. Esta opción permite habilitar la caché sobre los archivos compartidos
de este servidor.
Seleccione la opción BranchCache para archivos de red.

El servidor está, ahora, activo como cliente y servidor de BranchCache para los sitios Web
y cliente, únicamente, para los servidores de recursos compartidos de archivos.
Seleccione BranchCache.

El servidor está, ahora, activo como servidor de BranchCache para los archivos.

El servicio BITS (Servicio de transferencia inteligente en segundo plano) debe estar

iniciado si quiere utilizar BranchCache sobre los sitios Web de este servidor.

Confirme la selección.
 Tras la instalación, se inicia el servicio BranchCache, habitualmente sin necesidad de
reiniciar el servidor.
A continuación, debe activar una directiva de grupo que permita, al servidor, utilizar las
funcionalidades de decodificación de tipo "Hash coding". Esta funcionalidad permite
identificar cada documento de forma única y detectar sus modificaciones basándose en el
hash único para cada archivo.

Esta opción autoriza la activación de BranchCache sobre todos los recursos compartidos.
No olvide forzar la aplicación de la directiva.

La gestión de las directivas de grupo se accede desde el menú Herramientas de un

controlador de dominio.

La configuración del servicio BranchCache se aplica sobre la directiva Equipo, en

Directivas - Plantillas administrativas - Red - BranchCache.
2. Configuración de los recursos compartidos

Sobre cada recurso compartido, la opción de caché puede accederse mediante el botón
Configuración sin conexión.
La configuración de los recursos compartidos puede realizarse desde la consola
Administración de equipos - Carpetas compartidas - Administrar recursos
compartidos y almacenamiento o, simplemente, desde la propia carpeta, mediante la
pestaña Recursos compartidos - Uso compartido avanzado y, a continuación, el botón
Caché.

Seleccione la opción Habilitar BranchCache.

Preste atención, a diferencia del modo sin conexión clásico, los documentos o programas
ejecutables sólo estarán disponibles si el recurso compartido y el documento remoto están,
efectivamente, accesibles. En efecto, antes de enviar el documento al usuario desde la
caché, es necesario verificar que el archivo no se ha modificado y que los permisos siguen
autorizando al usuario acceder al mismo.

3. Configuración de los clientes

El servicio BranchCache viene instalado, por defecto, en los clientes Windows 7 y 8,

aunque deberá iniciarlo para que la directiva de grupo sea eficaz.

Ejecute la herramienta de Administración de directivas de grupo desde el

Administrador del servidor.

Cree una nueva directiva específica en el contenedor Objetos de directiva de grupo.

Puede asociar, más adelante, la directiva a la unidad organizativa que contiene los equipos
seleccionados.

He aquí la directiva de grupo que debe definir para configurar los clientes:
• El parámetro Activar BranchCache permite habilitar el uso de la caché, aunque no
se produce el arranque del servicio BranchCache, que se configura para arrancar
automáticamente sobre los equipos.

Su activación se realiza mediante la directiva, y se proponen dos modos:

• El modo distribuido, que se utiliza cuando no hay ningún servidor disponible en el

sitio.

En este modo, todas las estaciones del sitio activadas por el BranchCache
comparten la caché y verifican, de manera local, la presencia del documento
buscado en una de las cachés antes de ir a buscar el archivo original en el sitio
central.

• El modo hospedado, a menudo recomendable cuando existe un servidor Windows

2008 R2 o superior en el sitio remoto.

En este modo, todas las estaciones del sitio activadas por el BranchCache utilizan el
servidor para verificar la presencia del documento y alojarlo en la caché si es
necesario.

• La activación del modo BranchCache para archivos de red permite indicar el

retardo a partir del cual se decide, efectivamente, poner en caché el archivo
afectado.
 El valor 0 hace que se alojen en caché todos los archivos.

• El parámetro Establecer el porcentaje de espacio en disco usado por la memoria

caché del equipo cliente define el porcentaje de espacio en disco autorizado para la
caché sobre las estaciones o los servidores definidos para el almacenamiento de los
archivos.
 El valor por defecto es un 5 %.

Esta lógica significa que se preparará una directiva específica para cada sitio remoto
que contenga bien un servidor, o bien una caché repartida entre las distintas
estaciones. Observe que el arranque automático del servicio puede incluirse en la
misma directiva.

A partir del cliente Windows 8, se incluyen algunas novedades:

• La activación de detección automática de la caché hospedada permite, al cliente,

buscar directamente el servidor hospedado correspondiente con el sitio de conexión,
lo que evita una configuración por sitio.
• El parámetro Establecer el vencimiento de los segmentos de la memoria caché
de datos define el periodo de tiempo durante el que se conservan los elementos
considerados como válidos. La duración por defecto es de 28 días.
• El parámetro Configurar compatibilidad con versiones de clientes de
BranchCache permite, a los clientes Windows 8, ser compatibles con las versiones
anteriores de BranchCache. Si esta opción no se utiliza, cada máquina utiliza su
propia versión y su propio formato, lo cual puede provocar incompatibilidades con
los datos hospedados en la caché por una versión diferente.
En definitiva, Microsoft refuerza la optimización de los sitios remotos, buscando, siempre,
mejorar el acceso remoto. En efecto, este tipo de funcionalidad permite considerar una
centralización mucho más importante de recursos y archivos compartidos, limitando el
número de servidores necesarios para mantener el conjunto y facilitar la administración y la
copia de seguridad del conjunto de información.

Las carpetas de trabajo

1. Presentación

Se trata de un nuevo rol de servicio que depende del servicio de archivos y de

almacenamiento. El objetivo es permitir la sincronización de archivos profesionales entre
varios PC o dispositivos que pertenezcan al mismo usuario, pertenezcan o no a la empresa.
Los archivos los gestiona la empresa, que mantiene el control de la información definiendo
el marco de uso mediante directivas de encriptación y de contraseña.
De momento, sólo Windows 8.1 (versiones normal y RT) pueden utilizar esta funcionalidad
(el módulo no existe en el servidor y, por tanto, no es compatible con Windows Server
2012 R2). Existe una aplicación, Work Folders client for Devices, pero no se ha
proporcionado una fecha para su publicación en el momento de escribir estas líneas.

Las carpetas de trabajo se ubican en una carpeta del servidor llamada Recurso compartido
de sincronización. La carpeta seleccionada puede contener documentos del usuario que
estarán disponibles, inmediatamente, para el usuario sin tener que realizar ninguna
migración.

La administración se lleva a cabo desde la interfaz del Administrador del servidor o

mediante comandos PowerShell.

He aquí la lista de comandos que puede es posible utilizar:

Comando
Descripción
PowerShell
Enable-SyncShare Activar un recurso compartido de sincronización
Disable-SyncShare Desactivar un recurso compartido de sincronización
Get- Obtener la configuración de un recurso compartido de
SyncServerSetting sincronización.
Get-SyncShare Obtener la lista de recursos compartidos
Get-SyncUserSetting Recuperar la configuración del usuario desde el servidor de
sincronización.
Get-SyncUserStatus Recuperar el estado del usuario desde el servidor de
sincronización.
New-SyncShare Crear un recurso compartido de sincronización.
Remove-SyncShare Eliminar un recurso compartido de sincronización.
Repair-SyncShare Reinicializar los metadatos de un usuario de recurso
compartido de sincronización.
Set- Modificar la configuración de un servidor de recursos
SyncServerSetting compartidos de sincronización.

2. Requisitos previos

En la red interna, he aquí los requisitos previos mínimos:

• Un servidor Windows Server 2012 R2

• Un volumen con formato NTFS

Para acceder desde Internet:

 • Se recomienda utilizar un certificado en el servidor (el acceso mediante http es
posible, aunque debe evitarse en producción).
• El servidor debe estar accesible mediante HTTPS (y/o http) desde Internet, a través
de una publicación de tipo ReverseProxy o Gateway.

De manera opcional, si los controladores de dominio no funcionan con Windows Server

2012 R2:

• Una extensión del esquema para agregar un atributo que contenga el servidor de
sincronización.

Si esta extensión no se lleva a cabo, el usuario debe conocer e informar la URL de

acceso cuando se configure la configuración del cliente.

• Una infraestructura AD FS, si se utiliza autenticación AD FS (consulte el capítulo

Acceso remoto - sección Rol Web Application Proxy).

En los equipos cliente:

• Una versión de Windows adaptada (de momento Windows 8.1 o 8.1 RT).
• El espacio suficiente en el disco local NTFS.

Por defecto, la carpeta %USERPROFILE%\Work Folders contiene los datos

sincronizados. Pero es posible seleccionar otra ubicación, en un dispositivo USB o
MicroSD, por ejemplo. El tamaño máximo de los archivos es de 10 GB. Es posible definir
cuotas mediante el FileServerResourceManager.

3. Instalación en el servidor

La instalación mediante PowerShell es relativamente sencilla:

Add-WindowsFeature FS-SyncShareService

Con una única instrucción es posible implementar este nuevo tipo de recurso compartido.

New-SyncShare SyncDataUsuarios -path E:\ USERS

-User MiEmpresa\MiUsuario -RequireEncryption $true
-RequirePasswordAutoLock $true

Las distintas opciones de configuración se detallan en la configuración mediante el

asistente gráfico. En concreto, encontraremos:

• El uso de una subcarpeta determinada que podemos indicar, en caso contrario se

incluirán todas las carpetas.
• El uso del nombre de login (NetBIOS) o el nombre único, llamado UPN.
Desde el asistente para agregar roles y características es preciso seleccionar el rol Servicios
de archivos y almacenamiento y, a continuación, Servicios de iSCSI y archivo.

Es probable que el servidor seleccionado ya tenga estos elementos instalados.

Seleccione, a continuación, el rol de servicio Carpetas de trabajo entre los componentes

propuestos.

Valide para agregar la funcionalidad Núcleo de web hospedable IIS.

Esta funcionalidad habilita y utiliza, automáticamente, los puertos 80 (HTTP) y 443
(HTTPS).

Tras validar la funcionalidad:

Observe que los demás componentes de IIS no son indispensables para el buen
funcionamiento.

Las carpetas de trabajo están, ahora, instaladas.

La configuración se encuentra, naturalmente, en la sección Servicios de archivos y
almacenamiento del servidor local.

Haga clic en el vínculo Para crear un recurso compartido de sincronización para

Carpetas de trabajo….
Para simplificar seleccione, preferentemente, una carpeta nueva y específica para este uso.

Cada usuario tendrá su carpeta personal en la carpeta indicada; la solución aquí diseñada es
útil únicamente para carpetas personales y, en ningún caso, para carpetas comunes.

La carpeta se crea si no existe.

Indique la nomenclatura utilizada para las carpetas, así como la carpeta que se desea
sincronizar, si no queremos sincronizar el total de carpetas presentes en la ubicación
indicada.
Por ejemplo, si utilizamos la carpeta E:\USERS, esta carpeta se comparte para recibir todas
las carpetas personales bajo la forma \\servidor\USERS\%username%, mientras que puede
ser preferible limitar la replicación de la carpeta de trabajo únicamente a una subcarpeta
concreta, nueva o existente.

Indique el nombre del recurso compartido de sincronización y su descripción.

 Agregue los usuarios o, mejor, los grupos autorizados que deben poder utilizar este recurso
compartido de sincronización.
A menudo es preferible deshabilitar la herencia de las autorizaciones a este nivel para evitar
cualquier riesgo de conflicto con permisos no deseados (la opción correspondiente está
marcada por defecto). Esto es, sobre todo, importante si la carpeta seleccionada o una
carpeta superior están compartidas y se han definido permisos sobre las carpetas superiores.

Indique la seguridad seleccionada para los datos.

Esta directiva debe aceptarla el usuario antes del primer uso de los grupos de trabajo,
incluidos ordenadores y dispositivos que no forman parte de la empresa (o del dominio) y
sobre los que el usuario desea realizar la sincronización.

Valide el conjunto de opciones configuradas.

La representación del resultado final:
El acceso a las carpetas se vuelve lo más seguro posible. Por defecto, sólo el acceso
mediante el protocolo encriptado HTTPS está habilitado en el equipo cliente. Esto significa
que es preciso disponer de un certificado en el servidor.

Si el servidor recibe automáticamente un certificado emitido por una entidad emisora

interna, las carpetas de trabajo pueden utilizarse automáticamente.

A modo de prueba, es posible deshabilitar la obligación de usar HTTPS en el equipo cliente

ejecutando el siguiente comando en el equipo cliente:

Reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WorkFolders /v

AllowUnsecureConnection /t REG_DWORD /d 1

Mejor que deshabilitar el uso de HTTPS, una solución más elegante consiste en generar un
certificado que contenga los nombres internos y externos, para permitir a los clientes
acceder a las carpetas de trabajo de forma segura tanto desde la red local (mediante la URL
WorkFolders.MiEmpresa.Priv) como desde una red externa (WorkFolders.MiEmpresa.Es),
que es el objetivo principal de esta funcionalidad.

El siguiente comando permite generar un certificado autofirmado con este fin. Sepa que es,
también, posible comprar un certificado emitido por un proveedor público si no dispone de
una PKI en su empresa o el despliegue de certificados autofirmados le resulta demasiado
complejo.

New-SelfSignedCertificate -DnsName
"WorkFolders.MiEmpresa.Priv","SrvFic01.MiEmpresa.Priv",
"WorkFolders.MiEmpresa.Es" -CertStoreLocation
cert:Localmachine\My

Tras crear el certificado, debe agregarlo en las entidades raíz del servidor, y en los distintos
clientes.

El nombre DNS WorkFolders permite automatizar y facilitar la búsqueda, disponiendo de

una forma para descubrir automáticamente la configuración, a partir de la dirección de
mensajería indicada por el usuario una vez se establece la conexión. Se recomienda crear
una entrada de tipo CNAME (alias) para este nombre en la zona DNS interna, y hacerla
apuntar al registro A (Host) correspondiente al servidor de archivos.

Para habilitar el uso del certificado que acaba de instalar, es preciso afectar al proceso IIS
Core mediante el siguiente comando que puede ejecutar desde una ventana de comandos
CMD.

netsh http add sslcert ipport=0.0.0.0:443 certhash=<Cert thumbprint>

appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D}
certstorename=MY

El número de firma (thumbprint) que debe indicar en el comando puede obtenerse mediante
el siguiente comando PowerShell:

dir cert:\localmachine\my
Thumbprint Subject
---------- -------
EFEE6E02A04A2C1D18AF2B70B49103DF2E191ABC CN=WorkFolders.MiEmpresa.Priv

Para completar esta sección sobre la configuración, es posible modificar el esquema Active
Directory para agregar un campo suplementario que permita administrar la URL de acceso
a las carpetas de trabajo. Este campo puede resultar interesante si varias carpetas de trabajo
se definen en distintos servidores para asociar al usuario a una carpeta de trabajo concreta.

Esta extensión se agrega, por lo general, en el esquema tras su actualización, antes de

promover el primer controlador de dominio 2012 R2.

El siguiente enlace indica los elementos necesarios para administrar esta extensión sin tener
que preparar el dominio para Windows Server 2012 R2:
http://blogs.technet.com/b/filecab/archive/2013/10/09/a-new-user-attribute-for-work-
folders-server-url.aspx

Por otro lado, la gestión de la directiva de 2012 R2 permite modificar esta URL para el
usuario.
El parámetro Especificar configuración de carpetas de trabajo se encuentra en Usuarios
- Directivas - Plantillas administrativas - Componentes de Windows - Carpetas de
trabajo.

Permite habilitar las carpetas de trabajo, indicar la dirección URL que debe utilizar, y forzar
la configuración automática.

4. Configuración en el puesto cliente

El módulo Carpetas de trabajo está integrado en Windows 8.1. Basta con configurarlo
desde el panel de control.

Acceda al Panel de control y seleccione Carpetas de trabajo.

Haga clic en Configurar carpetas de trabajo.

Indique su sufijo UPN (tiene el formato de una cuenta de correo electrónico).

La URL se configura automáticamente si los equipos están integrados en el directorio o si

la configuración automática está basada en el nombre WorkFolders.

Si la configuración automática no funciona, o si desea utilizar un servidor de sincronización

diferente, la opción Indicar una URL de Carpetas de trabajo sirve para definir una
dirección de sitio web diferente.

En el caso de una estación integrada en AD, se utiliza la autenticación integrada.

Si todo funciona bien, la configuración continúa con la configuración de la ubicación de los

datos.
Acepte la directiva de empresa.

Este concepto es importante en términos de permisos de datos, incluso para equipos

integrados en el dominio.

La configuración de las carpetas de trabajo finaliza.

Es posible, a continuación, administrar la configuración de las carpetas de trabajo desde el
Panel de control.

Con el uso, es posible modificar ciertos parámetros de sincronización en el servidor y en el

puesto cliente.
Por defecto, las modificaciones locales sobre los dispositivos tienen preferencia e inician la
sincronización. Si las modificaciones provienen del servidor (o de la sincronización de otro
dispositivo), tardarán más en tenerse en cuenta. Es, por tanto, posible configurar el
intervalo entre dos verificaciones de sincronización.

Por defecto, el intervalo de verificación es de 5 minutos. El valor mínimo es de 1 minuto,

aunque si se disminuye este valor, no hay que olvidar tener en cuenta la potencia de CPU y
el disco necesarios para realizar esta operación, que depende de la cantidad de archivos a
examinar.

He aquí la sentencia PowerShell que permite configurar este parámetro a tres minutos.

set-SyncServerSetting -MinimumChangeDetectionMins 3

Conclusión
¡Se han aportado numerosas mejoras relativas a DFS! Por ejemplo, el hecho de disponer de
comandos PowerShell para configurar la replicación DFS permite utilizar Remote
PowerShell desde una máquina donde el componente no se encuentre instalado.

La existencia de un proveedor WMI para la replicación mejora las nuevas herramientas de

gestión destinadas a controlar la replicación.

Una base de DFSR corrupta puede reconstruirse sin riesgo de pérdida de enlaces ligados a
una sincronización inicial no autoritativa. Ya no se corre el riesgo de perder,
arbitrariamente, los archivos en conflicto. Antes, en caso de producirse un error en la base
tras una sincronización inicial, la replicación reiniciaba completamente desde el origen, sin
tener en cuenta archivos más recientes que podrían encontrarse.

El cross-file RDC se encuentra, ahora, deshabilitado. Por defecto, la replicación puede

utilizar hasta cinco orígenes de un mismo archivo para generar un nuevo archivo sobre un
nuevo destino. Se obtiene, también, un ahorro en tiempo y en ancho de banda en redes
lentas o de tipo medio. En cambio, según la configuración de la red, si las redes son
rápidas, es posible que afecte al rendimiento y al tiempo que se pasa de manera local a
procesar la información cuando se tratan conjuntos importantes de archivos con muchas
similitudes. ¡Los comandos SET-DFSRConnection y ADD-DFSRConnection soportan,
ahora, la opción -DisableCrossFileRdc!

El file staging tuning permite definir el tamaño mínimo a partir del cual se comprime un
archivo y se replica por partes, pasando por la etapa llamada Staging. El resultado es que,
por defecto, los archivos de menos de 64 KB no pasan por esta etapa de staging y no se
comprimen. Windows Server 2012 R2 permite indicar el tamaño mínimo (entre 256 Kb y
512 TB) antes de que un archivo se procese y comprima. Los rendimientos se ven, de este
modo, mejorados en detrimento de un ancho de banda algo más exigente.
Existen dos nuevos comandos PowerShell que facilitan la recuperación de los archivos en
conflicto (ConflictAndDeleted) y carpetas preexistentes (PreExisting): Get-
DFSRPreservedFiles muestra los datos correspondientes y Restore-DFSRPreservedFiles
los recupera bien en su carpeta de origen, o bien en un nuevo destino

Tras un corte de corriente o un fallo inesperado, la base de datos de DFSR se repara y, a

continuación, se reactivan automáticamente las replicaciones una vez preparada la base de
datos.

En caso de deshabilitar un miembro de la replicación DFSR, los datos presentes, incluidas

las carpetas ConflictAndDeleted y PreExisting, no se eliminan.

Esto representa muchas pequeñas mejoras que, de manera global, aportan una fiabilidad
mucho mayor a los datos gestionados mediante DFS.

Introducción
Este capítulo está dedicado a la alta disponibilidad. Su objetivo es describir las posibles
ofertas en términos de alta disponibilidad con Windows Server 2012 R2. Aumentar la
disponibilidad de los servicios que se ofrecen es un reto permanente en cualquier
departamento informático.

Existen una serie de factores que favorecen esto:

• Homogeneizar los servidores que se basan en una instalación y una configuración

idénticas (véase el capítulo Despliegue de servidores y puestos de trabajo).
• Centralizar la configuración por GPO (consulte el capítulo Dominio Active
Directory).
• Salvaguardar y mantener actualizados los servidores (consulte el capítulo El ciclo
de vida de su infraestructura).
• Replicar los archivos ofimáticos (consulte el capítulo Arquitectura distribuida de
acceso a los recursos).
• Duplicar los servicios de infraestructura de red (controladores de dominio,
servidores DNS, DHCP...).
• Utilizar la versión Core de Windows Server 2012 R2 para limitar los tiempos de
indisponibilidad debidos a instalaciones o actualizaciones de seguridad.
• Virtualizar el servicio y hospedar la máquina virtual en un clúster Hyper-V.

Una vez llevadas a cabo todas estas acciones, algunos servicios críticos siguen dependiendo
de un servidor único que, tarde o temprano, fallará o será necesario reiniciar tras haber
instalado algún parche o correctivo. Es aquí donde entra en juego la alta disponibilidad, que
permite convertir un servicio necesariamente disponible en un servicio altamente
disponible. Es un buen complemento de los factores anteriores.
Los servidores que participan de la alta disponibilidad se designan como nodos de un
clúster, y éste define al conjunto de servidores. El clúster se prevé para dar respuesta a
fuertes necesidades de disponibilidad y no debe considerarse a la ligera. Antes de decidir si
una solución de tipo clúster responde a esta necesidad, es necesario plantearse ciertas
preguntas:

• ¿Cuál es la tasa de disponibilidad de la solución actual?

• ¿Cuál es la tasa de disponibilidad deseada/solicitada?
• ¿Cuánto cuesta la pérdida de la disponibilidad actual?
• En caso de fallo, ¿cuánto tiempo hace falta para restaurar el servidor?
• ¿Está la solución que presta el servicio preparada para funcionar en modo clúster?
• ¿Un solo servidor es capaz de aportar todos los recursos de hardware necesarios o es
necesario disponer de varios servidores activos al mismo tiempo?

Elecciones de arquitectura
1. Las distintas arquitecturas

Tras los términos de alta disponibilidad se esconden dos tipos de soluciones distintas:

• Soluciones de tipo activo/pasivo.

• Soluciones de tipo activo/activo.

La primera solución aumenta la disponibilidad del servicio haciendo bascular los recursos
de un servidor a otro en caso de existir algún problema (solución altamente disponible). La
segunda solución permite tener varios servidores que responden a las solicitudes al mismo
tiempo (reparto de carga) y que pueden tolerar la pérdida de algún miembro (solución
altamente disponible).

Las soluciones de tipo activo/activo pueden parecer, a primera vista, más interesantes,
aunque son, generalmente, mucho más complejas y deben considerarse para dar respuesta a
un problema concreto de reparto de carga. En un entorno Microsoft, las soluciones son las
siguientes:

• Solución activo/pasivo: clúster de conmutación por error (MSCS - Microsoft

Cluster Service).
• Solución activo/activo: clúster de reparto de carga de red (NLB, Network Load
Balancing).

Una aplicación destinada a los usuarios debe ser compatible con una solución de alta
disponibilidad. Dejando a parte los "grandes" desarrolladores de software, es habitual que
un proveedor de aplicaciones no haya probado, jamás, su aplicación en un entorno de alta
disponibilidad y que no pueda, por tanto, asegurar su funcionamiento. Como mínimo, cabe
analizar los siguientes puntos :
 • ¿Puede residir el conjunto de datos en volúmenes compartidos y, por tanto,
diferentes a las unidades locales C:, D...?
• ¿Deben replicarse algunas claves de registro entre ambos servidores?
• ¿La aplicación utiliza algún dispositivo de protección física (dongle instalado en un
puerto USB o paralelo, por ejemplo) o se requiere una conexión física que no se
puede duplicar ni conectarse sobre dos servidores?
• ¿Los clientes pueden utilizar un nombre NetBIOS/DNS y una dirección IP distintos
del de la máquina física (nombre/IP virtuales)?
• ¿Cuáles son los mecanismos para detectar un fallo en la aplicación y decidir
bascular al otro nodo?

Caso 1: solución activo/pasivo

Un único servidor hospeda un mismo recurso en un momento determinado. No existe

ninguna necesidad de sincronizar los datos de aplicación con los demás servidores (hasta
64, como máximo). Si se produce un fallo, otro servidor inicia la aplicación, que tendrá
acceso a los mismos volúmenes de disco que el servidor anterior, debiendo gestionar la
interrupción brusca del servicio (registros de transacciones, en el caso de una base de datos,
por ejemplo). El almacenamiento puede suponer un punto de fallo único en ciertos casos. El
almacenamiento corporativo (SAN, etc.) es caro, y generalmente se comparte entre varias
aplicaciones y plataformas. En contrapartida, todos los elementos se duplican,
especialmente los controladores. Si bien se tiene especial precaución en que nunca se
produzca un fallo, sigue siendo posible. Otro problema es la corrupción de algún volumen
(LUN) que hospede datos. Si fuera preciso realizar una verificación de la partición
(chkdsk), cabría considerar la indisponibilidad durante la duración de la misma (que
depende del número de archivos y no del tamaño del volumen).

Caso 2: solución activo/activo

N servidores (hasta 32, como máximo) responden a las solicitudes simultáneamente. Los
servidores deben poder responder a todas las consultas y, por tanto, tener acceso al conjunto
de datos que permiten elaborar las respuestas. Su uso más extendido son las granjas de
servidores Web. Todos los servidores tienen una copia del sitio Web y los datos se
almacenan en una base de datos que se hospeda fuera de la granja. La complejidad aparece
en la gestión de la sesión del usuario. El usuario puede tener un carrito de la compra (en un
sitio comercial) y/o estar autentificado en el sitio. Si el servidor que ha respondido a sus
consultas dejara de funcionar, otro servidor debería ser capaz de poder tomar el relevo,
preferentemente sin reenviar al usuario a su página de inicio. La sesión del usuario debe,
por tanto, conservarse de forma externa al servidor, por ejemplo utilizando una base de
datos.

Esto implica que el sitio web tiene que haber previsto este tipo de arquitectura y
almacenar la sesión de forma externa al servidor. Sobre un sitio comercial muy
frecuentado, esta gestión de la sesión tiene un impacto enorme en el consumo de recursos.
Es posible utilizar un clúster de tipo NLB en modo activo/pasivo, aunque este modo de
funcionamiento supone un uso atípico respecto a la filosofía del producto.
He aquí una tabla que resume las principales diferencias entre ambas soluciones:

Ventajas Inconvenientes
Clúster de No se produce ninguna Almacenamiento externo
conmutación sincronización entre los mutualizado.
por error servidores.
Un único servidor debe ser capaz
Es consciente del estado de de gestionar la carga (activo/pasivo
la aplicación (funciona o por grupo de recursos).
no) y de los recursos
(saturados o no).
Clúster NLB Reparto de carga Trabaja únicamente a nivel IP.
(activo/pasivo).
No es consciente del estado de la
Sin almacenamiento aplicación.
mutualizado.

Observe que estas dos tecnologías no pueden estar soportadas en el mismo servidor, véase
el artículo 235305 (Interoperability between MSCS and NLB) de la base de conocimiento
Microsoft.

2. Alta disponibilidad, ¿la panacea de su infraestructura?

Las promesas de la alta disponibilidad sólo podrán materializarse si los equipos y los
procedimientos son coherentes con la necesidad a la que responden estas promesas. Si bien
el coste de la solución es elevado, sólo se verá amortizado si permite, efectivamente, evitar
interrupciones en el servicio. El coste de la solución implica, como mínimo, los elementos
siguientes:

• Inversiones en material (dos servidores, en lugar de uno, por ejemplo).

• Volumen de espacio, consumo eléctrico y de climatización suplementario.
• El coste de "mantenimiento y gestión de infraestructura" (dos licencias de Windows
Server, los agentes de copia de seguridad...).
• Licencias de las aplicaciones, algunos fabricantes obligan a pagar dos veces el
precio de la licencia de la aplicación, incluso cuando se realiza un uso activo/pasivo.
• La supervisión y la copia de seguridad se vuelven tareas más complejas.
• Necesidad de tener un almacenamiento compartido cuando se podría haber
trabajado con discos internos.
• Coste de personal para formarse en esta tecnología.
• Coste de personal para mantener operativa toda la solución.

Estos costes se producen por entorno y deben reportarse en cada entorno impactado
(preproducción, certificación...). El coste de una indisponibilidad debe, por tanto, ser
superior a todos estos costes.
El riesgo consiste en considerar un clúster como un servidor clásico "mejorado". Este
enfoque es, a menudo, fatal en las versiones anteriores de Windows. Bastaba con que un
administrador borrara un recurso compartido de archivos desde el explorador en lugar de
hacerlo desde la consola de administración del clúster para hacer fallar este recurso de
clúster y provocar, por defecto, una conmutación por error del mismo. Microsoft ha
revisado a conciencia la integración de la capa de clúster en el sistema operativo. Este
mismo error en Windows Server 2012 R2 se gestiona, y el sistema elimina de hecho el
recurso de clúster directamente sin provocar una incidencia. Esto provoca una importante
disminución de los incidentes provocados por errores humanos debidos a un mal
conocimiento de las especificaciones de esta solución.

La política de los fabricantes en lo relativo a las licencias evoluciona, aunque sigue

existiendo cierto desfase. Por ejemplo, ya no es necesario adquirir la versión Enterprise de
Microsoft SQL Server para implementar un clúster, desde la versión 2005. En cambio, el
mismo producto sigue requiriendo una licencia Enterprise para formar un clúster NLB de
servidores SSRS (SQL Server Reporting Services).

Un clúster NLB presenta, también, problemas que no deben ignorarse. Se trata de un

administrador de la carga de red de nivel 3 (IP), que no tiene, por tanto, consciencia del
estado de las aplicaciones para las que reparte la carga. Si se trata de aplicaciones web, por
ejemplo, la parada de un IIS en uno de los servidores no lo sacará del clúster. Tendrá una
parte de los usuarios que no podrá acceder al sitio Web, en particular si está habilitada la
afinidad. Esto le obliga a implementar un mecanismo de verificación de la aplicación, para
sacar de la granja a un nodo con error. El único caso gestionado por un clúster NLB es un
problema de nivel 3 o inferior. Por ejemplo, si el servidor pierde el acceso a la red, se
sacará automáticamente de la granja y los usuarios se repartirán sobre los nodos restantes
(convergencia). Una excepción la constituye, por ejemplo, Microsoft Forefront TMG, que
controla el clúster NLB y sale del clúster si encuentra algún problema.

La tecnología NLB proporciona varias soluciones para crear una dirección IP virtual,
aunque todas presentan ventajas e inconvenientes. Algunos fabricantes de red (Cisco,
Enterasys...) requieren una configuración especial para poder funcionar.

Un clúster NLB está formado, a menudo, por dos servidores, con un máximo de 32
servidores. A diferencia del modo activo/pasivo, podemos encontrar una situación en la que
uno de los nodos no pueda gestionar, por sí mismo, toda la carga. La alta disponibilidad no
está, por tanto, asegurada, pues la pérdida de un nodo genera una interrupción del servicio o
una degradación en el rendimiento. Es preciso, por tanto, prestar atención a la carga que
debe absorber la granja para tolerar la pérdida de un nodo. Este fenómeno también puede
darse en un clúster de conmutación por error, si los dos nodos trabajan en modo activo
sobre recursos diferentes (activo/activo en modo cruzado). Microsoft no recomienda
utilizar esta configuración, y propone, en su lugar, utilizar un clúster de tres nodos en este
caso (activo/activo/pasivo). El nodo pasivo se encuentra mutualizado con los otros dos
nodos activos.

Reparto de carga (clúster NLB)

El reparto de carga resulta indispensable cuando no basta con un único servidor para
gestionar toda la carga de la aplicación o mantener unos tiempos de respuesta aceptables. Si
no existen requisitos suplementarios de disponibilidad, se recomienda agregar, en primer
lugar, recursos hardware al primer servidor antes de considerar una solución con varios
servidores.

El reparto de carga no supone una capacidad de carga lineal. Si un servidor es capaz de dar
servicios a 200 usuarios, dos servidores no tienen por qué, necesariamente, ser capaces de
dar servicio a 400 usuarios. Todo va a depender de la naturaleza de la carga y del
comportamiento de las sesiones TCP generadas. La noción de afinidad permite conservar a
un usuario sobre el mismo nodo mientras dure su interacción. De este modo, se disminuyen
los cambios de sesión de usuario sobre los servidores. Para ello, la granja calcula un hash a
partir de la dirección IP del cliente y su destino. Si todos los clientes se presentan con la
misma dirección IP (por ejemplo, cuando se ubican tras un firewall con reglas NAT), serán
redirigidos hacia el mismo servidor, anulando, de este modo, el reparto de carga.

El reparto no se realiza en función de la carga de los servidores. Si algunos usuarios saturan

uno de los nodos, seguirá recibiendo el mismo número de usuarios que los demás nodos. Si
la carga entre los nodos no es del todo uniforme, deberá desarrollar una rutina encargada de
drenar los nodos a partir de cierta carga.

1. Requisitos previos de una solución NLB

Si bien la instalación de la funcionalidad de reparto de carga de red es sencilla, conviene

respetar ciertos requisitos previos para obtener el mejor rendimiento posible. La primera
etapa consiste en instalar las últimas actualizaciones del sistema operativo. En efecto, sería
una pena hacerlo justo una vez puesto en producción el clúster... si bien no debería
producirse ninguna parada del servicio en este caso.

Los servidores que participan del clúster no deben ser controladores de dominio. No
obstante, es necesario que sean miembros del mismo dominio Active Directory y que estén
en la misma subred.

Desde un punto de vista de hardware, el servidor, así como sus componentes, deben
disponer del logotipo Certificado para Windows Server 2012 R2 o, como mínimo,
Certificado para Windows Server 2012 para garantizar su estabilidad (y el soporte por parte
de Microsoft en caso de producirse cualquier problema).

Incluso si basta con una interfaz de red por nodo, se recomienda encarecidamente utilizar,
como mínimo, dos interfaces de red: la primera para el host como máquina única, y la
segunda para el tráfico del clúster. Si una de las interfaces de red se dedica al tráfico del
clúster, ésta debe tener una dirección IP fija. Además, el registro automático DNS de esta
interfaz debe estar deshabilitado, así como NetBIOS sobre TCP/IP. Todas las interfaces de
red que forman parte del clúster, sea cual sea el nodo, deben tener una configuración
idéntica desde un punto de vista de los parámetros (control de flujo, modo dúplex y tipo de
medio). Para terminar, es posible utilizar tarjetas de red configuradas en teaming.
Para realizar la instalación, deben utilizar una cuenta que posea permisos de administrador
local. Necesitará, también, el nombre completo del clúster así como su futura dirección IP.

2. Crear una granja NLB

La creación de una granja NLB es, técnicamente, una tarea rápida. Es preciso, no obstante,
verificar ciertos puntos previamente:

• El modo de operación del clúster:

• Monodifusión (misma dirección MAC en todos los nodos).

• Multidifusión (dirección MAC única por nodo).
• Multidifusión IGMP (dirección MAC única por nodo e inscripción de la
dirección IGMP).

• El modo de filtrado:

• Host múltiple (reparto de carga).

• Host único (activo/pasivo).
• Ninguno (bloquear el tráfico correspondiente a la regla).

• El modo de afinidad (host múltiple únicamente):

• Ninguno (envío sobre un nodo aleatorio).

• Único (mantenerse sobre el mismo nodo por dirección IP cliente).
• Red (mantenerse sobre el mismo nodo por subred completa).

Elección del modo de operación del clúster

La elección del modo de operación debe realizarse de forma coordinada con los
responsables de la red:

• El modo monodifusión asigna la misma dirección MAC sobre todos los nodos del
clúster. Esto va en contra del funcionamiento de los switches, que memorizan las
direcciones MAC por puerto, y para los que es imposible registrar dos veces la
misma dirección MAC. NLB mitiga este punto activando la clave
"MaskSourceMAC". El paquete llega con una dirección MAC de destino
correspondiente a la del clúster, aunque el nodo responde con la suya propia. El
switch no puede, en este caso, asignar la dirección MAC al nodo que responde y
sigue enviando los paquetes a toda la red (inundación). Este comportamiento es "por
diseño". Si el modo es obligatorio (lo era con Microsoft ISA Server, en un
principio), existen varias alternativas. Es posible situar un hub entre los servidores
del clúster y el switch. De esta forma, el switch ve la dirección MAC del clúster
desde un solo puerto (sin "MaskSourceMac"), lo cual evita la inundación. Esto no
forma parte, no obstante, de las "buenas prácticas". El uso de un conmutador de
nivel 3 (router) no es posible, pues todos los nodos comparten la misma dirección IP
 y el router envía los paquetes en función de la dirección IP. Los servidores no
pueden comunicarse entre ellos, puesto que tienen la misma dirección MAC. Los
paquetes se reenvían al servidor sin salir de la propia tarjeta de red.
• El modo multidifusión resuelve el problema de la dirección MAC agregando una
dirección MAC de tipo multidifusión e impidiendo a los equipos de red memorizar
la dirección MAC del clúster. El switch envía los paquetes al conjunto de puertos,
entre los que se encuentran los nodos del clúster. Se produce, todavía, una
inundación del tráfico sobre todos los puertos de la red. Algunos equipos (Cisco, en
particular) requieren convertir parcialmente el switch en un hub por configuración,
indicándole que transfiera sistemáticamente los paquetes para la dirección MAC del
clúster a los puertos de todos los nodos. Es posible limitar este problema aislando
los servidores tras un router, en una VLAN dedicada.
• El modo multidifusión IGMP se comporta como el anterior, aunque los nodos se
registran, también, con una dirección IP IGMP de clase D (de 224.0.0.0 a
239.255.255.255). Esto obliga que los equipos de red soporten la multidifusión
IGMP, aunque permite resolver lo más elegantemente posible los distintos
problemas. Cada nodo tiene su propia dirección MAC, la dirección IP de
multidifusión y sólo los nodos reciben el tráfico de red del clúster.

He aquí algunos artículos que tratan este asunto en función de los fabricantes:

• Cisco:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_e
xample09186a0080a07203.shtml
• Enterasys: http://www.enterasys.com/partners/microsoft/sa-nlb-tb.pdf

Elección del modo de filtrado

El modo de filtrado permite definir el modo de funcionamiento del clúster, desde un punto
de vista de los flujos de red. Permite definir qué paquete de red (puerto y tipo) debe
enrutarse hacia qué nodo(s), o si se bloquea, simplemente.

El modo de filtrado más interesante es host múltiple, que es de tipo activo/activo, lo que
significa que varios nodos trabajan simultáneamente y, por tanto, se reparten la carga de
trabajo y, por tanto, los flujos de red. El modo host único es de tipo activo/pasivo, con el
nodo que tiene menor ID activo, donde sólo el nodo activo recibe el flujo de red. El modo
de filtrado Ninguno permite bloquear el tráfico sobre ciertos puertos, en particular para
proteger los nodos.

Elección del modo de afinidad

Utilizando un modo de filtrado de host múltiple, existen tres modos de afinidad posibles:

• Ninguno: con cada conexión TCP de un mismo cliente, se le redirigirá hacia el

nodo que tenga menos clientes. Este modo asegura el mejor reparto posible,
especialmente cuando no hay datos de cliente que deban mantenerse (carrito de la
compra, sesión...).
 • Único: permite mantener a un cliente (según su dirección IP) sobre el mismo nodo
mientras la topología de la granja no se vea modificada (se agregue/elimine un
nodo). Cada cliente debe tener una dirección IP única para tener un reparto eficaz
(sin NAT, proxy...).
• Red: se comporta como el filtrado anterior, aunque en vez de utilizar directamente
la dirección IP del cliente, calcula la dirección de la red. Si, por ejemplo, un cliente
se conecta con la dirección IP 192.168.1.1, NLB la transformará en 192.168.1.0.
Todos los clientes que pertenezcan a esta red de clase C bascularán sobre el mismo
nodo. Este tipo de filtrado permite mantener a un conjunto de clientes que
provengan de una misma red sobre un mismo nodo.

De forma complementaria, en Windows Server 2012 R2 (desde Windows Server 2008 R2

para ser más exactos), la afinidad única puede sobrevivir a un cambio en la topología
(convergencia), a diferencia que con las versiones anteriores, donde el cliente era redirigido
hacia otro nodo. Si un cliente X se conecta sobre un nodo A y se agrega o elimina un nodo
del clúster, el clúster mantendrá la afinidad durante X minutos. Este retardo de expiración,
expresado en minutos, comienza desde que el cliente está inactivo. El valor por defecto es:
no activo (0 sombreado). Esto significa que la afinidad expira desde que el cliente se
desconecta. Si fuera necesario, el clúster puede disponer de varias direcciones IP virtuales.
Esto es necesario, en particular, si hospeda varios sitios web con certificados SSL. A menos
que tenga un certificado de tipo wildcard (*.MiEmpresa.Priv), cada sitio deberá tener una
dirección IP dedicada para las conexiones SSL. A diferencia del protocolo HTTP, que
autoriza los host virtuales, el protocolo SSL comienza negociando la seguridad, en primer
lugar, y realizando una validación de la URL solicitada por el cliente.

3. Configurar la granja

La implementación consiste en:

• Instalar la funcionalidad "reparto de carga de red".

• Crear la granja con un nombre y, al menos, una dirección IP sobre, al menos, un
nodo.
• Configurar las reglas para determinar el tráfico a repartir.

La instalación puede hacerse mediante el Administrador del servidor aunque, también, a

través de PowerShell. Windows Server 2012 R2 se instala con la versión 4 de PowerShell,
que permite instalar esta funcionalidad sobre varios nodos mediante un único comando:

Invoke-Command -ComputerName nodo1,nodo2 -Command

{install-WindowsFeature NLB,RSAT-NLB}
La granja NLB puede crearse de dos formas:

• Con la interfaz clásica NLB.

• Con PowerShell.

Configuración de la granja con la interfaz gráfica:

Haga clic en Inicio - Herramientas de administración - Administrador de equilibrio de

carga de red.

A continuación, haga clic en Clúster y Nuevo.

Seleccione un primer nodo para configurarlo, así como una interfaz (la que recibirá el flujo
de red proveniente de los clientes y tenga como destino la dirección IP del clúster). Defina
su prioridad, su interfaz de administración y su estado por defecto..

Agregue, a continuación, al menos una dirección IP utilizada por la granja.

Determine la dirección IP principal del clúster así como el nombre del clúster.

La siguiente etapa es crítica, y consiste en seleccionar el modo de operación del

clúster (monodifusión, multidifusión con o sin IGMP). Por defecto, todos los puertos están
configurados con reparto de carga, con una afinidad de tipo única.

Llegados a este punto, se crea la granja con un único servidor como miembro. Es posible
agregar un segundo nodo mediante el menú Clúster - Agregar host:
La interfaz de gestión de las reglas permite seleccionar la dirección IP del clúster donde se
aplica, un puerto, o un rango de puertos, su naturaleza (TCP, UDP) y el modo de filtrado:

Configuración de la granja con PowerShell:

#Creación del clúster sobre el primer nodo

New-NlbCluster -InterfaceName NLB -ClusterName cluster1.MiEmpresa.Priv
-ClusterPrimaryIP
172.16.0.25 -SubnetMask 255.255.0.0

#Agregar un segundo nodo tras la creación del primer nodo

Add-NlbClusterNode -Interface NLB -NewNodeName nodo2.MiEmpresa.Priv
-NewNodeInterface NLB

#O Agregar un segundo nodo tras el segundo nodo

Get-NlbCluster -HomeName cluster1.MiEmpresa.Priv | Add-NlbClusterNode
-NewNodeName nodo2.MiEmpresa.Priv -NewNodeInterface NLB

Para obtener la lista completa de comandos PowerShell que permiten administrar un clúster
NLB (35 en total), ejecute uno de los siguientes comandos PowerShell:

Get-Command *-NlbCluster*
#O
Get-Command -Module NetworkLoadBalancingClusters

4. Ejemplo: granja Web IIS

Una granja de servidores Web supone el uso típico de una solución NLB. IIS 8.5 gestiona
la noción de configuración compartida, que facilita la gestión de la granja centralizando la
configuración IIS de todos los servidores Web sobre un almacén compartido de archivos
UNC. El siguiente artículo de la TechNet describe su implementación:
http://technet.microsoft.com/en-us/library/jj635853.aspx

Las etapas son las siguientes:

• Instalar el rol Servidor Web (Web-Server).

• Crear, al menos, un clúster NLB con dos nodos.
• Modificar la regla por defecto, para equilibrar únicamente los puertos TCP 80
(HTTP) y 443 (HTTPS).

Llegados a este punto, tendrá una granja formada por dos servidores Web con una afinidad
única. Ya sabe que NLB no es consciente del estado de la aplicación para la que realiza el
reparto de carga. En cambio, puede modificar el comportamiento de IIS para que tenga en
cuenta el clúster NLB y modifique su comportamiento en caso de ocurrir algún problema.
Por defecto, IIS reenvía un código HTTP 503 en caso de fallo de algún pool de
aplicaciones. En el caso de una granja de servidores, es muy probable que sólo este servidor
tenga el problema. Indicando al pool de aplicaciones que realice una respuesta a nivel TCP,
va a cerrar la conexión del cliente, que se verá redirigido hacia otro nodo de la granja.

Par modificar este comportamiento, vaya a la configuración avanzada del pool de la

aplicación:
5. Actualización de una granja NLB

La actualización de una granja NLB existente es más sencilla que la creación de una granja.
Los principales problemas son, generalmente, la compatibilidad de las aplicaciones y los
drivers, como con cualquier actualización sobre cualquier servidor de una infraestructura.

Una granja NLB bajo Windows Server 2012 R2 puede trabajar con nodos en alguna versión
anterior de Windows Server (Windows Server 2003 R2, como mínimo), y la actualización
necesaria es sencilla y no requiere crear ninguna granja nueva.

He aquí los posibles métodos de actualización:

 • Parada total del clúster: la parada total del clúster permite realizar la actualización
en todos los nodos al mismo tiempo. Esto supone una parada total de los servicios
proporcionados por el clúster.
• Actualización por turnos (rolling update): se detiene uno de los nodos y se actualiza
a Windows Server 2012 R2. A continuación, se realiza la misma operación con otro
nodo del clúster.
• Agregar un nodo nuevo (nuevo hardware): se trata de una opción común puesto que,
por lo general, se aprovecha para renovar el hardware. Se agrega, simplemente, un
nodo nuevo que ya funciona con Windows Server 2012 R2. A continuación, se
elimina el nodo de la generación anterior.

Una vez realizada la actualización, conviene probar el conjunto de nodos así como la
tolerancia a fallos.

Clúster de conmutación por error

La tecnología de clúster de conmutación por error tiene un enfoque distinto al de NLB. Su
objetivo consiste en mantener los recursos en línea de forma permanente e ininterrumpida.
Cada recurso se instancia sobre un único servidor a la vez, aunque varios servidores pueden
estar activos al mismo tiempo sobre recursos diferentes. Para garantizar un buen
funcionamiento, la capa de clúster verifica una serie de puntos:

• ¿Funcionan la dirección IP y el nombre virtual?

• ¿Funciona el acceso al almacenamiento?
• ¿El nodo es capaz de comunicarse con los demás nodos (no está aislado)?
• ¿Los servicios que hay que mantener activos son funcionales?

Si se detecta algún incidente sobre alguno de los puntos anteriores, el clúster bascula el
conjunto de recursos necesarios para el funcionamiento del (de los) servicio(s) sobre otro
nodo.

Como mínimo, un clúster posee al menos un grupo (el ”grupo clúster”) que contiene:

• Una dirección IP virtual.

• Un nombre virtual.
• Potencialmente, un volumen que forma parte de un quórum, o un disco testigo.

En caso de producirse algún problema en la red, el clúster debe determinar qué nodos
funcionan correctamente y qué nodos deben retirarse del clúster (y los recursos que los
hospedan deben conmutar). Los nodos que sean mayoritarios quedarán en línea.

Existen cuatro modos de funcionamiento para determinar este comportamiento:

• Mayoría de nodo: el nodo que se comunica con la mayor parte de nodos resulta
ganador. Este modo funciona únicamente con un número impar de nodos.
 • Mayoría de disco y nodo: cada nodo tiene su propio voto, así como el quórum de
disco. El nodo con más votos gana. Windows Server 2012 R2 aporta una
modificación en el cálculo de votos (Dynamic withness) para obtener un resultado
impar de votos en cualquier situación. Si el resultado del número de votantes (los
nodos, por tanto), es impar, entonces el voto del quórum se toma en consideración.
Puede conocer el estado del voto del quórum mediante el cmdlet PowerShell: (Get-
Cluster). WithnessDynamicWeight. Si el valor es igual a "1", entonces el voto del
quórum se considera, si vale "0", el voto del quórum no se tiene en cuenta. Esta
configuración no se recomienda para una configuración multisitio (almacenamiento
replicado) y requiere que todos los nodos del clúster estén instalados con Windows
Server 2012 R2.
• Mayoría de recurso compartido de archivos y nodo: idéntico al anterior, aunque
utiliza un recurso compartido de archivos externo al clúster en lugar del disco
quórum. Esta es la configuración que utiliza Microsoft Exchange 2007 en su
configuración en clúster CCR (Cluster Continuous Replication) y por Microsoft
Exchange 2010 y 2013 para DAG (Database Availability Groups).
• Sin mayoría: sólo disco: solamente un nodo puede poseer el volumen en un
momento determinado, y recupera el conjunto de los recursos. Esta solución se
corresponde con el funcionamiento de un clúster Windows Server 2000/2003. Ya no
es el modo recomendado, sobretodo en el caso de clúster multisitio (con
almacenamiento replicado). No tolera la pérdida del quórum de disco
(convirtiéndose en un punto de fallo único).

Cada recurso hospedado en un clúster (instancia SQL, compartición de archivos,

Exchange...) dispone de uno o varios grupos que contienen un conjunto de recursos
dedicados a su funcionamiento.

Para poder definir un servicio o una aplicación, hay que escoger entre las siguientes
opciones:

• Aplicación genérica
• Servicio genérico
• DTC (Distributed Transaction Coordinator)
• Ordenador virtual (máquina virtual Hyper-V)
• Message Queuing
• Servidor de espacios de nombres DFS
• Servidor de archivos
• Servidor DHCP
• Servidor de destino iSCSI
• Servidor iSNS (Internet Server Name Service)
• Servidor WINS
• Otro tipo de servidor
• Servicio de agente de conexión para los servicios de Escritorio remoto
• Un script genérico. Éste le permite utilizar un script para realizar verificaciones
específicas para determinar el estado del recurso y decidir o no conmutar el clúster.

Una vez creado el grupo, pueden agregarse los siguientes recursos virtuales:
 • Aplicación genérica
• Punto de acceso de cliente (con un nombre y una dirección IP virtual)
• Script genérico
• Servicio genérico
• Dirección de túnel de IPv6
• Coordinador de transacciones distribuidas
• Recurso compartido de NFS
• Servidor DHCP, WINS
• Carpeta compartida

En función del tipo de recurso, algunos parámetros estarán, o no, disponibles. Los
parámetros siguientes son comunes a todos los recursos:

• Dependencias: este parámetro determina qué otros recursos deben estar operativos
para que este recurso funcione.

Este parámetro puede, a su vez, determinar en qué orden deben iniciarse los
recursos. Si alguna dependencia fallara, los recursos que dependan de ella se
detendrán.

Es posible utilizar los operadores lógicos "Y" y "O". El operador "O" permite
flexibilizar las dependencias, en la medida en que dos recursos pueden cumplir un
mismo rol. Es el caso, en particular, de un clúster que tenga nodos sobre dos
subredes diferentes. Existen dos recursos de tipo ”dirección IP” (una por cada
subred), aunque solamente habrá operativo uno de ellos, en un instante T. El
operador lógico "O" permite satisfacer sólo una de ambas dependencias.

• Afectar al grupo: este parámetro está activo por defecto. Determina, en caso de que
falle algún recurso del grupo, si todo el grupo de recursos debe conmutar sobre otro
nodo. Si este recurso no es imprescindible para el funcionamiento del grupo
completo, puede considerarse el no conmutar y que el grupo no se vea afectado. Las
soluciones de copia de seguridad crean, por lo general, un recurso en el clúster. Si se
produce algún problema (crash o una acción incorrecta en la solución de seguridad),
todo el grupo conmutará. Una solución de supervisión adecuada permite alertar
sobre el fallo de este recurso y dejar el tiempo suficiente para reparar el problema
antes de que empiece la copia de seguridad. Evitará, así, perturbar la disponibilidad
del clúster de forma imprevista y no indispensable.
• Intervalo de comprobación: el intervalo entre dos verificaciones sobre la salud del
recurso. Puede ser necesario aumentar el tiempo por defecto en el caso de servidores
con mucha carga de trabajo.

En las versiones anteriores de Windows Server, era preciso tener una red privada,
dedicada a la comunicación inter-nodo, llamada "heartbeat". Windows Server 2012 R2
ofrece una mayor flexibilidad y no impone esta restricción. El motivo es no tener ningún
punto de fallo único y, por tanto, disponer de, al menos, dos caminos de red entre los
nodos. Si utiliza iSCSI, las tarjetas de red deben estar dedicadas y la comunicación inter-
nodo bloqueada. Si utiliza una red dedicada a la copia de seguridad, es, también, una buena
idea prohibir su uso al clúster. El bloqueo se gestiona desde las propiedades de red, en la
consola Administrador de clúster de conmutación por error.

Es bastante común que una aplicación almacene ciertos parámetros en una base de registro.
Si fuera necesario, el clúster puede replicar una arborescencia de la base de registro, situada
en HKEY_LOCAL_MACHINE. Esta configuración puede estar ligada a un servicio de
Windows o a una aplicación.

1. Validación de su clúster

En las versiones anteriores de Windows Server, el hardware debía estar certificado para
poder funcionar con el servicio de clúster de conmutación por error de Microsoft. En caso
contrario, Microsoft no garantizaba el soporte. Desde Windows Server 2008, este proceso
se ha simplificado. Para poder gozar de una configuración soportada por Microsoft, basta
con que:

• El hardware incluya el logotipo "certificado para Windows Server 2012 R2"

(certificado para Windows Server 2012, como mínimo).
• La instalación se valide mediante el asistente Validación de una configuración.

El asistente realiza una serie de comprobaciones sobre los siguientes dominios:

• Configuración del clúster

• Configuración del sistema
• Inventario
• Red
• Almacenamiento

Existen dos excepciones relativas a este asistente de validación. Las configuraciones

siguientes no pasan la prueba relativa al almacenamiento:

• Exchange en modo CCR (Cluster Continuous Replication). El clúster no dispone de

un almacenamiento compartido, puesto que lo replica CCR. Esta comprobación no
puede llevarse a cabo (http://technet.microsoft.com/en-us/library/bb676379.aspx).
• Los clústeres que utilizan un almacenamiento replicado. Ambos nodos tienen
acceso al conjunto de volúmenes incluido el quórum
(http://technet.microsoft.com/en-
us/library/cc732035(WS.10).aspx#BKMK_multi_site).

La prueba acerca del almacenamiento es la única que podría interrumpir la disponibilidad.

Una vez tenga el clúster en producción, puede utilizar una LUN, de forma temporal, para
superar las pruebas relativas al almacenamiento, en lugar del set de pruebas completo.

Este asistente tiene como objetivo verificar un clúster que se pone en producción, aunque
también cada cambio significativo realizado sobre el mismo, como:
 • La actualización del firmware o de los controladores.
• La agregación o eliminación de un nodo en el clúster.
• El cambio de hardware de almacenamiento.

Encontrará referencias a las pruebas a realizar en función de las modificaciones realizadas

sobre el clúster en la siguiente dirección: http://technet.microsoft.com/en-
us/library/cc732035(WS.10).aspx#BKMK_validation_scenarios

2. Implementación del clúster

La implementación del clúster incluye las siguientes etapas:

• Configurar las interfaces de red sobre los futuros nodos del clúster.
• Configurar el almacenamiento para el clúster.
• Instalar la funcionalidad de clúster de conmutación por error.
• Configurar el clúster:

• Interfaz de red
• Determinar la mayoría (quórum, recurso compartido testigo...)

• En función del objetivo del clúster, instale el rol de alta disponibilidad sobre todos
los nodos (servidor de archivos, servidor WINS...).
• Cree la aplicación en el clúster.
• Bascule sobre cada uno de los nodos para validar el correcto funcionamiento de los
mismos.
• Ejecute, de nuevo, el asistente de validación del clúster.

a. Configurar la red para el clúster

La primera etapa consiste en configurar las interfaces de red de los nodos de su futuro
clúster. Recuerde que se recomienda encarecidamente utilizar varias tarjetas de red, cada
una configurada sobre una subred o una VLAN diferentes, y dedicarles un rol bien
definido. En nuestro ejemplo, utilizaremos cuatro tarjetas de red por nodo, he aquí su
configuración:

• LAN (172.16.0.x/16): dedicada a la comunicación entre los clientes y los nodos del
clúster.
• Clúster (10.0.1.x/24): dedicado a las comunicaciones internas del clúster.
• Almacenamiento 1 (10.0.2.x/24): primera conexión al espacio SAN iSCSI.
• Almacenamiento 2 (10.0.3.x/24): segunda conexión al espacio SAN iSCSI.

Todas las interfaces deben estar direccionadas convenientemente. Esta conectividad con la
red local (LAN), donde se encuentran los clientes, debe estar direccionada correctamente
(dirección IP y DNS). Para las demás interfaces, y salvo por algún motivo en especial,
debería dejar el mínimo imprescindible (dirección IP, deshabilitar el registro DNS y de
NetBIOS).
b. Configurar el almacenamiento para el clúster

La segunda etapa consiste en conectar sus nodos a un espacio de direccionamiento, iSCSI

en nuestro ejemplo, teniendo en cuenta la duplicidad de equipos de red para la tolerancia a
fallos. Para poder gestionar varias rutas de red para alcanzar el almacenamiento, será
preciso instalar la funcionalidad MPIO (MultiPath I/O).

La configuración de los destinos iSCSI se realiza de la siguiente manera:

Abra el iniciador iSCSI desde las herramientas administrativas.

Vaya a la pestaña Detección, en la sección Portales de destino, haga clic en el botón

Detectar portal..., escriba la dirección IP del espacio de almacenamiento y haga clic en
Aceptar.

Vaya a la pestaña Destinos, seleccione el destino correspondiente a la LUN para el quórum

y, a continuación, haga clic en el botón Conectar.

En la ventana Iniciar sesión en el destino, marque la opción Habilitar múltiples rutas y,

a continuación, haga clic en Opciones avanzadas....

En la sección Conectarse utilizando de la pantalla que muestra la configuración avanzada,

realice los siguientes cambios:

• Adaptador local: iniciador Microsoft iSCSI.

• IP del iniciador: dirección IP del nodo de la primera red de almacenamiento.
• IP del portal de destino: dirección IP del espacio de almacenamiento en la primera
red de almacenamiento.
A continuación, haga clic en Aceptar dos veces.

Para gestionar rutas múltiples, deberá repetir las etapas 3 a 5 utilizando las direcciones IP
de la segunda red de almacenamiento en la etapa 5.

Una vez configurado el iniciador iSCSI, debe instalarse la funcionalidad MPIO. Puede
hacerlo a través del Administrador del servidor. A continuación, para configurar la
funcionalidad MPIO:

Abra la consola MPIO desde las herramientas administrativas.

En la pestaña Detectar múltiples rutas, marque la opción Agregar compatibilidad con

dispositivos iSCSI (si estuviera deshabilitada, significa que no ha conectado el destino
iSCSI) y haga clic en el botón Agregar (vea la siguiente captura de pantalla).

Para terminar, valide el reinicio haciendo clic en el botón Sí.

c. Configurar el quórum para el clúster

En este ejemplo, vamos a configurar el clúster en modo mayoría de disco y nodo, lo que
implica que el quórum se define en un almacenamiento de red central, un espacio iSCSI,
FCo FCoE. Todos los nodos de su futuro clúster deben tener acceso bien al quórum, o bien
a la propia LUN. Ahora que ha realizado la conexión con el almacenamiento, vamos a
preparar el volumen que queremos utilizar para el quórum del clúster.

Para realizar esta preparación, utilizaremos la LUN que ha conectado en la sección anterior.
Configure el almacenamiento para el clúster y realice esta tarea únicamente para el primer
nodo. Esta preparación puede realizarse de varias formas:

• Desde el Administrador del servidor.

• Desde la consola Administrador de discos (diskmgmt.msc).
• Mediante el comando DISKPART.EXE.
• Utilizando los cmdlets PowerShell.

Utilizaremos la consola Administrador de discos:

Abra la consola Administrador de discos.

Haga clic, con el botón derecho, sobre el disco destinado a ser el volumen del quórum, que
normalmente aparecerá como disco desconocido, y seleccione En línea.

Haga, de nuevo, clic con el botón derecho sobre el disco del quórum, y seleccione
Inicializar el disco.

En la ventana Inicializar el disco, deje las opciones por defecto y valide haciendo clic en
el botón Aceptar.

En la zona no particionada del disco de quórum, haga clic con el botón derecho y
seleccione Nuevo volumen simple....

Mediante el asistente de Creación de un volumen simple, cree un volumen utilizando la

totalidad del espacio disponible, asígnele la letra Q (se trata de una vieja convención de
nomenclatura para el Quórum), asígnele el nombre quórum y realice un formato rápido en
NTFS.

d. Instalación del clúster

La instalación de la funcionalidad de clúster puede realizarse de varias formas:

• Desde el Administrador del servidor.

• Desde PowerShell:

Invoke-Command -ComputerName nodo3,nodo4 -Command {Install-Windows

Features -Name Failover-Clustering -IncludeManagementTools}
La configuración puede hacerse de distintas formas, aunque le conviene utilizar una cuenta
con permisos de Administrador de dominio para realizar la creación de la cuenta de equipo
que representa el clúster:

• La interfaz gráfica: Administrador de clúster de conmutación por error.

• Desde PowerShell.

Observe que la herramienta por línea de comandos cluster.exe ya no se encuentra

soportada en Windows Server 2012 R2.

En este libro, vamos a explicar el primer y el último método para realizar la configuración
de un clúster.

Configuración mediante la interfaz gráfica:

Abra el Administrador de clústeres de conmutación por error.

Haga clic en Validar configuración en el panel Acciones.

El mensaje de bienvenida le recuerda tres aspectos muy importantes:

 • Incluso si su instalación pasa la validación, es preciso que todo el hardware incluya
una mención "para Windows Server 2012 R2".
• Es necesario ser, al menos, administrador local de cada uno de los nodos.
• La validación no puede interrumpirse tanto si realiza todas las pruebas (que
incluyen pruebas sobre el almacenamiento) como si realiza una prueba
personalizada seleccionando el almacenamiento, lo que significa una interrupción
del servicio para el almacenamiento del clúster de algunos segundos durante la
validación.

Haga clic en Siguiente.

Agregue todos los nodos que van a formar parte del clúster.

Seleccione la opción Ejecutar todas las pruebas salvo si se trata de una excepción, de
tipo clúster Exchange CCR o clúster multisitio. Haga clic en Siguiente.
El asistente muestra un resumen de las opciones anteriores. Haga clic en Siguiente.
 Una vez realizadas las pruebas, se muestran los resultados. La primera frase del cuadro de
diálogo permite conocer inmediatamente si el conjunto de pruebas es concluyente. Si se han
detectado problemas, puede consultarlos mediante el informe.

Su instalación se encuentra, ahora, certificada para funcionar en modo clúster de

conmutación por error. La siguiente etapa consiste en crear el clúster.

Haga clic en Crear el clúster desde el panel Acciones:

Haga clic en Siguiente.

Agregue los nodos que van a formar parte del clúster. Haga clic en Siguiente.
 Indique un nombre (virtual) y una dirección IP para el clúster. Ambos recursos estarán
dedicados al funcionamiento del clúster y no deberían utilizarse para ninguna otra tarea.
Haga clic en Siguiente.
 El asistente le muestra un resumen de la configuración que se aplicará antes de hacerlo
realmente. Haga clic en Siguiente y, a continuación, haga clic en Finalizar.

Habríamos podido llegar al mismo resultado con los siguientes comandos PowerShell:

Test-Cluster -Node nodo3,nodo4

New-Cluster -Name cluster02 -Node nodo3,nodp4 -StaticAddress
172.16.0.28

Puede recuperar la lista de comandos de gestión del clúster con: get-command -module
FailoverClusters.

Por lo general, si se cumplen todos estos requisitos previos, su clúster debería estar, de
manera automática, configurado completamente por parte del asistente de instalación del
clúster. En nuestro ejemplo, el clúster está configurado en modo Mayoría de disco y nodo
utilizando para el quórum la LUN conectada en la sección Configurar el almacenamiento
para el clúster. Si lo requisitos previos no se cumplen, su clúster se configurará en modo
Mayoría de nodo.

Por defecto, la creación de un clúster de conmutación por error a partir de la interfaz

gráfica, o mediante el cmdlet PowerShell anterior, implica la creación de la cuenta de
equipo para el clúster en Active Directory. Windows Server 2012 R2 aporta una nueva
funcionalidad, Directory-Detached Cluster, que permite crear un clúster de conmutación
por error sin crear una cuenta de equipo en Active Directory, aunque los nodos formen
parte del dominio de Active Directory.

El despliegue de este tipo de clúster se realiza, exclusivamente, por línea de comandos

PowerShell, agregando el parámetro AdministrativeAccessPoint :

Test-Cluster -Node nodo5,nodo6

New-Cluster -Name cluster03 -Node nodo5,nodo6 -StaticAdress
172.16.0.29 -NoStorage -AdministrativeAccessPoint DNS

Conviene verificar la configuración de las redes del clúster para una mejor comunicación
entre los nodos, pero también para el almacenamiento de red y el acceso por parte de los
clientes. Como se precisaba antes en este mismo capítulo, nuestro ejemplo utiliza cuatro
tarjetas de red. He aquí la configuración de las redes del clúster (observe que hemos
renombrado las redes para una mejor comprensión):
Una vez haya verificado y corregido, si fuera necesario, los parámetros de su clúster, y
antes de agregar los servicios, se recomienda validar el clúster. Para realizar esta tarea, haga
clic en el enlace Validar el clúster... que se encuentra en el panel Acciones y siga las
instrucciones del asistente de validación del clúster.

Llegados a este punto, tenemos un clúster con mayoría de disco y nodo operacional, aunque
todavía no hospeda ningún servicio.

e. Implementar un clúster de archivos

En una configuración en clúster, el servidor de archivos requiere un almacenamiento

compartido sobre un espacio de almacenamiento de red. Deberá, ahora, agregar una
conexión a una nueva LUN sobre los nodos antes de agregar el servicio de Servidor de
archivos a su clúster. Revise la sección Configurar el almacenamiento para el clúster en
este capítulo.

Una vez conectada la LUN y creado el volumen (letra E:\ en nuestro ejemplo), debemos
agregar este volumen a los discos de nuestro clúster.
En el Administrador del clúster de conmutación por error, vaya a la sección
Almacenamiento y, a continuación, Discos. En el panel Acciones haga clic en Agregar un
disco. Seleccione el disco que desea agregar y haga clic en Aceptar.

Ahora que el almacenamiento está configurado, es posible agregar el rol Servidor de

archivos al clúster. Un pequeño matiz: para configurar un rol en un clúster, debe
estar instalado el rol Windows equivalente.

Utilice la interfaz gráfica para agregar un grupo servidor de archivos al clúster:

Haga clic en Siguiente.
 En la pantalla Tipo de servidor de archivos, puede escoger entre un servidor de archivos
para uso general o con escalabilidad horizontal para datos de aplicación. Deje marcada la
opción Servidor de archivos para uso general y haga clic en Siguiente.
Indique el nombre virtual del clúster para este grupo, así como una dirección IP virtual.

Seleccione el o los volúmenes que hospedan los datos.

El asistente muestra el resumen de la configuración que se va a aplicar.

Haga clic en Siguiente.

El asistente muestra el informe de creación.

El grupo que acaba de crear aparece en la arborescencia Roles:

Sólo queda probar el clúster reiniciando los nodos, cada uno en su turno y, a continuación,
crear los recursos compartidos.

Sepa que este procedimiento es idéntico para todos los roles de Windows que quiera
configurar en clúster.

f. Casos particulares

Caso de SQL Server

En la instalación en clúster de una aplicación Microsoft SQL Server, debe tener en cuenta:

• Instalar el clúster.
• Instalar MSDTC como aplicación clúster (si fuera necesario).
• Instalar Microsoft Framework 3.5 SP1.
• Instalar Windows Installer 4.5.
• Crear un grupo de clúster vacío (uno por instancia a instalar).
• Asignar volúmenes de almacenamiento al grupo.
• Ejecutar el programa de instalación de SQL Server (como mínimo, SQL Server
2008 R2 SP1 o SQL Server 2012).
De preferencia a las versiones que ya incorporen los Service Packs mencionados, en
particular los que permitan evitar los problemas que se describen en los artículos 955725 y
973993 de la base de conocimiento.

Caso de Exchange

Microsoft Exchange Server 2010 está, oficialmente, soportado a partir del Service Pack 3.
Exchange Server 2013 también está soportado.

Caso de Hyper-V

Una de las principales novedades asociadas a Hyper-V y a los clústeres es la relativa al

almacenamiento de máquinas virtuales. El CSV (Cluster Shared Volume), que se incluye
con Windows Server 2008 R2, hace que no sea obligatorio disponer de un volumen por
máquina virtual (VM). Es posible hospedar un conjunto de máquinas virtuales sobre el
mismo volumen. Uno de los nodos realiza el rol de coordinador, siendo el único que puede
crear archivos. Es él el encargado de gestionar el acceso de escritura a los archivos por
parte de los servidores, para que no haya dos servidores que modifiquen el mismo archivo.
Las ventajas son numerosas:

• El espacio libre es común a todas las VM. Este espacio pueden utilizarlo todas las
VM cuyo almacenamiento sea de tipo extensible, y también es posible agregar
nuevas VM. La eliminación de una VM hace que su espacio quede disponible,
inmediatamente, para las demás VM.
• El número de volúmenes es considerablemente bajo. Habrá menos intervenciones
sobre el almacenamiento central y, por tanto, menos riesgos derivados.
• El tamaño del volumen puede ser importante, y el tiempo de análisis para realizar
un chkdsk está vinculado con el número de archivos y no con el tamaño.
• Con Windows Server 2012 R2, CSV soporta funcionalidades avanzadas de
administración de archivos tales como la deduplicación de datos y ReFS (Resilient
File System), de las que se habla en el capítulo El ciclo de vida de su
infraestructura.

El modo CSV está soportado y se reserva, exclusivamente, para almacenar máquinas

virtuales Hyper-V. Jamás debería utilizarse para almacenar otro tipo de objetos.

Es posible agregar volúmenes CSV desde el Administrador de clúster de conmutación

por error o mediante comandos PowerShell:

$cluster = Get-Cluster cluster01

$cluster.EnableSharedVolume="Enabled"

Windows Server 2012 R2 aporta, a su vez, los discos virtuales VHDX compartidos (Shared
VHDX) que permiten el acceso al mismo disco virtual, en formato *.vhdx, a varios equipos
virtuales. Esto permite, por ejemplo, crear clústers compuestos por nodos formados por
máquinas virtuales. Se aborda la implementación de un Shared VHDX en el capítulo
Consolidar sus servidores.
3. Migración de Windows Server 2008 a 2012 R2

Si bien este libro está orientado a Windows Server 2012, existen ciertas consideraciones
que debemos tener en cuenta si queremos migrar un clúster desde una edición anterior a
Windows Server 2012 R2:

• Windows Server 2012 R2 existe, únicamente, en versión de 64 bits. Esto obliga a

que tanto el hardware como todas las aplicaciones del mismo deban ejecutarse sobre
64 bits o, al menos, mediante la emulación de 32 bits WoW64 (Windows On
Windows).
• La funcionalidad Compartir subdirectorios ya no está disponible desde Windows
Server 2012. Será preciso crear cada recurso compartido. Esto se debe a una
limitación técnica de 900 recursos compartidos. Como ya no existe este problema,
esta funcionalidad se ha suprimido.
• DFS y FRS ya no están soportados en Windows Server 2012 R2 (salvo para
controladores de dominio). Debería migrar a DFSR, preferentemente. Esto implica
que los demás nodos DFS estén configurados, como mínimo, en Windows Server
2003 R2.
• ¿Utilice nombres virtuales y direcciones IP diferentes a las del grupo de clúster para
sus recursos? Si no fuera el caso, la migración implicará una interrupción mayor del
servicio, pues ambos clústeres (el viejo y el nuevo) deben cohabitar durante la
migración.

Existen dos enfoques para abordar la migración:

• Conservar el mismo hardware.

• Migrar el clúster a un nuevo clúster físico.

El primer enfoque consiste en:

• Sacar un nodo del clúster (véase el artículo 935197 de la base de conocimiento de

Microsoft).
• Actualizarlo a Windows Server 2012 R2 o instalar de nuevo todo el sistema
operativo.
• Crear un nuevo clúster sobre este servidor.
• Utilizar el asistente para migrar un clúster.
• Poner en línea los recursos migrados.
• Sacar el nodo 2008 del anterior clúster y actualizarlo.

El segundo enfoque se utiliza muy a menudo, puesto que el cambio de sistema operativo
supone, a menudo, un cambio de generación de hardware. El plan es muy similar, siempre
que no se degrade (en número de nodos) durante la migración:

• Instalar un clúster Windows Server 2012 R2 sobre, al menos, uno de los nodos
(nuevo clúster).
• Utilizar el asistente para migrar un clúster.
 • Decidir si se utiliza el mismo almacenamiento o no.
• Poner en línea los recursos migrados.
• Eliminar el clúster anterior.

4. Configurar un clúster de conmutación por error en modo multisitio

Si ocurre cualquier problema con el DRP (Plan de Recuperación ante Desastres) o,

especialmente, del PSI (Plan de Seguridad Informática) llevados a un situación extrema,
algunas empresas implementan un entorno informático idéntico al entorno de producción
sobre un sitio auxiliar (locales separados geográficamente). El objetivo es que, si el sitio
principal dejara de estar disponible (debido a un fuego, a una inundación...), los usuarios no
tengan más que acudir al sitio secundario para poder seguir trabajando.

Para ello, es preciso, evidentemente, que los usuarios sean capaces de encontrar los mismos
datos y los mismos servicios que en el sitio principal, de la manera lo más transparente
posible. En lo relativo a los propios datos, tiene varias posibilidades para replicarlos entre
los sitios (DFS-R por ejemplo). Pero, ¿qué ocurre con un clúster?

La implementación de un clúster de conmutación por error en un multisitio supone que los

sitios estén conectados mediante una conexión fiable y rápida, e impone, a su vez, una
replicación de datos del clúster. Esta replicación puede realizarse de distintas formas:

• A nivel de hardware: a día de hoy, la mayoría de espacios de almacenamiento

profesionales permiten replicarse entre sí. Con algunos de ellos, es posible incluso
encriptar y comprimir los datos replicados. Con este tipo de replicación, el espacio
de almacenamiento replica los bloques de datos sea cual sea el tipo o el sistema de
archivos.
• A nivel lógico o sistema de archivos: la replicación a nivel de aplicación se basa, a
menudo, en el servicio DFS-R de Microsoft, si bien existen otras soluciones de
replicación. Se trata de una replicación basada en el sistema de archivos.
• A nivel de aplicación: en este tipo de replicación, es la propia aplicación la
encargada de replicar sus propios datos. Podemos citar a Microsoft Exchange 2007
como ejemplo, con una replicación de tipo CCR.

A esto le acompañan dos modos de funcionamiento:

• Una replicación síncrona: en este modo, cuando un dato se encuentra en el

almacenamiento del sitio principal, la acción se considera como terminada cuando
todos los sitios reconocen la escritura de dicho dato. Esto puede suponer una fuerte
latencia de procesamiento si la replicación utiliza una conexión lenta.
• Una replicación asíncrona: aquí, el clúster del sitio principal puede leer y escribir
sobre su almacenamiento sin tener por qué esperar a que los datos se repliquen
sobre el segundo sitio. La replicación se efectúa, en este caso, bien de forma
continua o bien de manera planificada. En caso de siniestro, puede haber cierta
diferencia entre los datos de ambos sitios.
Desde un punto de vista del clúster, este comportamiento debe configurarse como Mayoría
de nodo o Mayoría de recurso compartido de archivos y nodo. En este último modo, se
recomienda que el recurso compartido de archivos para el quórum esté hospedado en un
servidor externo al clúster. Esto permite aprovechar la conmutación por error automática
entre los sitios, si bien la mayoría de administradores prefieren realizar esta conmutación de
forma manual.

5. Actualización compatible con clústeres de conmutación por error

Incluida con Windows Server 2012 R2, la funcionalidad Actualización compatible con
clústeres (CAU, Cluster-Aware Updating) permite automatizar la aplicación de
actualizaciones de Microsoft (Windows Update) sobre los nodos del clúster, conservando
un alto nivel de servicio.

El principio de funcionamiento es sencillo: se instalan las actualizaciones nodo a nodo. En

primer lugar, el primer nodo se pone en pausa, sus sesiones activas se drenan hacia otro
nodo y los roles basculan. A continuación, se aplican las actualizaciones y se reinicia el
servidor, si fuera necesario. Para finalizar, el nodo se pone en funcionamiento dentro del
clúster, recuperando los roles que tuviera antes de realizar las actualizaciones.

La actualización compatible con clústeres funciona siguiendo los siguientes dos modos:

• Actualización remota: en este modo se utiliza un equipo Windows Server 2012 R2

o Windows 8.1 (Windows Server 2012 y Windows 8, como mínimo) con las
herramientas de administración de Actualización compatible con clústeres
instaladas que no forme parte del clúster. Este equipo permite verificar, aplicar y
realizar un seguimiento de la aplicación de actualizaciones con una instalación
mínima (Server Core) de Windows Server 2012 R2 o Windows Server 2012.
• Actualización automática: en este modo, es el clúster quien administra,
directamente, las actualizaciones sobre los nodos. El primer nodo que se actualiza es
el que posee el rol de Actualización compatible con clústeres y, a continuación, se
actualizan los demás nodos.

De hecho, el proceso de actualización adaptado a los clústeres ejecuta el cliente Windows

Update. De este modo, por defecto, es posible instalar todas las actualizaciones disponibles
en el sitio Windows Update de Microsoft. Es posible gestionar las actualizaciones que
quiere instalar sobre sus nodos con ayuda de un servidor WSUS interno y una GPO.

Puede configurar la actualización compatible con clústeres en modo automático de dos

formas: utilizando el Administrador de clúster de conmutación por error, seleccionando
su clúster y, a continuación, haciendo clic en el enlace Actualización compatible con
clústeres que se encuentra en la sección Configurar, o bien mediante comandos
PowerShell.
En el primer caso, en la zona Conectar a un clúster de conmutación por error, tendrá
que seleccionar el nombre de su clúster y, a continuación, hacer clic en Conectar para que
aparezcan sus nodos.

Mediante la consola Actualización compatible con clústeres, podrá:

• Aplicar actualizaciones a este clúster: con ayuda del asistente, puede instalar, de
manera inmediata, las actualizaciones disponibles para los nodos de su clúster.
• Vista previa de actualizaciones para este clúster: le permite ver las
actualizaciones disponibles para los nodos de su clúster.
• Crear o editar perfil de ejecución de actualizaciones: permite crear o modificar
un perfil de ejecución de actualizaciones y almacenarlo en formato XML para
importarlo en otro servidor.
• Generar informe sobre ejecuciones de actualización anteriores: permite generar
un informe acerca de la ejecución e instalación de las actualizaciones en su clúster.
• Configurar opciones de auto-actualización de clúster: le permite habilitar,
deshabilitar, configurar y planificar la aplicación de actualizaciones automáticas en
su clúster de forma automática, mediante un simple asistente.
• Analizar preparación de la actualización del clúster: permite verificar la correcta
configuración del clúster para instalar actualizaciones remotas.
Ejemplo de configuración mediante PowerShell:

#Agregar un rol al clúster

Add-CauClusterRole -ClusterName cluster02 -CauPluginName
Microsoft.WindowsUpdatePlugin
-MaxRetriesPerNode 3 -CauPluginArguments
@{’IncludeRecommentedUpdate’=’True’} -StartDate
"14/10/2012 03:00:00" -DaysOfWeek 4 -WeeksOfMonth @(3)
-EnableFirewallRules -Force

#Activación del rol

Enable-CauClusterRole -ClusterName cluster02 -Force

Conclusión
Ahora, conoce las ventajas e inconvenientes de una solución de alta disponibilidad y/o de
reparto de carga. Tiene las cartas en su mano para preparar su solución y gestionarla una
vez puesta en producción. Como con muchas otras soluciones, no debe esperar a tener
alguna necesidad tecnológica concreta (una caída de algún servidor, por ejemplo) para
validar su buen funcionamiento. Debe planificar pruebas de forma regular, con el objetivo
de asegurar su correcto funcionamiento del día D. A diferencia de la mayoría de proyectos,
es precisamente si ningún usuario se da cuenta de nada (comportamiento transparente),
cuando podremos decir que el proyecto ha sido un éxito.

Introducción
Este capítulo está dedicado a la definición y la configuración de los componentes
necesarios para el correcto funcionamiento de la red de la empresa basada en Windows
Server 2012.

En él, se abordan los componentes IP, DNS, DHCP, WINS, así como la implementación de
la cuarentena de red en DHCP, IPsec y 802.1x.

Seleccionar una infraestructura de red

La implementación de toda la arquitectura de red supone realizar un análisis de las redes
existentes. A menudo, es difícil modificar el conjunto de una sola vez. La migración se
lleva a cabo, habitualmente, implementando un nuevo direccionamiento de red y
haciéndolo cohabitar con las redes existentes. La modificación del direccionamiento IP se
ve, a menudo, como una tarea costosa que aporta pocas ventajas suplementarias.

Es, por lo general, durante el desplazamiento o la creación de un sitio cuando es fácil, o

incluso necesario, repensar el direccionamiento IP y planificar un nuevo sistema.

El cambio de un dominio DNS es, todavía, más complicado, sobre todo cuando dicho
dominio sirve como soporte a un dominio Active Directory. En este caso, una migración
representa un estudio particular que se sale del marco de nuestra presentación.

1. La elección de la arquitectura de red

A este nivel, cabe estudiar bien dos puntos:

• La elección de la zona DNS.

• La elección de la clase de red.

a. La zona DNS

Existen dos aspectos importantes a la hora de escoger la zona DNS.

El nombre escogido para la zona DNS debe corresponderse con la integridad de la entidad
(empresa, grupo, etc.) que se quiere gestionar. Este nombre debe poder ser aceptado por
todas las entidades dependientes que tengan que alcanzar esta zona. ¡El problema es más de
aspecto político que técnico!
Si alguna entidad no se encuentra en este marco, quiere decir que debe asociársele una zona
DNS específica.

Si la zona DNS debe utilizarse en Internet, el dominio DNS tendrá que ser,
obligatoriamente, público y estar registrado, es decir, debe utilizar una extensión
reconocida de tipo .es, .com, .info...

En una red interna, el dominio puede ser público o privado. La elección más común es, por
tanto, escoger un dominio DNS local con una extensión desconocida en Internet. La
extensión .local se utiliza muy a menudo bajo la forma miempresa.local. El desacople
entre la sección interna y la externa resulta mucho más fácil de llevar a cabo. Esta elección
se desaconseja, pues los proveedores de certificados han decidido, de acuerdo con los
grandes fabricantes, no distribuir más certificados a partir del 1 de Enero de 2014 que
incluyan nombres de dominios DNS que no puedan verificarse. Esto tiene una
consecuencia directa en la configuración de muchos servidores Exchange que trabajan con
este tipo de certificados. No obstante, es probable que algunos servidores Web visibles al
mismo tiempo en la Intranet y en Internet utilicen este tipo de funcionalidad.

En cambio, el uso del mismo nombre de dominio sobre la red interna y sobre Internet
obliga a tener servidores DNS diferentes para hacer visible sobre Internet únicamente la
parte que se desea exponer. Esto supone una doble administración de las zonas DNS. Esta
solución resulta muy compleja. En las nuevas instalaciones, las recomendaciones serán:

• bien utilizar un dominio con una extensión conocida (y disponible en el registro) tal
como .org, .net, .info.
• o bien definir un subdominio del dominio público que ya se esté utilizando, de la
forma ad.miempresa.es.

En ambos casos, no supondrá ningún problema obtener un certificado público.

b. La clase de red

Para todas las redes internas, la elección se realizará, evidentemente, sobre las clases de
redes privadas. Si no se quiere modificar la integridad de las redes existentes por motivos a
menudo históricos, es posible, al menos, crear todas las nuevas redes siguiendo esta regla.

La clase de red se escoge en función del número de máquinas presentes en la red, del
número de sitios, etc. Una red de clase C (192.168.0.X) representa, a menudo, una buena
elección inicial. Siempre es posible cambiar la clase de la red o incluso utilizar varias redes
en función de las necesidades.

El uso de TCP/IP v6 no está, todavía, bien desarrollado, aunque será necesario en un plazo
de dos a tres años, principalmente en Internet. En la red local, siguen existiendo muchas
aplicaciones que no son compatibles, ¡aunque deberían evolucionar rápidamente! La red
IPv6 se estudia en el capítulo La evolución de la red.
2. La instalación de un servidor DHCP

El servidor DHCP permite implementar rápidamente la red seleccionada, y permite,

también, modificar rápidamente y de forma global una serie de parámetros. Las empresas
que, a día de hoy, no utilizan ningún servicio DHCP son más bien raras.

Como muchos otros componentes de Windows Server 2012, el servicio DHCP es un rol.

a. Definición

El protocolo DHCP (Dynamic Host Configuration Protocol) tiene como objetivo proveer
una dirección IP y una máscara de subred a cualquier dispositivo de la red (estación,
servidor u otro) que lo solicite. Según la configuración, es posible configurar también otros
parámetros importantes, tales como: las direcciones IP de la ruta por defecto, los servidores
DNS que debe utilizar, los servidores WINS y el sufijo del dominio, por citar algunos de
los más importantes.

DHCP se reserva, a menudo, para las estaciones, las impresoras, y no debería servir, salvo
muy excepcionalmente, para los servidores.

b. Instalación

Como con todos los demás componentes de Windows, la instalación puede llevarse a cabo
de forma gráfica o mediante un comando PowerShell sin tener que insertar ningún medio
extraíble.

Instalación mediante PowerShell :

Install-WindowsFeature DHCP

Preste atención, ¡el servicio se iniciará y configurará de manera inmediata con arranque
automático! En cambio, la instalación del componente DHCP mediante PowerShell sólo
instala el servicio DHCP. Es preciso ejecutar el comando indicado a continuación para
instalar la herramienta de administración.

Install-WindowsFeature RSAT-DHCP

El servicio debe iniciarse para poder acceder y configurar DHCP.

Para que el servicio DHCP empiece a distribuir las direcciones, es imprescindible

configurar y habilitar un ámbito.

Preste atención, si el servidor que hospeda DHCP forma parte de un bosque Active
Directory, debe estar, además, autorizado para los administradores miembros del grupo
Administradores de empresas y aquellos que hayan recibido los permisos de
administración de DHCP.

El servicio DHCP, como los demás servicios de red de referencia (DNS, WINS), debería
instalarse siempre sobre servidores que utilicen una IP fija.

c. Configuración

La consola de administración de DHCP se encuentra en cualquier servidor con el rol DHCP

instalado mediante la interfaz gráfica y en cualquier servidor donde se haya agregado,
específicamente, este componente de administración.

Si el servidor local tiene el rol DHCP instalado, el servidor debería aparecer

automáticamente en la consola.

Si el servidor no tiene el rol DHCP instalado, o no es el servidor que desea administrar,

utilice el botón derecho para agregar un servidor específico o escogerlo entre los servidores
autorizados.
Para autorizar un servidor DHCP, utilice la opción Administrar servidores autorizados.

Haga clic en el botón Autorizar, e indique el nombre o la dirección IP.

En un bosque Active Directory, sólo aquellos servidores DHCP que estén autorizados a los
administradores de empresas tienen el permiso de asignar direcciones IP a partir de los
ámbitos habilitados.

Confirme la dirección y el nombre propuestos haciendo clic en el botón Aceptar.

Cierre la ventana de los servidores autorizados haciendo clic en Cerrar.

Los servidores autorizados aparecen marcados con una flecha de color verde.
Cada servidor DHCP puede servir varios ámbitos, aunque sólo uno por cada red IP.

Utilice el asistente Ámbito nuevo que aparece haciendo clic con el botón derecho sobre
IPv4 para preparar el uso de la red deseada.
Defina el nombre y la descripción del ámbito.

Indique el ámbito deseado.

He aquí un ámbito clásico para una red 172.16.X.X de clase B que utiliza una máscara
estándar 255.255.0.0.

El rango utilizado no debe, obligatoriamente, utilizar la totalidad de la clase de red, de

modo que puede dejar algunas direcciones libres para los servidores, o direcciones IP
reservadas a impresoras u otros dispositivos.

Informe las excepciones y el eventual retardo.

Las exclusiones permiten bloquear el uso de direcciones cuyo grupo de direcciones ya esté
en uso en el ámbito seleccionado. Esta elección se utiliza, a menudo, cuando se quiere
recuperar direcciones excluidas. El retardo permite tener en cuenta los distintos métodos de
conmutación o escoger un servidor DHCP para que responda en primer lugar sobre un
segmento determinado.

Seleccione la duración del contrato.

La duración del contrato debe seleccionarse en función de la disponibilidad de direcciones.
Idealmente, el contrato será lo más largo posible (30 días) siempre y cuando existan las
suficientes direcciones disponibles. Si fuera necesario disminuir a menos de 3 días la
duración del contrato, cabría considerar una ampliación de la subred seleccionada.

Configure las opciones del ámbito.

Defina la dirección IP de la pasarela por defecto (pasarela de red).
La pasarela por defecto forma parte de los parámetros que habitualmente están ligados al
ámbito. Salvo casos muy concretos, sólo hay que incluir una dirección IP. Las direcciones
IP siguientes se utilizan únicamente si la primera no responde.

Indique el sufijo DNS y las direcciones IP de los servidores DNS.

Idealmente, todo dominio Active Directory debería incluir, al menos, dos controladores de
dominio y, por tanto, dos servidores DNS a este nivel.

Escriba las direcciones IP de los eventuales servidores WINS.

Como buena práctica, se recomienda no utilizar servidores WINS, salvo en caso necesario.
No hay que informar las direcciones IP de los servidores WINS salvo si el servicio tiene
que estar, efectivamente, instalado.

Active el ámbito al finalizar el asistente

He aquí la visualización de las opciones del ámbito tras su activación. Observará que las
opciones a nivel de servidor se identifican mediante un icono especial que representa un
servidor. Son aquellas que contienen parámetros que son variables globales sobre todos los
ámbitos.

Las opciones del servidor (006, 015, 042 y 046) sirven como valores por defecto, aunque se
reemplazan por las opciones del ámbito, que son prioritarias.
 • La opción Nombre de dominio DNS no permite especificar varios sufijos de
búsqueda DNS. Si fuera necesario, las directivas de grupo permiten agregar sufijos
de búsqueda.
• El Tipo de nodo con el valor 0x8 configura el modo de resolución híbrida. Es decir,
se realizará una búsqueda de servidores WINS en primer lugar, y se pasará al modo
Broadcast si falla.

Puede resultar muy interesante configurar ciertas propiedades avanzadas del servidor
DHCP.

Por ejemplo, cuando se configura la zona Intentos de detección de conflictos con un valor
superior a cero (generalmente 2), DHCP utilizará una consulta ICMP para determinar la
posible existencia de alguna máquina sobre esta dirección.

La actualización dinámica de los registros DNS es un elemento particularmente importante

que hay que configurar.
En la versión R2, es posible deshabilitar la actualización dinámica de los registros PTR.

El botón Configurar permite habilitar la protección de nombres durante la inscripción, las

actualizaciones y las eliminaciones de registros de tipo A y PTR. Esta protección resulta
efectiva únicamente si está habilitado el modo Actualizaciones dinámicas seguras.

Cuando se crean y utilizan zonas de búsqueda inversa (Reverse DNS), es importante

actualizar los registros PTD y no ignorarlos cuando se elimina el contrato..

La duración del contrato será más elevada conforme mayor sea el número de direcciones IP
disponibles y menor sea el riesgo de producirse algún conflicto.

La pestaña Filtros permite limitar la distribución de direcciones DHCP, bien autorizando

ciertos tipos de hardware de red o bien excluyendo algunos otros. Estos tipos incluyen,
habitualmente, Token Ring, X25, ATM, Ethernet, Localtalk, Frame Relay, Fibre channel,
HDLC, LocalNet y Ethernet IEE 802.
d. Reservas

Incluso para aquellos administradores que quieran gestionar todas las máquinas con un
direccionamiento IP fijo, DHCP puede resultar muy útil. En efecto, hay quien gestiona de
este modo la práctica totalidad del parque mediante una reserva para cada dirección IP,
incluso si esto supone una seguridad más o menos ficticia.

Sin llegar al caso en que debamos gestionar así toda la red, las reservas resultan muy útiles
para las impresoras de red, los dispositivos administrables (tales como switch...) y, en
ocasiones, para ciertas máquinas cuya dirección IP se autorice y utilice en la configuración
de alguna aplicación.

Cada tarjeta de red dispone de una dirección física única llamada dirección MAC y, de este
modo, es posible identificar una demanda proveniente de esta dirección y proveerle siempre
la misma dirección IP y la misma configuración.

He aquí un ejemplo de definición de una reserva:

Observe que las reservas deben formar parte de la red, aunque no tienen por qué formar
parte del ámbito DHCP, lo cual puede resultar práctico en ciertas ocasiones. Si se utilizan
varios servidores DHCP para una misma subred (con restricción de uso), las reservas deben
configurarse sobre todos los servidores.

Algunas herramientas proveen kits de recursos tales como DHCPCMD.EXE, o la librería

DHCPOBJS.DLL, que permiten desarrollar scripts para automatizar la creación y
configuración de los ámbitos. El comando NETSH permite, también, realizar operaciones
de configuración, importación o exportación.

Para exportar una configuración existente, puede utilizar el comando NETSH:

NETSH DHCP SERVER DUMP >DHCPCONFIG.CMD

Adapte, a continuación, el archivo DHCPCONFIG.CMD en función de las necesidades

eliminando las líneas inútiles y modificando las demás.

La programación de DHCP para PowerShell requiere que se cargue el módulo

correspondiente mediante el siguiente comando:

Import-Module DHCPSERVER

La instrucción Get-Command -Module DHCPSERVER enumera todos los componentes

que incluye este módulo.
He aquí un enlace hacia un primer ejemplo de uso práctico de los comandos PowerShell
para DHCP: http://blogs.technet.com/b/teamdhcp/archive/2012/07/15/bringing-powershell-
to-dhcp-server.aspx

e. Registros DNS basados en directivas DHCP

Las directivas DHCP permiten configurar de manera particular los dispositivos, por
ejemplo asignándoles una parte del rango IP, en base a los siguientes criterios:

• La clase Vendor
• La clase User
• La dirección MAC
• El identificador de cliente
• La información relativa al agente de retransmisión

Estas directivas resultan particularmente interesantes para gestionar, de distinta manera:

• Los tipos de dispositivos diferentes: impresoras, teléfonos IP…

• El rol y el distinto uso de estos dispositivos: portátiles, PC fijos…
• Dispositivos virtuales: máquinas virtuales

El criterio más sencillo que se puede utilizar es, a menudo, la dirección MAC cuyos 6
primeros caracteres hexadecimales identifican, generalmente de forma unívoca, al
fabricante y el modelo.

En el caso de máquinas virtuales, son los 6 últimos caracteres los que pueden resultar útiles,
pues definen el direccionamiento definido a nivel de hypervisor.

Destacaremos que las directivas se gestionan bien a nivel del servidor o bien a nivel de un
ámbito.

Cree una nueva directiva DHCP.

Asigne un nombre a la directiva.
Agregue una condición.
Seleccione las condiciones de aplicación de la directiva.
Haga clic en Agregar tras marcar la opción Anexar o Anteponer.
Indique si desea utilizar un ámbito concreto para esta directiva.
Preste atención, este rango de direcciones IP debe formar parte del ámbito DHCP
correspondiente.

Indique las propiedades DHCP que podrían ser diferentes (Router, Servidor DNS…).
Resumen de la configuración inicial:
La dirección MAC puede obtenerse desde una ventana de comandos DOS mediante el
comando Ipconfig /ALL o mediante el comando PowerShell GET-NetAdapter.

Tras configurar una directiva, es posible configurar la actualización de DNS específica

asociada a la misma.

A partir de las propiedades de la directiva, la pestaña DNS permite modificar el

comportamiento del registro DNS, por ejemplo para modificar el sufijo del dominio.
Observe que la pestaña General da acceso a la configuración de una concesión
personalizada, incluso ilimitada.
f. Configuración de la conmutación por error del ámbito DHCP

En las versiones anteriores, existían dos formas de garantizar la disponibilidad de la función

DHCP:

• Instalar el servicio en un clúster de Windows

• Repartir el ámbito DHCP entre varios servidores (habitualmente 70 %, 30 %)

Windows Server 2012 y 2012 R2 proporcionan la funcionalidad de DHCP Failover, es

decir, la conmutación por error de DHCP evitando los problemas vinculados con las
soluciones anteriores.

Para simplificar, esta nueva configuración permite a dos servidores DHCP gestionar la
misma red o el mismo ámbito. Existen dos modos de funcionamiento: bien un modo de tipo
activo/pasivo, o bien un reparto de carga con un reparto de clientes. En ambos casos, la
información y los ámbitos se replican entre los servidores, y los clientes conservan la
misma configuración.

Observe que, para IPv6, este tipo de configuración no resulta útil. Basta con que ambos
servidores DHCP distribuyan las mismas opciones para obtener el mismo resultado.
Sólo es posible instalar dos servidores DHCP. La única restricción es disponer de dos
servidores Windows Server 2012/2012 R2. Éstos no deben, obligatoriamente, formar parte
del dominio, en cambio no se garantiza el correcto funcionamiento si los relojes están
desfasados más de un minuto.

He aquí el procedimiento de configuración:

La primera etapa consiste en verificar que ambos servidores DHCP están instalados y
autorizados, si forman parte de un dominio.

Debe existir al menos un ámbito sobre uno de los servidores antes de comenzar con el
procedimiento que permite configurar la conmutación por error.

La opción Configurar conmutación por error se encuentra en el menú contextual del

contenedor IPv4 o del ámbito que se desea proteger.

Seleccione el ámbito (o los ámbitos) que desea configurar en alta disponibilidad.

 Agregue el servidor DHCP asociado. Este puede escogerse entre los servidores autorizados
en el caso de un dominio, en caso contrario escriba su nombre.
 Cree la relación de conmutación por error. ¡Es importante seleccionar el modo de
protección!
Seleccionar el modo Equilibrio de carga o Espera activa.

El modo Equilibrio de carga repartirá las peticiones en función del porcentaje indicado.

El modo Espera activa utiliza únicamente el servidor principal, aunque los datos se
replican en el segundo servidor, que toma el control en caso de caída del servidor principal.

Escriba una cadena de encriptación en la zona Secreto compartido.

Esta cadena se utiliza para dotar de seguridad a la comunicación entre ambos servidores,
que comparten esta misma clave.

Se muestran los detalles de la configuración antes de su validación.

Se muestra el resultado de la configuración. Haga clic en Finalizar.
La replicación de toda la configuración de la zona, incluidos los rangos activos, se realiza
de manera inmediata.

He aquí alguna información complementaria relativa a la administración:

• Tras la configuración, es posible forzar la replicación del ámbito o de la relación.

 Estas opciones resultan prácticas para asegurar una configuración idéntica en
ambos servidores DHCP, por ejemplo tras la parada de uno de los dos servidores.

La replicación del ámbito replica únicamente el ámbito seleccionado.

La replicación de la relación replica todos los ámbitos configurados con

conmutación por error entre ambos servidores DHCP.

• En caso de que se anule la configuración, el servidor principal guarda la

configuración, y el servidor Asociado se vacía de cualquier información relativa a
este ámbito.

Implementar los sistemas de resolución de

nombres
1. La resolución DNS

DNS se ha convertido en la piedra angular del funcionamiento de una red Windows basada
en Active Directory, aunque no sólo esto.

Muchas de las actividades actuales (mensajería, Internet) se basan en un buen

funcionamiento de la red y, en particular, del servicio DNS.
Ya no es, por tanto, posible obviar este sistema que hospeda cada vez más información vital
para el buen funcionamiento del conjunto de la red.

a. Definición

DNS (Domain Name Server) es un protocolo que permite a los clientes (de la red) consultar
una base de datos que contiene información sobre las máquinas y los servicios que
hospedan.

DNS es un sistema que permite establecer una correspondencia entre una dirección IP y un
nombre de dominio y, en términos generales, encontrar cierta información a partir de un
nombre de dominio.

b. Instalación

La instalación del servicio DNS sobre una red Windows se hace, a menudo, en el marco de
instalación del primer controlador de dominio Active Directory. Su configuración inicial se
tiene en cuenta de manera automática en el asistente DCPROMO. Por defecto, la zona DNS
utilizada por Active Directory está, ahora, integrada y administrada por Active Directory.

Para instalar el rol DNS mediante PowerShell:

Install-WindowsFeature DNS
Install WindowsFeature RSAT-DNS-Server

La segunda instrucción instala las herramientas de administración de DNS.

Si el servicio DNS se agrega sobre un controlador de dominio, todas las zonas integradas
con Active Directory se conocen automáticamente y se utilizan en el servicio DNS para
llevar a cabo la resolución de nombres.

En los demás casos, el servicio DNS deberá gestionarse como un servidor DNS clásico.
Podrá, por tanto, hospedar zonas y servir de caché o de redirector hacia otros sistemas
DNS.

c. Los distintos tipos de zona

Zona de tipo principal

Este tipo de zona se utiliza principalmente para administrar zonas que no estén vinculadas a
Active Directory. Las zonas DNS públicas, que contienen los servidores Web de la empresa
y los servidores de mensajería son los ejemplos de uso más corrientes.

Cada zona se almacena en un archivo de texto específico con formato estándar y

extensión .dns. Este tipo de archivo es compatible con los demás sistemas DNS tales como
BIND. Esto permite importar o exportar zonas DNS entre los distintos servidores.
El servidor que hospeda la zona principal es el único que autoriza y valida las
actualizaciones de su zona. Esta es la principal diferencia con las zonas integradas en
Active Directory que autorizan, ellas, las modificaciones sobre cada controlador de
dominio.

Zona de tipo secundario

Una zona secundaria puede establecerse a partir de un servidor de zona principal, una zona
integrada en Active Directory o incluso otro servidor de zona secundaria. La zona
secundaria no es sino una réplica exacta de la zona de la que depende. En cambio, la
replicación debe estar autorizada sobre el servidor que sirve como referencia.

En el mundo Windows, la zona de tipo secundario sirve, a menudo, para replicar la

información de otro dominio Active Directory para realizar una aprobación entre dos
dominios. Las zonas secundarias se configuran, a menudo, sobre servidores BIND (Unix o
Linux) para obtener una resolución indirecta de los dominios DNS administrados por
Active Directory.

Como ocurre con la zona principal, la información se almacena en un archivo de texto con
extensión .dns.

En caso de pérdida del servidor principal, un servidor de zona secundario puede convertirse
en un nuevo servidor principal.

Las zonas secundarias presentan, a menudo, problemas de replicación, de retardos en las

actualizaciones, de notificación o de seguridad que hay que configurar. Es, por
tanto, preferible evitar el uso de zonas secundarias reemplazándolas por redirecciones
condicionales o zonas de rutas internas.

Zona integrada en Active Directory

Una zona integrada en Active Directory consiste, como su propio nombre indica, en utilizar
la base de datos de Active Directory como almacén principal de información. De entrada,
aprovecha todas las opciones de seguridad de Active Directory, así como la replicación
incremental entre todos los controladores de dominio.

Todos los dominios DNS pueden integrarse con Active Directory, no sólo aquellos usados
directamente por Active Directory.

A menos que su servidor DNS no se encuentre en su controlador de dominio, todas las

zonas DNS deberían estar integradas en Active Directory.

d. Los distintos tipos de replicación

Sólo se aplican a las zonas integradas en Active Directory, accediendo a las propiedades del
dominio seleccionado.
Seleccione la zona DNS y, a continuación, haga clic con el botón derecho y seleccione
Propiedades en el menú.

Haga clic en Modificar junto a Replicación.

Aparecen los distintos tipos de replicación.

Replicación en todos los servidores DNS del bosque

De preferencia a este tipo de replicación para los dominios que deban ser conocidos (y se
tengan que resolver) rápidamente en todos los dominios del bosque sin tener que transferir
las consultas hacia los redirectores (Forwarders). Esta elección debe aplicarse,
particularmente, al dominio raíz del bosque.

Replicación sobre todos los controladores de dominio

La replicación sobre todos los controladores de dominio es el modo compatible con el que
existía en Windows 2000. Se trata de la elección lógica cuando los controladores de
dominio se utilizan como servidores DNS de referencia. En efecto, como los controladores
de dominio ya replican los datos de DNS al mismo tiempo que los demás datos del
directorio, basta con instalar el servicio DNS para que se asegure esta funcionalidad.

Replicación sobre todos los servidores DNS del dominio

Esta elección se utiliza con poca frecuencia, y permite a los servidores DNS que no son
controladores de dominio recibir, también, la replicación de una zona concreta.

Replicación ligada a una partición de aplicación

Por defecto, en un bosque Active Directory, existen dos particiones de aplicación

particulares y que están disponibles para realizar la replicación:

• la partición ForestDnsZones;
• la partición DomainDnsZones.

Si se crea alguna otra partición de aplicación, puede utilizarse para replicar la información
DNS (u otro tipo de información) sobre grupos de máquinas personalizados.

Observe que haciendo clic con el botón derecho sobre el servidor DNS, la opción Crear
particiones de directorio de aplicaciones por defecto puede resultar muy útil para recrear
una u otra partición.
e. Zonas de búsqueda inversa

Las zonas de búsqueda inversa DNS son capaces de resolver el nombre de una máquina a
partir de su dirección IP. La clasificación se realiza, por lo tanto, en función del
direccionamiento IP de la red.

Este modo de búsqueda no es necesario, y no se utiliza en el funcionamiento normal de un

bosque Active Directory. Por este motivo Microsoft no crea zonas de búsqueda inversa de
manera automática.

En cambio, el cliente DNS de Microsoft sabe cómo utilizarlas si se definen. Algunas

herramientas, tales como la copia de seguridad TINA (Time Navigator de ATEMPO)
necesitan este tipo de zonas para poder funcionar correctamente.

Cuando se resuelve un problema de red y se utiliza la herramienta NsLookup, es

imprescindible haber creado estas zonas de búsqueda inversa para que la herramienta
funcione correctamente y poder interpretar los resultados.

Cuando se crean estas zonas, es importante configurar DHCP para gestionar las
actualizaciones de los registros PTR, es decir, el nombre del host asociado con cada
dirección IP. La integración de estas zonas con Active Directory se aplica, principalmente,
a las redes IP que contienen, en su mayor parte, equipos Windows.

Tras la creación de una zona de búsqueda inversa, el nombre de la zona se basa en el

direccionamiento IP, tomando cada valor de forma inversa.

f. La zona GlobalNames o GNZ

Esta posibilidad no viene activada por defecto. Su objetivo consiste en obtener una
resolución de nombres simples (llamados single-label name), sin dominio ni extensión,
sobre el conjunto del dominio o del bosque. Para algunos controladores, esto puede servir
para eliminar el servicio WINS sin tener que sufrir los inconvenientes de la replicación y
las actualizaciones regulares propias del servicio WINS.

En particular, se trata de crear una zona DNS especial llamada GlobalNames en la cual se
incluyen todos los nombres para los que se quiere tener una resolución inmediata sin tener
que buscar entre los distintos sufijos de dominio de búsqueda DNS.

Es posible, por tanto, crear entradas tales como www, smtp, pop, proxy... que apunten a
servidores bien conocidos o muy solicitados en el conjunto de la empresa. Estas entradas
pueden ser registros de tipo A que indican, directamente, la dirección IP, o de tipo
CNAME, es decir, un nombre completo que se resuelve de forma clásica.

Para configurar la GNZ, los servidores DNS autoritarios deben ser, como mínimo,
servidores Windows Server 2008. Sobre cada servidor DNS, active el modo GNZ
utilizando el siguiente comando PowerShell:
Set-DnsServerGlobalNameZone -Enable:$true

Por defecto, la zona GlobalNames no debe aceptar las actualizaciones dinámicas. En

cualquier caso, es algo que no se recomienda. Se aconseja crear una zona integrada con
Active Directory con replicación a nivel del bosque o del dominio, según el ámbito
deseado.

add-dnsserverprimaryzone -name GlobalNames -ReplicationScope forest

-DynamicUpdate None

Agregue los registros que desee por línea de comandos o a través de la interfaz gráfica. A
continuación se muestra un ejemplo de cómo agregar un registro estático que apunta a un
servidor Proxy.

Add-DnsServerResourceRecordA -zone GlobalNames -name Proxy

-IPv4address 172.16.1.5

Por defecto, la resolución local DNS se utiliza antes que la de la zona global, si fuera
preciso utilice el siguiente comando para dar preferencia a la resolución de nombres a partir
de la zona GlobalNames:

set-DnsServerGlobalNameZone -GlobalOverLocal $true

Esta configuración sólo se aplica a nivel de los servidores DNS. El objetivo es centralizar la
configuración.

g. Pruebas y verificaciones

Existen diversas herramientas que permiten verificar el correcto funcionamiento de la

resolución de nombres sobre los distintos dominios.

La herramienta ping es la primera que se utiliza para realizar pruebas de resolución. Preste
atención, el resultado de las pruebas puede verse alterado por el filtrado existente en los
firewall intermedios o sobre los propios sistemas. Utilice ping con el nombre corto, el
nombre completo (el nombre seguido del dominio DNS completo) y la dirección IP. Si se
obtiene una respuesta con cada una de las pruebas, significa que todo funciona
correctamente. En la prueba basada en la dirección IP, el argumento -a permite verificar
también la resolución inversa.

Si aparece el nombre completo SRVFIC01.MiEmpresa.Priv, significa que la resolución

inversa funciona correctamente, incluso en el caso de que no responda a un ping.

C:\Users\administrator.DOMINIOLOCAL>ping -a 172.16.1.184

Haciendo ping a SRVFIC01.MiEmpresa.Priv [172.16.1.184]

con 32 bytes de datos:
Respuesta desde 172.16.1.184: bytes=32 tiempo<1ms TTL=128
Respuesta desde 172.16.1.184: bytes=32 tiempo<1ms TTL=128
Respuesta desde 172.16.1.184: bytes=32 tiempo<1ms TTL=128
Respuesta desde 172.16.1.184: bytes=32 tiempo<1ms TTL=128

Estadísticas de ping para 172.16.1.184:

Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos),
Tiempo aproximado de ida y vuelta en milisegundos:
Mínimo = 0ms, Máximo = 0ms, Media = 0ms

La herramienta NsLookup permite consultar a los servidores DNS los distintos campos y
registros de las zonas DNS accesibles.

Los dos comandos, Tracert y PathPing, son equivalentes al ping, aunque muestran todas
las etapas, las direcciones atravesadas y las duraciones de cada etapa.

Existen, adicionalmente, otras herramientas como netsh, dnscmd y dcdiag que

aumentan enormemente las posibilidades.

Encontrará información complementaria acerca de la implementación de Active Directory

en el capítulo Dominio Active Directory.

h. Los distintos tipos de registro

SOA: el registro de tipo SOA se corresponde con una fuente de autoridad de la zona
afectada. Todas las modificaciones en la zona incrementan el número de versión asociado a
esta zona.

NS: el registro NS contiene todos los servidores de nombres de servidores autorizados a

responder en el dominio,

A diferencia de los demás registros, los registros SOA y NS son únicos en cada zona.

A: el registro A define la dirección IP asociada a un nombre de máquina concreto (llamado

Host en inglés).

CNAME: el registro CNAME crea un nombre (llamado Alias) en una zona, que podrá
asociarse a un registro de tipo A en la misma zona o en otra zona DNS.

MX: cada registro MX debe apuntar a un registro de tipo A en el que alguna máquina posea
un servicio SMTP activo. Este registro resulta inútil para la mensajería interna basada en
Exchange. Cuando existen varios registros de tipo MX, el peso (prioridad) más bajo
asociado a cada uno de ellos indica el servidor de mensajería que debe utilizarse de forma
prioritaria.

SRV: el registro SRV sirve para indicar un servicio particular en un puerto específico. Los
registros LDAP, Catálogo Global, Kerberos, SIP y otros utilizan este tipo de registros.
PTR: el registro PTR (Puntero) indica el nombre completo (FQDN) asociado a la dirección
IP que se utiliza para la búsqueda. Sólo existe en las zonas de búsqueda inversa y no son
indispensables en un entorno Microsoft.

Existen otros tipos de registro, tales como el campo TXT, que se utilizan con menor
frecuencia y son menos útiles para el funcionamiento de una red de equipos Windows.

i. Buenas prácticas

En el marco de un bosque Active Directory, las buenas prácticas tratan de evitar la

replicación inútil de la información y, por tanto, evitar el uso de zonas secundarias que son
origen de muchos problemas.

Las soluciones que se utilizan son las zonas de código auxiliar (stub zones) o las
redirecciones condicionales.

En los bosques y redes completas, la simplificación implica el uso de redirectores a nivel de

cada subdominio hacia el dominio raíz de cada bosque.

A nivel de cada dominio raíz de cada bosque, el uso de una redirección condicional hacia
cada bosque bastará para resolver todo el bosque correspondiente.

j. DNSSEC

A partir de Windows Server 2008 R2 y Windows Server 2012, es posible aumentar la

fiabilidad de la información ofrecida y recibida por el servicio DNS. La condición principal
para utilizad DNSSEC es disponer de, al menos, un servidor Windows Server 2008 R2 con
el rol DNS instalado. El servidor no tiene por qué formar parte, necesariamente, de Active
Directory. En cambio, si la zona DNS que se quiere firmar está integrada en Active
Directory, entonces todos los servidores DNS del dominio o del bosque que gestionan esta
zona DNS deben tener instalado, como mínimo, un sistema operativo Windows Server
2008 R2.

DNSSEC permite autentificar la información DNS. Las zonas pueden firmarse

digitalmente. Esta firma se envía a los clientes bajo la forma de registros de recursos desde
los servidores que gestionan estas zonas. El cliente puede, a continuación, validar la
información como auténtica desde los servidores DNS firmados. DNSSEC impide, así,
ataques de tipo Man in the Middle que se basan, entre otros, en corromper los registros en
caché de un servidor DNS para redirigir a los usuarios hacia direcciones IP controladas por
el atacante.

El número de DNSSEC de Windows 2008 estaba muy limitado y se basaba en tres tipos de
registro:

• KEY: este registro contiene la clave pública indicada en la zona DNS del dominio.
 Esta clave puede corresponderse con un servidor, la zona u otra entidad. Los
registros KEY se autentifican mediante registros de tipo SIG.

• NXT: este registro permite indicar el próximo registro firmado, si existe.

• SIG: este registro contiene la firma digital de una zona o parte de la zona para
autentificar un recurso de un tipo concreto.

La implementación DNSSEC de Windows 2008 no permitía ni gestionar ni verificar la

información transmitida.

La norma utilizada actualmente por DNSSEC consiste en cuatro nuevos registros de

recursos:

• DNSKEY: registro de una clave DNSSEC.

• RRSIG: firma de los RR existentes con DNSSEC.
• NSEC: Next SEC, firma de los RR inexistentes con DNSSEC.
• DS: firma de las delegaciones de zona en DNSSEC.

Como con Windows Server 2008 R2, Windows Server 2012 puede no solo gestionar las
zonas firmadas, sino también recibir información firmada, validarla y transmitirla a sus
clientes. Sin embargo, DNSSEC puede configurarse de forma mucho más sencilla,
directamente mediante la interfaz de administración gráfica.

He aquí las distintas etapas a seguir para implementar DNSSEC:

Verifique bien las condiciones de uso de DNSSEC en los puntos importantes que se
indican al final del procedimiento.

En este ejemplo, se dota de seguridad a una zona sencilla llamada MiEmpresa.es, estática
y pública, que contiene dos registros MiSitioWeb (de tipo A) y www (de tipo CNAME).

Preste atención, el procedimiento es el mismo tanto si la zona DNS se integra con Active
Directory como si no. Sin embargo, la firma de la zona bloquea la zona, que ya no
podremos transformar.

La primera etapa consiste en autorizar DNSSEC sobre el servidor DNS.

DNSSEC está autorizado por defecto en Windows Server 2012. He aquí el comando que
permite verificar esto sobre el servidor DNS seleccionado:

Get-DnsServer -Computername DC2012 | FindStr /I "Enablednssec"

EnableDnsSec True

Si fuera necesario, utilice el siguiente comando de activación (por línea de comandos):

DnsCmd /config /EnableDnsSec 1

Esta activación de DNSSEC se corresponde con la entrada Habilitar validación DNSSEC

en las opciones avanzadas del servidor DNS.

Seleccione la zona que desea firmar y haga clic con el botón derecho para desplegar el
menú que contiene la opción DNSSEC.
Seleccione la opción Firmar la zona y haga clic en Siguiente.
Configure y distribuya los puntos de validación de DNSSEC.

Configure la clave KSK.

Agregue una clave de tipo KSK haciendo clic en Agregar.
Modifique los parámetros del certificado.

Se recomienda seleccionar una encriptación de tipo NSEC3, que impide recorrer y

descubrir toda la zona.

La clave KSK se agrega a la lista, haga clic en Siguiente para continuar.

Haga clic en Agregar para crear una clave de zona.
 Seleccione, de nuevo, el algoritmo NSEC3 y, a continuación, haga clic en Siguiente en la
lista de claves de la zona.
Haga clic en Siguiente.

Seleccione la distribución y la actualización de los anclajes de veracidad a nivel del

dominio y, a continuación, haga clic en Siguiente.
Haga clic en Siguiente.

Haga clic en Siguiente para aprobar las modificaciones aportadas.

Haga clic en Finalizar.
Refresque la visualización haciendo pulsando la tecla [F5].
La zona MiEmpresa.es está, ahora, firmada.

Si la zona no está integrada en Active Directory, o si los anclajes de veracidad no aparecen,

es posible importar las claves DNSKEY desde el servidor DNS que ha servido para firmar
la zona en todos los servidores DNS que pudieran necesitarlo.

Seleccione el contenedor Puntos de confianza y, a continuación, Importar. Seleccione

DNSKEY en la herramienta de administración DNS.
Indique el archivo Keyset correspondiente a la zona DNS deseada.

Verifique la integración de los certificados de tipo DNSKEY en la visualización de la

herramienta de administración.

Preste atención, esta configuración no debe realizarse sobre el servidor primario, sino,
únicamente, sobre los demás servidores DNS que reciban las consultas para esta zona.

Si la zona está integrada y el servidor DNS es controlador de dominio, esta operación sólo
debe realizarse una única vez para todo el bosque.

Verifique que la resolución de la zona especial .trustanchors funciona para la zona que ha
firmado mediante el siguiente comando PowerShell.

resolve-dnsname -name MiEmpresa.Es.trustanchors -type dnskey -server

dc2012
Name Type TTL Section Flags Protocol Algorithm
Key
---- ---- --- ------- ----- -------- --------- -
--
MiEmpresa.Es.trustanchors DNSKEY 3600 Answer 257 DNSSEC
7
{3, 1, 0, 1...}
MiEmpresa.Es.trustanchors DNSKEY 3600 Answer 257 DNSSEC
7
{3, 1, 0, 1...}

Firmar una zona DNS integrada en Active Directory

El procedimiento es muy similar al anterior.

Durante la instalación, el asistente pregunta si el servidor DNS en curso debe convertirse en

el maestro de claves.

Seleccione el servidor que va a actualizar las claves de la zona.

La única diferencia es que los puntos de confianza aparecen de forma inmediata en el

contenedor correspondiente.
Los nuevos registros creados en la zona están dotados, automáticamente, de una
nueva clave.

Configuración de servidores DNS integrados en Active Directory

Idealmente, si los servidores DNS son controladores de dominio, las directivas se aplican
directamente sobre la unidad organizativa de los controladores de dominio. Además, una
unidad organizativa puede utilizarse para todos los servidores DNS miembros.

Los certificados que utilizan los servidores DNS integrados en Active Directory pueden,
también, entregarse de forma automática a través de una entidad emisora de certificados
interna utilizando el modelo Directory Service Email Replication para crear una nueva
plantilla que incluya el identificador del objeto 1.3.6.1.4.1.311.64.1.1.

Se aplica una configuración particular para que el protocolo DNS pueda utilizarse de forma
anónima y autentificada, con el objetivo de validar los certificados.

Configuración de los clientes de DNSSEC

Las estaciones o servidores miembros previstos para utilizar DNSSEC deben estar
configurados para utilizar una NRPT (Name Resolution Policy Table), es decir, una tabla
que incluye una directiva de resolución de nombres.

Es posible crear una directiva de grupo para las máquinas miembros. Las demás se
configuran directamente en las claves de registro.

La directiva de grupo consiste en un conjunto de reglas que se aplican a la totalidad o a una

parte de la zona correspondiente. Se puede configurar en Configuración del equipo -
Directivas - Configuración de Windows - Directiva de resolución de nombres.
Cada regla puede aplicarse a distintas partes (configuración de las distintas pestañas
DNSSEC, Configuración DNS..., Servidor DNS genérico, Codificación) según los
criterios de la siguiente tabla:

Con cada regla, haga clic en el botón Crear para agregarla a la tabla de la directiva.
He aquí las distintas reglas que pueden habilitarse mediante esta directiva:

• El prefijo se corresponde con el nombre de la máquina: MiSitioWeb.

• El sufijo se corresponde con el nombre del dominio: MiEmpresa.es.
• El nombre completo es la combinación del prefijo y del sufijo:
MiSitioWeb.MiEmpresa.es.
• La subred (IPv4) con aspecto 172.16.1.1/16 permite securizar la búsqueda a partir
de la dirección IP para la zona de búsqueda inversa: 16.172.in-addr.arpa.
• La subred (IPv6) realiza esta misma operación para IPv6.

Los botones Actualizar, Crear, Eliminar, y también Eliminar regla, Editar regla
permiten agregar, modificar o eliminar el conjunto de reglas de la lista asociada a la
directiva.

El botón Configuración de directiva global avanzada permite acceder a las opciones

complementarias que indican cómo debe funcionar la resolución de nombres DNS según la
ubicación de red, los fallos que se produzcan en las consultas y la resolución de las mismas.
Para aquellas máquinas que no pertenezcan al dominio, es posible configurar la tabla NRPT
en la directiva local. Si se desea, es posible elaborar un script manual para aplicar esta
directiva. Basta, para ello, con exportar la clave
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicy-Config en un
archivo NRPT.REG mediante la herramienta REGEDIT y, a continuación, aplicarlo
mediante el comando REGEDIT /S NRPT.REG.

Hay varios puntos importantes que cabe tener en cuenta a la hora de utilizar DNSSEC:

• Incluso si Windows Server 2012 incluye, ahora, una actualización (llamada

RollOver) automática de los certificados para las zonas integradas en Active
Directory, es posible, aunque no recomendable, habilitar las actualizaciones
dinámicas sobre las zonas protegidas mediante DNSSEC.
 Este tipo de zona la utilizarán, con mayor frecuencia, las raíces del bosque o las
zonas que se accedan a través de Internet.

• La renovación de claves: el uso de claves seguras mediante certificados supone

configurar y verificar el mecanismo de renovación regular de claves.
• A diferencia de Windows Server 2008 R2, es posible agregar o eliminar registros en
cualquier momento y ya no requiere firmar de nuevo la zona. No es necesario
ningún certificado nuevo.
• La seguridad que provee DNSSEC sólo funciona con sistemas que tengan un cliente
DNS compatible y con sistemas que ejecuten Windows 7, Windows Server 2008 R2
y versiones superiores.

k. Administración de DNS mediante PowerShell

PowerShell incluye numerosos comandos que permiten facilitar el conjunto de la

administración del rol DNS.

Utilice el siguiente comando para obtener la lista de todos los comandos posibles.

Get-Command -Module DNSserver

Los comandos permiten crear, modificar y eliminar zonas, registros, así como configurar la
práctica totalidad de los parámetros de un servidor DNS, incluido DNSSEC.

He aquí la lista de comandos:

Expo Impo Clea Convert Enabl Disab

DnsServer Add Set Get Remove Invoke
rt rt r To e le
X X
Cache X X X
Conditiona
l
X
Forwarder
Zone X
Diagnostic
s X X
Directory
X
Partition X X
DnsSec
PublicKey X
DnsSecZo
ne Setting X X
DsSetting X X
EDns X X
Forwarder X X X X
Global
NameZone X X
Global-
Query-
BlockList X X
Key-
Storage-
Provider
Primary
X
Zone X X
Recursion X X
Resource-
X
Record X
Resource-
X
RecordA
Resource-
Record- X
AAAA
Resource-
Record-
Aging X
Resource-
Record- X
CName
Resource-
Record- X
DnsKey
Resource-
X
RecordDS X
Resource-
RecordM X
X
Resource-
X
RecordPtr
RootHint X X X X X
Scavengin
g X X
Secondary X X X
Zone
Setting X X
SigningKe
X
y X X X
SigningKe
y-Rollover X X X
Statistics X X
StubZone X X
Trust
Anchor X X X X X
TrustPoint X
Zone X X X X
ZoneAgin
g X X
Zone
Delegation X X X X
ZoneKey-
MasterRol
e
ZoneSign X
Zone
Transfer
Zone
Unsign X
Regist Res Restau Resu Suspen Syn Unregiste Updat
DnsServer Show Start Test
er et re me d c r e
X
Cache X
Condition
al
Forwarder
Zone
Diagnosti
cs
Directory
Partition X X
DnsSec
PublicKey
DnsSecZo X
ne Setting
DsSetting
EDns
Forwarder
Global
NameZon
e
Global-
Query-
BlockList
Key-
Storage-
Provider X
Primary
Zone X
Recursion
Resource-
Record
Resource-
RecordA
Resource-
Record-
AAAA
Resource-
Record-
Aging
Resource-
Record-
CName
Resource-
Record-
DnsKey
Resource-
RecordDS
Resource-
RecordM
X
Resource-
RecordPtr
RootHint
Scavengin
g X
Secondary
Zone X
Setting
SigningKe
y
SigningKe
y-
Rollover
Statistics
StubZone
Trust
Anchor
TrustPoint X
Zone X X X
ZoneAgin
g
Zone
Delegatio
n
ZoneKey-
MasterRol
e X
ZoneSign
Zone
Transfer X
Zone
Unsign
He aquí un enlace que le permite acceder a numerosos ejemplos de scripts PowerShell
adaptados al rol DNS: http://gallery.technet.microsoft.com/scriptcenter/DNS-Server-
PowerShell-afc2142b

l. Mejoras aportadas por la versión R2 de Windows 2012

Las estadísticas de DNS están mucho más detalladas:

• El comando Get-DnsServerStatistics incluye una opción -ZoneName que permite

obtener las estadísticas específicas de esta zona.
• A nivel del servidor, las estadísticas incluyen la siguiente lista de secciones:
 CacheStatistics, DatabaseStatistics, DnssecStatistics, DsStatistics, ErrorStatistics,
MasterStatistics, MemoryStatistics, NetBiosStatistics, PacketStatistics,
PrivateStatistics, Query2Statistics, QueryStatistics, RecordStatistics,
RecursionStatistics, SecondaryStatistics, SecurityStatistics, TimeoutStatistics,
TimeStatistics, UpdateStatistics y WinsStatistics.

El soporte de zonas protegidas mediante DNSSEC se ve mejorada:

• El rol Key Master es, ahora, posible de configurar en las zonas multimaestro
gestionadas en los archivos (no integradas en Active Directory).
• Por otro lado, todas las tareas de administración pueden realizarse en el servidor
KeyMaster sin impactar a los demás DNS primarios que no son KeyMaster. Este
aislamiento permite realizar todas las operaciones de generación de claves,
almacenamiento, reemplazo y eliminación mientras que los demás servidores siguen
firmados en la zona mediante estas claves.

Se han agregado o extendido algunos comandos PowerShell:

• El comando Step-DnsServerSigningKeyRollover fuerza la renovación de KSK

mientras se espera una actualización de una firma de delegación.
• Se ha agregado la opción -root al comando add-DnsServerTrustAnchor para
recuperar los puntos de anclaje a partir de la URL indicada en la propiedad
RootTrustAnchorsURL. Observe que el comando Retrieve-
DnsServerRootTrustAnchor es un alias.
• La propiedad RootTrustAnchorURL forma parte de los elementos devueltos por
los comandos Get-DnsServerSetting y Set-DnsServerSetting.

2. La resolución WINS
En teoría, esta resolución no debería utilizarse más, salvo para integrar dominios antiguos
NT4. En la práctica, suele ser necesario (incluso muy práctico) para ciertas aplicaciones
heredades (Microsoft o no), y también para aplicaciones recientes tales como Exchange
2007 (en casos muy particulares).

Cuando se realiza una migración o cuando existe alguna duda sobre el funcionamiento de
ciertas aplicaciones, es habitual mantener uno o dos servidores WINS en el sitio central.
Las estaciones y servidores que utilizan este tipo de aplicación apuntarán, directamente,
sobre este servidor WINS. De este modo, es inútil mantener y replicar los servidores WINS
por toda la red.

a. Definición

WINS (Windows Internet Name Service) es un servicio basado en una base de datos Jet
que permite encontrar la dirección IP asociada a un nombre NetBIOS, y viceversa.
A diferencia de DNS, WINS mantiene información sobre los grupos de máquinas (llamados
grupos de trabajo cuando los ordenadores no pertenecen a un dominio), y también sobre los
usuarios conectados a dichas máquinas.

b. Instalación

La instalación de WINS se realiza agregando la funcionalidad correspondiente desde

PowerShell:

Install-WindowsFeature WINS

En este caso, el componente de administración no se instala automáticamente y puede

agregarse mediante el componente RSAT-WINS:

Install-WindowsFeature RSAT-WINS

En cualquier caso, es posible, también, agregar todas estas funcionalidades mediante el

Administrador del servidor.

c. Configuración

Salvo en casos excepcionales en los que hay que informar manualmente un nombre
(llamado estático) y una dirección IP, no es necesario configurar un servidor WINS, que
recibe dinámicamente toda la información necesaria desde los servidores y clientes que se
inscriben, de forma automática, en la base de datos.

La única particularidad consiste en replicar la base de datos entre dos servidores WINS, o
más, dependiendo del caso.

d. La replicación entre servidores WINS

La replicación WINS se basa en dos operaciones: la emisión y la extracción.

Para que una replicación WINS funcione en un sentido, es preciso que el servidor WINS
esté configurado para emitir las modificaciones que recibe hacia otro servidor WINS,
aunque también es necesario que el otro servidor WINS esté configurado para recuperar la
información que proviene del servidor emisor en cuestión.

Para que la replicación funcione bien en ambos sentidos entre dos servidores WINS, es
preciso que cada servidor esté configurado como Emisión/Extracción con el servidor
remoto.

e. ¿Cuándo y por qué utilizar WINS?

Preste atención, ya no hay que ver a WINS como una solución de resolución completa. A
día de hoy, DNS resulta imprescindible.
WINS es, simplemente, una solución que permite resolver problemas marginales de
funcionamiento de las aplicaciones o de acceso que sería demasiado complejo resolver de
otro modo.

El caso más común es una aplicación que utilice, únicamente, nombres de servidores
sencillos y relativamente cortos. Es el caso, por ejemplo, de algunas funcionalidades de
Exchange.

La instalación de un servicio WINS único, centralizado, que utilizarán únicamente

algunas estaciones o servidores que tengan una verdadera necesidad del mismo responde
perfectamente a este tipo de problemática.

Implementar la cuarentena de red

La cuarentena de red no es una verdadera solución de seguridad, sino un elemento cuyo
objetivo es mantener en un buen estado de mantenimiento los elementos presentes en la
red.

Este componente NAP (Network Access Protection) está, todavía, presente aunque
debería considerarse como obsoleto a partir de Windows Server 2012 R2. Microsoft
recomienda el uso de DirectAccess, que permite gestionar el equipo conectado "como" las
demás máquinas de la red (AV, WSUS...). La solución aportada por DirectAccess es, por
tanto, algo diferente al control de conformidad que proporciona el componente NAP.

1. Preparar el entorno común para los distintos tipos de cuarentena

El uso del cliente NAP se basa en el uso de un servidor NPS (Network Policy Server), es
decir, un servidor de directivas de red, que permite definir las restricciones deseadas.

Es, por lo tanto, necesario instalar y configurar este rol a partir del comando PowerShell:

Install-WindowsFeature NPAS-Policy-Server

La herramienta de administración Servidor NPS (Network Policy Server) no se instala

automáticamente, y debemos agregarla.

Install-WindowsFeature RSAT-NPAS

Una vez terminada la instalación, es necesario definir algunos puntos para las directivas
funcionales:

• Un sistema de validación (SHV), es decir, pruebas que deben realizarse para

verificar un sistema.
 Windows Server 2008 R2 y Windows Server 2012 autorizan, ahora, varias
configuraciones diferentes del sistema de validación. Una vez configurada la
directiva de mantenimiento de la integridad del sistema, es posible seleccionar una
de las configuraciones. Cada directiva de red puede configurarse para utilizar una o
varias directivas de mantenimiento.

• Un grupo de servidores de remedio: son los servidores que verán aquellas

estaciones que no cumplan con la conformidad para poder actualizarse y cumplir
con la política de seguridad configurada.
• Las directivas de mantenimiento, que se definen como SHVs, y serán
interpretadas.
• Directivas de red.

Es posible descargar el kit de integración ForeFront for NAP (gratuito) para disponer de
un sistema de validación complementario. Deben cargarse varios módulos en los equipos
en función del tipo de procesador (32 o 64 bits), el módulo SHV sobre los servidores NPS,
el módulo SHA sobre los clientes que se quiere validar (http://www.microsoft.com/en-
us/download/details.aspx?id=15887).

La primera etapa consiste en definir las pruebas que se quieren realizar sobre los equipos
que disponen de un cliente NAP, es decir, Windows XP SP3, Windows Vista o superior.

En la consola de administración del servidor NPS, NAP, seleccione el contenedor SHV.

Configure, a continuación, el sistema de validación provisto por defecto llamado

Validador de mantenimiento de seguridad de Windows y, a continuación, haga clic en
Configuración. El contenedor Configuración contiene una configuración llamada
Configuración predeterminada que podemos utilizar. Es posible, también, definir nuevas
configuraciones.

En el contenedor Códigos de error, se asume que si los programas de validación de

integridad no responden o no pueden responder, el cliente se clasificará como No
compatible. Aunque, para cada situación, es posible adaptar su estado mediante el menú
Propiedades de la carpeta Códigos de error.

Seleccione la configuración que desea personalizar y haga doble clic para acceder a las
distintas propiedades que se comprobarán. Observe que existe una pestaña para Windows
XP y otra para Windows Vista y versiones superiores.

En el marco de esta implementación de prueba, utilizaremos una configuración simplificada

basada en la existencia de un firewall.
La segunda etapa consiste en definir un grupo que contenga los servidores autorizados para
configurar la conformidad con las normas definidas en los grupos de servidores de
actualizaciones.
Las máquinas no conformes pueden conectarse con los servidores indicados si están
autorizadas las actualizaciones automáticas (que sirven como remedio) en la directiva de
red.

La tercera etapa consiste en crear al menos dos directivas de mantenimiento diferentes en

las directivas de mantenimiento.

Una para los equipos conformes:

Sólo aquellos validadores habilitados, es decir, los programas de mantenimiento instalados

y activos, forman parte de la regla de conformidad.
Si se crean varias configuraciones, seleccione aquella configuración que le interesa, entre
las propuestas y configuradas anteriormente.

Haga clic en Aceptar para terminar con esta primera directiva.

Una para los equipos no conformes:

Seleccione el mismo validador que para una máquina conforme, pero defina la regla como
El cliente no supera ninguna de las comprobaciones de SHV.
La cuarta etapa consiste en la creación de directivas de red.

Creación de la directiva de red para los equipos conformes:

Haga clic con el botón derecho en Directivas de red y, a continuación, en Nuevo en el

menú.

Llame a la directiva Acceso completo para los equipos conformes, y deje el tipo de red
como No especificada.

No especificada significa que la directiva se aplicará sea cual sea el tipo de acceso de red
utilizado.

En la pantalla Especificar condiciones, es obligatorio precisar sobre qué elementos se

aplicará la directiva, haga clic en Agregar.

Es posible aplicar múltiples condiciones, seleccione Directivas de manteni-miento.

Seleccione, en la lista, la opción Equipo conforme, y pase a la siguiente pantalla.

Indique Acceso concedido, ¡lo cual resulta evidente para las máquinas conformes!

No se requiere ninguna autenticación para este tipo de cuarentena, seleccione la opción

Realizar sólo comprobación de mantenimiento del equipo.

En la pantalla Configurar restricciones, no hay que modificar ningún valor.

En la pantalla Configurar opciones, se trata de aplicar una configuración (modificación)

del cliente de red. Aquí, en la sección NAP, se conserva el valor Permitir acceso completo
a la red.

Haga clic en Finalizar en la pantalla final que resume los valores de la directiva.

Creación de la directiva de red para los equipos no conformes:

Haga clic con el botón derecho en Directivas de red y, a continuación, seleccione Nueva
en el menú.
 Llame a la directiva Acceso completo para los equipos no conformes, deje el tipo de red
en No especificada como hizo con las máquinas conformes.

En la pantalla Especificar condiciones, debe precisar sobre qué equipos se aplica esta
directiva, haga clic en Agregar.

Es posible aplicar numerosas condiciones, seleccione Directivas de mantenimiento y, a

continuación, seleccione la directiva Máquina no conforme de la lista. Pase a la siguiente
pantalla.

Indique Acceso concedido. En efecto, incluso para aquellas máquinas no conformes, se

trata de una regla que va a autorizar un acceso a la red, ¡aunque sólo a aquellos elementos
autorizados!

No se requiere ninguna autenticación para este tipo de cuarentena, seleccione Realizar

sólo comprobación de mantenimiento del equipo como con las máquinas conformes.

En la pantalla Configurar restricciones, no modifique ningún valor.

En la pantalla Configurar opciones, se trata de aplicar una configuración (modificación)

del cliente de red. Aquí, en la sección NAP, seleccione Permitir acceso limitado.

La opción Permitir acceso limitado no debe aplicarse si no estamos seguros de los efectos
de la directiva. Es, a menudo, preferible autorizar un acceso completo en primer lugar y
utilizar el modo informe para hacerse una idea del conjunto de equipos que se verán
impactados.

Si queremos autorizar las actualizaciones automáticas (y, por tanto, habilitar los servidores
de conformidad), debemos marcar la opción Habilitar corrección automática de equipos
cliente.
 Haga clic en Configurar para especificar un Grupo de servidores de actualizaciones así
como la dirección de una página Web opcional que le dé instrucciones al usuario.
En los clientes restantes, cada servidor indicado en el grupo dispone de su propia ruta con
una máscara 255.255.255.255. Lógicamente, los demás servidores no están accesibles.

Haga clic en Finalizar en la pantalla final que resume el conjunto de parámetros de la

directiva.

Observe que, según el reparto de roles en los distintos servidores autorizados, las
actualizaciones automáticas pueden requerir un acceso completo.

El cliente Agente de Protección de acceso a redes debe estar habilitado sobre los puestos
cliente, es decir, el servicio debe estar configurado con arranque automático.

El Centro de seguridad debe estar habilitado, algo que puede llevarse a cabo mediante una
directiva.

La consola del cliente NAP (NAPCLCFG.MSC) permite verificar las restricciones

impuestas.

El comando Napstat permite verificar la conformidad respecto a las reglas establecidas.

2. Implementar NAP mediante DHCP

Una vez realizadas las preparaciones previas descritas anteriormente, quedan pocas etapas
para que NAP funcione sobre DHCP.

El ámbito DHCP debe, en primer lugar, estar habilitado para utilizar la seguridad basada en
NAP.

En las propiedades del ámbito, encontrará la pestaña Protección de acceso a redes.

Las máquinas que cumplen con los requisitos previos utilizan las opciones que ha
configurado en las Opciones estándar de DHCP (Clase de proveedor), para la Clase de
usuario predeterminada.

El perfil predeterminado de protección de acceso a redes se corresponde con la clase de

usuario Clase de protección de acceso a red predeterminada que está accesible en la
configuración avanzada de las propiedades del ámbito. Las máquinas no conformes
utilizarán las opciones definidas a nivel de esta clase.

Sólo es necesario definir las opciones deseadas, por ejemplo:

 • Un servidor DNS específico o que no permita alcanzar o resolver ciertos nombres.
• Una zona DNS ficticia o no, pero específica para identificar rápidamente las
máquinas no conformes.
• No informar ningún router, para impedir a la máquina acceder a secciones de la red
que se desean proteger.

Aparecen las opciones concretas con una clase de red específica.

Ahora, podemos habilitar la directiva de cuarentena de DHCP, bien utilizando una

directiva, o bien directamente en la herramienta de administración del cliente NAP que
podemos abrir mediante el comando NAPCLCFG.MSC.

En caso de que se detenga el servicio de Firewall de Windows, la estación de trabajo no

estará conforme con las reglas definidas. Si están autorizadas las actualizaciones
automáticas, y el servidor de resolución de problemas es accesible, las reparaciones se
realizan de manera inmediata. En nuestro caso, el reinicio inmediato del servicio Firewall
permite devolver a la máquina a la conformidad.
Utilice el comando napstat.exe para verificar el estado de conformidad de las estaciones
respecto a las directivas en uso. Existe un icono situado en el área de notificación que
permanece ahí hasta que cerremos la herramienta.

La cuarentena de red basada en DHCP es la más débil de las protecciones posibles, y es

fácilmente eludible por parte de cualquier usuario que tenga permisos de administrador
local sobre su equipo.

3. Implementación de NAP mediante IPsec

a. Instalación del servicio Autoridad HRA

Esta seguridad requiere la instalación del servicio Autoridad HRA (Health Registration
Authority) a través del siguiente comando PowerShell:

Install-WindowsFeature NPAS-Health

Es preciso instalar una entidad emisora de certificados de tipo Entreprise si no existe

ningún otro sistema de distribución de claves (PKI). El uso del rol Microsoft
correspondiente simplifica enormemente la tarea. Se recomienda encarecidamente utilizar
la interfaz gráfica y, a continuación, utilizar el asistente de creación del certificado raíz.

Para limitar la aplicación de la cuarentena de red basada en IPsec, es prudente crear grupos
de equipos para cada categoría.

• Equipos clientes de NAP IPsec: es decir, todas aquellas estaciones que deban
cumplir con las normas de seguridad (CLIENTES-NAP).
• Aquellos servidores llamados "de frontera" (Boundary) que reciben,
automáticamente, un certificado de salud y que sirven para autentificar a los
clientes. Los controladores de dominio, los servidores DNS y los servidores de
reparación deben formar parte de este grupo (SERVIDORES-FRONTERA).
• Los equipos protegidos por NAP IPsec: reciben, también, automáticamente un
certificado y sólo autorizan la conexión desde las máquinas autentificadas
(SERVIDORES-NAP).

Cada máquina (estación o servidor) debe poder recibir un certificado. Ahora bien, el
certificado emitido por defecto a las estaciones no contiene la directiva de autenticación
adecuada.

Cree un nuevo certificado Autenticación de estación de trabajo duplicando el modelo

existente a partir de la consola de Plantillas de certificado que podemos abrir
directamente mediante el comando certtmpl.msc.

Tras la duplicación, seleccione la compatibilidad Windows 2003 o Windows 2008. En

cualquier caso, es necesario disponer de una entidad emisora de certificados de tipo
Enterprise para que la distribución de certificados sea automática.
 Aproveche para modificar algunos parámetros, tales como la duración de la validez de los
certificados.

Dé nombre al certificado, modifique el periodo de validez y publíquelo en Active

Directory.

Los servidores implicados en la validación tienen, efectivamente, un certificado válido

durante dos años. En cambio, los equipos que soliciten la validación obtendrán un
certificado con un tiempo de vida de cuatro horas.

En la pestaña Extensiones, seleccione Directivas de aplicación y agregue la directiva

Autenticación del agente SHA (System Health).

En la pestaña Seguridad, agregue los grupos de servidores de tipo frontera y los servidores
protegidos, y asigne los permisos Inscribirse e Inscripción automática.
 En la consola Entidad emisora de certificados, en el contenedor de las plantillas de
certificado, haga clic con el botón derecho y seleccione Plantilla de certificado que se va
a emitir y, a continuación, la plantilla Autenticación de sistemas sanos.

Como la validación de los clientes requiere, de manera regular, certificados de buena

salud, es importante verificar que el módulo de directiva (sobre el certificado raíz) esté
configurado a Emitir certificado automáticamente.

Los clientes deben configurarse para solicitar automáticamente los certificados. En la

herramienta GPMC (Administración de directivas de grupo), configure la petición de
certificados automática en la Default Domain Policy. Este parámetro se encuentra en la
sección Configuración de Windows - Configuración de seguridad - Directivas de clave
pública.

Haga clic con el botón derecho en Configuración del equipo - Configuración de

Windows - Configuración de seguridad - Directivas de clave pública - Configuración
de la solicitud de certificados automática - en la directiva Cliente de servicios de
servidor de certificados - Inscripción automática.

Los parámetros de inscripción y renovación automática están habilitados por defecto en las
Propiedades.

La cuenta SERVICIO DE RED (si la CA y la HRA se encuentran en la misma máquina) o

el equipo sobre el que se encuentra instalado el sistema de validación (HRA) deben obtener
los siguientes permisos:
El siguiente comando permite al sistema validador solicitar los certificados con una
duración distinta a la validez de dos años definida e impuesta en el modelo.

certutil -setreg policy\editflags +EditF_attributeEndDate

b. Configuración del sistema de validación (HRA)

En el menú Inicio, busque y ejecute la herramienta Autoridad HRA.

Es posible, también, abrir una consola MMC y agregar el componente Autoridad HRA
(Health Registration Authority).

Agregue la entidad emisora de certificados a partir de Active Directory.

Modifique las propiedades de la entidad emisora de certificados, en particular para validar

la entidad emisora de certificados de la empresa, y las plantillas de certificado que se van a
utilizar.
En la herramienta de administración NPS, debe estar deshabilitada la reparación
automática. Esto puede configurarse en los parámetros del validador de mantenimiento del
sistema dentro de la configuración por defecto. La opción Configuración de
Actualizaciones automáticas debe estar desmarcada.

En el puesto cliente, para habilitar IPsec, es necesario hacerlo desde la línea de comandos
mediante la siguiente instrucción:

netsh nap client set enforcement ID =79619

Cada cumplimiento (Enforcement) dispone de un identificador específico:

• DHCP = 79617
• RAS = 79618
• IPsec = 79619
• TS Gateway = 79621
• EAP = 79623

Observe que si el equipo no está conforme, el certificado que reciba se verá invalidado
inmediatamente sin esperar las cuatro horas.
De momento, no se impone ningún cumplimiento salvo el hecho de disponer de un
certificado. Estos cumplimientos los aportan tres directivas basadas en los grupos de
seguridad creados al principio.

c. Definición de las reglas de seguridad de conexión

Estas directivas pueden definirse en la raíz del dominio siempre que se implemente un
filtrado sobre los grupos de seguridad.

Los servidores frontera deben solicitar, pero no imponer, certificados válidos. Los
servidores protegidos y los puestos cliente deben utilizar certificados, aunque es preferible
utilizar directivas diferentes para asociar una configuración específica para los clientes
(URL de configuración HRA).

He aquí la directiva que debe implementar sobre los servidores frontera (Boundary):

En Configuración del equipo - Directivas - Configuración de Windows -

Configuración de seguridad - Firewall de Windows con seguridad avanzada - Firewall
de Windows con seguridad avanzada - LDAP... cree una nueva regla de seguridad en
Reglas de seguridad de conexión, y seleccione Aislamiento.
 Seleccione Solicitar autenticación para conexiones entrantes y salientes y, a
continuación, el método de autenticación modo avanzado.

Haga clic en Personalizar.

Haga clic en Agregar en la sección Primera autenticación.

 Seleccione el modo Certificado de equipo y, a continuación, Examinar para indicar su
entidad emisora de certificados. Haga clic en Aceptar solo certificados de
mantenimiento.
 Haga clic en Aceptar para terminar de personalizar los modos de autenticación y, a
continuación, en Siguiente.

Deje marcados todos los perfiles que se aplicarán: Dominio, Privado, Público.

Dé nombre a la regla REGLA NAP IPSEC Frontera.

En la pestaña Ámbito de la directiva, agregue un filtrado de seguridad para el grupo

Servidores IPSEC de Frontera (SERVIDORES-FRONTERA) y elimine el grupo por
defecto Usuarios autenticados.

He aquí la nueva directiva que debe implementarse en los clientes y los servidores
protegidos.

Aunque la configuración sea idéntica, cree dos directivas independientes para poder
habilitar y modificar la configuración según las necesidades.

Utilice el mismo procedimiento que con los servidores frontera, seleccionando la opción
Requerir autenticación para las conexiones entrantes y solicitar autenticación para las
conexiones salientes, en lugar de Solicitar.
 Indique su entidad emisora de certificados de dominio, y marque la opción Sólo aceptar
certificados de mantenimiento.

Deje marcados todos los perfiles que se aplicarán: Dominio, Privado, Público.

Dé nombre a esta regla REGLA NAP IPSEC Client.

En la pestaña Ámbito de la directiva, agregue un filtrado de seguridad para el grupo

Clientes IPSEC (CLIENTES-NAP).

Se creará una directiva idéntica para los servidores que se quieren proteger.

Utilizando la instrucción ping -t sobre un servidor frontera o un servidor protegido, será

posible verificar la autenticación por certificado mediante la herramienta Firewall de
Windows con seguridad avanzada.

Se utiliza una asociación de seguridad basada en los certificados para llevar a cabo la
comunicación.

Efectivamente, esta es tan solo una posibilidad de implementación de seguridad basada en

la cuarentena de IPsec. Sería prudente maquetar el conjunto de la red antes de implementar
dichos cambios sobre una red en producción.

Preste atención, el hecho de imponer una autenticación hace que no sea posible conectarse
con máquinas que no tengan un certificado válido o que no cumplan la directiva de
seguridad para los sistemas conformes.

4. Implementar NAP sobre 802.1x

802.1X estaba, hasta el momento, reservado principalmente a los puntos de acceso

inalámbricos.

Actualmente, NAP permite, también, utilizar fácilmente esta autenticación directamente

sobre la red local. Esta implementación supone el uso de RADIUS para procesar la
solicitud, y la creación de una VLAN específica mediante un switch que acepte VLAN.
Son necesarios, por tanto, tres elementos:

• un servidor de autenticación;
• un agente de autenticación (switch o punto de acceso inalámbrico) ;
• el solicitante.

El cliente solicitante utiliza el protocolo EAP (EAP over LAN) para enviar la solicitud al
agente de autenticación (Pass-Through). El agente Pass-Through puede, a continuación,
consultar al servidor RADIUS para validar o no la conexión.

A partir de Windows Server 2008/2008 R2/2012, el servidor NPS remplaza la tecnología

IAS, aunque sigue utilizando el protocolo RADIUS para comunicarse. Si los clientes
cumplen con la conformidad relativa a la seguridad demandada, se les asigna una VLAN
específica o un filtrado por IP.

a) Configuración del switch (o punto de acceso):

He aquí la configuración de las distintas VLAN que deben configurarse en el switch (o

punto de acceso) para llevar a cabo nuestro ejemplo:

• VLAN ID 1 es la VLAN por defecto.

• VLAN ID 2 para las máquinas que no cumplen con la conformidad.
• VLAN ID 3 para las máquinas conformes.

Es necesario deshabilitar la comunicación inter-VLAN entre las VLAN 2 y 3.

Los puertos del switch utilizados para conectar el servidor NPS y los controladores de
dominio deben configurarse para no imponer la autenticación 802.1X. Todas las solicitudes
de autenticación del switch deben redirigirse hacia el servidor NPS.

b) En el bosque Active Directory, será preciso tener una entidad emisora de certificados
raíz de tipo Enterprise. El servidor NPS debe haber recibido un certificado de equipo y el
certificado raíz deberá agregarse a las principales entidades de confianza en todas las
máquinas.

Es posible crear un grupo de seguridad específico llamado Clientes NAP 802.1X para los
clientes NAP 802.1X, con el objetivo de restringir la aplicación de las directivas en las
máquinas que pertenezcan a este grupo.

La mayoría de elementos (Controladores de dominio, Servidor NPS, Entidad emisora de

certificados, Administración de directivas de grupo) pueden instalarse sobre el mismo
servidor, lo cual nos simplificará en gran medida la configuración de las pruebas. Si los
sistemas de cuarentena anteriores se han probado con éxito, todos los elementos necesarios
se encuentran ya instalados. En cambio, será preferible, en primer lugar, eliminar o
deshabilitar las directivas de grupo y las directivas de red que ya estén configuradas.
c) Configuración del servidor NPS como servidor de directivas de mantenimiento
(Health Policy Server):

Lo más sencillo es utilizar el asistente de configuración de NAP.

A partir de la raíz (NPS Local):

Haga clic en Configurar NAP en la sección Configuración estándar.

En Método de conexión de red, seleccione IEE 802.1X (cableada).

En los Clientes RADIUS, agregue la dirección IP o los switch RADIUS, así como el
secreto compartido que utilizará el cliente RADIUS.

En la pantalla Grupos de equipos y usuarios, no indique nada.

En lo relativo al método de autenticación, haga clic en Seleccionar, seleccione el

certificado (válido) emitido por el servidor que hospeda NPS y valide el modo PEAP-MS-
CHAP v2.

A continuación, debe configurar las dos redes locales virtuales (VLAN) tal y como se
indica a continuación, haciendo clic en Configurar.

La VLAN de la red de organización que se obtiene modificando el atributo estándar:

Debe agregarse un atributo (tag) específico:
La VLAN de la red restringida:
El atributo indicado Tunnel-Tag debe tener el valor 1.

En Definir directivas de mantenimiento de NAP, seleccione el sistema de validación

deseado, es decir, Validador de mantenimiento de seguridad de Windows, en nuestro
caso.
 Por defecto, el acceso completo a la red no está permitido para aquellos clientes no
conformes.

Todas las directivas se crean en la pantalla final haciendo clic en Finalizar.

d) Una vez finalizada la configuración a través del asistente, es interesante verificar cada
parámetro.

• Para realizar pruebas, el validador de mantenimiento de seguridad de Windows está

configurado para verificar únicamente el arranque del servicio de firewall.
• Las directivas de control de integridad (definir los validadores a utilizar).
• Las directivas de solicitud de conexión (verifique el orden de ejecución, observe
que la directiva NAP 802.1X sólo se aplica a conexiones de tipo Ethernet).
• Las directivas de red y, en particular, la directiva NAP 802.1X (cableada) No
compatible con NAP.

En efecto, tras la implementación de directivas de red, es primordial considerar la

existencia de máquinas Unix, Linux, Mac u otros, que no serán compatibles con NAP.
Estas máquinas deben seguir funcionando y comunicándose en la red, bien a partir de
exclusiones, o bien a partir de reglas específicas.
e) Para aquellos clientes NAP declarados como conformes, es necesario que los clientes
tengan la configuración adaptada. Para las máquinas integradas en el dominio, es lógico
utilizar directivas de grupo para forzar su correcta configuración.

He aquí los principales puntos de esta directiva:

Inicie automáticamente el servicio Agente de protección de acceso a redes.

Inicie automáticamente el servicio de Configuración automática de redes cableadas.

Habilite el Cliente de aplicación de cuarentena de EAP en la sección Configuración de

Windows- Configuración de seguridad - Protección de acceso a redes - Configuración
del cliente NAP - Clientes de cumplimiento.

Todos estos elementos pueden configurarse y automatizarse mediante una directiva.

Habilite el Centro de seguridad (solo equipos de dominio).

En Directivas de red cableada (IEEE 802.3), cree una directiva de red cableada con la
siguiente configuración:
 Haga clic en Propiedades y deje la opción Verificar la identidad del servidor validando
el certificado marcada, así como el método de autenticación EAP-MSCHAP versión 2
por defecto.

Desmarque la opción Habilitar reconexión rápida.

Marque la opción Aplicar Protección de acceso a redes.

Si queremos restringir esta directiva a un grupo de equipos concreto, retire el grupo

Usuarios autenticados en la sección Filtro de seguridad y agregue el grupo Clientes
NAP 802.1X que se ha creado al principio del procedimiento.

El botón Opciones avanzadas, en la pestaña Seguridad, permite acceder a una

configuración avanzada de 802.1X.
Preste atención, ¡no olvide integrar los clientes en este grupo!

Observe que estos parámetros pueden también configurarse de manera manual en el equipo
de trabajo, a condición de iniciar manualmente todos los servicios indicados en la directiva.

5. Conclusión

He aquí los resultados obtenidos con los distintos tipos de cuarentena.

Reglas Cliente correcto Cliente incorrecto

DHCP Dirección IP completa y acceso Rutas restringidas.
completo.
802.1X Acceso completo. Acceso a la VLAN restringida o a los
puertos autorizados.
IPsec Comunicación con cualquier Los elementos de confianza rechazan las
elemento de confianza. conexiones de sistemas no seguros.
La mejor seguridad es la que aporta 802.1X, seguida de la que ofrece IPsec, siendo DHCP
una barrera fácilmente franqueable.

En cualquier caso, la cuarentena de red no supone una seguridad absoluta, aunque mejora
enormemente la seguridad global favoreciendo la uniformidad a nivel del conjunto de la
red.

Existen otros tipos de cuarentena, aunque no se aplican a la totalidad de la red: se trata de la

cuarentena VPN, Acceso Remoto o Escritorio remoto.

Una de las principales restricciones ligadas al uso de la cuarentena consiste en utilizar

Windows XP SP3, Windows Vista, o superior, e iniciar los servicios de protección de red
necesarios. No obstante, es importante destacar que existen numerosos fabricantes que
ofrecen productos compatibles con NAP y existen, en particular, clientes NAP para Linux y
Mac.

La consola IPAM
La instalación de la funcionalidad IPAM (IP Address Management) tiene como objetivo
centralizar la administración del direccionamiento IP utilizando por el conjunto de
elementos dependientes de la infraestructura de red de Microsoft.

La herramienta está basada en una base de datos que permite administrar el descubrimiento,
la supervisión y la auditoría del direccionamiento. Esta base de datos conserva y registra la
información durante 3 años a partir de criterios tales como las direcciones IP, los nombres
de las máquinas o de los usuarios. A partir de esta información centralizada y agregada, la
consola permitirá modificar la configuración DNS, DHCP de manera remota teniendo en
cuenta todos los elementos necesarios.

Las funcionalidades que se tienen en cuenta son:

• DHCP
• DNS
• NPS

Esta consola no puede instalarse sobre un controlador de dominio. En cambio, sí es posible

instalar la consola de administración remota de IPAM sobre un controlador de dominio.

1. Ventajas de esta solución

Supervisar y administrar el direccionamiento IP sobre una red de empresa es un elemento

crítico en la administración de la red, conforme ésta se va haciendo más grande y compleja.

Muchos administradores utilizan, todavía, tablas o bases de datos personalizadas para

realizar un seguimiento manual del lugar y el uso de las direcciones IP. Generalmente, esto
consume bastante tiempo y suele producir errores de tipo humano. El servidor IPAM es una
herramienta que trata de dar solución, precisamente, a esta necesidad.

• En términos de planificación, IPAM remplaza herramientas manuales y scripts.

Permite evitar análisis costosos durante las expansiones o modificaciones del nivel
de actividad, o durante cambios de configuración o de tecnología.
• IPAM provee una plataforma de gestión única para la administración de las
direcciones IP de la red. Permite optimizar el uso y las capacidades de los servicios
DHCP y DNS en un entorno multi-sitio.
• IPAM permite trazar y prever el uso del conjunto de direcciones IP utilizadas. El
análisis de la tendencia general permitirá prever mejor ciertos incidentes.
• La auditoría realizada por IPAM ayuda a cubrir ciertas exigencias legales asociadas
a leyes tales como HIPAA y Sarbanes-Oxley, y provee informes que permiten
investigar y gestionar los cambios.

2. La arquitectura IPAM

Según el tamaño de la empresa y sus necesidades, el despliegue puede ser distribuido (un
servidor IPAM por sitio) o centralizado (un único servidor para toda la empresa), o incluso
una combinación de ambos. El límite de cobertura de un servidor IPAM es el bosque del
que forma parte.

Cada servidor IPAM se configura para administrar un ámbito específico. El ámbito puede
ser un dominio, un sitio y puede también limitarse a una lista filtrada de servidores
administrados. Un servidor IPAM puede, también, definirse en la copia de seguridad.

IPAM se comunica de manera regular con los controladores de dominio, los servidores
DNS y DHCP de la red que están en su dominio de cobertura. ¡Cada servidor debería
definirse como administrado o no administrado!

Para que un servidor pueda ser administrado por IPAM, es necesario configurar la
seguridad sobre dicho servidor, de modo que el servidor IPAM pueda realizar la
supervisión y modificar la configuración si fuera necesario. Las directivas de grupo son,
por tanto, la herramienta ideal para automatizar esta configuración según si el servidor está
administrado o no.

He aquí los protocolos que se utilizan según los servicios solicitados:

Protocolos de acceso Servicios

IPAM Server RPC WMI SMB WS-Mgmt DHCP
RPC WMI WS-Mgmt DNS
RPC WMI LDAP Controladores de dominio
RPC NPS
3. Instalación

Como con los demás elementos, la instalación puede hacerse de forma gráfica o mediante
comandos PowerShell.

Seleccione la funcionalidad Servidor de administración de direcciones IP (IPAM).

Valide la lista de las demás funcionalidades necesarias haciendo clic en Agregar

características.
 Observe que se necesita la base de datos interna de Windows para la primera instalación.
IPAM para Windows Server 2012 R2 soporta la migración de MS SQL, aunque no lo
propone, por defecto, durante su instalación. La migración se describe al final del módulo.

Haga clic en Siguiente.

Haga clic en Instalar.
 Instale la consola sobre otro servidor 2012 reservado para la administración o sobre el
controlador de dominio.

Si el componente IPAM se instala sobre un servidor, el componente se muestra en el

administrador del servidor, aunque sólo puede utilizarse si el cliente de gestión IPAM está
instalado. He aquí el comando que debe utilizar en este caso:

Install-WindowsFeature IPAM-Client-Feature

4. Configuración inicial

Acceda a la consola de administración, desde el administrador del servidor, que contiene la

herramienta IPAM/Información general.
La configuración se realiza en seis etapas.

Haga clic en Conectar con servidor IPAM (etapa número 1 del asistente).

Seleccione el servidor IPAM deseado y haga clic en Aceptar:

Haga clic en Aprovisionar el servidor IPAM (etapa número 2 del asistente) y, a

continuación, en Siguiente.
Seleccione la configuración básica que desea.
Seleccione el modo Microsoft SQL Server y, a continuación, indique:

• el nombre del servidor SQL

• el nombre de la base de datos SQL
• el puerto 1433
• y si es necesario crear el esquema en la base de datos.

A continuación, valide haciendo clic en Siguiente.

Observe que, utilizando la base de datos Interna, ahora es posible cambiar la ubicación de
dicha base de datos.

Configure la cuenta de acceso a SQL.

Para que el acceso y la creación de la base de datos se realicen correctamente, verifique
bien los siguientes puntos:

• El firewall debe autorizar la conexión sobre el puerto SQL (1433).

• El servidor IPAM debe tener permisos para conectarse.

La solución más sencilla consiste en crear un grupo de ACCESO_IPAM_SQL que

contenga al servidor IPAM en Active Directory y, a continuación, crear un login en SQL
para dicho grupo. Asigne, a continuación, el rol DbCreator a dicho login.

Seleccione el método de aprovisionamiento por directiva de grupo e indique el prefijo

seleccionado.
Observe el comando que tendrá que ejecutar mediante PowerShell:

Invoke-IpamGpoProvisioning

Si no utiliza las directivas de grupo propuestas, deberá configurar manualmente los

recursos compartidos, las reglas de firewall y los grupos de seguridad necesarios.

Haga clic en Aplicar para confirmar los parámetros.

Haga clic en Cerrar.
Cree las directivas mediante el comando Invoke-IpamGpoProvisioning.

Invoke-IpamGpoProvisioning -Domain MiEmpresa.Priv -GpoPrefixName IPAM

-force

¡Es importante especificar el mismo prefijo de dominio que el que ha indicado en el

asistente!

Las directivas se crean en la raíz del dominio correspondiente. Se aplican, por tanto, a todos
los servidores DNS, DHCP y DC (para acceder a la configuración de NPS) del dominio.
Idealmente, es posible desplazar la aplicación de dichas directivas sobre las unidades
organizativas que contengan únicamente los servidores correspondientes. No hay que
olvidar que los controladores de dominio pertenecen a un contenedor específico.

Haga clic en la etapa siguiente en Configurar detección de servidores (etapa número 3

del asistente).
 Haga clic en Agregar sobre cada dominio que quiera administrar y, a continuación, valide
haciendo clic en Aceptar.

Seleccione aquellos roles que desea descubrir.

Por defecto, los tres roles (DNS, DHCP, Controladores de dominio) están seleccionados, lo
cual resulta aconsejable. Haga clic en Aceptar.
Haga clic en Iniciar detección de servidores (etapa número 4 del asistente).

La ejecución de la tarea aparece hasta el final de la ejecución. El tráfico no será importante

en un primer momento, puesto que se trata de consultas LDAP en el directorio.

Haga clic en Seleccionar o agregar servidores para administrar y comprobar el acceso

de IPAM (etapa número 5 del asistente).
Es preciso definir el estado de gestión de cada servidor, es decir, si se desea administrarlo o
no. Es importante considerar bien la acción recomendada especificada junto a cada
servidor.

Seleccione el servidor o los servidores que desea configurar y, a continuación, haga clic
con el botón derecho para desplegar el siguiente menú contextual:

Haga clic en Editar servidor para obtener la siguiente pantalla:

Seleccione el modo Administrado y, a continuación, haga clic en Aceptar.

El retardo en el estado de la comunicación entre cada servidor y el servidor IPAM aparece

en la parte inferior de la página.
Existen varios elementos que podrían impedir una correcta comunicación sobre todos o
parte de los modos de acceso necesarios. Las directivas anteriores tienen como objetivo
autorizar IPAM a acceder a los servidores que posean los roles administrados.

Fuerce la aplicación de las directivas IPAM en cada servidor DC, DHCP o DNS mediante
el comando GPUPDATE /FORCE.

Reinicie los servicios DHCP y DNS.

A continuación, utilice la opción Actualizar el estado de acceso del servidor. Si todo va

bien, el servidor pasa al estado desbloqueado (icono verde).

Cada uno de los componentes debería pasar al estado desbloqueado:

Puede ocurrir, generalmente en Windows Server 2008 R2, que el acceso al servicio DHCP
se mantenga bloqueado. En este caso, verifique que el recurso compartido DHCPAUDIT
está creado correctamente en la carpeta C:\Windows\system32\ dhcp.

Haga clic en Recuperar datos de servidores administrados (etapa número 6 del

asistente).

Ahora, todas las funcionalidades IPAM se encuentran habilitadas.

5. Grupos utilizados por IPAM

Los siguientes grupos de seguridad se crean en la base de datos local de cuentas del
servidor IPAM:
 • Usuarios IPAM: los miembros de este grupo pueden ver toda la información
disponible en el inventario de servidores, el espacio de direccionamiento IP y el
análisis de la gestión de la consola IPAM así como los eventos operacionales IPAM
y DHCP que forman parte del catálogo de eventos, aunque no consultar la
información de seguimiento de las direcciones IP.
• Administradores IPAM MSM: los miembros del grupo Administradores MSM
(Multi-Server Management, gestión multiservidor) tienen los mismos permisos que
los usuarios IPAM y, además, pueden realizar tareas de gestión IPAM corrientes y
tareas de análisis y de administración.
• Administradores IPAM ASM: los miembros del grupo de Administradores ASM
(Address Space Management, gestión del espacio de direccionamiento) tienen los
mismos permisos que los usuarios IPAM y, además, pueden realizar tareas de
gestión IPAM corrientes así como tareas ligadas al espacio de direccionamiento IP.
• Administradores de auditoría IPAM IP: los miembros del grupo de
administradores de auditoría IPAM tienen los mismos privilegios que los usuarios
IPAM. Pueden realizar tareas de gestión IPAM corrientes y, además, ver la
información de seguimiento de las direcciones IP.
• Administradores IPAM: los miembros de este grupo tienen permisos sobre todos
los datos IPAM y pueden realizar cualquier tarea.

Existe un grupo de seguridad universal IPAMUG que se crea sobre el dominio tras la
primera instalación:

• Este grupo de equipos contiene el primer servidor IPAM instalado.

• Este grupo está incluido en los Event Log Readers y Usuarios DHCP del
dominio.

6. Tareas de administración cotidianas

Haga clic en el menú ACCIONES para obtener las operaciones habituales sobre las
direcciones IP:

Este menú Acciones contiene, también, las distintas tareas planificadas:

7. Limitaciones a tener en cuenta

• IPAM sólo soporta controladores de dominio Microsoft, y servidores

Windows 2008 o superior, integrados en un bosque mediante servicios DHCP, DNS
y NPS.

Esto quiere decir que la herramienta no gestiona la administración y la

configuración de elementos no-Microsoft de la red. No obstante, es posible
incluirlos en la base de datos.

• La instalación puede ahora utilizar la base de datos interna de Windows o una base
de datos ubicada en un servidor MS SQL 2008 o superior. Preste atención, la base
de datos integrada en Windows está limitada a 4 GB.
• Un servidor IPAM es capaz de gestionar hasta 150 servidores DHCP, 500
servidores DNS, 6000 ámbitos DHCP y 150 zonas DNS.
• La base de datos almacena tres años de información histórica (contratos, direcciones
MAC, conexiones y desconexiones de los usuarios) de hasta 100000 usuarios. No
existe ninguna estrategia de purgado automático, de modo que tendrá que hacerse
manualmente si fuera necesario.
• El análisis de tendencias sobre el uso de direcciones IP y de solicitudes sólo está
disponible para IPv4.
• No existe ningún procesamiento especial para direcciones de tipo IPv6
autoconfiguradas sin estado, ni sobre la migración de máquinas virtuales.
• IPAM no permite auditar direcciones IPv6 autoconfiguradas sobre un equipo que no
esté administrado para seguir un usuario.
• IPAM no verifica la coherencia de las direcciones IP con los routers y switchs de la
red.
8. La migración de IPAM a IPAM 2012 R2

La actualización de Windows Server 2012 a 2012 R2 conserva la funcionalidad IPAM, así

como la mayoría de componentes instalados y configurados. En cambio, la base de datos
IPAM debe actualizarse para poder continuar siendo administrada y, principalmente,
aprovechar las nuevas funcionalidades.

Al arrancar la herramienta de la consola IPAM, tras la conexión, aparece la opción

Actualizar el servidor IPAM.

Haga clic en Actualizar el servidor IPAM.

Haga clic en Siguiente para iniciar el asistente.

El asistente realiza una verificación de la base de datos. Una vez terminada, haga clic en
Siguiente.
Haga clic en Actualizar.
Haga clic, a continuación, en Cerrar en el resumen de tareas de actualización.

Aparece la visualización clásica de todas las opciones de administración de la consola

IPAM:

9. Los roles de IPAM 2012 R2

La gestión de los roles se ve mejorada con Windows Server 2012 R2, y es mucho más
granular.

La administración se divide, ahora, en:

• Roles: conjunto de acciones autorizadas para usuarios concretos.

 • Ámbitos de acceso: conjunto de objetos o de recursos autorizados a los usuarios.

Por defecto, existe un único ámbito llamado Global, que incluye todos los recursos.

• Directivas de acceso: combinación de roles y de ámbitos de acceso.

La delegación granular de la administración consiste en:

• Agregar roles suplementarios si es necesario.

• Crear y nombrar ámbitos y, a continuación, asociar estos ámbitos a los objetos
correspondientes.
• Agregar usuarios o grupos autorizados, asociarles su rol y su ámbito de acceso.

a. La lista de roles integrados

He aquí la lista de roles que se ofrecen por defecto. Cabe destacar que los roles no se
corresponden, exactamente, con los grupos creados por IPAM. Además, es posible crear
nuestros propios roles:

• Rol Administrador ASM IPAM:

Este rol integrado provee las autorizaciones requeridas para gestionar

completamente los espacios de direccionamiento IP, los bloques de direcciones IP,
las subredes de direcciones IP, los rangos de direcciones IP y las direcciones IP.

• Rol Administrador de ámbitos DHCP IPAM:

Este rol integrado provee los permisos requeridos para gestionar los ámbitos DHCP.

• Rol Administrador de reservas DHCP IPAM:

Este rol integrado provee los permisos requeridos para gestionar las reservas DHCP.

• Rol Administrador de registros de direcciones IP:

Este rol integrado provee los permisos requeridos para gestionar las direcciones IP,
en particular la búsqueda de direcciones IP no asignadas, así como la creación y la
eliminación de instancias de direcciones IP.

• Rol Administrador de registros DNS:

Este rol integrado provee los permisos requeridos para gestionar los registros de
recursos DNS.

• Rol Administrador DHCP IPAM:

 Este rol integrado provee los permisos requeridos para gestionar completamente un
servidor DHCP, así como sus ámbitos DHCP, sus filtros de direcciones MAC, sus
directivas DHCP y sus reservas DHCP.

• Rol Administrador IPAM:

Este rol integrado provee los permisos especificados por los roles Administrador
ASM IPAM y Administrador MSM IPAM, además de los permisos necesarios para
gestionar ámbitos de acceso, directivas de acceso y grupos lógicos.

• Rol Administrador MSM IPAM:

Este rol integrado provee los permisos requeridos para gestionar completamente los
servidores DHCP, los ámbitos globales DHCP, los ámbitos DHCP, los filtros de
direcciones MAC, las directivas DHCP, las zonas DNS y los registros de recursos
DNS.

b. Creación de un rol personalizado

Si se quiere, por ejemplo, delegar la modificación de registros DNS en la zona DNS

pública únicamente, he aquí las etapas que debe seguir.

Para crear un rol personalizado, basta con ir a la carpeta IPAM/CONTROL DE

ACCESO/Roles de la consola.

El botón TAREAS (ubicado arriba a la derecha) permite abrir el asistente para Agregar un
rol de usuario.
Escriba un Nombre y, opcionalmente, una Descripción del rol.

Seleccione, a continuación, todas las operaciones autorizadas para este rol.

c. Creación de un ámbito de acceso

Para crear un ámbito personalizado, basta con ir al a carpeta IPAM/CONTROL DE

ACCESO/Ámbito de acceso en la consola.

El botón TAREAS (ubicado arriba a la derecha) permite abrir el asistente Agregar ámbito
de acceso.
El ámbito puede ubicarse directamente bajo el ámbito Global, o en otro nivel si se desea
crear una arborescencia más compleja.
A continuación es posible asociar este ámbito a los recursos u objetos correspondientes.

Por defecto, todos los recursos dependen del ámbito Global.

Si desea delegar la zona pública MiEmpresa.es, haga clic en el botón derecho en la zona
miempresa.es y seleccione la opción definir ámbito de acceso.

Seleccione el ámbito de acceso deseado.

d. Definición de las directivas de acceso

Hasta ahora, no ha tenido lugar, realmente, ninguna delegación. Agregando los usuarios o
los grupos es como se otorgan los permisos reales de administración.

Vaya a IPAM/CONTROL DE ACCESO/Directivas de acceso.

Haga clic en el botón TAREAS y, a continuación, seleccione Agregar directiva de

acceso.

Seleccione el grupo o el usuario desde el directorio.

 Haga clic, a continuación, en Configuración de acceso para poder agregar combinaciones
de roles y ámbitos.
Haga clic en el botón Agregar configuración y, a continuación, en Aplicar.

Como con Exchange, y con muchos otros productos, la tendencia es hacia la granularidad
en la delegación de la administración mediante el uso de roles personalizados que gestionan
un ámbito. El objetivo es no asignar más que aquellos permisos necesarios relativos a las
acciones y ámbitos deseados.

El protocolo IPv6
Poco a poco, la tecnología IPv6 se va introduciendo en nuestro día a día. Esto es así debido
a la inercia que adquiere todo en Internet, porque ya no existe otra opción en ciertas zonas
de Internet (África, Asia...) y, también, para conseguir una mejora progresiva a la hora de
adquirir nuevos dispositivos y componentes.
Microsoft está actualizando, de manera progresiva, todos sus productos para soportar los
estándares de la industria. Esto incluye a IPv6, que será el nuevo protocolo obligatorio en el
acceso a Internet, y que supone una evolución de IPv4, protocolo que se utiliza a día de
hoy.

IPv6 se concibe para dar respuesta a numerosos problemas vinculados a IPv4: la

configuración automática, la movilidad y, sobre todo, la extensibilidad del espacio de
direccionamiento, que se hace casi infinito en Internet.

La funcionalidad principal de IPv6 es el uso de direcciones de 128 bits (en lugar de

direcciones de 32 bits), lo cual permite explotar hasta 3.4 × 1038 direcciones, más que
suficiente para gestionar las necesidades actuales y futuras.

IPv6 no asegura la compatibilidad hacia atrás con IPv4. Un nodo configurado

exclusivamente con IPv6 no puede comunicarse con un nodo que esté configurado,
exclusivamente, en IPv4. Como consecuencia de ello, debe producirse una transición
progresiva desde una red que funcione exclusivamente en IPv4 hacia una red que tenga en
cuenta al mismo tiempo IPv4 e IPv6 de forma nativa. A medida que el número de nodos y
de aplicaciones de la red que tengan en cuenta IPv6 aumente, el tráfico de su red basculará,
con el tiempo, de un uso mayoritario de IPv4 a un uso mayoritario de IPv6. Se trata, por
tanto, del objetivo de transición hacia IPv6.

Dado que actualmente prevalecen los nodos, dispositivos, aplicaciones y sistemas de

gestión de red que utilizan únicamente IPv4, salvo algunas excepciones, el objetivo de su
estrategia de transición hacia IPv6 consistirá en migran una red que trabaja exclusivamente
en IPv4 hacia una red que tenga en cuenta, al mismo tiempo, el tráfico IPv4 y el tráfico
IPv6, y no migrar hacia una red que trabaje exclusivamente con IPv6.

El objetivo de esta parte no es presentar la integridad de IPv6 (lo que podría llevarnos
varios libros), sino disponer de los comandos básicos de referencia para comprender y
adaptarse al nuevo entorno.

1. Tabla de equivalencia entre IPv4 e IPv6

A continuación se presentan algunos conceptos IPv4 y su equivalente en Ipv6:

Direccionamiento IPv4 Direccionamiento IPv6

Clases de direcciones 5 Clases: A a E. No existe una equivalencia en
de Internet IPv6
Direcciones MultiCast 224.0.0.0/4 FF00::/8
Direcciones de Todos los bits a 1 No se aplica en IPv6
BroadCast (255...)
Dirección no 0.0.0.0 ::
especificada
Dirección de bucle 127.0.0.1 ::1
local
Direcciones IP públicas Clases A a C salvo las Direcciones de tipo Global
clases privadas. unicast.
Direcciones IP 10.0.0.0/8, Direcciones de Site-local
privadas 172.16.0.0/12, ULA=FC00::/7
192.168.0.0/16
Direcciones 169.254.0.0/16 Direcciones de Link-local
autoconfiguradas FE80::/64
(APIPA)
Representación en Notación decimal Notación hexadecimal separada
modo Texto separada por puntos. por los símbolos ":", se eliminan
los ceros correspondientes a la
compresión.

Las direcciones compatibles

IPv4 se representan en notación
decimal con puntos (para los 4
últimos valores).

Ejemplo ::ffff:172.16.1.1
Representación de las Notación decimal o Únicamente la longitud del
redes y subredes longitud del prefijo. prefijo.
(Máscara de red)
Resolución de nombres Registro de tipo (A) Registro de tipo (AAAA) que
DNS que contiene una contiene una dirección IPv6.
dirección IPv4.
Resolución DNS Dominio de tipo IN- Dominio de tipo IP6.ARPA.
inversa ADDR.ARPA.

2. Comandos principales

La mayoría de comandos son idénticos y funcionan a la vez sobre IPv4 e IPv6, por ejemplo
los comandos ipconfig /flushdns y /registerdns.

En algunos casos, se desea forzar el uso de un protocolo, por ejemplo, en la resolución de

nombres DNS.

Ping -4 DC2012

Envío de una consulta ’ping’ sobre DC2012.MiEmpresa.Priv [172.16.1.1] con 32 bytes de

datos:
Respuesta de 172.16.1.1: bytes=32 tiempo<1ms TTL=128

Ping -6 DC2012

Envío de una consulta ’ping’ sobre

DC2012.MiEmpresa.Priv[fe80::2d95:5a6:9b7d:f350%13] con 32 bytes de datos:

Respuesta de fe80::2d95:5a6:9b7d:f350%13: tiempo<1ms

Preste atención, en este resultado, la parte %13 no forma parte de la dirección IP, sino que
se corresponde con el número del itinerario (interfaz) utilizado.

Cuando una tarjeta de red soporta los dos protocolos IP, no es obligatorio configurar DHCP
sobre ambos protocolos. Cuando se quiere utilizar el protocolo IPv6, o bien que el
protocolo DHCP se base en IPv6, he aquí algunos comandos prácticos:

Ipconfig /release6

Adaptador Ethernet LAN:

Sufijo DNS específico para la conexión. . : MiEmpresa.Priv

Vínculo: dirección IPv6 local. . . . . . . . . . . : fe80::c969:22b:c9fc:8eb0%12

Dirección IPv4. . . . . . . . . . . . . . . . . . . . . . : 172.16.1.185

Máscara de subred. . . . . . . . . . . . . . . . . . . : 255.255.0.0

Pasarela por defecto. . . . . . . . . .. . . . . . . . . : 172.16.1.5

Ipconfig /renew6

Adaptador Ethernet LAN :

Sufijo DNS específico para la conexión. . . . . . : MiEmpresa.Priv

Dirección IPv6. . . . . . . . . . . . . . . . . . . . . . : fd00::afbe:52a9:314e:e25c

Vínculo: dirección IPv6 local. . . . . . . . . . . . . . . : fe80::c969:22b:c9fc:8eb0%12

Dirección IPv4. . . . . . . . . . . . . . . . . . . . . . . . . . : 172.16.1.185

Máscara de subred. . . . . . . . . . . . . . . . . . . . . . . : 255.255.0.0

Pasarela por defecto. . . . . . . . . . . . . . . . . . . . . . : 172.16.1.5

Observe que los comando /release y /renew sólo funcionan para IPv4.
3. La configuración de DHCP v6

Por defecto, la configuración de un servidor DHCP v6 no es obligatoria. Existen muchos

mecanismos para evitar la mayoría de conflictos entre sitios, y sobre cada sitio. La
asignación aleatoria de una parte del sitio entre millones de combinaciones posibles, y la
asignación aleatoria de direcciones voluntarias repartidas también sobre varios millones de
combinaciones hacen que los problemas sean meramente teóricos. En un sitio determinado,
la primera máquina define el direccionamiento único que se utilizará y, a continuación,
todas las demás máquinas se integran en el mismo direccionamiento. De hecho, la noción
de sitio o, para ser más exactos, de sub-sitio puede extraerse de las subredes IPv6 y
gestionarse, por defecto, mediante routers. Son ellos los encargados de configurar los
equipos de acuerdo con el prefijo de la subred correspondiente.

El inconveniente es que los servidores, en particular los servidores DNS y los controladores
de dominio, tendrán, también, una dirección algo compleja y difícil de memorizar. En el
marco de las directivas los scripts, o la configuración de ciertos componentes tales como
firewalls, puede ser deseable configurar uno mismo esta parte de DHCP. Sabiendo que se
puede escoger la dirección IP de su servidor DNS; de su proxy, será mucho más fácil
utilizar información fija en los scripts de conexión o de personalización del entorno.

Esta elección supone utilizar, voluntariamente, una configuración globalmente IPv6,

sabiendo que muchos dispositivos y aplicaciones no están, todavía, plenamente operativos
sobre este protocolo. Si bien el acceso de los clientes está, generalmente, bien administrado
en IPv6, es necesario en términos de administración y de funcionamiento de varias
aplicaciones importantes. Por ejemplo, en Exchange 2010, todos los protocolos de acceso
IMAP, POP, SMTP y MAPI están preparados para funcionar en IPv6. En cambio, IPv4
sigue siendo indispensable para establecer la comunicación entre servidores Exchange.

El funcionamiento de DHCPv6 está ligado a varios valores del entorno definidos sobre las
tarjetas de red. Cuando se habilita IPv6 en una tarjeta de red, la configuración se realiza,
por defecto, en modo StateLess (sin estado). Esto quiere decir que la configuración de la
dirección (flag llamado M), tiene el valor Disabled, y no está administrado. La
configuración de cada sitio la aportan los routers.

Si se instala DHCPv6, puede utilizarse para distribuir otros elementos de configuración

(por ejemplo, el servidor DNS, los sufijos de búsqueda...) a condición de que el atributo
Otra configuración con estado (flag llamado O) tenga el valor Enabled.

Si se habilitan ambos parámetros, la configuración llamada StateFull se basa

completamente en DHCP.

a. Configuración del cliente DHCPv6 sobre el servidor DHCP

He aquí la lista de comandos que debe utilizar para gestionar, de manera efectiva, un
direccionamiento IPv6 basado en DHCPv6.
En los siguientes comandos, LAN se corresponde con el nombre de la tarjeta de red.

netsh interface ipv6 set interface LAN routerdiscovery=dhcp

netsh interface ipv6 set interface LAN managedaddress=enabled
netsh interface ipv6 set interface LAN otherstateful=enabled

La opción routerdiscover puede valer Enabled si los routers están, efectivamente,

configurados de forma que puedan aportar los elementos necesarios.

Utilice el comando netsh interface ipv6 show interface LAN para confirmar las opciones en
curso.

b. Configuración del servicio DHCPv6

Abra la consola de administración de DHCP.

Seleccione la opción Ámbito nuevo en el menú IPv6.

Haga clic en Siguiente para iniciar el asistente.

Asigne un nombre al ámbito y haga clic en Siguiente.
Indique el prefijo de la red así como la posible preferencia.
El número de prefijo se debe escoger en el ámbito previsto para las redes privadas. Como
con las redes IPv4, ¡cada subred utiliza una parte fija que debe ser diferente!

La noción de preferencia (valor de 0 a 255) permite repartir/optimizar el comportamiento

de DHCP entre varios servidores. Un cliente DHCP preferirá un servidor que tenga la
misma preferencia que el que haya obtenido la vez anterior.

Agregue las zonas o direcciones IP que desea excluir.

En este caso, se escogen las 255 primeras direcciones, aunque podemos ser más generosos
sin que ello suponga un problema. Todos los servidores para los que se quiere asignar una
dirección IP fija, en particular servidores DNS y controladores de dominio, utilizarán,
principalmente, este tipo de dirección, que podremos informar en las opciones.

Indique la duración deseada para los contratos.

La duración preferida se corresponde con el retardo normal deseado de conservación de una
dirección.

La duración válida se corresponde con la duración máxima, si no existe una renovación del
contrato.

Habilite el ámbito y valide al final del asistente.

Configure, a continuación, las opciones del ámbito o la configuración a nivel de servidor.
Las opciones 23 (servidores DNS que se usarán para la resolución de nombres) y 24
(sufijos de búsqueda) son las opciones más interesantes que se pueden configurar.

Preste atención, la activación del modo IPv6 completo no tiene sino ventajas. La estación
recibe una dirección IPv6 aunque no funcionará plenamente en este modo sino tras haber
deshabilitado IPv4. Es preciso probar bien el conjunto antes de utilizarlo en una red de
producción.

4. Configuración DNS v6 de la zona de búsqueda inversa

La zona de búsqueda DNS directa no necesita ninguna configuración particular.

Los registros siguen la misma lógica que los registros clásicos.

He aquí las etapas que permiten crear una zona de búsqueda inversa de tipo IPv6:

Seleccione Zonas de búsqueda inversa y, a continuación, haga clic con el botón derecho
y seleccione Zona nueva... en el menú contextual.
Inicie el asistente Nueva zona y haga clic en Siguiente.
Seleccione el tipo de zona y haga clic en Siguiente.

Seleccione el tipo de replicación y haga clic en Siguiente.

Seleccione el tipo Zona de búsqueda inversa para IPv6.
Escriba el prefijo y el tamaño de la zona que se desea, en bits.

Teniendo en cuenta el número casi ilimitado de redes y de máquinas, nos limitaremos a una
red en la que queremos recibir y actualizar la información.

Seleccione el tipo de actualización y haga clic en Siguiente.

Finalice la creación de la zona haciendo clic en Finalizar.
Los registros DNS inversos aparecen una vez actualizada la zona, tarea que podemos forzar
mediante el comando ipconfig /registerdns.

5. TEREDO

Teredo es una tecnología que facilita la transición entre IPv6 e IPv4, permitiendo a las
aplicaciones IPv6 comunicarse a través de una red IPv4, incluso a través de redes que
utilizan NAT, es decir, traducción de direcciones. Esta capa es válida y está lista para
utilizarse en Windows Server 2012. DirectAccess puede utilizar esta solución, aunque
requiere dos direcciones IP públicas simultáneas consecutivas.

6. ISATAP

ISATAP (Intra-site Automatic Tunnel Addressing Protocol) es una tecnología de transición

definida en la RFC 4214. El interés de ISATAP consiste en utilizar la infraestructura IPv4
tal como es, sin ningún hardware suplementario ni modificación en la configuración de los
routers. Las nuevas aplicaciones que utilizan IPv6 pueden instalarse sobre IPv4 gracias a
esta capa suplementaria adaptándose al direccionamiento existente. Esta capa es, de hecho,
válida y está lista para utilizarse en Windows Server 2012.

El direccionamiento de ISATAP está compuesto por un prefijo, un valor fijo (0:5efe o

200:5efe) y termina con el direccionamiento IPv4.

64-bits_Unicast_Prefix:0:5efe:w.x.y.z

Este formato de dirección se utiliza cuando la dirección IPv4 es privada.

64-bits_Unicast_Prefix:200:5efe:w.x.y.z

Este formato de dirección se utiliza cuando la dirección IPv4 es pública.

Esta combinación permite utilizar IPv6 manteniendo sus equivalentes en IPv4.

Asociación de tarjetas de red en equipo
(Teaming)
Windows Server 2012 soporta ahora, de forma nativa, la combinación de varias tarjetas de
red. Las soluciones que daban antes los fabricantes suponían utilizar tarjetas de red
idénticas, del mismo proveedor, y no estaban soportadas directamente por Microsoft en
configuraciones de virtualización, soluciones que son exigentes, por lo general, en cuanto a
la necesidad de tarjetas de red.

La asociación (hasta 32 tarjetas de red) realiza, principalmente, la agregación del ancho de

banda y la tolerancia a fallos. Es posible asociar tarjetas de distintas velocidades, y crear,
por lo tanto, tantas asociaciones de tarjetas como sea necesario. El asistente propone
integrar las tarjetas físicas, o incluso las tarjetas virtuales creadas por Hyper-V. Esto resulta,
por otro lado, muy práctico cuando se desea desplazar tarjetas Hyper-V hacia nuevas
tarjetas de forma asociada. Este tipo de configuración no requiere la configuración de un
switch, y permite conectarse directamente a varios switchs diferentes, lo que mejora la
tolerancia a fallos. Por supuesto, es mejor utilizar tarjetas que dispongan de las mismas
propiedades.

He aquí el procedimiento de instalación, que es relativamente sencillo.

Abra el Administrador del servidor y sitúese en el Servidor local.

Puede, también, configurar asociaciones sobre un servidor remoto, aunque no se

recomienda.

Haga clic en Deshabilitado junto a la propiedad Formación de equipos de NIC.

 Agregue una asociación seleccionando la opción TAREAS en EQUIPOS y, a
continuación, Nuevo equipo.

Podemos, también, utilizar el menú TAREAS de una tarjeta disponible o en la sección

ADAPTADORES E INTERFACES.

Seleccione el nombre de la futura tarjeta, e indique las tarjetas que forman parte de la
asociación.
Haga clic en Propiedades adicionales para adaptar la configuración.
El modo de formación de equipos y el modo de equilibrio de carga no se pueden modificar
en una máquina virtual. En cambio, es posible definir una VLAN específica, o la tarjeta que
se deja como reserva.

El modo Independiente del conmutador funciona en cualquier caso, y no requiere ni un

switch particular, ni disponer de una configuración particular. Permite, también, conectar
cada tarjeta a switchs diferentes, con el objetivo de gestionar, de este modo, los fallos o el
reinicio de un switch.

Los otros dos modos de asociación requieren una configuración específica sobre los
switchs.

• El modo Formación de equipos estática obliga a identificar los enlaces que

componen la asociación a nivel de switch.
• El modo LACP es un protocolo estándar que permite negociar con los demás
equipos el funcionamiento óptimo agrupando los puertos configurados de la misma
manera (velocidad, modo Duplex, VLAN, Trunk).

El modo de equilibrio de carga por defecto se basa en una tabla hash de las direcciones, es
decir, un reparto basado en las direcciones IP recibidas. El otro modo propuesto se basa en
los puertos Hyper-V.

La asociación de tarjetas en una máquina virtual es útil solamente si no se ha creado

ninguna asociación sobre la máquina host. O bien asociamos dos tarjetas sobre el servidor
host, o bien asociamos dos tarjetas a la máquina virtual. Preste atención, es necesario
modificar las opciones de las tarjetas de red en la configuración de la máquina virtual.
La asociación de la tarjeta ha concluido.

La administración de las tarjetas permite habilitar, deshabilitar, agregar o eliminar nuevas

tarjetas.

Preste atención, la nueva tarjeta creada no recupera la configuración TCP/IP de ninguna de

las tarjetas anteriores, y se basa, por tanto, en DHCP. Las tarjetas que forman parte de la
asociación pierden su configuración específica. En cambio, cabe destacar que esta
configuración específica se recupera siempre que la tarjeta salga de la asociación.

Configure la nueva tarjeta llamada Team1.

Las tarjetas utilizadas para la asociación se marcarán como Habilitado. La tarjeta Team1
incluye, ahora, la configuración del protocolo TCP/IP.
Presentación de SMBv3
SMB 3.0 es la nueva versión, incluida desde Windows Server 2012 y Windows 8.
Observe que se llamaba SMB 2.2 durante su periodo Beta. La mayor parte de novedades
funcionan únicamente con estas versiones de Windows. Este nuevo protocolo debería
incluirse en la próxima versión de Samba 4.0, y ahora mismo se encuentra en desarrollo por
parte de NetApp y EMC.

1. Características de SMBv3

SMB 3.0 aporta las siguientes mejoras respecto a versiones anteriores del protocolo:

• Conmutación transparente de SMB (Transparent Failover - Node Fault Tolerance)

Un mismo recurso compartido puede proveerse por varios servidores o nodos

diferentes de un clúster. La parada de un nodo ya no implica una desconexión y una
reconexión.

• SMB multicanal

Todos los enlaces de red disponibles entre dos equipos serán evaluados y utilizados.
El número de conexiones establecidas está vinculado entre dos sistemas. Depende
del número de interfaces y del tipo de tarjeta. Una tarjeta que soporte RSS
autorizaría cuatro conexiones, con un máximo de ocho de manera global. Incluso un
sistema que posea una sola tarjeta puede utilizar esta funcionalidad y repartir su
actividad entre varios procesadores.

• Agrupaciones de servidores SMB (ScaleOut)

Esta funcionalidad supone una ventaja respecto a las dos anteriores (Failover y
Multicanal). Cuando un recurso compartido SMB 3.0 se instala en un clúster, todos
los nodos y todas las tarjetas de red se utilizan para optimizar la transferencia de
datos.

• SMB directo

Esta funcionalidad permite a los equipos que poseen tarjetas de red RDMA
transferir datos de memoria a memoria entre ellos sin tener que pasar por el
procesador.

• Encriptación SMB

Todos los datos enviados por SMB 3.0 entre los equipos se encriptan,
automáticamente, por defecto.
 • VSS sobre los recursos compartidos de archivos SMB

Los recursos compartidos pueden, en lo sucesivo, salvaguardarse gracias a una

herramienta compatible con VSS. El servicio de instantáneas de Microsoft realizará,
bajo demanda, los snapshots necesarios.

• Concesión de directorio SMB (SMB directory leasing)

SMB aloja en caché todos los metadatos de los documentos accesibles, en particular
a través de BranchCache. Esto disminuye el número de consultas de ida y vuelta y
el tiempo de latencia en el acceso inicial a las propiedades de un archivo.

• PowerShell para SMB

Todas las propiedades de SMB son, ahora, accesibles y configurables a partir de

comandos PowerShell.

2. Caso práctico: implementar el modo Multicanal

a. Requisitos previos

Para probar y utilizar SMB 3.0 es necesario disponer de, al menos, dos equipos con
Windows Server 2012/2012 R2 o Windows 8/8.1. Para aprovecharlo plenamente, hace
falta:

• Varias tarjetas de red.

• O, al menos, una tarjeta que soporte el modo RSS (Receive Side Scaling).
• O, al menos, una tarjeta que soporte el modo RDMA (Remote Direct Memory
Access).

Observe que las máquinas virtuales (Windows 8/8.1 o Windows Server 2012/2012 R2)
creadas por Hyper-V soportan, de forma nativa, RSS. Esto resulta muy práctico, y explica
también, en parte, las transmisiones tan rápidas entre sistemas hospedados en un mismo
servidor host.

Cada tarjeta clásica autoriza una conexión TCP.

Cada tarjeta RDMA autoriza dos conexiones RDMA.

Cada tarjeta que soporta RSS autoriza un máximo de cuatro conexiones TCP.

b. Comandos PowerShell

Verificar la configuración del servidor:

Get-SmbServerConfiguration
AnnounceServer : False
AsynchronousCredits : 64
AutoShareServer : True
AutoShareWorkstation : True
CachedOpenLimit : 5
AnnounceComment :
EnableDownlevelTimewarp : False
EnableLeasing : True
EnableMultiChannel : True
EnableStrictNameChecking : True
AutoDisconnectTimeout : 0
DurableHandleV2TimeoutInSeconds : 30
EnableAuthenticateUserSharing : False
EnableForcedLogoff : True
EnableOplocks : True
EnableSecuritySignature : False
ServerHidden : True
IrpStackSize : 15
KeepAliveTime : 2
MaxChannelPerSession : 32
MaxMpxCount : 50
MaxSessionPerConnection : 16384
MaxThreadsPerQueue : 20
MaxWorkItems : 1
NullSessionPipes :
NullSessionShares :
OplockBreakWait : 35
PendingClientTimeoutInSeconds : 120
RequireSecuritySignature : False
EnableSMB1Protocol : True
EnableSMB2Protocol : True
Smb2CreditsMax : 2048
Smb2CreditsMin : 128
SmbServerNameHardeningLevel : 0
TreatHostAsStableStorage : False
ValidateAliasNotCircular : True
ValidateShareScope : True
ValidateShareScopeNotAliased : True
ValidateTargetName : True
EncryptData : False
RejectUnencryptedAccess : True

Verificar la configuración del cliente:

Get-SmbClientConfiguration
ConnectionCountPerRssNetworkInterface : 4
DirectoryCacheEntriesMax : 16
DirectoryCacheEntrySizeMax : 65536
DirectoryCacheLifetime : 10
EnableBandwidthThrottling : True
EnableByteRangeLockingOnReadOnlyFiles : True
EnableLargeMtu : True
EnableMultiChannel : True
DormantFileLimit : 1023
EnableSecuritySignature : True
ExtendedSessionTimeout : 1000
FileInfoCacheEntriesMax : 64
FileInfoCacheLifetime : 10
FileNotFoundCacheEntriesMax : 128
FileNotFoundCacheLifetime : 5
KeepConn : 600
MaxCmds : 50
MaximumConnectionCountPerServer : 32
OplocksDisabled : False
RequireSecuritySignature : False
SessionTimeout : 60
UseOpportunisticLocking : True
WindowSizeThreshold : 8
Get-SmbServerNetworkInterfaceGet-SmbClientConfiguration
Scope Name Interface Index RSS Capable RDMA Capable Speed IpAddress
---------- --------- ----- --- ------- ------------ ----- ---------
* 12 True False 10 Gbps
172.16.1.184
* 12 True False 10 Gbps
fe80::4eb:1e38:4cf5...
* 12 True False 10 Gbps fec0::12
Get-SmbClientNetworkInterface| ft -auto
Interface Index RSS Capable RDMA Capable Speed IpAddresses Friendly
Name
--------------- ----------- ------------ ----- ----------- --------
-----
12 True False 10 Gbps {fec0::12,
fe80::4eb:1e38:4cf5:cfc0,
172.16.1.184} LAN
17 False False 0 bps
{fe80::5efe:172.16.1.184}
isatap.MiEmpresa.Priv
14 False False 0 bps {fe80::100:7f:fffe}
do Tunneling
Pseudo-Interface
Get-SmbMultichannelConnection |ft -auto
Server Name Selected Client IP Server IP Client Interface Index Server
Interface Index Client RSS Capable Client RDMA Capable
----------- -------- --------- --------- ---------------------- -----
----------------- ------------------ -------------------
dc2012 True 172.16.1.184 172.16.1.1 12 13 True False
Get-SmbMultichannelConnection |fl
ServerName : dc2012
Selected : True
Failed : False
FailureCount : 0
ClientInterfaceIndex : 12
ClientRSSCapable : True
ClientRdmaCapable : False
ClientLinkSpeed : 10 Gbps
ClientIpAddress : 172.16.1.184
ServerInterfaceIndex : 13
ServerRSSCapable : True
ServerRdmaCapable : False
ServerLinkSpeed : 10 Gbps
ServerIpAddress : 172.16.1.1
MaxChannels : 4
CurrentChannels : 1
Para comprobar el uso del modo multicanal, basta con copiar una pequeña herramienta.

PS C:\sources> copy .\admtsetup32.exe x:\

Get-SmbMultichannelConnection |fl
ServerName : dc2012
Selected : True
Failed : False
FailureCount : 0
ClientInterfaceIndex : 12
ClientRSSCapable : True
ClientRdmaCapable : False
ClientLinkSpeed : 10 Gbps
ClientIpAddress : 172.16.1.184
ServerInterfaceIndex : 13
ServerRSSCapable : True
ServerRdmaCapable : False
ServerLinkSpeed : 10 Gbps
ServerIpAddress : 172.16.1.1
MaxChannels : 4
CurrentChannels : 4

Observe que existe un máximo de cuatro canales activos simultáneamente entre ambos
equipos.

Por último, destacaremos que, incluso habiendo probado las reglas por defecto del grupo
para ser lo más favorables posibles en los casos más comunes, es posible parametrizar el
número de conexiones utilizadas mediante los siguientes comandos:

Set-SmbClientConfiguration -MaximumConnectionCountPerServer <n>

Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface <n>

También es posible personalizar el comportamiento del multicanal entre varios servidores

para forzar el uso de ciertas tarjetas y excluir algunas otras. Será preciso, entonces, utilizar
los siguientes comandos:

New-SmbMultichannelConstraint -ServerName <miservidor> -InterfaceAlias

<mitarjeta1>, <mitarjeta2>

En términos de optimización y de seguridad, deshabilitar el protocolo SMB 1.0 es más que

aconsejable:

Set-SmbServerConfiguration -EnableSMB1Protocol :$false

3. Observaciones

Destacaremos que la práctica totalidad de las ventajas de SMB 3.0 no requieren, en

realidad, ninguna configuración específica. Si los servidores poseen las tarjetas de red
adecuadas y la negociación se lleva a cabo con éxito, se utilizará la mejor opción de entre
las posibles. En un futuro próximo, serán los servidores Windows Server 2012 físicos o
virtuales los que aprovecharán un mejor rendimiento con una configuración que utilice los
roles y características de Hyper-V, el clustering, y el almacenamiento compartido de tipo
CSV basado en SMB 3.0. Los servidores de recursos compartidos tendrán que esperar,
seguramente, algo más de tiempo antes de que un gran número de estaciones de trabajo con
Windows 8 aprovechen estas nuevas mejoras de rendimiento.

4. Las modificaciones de SMB en Windows Server 2012 R2

La modificación más inmediata es SMB 1, que ya no es necesario en el funcionamiento

normal. Sigue estando activo, por defecto, aunque puede deshabilitarse, lo cual elimina
también el servicio llamado Explorador de red (Computer Browser) y el protocolo de
administración a distancia (Remote Administration Protocol).

El rendimiento se ve mejorado en el marco de los servidores de recursos compartidos

utilizados bajo la forma de granja de servidores (Scale-Out File server) y, por extensión,
aquellos que sirven para alojar a los servidores virtualizados. Cabe destacar:

• La conmutación automática de los clientes en función de los archivos compartidos y

no en función del servidor para obtener el mejor acceso posible.
• El uso de archivos VHDX compartidos en recursos compartidos CSV o SMB Scale-
Out para gestionar los clústers. La noción de Scale-out consiste en poder repartir la
carga sobre varios servidores.
• La migración Over SMB de máquinas virtuales utilizando SMB Direct y SMB
Multichannel, para una migración más rápida y con menor consumo de procesador.
• El soporte de varias instancias SMB diferentes sobre un servidor de archivos Scale-
Out: por defecto, una instancia administra los accesos estándar a los archivos
compartidos, y se crea una instancia suplementaria por cada nodo del clúster para
gestionar el tráfico CSV inter-nodo.

Existen otras pequeñas mejoras:

• El rendimiento es mucho mejor para las tarjetas que soportan RDMA (SMB over
RDMA), principalmente para las de tipo 40 Gbps Ethernet o 56 Gbps InfiniBand.

Las tarjetas RDMA permiten la transferencia direct de memoria a memoria, entre

dos equipos que disponen de este tipo de tarjeta.

• Los eventos SMB están mejor detallados.

• La gestión del ancho de banda permite definir límites sobre los distintos tipos de
tráfico: Default, Live Migration y máquinas virtuales.

Windows Server Gateway

Esta funcionalidad es un elemento clave en las redes híbridas, que va a ayudar a las
empresas a conectarse con los proveedores de servicios a través de una red privada de tipo
punto a punto.

Como tal, la máquina virtual realiza solamente el enrutamiento, es decir, la transferencia de

los paquetes entre dos tarjetas de red. El resto del trabajo lo aseguran las capas de red
incluidas con Hyper-V, que encapsulan, etiquetan y segmentan los paquetes.

A día de hoy, éste no es el único uso para esta pasarela, que permite interconectar distintos
tipos de redes físicas y virtuales, segmentando si fuera necesario la comunicación.

Según la arquitectura, esta funcionalidad debe complementarse con otros productos para
crear puentes, separar los flujos mediante tags (VLAN) y enrutar correctamente los flujos
una vez que se ha eliminado la máquina virtual.

En la empresa, esto puede aportar:

• La compartición de una Cloud privada entre varias entidades (Dev, PreProd, Prod).
• El acceso a infraestructuras externas (Cloud hybride).
• La intercomunicación entre distintas redes o arquitecturas que provengan de
distintas entidades.

Para proveedores de Cloud pública, esto facilita:

• El aislamiento de las comunicaciones.

• La compartición de recursos de hardware de red (routers/switchs/…).
• La continuidad del direccionamiento de red del cliente que puede interconectar, sea
cual sea su direccionamiento.

De manera esquemática, se trata de un router por software basado en una máquina virtual.
Aun así, el uso de una máquina virtual permite gestionar el filtrado de las conexiones
(aislamiento) a nivel del servidor físico, y etiquetar los paquetes a su paso.

1. Instalación

Hablando con propiedad, no existe, como tal, una instalación sino simplemente una
configuración.

Dejando a un lado la configuración del entorno de red, esta configuración se realiza a dos
niveles en Windows Server 2012 R2:

• En el servidor Hyper-V
• En la máquina virtual
a. En el servidor Hyper-V

Algunos comandos indicados aquí son opcionales y dependen de la configuración de la red,

otros optimizan el rendimiento, y muy pocos son indispensables.

Otros es posible ejecutarlos solamente si se dispone de tarjetas de red que soportan la

funcionalidad correspondiente.

He aquí las instrucciones de optimización (todas las tarjetas no aceptan los mismos
parámetros):

• Aumentar los buffers de recepción:

Set-NetAdapterAdvancedProperty "LAN" -DisplayName "Receive Buffers"

-DisplayValue 3000

• Aumentar los buffers de transmisión:

Set-NetAdapterAdvancedProperty "LAN" -DisplayName "Transmit Buffers"

-DisplayValue 3000

• Activación del modo RSS:

Enable-NetAdapterRss LAN

• Activación del Queuing:

Enable-NetAdapterVmq "Teaming1"

Si fuera necesario, indique la VLAN que desea utilizar en la tarjeta externa:

Set-VMNetworkAdapterVlan -VMName "WSG" -Name "VIRTUAL" -Access

-VlanId 5

Activar el aislamiento en la tarjeta de red LAN:

Set-VmNetworkAdapterIsolation -VMName WSG -VMNetworkAdapterName "LAN"

-IsolationMode NativeVirtualSubnet -MultiTenantStack Off

Es posible deshabilitar el modo de aislamiento mediante el comando:

Set-VmNetworkAdapterIsolation -VMName WSG -VMNetworkAdapterName "LAN"

-IsolationMode None

b. Configuración de la pasarela WSG

He aquí los comandos de optimización de las tarjetas de red en la máquina virtual.

Definición del número máximo de procesos a utilizar en función de la configuración:

Set-NetAdapterRss "LAN", "VIRTUAL" -MaxProcessorNumber 8

Tamaño máximo de los buffers que se utilizan en entrada y salida:

Set-NetAdapterAdvancedProperty "LAN","VIRTUAL" -DisplayName

"Send Buffer Size" -DisplayValue "32MB"

Set-NetAdapterAdvancedProperty LAN, VIRTUAL -DisplayName

"Receive Buffer Size" -DisplayValue "16MB"

La configuración de ambas tarjetas de red y la ruta por defecto puede definirse mediante la
interfaz gráfica.

En la tarjeta que permite acceder a la red virtual o remota, es preciso especificar esta red
remota y la dirección IP concreta que se desea utilizar.

Configuración de la ruta estática hacia la red virtual (es posible, también, utilizar el
comando route add):

New-NetRoute -InterfaceAlias VIRTUAL -DestinationPrefix

172.17.100.1.0/24 -NextHop 172.17.100.254

Ejemplo de configuración de la ruta por defecto:

New-NetRoute -InterfaceAlias LAN -DestinationPrefix 0.0.0.0/0 -NextHop

172.16.254.254

La parte más importante consiste en activar el enrutamiento entre ambas redes:

Set-NetIPInterface -InterfaceAlias LAN -Forwarding Enabled

Set-NetIPInterface -InterfaceAlias VIRTUAL -Forwarding Enabled

¡Ahora el enrutamiento debería estar activo!

La desactivación del enrutamiento se realiza mediante el comando:

Set-NetIPInterface -InterfaceAlias VIRTUAL -Forwarding Disabled

c. La configuración del router interno

Para que los paquetes se encaminen desde la máquina virtual hacia la o las redes remotas,
se agrega una ruta estática sobre el router por defecto para que los paquetes cuyo destino
sea 172.17.100.0 se envíen a la dirección IP de la pasarela. La configuración dependerá del
router utilizado.
2. Esquema de un ejemplo de uso

La red virtual indicada aquí estará, a menudo, vinculada con otra tarjeta de red física que
permitirá acceder a otros recursos internos o externos según la configuración. Es posible,
también, instalar una VPN para acceder a otras redes que no estarán accesibles más que por
esta pasarela.

Es posible realizar una configuración idéntica sobre el sitio remoto para recibir y
repartir los flujos.

Si tiene lugar, la conexión intersitio utilizará mecanismos de tipo Tunnel para encapsular
los paquetes de red que, de otro modo, no podrían enrutarse directamente. Si el número de
la red gestiona el nivel 3, estos mecanismos pueden ser GRE o IP-in-IP tunneling. A nivel
2, existen las VLAN de tipo Q-in-Q.

Para saber más, el siguiente enlace presenta la mayoría de combinaciones posibles:

http://technet.microsoft.com/es-es/library/jj618319.aspx

3. Conclusión

He aquí algunos elementos de reflexión suplementarios que cabe tener en cuenta.

La capa Hyper-V Network Virtualization (HNV) puede soportar en esta versión:

 • 50 dominios de enrutamiento (red de máquinas virtuales)
• 500 subredes virtuales (subredes en las redes de máquinas virtuales)
• 200 conexiones VPN punto a punto

He aquí un procedimiento que indica las distintas etapas de la implementación:

http://geekswithblogs.net/KeithMayer/archive/2012/10/08/step-by-step-implementing-
hyper-v-network-virtualization-with-windows-server-2012.aspx

Desafortunadamente, no existe, a día de hoy, una herramienta de administración integrada

en Windows Server 2012 R2 para administrar la pasarela. La gama System Center contiene
la mayoría de elementos necesarios para controlar la construcción de soluciones basadas en
la WSG.

Con todas estas mejoras, Windows Server 2012 R2 incluye muchos usos que cambian muy
rápido. La interconexión de nubes privadas, públicas, la virtualización en varios niveles, las
facilidades de conexión y la velocidad permiten adoptar nuevas arquitecturas que facilitan
la administración de un conjunto de componentes muy diverso.

Experiencia con Windows Server

Essentials
Se trata de un nuevo rol de Windows Server 2012 R2. Este rol ayuda a proteger los datos,
ofreciendo un acceso a la información desde casi cualquier dispositivo.

Este servicio le ayuda a conectarse rápidamente a las aplicaciones de gestión de su empresa

y a los servicios asociados - accesibles desde este servidor.

Este rol le aporta el mismo nivel de facilidad en la administración que el proporcionado por
SBS, dejando a un lado la mensajería, que no está incluida en este rol. En cambio, se ha
hecho lo posible para poder integrar fácilmente la mensajería correspondiente a Office 365,
y la mensajería de tipo Exchange.

Preste atención, como con SBS, este rol incluye sus restricciones, en particular a la hora de
tener en cuenta bosques mono-dominios únicamente.

1. Instalación

En la ventana del Asistente para agregar roles y características, seleccione el rol

Experiencia con Windows Server Essentials de la lista.
Este rol integra toda una serie de componentes. Haga clic en Agregar características.
Podemos observar la instalación automática de numerosos componentes relacionados con el
rol IIS así como la herramienta de copia de seguridad.

No hay que agregar ninguna característica adicional.

Haga clic en Siguiente.
¡El rol IIS se instala automáticamente!
Valide la lista de componentes IIS instalados, y agréguelos si fuera necesario.
Confirme la instalación de los componentes haciendo clic en Instalar.
Valide el resultado de la instalación.
2. Configuración inicial

Tras la instalación de la funcionalidad, la consola de gestión de servidores pide realizar la

configuración.

Haga clic en el enlace Más... junto al mensaje Requiere configuración para:....

Haga clic en la acción Configurar Windows Server Essentials en el detalle de las tareas.

Si la configuración es válida, haga clic en Configurar.

Haga clic en Cerrar.
Observe que el sistema puede reiniciar en cualquier momento.

Si todo va bien, verá aparecer el siguiente mensaje:

Preste atención, Windows Server Essentials se configura por defecto en los puertos 80 y
443. Entrará, por tanto, en conflicto con cualquier otro servicio Web ya instalado, así como
con la función Carpetas de trabajo, ¡que utiliza los mismos puertos!

Por otro lado, el servicio entidad de certificados se instala automáticamente, y se solicita

automáticamente un certificado a esta entidad.

3. Administración

La herramienta de administración principal se llama Panel, para la que existe un

acceso directo en el escritorio. Observe que no hay que confundirlo con el cuadro de mando
de administración de servidores.

He aquí el panel de Windows Server Essentials:

Aquí encontrará la lista esencial de tareas a manejar para obtener las funcionalidades
deseadas:

• Administrar las cuentas y las carpetas

• Administrar el acceso desde cualquier lugar
• Configurar la copia de seguridad
• Integrar equipos

La ventaja consiste en obtener, a continuación, rápidamente el estado de seguimiento, de

los servidores, etc.

Es posible, a continuación, integrar distintos servicios locales o remotos (Cloud):

En las aplicaciones, existe la posibilidad de conectarse a Microsoft Pinpoint. Se trata de
una ubicación donde podemos encontrar herramientas complementarias que se integran con
Windows Server Essentials.
4. Configuración del cliente en el equipo del usuario

Para instalar el cliente que permite interactuar con esta funcionalidad, utilice la URL
http://NombreDelServidor/CONNECT, que da acceso a un enlace de descarga de la
herramienta llamada Conector, compatible con Windows 7 SP1, Windows 8, Windows 8.1
y Mac OS X 10.6 a 10.8.

Tras la instalación, el equipo se integra al dominio, si no lo estuviera ya.

Descargue la herramienta.

Ejecute el asistente de instalación.

Siga la instalación.
Indique su nombre de usuario y contraseña.
Se muestra una alerta de seguridad sobre la cuenta Administradores.

Seleccione la opción apropiada. Haga clic en No si configura el cliente para el conjunto de

usuarios del equipo.
La primera opción está, principalmente, adaptada a equipos portátiles y equipos personales,
la segunda opción a equipos de empresa.

Configure el modo de copia de seguridad del equipo.

Valide la configuración.
Una vez terminada la instalación, se agrega un componente a la barra de tareas.

Preste atención, tras la primera conexión se realiza una copia de seguridad de la estación…

Las copias de seguridad de los equipos cliente están ubicadas en archivos especiales con
extensión de tipo DAT en el servidor, en la carpeta C:\ServerFolders\Copias de seguridad
de equipos cliente.

5. Uso

Si se ha configurado para todos los usuarios del puesto de trabajo, cualquier usuario que
inicie sesión se conectará, automáticamente, al servidor.
El entorno del usuario incluye dos elementos para acceder a los datos:

• El acceso directo en el Escritorio.

Éste contiene dos accesos directos que apuntan a carpetas de trabajo a través del
recurso compartido Carpetas compartidas sobre el servidor.

• El icono de la aplicación Launchpad, instalado por el conector, aparece en la barra

de tareas.

Si se abre el LaunchPad, se obtiene la lista de aplicaciones disponibles.

Por defecto, aparece la siguiente pantalla:

El usuario puede, de este modo, iniciar una copia de seguridad, acceder de manera remota
si el módulo se ha configurado para obtener las carpetas compartidas, así como las
aplicaciones agregadas tales como el correo electrónico, si se hubiera configurado.

La aplicación Panel está accesible únicamente a aquellos usuarios declarados como

administradores en la consola de administración de Windows Server Essentials.

6. Conclusión

La administración aprovecha una herramienta que le permite implementar rápidamente toda

una infraestructura comparable a la que se provee con SBS o en la versión específica de
Windows Server 2012 Essentials, salvo en lo relativo al correo electrónico, que se propone
como una integración con Office 365.

Ahora es posible realizar una pequeña maqueta para afinar la configuración y adaptarla a
las necesidades concretas del proyecto. Por ejemplo, las carpetas compartidas se crean por
defecto en el disco C: del servidor.

Introducción
Este capítulo está dedicado al rol Servicios de Escritorio remoto (Remote Desktop
Services) de Windows Server 2012 R2. Probablemente ya utiliza este servicio para
administrar su parque de servidores de forma cotidiana. Tras revisar este uso simple
aunque, ciertamente, crítico, veremos la potencia del rol RDS. Esto incluye, en particular,
la publicación de aplicaciones, del escritorio en modo sesión o virtual, así como el acceso a
estas aplicaciones a través de una pasarela Web.

Antes de empezar, vamos a realizar algunas aclaraciones sobre la nomenclatura. El nombre

de los servicios se ha visto modificado desde Windows Server 2008 R2, y encontramos
nuevos nombres en Windows Server 2012 R2:

Antes de Windows Windows Server 2012 R2 También llamado

Server 2008
Terminal Services Servicios de Escritorio RDS
remoto (Remote Desktop
Services)
Terminal Server Host de sesión de Escritorio RDSH
remoto
no existía Host de virtualización de RDVH o VDI
Escritorio remoto
Administración de Administración de licencias
licencias TS de Escritorio remoto
Service Broker TS Agente de conexión a RDCB (Connection Broker)
Escritorio remoto RDSB (Service Broker) o
Broker
Acceso Web TS Acceso Web para los RDWA o RDWEB
servicios de Escritorio remoto
Puerta de enlace de Puerta de enlace de Escritorio
TS remoto

Como podrá observar, el cambio principal es que se ha remplazado "Terminal Services" por
"servicios de Escritorio remoto".

Esta obra, centrada en Windows Server 2012 R2, utiliza la nueva nomenclatura en lo
sucesivo. Aquellas funcionalidades que sólo existan en una versión se destacarán. La
denominación "Escritorio remoto" se remplazará, a menudo, por la voz inglesa RDS
(Remote Desktop Services) con el objetivo de hacer más legible el texto.

Windows Server 2012 R2 incluye su conjunto de mejoras en los servicios de Escritorio

remoto respecto a las versiones anteriores. En particular, destacaremos:

• Una consola de administración que le permitirá administrar sus servidores de

Escritorio remoto o escritorios virtuales de forma sencilla y centralizada.
• Los discos de perfil de usuario que permiten ampliar la gestión de los perfiles
móviles.
 • La gestión automatizada de los escritorios virtuales que permite recrear escritorios
virtuales, una vez aplicadas las actualizaciones de seguridad instaladas en el modelo
de escritorio virtual.
• La instalación simplificada de los servicios de Escritorio remoto en modo sesión o
en modo de escritorios virtuales (VDI).
• Una mejora en la compresión de los flujos de audio y vídeo con una reducción del
ancho de banda de casi el 50% en algunos casos.
• La posibilidad de visualizar las sesiones (Session Shadowing), que permite
supervisar y controlar la sesión de otro usuario conectado a un servidor host de
sesión de los servicios de Escritorio remoto o a un escritorio virtual que se ejecuta
sobre un servidor host de virtualización de los servicios de Escritorio remoto.
• Una mejor tasa de compresión de los flujos RDP, que mejora el uso del ancho de
banda.
• Una mejora en el tiempo de reconexión (Quick reconnect), tras la pérdida de la
conexión mediante un escritorio virtual, una sesión o una aplicación RemoteApp.
• La posibilidad de instalar el rol Connection Broker en un servidor controlador de
dominio.

Sería demasiado extenso enumerar la lista completa.

Windows 8.1 y Windows Server 2012 R2 incluyen el cliente Remote Desktop Client
(RDC) en su versión 8.0. El objetivo consiste en mejorar la experiencia de usuario
proporcionando:

• Soporte multi-touch.
• Redirección dinámica de USB mediante RemoteFX.
• Gestión de la reconexión automática para aplicaciones RemoteApp y conexiones de
Escritorio remoto.
• Integración de una autenticación única (Single Sign-on).
• Integración de una API mediante RemoteFX para VoIP.
• Integración de sesiones anidadas.
• Un verdadero soporte multipantalla (en lugar de la extensión habitual).
• Soporte a pantallas con cambio de representación apaisada/vertical.
• Soporte a la hora de agregar o eliminar una pantalla en caliente (conexión a un
proyector de vídeo, por ejemplo) en una sesión y las aplicaciones RemoteApp.
• Securización de las conexiones de administración mediante el modo
RestrictedAdmin, que permite realizar una autenticación mediante un ticket
Kerberos y un token de autenticación de la sesión interactiva sin necesidad de
volver a introducir las credenciales tras la conexión. No se envía ninguna
contraseña, encriptada o en claro, al servidor, y no existe, por tanto, la posibilidad
de que un pirata nos robe la contraseña (ni siquiera el hash de la contraseña). Los
sistemas operativos compatibles son únicamente Windows Server 2012 R2 y
Windows 8.1 (tanto del lado cliente como servidor de conexión). Además, sólo
aquellos usuarios miembros del grupo local Administradores (directa o
indirectamente) podrán conectarse en modo RestrictedAdmin. Para abrir una
conexión en modo RestrictedAdmin necesita escribir el comando mstsc.exe
 /restrictedAdmin. Observe que el parámetro /admin viene implícito con el
parámetro /restrictedAdmin.

RemoteFX, incluido por primera vez con Windows Server 2008 R2 SP1, ha visto
evolucionar sus funcionalidades gracias a Windows Server 2012 R2. He aquí las
principales mejoras de RemoteFX:

• Soporte de DirectX 11.1: en una sesión, RemoteFX gestiona, ahora, DirectX 11.1
sobre los procesadores gráficos virtuales (vGPU) con el objetivo de mejorar la
calidad gráfica y dar soporte, también, a la visualización 3D, siempre basada en
DirectX 11.1.
• Soporte de aplicaciones Metro RemoteFX gestiona las aplicaciones Metro
introducidas con Windows 8.
• Soporte extendido de dispositivos USB: RemoteFX puede, ahora, redirigir varios
tipos de dispositivos USB, tales como impresoras, teléfonos móviles,
lectores/grabadoras de CD, lectores de smartcard, webcams u otros dispositivos
USB. Además, los dispositivos USB pueden redirigirse en mitad de una sesión, de
forma dinámica, y no sólo durante la apertura de la sesión.
• Mejora de las conexiones WAN y externas: gracias a las funcionalidades de
RemoteFX Adaptative Graphics, RemoteFX Media Streaming y RemoteFX for
WAN, se hace mucho más cómodo trabajar a distancia.

Para aprovechar todas las mejoras aportadas por RemoteFX, es preciso utilizar el cliente
RDP 8.1.

En una infraestructura de servicios de Escritorio remoto con Windows Server 2012 R2, los
servicios de rol Agente de conexión a Escritorio remoto son el pilar fundamental.

Este servicio de rol permite gestionar el conjunto de sesiones de usuario sobre varios
servidores RDS. Esto mejora, a su vez, la experiencia de usuario, agregando las
publicaciones RemoteApp, escritorio remoto y escritorio virtual en una vista única. Para
ello, almacena el estado de todas las sesiones de todos los servidores, información que
recibe mediante servidores RDS. Cuando un usuario se conecta por primera vez sobre un
servidor, el Agente de sesiones memoriza esta conexión. Si el usuario pierde la conexión de
red, su sesión TS permanece activa sobre el servidor, aunque en estado desconectado.
Cuando vuelva a tener conexión de red, y vuelva a conectarse con el servidor, el Agente de
sesiones detectará que ya existe una sesión existente y enviará al usuario sobre este servidor
RDS. De este modo, el usuario volverá a su sesión anterior en lugar de creársele,
potencialmente, una sesión nueva.

También se utiliza, por defecto, el servidor de administración de la implementación como

punto de unión con la nueva consola de gestión de los servicios de Escritorio remoto.

No podrá tener una infraestructura de servicios de Escritorio remoto en Windows Server

2012 R2 sin tener este rol instalado. Es obligatorio, aunque casi transparente.
Implementar los Servicios de Escritorio
remoto
Desde un punto de vista técnico, los servicios de Escritorio remoto ya están instalados, por
defecto, aunque detenidos, con Windows Server 2012 R2. A diferencia de las versiones
anteriores a Windows Server 2008 R2, esto servicios se ejecutan, en lo sucesivo, con la
cuenta "Servicio de red" en lugar de como local system. La seguridad del sistema se ha
visto mejorada y, de este modo, un fallo en el servicio tiene un impacto menor que antes.
Como se explica en la base de conocimientos de Microsoft (KB946399), la cuenta
"Servicio de red" necesita tres privilegios para ejecutar los servicios de Escritorio remoto:

• Ajustar las cuotas de memoria para un proceso (SeIncreaseQuotaPrivilege).

• Generar auditorías de seguridad (SeAuditPrivilege).
• Remplazar un token a nivel de proceso (SeAssignPrimaryTokenPrivilege).

Estos tres privilegios no deben eliminarse de la cuenta (mediante una GPO...), o existe el
riesgo de no poder ejecutar más estos servicios. Desde Windows Server 2008 es, no
obstante, posible detener el servicio RDS, lo que no podía hacerse antes. Puede comprobar
el estado actual del servicio así como los estados aceptados por el servicio utilizando el
siguiente comando (el nombre corto del servicio no se ha modificado):

sc query TermService

El servicio RDS utiliza, por defecto, el puerto TCP 3389. Mientras el acceso remoto no se
haya autorizado de manera explícita, el servidor no escucha en el puerto TCP para no
exponer los servicios sobre la red. El siguiente comando permite verificar que el puerto
TCP 3389 no escucha nada sobre el servidor, por el momento:

netstat -an | findstr 3389

Para aprovechar el conjunto de funcionalidades que ofrece Windows Server 2012 R2, se
requiere el cliente RDP versión 8.1 (realmente, la versión 6.3.9600, aunque no se
corresponde con el sistema operativo). Ya está incluido en Windows 8.1 y Windows Server
2012 R2. En el momento de escribir estas líneas, no existe un cliente RDP 8.1 para sistemas
anteriores a Windows 8.1, aunque las versiones 8.0 y 7.0 del cliente RDP siguen siendo
compatibles con los servicios de Escritorio remoto de Windows Server 2012 R2, sin las
mejoras aportadas por la versión 8.1 del cliente RDP.

Los servicios de rol que componen este rol de Servicios de Escritorio remoto son:

• Host de sesión: permite, a un servidor, hospedar aplicaciones o el escritorio

completo de Windows. Todos los usuarios pueden conectarse, no sólo los
administradores. Se ha eliminado la limitación a dos sesiones concurrentes.
• Host de virtualización: los servicios de Escritorio remoto se integran con Hyper-V
y permiten implementar escritorios o aplicaciones virtuales, en modo pool o
personalizado, y presentarlas a los clientes mediante el cliente RDP, RemoteApp o
mediante acceso Web.
• Administrador de licencias: gestiona la asignación de licencias CAL por
dispositivo o usuario con el objetivo de conectarse a un servidor RDSH o RDVH.
• Agente de sesiones: permite repartir las sesiones TS en una infraestructura (o granja
de servidores) RDS, así como la reconexión a una sesión existente en una granja.
Gestiona, a su vez, el reparto de carga entre los servidores del mismo grupo siempre
que no exista una sesión abierta para un usuario determinado.
• Puerta de enlace: permite a los usuarios habilitados consumir recursos desde
Internet siempre que el periférico ejecute el cliente RDC. El flujo RDP (Remote
Desktop Protocol), inicialmente sobre el puerto TCP 3389, se encapsula en un canal
HTTPS (puerto TCP 443) entre el cliente y la puerta de enlace de los servicios de
Escritorio remoto. Esto le va a permitir utilizar una conexión VPN para acceder a
los recursos ofrecidos por los servicios de Escritorio remoto.
• Acceso Web: permite presentar las aplicaciones y los escritorios remotos a los
usuarios mediante un simple sitio Web. Está acoplado a la Puerta de enlace de
Escritorio remoto, lo que permite aumentar las posibilidades de acceso por parte
de los usuarios, en particular desde hoteles, estaciones u otras empresas, donde el
acceso a Internet está, a menudo, limitado a un flujo HTTP (TCP 80) y HTTPS
(TCP 443).
1. Administración remota

Si bien el servicio de Windows ya está instalado, éste no se inicia por defecto. En efecto, el
servicio de Escritorio remoto (TermService) está configurado con un arranque Manual, y
se configura automáticamente con arranque Automático cuando se habilita la
Administración remota o se instalan los servicios de rol Host de sesión de Escritorio
remoto o Host de virtualización de Escritorio remoto. De momento no puede utilizarlo
para administrar sus servidores de forma remota, es preciso autorizar explícitamente el
acceso remoto mediante el Administrador del servidor.

Abra la consola Administrador del servidor y haga clic en Servidor local en la zona de
navegación.

En la parte principal de la consola, dentro de Propiedades para NombreDeServidor, haga

clic en Deshabilitado donde indica Escritorio remoto.

Se abre una ventana de Propiedades del sistema, donde la pestaña Acceso remoto
permite habilitar el escritorio remoto, con o sin NLA, así como autorizar a ciertos usuarios
a conectarse. Escoja la opción Permitir las conexiones remotas a este equipo.
Esta interfaz modifica dos claves del registro: fDenyTSConnections y User-
Authentication, ubicadas en
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server.
La primera bloquea cualquier conexión TS, será necesario asignarle un valor 0 para
autorizar las conexiones, y la segunda exige la autenticación NLA siempre que su valor sea
1.

Aparece el siguiente mensaje informativo, haga clic en Aceptar.

La gestión del Firewall de Windows se describe en el capítulo Securizar su arquitectura.

Deje la opción Permitir sólo las conexiones desde equipos que ejecuten Escritorio
remoto con Autenticación a nivel de red (recomendado) marcada. A continuación, haga
clic en Aplicar.

NLA significa Network Level Authentication. El objetivo consiste en luchar contra los
ataques llamados hombre en el medio (man in the middle) autenticando al servidor RD
antes de que se conecte el usuario. Es posible utilizar varios protocolos para realizar esta
tarea: kerberos, TLS/SSL, NTLM. Técnicamente, se basa en el proveedor CredSSP, que
utiliza SSPI (Security Service Provider Interface). Una vez superada la fase de
autenticación mutua, el cliente provee las credenciales del usuario, que se encriptan dos
veces con las claves de sesión SPNEGO y TLS.

El Escritorio remoto, destinado especialmente a la administración remota, permite, por

defecto, acceder únicamente a los miembros de los grupos Administrador local y
Administrador de dominio. Puede agregar otras cuentas haciendo clic en el botón
Seleccionar usuarios.

Haga clic en el botón Aceptar para cerrar la ventana de las propiedades del sistema

Ahora que el acceso remoto está abierto, el servicio RDS está iniciado y escuchando en el
puerto TCP y UDP 3389 (una línea para IP versión 4 y otra para IP versión 6):
En efecto, Windows Server 2012 R2 gestiona, ahora, el protocolo UDP para los servicios
de Escritorio remoto. La conexión inicial se realiza siempre sobre el puerto 3389 TCP.
UDP entra en juego una vez establecida la conexión inicial, para acelera la tasa de
transferencia.

Sobre una red local, la tasa de transferencia es generalmente buena, entre los 100 Mb/s y
1000 Mb/s. El protocolo UDP no aporta, necesariamente, una mejora importante en el
rendimiento, salvo para el uso de RemoteFX. Por el contrario, UDP adquiere sentido
cuando hablamos de conexiones de tipo WAN o mediante una puerta de enlace de servicios
de Escritorio remoto, donde la tasa de transferencia se ve limitada a la velocidad de su
conexión a Internet.

Para aprovechar el protocolo UDP, es preciso utilizar, como mínimo, el cliente RDP 8.0.

Puede, ahora, utilizar el escritorio remoto para administrar su servidor. Esta funcionalidad
no requiere la instalación del rol Escritorio remoto. La administración remota se considera
algo indispensable en cualquier servidor, sea cual sea su uso, y no se caracteriza por un rol
determinado.

La administración remota es muy útil, aunque no supone un avance destacado. ¡Es

momento de explotar todo el potencial del rol! Para ello, tras haber instalado los
componentes del rol, se configurarán en el marco de ejemplos concretos.

2. Instalación de los servicios de Escritorio remoto

Windows Server 2012 R2 utiliza una nueva forma (incluida con Windows Server 2012) de
instalar los servicios de Escritorio remoto basada en escenarios que simplifican, así, la
instalación de los distintos servicios de rol de Escritorio remoto sobre varios servidores.
Este modo de instalación instala y configura también el protocolo de despliegue de
Escritorio remoto que permite administrar el servidor mediante la nueva interfaz de gestión
de servicios de Escritorio remoto RDMS.

Sigue siendo posible instalar los servicios de Escritorio remoto mediante la instalación
basada en roles o características. No obstante, este modo de instalación requiere una
administración por GPO o directamente en la base de registro. En efecto, las consolas de
administración tsadmin.msc y tsconfig.msc ya no existen en Windows Server 2012 R2.
Además, si prevé agregar su servidor RDS 2012 R2 a una granja RDS 2008 R2, tendrá que
seleccionar este modo de instalación.

Si bien todos los servicios de rol de Escritorio remoto pueden instalarse sobre el mismo
servidor, se recomienda separarlos. En la mayoría de casos, los servicios de rol Host de
sesión y Host de virtualización se instalan sólo sobre un servidor, el Administrador de
licencias se instala, a menudo, sobre un controlador de dominio, y el Acceso Web y la
Puerta de enlace se agrupan en otro servidor.

¿Por qué separar los servicios de rol de Escritorio remoto? Desde un punto de vista
práctico, es obligatorio para poder configurar en clúster los servidores Host de sesión (RD
Session Host) y el Acceso Web (RD Web Access). Otro ejemplo es que, si su
infraestructura RDS soporta un gran número de usuarios que utilizan la misma puerta de
enlace de los servicios de Escritorio remoto, esta última consumirá bastante tiempo de
procesador para el cifrado de los flujos SSL y, por tanto, ralentizará a los usuarios que
trabajan en la parte Host de sesión si estos servicios de rol están instalados en el mismo
servidor.

Observe que la instalación del rol Connection Broker sobre un controlador de dominio está,
ahora, soportada, aunque no es una buena práctica.

He aquí las principales posibilidades para instalar los servicios de Escritorio remoto:

• Mediante la instalación de Escritorio remoto: este modo de instalación, también

llamado modo escenario, permite implementar sobre uno o varios servidores los
servicios de rol de Escritorio remoto mediante un asistente de instalación gráfico.
Permite instalar los servicios de rol RD Session Host, RD Web Access y RD
Session Broker.
• Mediante la instalación basada en roles o características: este modo de
instalación, idéntico a las versiones anteriores de Windows Server, permite instalar
cada servicio de rol de Escritorio remoto de forma unitaria. Será preciso utilizar este
modo de instalación para instalar los servicios de rol de Escritorio remoto
siguientes: Administrador de licencias de Escritorio remoto y Puerta de enlace
de Escritorio remoto.
• Mediante PowerShell: con PowerShell, veremos que es posible reproducir los dos
tipos de instalación anteriores.
a. Requisitos previos

Antes de proceder con la instalación de los servicios de Escritorio remoto, debe asegurar
que se respetan, como mínimo, los siguientes requisitos previos:

• Los servidores afectados por la instalación deben ser miembros del dominio Active
Directory.
• Los servidores afectados por la instalación deben tener una dirección IP fija.

Es también aconsejable crear una jerarquía de unidades organizativas dedicada a los

servicios de Escritorio remoto en el seno de Active Directory. El objetivo consiste en poder
aplicar las directivas de grupo únicamente a aquellos servidores y equipos virtuales que
formen parte de los servicios de Escritorio remoto (principalmente servidores RD Session
Host). Otra ventaja "oculta" es que esto le va a permitir organizar mejor su arborescencia de
servidores en el seno de su Active Directory.

Para instalar los servicios de Escritorio remoto, debe utilizar una cuenta de usuario que
posea, al menos, permisos de Administrador local sobre los servidores afectados por la
instalación.

b. Instalación Inicio rápido

Como ya hemos mencionado, la instalación de los servicios de Escritorio remoto es algo

sencillo, sobre todo utilizando el asistente de instalación en modo Inicio rápido. Este tipo de
instalación implementará los servicios de rol necesarios (RDWEB, Agente de conexión y, o
bien RDSH, o bien RDVH) sobre el mismo servidor.

Instalación basada en sesiones

A continuación, se muestra cómo instalar los servicios de Escritorio remoto basados en

sesiones:

Desde el futuro servidor de servicios de Escritorio remoto, abra el Administrador del

servidor, haga clic en el menú Administrar y, a continuación, Agregar roles y
características.

Se abre el Asistente para agregar roles y características y le muestra la pantalla Antes

de comenzar, haga clic en el botón Siguiente.

En la pantalla Seleccionar el tipo de instalación, marque Instalación de Servicios de

Escritorio remoto y, a continuación, haga clic en Siguiente.

En la pantalla Seleccionar tipo de implementación, marque Inicio rápido y, a

continuación, haga clic en Siguiente.

En la pantalla Seleccionar escenario de implementación, marque Implementación de

escritorio basada en sesión y, a continuación, haga clic en Siguiente.

En la pantalla Seleccionar un servidor, seleccione el nombre del servidor afectado por la

instalación de los servicios de Escritorio remoto en la columna Grupo de servidores, y
haga clic en la flecha situada en el centro para desplazarlo a la columna Seleccionado. Si
realiza la instalación desde otro servidor, puede que el nombre del servidor afectado por la
instalación no aparezca en la lista Pool de servidores. Será preciso anular la instalación de
los servicios de Escritorio remoto, volver al Administrador del servidor, abrir el menú
Administrar y seleccionar Agregar servidores para incluir su servidor. Haga clic en el botón
Siguiente para continuar con la instalación.

En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el

servidor de destino en caso necesario y haga clic en el botón Implementar.

El Asistente para agregar roles y características le muestra, a continuación, la página

Ver progreso que le permite implementar roles y servicios de rol. Una vez se haya
reiniciado automáticamente el servidor, abra de nuevo una sesión con la cuenta de usuario
que haya utilizado para realizar la instalación de los servicios de Escritorio remoto y, a
continuación, abra el Administrador del servidor para terminar la instalación. Este último
abrirá, automáticamente, la ventana del Asistente para agregar roles y características en
la página Ver progreso. Una vez terminadas las etapas de la instalación con éxito, haga
clic en el botón Cerrar.
Una vez finalizado el procedimiento de instalación, su servidor está listo para recibir
sesiones de usuario. En efecto, el modo de instalación inicio rápido instala y configura los
roles necesarios para los servicios de Escritorio remoto sobre un entorno Windows Server
2012 R2 (servicios de sesión de agente de conexión, acceso Web, servidores host de
sesión), la consola de administración de los servicios de Escritorio remoto (RDMS, Remote
Desktop Management Service), configura el punto de implementación de los servicios de
Escritorio remoto, y crea una colección para el servicio de sesión de Escritorio remoto
llamada QuickSessionCollection. Puede, también, observar que este modo de instalación
publica de manera automática tres aplicaciones a través de RemoteApp: Calculadora, Paint,
WordPad.

Vista del conjunto de una implementación en modo rápido.

Vista de la colección creada por defecto por una implementación en modo rápido.

Aparece un icono en la barra de tareas que le advierte sobre la ausencia de licencias. Será
preciso disponer de un servidor de licencias, con un periodo de prueba de 120 días. Tendrá
que instalar el administrador de licencias de servicios de Escritorio remoto, habilitarlo e
instalar las licencias de acceso cliente a los servicios de Escritorio remoto.

También tendrá que obtener (o administrar) y asociar al servidor RD Session Broker y al

servidor RD Session Host certificados digitales, y precisar, si fuera necesario, la
configuración de los parámetros de la colección del servicio de implementación de
Escritorio remoto, las conexiones, las aplicaciones publicadas mediante RemoteApp... Y,
para finalizar, tendrá evidentemente que instalar las aplicaciones sobre las que podrán
acceder los usuarios de los servicios de escritorio remoto.

He aquí el equivalente en PowerShell:

# Instalación en modo roles y características (opcional)

Install-WindowsFeature RDS-RD-Server,RDS-Web-Access,RDS-Connection-
Broker -IncludeManagementTools

# Instalación en modo escenario servicio de Escritorio remoto

New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv
-WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv
# Creación de la colección
New-RDSessionCollection -CollectionName QuickSessionCollection -Session
Host rds1.MiEmpresa.Priv -ConnectionBroker rds1.MiEmpresa.Priv

# Publicación de la calculadora mediante RemoteApp

New-RDRemoteApp -CollectionName QuickSessionCollection -Connection
Broker rds1.MiEmpresa.Priv -DisplayName Calculadora -Alias
Calculadora -FilePath "C:\Windows\system32\calc.exe"
-ShowInWebAccess $true -RequiredCommandLine $false

# Publicación de WordPad mediante RemoteApp

New-RDRemoteApp -CollectionName QuickSessionCollection -Connection
Broker rds1.MiEmpresa.Priv -DisplayName WordPad -Alias WordPad
-FilePath "C:\Program Files\Windows NT\Accesorios\wordpad.exe"
-ShowInWebAccess $true -RequiredCommandLine $false

# Publicación de Paint mediante RemoteApp

New-RDRemoteApp -CollectionName QuickSessionCollection -Connection
Broker rds1.MiEmpresa.Priv -DisplayName Paint -Alias Paint
-FilePath "C:\Windows\system32\mspaint.exe" -ShowInWebAccess $true
-RequiredCommandLine $false

Observe que la instrucción Install-WindowsFeatures... no es obligatoria. En efecto, la

instrucción New-RDSessionDeployment instalará todos los roles y servicios necesarios,
como IIS, por ejemplo.

Instalación basada en escritorios virtuales

La instalación basada en escritorios virtuales no es complicada. No obstante, es

preferible crear un disco virtual que contenga una instalación de un cliente Windows. En
nuestro caso, utilizaremos un disco virtual que contenga una instalación de Windows 8,
instalado y con el sistema preparado.

Cabe indicar que la instalación en modo Inicio rápido crea, por defecto, una colección de
escritorios virtuales en Pool.

Recuerde que, a diferencia de las sesiones basadas en un servidor host de sesión donde
todos los usuarios abren una sesión sobre la misma máquina, gestionados por el servidor
host de sesión, las sesiones basadas sobre escritorios virtuales se abren sobre máquinas
virtuales donde se conecta un único usuario.

A continuación se muestra cómo instalar los servicios de Escritorio remoto basados en

escritorios virtuales (VDI) en modo Pool:

Abra el Administrador del servidor, haga clic en el menú Administrar y seleccione

Agregar roles y características.

Se abre el Asistente para agregar roles y características. En la pantalla Antes de

comenzar, haga clic en Siguiente.
En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de
Escritorio remoto y, a continuación, haga clic en Siguiente.

En la pantalla Seleccionar tipo de implementación, marque Inicio rápido y, a

continuación, haga clic en Siguiente.

En la pantalla Seleccionar escenario de implementación, marque Implemen-tación de

escritorio basada en máquina virtual y, a continuación, haga clic en Siguiente.

En la pantalla Seleccionar un servidor, seleccione el servidor sobre el que desea instalar

los servicios de Escritorio remoto y haga clic en Siguiente.

En la pantalla Seleccionar una plantilla de escritorio virtual, escriba la ruta completa del
archivo de disco duro virtual que servirá como modelo y habrá creado previamente y, a
continuación, haga clic en Siguiente.

En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el

servidor de destino en caso necesario y haga clic en el botón Implementar.

El Asistente para agregar roles y características le muestra, a continuación, la página

Ver progreso que le permite implementar roles y servicios de rol. Una vez se haya
reiniciado automáticamente el servidor, abra de nuevo una sesión con la cuenta de usuario
que haya utilizado para realizar la instalación de los servicios de Escritorio remoto y, a
continuación, abra el Administrador del servidor para terminar la instalación. Este último
abrirá, automáticamente, la ventana del Asistente para agregar roles y características en
la página Ver progreso. Una vez terminadas las etapas de la instalación con éxito, haga
clic en el botón Cerrar.

Si durante la instalación de los servicios de Escritorio remoto en modo Implementación de

escritorio basada en máquina virtual observa que se detiene en la etapa Colección de
escritorios virtuales - Creación de la colección de escritorios virtuales..., que abriendo
el Administrador de Hyper-V, existe alguna máquina virtual además de la máquina
virtual QuickMasterVM, en estado iniciado, y que su instalación dura más de 10 minutos,
entonces probablemente no tenga ningún servidor DHCP configurado en su red, o bien no
es accesible desde las máquinas virtuales que está tratando de implementar (máquina virtual
ubicada sobre el switch incorrecto, por ejemplo). Conviene, evidentemente, resolver este
problema, de modo que pueda finalizar su implementación.

Como con una instalación de los servicios de Escritorio remoto basada en sesiones y en
modo de inicio rápido, su servidor está listo para aceptar conexiones de usuario. No
obstante, estará limitado en cuanto al número de usuarios que pueden conectarse
simultáneamente, puesto que sólo se ha creado una VM durante la instalación.

He aquí el equivalente en PowerShell:

# Instalación en modo roles y características (opcional)
Install-WindowsFeature Hyper-V,RDS-Virtualization,RDS-Web-Access,
RDS-Connection-Broker -IncludeManagementTools -Restart

# Instalación en modo escenario servicio de Escritorio remoto,

# debe realizarse desde otro equipo.
New-RDVirtualDesktopDeployment -ConnectionBroker rdvh1.MiEmpresa.Priv
-WebAccessServer rdvh1.MiEmpresa.Priv -VirtualizationHost
rdvh1.MiEmpresa.Priv -CreateVirtualSwitch

# Atribución de permisos de creación y eliminación de VM

# sobre la OU Equipos
Grant-RDOUAccess -Domain MiEmpresa.Priv -OU "Computers"
-ConnectionBroker rdvh1.MiEmpresa.Priv

# Creación de la colección
New-RDVirtualDesktopCollection -CollectionName QuickVMCollection
-PooledManaged -VirtualDesktopTemplateName "Win8.1 Ent"
-VirtualDesktopTemplateHostServer rdvh1.MiEmpresa.Priv
-VirtualDesktopAllocation
@{"rdvh1.MiEmpresa.Priv" = 1} -StorageType LocalStorage
-VirtualDesktopNamePrefix Win81ent -ConnectionBroker
rdvh1.MiEmpresa.Priv

c. Implementación estándar

Primera instalación de los servicios de Escritorio remoto en modo sesión

La instalación en modo Implementación estándar le permitirá instalar los servicios de rol

Escritorio remoto sobre varios servidores, con el objetivo de separar o instalar varios
servidores host simultáneamente, aprovechando una instalación más sencilla.

A continuación se describe cómo proceder para realizar una instalación de los servicios de
Escritorio remoto basada en sesiones, sobre varios servidores (para dos servidores RDSH,
rds1.MiEmpresa.Priv y rds2.MiEmpresa.priv, y un servidor RDWA y RDCB,
rdsgw.MiEmpresa.Priv en este ejemplo):

Abra el Administrador del servidor, haga clic en el menú Administrar y, a

continuación, en Agregar roles y características, y seleccione la opción Agregar
servidores para agregar los servidores que van a contener, al menos, un servicio de rol de
Escritorio remoto

En el Administrador del servidor, haga clic en Administrar y, a continuación, en

Agregar roles y características.

Se abre el Asistente para agregar roles y características. En la pantalla Antes de

comenzar, haga clic en Siguiente.

En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de

Escritorio remoto y, a continuación, haga clic en Siguiente.
 En la pantalla Seleccionar tipo de implementación, marque Implementación estándar y,
a continuación, haga clic en Siguiente.

En la pantalla Seleccionar escenario de implementación, marque Implementación de

escritorio basada en sesión y, a continuación, haga clic en Siguiente.

En la pantalla Revisar servicios de rol, haga clic en Siguiente.

En la pantalla Especificar servidor de Agente de conexión a Escritorio remoto,

seleccione el servidor que será el RD Connection Broker en la columna Pool de servidores
y, a continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna
Seleccionado (el servidor rdsgw.MiEmpresa.Priv en nuestro ejemplo). A continuación,
haga clic en Siguiente.

En la pantalla Especificar servidor de acceso Web de conexión a Escritorio remoto,

seleccione el servidor que será el RD Web Acces en la columna Pool de servidores y, a
continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna
Seleccionado (el servidor rdsgw.MiEmpresa.Priv en nuestro ejemplo). A continuación,
haga clic en Siguiente.

En la pantalla Especificar servidores host de sesión de Escritorio remoto, seleccione el

o los servidores que serán RD Session Host en la columna Pool de servidores y, a
continuación, haga clic en la flecha situada en el centro para deslizarlo en la columna
Seleccionado (los servidores rds1.MiEmpresa.Priv y rds2.MiEmpresa.Priv en nuestro
ejemplo). A continuación, haga clic en Siguiente.

En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el

servidor de destino en caso necesario y haga clic en el botón Implementar.

Tras finalizar la instalación, se reiniciará el servidor. Una vez reiniciado, abra de nuevo
una sesión con la cuenta de usuario que haya utilizado para realizar la instalación y, a
continuación, abra el Administrador del servidor para que finalice el asistente de
instalación y configuración de los servicios de Escritorio remoto. Haga clic en Cerrar.

Una vez terminada la instalación de los servicios de Escritorio remoto, sólo los usuarios
miembros del grupo Administradores de dominio podrán abrir una sesión sobre los
servidores RD Session Host. El motivo es bien simple, el asistente de instalación no ha
creado ninguna colección, ni existen aplicaciones publicadas por RemoteApp.

Además de seguir las mismas recomendaciones que con la post-instalación de la

instalación de los servicios de Escritorio remoto - Inicio rápido, tendrá que crear una
colección.

A continuación se muestran los comandos equivalentes en PowerShell (basados en

sesiones):

# Instalación en modo escenario del servicio de Escritorio remoto

New-RDSessionDeployment -ConnectionBroker rdsgw.MiEmpresa.Priv
-WebAccessServer rdsgw.MiEmpresa.Priv -SessionHost
rds1.MiEmpresa.Priv,rds2.MiEmpresa.Priv

Primera instalación de los servicios de Escritorio remoto en modo escritorio virtual

La instalación basada en escritorios virtuales con una implementación estándar es

prácticamente idéntica, de modo que no vamos a describirla con detalle. He aquí los
comandos equivalentes en PowerShell para un servidor RDVH, rdvh1.MiEmpresa.Priv y
un servidor RDWA y RDCB, rdsgw.MiEmpresa.Priv en este ejemplo):

# Instalación en modo roles y características (opcional)

Install-WindowsFeature Hyper-V,RDS-Virtualization,RDS-Web-Access,
RDS-Connection-Broker -IncludeManagementTools -Restart

# Instalación en modo escenario del servicio de Escritorio remoto,

# debe realizarse desde otro puesto.
New-RDVirtualDesktopDeployment -ConnectionBroker rdsgw.MiEmpresa.Priv
-WebAccessServer rdsgw.MiEmpresa.Priv -VirtualizationHost
rdvh1.MiEmpresa.Priv -CreateVirtualSwitch

Agregar un tipo de implementación

Una instalación basada en un despliegue de sesión puede, también, gestionar un despliegue

de escritorios virtuales. Para ello, basta con proceder como si se tratara de una nueva
instalación:

Abra el Administrador del servidor, haga clic en el menú Administrar y seleccione

Agregar roles y características.

Se abre el Asistente para agregar roles y características. En la pantalla Antes de

comenzar, haga clic en Siguiente.

En la pantalla Seleccionar el tipo de instalación, marque Instalar los servicios de

Escritorio remoto y, a continuación, haga clic en Siguiente.

En la pantalla Seleccionar tipo de implementación, marque Implementación estándar y,

a continuación, haga clic en Siguiente.

En la pantalla Seleccionar escenario de implementación, marque Implemen-tación de

escritorio basada en máquina virtual y, a continuación, haga clic en Siguiente.

.En la pantalla Revisar servicios de rol, haga clic en Siguiente.

En la pantalla Especificar servidor de Agente de conexión a Escritorio remoto,

verifique que está seleccionado correctamente su servidor de agente de conexión y haga
clic en Siguiente.
 En la pantalla Especificar servidor de acceso Web de conexión a Escritorio remoto,
verifique que está seleccionado correctamente su servidor de acceso web y haga clic en
Siguiente.

En la pantalla Especificar servidor host de virtualización de Escritorio remoto,

seleccione el servidor que será host de virtualización para los servicios de Escritorio remoto
y marque la opción Crear un nuevo conmutador virtual en los servidores seleccionados
y, a continuación, haga clic en Siguiente.

En la pantalla Confirmar selecciones, marque la opción Reiniciar automáticamente el

servidor de destino en caso necesario y haga clic en el botón Implementar.

El Asistente para agregar roles y características le muestra, ahora, la opción Ver

progreso que le permite supervisar el despliegue de roles y servicios de rol. El servidor
host de virtualización reiniciará dos veces durante la instalación, debido a la instalación del
rol Hyper-V. Cuando finalicen todas las etapas de instalación con éxito, haga clic en
Cerrar.

Ejemplo con un servidor Host de sesión, rds1, que también es servidor de Acceso Web y
Agente de conexión

# Nuevo despliegue de sesiones.

New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv
-WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv

Ejemplo con un servidor Host de virtualización, rdvh1, y un servidor de Acceso Web y

Agente de conexión, rds1.

# Instalación en modo servicio de Escritorio remoto,

# debe instalarse desde otro puesto.
New-RDVirtualDesktopDeployment -ConnectionBroker rds1.MiEmpresa.Priv
-WebAccessServer rds1.MiEmpresa.Priv -VirtualizationHost
rdvh1.MiEmpresa.Priv -CreateVirtualSwitch

# Atribución de permisos de creación y eliminación de VM

# sobre la OU Computers
Grant-RDOUAccess -Domain MiEmpresa.Priv -OU "Computers"
-ConnectionBroker rdvh1.MiEmpresa.Priv

d. Instalación mediante PowerShell

Instalación de los servicios de Escritorio remoto mediante PowerShell

# Instalación en modo roles y características

Install-WindowsFeature -Name NombreDelRol -IncludeManagementTools -
Restart

Este cmdlet le permite instalar roles (y/o características) que siguen al atributo Name, así
como su consola de administración asociada. Si se requiere el reinicio del servidor, se podrá
automatizar gracias al atributo Restart. Es, también, importante destacar que cualquier rol o
servicio de rol necesario para el rol especificado por el atributo Name se instalarán de
manera automática, tales como RPC over HTTP, IIS, .NET Framework 4.5...

Es posible especificar varios roles al mismo tiempo separándolos por comas (por ejemplo:
RDS-SessionHost, RDS-Web-Access, RDS-ConnectionBroker).

Para obtener la lista de roles RDS posibles, instalados o no, puede ejecutar el siguiente
cmdlet:

Get-WindowsFeature *RDS*

Aparece un mensaje de advertencia que le indica que es necesario reiniciar para tener en
cuenta la instalación del rol. Si realiza esta instalación desde el Administrador del
servidor, y el servidor tiene, también, el rol de controlador de dominio, aparecerá una
alerta que le indicará que no se recomienda realizar esta acción. En efecto, instalar el rol de
Escritorio remoto sobre un controlador de dominio conlleva verdaderos riesgos que debe
evaluar cuidadosamente.

Una vez ejecutado el cmdlet, los roles y servicios de rol están instalados, aunque su
servidor no podrá, de momento, responder a las consultas de los clientes puesto que falta,
todavía, configurar los servicios de Escritorio remoto. Esta acción puede realizarse
mediante RDM (Remote Desktop Manager), por directiva de grupo (GPO) o incluso
mediante PowerShell.

Además, para una instalación con varios servidores, con separación de roles, habrá que
utilizar varios cmdlets PowerShell del tipo:

# Instalación en modo roles y características (remoto)

Invoke-Command -ComputerName NombreDeServidor -Command{Install-
WindowsFeature -Name NombreDeRol -IncludeManagementTools -Restart }

El cmdlet PowerShell más eficaz para instalar los servicios de Escritorio remoto basado en
sesiones es el siguiente:

# Instalación del servicio de Escritorio remoto

New-RDSessionDeployment -ConnectionBroker rds1.MiEmpresa.Priv
-WebAccessServer rds1.MiEmpresa.Priv -SessionHost rds1.MiEmpresa.Priv

Tiene la ventaja de instalar y pre-configurar los servicios de Escritorio remoto sobre uno o
varios servidores de forma simultánea, con un único cmdlet.

Para conocer más cmdlets relacionados con la instalación, consulte las secciones
Instalación Inicio rápido e Implementación estándar en este mismo capítulo.

Para tener una idea de todos los cmdlets posibles puede utilizar el siguiente comando
PowerShell:

Get-Command *-RD*

3. Presentación del Administrador de Servicios de Escritorio remoto

En un entorno de Escritorio remoto Windows Server 2012 R2, lo esencial de la

configuración y de la administración de los servicios de Escritorio remoto se realiza
mediante la nueva consola de administración de servicios de Escritorio remoto (RDMS,
Remote Desktop Management Services), o por línea de comando PowerShell.

Como hemos visto durante la instalación, por defecto, una infraestructura de Escritorio
remoto en Windows Server 2012 R2 requiere, como mínimo, tres servicios de rol de
Escritorio remoto:

• RD Connection Broker, que gestiona la infraestructura RDS, las conexiones de los

usuarios y el reparto de carga de red.
• RD Web Access, que se encarga de proveer a los usuarios un portal de acceso Web
para la presentación de las aplicaciones y escritorios públicos.
• Y, o bien RD Session Host (servidor de sesión), o bien RD Virtualization Host
(servidor de escritorio remoto virtual).

A todo esto se le debe agregar, obligatoriamente, un servidor de licencias de servicios de

Escritorio remoto (RD Licensing).

Con Windows Server 2012 R2, los servicios de Escritorio remoto se articulan en torno al
servicio de rol Agente de conexión, incluso aunque sólo tenga un servidor host (de sesión o
de virtualización), y aunque no utilice la gestión de los perfiles de usuario. El servidor que
posee el servicio de rol Agente de conexión es, también, el servidor de implementación de
los servicios de Escritorio remoto, servicio que permite, en particular, configurar el
conjunto de servicios de Escritorio remoto.

La consola de administración de servicios de Escritorio remoto RDMS, integrada con el

Administrador del servidor, le obligará a abrir este último para acceder a la consola RDMS
y configurar, así, su infraestructura RDS.

La primera sección Información general le ofrece, como su propio nombre indica, una
vista general de su infraestructura de servicios de Escritorio remoto. Esta pantalla le
permite agregar servidores a los servicios de Escritorio remoto y, también, administrar la
configuración de alta disponibilidad del servicio de rol Connection Broker. Veremos esto
un poco más adelante en este capítulo.

La segunda sección Servidores le permite ver la lista de servidores que forman parte de su
infraestructura RDS, y le permite, también, agregar roles y características sobre estos
servidores y recopilar eventos. Encontrará, también, la herramienta Best Practice Analyzer
para los servicios de Escritorio remoto, que conviene ejecutar una vez terminadas la
instalación y configuración.
La siguiente sección, Colecciones, le permite modificar, mediante el menú Tareas en la
sección Colecciones, los parámetros de implementación comunes a toda la infraestructura
RDS conectada a su servidor de Agente de conexión, tales como: el método de
autentificación, el modo de licenciamiento, los certificados... También podrá agregar
nuevas colecciones. La sección Conexiones le mostrará todas las conexiones activas sea
cual sea su colección de origen, y desde aquí podrá enviar un mensaje, tomar el control
sobre la sesión (Instantánea en el submenú), forzar la desconexión o cerrar la sesión del
usuario conectado.
Para terminar con la lista de secciones, encontrará, a continuación, la lista de colecciones
disponibles. Con una instalación en modo Inicio rápido, se crea una colección llamada
QuickSessionCollection si su instalación se basa en hosts de sesión o QuickVMCollection
si su instalación se basa en hosts de virtualización. Con cualquier otro modo de instalación,
tendrá que crear una nueva colección para que los usuarios puedan conectarse.

Desde la pantalla de una colección, es posible modificar las propiedades de dicha colección
y gestionar las aplicaciones RemoteApp. Si se trata de una colección de sesión, podrá
agregar servidores host de sesión suplementarios o administrar las conexiones de dicha
colección. Si se trata de una colección de escritorios virtuales, podrá agregar un escritorio
virtual o recrear todos los escritorios virtuales de la colección.

La vista de una colección de sesión QuickSessionCollection:

Vista de una colección de virtualización QuickVMCollection:

Configuración
1. Propiedades de implementación

Para acceder a las propiedades de implementación, abra el Administrador del servidor,

vaya a la sección Servicios de escritorio remoto, Colecciones y, a continuación, en el
menú Tareas seleccione la opción Editar propiedades de la implementación:

• Pestaña Puerta de enlace de Escritorio remoto: permite definir el nombre de la

puerta de enlace de los servicios de Escritorio remoto que debe utilizarse así como
el método de autenticación.
• Pestaña Administración de licencias de Escritorio remoto: permite definir el
modo de licenciamiento (por usuario o por dispositivo) y el servidor de licencias
que se debe utilizar.
• Pestaña Acceso Web a Escritorio remoto: muestra, simplemente, la lista de
servidores de Acceso Web.
• Pestaña Certificados: le permite importar certificados o generar certificados auto-
firmados para los servicios de Escritorio remoto.
 • Pestaña Active Directory (requiere, al menos, un despliegue virtual): permite
indicar la unidad organizativa donde se crearán las cuentas de equipos
correspondientes a los escritorios virtuales de los servicios de Escritorio remoto.

• Pestaña Ubicación de exportación de escritorio virtual (requiere, al menos, un

despliegue virtual): permite especificar la ubicación donde se almacenarán los
modelos de escritorio virtual.

Los parámetros de despliegue afectan a todas las colecciones y todos los servidores
asociados a esta implementación. Todos estos parámetros afectan, por tanto, a la
implementación de los servicios de Escritorio remoto en su conjunto.

2. Configuración de una colección de sesiones

En un entorno RDS en Windows Server 2012 R2, todos los servidores host de sesión de
una misma colección comparten los mismos parámetros de sesión, de seguridad,
de administración de dispositivos...

Observe que un servidor host de sesión no puede pertenecer a más de una colección.
He aquí el procedimiento que debe seguir si ha realizado una instalación en
Implementación estándar o si ha eliminado la colección por defecto o, simplemente, si
desea crear una nueva colección:

Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto,

Colecciones y, a continuación, en el menú Tareas, seleccione Crear colección de
sesiones.

Se abre el asistente Crear colección y aparece la pantalla Antes de comenzar, haga clic
en Siguiente.

En la pantalla Nombre de colección, escriba el nombre de su colección y, eventualmente,

una descripción. A continuación, haga clic en Siguiente.

En la pantalla Especificar servidores host de sesión de Escritorio remoto, seleccione el

o los servidores que formarán parte de dicha colección y, a continuación, haga clic en
Siguiente.

En la pantalla Especificar grupos de usuarios, agregue los grupos de usuarios que

tendrán autorización de acceso sobre la colección y, a continuación, haga clic en Siguiente.

En la pantalla Especificar discos de perfil de usuario, desmarque la opción Habilitar

discos de perfil de usuario, y haga clic en Siguiente.

En la pantalla Confirmar selecciones, haga clic en el botón Crear.

Para finalizar, en la pantalla Ver progreso, haga clic en Cerrar.

He aquí el equivalente en PowerShell:

# Creación de la colección
New-RDSessionCollection -CollectionName MiColeccionDeSesiones
-CollectionDescription "" -SessionHost rds1.MiEmpresa.Priv
-ConnectionBroker rds1.MiEmpresa.Priv

Tendrá, ahora, una colección de servidores de sesión configurada de forma sencilla, sin
aplicaciones RemoteApp.

Propiedades de una colección de Hosts de sesión

He aquí una descripción de las propiedades de una colección de servidores host de sesión:

• Pestaña General: en esta pestaña puede modificar el nombre y la descripción de la

colección. La opción Mostrar la colección de sesiones en Acceso Web de
Escritorio remoto le permitirá mostrar o no la colección en el Acceso Web.
Observe que esta opción no estará disponible si se han publicado aplicaciones
RemoteApp en dicha colección.
#Ejemplo de modificación de la descripción en PowerShell
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones -CollectionDescription "Nueva descripción"

• Pestaña Grupos de usuarios: le permite administrar los grupos de usuarios que

pueden conectarse a los servidores host de sesión y a las aplicaciones RemoteApp
de la colección. Preste atención a los permisos suplementarios que deben aplicarse
para RemoteApp, para saber más consulte la sección que aborda RemoteApp.

# Agregar autorizaciones de conexión para el grupo Usuarios de

# dominio (para definir más grupos, sepárelos con comas).
Set-RDSessionCollectionConfiguration -CollectionName MiColeccionDe
Sesiones -UserGroup "MIEMPRESA\Usuarios de dominio"

• Pestaña Sesión: puede definir la duración de las sesiones inactivas, así como el
comportamiento que desea cuando se alcanza el tiempo de inactividad. ¿Por qué
gestionar estos elementos? Si algún usuario no se desconecta, su sesión, así como
los programas en memoria, permanecen en el servidor. El consumo de recursos del
sistema, mantenido, provoca que el servidor no pueda aceptar conexiones de otros
usuarios.

He aquí una explicación y una recomendación para la configuración:

 • Finalizar una sesión desconectada: cierra de forma arbitraria cualquier sesión
desconectada. Valor propuesto: 2 horas.
• Límite de la sesión activa: obliga al usuario a cerrar su sesión incluso si está
activo. Esto permite luchar contra fugas de memoria en las aplicaciones, y evitar
que un usuario no cierre jamás su sesión. Valor propuesto: 12 horas.
• Límite de la sesión inactiva: cierra de forma arbitraria cualquier sesión mantenida
por un cliente pero que no tiene actividad en el teclado/ratón. Valor propuesto:
4 horas.
• Cuando se alcanza el límite de una sesión o se pierde la conexión: acción que
desea realizar cuando se produce una de ambas situaciones. Valor sugerido
Desconectar de la sesión.

La situación es la siguiente:

El tiempo máximo, antes del cierre de una sesión, es igual a:

Límite de sesión activa + Finalizar una sesión desconectada = 14 horas.

Observará que el usuario dispone, todavía, de 2 horas potenciales para volver a conectarse
sin perder su sesión.

Antes de salvaguardar un servidor de host de sesión por la noche, se recomienda cerrar

todas las sesiones de Escritorio remoto del servidor de forma arbitraria. Esto evita que se
produzcan errores sobre los archivos abiertos en modo exclusivo y permite salvaguardar
perfiles RDS que se copian tras el cierre de sesión sobre su carpeta).

He aquí los comandos equivalentes en PowerShell:

# Límite de sesión y carpeta temporal
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones
-ActiveSessionLimiteMin 720
-IdleSessionLimitMin 240
-BrokenConnectionAction Disconnect
-AutomaticReconnectionEnable $true
-DisconnectedSessionLimitMin 120
-TemporaryFoldersDeletedOnExit $true
-TemporaryFoldersPerSession $true

# Valores admisibles
# los valores numéricos se definen en minutos
# -BrokenConnectionAction None/Disconnect/LogOff

• Pestaña Seguridad: esta pestaña le permite administrar la capa de seguridad y el

nivel de cifrado del protocolo RDP.

He aquí los comandos equivalentes en PowerShell:

# Security
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones
-SecurityLayer Negociate
-EncryptionLevel ClientCompatible
-AuthenticateUsingNLA $true

# Valores admisibles
# -SecurityLayer RDP/Negociate/SSL (por defecto Negociate)
# -EncryptionLevel Low/ClientCompatible/High/FipsCompliant
(por defecto: ClientCompatible)

• Pestaña Equilibrio de carga: si dispone de varios servidores host de sesión en su

colección y éstos no tienen el mejor rendimiento, esta pestaña le será útil para
repartir la carga entre ellos, así como administrar el número máximo de sesiones por
servidor host de sesión.

He aquí los comandos equivalentes en PowerShell:

# Reparto de carga (ejemplo para 2 servidores host de sesión)

$LoadBalanceObjectsArray = New-Object System.Collections.
Generic.List[Microsoft.RemoteDesktopServices.Management.
RDSessionHostCollectionLoadBalancingInstance]

$LoadBalanceSessionHost1 = New-Object Microsoft.RemoteDesktopServices

.Management.RDSessionHostCollectionLoadBalancingInstance
("MiColeccionDeSesiones",80,500,"rds1.MiEmpresa.Priv")

$LoadBalanceObjectsArray.Add($LoadBalanceSessionHost1)

$LoadBalanceSessionHost2 = New-Object Microsoft.RemoteDesktopServices

.Management.RDSessionHostCollectionLoadBalancingInstance
("MiColeccionDeSesiones",100,700,"rds1.MiEmpresa.Priv")
$LoadBalanceObjectsArray.Add($LoadBalanceSessionHost2)
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones -LoadBalancing $LoadBalanceObjectsArray

# Valores admisibles
# -LoadBalancing Array[CollectionName,Weight,NumberOfSessions,
RDSessionHost]

• Pestaña Configuración de cliente: en esta pestaña puede administrar la redirección

del lector de audio y vídeo, las tarjetas y dispositivos Plug-and-Play, etc. para las
conexiones. A esto se le añade la administración de las redirecciones de las
impresoras y el número máximo de pantallas redirigidas.

He aquí los comandos equivalentes en PowerShell:

# Configuración de cliente
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones
-ClientDeviceRedirectionOptions AudioVideoPlayBack,
AudioRecording,SmartCard,PlugAndPlayDevice,Drive,ClipBoard
-ClientPrinterRedirected $true
-ClientPrinterAsDefault $true
-RDEasyPrintDriverEnable $true
-MaxRedirectedMonitors 16

# Valores admisibles
# Varias opciones separadas por comas
# -ClientDeviceRedirectionOptions None/AudioVideoPlayBack/AudioRecording/
# SmartCard/PlugAndPlayDevice/Drive/ClipBoard/COMPort/LPTProt/USBPort/
# TimeZone-MaxRedirectedMonitors [1-16], 16 por defecto

Las CustomRDPProperty son opciones que permiten, en particular, agregar parámetros

complementarios a la conexión RDS. Por ejemplo, un archivo RDP no es sino un conjunto
de CustomRDPProperty, para darse cuenta de esto, edite un archivo RDP con ayuda de
Notepad. Si desea más información acerca de CustomRdpProperty:
http://go.microsoft.com/fwlink/?LinkId=139899

• Pestaña Discos de perfil de usuario: Windows Server 2012 R2 implementa una

nueva forma de administrar los perfiles de los usuarios de los servicios de Escritorio
remoto: los discos de perfil de usuario.

Un disco de perfil de usuario se presenta bajo la forma de un disco virtual con un

formato *.vhdx y contiene, por defecto, los datos del perfil de un usuario, o el
equivalente al perfil de usuario que se encuentra, habitualmente, en
C:\Usuarios\%username%. A esto, puede incluirle carpetas externas al perfil o
excluir carpetas propias del perfil. Los discos del perfil de usuario permiten, por
ejemplo, resolver problemas de sincronización de ciertos tipos de archivos, tales
como los archivos PST de Outlook y los archivos de base de datos como Access.
 Estos discos de perfil de usuario deben almacenarse sobre un recurso compartido
accesible por todos los servidores host de la colección y, preferentemente, por
enlaces de red rápidos. Además, el conjunto de servidores de la colección deben
tener autorización Control Total sobre el recurso compartido y la carpeta asociada.

Cuando un usuario abre una sesión sobre uno de los servidores de la colección, el
servidor monta el disco de perfil de usuario directamente en su carpeta de perfil (por
defecto: C:\Usuarios) mediante un enlace simbólico. Esto resulta transparente al
usuario, y a las aplicaciones.

He aquí los comandos equivalentes en PowerShell:

# Creación de la carpeta de almacenamiento de discos virtuales

# de perfil de usuario (sobre DC2012, en este ejemplo)
mkdir
D:\UserProfileDisk
# Aplicación de los permisos necesarios para usar los discos
# virtuales de perfil usuario (para DC2012 en este ejemplo)
# Permisos asignados en este ejemplo:
# - Control total para RDS1, nuestro servidor RDSH,
# - Control total para el grupo de Administradores de empresas,
# - Control total para la cuenta Sistema,
# - Control total para la cuenta Creador Propietario (sólo
# para aquellas carpetas y archivos hijos).
$RepUserDisk = "D:\UserProfileDisk"
$acl = Get-Acl $RepUserDisk
$acl.SetAccessRuleProtection($True, $False)
$rule = new-object System.Security.AccessControl.
FileSystemAccessRule("MIEMPRESA\RDS1$",
"FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = new-object System.Security.AccessControl.FileSystemAccessRule
("MIEMPRESA\Administradores de empresas", "FullControl",
"ContainerInherit,
ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = new-object System.Security.AccessControl.FileSystemAccessRule
("Sistema", "FullControl", "ContainerInherit,
ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = new-object System.Security.AccessControl.FileSystemAccessRule
("CREADOR PROPIETARIO", "FullControl", "ContainerInherit,
ObjectInherit",
"InheritOnly", "Allow")
$acl.AddAccessRule($rule)
Set-acl $RepUserDisk $acl

# Creación del recurso compartido Userdisk con autorización

# de control total (para DC2012 en este ejemplo)
New-SMBShare -Name UserProfileDisk -Path D:\UserProfileDisk -FullAccess
"MIEMPRESA\RDS1$","MIEMPRESA\Administradores de empresas"

# Configuración de los discos de perfil de usuario

# para una colección de sesiones
Set-RDSessionCollectionConfiguration -CollectionName
MiColeccionDeSesiones
-EnableUserProfileDisk
-DiskPath \\DC2012\UserProfileDisk
-MaxProfileDiskSizeGB 5

# Valores posibles :
# -IncludeFolderPath "RutaDeLaCarpeta"
# -ExcludeFolderPath "RutaDeLaCarpeta"
# -IncludeFilePath "RutaDelArchivo"
# -ExcludeFilePath "RutaDelArchivo"

a. Instalación de una aplicación sobre un servidor de sesiones

Cuando instala una aplicación sobre un servidor RDS, debe indicar que va a tener lugar una
instalación. Para ello, puede utilizar el comando:

change user /install

Una vez terminada la instalación, puede volver al modo estándar:

change user /execute

Si el instalador utiliza la tecnología MSI, el comando change user no es necesario, puede

ejecutarlo directamente.

Esta manipulación no es obligatoria en Windows Server 2012 R2 con las aplicaciones

certificadas para Windows Server 2012 o Windows Server 2012 R2, aunque supone una
buena práctica si la aplicación que instala es anterior y no está certificada para Windows
Server 2012/2012 R2.

Windows Server 2012 existe, únicamente, en versión de 64 bits. Wow64 permite ejecutar
aplicaciones de 32 bits mediante emulación. Esto supone, en cualquier caso, una carga
complementaria y no permite aprovechar al máximo la capacidad de la plataforma técnica.
Verifique sistemáticamente si existe una versión de 64 bits antes de instalar el componente
o la aplicación en cuestión.

b. Mantenimiento de un servidor de sesiones

A diferencia de un servidor Web, por ejemplo, pasar un servidor host de sesiones al modo
de mantenimiento es más complicado de cara a los usuarios. Pueden tener documentos
abiertos, no salvaguardados, correos electrónicos en curso, etc. Afortunadamente, existen
herramientas adaptadas a estas situaciones disponibles para cortar el servicio de forma
controlada.

Para empezar, puede autorizar o no el inicio de sesión de un usuario mediante el comando

change logon. Este comando acepta varios argumentos:
 • /QUERY: muestra el modo de inicio de sesión actual.
• /ENABLE: autoriza los inicios de sesión de usuario.
• /DISABLE: prohíbe los inicios de sesión de usuario.
• /DRAIN: prohíbe los nuevos inicios de sesión de usuario, aunque autoriza las
reconexiones a las sesiones existentes.
• /DRAINUNTILRESTART: prohíbe los nuevos inicios de sesión de usuario hasta
que el servidor haya reiniciado, aunque autoriza las reconexiones a las sesiones
existentes.

Para cerrar todas las conexiones a la vez, puede utilizar el siguiente script:

for /f "skip=2 tokens=2," %i in (’query session’) do logoff %i

El comando query session permite enumerar todas las sesiones de usuario del servidor.

Una vez se obtiene la lista de sesiones, anote el número de sesión para el que desea realizar
alguna acción. A continuación, podrá:

• Cerrar la sesión (cierra todas las aplicaciones abiertas, sin realizar una copia de
seguridad): logoff XXX
• Desconectar al usuario (todas las aplicaciones siguen abiertas, aunque el usuario se
desconecta): tsdiscon XXX
• Eliminar una sesión por la fuerza: session reset XXX
• Conectarse a esta sesión: tscon XXX
• Enviar un mensaje al usuario: msg XXX « Cierre, por favor, su sesión »

c. Mejora en la experiencia de usuario sobre un servidor de sesiones

Instalación de la experiencia del usuario

La experiencia del usuario supone agregar la funcionalidad Experiencia de escritorio,

presente por defecto en una edición cliente de Windows (como, por ejempo, Windows 8.1),
sobre los servidores host de sesión. Esto incluye, en particular, al lector Windows Media, la
reproducción de archivos AVI, el centro de sincronización, la grabadora de Windows,
Herramientas de captura de pantalla, temas de Windows y la gestión multi-pulsación.

Para aprovechar todo esto, instale las características Experiencia de escritorio y Servicios
de Escritura con lápiz y Escritura a mano. Reinicie el servidor.
Para aprovechar plenamente las mejoras gráficas aportadas por la activación de la
experiencia del usuario (del lado servidor), necesitará una conexión con alta tasa de
trasferencia entre el cliente y el servidor (como mínimo 10 Mb/s) y configurar el cliente
RDP.
Activación de la experiencia del usuario auditiva

Para aprovechar completamente el uso del sonido en una sesión de Escritorio remoto, es
necesario iniciar el servicio Audio de Windows y configurarlo en arranque automático.

Gestión del entorno mediante directivas de grupo

Es posible, incluso necesario, recurrir a una directiva de grupo para modificar el entorno de
los usuarios que abran una sesión sobre el host de sesión. Será posible mostrar u ocultar
iconos en el escritorio o prohibir el acceso a ciertos dispositivos, o configurar los
parámetros de Internet Explorer, por ejemplo.

Para ello, tendrá que crear una nueva directiva de grupo y asociarla a la unidad organizativa
que contenga sus servidores de host de sesión. Defina los parámetros de usuario de la
directiva tal y como desee, y habilite la opción Configurar el modo de procesamiento de
bucle invertido de la directiva de grupo de usuario seleccionando el modo Combinar.
Encontrará este parámetro en Configuración del equipo - Directivas - Plantillas
administrativas - Sistema/Directiva de grupo.
Administración de la impresión

La gestión de la impresión y, en particular, de los controladores de las impresoras sigue

siendo un asunto importante en un entorno de Terminal Services. Windows Server 2012 R2
utiliza la funcionalidad Easyprint para superar los distintos problemas. Se implementa en
tsprint.dll, tanto en 32 como en 64 bits, del lado cliente o del lado servidor. Los requisitos
previos del lado cliente son los siguientes:

• Cliente RDC 6.1 como mínimo.

• Framework .Net 3.0 Service Pack 1.

Observe que, si el cliente no cumple estos requisitos previos, será preciso instalar los
controladores de impresión sobre el servidor.

De otro modo, Easyprint permite ver, desde el servidor RDS, el conjunto de propiedades de
la impresora, sin tener que instalar el controlador en el propio servidor. Para ello, se
comporta como un proxy y redirige todas las llamadas a la interfaz sobre el controlador del
lado cliente. Convierte la impresión de un formato GDI a un formato XPS (siempre que no
se trate ya de un formato XPS) sobre el servidor, y lo envía al cliente en la sesión RDP, a
través de un canal virtual (XPS over RDP). Una vez en el puesto cliente, si el controlador
de impresión es compatible con XPS, el documento se imprime directamente. En caso
contrario, se convierte de nuevo del formato XPS al formato GDI y se imprime.
Ahora, es posible restringir el número de impresoras que se conectan desde el puesto
cliente mediante una GPO. El inicio de sesión se ve, así, acelerado, y la impresora por
defecto del puesto cliente basta en la mayoría de casos.

Para aplicar esta restricción mediante GPO, debe habilitar el parámetro: Configuración del
equipo - Plantillas administrativas - Componentes de Windows - Servicios de
Escritorio remoto - Host de sesión de Escritorio remoto - Redirección de impresora.

3. Configuración de una colección de escritorios virtuales

El Escritorio remoto y VDI (Virtual Desktop Infrastructure) resultan una solución

integrada. A diferencia de los servicios de Escritorio remoto clásicos donde varios usuarios
abrían una sesión sobre un servidor host de sesión, una infraestructura de escritorios
virtuales le permite dedicar una máquina virtual a cada usuario, y éstos se conectan a su
máquina virtual a través de los servicios de Escritorio remoto.

Hyper-V soporta los escritorios virtuales, en particular mediante el servicio de Agente de

conexión de los servicios de Escritorio remoto y, eventualmente, SCVMM (el
administrador de máquinas virtuales). El objetivo es complementario al de un servidor de
Escritorio remoto clásico: se trata de proveer un escritorio remoto sobre un cliente
Windows (Windows 8.1, por ejemplo) a un usuario. Esta asignación puede ser temporal
(pool de VM) o permanente (escritorio personal).

Esta flexibilidad permite cubrir necesidades muy específicas:

 • Ciertas aplicaciones que no funcionan o no están soportadas salvo en un OS cliente,
o donde el modelo de licenciamiento es más ventajoso con OS de tipo cliente.
• Ciertos usuarios deben tener privilegios de «administrador» sobre la máquina
(desarrolladores remotos, etc.). De este modo, no son administradores de servidores
de servidores RDS. Gracias a los escritorios virtuales personales, el usuario es
administrador de la máquina virtual donde está conectado, y ya no sobre el todo
servidor.
• En el caso de aplicaciones temporales, cuando finaliza la solución temporal, la
máquina virtual vuelve, automáticamente, a su estado final (disco de rollback).

Este tipo de arquitectura está orientada a una solución multiservidor:

• Un servidor que juega el rol de agente de conexión y despacha las conexiones de los
usuarios (RDS-Connection-Broker).
• Uno o varios servidores Hyper-V que albergan máquinas virtuales. Estas máquinas
deben ser estrictamente idénticas (con los mismos programas instalados).
• Las máquinas virtuales deben ser de primera generación, pues las máquinas
virtuales de segunda generación no están soportadas.

Como con las colecciones de sesiones, con un entorno RDS en Windows Server 2012,
todos los servidores host de virtualización de una misma colección comparten los mismos
parámetros de sesión, de seguridad, de gestión de dispositivos...

He aquí cómo crear una nueva colección de escritorios virtuales en pool:

Abra el Administrador del servidor, navegue a la sección Servicios de Escritorio

remoto, Colecciones y, a continuación, en el menú Tareas seleccione la opción Crear una
colección de escritorios virtuales.

Se abre el asistente Crear una colección y aparece la pantalla Antes de empezar, haga
clic en Siguiente.

En la pantalla Asignar nombre a la colección, escriba el nombre de su colección y,

eventualmente, una descripción. A continuación, haga clic en Siguiente.

En la pantalla Especifique el tipo de colección, seleccione el tipo de colección que desea

aplicar y haga clic en Siguiente.

En la pantalla Especifique la plantilla de escritorio virtual, seleccione un modelo que

haya creado previamente y, a continuación, haga clic en Siguiente.

En la pantalla Especificar configuración de escritorio virtual, seleccione la opción

Proporcionar configuración de instalación desatendida y haga clic en Siguiente.
 En la pantalla Especificar la configuración de instalación desatendida, seleccione el
huso horario, el dominio y, eventualmente, una unidad organizativa y, a continuación, haga
clic en Siguiente.

En la pantalla Especifique los usuarios y grupos de usuarios, si fuera necesario, agregue

los grupos de usuario que tendrán permisos de acceso a la colección, modifique el número
de escritorios virtuales que desea crear y el prefijo del nombre. A continuación, haga clic en
Siguiente.

En la pantalla Especificar asignación de escritorio virtual, haga clic en Siguiente.

En la pantalla Especificar almacenamiento de escritorios virtuales, puede modificar el

tipo y la ubicación del almacenamiento de los escritorios virtuales (archivos de las
máquinas virtuales). En nuestro ejemplo, mantendremos los valores por defecto, haciendo
clic en Siguiente.

En la pantalla Especificar discos de perfil de usuario, desmarque la opción Habilitar

discos de perfil de usuario, y haga clic en Siguiente.

En la pantalla Confirmar selecciones, haga clic en el botón Crear, aparece la pantalla

Ver progreso que le muestra el grado de avance.

Para terminar, en la pantalla Ver resultados, haga clic en Cerrar.

He aquí los comandos equivalentes en PowerShell:

# Creación de la colección
New-RDVirtualDesktopCollection -CollectionName MiColeccionDeVMs
-Description ""
-PooledManaged
-VirtualDesktopTemplateName "Windows 8.1 Ent - Sysprep"
-VirtualDesktopTemplateHostServer rdvh1.MiEmpresa.Priv
-VirtualDesktopAllocation @{"rdvh1.MiEmpresa.Priv" = 2}
-Domain "MiEmpresa.Priv"
-OU "OU=Escritorios virtuales,DC=miempresa,DC=priv"
-UserGroup "MIEMPRESA\Usuarios de dominio"
-StorageType LocalStorage
-VirtualDesktopNamePrefix Win8ent
-ConnectionBroker rds1.MiEmpresa.Priv
-UserProfileDiskPath \\DC2012\UserProfilDisk
-MaxUserProfileDiskSizeGB 5

# El parámetro PooledManaged puede remplazarse por:

# -PooledManaged
# -PooledUnmanaged
# -PersonnalManaged
# -PersonnalUnmanaged
#
# El parámetro CustomSysprepUnattendFilePath permite indicar la
# ruta hacia un archivo de respuestas de sysprep de formato XML
# -CustomSysprepUnattendFilePath "RutaDelArchivoXML"

Una vez ejecutado este cmdlet, las cuentas de equipo para los escritorios virtuales se crean
correctamente en la unidad organizativa Escritorios virtuales.
Propiedades de una colección de Host de virtualización

• Pestaña General: esta pestaña presenta la misma información que para una
colección de sesiones con algunos datos suplementarios, tales como la posibilidad
de habilitar el retraso de guardado.

He aquí los comandos equivalentes en PowerShell:

# Configuración del cliente

Set-RDVirtualDesktopCollectionConfiguration
-CollectionName MiColeccionDeVMs
-CollectionDescription ""

# Valores posibles
# -SaveDelayMinutes

• Pestaña Escritorios virtuales: todos los campos son de solo lectura. Algunos
pueden configurarse durante la creación de la colección, y otros en la configuración
de la implementación.
• Pestaña Grupos de usuarios: esta herramienta es idéntica a la pestaña Grupos de
usuarios para una colección de sesiones.

He aquí los comandos equivalentes en PowerShell:

# Agregar autorizaciones de conexión para el grupo Usuarios de
# dominio (para definir varios grupos, sepárelos por comas).
Set-RDVirtualDesktopCollectionConfiguration -CollectionName
MiColeccionDeVMs -UserGroup "MIEMPRESA\Usuarios de dominio"

• Pestaña Cliente: encontrará en esta pestaña la misma información que para una
colección de sesiones.

He aquí los comandos equivalentes en PowerShell:

# Configuración del cliente

Set-RDVirtualDesktopCollectionConfiguration
-CollectionName MiColeccionDeVMs
-ClientDeviceRedirectionOptions AudioVideoPlayBack,
AudioRecording,SmartCard,PlugAndPlayDevice,Drive,ClipBoard
-RedirectClientPrinter $true
-RedirectAllMonitors $true

# Valores posibles
# Es posible seleccionar varios separados por comas
# -ClientDeviceRedirectionOptions None/AudioVideoPlayBack/AudioRecording
# /SmartCard/PlugAndPlayDevice/Drive/ClipBoard/COMPort/LPTProt/USBPort/
# TimeZone

• Pestaña Discos de perfiles de usuario: esta pestaña es idéntica a la pestaña Discos

de perfil de usuario de una colección de sesiones.

He aquí los comandos equivalentes en PowerShell:

# Creación de la carpeta de almacenamiento de discos virtuales

# de perfil de usuario
mkdir UserProfileDisk on c:\
New-SMBShare -Path D:\UserProfileDisk -Name UserProfileDisk

# Agregar autorizaciones de conexión para el grupo de Usuarios de

# dominio (para definir varios grupos, sepárelos por comas).
Set-RDVirtualDesktopCollectionConfiguration -CollectionName
MiColeccionDeVMs
-EnableUserProfileDisk
-DiskPath \\DC2012\UserProfileDisk
-MaxProfileDiskSizeGB 5

# Valores posibles :
# -IncludeFolderPath "RutaDeLaCarpeta"
# -ExcludeFolderPath "RutaDeLaCarpeta"
# -IncludeFilePath "RutaDelArchivo"
# -ExcludeFilePath "RutaDelArchivo"
a. Agregar escritorios virtuales a una colección - Creación de un escritorio virtual

Puede resultar útil saber cómo agregar escritorios virtuales a una colección de escritorios
virtuales. Para ello, simplemente hay que seguir el siguiente procedimiento sencillo:

Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto,

Colecciones, y el nombre de su colección (MiColeccionDeVMs, en nuestro ejemplo) y, a
continuación, en la sección Escritorios virtuales, haga clic en el menú Tareas y seleccione
Agregar un escritorio virtual.

Se abre el asistente Agregar escritorios virtuales, indique el número de escritorios

virtuales que desea agregar y haga clic en Siguiente.

En la pantalla Especificar asignación de escritorio virtual, haga clic en Siguiente.

En la pantalla Confirmar selecciones, haga clic en el botón Crear.

Para finalizar, en la pantalla Ver resultados, haga clic en el botón Cerrar.

He aquí los comandos equivalentes en PowerShell:

# Agregar escritorios virtuales a una colección

Add-RDVirtualDesktopToCollection -CollectionName MiColeccionDeVMs
-VirtualDesktopAllocation @{"rdvh1.MiEmpresa.Priv"=1}

4. Desplegar aplicaciones con RemoteApp

Este servicio de rol hace RDS muy atractivo. Permite publicar aplicaciones en lugar de un
escritorio completo. Esta capacidad para publicar una aplicación permite una mejor
integración de dicha aplicación en el entorno habitual del usuario, que tendrá la impresión
de que la aplicación se ejecuta, directamente, en su puesto (como si fuera una ventana más).

Con la configuración del cliente RemoteApp, la aplicación aparecerá en la pantalla de

bienvenida (menú inicio) y la asociación de la extensión del archivo se realizará con el
puesto cliente. Por ejemplo, si Microsoft Visio sólo está disponible mediante RemoteApp,
el cliente RemoteApp puede asociar la extensión.vsd con esta aplicación publicada. De este
modo, cuando un usuario hace doble clic sobre un archivo local.vsd, Microsoft Visio se
abre automáticamente como RemoteApp y abre el archivo solicitado. La operación es, por
tanto, transparente de cara al usuario.

Ya no es posible crear el archivo.rdp o el paquete .msi con Windows Server 2012 R2,
tendrá que crearlo a mano si no quiere utilizar la configuración del cliente RemoteApp en
los puestos cliente.

Con Windows Server 2012 R2, las aplicaciones RemoteApp se publican a nivel de la
colección.
A continuación se muestra cómo configurar una aplicación RemoteApp que se publica en
un escritorio virtual:

Abra el Administrador del servidor y vaya a una colección de sesiones, o de escritorios

virtuales. A continuación, en la zona principal de la ventana, haga clic en el menú Tareas y
en la sección RemoteApp, seleccionando la opción Publicar programas RemoteApp.

Si publica una aplicación en un escritorio virtual, debe escoger el escritorio virtual sobre el
que se encuentra la aplicación que quiere publicar. Es lo que le permite hacer la siguiente
pantalla Seleccionar escritorio virtual. Una vez lo haya seleccionado, haga clic en
Siguiente.

En el asistente Publicar programas RemoteApp, en la página Seleccionar programas

RemoteApp, marque la opción correspondiente al programa que desea publicar (la
calculadora, en este ejemplo) y, a continuación, haga clic en Siguiente.

En la pantalla Confirmación, haga clic en el botón Publicar.

Espere algunos segundos hasta que se publique la aplicación y, a continuación, en la

página Última etapa haga clic en el botón Cerrar.

He aquí los comandos equivalentes en PowerShell:

# Publicación de la Calculadora mediante RemoteApp

# por un servidor de sesiones
New-RDRemoteApp -CollectionName MiColeccionDeSesiones -ConnectionBroker
rds1.MiEmpresa.Priv -DisplayName Calculadora -Alias Calculadora
-FilePath "C:\Windows\system32\calc.exe" -ShowInWebAccess $true
-RequiredCommandLine $false

# Publicación de la Calculadora mediante RemoteApp

# por un servidor de escritorio virtual
New-RDRemoteApp -CollectionName MiColeccionDeVMs -VirtualDesktopName
Win8Ent-0 -ConnectionBroker rds1.MiEmpresa.Priv -DisplayName
Calculadora -Alias Calculadora -FilePath
"C:\Windows\system32\calc.exe" -ShowInWebAccess $true
-RequiredCommandLine $false

Observe que la publicación de una aplicación oculta, automáticamente, el acceso web del
escritorio, mientras que muestra la aplicación publicada mediante RemoteApp.

Podrá gestionar las propiedades de la aplicación RemoteApp mediante la interfaz gráfica o

mediante los siguientes cmdlets PowerShell:

• Get-RemoteApp: muestra la lista de aplicaciones RemoteApp publicadas.

• New-RemoteApp: publica una nueva aplicación RemoteApp.
• Set-RemoteApp: modifica las propiedades de una aplicación RemoteApp.
• Remove-RemoteApp: elimina una aplicación RemoteApp.
Para finalizar, observe que es posible precisar los permisos de acceso de los usuarios a las
aplicaciones RemoteApp mediante la pantalla Asignación de usuarios en las propiedades
de la aplicación RemoteApp.

Del lado del puesto cliente, la configuración del cliente RemoteApp es muy sencilla y
puede hacerse mediante la interfaz gráfica o mediante GPO. No obstante, si el certificado
de su servidor Broker es autorfirmado, tendrá que instalarlo en la Entidad de certificación
raíz de confianza del equipo cliente.

A continuación se muestra cómo realizar la configuración del cliente Remote App mediante
la interfaz gráfica:

Abra Conexiones remotas accesible en el Panel de control y haga clic en el enlace Acceso
a los programas RemoteApp y servicios de Escritorio remoto.

En el campo Dirección URL de conexión o dirección de correo electrónico escriba la

URL https://NombreDeSuServidorRDS/rdweb/feed/webfeed.aspx (rds1.MiEmpresa.Priv en
nuestro ejemplo) y haga clic en Siguiente.

En la pantalla Listo para configurar la conexión, haga clic en Siguiente.

En la pantalla Configuró correctamente la siguiente conexión, haga clic en Finalizar.

Si quiere configurar los puestos de cliente mediante una directiva de grupo, cree una nueva
directiva de grupo y vaya a Configuración de usuario - Directivas - Plantillas
administrativas - Componentes de Windows - Servicios de Escritorio remoto -
Conexión de RemoteApp y Escritorio.
Habilite el parámetro Especificar la dirección URL de conexión predeterminada y
escriba la URL correspondiente a su servidor que posea el servicio de rol Agente de
conexión para los servicios de Escritorio remoto

Este parámetro de directiva de grupo sólo se aplica a aquellos sistemas operativos Windows
Server 2012, Windows 8 y Windows RT. Con sistemas operativos anteriores, tendrá que
realizar una configuración manual.

Configuración avanzada
1. Configuración del Acceso Web de los servicios de Escritorio remoto

El uso de RDS se ha extendido mucho más allá de un simple escritorio remoto. Windows
Server 2012 ofrece, ahora, un medio para centralizar los recursos publicados sobre un
portal Web. Desde el punto de vista del cliente, siguen siendo necesarios dos criterios:

• Poder acceder al sitio Web que ofrece el acceso Web desde un navegador de
Internet, con o sin proxy.
• Tener instalado el cliente RDC 7.0 como mínimo.

Este servicio de rol puede instalarse sobre un servidor que tenga o no otros servicios de rol
de Escritorio remoto. Requiere, no obstante, como mínimo IIS 8.5 para poder funcionar y
una relación de confianza con los servidores host de sesión para poder enumerar las
aplicaciones RemoteApp. Generalmente, ya viene instalado si ha realizado la instalación
Inicio rápido o Implementación estándar.

Es posible agregar el servicio de rol Acceso Web para Escritorio remoto mediante la
interfaz gráfica o mediante PowerShell.

# Agregar un servidor de Acceso Web

Add-RDServer -Server MiServidorWebRDS -Role rds-web-access
-ConnectionBroker rds1.MiEmpresa.Priv

Para acceder al servicio, abra un navegador Web en la siguiente dirección, remplazando

MiServidorWebRDS por el nombre del servidor que tenga dicho servicio de rol:
http://MiServidorWebRDS/RDWeb/

El nuevo portal de Acceso Web gestiona, ahora, navegadores como Mozilla Firefox o
Google Chrome así como Microsoft Internet Explorer (si bien este último presenta ciertas
ventajas tales como una mejor gestión de la autenticación, por ejemplo).

Por defecto, la autenticación se realiza mediante un portal (formulario):

Una vez autentificado, se muestra la siguiente página:
Se presentan dos pestañas. La pestaña RemoteApp y escritorios se configura
dinámicamente con las aplicaciones y escritorios a los que tiene permisos para acceder si la
funcionalidad RemoteApp se ha configurado. La pestaña Conectarse a un equipo remoto
permite abrir una sesión RDP completa sobre el servidor especificado en el sitio Web.

La pestaña Conectarse a un escritorio remoto ofrece varias opciones, aunque no permite

escoger el servidor sobre el que abrir una conexión. Para configurar el servicio, tiene dos
opciones posibles:

• Dejar que el Administrador de servicios de Escritorio remoto se las apañe él solo

(opción recomendada).
• Utilizar la MMC IIS 8.5.
• Editar el archivo de configuración XML, web.config, ubicado por defecto en la ruta
C:\Windows\Web\RDWeb\Pages.

Configuración mediante IIS:

Abra la consola Administrador de servicios de Internet (IIS) desde la pantalla de

bienvenida, Herramientas administrativas y, a continuación, Administrador de
servicios de Internet (IIS).

En la pestaña Conexiones, despliegue el nombre de su servidor y, a continuación, Sitios -

Default Web Site - RDWeb y, por último, la carpeta virtual Pages.

Haga clic dos veces en el icono Configuración de aplicaciones en la parte central de la

pantalla:
El sitio de acceso RDWeb puede incorporarse en un sitio SharePoint, pues se trata de un
Webpart. Esta opción no se aborda en este libro, puesto que SharePoint se sale de su
perímetro.

Los parámetros configurables son los siguientes:

DefaultTSGateway: permite especificar la puerta de enlace por defecto que utilizarán las
conexiones. Por defecto, no existe ninguna puerta de enlace predeterminada. Una vez la
seleccionada la aplicación RemoteApp o el escritorio remoto, se abre una conexión RDP
clásica sobre el puerto 3389 TCP.

GatewayCredentialsSource: puede tomar los valores 0, 1 o 4. El valor por defecto es 4,

que se corresponde con "preguntarme más tarde".

ShowDesktops: con el valor true por defecto. Esta variable controla el hecho de que se
muestre o no la pestaña Escritorio remoto en el sitio Web.

xClipboard: con el valor true por defecto. Bloquea el uso del portapapeles de Windows si
su valor es false.
xDriveRedirection: con el valor false por defecto. Autoriza la redirección de los lectores
locales si su valor es true.

xPnPRedirection: con el valor false por defecto. Autoriza la redirección de dispositivos de

tipo plug & play si su valor es true. Esto aplica únicamente a los dispositivos multimedia
que trabajan con los protocolos Media Transfer Protocol, Picture Transfer Protocol o
Microsoft Point of Service (POS) for .NET 1.11.

xPortRedirection: con el valor false por defecto. Autoriza la redirección de los puertos
COM y LPT si su valor es true.

xPrinterRedirection: con el valor true por defecto. Bloquea la redirección de las

impresoras si su valor es false.

Utilizar el archivo XML web.config presenta la ventaja de que se tiene acceso a los
comentarios que explican los distintos valores, por ejemplo, para
GatewayCredentialsSource:

<!-- GatewayCredentialsSource: TS Gateway Authentication Type.

Admins can preset this.
0 = User Password
1 = Smartcard
4 = "Ask me later"
-->

Las modificaciones se aplican en caliente y no se requiere ningún reinicio. Basta con

refrescar la página Web para ver los cambios.

Por defecto, las aplicaciones RemoteApp están habilitadas para el Acceso Web. Esta
autorización puede gestionarse por aplicación, desde la consola Administrador de
RemoteApp.

2. Configuración de la Puerta de enlace de Escritorio remoto

El uso de RDS se ha extendido más allá de los límites de la empresa. Una vez fuera del
lugar de trabajo, no controlamos la infraestructura implementada, así como sus
restricciones. La apertura de una conexión sobre el puerto 3389 TCP desde otra empresa,
desde un hotel o desde cualquier otro lugar público puede estar bloqueada por firewalls, lo
cual limita la aplicación de los servicios de Escritorio remoto. Windows Server 2012 R2
ofrece un medio de transporte adaptado a este contexto para acceder a los recursos: HTTPS.

El primer requisito previo consiste en disponer de un certificado SSL válido, bien emitido
por un tercero de confianza, o bien desde su propia infraestructura de PKI. Windows Server
2012 R2 le permite generar un certificado auto-firmado, aunque esto implica poder agregar
este certificado raíz en los equipos que se utilizan para conectarse. Esta solución puede
resultar algo excesiva, aunque la experiencia del usuario no es óptima, y va a ser
problemática para la conexión desde un equipo sencillo desde un hotel, por ejemplo. Lo
principal es que el puesto cliente considere su certificado como digno de confianza.

A continuación se muestran los atributos del certificado y las reglas que deben respetar:

• El certificado debe ser de tipo equipo.

• El objetivo del certificado es la autenticación del servidor. El atributo EKU es de
tipo Server Authentication (1.3.6.1.5.5.7.3.1).
• El certificado no debe haber expirado.
• No se requiere un OID de 2.5.29.15, aunque si quiere utilizarlo, debe tener también
uno de estos usos: CERT_KEY_ENCIPHERMENT_KEY_USAGE,
CERT_KEY_AGREEMENT_KEY_USAGE, y
CERT_DATA_ENCIPHERMENT_KEY_USAGE;
• El nombre del certificado (CN) debe corresponderse con el nombre DNS utilizado
por el cliente que se conecta a la puerta de enlace.

Instalación de la Puerta de enlace de Escritorio remoto:

Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto e

Información general y, a continuación, haga clic en el icono con el signo ”+” en la Puerta
de enlace de Escritorio remoto sobre el esquema central (o haga clic en el menú Tareas de
la sección Servidor de implementación, y seleccione la opción Agregar servidores de
puerta de enlace de Escritorio remoto).

En la pantalla Seleccionar servidor, seleccione el o los servidores que asegurarán el rol de

puerta de enlace, y haga clic en Siguiente.

En la pantalla Nombre del certificado SSL autofirmado, escriba el nombre de dominio

completo (FQDN) que utilizarán los clientes para conectarse (generalmente el nombre de
dominio público, webapp.MiEmpresa.es) y, a continuación, haga clic en Siguiente.

En la pantalla Confirmar selecciones, haga clic en el botón Agregar.

Una vez terminada la instalación, en la pantalla Ver progreso, haga clic en el botón
Cerrar.

He aquí los comandos equivalentes en PowerShell:

# Instalación del servicio de rol RDS-Gateway

Add-RDServer -Role RDS-Gateway -GatewayExternalFqdn
webapp.MiEmpresa.es-Server rds1.MiEmpresa.Priv
-ConnectionBroker rds1.MiEmpresa.Priv

# Depuración...
Set-RDDeploymentGatewayConfiguration -GatewayMode Custom
-GatewayExternalFqdn webapp.MiEmpresa.es -LogonMethod GatewayAuthMode
-UseCachedCredentials $true -BypassLocal $true -Force
Observe que el cmdlet Add-Server instala el servicio de rol Puerta de enlace de Escritorio
remoto, así como todas las dependencias tales como RPC over HTTP e IIS, sobre el o los
servidores afectados. Crea, también, un certificado autofirmado y lo asocia con el servicio
Puerta de enlace de Escritorio remoto. No obstante, con Windows Server 2012, este cmdlet
finaliza con dos errores ligados a dos comandos incorrectos en el archivo de script
Despliegue del módulo PowerShell. Por este motivo, proporcionamos un segundo cmdlet
que termina el trabajo... Este cmdlet no es inútil, por el contrario, en un servidor Windows
Server 2012 R2 puesto que se ha corregido el error en esta versión.

Por defecto, la instalación genera un certificado autofirmado que resulta útil para una fase
de pruebas. Para un entorno de producción, se recomienda encarecidamente utilizar un
certificado obtenido a través de una entidad emisora de certificados reconocida.

Para configurar la Puerta de enlace de Escritorio remoto:

Abra la consola Administrador de puerta de enlace de Escritorio remoto desde la

pantalla de inicio, Herramientas administrativas - Servicios de Escritorio remoto y, a
continuación, Administrador de puerta de enlace de Escritorio remoto.

En el panel izquierdo, haga clic con el botón derecho sobre el nombre de su servidor y, a
continuación, haga clic en Propiedades. He aquí algunas pestañas interesantes:

• La pestaña General: permite limitar el número de conexiones simultáneas o

prohibir nuevas conexiones.
• La pestaña Certificado SSL: permite administrar el certificado que presenta la
puerta de enlace al cliente. Puede generar un certificado autofirmado mediante una
entidad emisora de certificados.
• La pestaña Configuración de transporte: permite modificar los puertos de red
utilizados por los protocolos HTTP y HTTPS. Observe la presencia del transporte
UDP sobre el puerto 3391, que permite optimizar los flujos de red
Cierre las propiedades del servidor.

Despliegue la carpeta Directivas, seleccione Directivas de autorización de conexiones y,

a continuación, edite las propiedades de la directiva RDG_CAP_AllUsers.
• En la pestaña Requisitos, puede modificar los usuarios y grupos de usuarios que
pueden conectarse mediante la puerta de enlace de Escritorio remoto.
• La pestaña Redirección de dispositivos le permite limitar la redirección de
dispositivos cuando se está conectado a través de la puerta de enlace.
• La pestaña Tiempos de espera le permite limitar el tiempo de espera de inactividad
de una sesión o el tiempo de espera de expiración de una sesión. Se recomienda
configurar un valor pequeño para el tiempo de espera de inactividad, 15 minutos es
incluso demasiado si una sesión se ha abierto desde un sitio público y no tiene
supervisión alguna.
 Despliegue la carpeta Directivas, seleccione Directivas de autorización de recursos y, a
continuación, edite las propiedades de la directiva RDG_AllDomainComputers.
• En la pestaña Grupos de usuarios, puede modificar los usuarios y grupos de
usuarios que pueden conectarse a los equipos remotos mediante la puerta de enlace
de Escritorio remoto.
• La pestaña Recurso de red le permite definir cuáles serán los equipos remotos a los
que podrán conectarse los usuarios a través de la puerta de enlace. Es importante
definir los equipos a los que los usuarios pueden acceder a través de la puerta de
enlace. Es posible definir un grupo de Active Directory, un grupo gestionado por la
puerta de enlace de Escritorio remoto, o bien todos los equipos. En producción,
debería ser lo más restrictivo posible a la hora de abrir el acceso.
• La pestaña Puertos permitidos permite definir los puertos de red autorizados. Por
defecto, sólo está autorizado el puerto TCP 3389, que es el puerto RDP por defecto.
Para terminar, verifique que su despliegue está bien configurado para utilizar la puerta de
enlace de Escritorio remoto:

Abra el Administrador del servidor - Servicios de Escritorio remoto - Colecciones y, a

continuación, haga clic en el menú Tareas y seleccione la opción Editar propiedades de
la implementación.

En la pestaña Puerta de enlace de Escritorio remoto, verifique que la opción Usar esta
configuración del servidor de puerta de enlace de Escritorio remoto está marcada y el
nombre completo de su servidor de puerta de enlace bien informado. Si no fuera el caso,
hágalo así.
La pasarela RDS está, ahora, operativa. Posee un certificado SSL autogenerado y se han
definido dos directivas. Todos los usuarios del dominio pueden utilizar la puerta de enlace
para acceder a cualquier equipo de la red.

3. Configuración del Administrador de licencias de Escritorio remoto

Las licencias RDS propuestas son de dos tipos:

• Por dispositivo, sea cual sea el número de usuarios que utilicen este dispositivo para
acceder a los recursos RDS.
• Por usuario, sea cual sea el dispositivo utilizado para acceder a recursos RDS.

En su arquitectura, puede ser adecuado instalar, por ejemplo, el Administrador de

licencias sobre el servidor que ejecuta KMS (Key Management System). Si este servicio de
rol está instalado sobre un controlador de dominio, todos los servidores RDS del dominio
(independientemente de la versión) serán capaces de encontrarlo automáticamente. Si su
infraestructura RDS sólo incluye servidores Windows Server 2012 o Windows Server 2012
R2, es preferible instalar el Administrador de licencias sobre el servidor Agente de
conexión.

Para instalar el servidor de licencias RDS:

Abra el Administrador del servidor, vaya a la sección Servicios de Escritorio remoto e

Información general y, a continuación, haga clic en el icono con el signo "+" a nivel de
Administrador de licencias de Escritorio remoto sobre el esquema central (o haga clic en el
menú Tareas en la sección Servidor de implementación, y seleccione la opción Agregar
servidores de licencias de Escritorio remoto).

En la pantalla Seleccionar servidor, seleccione el o los servidores que proveerán el rol de

servidor de licencias para Escritorio remoto y, a continuación, haga clic en Siguiente.

En la pantalla Confirmar selecciones, haga clic en el botón Agregar.

Una vez terminada la instalación, en la pantalla Ver progreso haga clic en el botón
Cerrar.

He aquí los comandos equivalentes en PowerShell:

# Instalación del servicio de rol RDS-Licensing

Add-RDServer -Role RDS-Licencing -Server rds1.MiEmpresa.Priv
-ConnectionBroker rds1.MiEmpresa.Priv

Activación del servidor de licencias de Escritorio remoto:

Abra el Administrador del servidor, haga clic en el menú Herramientas - Terminal

Services y Administrador de licencias de Escritorio remoto.
 Haga clic con el botón derecho en el servidor que desea activar y, a continuación,
seleccione la opción Activar servidor en el menú.

Se abre el asistente de Activación del servidor, haga clic en Siguiente.

En la pantalla Método de conexión, los posibles métodos de conexión son:

• Conexión automática: el servidor debe poder establecer una conexión con el

servidor Microsoft mediante el protocolo HTTPS.
• Navegador Web: utiliza otro equipo que accede a Internet para realizar el
procedimiento de activación.
• Por teléfono: intercambiará números de serie con Microsoft por teléfono.

Deje el método de conexión en Conexión automática (recomendado) y haga clic en

Siguiente.
 En la pantalla Información de la empresa, incluya aquella información asociada a su
empresa (todos los campos son obligatorios) y haga clic en Siguiente.

En la segunda pantalla Información de la empresa, escriba la información opcional, y

haga clic en Siguiente.

En la pantalla Finalización del Asistente para activar servidor, desmarque la opción

Iniciar el Asistente para instalar licencias ahora y haga clic en el botón Cerrar.

Esto no supone sino la primera etapa, registrar su servidor con Microsoft. Ahora es posible
agregar licencias TS, seleccionando el programa de licencias. Una vez provistos los
números necesarios, las licencias TS se muestran en el Administrador de licencias. Para
ello, haga clic con el botón derecho en el servidor y seleccione la opción Instalar licencias
en el menú contextual.

Tenga en cuenta que Microsoft no ha modificado el contrato de licencia entre Windows

Server 2012 y Windows Server 2012 R2, en lo relativo a la licencia de acceso cliente a los
servicios de Escritorio remoto (RDS Cal). Esto significa que las licencias RDS Cal de
Windows Server 2012 son compatibles con los servidores RDS Windows Server 2012 R2
y, por tanto, no es necesario volver a comprar RDS Cals.

Observaciones:

• Este servicio de rol consume muy pocos recursos, aunque debe instalarse sobre un
servidor estable. Las licencias no podrán entregarse a otro servidor fácilmente, y la
ausencia de este rol hace que el conjunto de hosts pasen al periodo de prueba de 120
días.
• Un servidor RDS Windows 2012 Server puede, únicamente, comunicarse con un
servidor de licencias Windows 2012 Server.
• Por defecto, se crea una base de datos en el servidor en la siguiente ruta:
%systemroot%\system32\lserver
• Un servidor de licencias Windows Server 2012 R2 puede proveer licencias RDS a
servidores RDS Windows Server 2008/2008 R2, siempre que posea RDS Cal
Windows Server 2008/2008 R2.
• El administrador de licencias permite seguir el consumo de licencias en modo
usuario, y generar informes. Para utilizar esta funcionalidad, el objeto equipo del
servidor debe ser miembro del grupo Active Directory Servidores de licencias de
Terminal Server. Si el servidor es, también, controlador de dominio, entonces la
cuenta Servicio de Red debe formar parte, también, de este grupo.

Para terminar la configuración, debe seleccionar el modo de licenciamiento a aplicar (por

dispositivo o por usuario), que se utilizará en las propiedades de implementación de
Escritorio remoto.
4. RemoteFX

RemoteFX, que se incluye desde Windows Server 2008 R2 Service Pack 1, es una
funcionalidad que permite mejorar de forma significativa la experiencia de usuario y
permite mostrar gráficos en 3D de buena calidad, a través de una conexión de Escritorio
remoto desde un puesto con un cliente RDP 8.1 u 8.0. El cliente RDP 7.1 también está
soportado, aunque con menos funcionalidades. Además, la tecnología incluye el soporte de
Aero, animaciones Flash o Silverlight con un rendimiento muy bueno (siempre que la tasa
de transferencia de la red sea lo suficientemente buena, por supuesto). Con la aparición de
HTML5 y la multiplicación de empresas que utilizan clientes ligeros para conectarse a su
infraestructura, no cabe duda de que a RemoteFX le espera un buen porvenir.

Observe que RemoteFX permite, también, aumentar las posibilidades de redirección de los
dispositivos USB.

Es posible utilizar dos arquitecturas para aprovechar la tecnología RemoteFX: o bien

mediante una infraestructura virtualizada VDI con Hyper-V, o bien a través de una
conexión a un servidor que posea el rol host de sesión disponible desde Windows
Server 2008 R2 SP1.

a. RemoteFX para un host de virtualización de Escritorio remoto

RemoteFX puede utilizarse a través de una infraestructura virtualizada hospedada en

Hyper-V a través del rol de virtualización de Escritorio remoto.

Los equipos cliente que acceden mediante esta infraestructura aprovechan la aceleración
gráfica de la tarjeta física del servidor Hyper-V, permitiendo así aprovechar las ventajas
que ofrece RemoteFX. La tarjeta gráfica está, en efecto, virtualizada y está accesible a
todas las máquinas virtuales hospedadas.

Los requisitos previos que permiten implementar dicha infraestructura son numerosos:

• El procesador debe ser compatible SLAT (Second Level Address Translation). Esta
funcionalidad se denomina EPT (Extended Page Tables) en los procesadores Intel y
NPT (Nested Page Tables) en los procesadores AMD. Los procesadores Intel
Nehalem como los Xeon X5540, Xeon E5530, con núcleo Sandy Bridge e Ivy
Bridge Intel i3, i5 o Intel i7 y los procesadores AMD con núcleo Barcelona,
Shanghaï, Istanbul o Magny-Cours como Opteron 2356 forman parte de los
modelos compatibles.
• Se necesita una tarjeta gráfica (CPU) sobre el servidor que hospeda RemoteFX. El
controlador debe soportar DirectX 11.1 y disponer de, al menos, 1 GB de memoria
dedicada al vídeo.

Observe que el número de máquinas virtuales que permitan aprovechar la funcionalidad

RemoteFX dependerá directamente de la capacidad de memoria de la tarjeta gráfica. Cada
máquina virtual requiere en torno a 200 MB de memoria (dependiendo de la resolución de
pantalla y del número de monitores que se utilicen).

• La tarjeta GPU instalada en el servidor debe poseer un único procesador gráfico. Si

una tarjeta gráfica se instala en el servidor, habrá que deshabilitarla para que la
tarjeta GPU sea la única que se utiliza.
• La funcionalidad Hyper-Threading debe estar habilitada sobre el servidor.
• La máquina virtual a la que se accede debe ejecutar Windows 8/8.1 Professional o
Enterprise, Windows 7 Entreprise o Ultimate con el Service Pack 1 instalado. Si se
trata de una versión x86, la cantidad de memoria alojada debe ser de 1024 MB
como mínimo. Para un sistema operativo de 64 bits, será preciso alojar 2048 MB de
memoria, como mínimo.
• Deben cumplirse los requisitos previos de hardware del rol Hyper-V en el servidor,
tal y compo hemos visto anteriormente.
 • Los roles "Host de virtualización de Escritorio remoto" así como, evidentemente, el
rol "Hyper-V" deben estar instalados en el servidor que hospeda las máquinas
virtuales.
• El cliente RDP utilizado para acceder a la máquina virtual debe tener la versión 7.1
(disponible, de momento, en Windows 7 SP1 y 2008 R2 SP1 únicamente) para
gestionar por aplicación la compresión/descompresión/codificación/decodificación
de los flujos de audio y vídeo a nivel del protocolo RDP 7.1. Estas acciones pueden,
además, realizarse mediante un componente de hardware dedicado (ASIC) que
estará instalado del lado del cliente y del lado servidor. Se recomienda utilizar la
versión 8.0 u 8.1, pues aportan una mejor compresión de los flujos de vídeo en el
protocolo RDP.

Observe que las tarjetas de supervisión remota (tarjeta ILO, iDrac, IMM, KVM sobre IP,
etc.), que sirven habitualmente para tomar el control sobre un servidor y configurar su
BIOS o acceder a la consola, pueden presentar problemas de compatibilidad.

RemoteFX utiliza, en efecto, los controladores WDDM cuando se instala una tarjeta GPU,
mientras que las tarjetas de supervisión utilizan, en su mayoría, el controlador XPDM.
Estos dos controladores no pueden funcionar de manera simultánea, si un controlador
intenta conectarse a través de la tarjeta de supervisión mientras el controlador RemoteFX
está cargado, la consola del servidor no será visible cuando se tome el control remoto de un
sistema operativo con sesión iniciada.

La solución consiste, por tanto, en deshabilitar la tarjeta de supervisión desde la BIOS o en

utilizar el controlador "cap" de RemoteFX. Encontrará más información acerca de la
instalación del controlador "cap" en la siguiente dirección: http://technet.microsoft.com/es-
es/library/gg607270(WS.10).aspx

Las principales etapas para implementar RemoteFX son:

• Instalación de RemoteFX en el servidor Hyper-V (abrir el Administrador del

servidor desde Agregar roles - Servicios de Escritorio remoto - RemoteFX).
• Configuración de la implementación de RemoteFX en la máquina virtual (en la
configuración de la máquina virtual, agregue la tarjeta de vídeo 3D RemoteFX y, a
continuación, reinicie la máquina virtual).
• Uso del cliente RDP 7.1 como mínimo, estando recomendado el cliente 8.0 o
superior. El cliente RDP 7.1 debe estar configurado para utilizar una conexión de
acceso remoto en modo LAN y con 32 bits de colores. Se genera, a continuación, un
evento con ID 2 sobre la máquina virtual, en el registro de Microsoft-Windows-
RemoteDesktopServices-RdpCoreTS/Admin, que confirma que se ha conectado
correctamente sobre la máquina virtual utilizando RemoteFX. De este modo podrá
aprovechar efectos 3D, Aero, etc.
Para disfrutar una mejor experiencia de usuario puede, también, seguir esta etapa opcional
configurando el parámetro Optimizar la experiencia visual al usar RemoteFX con una
tasa de captura de pantalla Máximo (calidad óptima) en la Configuración del equipo -
Plantillas administrativas - Componentes de Windows - Servicios de Escritorio
remoto - Host de sesión de Escritorio remoto - Entorno de sesión remota. Tras reiniciar
el equipo para confirmar los cambios en algún equipo (y siempre que la conexión de red
tenga una buena tasa de transferencia), apreciará todavía un mejor rendimiento de las
animaciones remotas.

Encontrará una guía paso a paso del despliegue de RemoteFX para un host de virtualización
de Escritorio remoto en la siguiente dirección:
http://go.microsoft.com/fwlink/?LinkId=177903

b. RemoteFX para un host de sesión de Escritorio remoto

Los requisitos previos de instalación de RemoteFX sobre un servidor que hospeda el rol de
host de sesión de Escritorio remoto son un poco menos exigentes que en el caso de una
infraestructura VDI.

Tendrá, en efecto, que respetar las condiciones siguientes:

• El procesador debe soportar SSE2 (Streaming SIMD Extensions 2).

• Debe estar instalado el rol "Host de sesión de Escritorio remoto" en un servidor
Windows Server 2012 R2 o Windows Server 2012.
• El cliente RDP que se utiliza para acceder a la máquina virtual debe tener, como
mínimo, la versión 7.1, estando recomendada la versión 8.0 u 8.1, para gestionar por
aplicación la compresión/descompresión/codificación/decodificación de los flujos
de audio y vídeo a nivel del protocolo RDP 7.1. Estas acciones pueden, además,
realizarse mediante un componente de hardware dedicado (ASIC) que estará
instalado del lado del cliente y del lado servidor.

Las principales etapas para implementar RemoteFX son:

• Instalación del rol "Host de sesión de Escritorio remoto" en su servidor Windows

Server 2012 R2 o Windows Server 2012.
• Configuración de la implementación de RemoteFX en el servidor al que accede. Es
preciso, también, limitar el número máximo de colores a 32 bits por píxel, bien a
nivel de las propiedades de conexión RDP, o bien mediante una directiva de grupo
en Configuración del equipo - Plantillas administrativas - Componentes de
Windows - Servicios de Escritorio remoto - Host de sesión de Escritorio remoto
- Entorno de sesión remota. El otro parámetro a habilitar se encuentra en el mismo
lugar y se llama Configurar RemoteFX.
• Uso del cliente RDP 7.1 como mínimo, estando recomendada la versión 8.0 u 8.1.
El cliente RDP 7.1 debe estar configurado para utilizar una conexión de acceso
remoto en modo LAN y con 32 bits de colores. Se genera, a continuación, un evento
con ID 2 sobre la máquina virtual, en el registro de Microsoft-Windows-
 RemoteDesktopServices-RdpCoreTS/Admin, que confirma que se ha conectado
correctamente sobre la máquina virtual utilizando RemoteFX. De este modo podrá
aprovechar efectos 3D, Aero, etc.

Para disfrutar una mejor experiencia de usuario puede, también, seguir esta etapa
opcional configurando el parámetro Optimizar la experiencia visual al usar
RemoteFX con una tasa de captura de pantalla Máximo (calidad óptima) en la
Configuración del equipo - Plantillas administrativas - Componentes de Windows -
Servicios de Escritorio remoto - Host de sesión de Escritorio remoto - Entorno de
sesión remota. Tras reiniciar el equipo para confirmar los cambios en algún equipo (y
siempre que la conexión de red tenga una buena tasa de transferencia), apreciará todavía un
mejor rendimiento de las animaciones remotas.

Encontrará una guía paso a paso del despliegue de RemoteFX para un host de sesión de
Escritorio remoto en la siguiente dirección:
http://go.microsoft.com/fwlink/?LinkId=192436

c. RemoteFX para la redirección de USB

Si lo desea, puede, también, aprovechar la redirección de dispositivos USB para redirigir

cualquier dispositivo USB hacia su escritorio remoto, hospedado sobre una máquina virtual
en Windows 7 SP1 como mínimo. Los dispositivos compatibles son numerosos (escáner,
impresora multifunción, webcam, etc.). Si dispone, físicamente, de una webcam conectada
a su equipo cliente, puede exportar su uso sobre la máquina virtual remota, que se accede
mediante el escritorio remoto.

Observe que la redirección USB no funciona si RemoteFX está hospedado sobre un host de
sesión de Escritorio remoto. La redirección sólo será efectiva si RemoteFX está instalado
sobre un host de virtualización de Escritorio remoto.

Puede utilizar esta funcionalidad en un equipo virtual con Windows 7 SP1, Windows 8 o
Windows 8.1 mediante una conexión de escritorio remoto, mediante un acceso Web RDS, o
incluso mediante una RemoteApp.

Las principales etapas para implementar la redirección de puertos USB son:

• Habilitar la funcionalidad de redirección USB mediante RemoteFX en la sección

Configuración del equipo - Plantillas administrativas - Componentes de
Windows - Servicios de Escritorio remoto - Cliente de conexión de Escritorio
remoto - Redirección de dispositivos USB RemoteFX. El parámetro Permitir la
redirección RDP de otros dispositivos USB RemoteFX compatibles desde este
equipo debe estar Habilitada con los Derechos de acceso a redirección de USB
con RemoteFX definidos para Administradores y usuarios. Reinicie, a
continuación, el puesto en cuestión.
 • Configurar el cliente RDP (7.1 como mínimo) para redirigir el dispositivo deseado.
El dispositivo deberá estar conectado antes de que se inicie la conexión a escritorio
remoto. En la conexión de acceso remoto (mstsc.exe) en las Opciones - Recursos
locales - Otros, marque el dispositivo USB que desea redirigir. Una vez establecida
la conexión mediante escritorio remoto, el dispositivo estará disponible sobre el
equipo remoto.

Encontrará una guía paso a paso para configurar la redirección USB en la siguiente
dirección: http://go.microsoft.com/fwlink/?LinkId=192432

Conclusión
Ahora ya sabe cómo implementar el rol de Escritorio remoto y el conjunto de sus
componentes. Puede implementar distintos métodos de acceso, adaptados a cada contexto
(desde la red local, Internet, hacia un servidor o VDI) sin reducir la seguridad del
sistema de información. Sería una pena privar a los usuarios, y por lo tanto clientes, de una
tecnología así de rápida y eficaz.

Introducción
Este capítulo está dedicado a las distintas formas que existen para acceder a los servicios de
su empresa si se encuentra fuera de ella.

La primera parte aborda los distintos medios que permiten este acceso remoto. A
continuación, se describen los distintos servicios que ofrece Windows Server 2012 para
responder a necesidades de movilidad cada vez más exigentes.

Principios básicos del acceso remoto

A día de hoy, los usuarios itinerantes son cada vez más exigentes y requieren poder acceder
a todos sus datos en cualquier momento (correo electrónico, archivos, etc.) de la misma
forma que si se encontraran en los locales de su empresa. Para poder satisfacer estas
necesidades, tendrá que configurar, seguramente, una solución de acceso remoto.

Este acceso remoto puede realizarse a través de dos tipos de enlace. Bien mediante un
enlace de tipo Conexiones de acceso telefónico (llamadas con frecuencia Dial-up), o viene
estableciendo una red privada virtual (VPN: Virtual Private Network).
1. Acceso telefónico
a. Generalidades sobre las conexiones telefónicas Dial-up

Utilizar una conexión de tipo Dial-up permite acceder a la red de la empresa mediante una
simple línea telefónica, desde cualquier sitio. La contrapartida de esta facilidad de acceso es
que se trata de una tecnología que ya es vieja y que ofrece un rendimiento muy limitado,
con una tasa de transferencia de información muy baja.

En la práctica, es necesario que tanto el cliente como el servidor estén dotados de un

módem. El usuario configura una conexión de acceso telefónico bajo demanda,
especificando un simple número telefónico. Cuando se inicia la conexión, se requiere un
nombre de usuario y una contraseña. El servidor que gestiona el acceso remoto (también
llamado RAS, Remote Access Server) será contactado a través de la línea telefónica, a la
que se encuentra conectado a través del módem.

b. Ventajas e inconvenientes de las conexiones telefónicas Dial-up

Ventajas

• No se necesita una conexión a Internet: basta con una simple línea telefónica
clásica.
• Confidencialidad de los datos: la información no transita a través de Internet, de
modo que los datos no son objetivo de todos los ataques propios de este medio
de comunicación a través de la red mundial. La seguridad es, por lo tanto máxima,
puesto que la red local no tiene por qué estar abierta al mundo exterior.

Inconvenientes
 • Muy poco ancho de banda. Basada en la tecnología telefónica, las tasas de
transferencia de este tipo de conexión es bastante limitada. En efecto, la red
telefónica se ha diseñado para poder reproducir la voz humana, y nada más. Las
frecuencias que pueden transitar por este medio de transmisión son, de hecho, muy
limitadas.
• Para aumentar la tasa de transferencia que encontramos (56K), existen líneas de
transmisión digitales (128K). No obstante, siguen representando una inversión
importante.
• Coste elevado. Las comunicaciones telefónicas tienen un coste que no es
despreciable, recuperar un simple archivo de 10 MB supondrá una inversión
considerable de tiempo necesario para descargarlo (cerca de cuarenta minutos si la
tasa de transferencia media es de 4 kB/s).
• Además, para poder proveer conexiones remotas múltiples se requieren tantas líneas
telefónicas como usuarios nómadas puedan conectarse simultáneamente.

Si bien el coste es bastante elevado de esta tecnología hace que su uso no parezca muy
atractivo, puede resultar muy útil en ciertos casos concretos. Si no es, en efecto, extraño
tener problemas de conexión a Internet, es mucho menos habitual tener cortes de la línea
telefónica. Puede resultar, de este modo, bastante interesante aprovechar este tipo de acceso
en ciertas empresas de administración de servidores. En efecto, un administrador podrá
seguir gestionando, de manera remota, sus servidores a través de la línea telefónica, aunque
no estén disponibles a través de Internet.

2. Acceso mediante Internet

a. Generalidades sobre las VPN

La segunda tecnología que permite realizar un acceso remoto utiliza la red Internet y no la
red telefónica. A diferencia de las conexiones bajo demanda que le permiten conectar
directamente con la red de la empresa, en este caso es necesario pasar "a través" de Internet.
La tecnología que se utiliza se denomina VPN (Virtual Private Network o Red Privada
Virtual, en castellano). Aquí, la comunicación se establece directamente a nivel IP.
A continuación se dan algunas explicaciones relacionadas con la terminología Red Privada
Virtual:

La conexión es virtual en cuanto a que el equipo que establece una conexión VPN a través
de Internet se va a comportar como si estuviera directamente conectado a la red de área
local, como si se tratase de un cable de red directamente conectado a ella. El usuario va a
poder, de este modo, acceder a los mismos recursos que si estuviera físicamente conectado
a la red. Esta conexión se considera, no obstante, virtual, precisamente porque no existe tal
enlace físico Ethernet con la red de destino. Es privada en cuanto a que se trata de una
conexión punto a punto entre el origen y el destino. Los datos que se intercambian están
cifrados. De este modo, si alguien interceptara los datos, no se podrían descifrar sin conocer
la clave privada de la transacción.

Las VPN se utilizan, a menudo, para conectar sitios remotos completos. Hablamos,
entonces, de VPN sitio a sitio. El objetivo de este tipo de conexiones es poder vincular
lógicamente redes remotas sin tener que realizar un enlace de red directo (Ethernet, Wi-Fi,
etc.).
b. Los distintos tipos de VPN que ofrece Windows Server 2012 R2

Windows Server 2012, como sus predecesores, soporta los siguientes tipos de VPN:

• PPTP (Point to Point Tunneling Protocol):

PPTP es el método más sencillo para implementar y utilizar una VPN. El cifrado de
los datos interviene después del proceso de autentificación mediante el protocolo
PPP. Utilice, preferentemente, una autentificación MS-CHAPv2 con una
autenticación basada en PAP (Password Authentication Protocol) o CHAP
(Challenge Handshake Authentication Protocol) para no dejar que la contraseña
transite sin cifrar por la red.

• L2TP/IPsec (Layer 2 Tunneling Protocol):

Más seguro que PPTP, L2TP/IPsec es el resultado de un desarrollo conjunto entre

Microsoft y Cisco.

A diferencia de PPTP, el cifrado incluye la fase de identificación puesto que la

sesión IPsec se establece justo antes.

Además, la autenticación mutua de las máquinas (también llamada handshake)

impide a cualquier máquina desconocida conectarse. Esto evita, en particular,
ataques del tipo Man-in-the-Middle, que sufren las VPN basadas en PPTP.

Preste atención, no obstante, puesto que es necesario evitar, teóricamente el NAT

antes de IPsec puesto que modifica el contenido de los paquetes. Esta modificación
es incompatible con los mecanismos de protección integrados de los datos IPsec. Si
se ve obligado a utilizar L2TP sobre una red "nateada", utilice la variante NAT-T
(NAT Traversal).

Desde Windows Server 2008, el sistema también ofrece:

• SSTP (Secure Socket Tunneling Protocol):

 SSTP es una nueva forma de túnel VPN que facilita el establecimiento de una
conexión VPN mediante un firewall o un dispositivo que realiza la traducción de las
direcciones de red (NAT).

Esto es posible gracias a la encapsulación de paquetes PPP (Point to Point Protocol)

en HTTPS. SSTP utiliza conexiones HTTP encriptadas con SSL para establecer
conexiones con las pasarelas VPN. De este modo, es posible establecer conexiones
VPN a través de un proxy HTTP.

Del mismo modo que con L2TP/IPsec, sólo se transmite la información de

identificación una vez establecida la sesión SSL con la pasarela VPN.

También llamado PPP/SSL, este protocolo permite utilizar PPP y EAP para realizar
la autenticación y hacer que la conexión sea todavía más segura.

Sólo disponible con la combinación de versiones Windows Server 2008 R2/Windows 7 o

versiones superiores, la tecnología VPN Reconnect permite hacer una reconexión
transparente mediante un enlace VPN. En caso de que se interrumpa la conexión a Internet,
por ejemplo, el sistema se encarga de recuperar la conexión VPN sin ninguna intervención
por parte del usuario, y en unos pocos segundos.

c. Ventajas e inconvenientes de VPN

Ventajas

• Coste reducido: todas las empresas y todos los usuarios ya están equipados, por lo
general, con una conexión a Internet. El coste de la implementación es por lo tanto
mínimo, pues basta con aprovisionar un servidor que haga las veces de servidor
VPN. Además, con una única conexión a Internet es posible dar servicio a varias
conexiones remotas simultáneas sin tener que adquirir una línea suplementaria.
• Ancho de banda elevado: la tecnología VPN se apoya directamente en IP y, por
tanto, sobre una infraestructura Internet. Con la extensión de ADSL y la explosión
del ancho de banda asociado, esta tecnología es mucho más rápida que las
conexiones de tipo Dial-Up.
• VPN Anywhere: supone una pequeña analogía con la tecnología empleada en
Exchange (RPC over HTTPS) donde se encapsula el tráfico de Outlook a través de
tráfico Web seguro (HTTPS). Como se ha explicado antes, aquí es el tráfico VPN el
que está encapsulado en HTTPS. La seguridad de las redes es por lo general una
prioridad, y es corriente bloquear el tráfico de salida que no se corresponda con las
necesidades de la empresa. Por el contrario es raro ver el tráfico HTTPS saliente
bloqueado. De este modo, gracias a SSTP, el usuario debe poder conectarse desde
cualquier red de empresa o punto de acceso a Internet.

Inconvenientes
 • Dependiente de la red: a diferencia de las conexiones bajo demanda, el
rendimiento de una conexión a Internet desde una de las dos partes (empresa o
usuario nómada) tienen un impacto nada despreciable en la calidad de la
transmisión. Cualquier problema en el proveedor de acceso de una u otra parte
puede provocar una incapacidad total para comunicarse.
• Confidencialidad de los datos: aunque se utilizan sistemas de cifrado no queda
más remedio que los datos transiten a través de Internet. Esto los vuelve
potencialmente visibles para todo el mundo aunque estén cifrados.

d. DirectAccess, el "VPN-Killer"

La tecnología DirectAccess se denomina, a menudo, "VPN-Killer" por parte de muchos

profesionales de la informática. Este sobrenombre proviene del hecho de que a diferencia
de las VPN habituales (PPTP, L2TP, etc.), Direct Access permite establecer una conexión a
la red de la empresa antes incluso de abrir una sesión sobre la máquina cliente.

El objetivo del lado del cliente consiste en mejorar su experiencia como usuario nómada
proporcionándole condiciones de trabajo totalmente idénticas a las que disfruta en los
edificios de su empresa

Los administradores de sistemas sacarán buen partido a esta tecnología. En adelante serán
capaces de administrar íntegramente los equipos situados fuera de la empresa: despliegue
de actualizaciones de software, actualización del antivirus, aplicación de las directivas de
grupo, etc.

Por defecto, y a diferencia de las tecnologías VPN habituales, sólo el tráfico de destino de
la empresa pasará a través de Direct Access, de forma que no ralentice el tráfico de Internet.
Siempre es posible hacer transitar la totalidad del tráfico por Direct Access, con el objetivo
de controlar de principio a fin la seguridad del acceso.

Su capacidad para gestionar la alta disponibilidad se ha visto mejorada con la llegada del
Service Pack 1 de Windows Server 2008 R2 pues incluye el soporte del direccionamiento
6to4 e ISATAP cuando se utiliza DirectAccess mediante un clúster NLB (Network Load
Balancing). Si desea más información acerca del clúster NLB, consulte el capítulo Alta
disponibilidad.

He aquí las etapas del proceso de conexión a la red gracias a DirectAccess con Windows
Server 2008/2008 R2/2012/2012 R2:

• El cliente detecta si tiene conexión de red.

• Intenta establecer una sesión sobre un sitio Intranet SSL para determinar si se
encuentra en el seno de la red de la empresa o en el exterior.
• El cliente se conecta al servidor Direct Access mediante IPSec e IPv6. Si no hay
disponible una conexión IPv6 nativa (éste es generalmente el caso si el equipo
cliente está conectado a Internet), el cliente establece un túnel IPv6 sobre IPv4
 mediante 6To4 o Teredo (para más información acerca de Teredo diríjase a la
página: http://technet.microsoft.com/en-us/network/cc917486.aspx).
• Si el cliente no llega a establecer la conexión a causa de un cortafuegos o de un
proxy, intentará conectarse automáticamente mediante el protocolo HTTPS.
• El equipo cliente y el servidor Direct Access van a autenticarse mutuamente gracias
a los certificados de equipo. Este proceso forma parte de los mecanismos IPSec.
• El servidor Direct Access va a verificar en sus reglas si el equipo está autorizado (o
forma parte de un grupo autorizado) para establecer una conexión Direct Access.
• El servidor Direct Access va a redirigir el tráfico del equipo cliente hacia los
servidores de la Intranet sobre los que esté autorizado el acceso del usuario.

Este proceso es ligeramente diferente con Windows Server 2012 puesto que ya no se utiliza
IPsec y, en lo sucesivo, la conexión externa se establece directamente mediante HTTPS. La
etapa 3 de intento de conexión IPsec e IPv6 ha desaparecido, pasando directamente de la
etapa 2 a la etapa 4.

e. Rol Web Application Proxy

Web Application Proxy (o WAP) es un nuevo servicio de rol de Acceso remoto en

Windows Server 2012 R2. El proxy de aplicación web provee una funcionalidad de proxy
inverso para las aplicaciones web presentes en su red de empresa permitiendo, así, a los
usuarios acceder desde el exterior de la empresa y desde cualquier dispositivo móvil (de
momento se soporta IOS y Android debería llegar próximamente).

WAP requiere poseer una granja de AD FS para poder funcionar. Sin AD FS, el asistente
no puede completar las etapas de configuración.

Es posible proveer funcionalidades simples de proxy inverso utilizando una autenticación

de tipo Pass-Through, que tiene, también, la capacidad de pasar información de
autenticación del cliente hacia el servidor de destino sin pre-autenticación. Puede, también,
proveer una autenticación a AD FS (Active Directory Federation Service) agregando el rol
de proxy AD FS. Observe que, incluso para el Pass-Through, el asistente exige una granja
AD FS configurada.

El objetivo de WAP es publicar aplicaciones web internas en la red de la empresa para

hacer que estén disponibles desde el exterior, poco importa el cliente utilizado (equipo
portátil, Smartphone, etc.), proveyendo una autenticación única (SSO) que juega, así, el rol
de portal SSL.

Se recomienda desplegar este rol en una red perimétrica (entre el firewall conectado a
Internet y el conectado a la red de la empresa). A diferencia de una publicación web
"clásica", WAP corta el tráfico entrante del cliente para iniciar una nueva sesión con la
aplicación final. De este modo, el usuario no se comunicará, jamás, directamente con la
aplicación, sino que accederá a través del componente WAP.
En resumen, WAP provee funcionalidades de publicación de aplicaciones similares a
Microsoft Forefront Unified Access Gateway (UAG). No obstante, WAP interactúa con
otros servidores y servicios (AD FS) para proveer un despliegue simplificado. No
reemplaza totalmente a UAG, pues sólo las aplicaciones web con autenticación Kerberos o
por notificación pueden aprovechar una publicación mediante WAP.

WAP puede, por ejemplo, resultar útil para publicar el acceso remoto web de un servidor
Exchange (OWA) o un servidor Lync (Lync Web app). Al gestionarse la autenticación en
AD FS, el usuario recibirá un token único y podrá aprovechar el SSO (Single Sign On) para
acceder a las dos aplicaciones gracias a una única autenticación.

Encontrará, en el siguiente enlace, las etapas que permiten implementar una publicación
mediante el componente WAP: http://technet.microsoft.com/en-us/library/dn383650.aspx

f. ¿Cuáles son las novedades de Windows Server 2012 y Windows Server 2012 R2?

Windows Server 2012 combina la funcionalidad de Direct Access con el rol RRAS
(Remote and Routing Access Service) en un nuevo rol que permite administrar de manera
centralizada, configurar y supervisar a la vez Direct Access y los servicios de VPN. La
mayor mejora reside en las numerosas actualizaciones y mejoras de Direct Access para
prevenir bloqueos ligados al despliegue, y simplificar su gestión.

Se han aportado las siguientes mejoras con Windows Server 2012:

• Coexistencia de Direct Access y RRAS: ambas herramientas pueden, en lo

sucesivo, administrarse desde la misma interfaz, a saber: la consola de
Administración de acceso remoto.
• Simplificación del despliegue de Direct Access para estructuras de tamaño
pequeño o mediano: ya no es obligatorio disponer de dos direcciones IPv6
consecutivas. Basta con tener acceso al puerto TCP 443 desde el exterior, ya no es
preciso utilizar reglas IPsec complicadas.
• Desaparecen los requisitos previos de clave pública (PKI): gracias a la
delegación Kerberos.
• Integración nativa del soporte NAT64 y DNS64 para acceder a recursos mediante
IPV4: antes, era preciso tener una intranet compatible con IPv6; en lo sucesivo basta
con IPv4.
• Soporte de DirectAccess sobre un servidor a través de NAT.
• Simplificación de la administración de las directivas de seguridad.
• Soporte de Load Balancing: ya no es necesario un servidor UAG (Unified Access
Gateway) como era el caso con la funcionalidad Direct Access en Windows 2008
R2.
• Integración de NAP (Network Access Protection): para asegurar la seguridad
verificando el estado de la seguridad en los puestos.
• Soporte multidominio.
• Soporte de Windows Server en modo Core.
• Soporte OTP (One-Time Password).
 • Supervisión de los usuarios.
• Herramientas de diagnóstico.
• Registro de eventos e Informes.
• VPN sitio a sitio en modo IKEv2 IPsec: Windows Server 2008 R2 incluye el
soporte IKEv2 en las conexiones VPN cliente. El uso de IKEv2 y de IPsec ofrece
una autenticación y métodos de cifrado robustos. Windows Server 2012 incluye esta
funcionalidad reforzada para conexiones VPN de tipo sitio a sitio.
• En lo sucesivo, es posible virtualizar el servidor que hospeda el rol de Acceso
remoto.

Windows Server 2012 R2 aporta, por su parte las siguientes mejoras:

• Pasarela VPN sitio a sitio multiteniente (Multi-Tenant Site-to-Site VPN

Gateway): con Windows Server 2012 R2, es posible desplegar pasarelas sitio a sitio
multilocalidad (multicliente) para proveer una conectividad a los sitios locales hacia
las redes virtuales dedicadas en la red principal. Una pasarela (o Gateway: GW) es
capaz de dar servicio a varios clientes que posean direcciones IP que se solapen
(overlap). Para aclarar este punto, se muestra a continuación un esquema que
muestra el caso de un anfitrión que aloja máquinas virtuales para clientes que
utilizan la virtualización de redes Hyper-V. Vemos cómo una única pasarela S2S
GW (Site To Site Gateway) es capaz de dar servicio a dos clientes distintos que
posean la misma dirección IP (en este caso 10.10.10.0/24).
• El servicio Enrutamiento y acceso remoto (RRAS) GW es una única solución
software que puede desplegarse en la mayoría de instancias de servidores RRAS
multicliente para equilibrar la carga. El siguiente enlace le indicará las etapas de la
configuración necesaria para su implementación:
http://blogs.technet.com/b/networking/archive/2013/10/15/multi-tenant-vpn-with-
windows-server-2012-r2.aspx
• Pasarela del acceso remoto VPN multicliente: para las pequeñas y medianas
estructuras, no existe la obligación de poseer dos direcciones IPv6 públicas
consecutivas. El acceso al puerto TCP 443 desde el exterior es suficiente. El uso de
reglas IPsec complicadas ya no es necesario.
• Border Gateway Protocol (BGP): Windows Server 2012 Border Gateway
Protocol (BGP) permite un reparto dinámico y el aprendizaje de las rutas mediante
interfaces de enrutamiento sitio-a-sitio (S2S) de RRAS. Esta funcionalidad permite,
a los anfitriones (principalmente proveedores de servicios (IaaS)) desplegar BGP en
las pasarelas S2S multi-cliente. De este modo, la pasarela puede saber qué paquetes
están dirigidos a Internet, hacia las redes locales (clientes), hacia la red virtual del
cliente en el anfitrión y, de este modo, determinar los itinerarios de manera
consecuente. Las pasarelas RRAS con BGP habilitado puede, a su vez, desplegarse
 en las empresas para distribuir rutas internas a otras pasarelas de la red de la
empresa sobre túneles seguros.

Implementar un acceso seguro a través de

Internet
En esta sección veremos cómo configurar un servidor como servidor de acceso remoto. En
primer lugar se describen los métodos para configurar los distintos tipos de VPN ofrecidos
por Windows Server 2012 (PPTP, L2TP, SSTP). A continuación se abordan los aspectos
relativos a la securización. No se mencionará la configuración de un servidor RAS
mediante módem, pues se trata de una tecnología que apenas se utiliza.

1. Implementar un enlace VPN

Requisitos previos de hardware: el servidor debe estar integrado en el dominio

MiEmpresa.Priv y provisto de dos tarjetas de red. Una conectada a Internet y otra conectada
a una red local (LAN). La primera se encarga de aceptar las conexiones VPN entrantes y
necesita una IP fija (en nuestro caso configurada con la dirección IP 211.111.111.111/25,
preste atención puesto que esta IP se utiliza como ejemplo, debería utilizar una IP pública
en producción). La segunda interfaz de red transfiere el tráfico entre las conexiones VPN y
los recursos de red de la LAN.

En el caso de una VPN PPTP o L2TP es técnicamente posible tener una única tarjeta de
red. Esto se sale, no obstante, del marco de buenas prácticas recomendadas por Microsoft y
el rendimiento puede verse afectado.

a. Instalación del rol Acceso remoto

La instalación del rol se realiza desde la consola Administrador del servidor, en la

subcarpeta Roles, haciendo clic en Agregar roles.

He aquí las distintas etapas:

Abra la consola Administrador del servidor.

Haga clic en Administrar y, a continuación, en Agregar roles y características.

Haga clic en Siguiente.

En Tipo de instalación, seleccione Instalación basada en roles o caracte-rísticas.

Haga clic en Siguiente.

 En la pantalla Seleccionar servidor, haga clic en DC2012 en la lista y, a continuación,
haga clic en Siguiente.

En la sección Roles del servidor, marque la opción Acceso remoto tal y como indica la
siguiente captura de pantalla:

Haga clic en Siguiente.

Lea la descripción del rol y, a continuación, haga clic en Siguiente.

Marque la opción DirectAccess y VPN (acceso remoto).

En el cuadro de diálogo Asistente para agregar roles y características, haga clic en
Agregar características y, a continuación, haga clic en Siguiente.
En la pantalla Rol de servidor web (IIS), haga clic en Siguiente.

Deje las opciones por defecto de los servicios de rol marcadas y, a continuación, haga clic
en Siguiente.

En la pantalla de confirmación, haga clic en Instalar.

 En la pantalla de Resultados, verifique que la instalación se desarrolla correctamente y
haga clic en Cerrar.

Si bien ya no resulta útil con Windows Server 2012, si lo desea puede crear un certificado
autofirmado para L2TP/IPsec o SSTP con Windows Server 2008/2008 R2: abra la consola
Administrador de Internet (IIS) y, en la parte central, haga doble clic en Certificados de
Servidor. En la sección Acciones, haga clic en Crear un certificado autofirmado... y, a
continuación, asígnele un nombre descriptivo.

b. Configuración de las funcionalidades VPN

Ahora que ha instalado el rol de servidor de acceso remoto, puede configurar sus
parámetros asociados.

El procedimiento de configuración para las tres tecnologías VPN es idéntico.

En la consola Administrador del servidor, haga clic en Herramientas y, a continuación,

seleccione Administración de acceso remoto.
En el panel de navegación, dentro de Configuración, haga clic en DirectAccess y VPN.

En la sección central, haga clic en Ejecutar el Asistente para introducción.

Se abre el asistente de instalación, haga clic en Implementar solo VPN.

 En la parte izquierda, haga clic con el botón derecho sobre su servidor y, a continuación,
seleccione Configurar y habilitar Enrutamiento y acceso remoto como se indica a
continuación:

Haga clic en Siguiente.

Seleccione Acceso remoto (acceso telefónico o red privada virtual) y haga clic en
Siguiente.
Marque la opción VPN y haga clic en Siguiente.

Seleccione su interfaz pública (aquí, de cara a simplificar, se han renombrado las

conexiones en función de su uso: se trata, por tanto, de la tarjeta WAN).
Haga clic en Siguiente.

En la pantalla Asignación de direcciones IP, seleccione Automáticamente si dispone de

un servidor DHCP. En caso contrario, seleccione De un intervalo de direcciones
especificado.

Haga clic en Siguiente.

Si desea que el servidor VPN asigne las direcciones, le aparece la siguiente pantalla:
 Haga clic en Nuevo y, a continuación, defina un rango que contenga suficientes
direcciones de red. Valide haciendo clic en Siguiente.

Preste atención y especifique un rango que se corresponda con su red local. Sin ello, la
comunicación no funcionará.
 En la pantalla Administrar servidores de acceso remoto múltiples, si dispone de un
servidor RADIUS marque Sí, en caso contrario marque No.

Aquí, marcaremos No puesto que la seguridad con RADIUS se aborda más adelante en este
capítulo.

Haga clic en Siguiente.

Aparece el siguiente cuadro de diálogo que le informa del uso de un agente de

retransmisión DHCP.

El componente Agente de retransmisión DHCP es un agente que transfiere los mensajes

DHCP (Dynamic Host Configuration Protocol) entre los clientes y los servidores DHCP
sobre distintas redes IP. Resulta, por lo tanto, útil cuando no existe ningún servidor DHCP
en el segmento físico de una máquina.
Haga clic en Aceptar.

En la pantalla Resumen, verifique que la información de la configuración es la deseada y,

a continuación, haga clic en Finalizar. A continuación, haga clic en Aceptar.

Una vez terminado este asistente, Windows Server 2012 crea automáticamente 128 puertos
para cada una de las tres tecnologías de VPN que conoce .Cada conexión requiere un puerto
único. Para obtener una mayor seguridad, conviene deshabilitar los puertos inútiles.

Una vez configurado para aceptar conexiones VPN entrantes, Windows Server 2012
bloquea automáticamente todo el tráfico entrante sobre la interfaz pública que no se
corresponde con el tráfico VPN.

Para modificar los paquetes autorizados (por ejemplo: para poder tomar el control sobre el
servidor por escritorio remoto):

Desde la consola Administrador del servidor, haga clic en Herramientas y, a

continuación, en Enrutamiento y acceso remoto.

Despliegue la arborescencia Nombre de su servidor - IPv4 (o IPv6 según su

configuración) - General.

Haga clic con el botón derecho sobre su interfaz pública y, a continuación, seleccione
Propiedades.
Haga clic en Filtros entrantes....
 Sólo falta autorizar el tráfico deseado (puerto 3389 TCP por ejemplo para el escritorio
remoto).

2. Administración de la seguridad de los accesos

Ahora que sabe cómo configurar Windows Server 2012 R2 como servidor de acceso
remoto, sin duda querrá controlar la forma en la que se conectan los usuarios. Cuentas de
usuario, franjas horarias, grupos y muchos otros parámetros son configurables.

En las versiones anteriores a Windows Server 2008, estos parámetros se administraban a

través de la consola Directivas del acceso remoto. Desde Windows Server 2008, debe
utilizar la consola Servidor de directivas de redes (Network Policy Server). Esta consola
le permite administrar la seguridad de los accesos a su red de forma centralizada.

Con Windows Server 2012 y Windows Server 2012 R2, el rol de servidor NPS (Network
Policy Server) se instala automáticamente cuando se agrega el rol de acceso remoto, a
diferencia de lo que ocurría en las versiones anteriores de Windows Server.

Para modificar una directiva existente:

En la consola Administrador del servidor, haga clic en Herramientas y, a continuación,

en Servidor de directivas de redes (Network Policy Server).

Despliegue el nodo Directivas - Directivas de red.

Encontrará dos directivas por defecto con valores máximos para la columna Orden de
procesamiento. Debe prestar atención a este orden. En efecto, las directivas de red se
procesan en orden creciente. El servidor va a recorrer las directivas partiendo del menor
valor de prioridad. Si encuentra una que corresponde con criterios de petición de conexión,
autoriza o no el tráfico. De este modo, si una directiva está configurada para rechazar el
acceso, tras la verificación de las directivas el acceso estará automáticamente bloqueado
incluso si hay otra directiva más tarde que lo autoriza.

Lo más práctico es que cree sus propias directivas de acceso a la red para controlar bien su
contenido. He aquí el procedimiento a seguir para crear una directiva que autoriza al grupo
Comerciales a conectarse a la red entre semana de 9h a 18h:

En la consola Servidor de directivas de redes (Network Policy Server), vaya a

Directivas de red.

Haga clic con el botón derecho en la carpeta Directivas de red y, a continuación, haga clic
en Nuevo. Especifique un nombre para su directiva. Preste atención a elegir nombres
explícitos, de este modo si sus directivas se multiplican ganará en claridad.
 La lista desplegable Tipo de servidor de acceso a la red se refiere a la tecnología NAP
(Network Access Protection) que se ha abordado en el capítulo Implementar los servicios
de red de la empresa. Aquí, sólo se administra la seguridad de acceso al servidor VPN, y
dejaremos la opción como No especificado.

Haga clic en Siguiente.

Aparece, a continuación, una página que le permite definir las condiciones. Haga clic en
Agregar.
A continuación tiene la posibilidad de elegir entre una gran variedad de criterios agrupados
en siete categorías diferentes:

• Grupo (grupo de equipos, de usuarios, etc.).

• HCAP (grupos que se corresponden con servidores de acceso a la red de terceros).
• Restricciones horarias (días de la semana, intervalos horarios, etc.).
• Protección de acceso (sistema operativo, compatibilidad NAP, etc.).
• Propiedades de la conexión (dirección IP del cliente, tipo de autenticación, etc.).
• Propiedades del cliente (nombre del cliente RADIUS, IP del cliente RADIUS, etc.).
• Puerta de enlace (número de teléfono del servidor Dial-Up, nombre del dispositivo
de red que transmite la solicitud).

En este libro no se abordan con detalle todas estas condiciones, teniendo en cuenta su
elevado número. Podrá no obstante encontrar más detalle en la TechNet de Microsoft en la
siguiente dirección: http://technet.microsoft.com/en-us/library/cc731220.aspx

Las condiciones son acumulables, puede por ejemplo autorizar a un único grupo de
usuarios y sobre una franja horaria muy precisa.

Seleccione Grupos de usuarios y, a continuación, haga clic en Agregar.

En el cuadro de diálogo que se abre, haga clic en Agregar grupos y, a continuación,

escriba el nombre del grupo (Comerciales, en nuestro ejemplo) y valide haciendo clic en
Aceptar.
Valide haciendo clic en Aceptar y, a continuación, haga clic en Siguiente.

Una vez haya agregado las condiciones, tiene la posibilidad de Conceder acceso, de
Denegar acceso o incluso hacer que sean las propiedades de marcado del usuario las
que determinen el acceso (en este caso, son las propiedades definidas en la cuenta del
usuario las que se tienen en cuenta). En este ejemplo, seleccione Acceso concedido y, a
continuación, haga clic en Siguiente.

A continuación puede elegir entre los distintos Métodos de autenticación.

Debe seleccionar al menos uno. Preste atención, las opciones sin marcar en la siguiente
imagen representan autenticaciones poco seguras y no deberían estar marcadas en la
medida de lo posible.
Aquí, deje las opciones marcadas por defecto.

Haga clic en Siguiente.

La página de restricciones permite aplicar restricciones suplementarias como la franja

horaria autorizada (en nuestro ejemplo).

Haga clic en Restricciones de día y hora y, a continuación, marque la opción Permitir

acceso solo en estos días y horas.
 Haga clic en Editar y, a continuación, rellene la información tal y como se muestra a
continuación para autorizar los días entre semana de 9h a 18h.
Valide haciendo clic en Aceptar y, a continuación, haga clic en Siguiente.

En esta ventana puede configurar los parámetros suplementarios para securizar la

conexión. En efecto, si la conexión responde a los criterios anteriores, a saber condiciones y
restricciones, es preciso aplicar parámetros suplementarios, que van desde la Protección de
acceso a redes (NAP), hasta el cifrado de la conexión, o incluso una restricción sobre los
protocolos utilizados durante la conexión. En nuestro ejemplo, no especifique ningún
parámetro y haga clic en Siguiente.

En la última página del asistente, verifique bien la información y haga clic en Finalizar.

Su nueva directiva aparece con una cifra asignada automáticamente para el orden de
procesamiento. A continuación puede modificar este orden haciendo clic con el botón
derecho del ratón sobre la directiva y seleccionando una de las opciones, Aumentar o
Disminuir. Esto le permite definir su prioridad y, por consiguiente, el orden en el que se va
a verificar durante la petición de conexión.
3. Administración de la autenticación RADIUS

En la sección anterior hemos visto cómo configurar una directiva de conexión para el
acceso mediante VPN gracias a la consola NPS. Si bien es posible técnicamente, se vuelve
rápidamente difícil de gestionar cuando tiene varios servidores de acceso a la red
(servidores VPN, accesos Wi-Fi, etc.).

Para centralizar la administración de las reglas de acceso de la autenticación necesita el

componente de servicio NPS (Network Policy Server). Este rol se conocía en las versiones
anteriores a Windows Server 2008 con el nombre de IAS (Internet Authentication Service).

Para centralizar la autenticación, utilice la función RADIUS (Remote Authentication Dial-

In User Service) de su servidor NPS. El interés de la tecnología RADIUS consiste en
centralizar la administración de la seguridad de los equipos informáticos que no son
Microsoft. En efecto, puede por ejemplo configurar un punto de acceso Wi-Fi para utilizar
el servidor NPS Windows Server 2012 para administrar la autenticación.

He aquí las funciones que le ofrece el Servidor NPS en materia de seguridad:

• Network Policy Server (NPS): autenticación, autorización, servicios de acceso

remoto, VPN, punto de acceso Wi-Fi, puerta de enlace TS.
• NPS Accounting (o registro): auditoría y registro de las autenticaciones y las
peticiones de cuenta en una base de datos SQL o en un archivo local. Windows
Server 2008 R2 integra un nuevo asistente que le permite configurar fácilmente este
registro creando automáticamente las bases de datos asociadas.
• NPS RADIUS Proxy: permite encadenar mensajes entre los clientes RADIUS (los
servidores de acceso y los servidores RADIUS que se ocupan de la autenticación).
• NPS NAP: diríjase al capítulo Implementar los servicios de red de la empresa -
Implementar la cuarentena de red.
• NPS RADIUS server: gestiona la autenticación, la autorización y el registro de las
peticiones de los clientes RADIUS.
• NPS RADIUS client: servidor de acceso remoto que utiliza un servidor RADIUS
para realizar la autenticación.

Los equipos cliente no son clientes RADIUS. Son los equipos a los que se conectan
(servidor VPN, punto de acceso Wi-Fi) los que lo son.

La configuración de las directivas de acceso (horarios, usuarios, etc.) se realiza del mismo
modo que para un servidor VPN (visto anteriormente en este mismo capítulo). En lo
sucesivo puede configurar su servidor NPS para que se comporte como un servidor
RADIUS o incluso como Proxy RADIUS.
Un servidor RADIUS permite realizar la autentificación, la autenticación y la gestión de los
clientes RADIUS. Un cliente RADIUS puede ser un servidor de acceso, tal como un
servidor de acceso remoto o un punto de acceso inalámbrico, o un proxy RADIUS.

Un proxy RADIUS asegura la distribución de los mensajes RADIUS entre los clientes
RADIUS (servidores de acceso) y los servidores RADIUS que realizan la autenticación de
los usuarios, su autorización y la gestión de cuentas durante los intentos de conexión.

Puede ser interesante utilizar un servidor proxy RADIUS en los siguientes casos:

• Si quiere ofrecer una autenticación para las cuentas que no sean miembro del
dominio del que forma parte el servidor NPS.
• Si quiere ofrecer una autenticación basada en una base de datos diferente a la de
Windows.
• Si desea poder gestionar una gran cantidad de consultas de conexión. El proxy
RADIUS se comportará como un distribuidor de carga.
• Si desea dotar de seguridad al acceso a su base de datos de usuarios situando un
proxy RADIUS en una DMZ.

Para que un dispositivo pueda acceder y utilizar su servidor como servidor RADIUS tendrá
que haberlo autorizado previamente. Para ello, siga los siguientes pasos:

En la consola NPS, vaya a Clientes y servidores RADIUS.

Haga clic con el botón derecho del ratón en Clientes RADIUS y seleccione Nuevo.
Basta con declarar el dispositivo dándole un Nombre descriptivo y su Dirección IP.

Si fuera necesario, haga clic en la pestaña Opciones avanzadas y especifique:

• El Nombre del proveedor (la lista desplegable ofrece muchos actores importantes
en el mundo informático tales como Cisco, etc.).
• Un secreto compartido que configurará también en el dispositivo de acceso.

También puede elegir los protocolos de autenticación y especificar si el cliente RADIUS es

compatible NAP o no.
Una vez declarado el dispositivo, puede habilitarlo o deshabilitarlo haciendo clic con el
botón derecho y marcando una opción. Para ello, basta, en la sección Clientes RADIUS, ir
a las propiedades del dispositivo que acaba de crear. Sólo falta seleccionar entre Activado
o Desactivado.

A continuación se muestra un ejemplo de uso de un servidor RADIUS.

Declarar su servidor como Servidor proxy RADIUS es, también, muy sencillo. En su
consola NPS basta con:

• Navegar a Clientes y servidores RADIUS.

• Hacer clic con el botón derecho en Grupos de servidores remotos RADIUS y, a
continuación, Nuevo.
• Indicar un nombre de grupo y, a continuación, hacer clic en Agregar.
• Informar el nombre o la dirección IP de un servidor RADIUS.
• Especificar si el proxy RADIUS debe autenticarse mediante un secreto compartido
desde el servidor RADIUS, o incluso configurar el reparto de carga.
• Agregar varios servidores RADIUS en un mismo grupo para asegurar su tolerancia
a fallos.
4. Implementación de DirectAccess tras un Firewall

Con DirectAccess para Windows Server 2008 R2, era obligatorio poseer una dirección IP
pública (y, por lo tanto, dos tarjetas de red: una pública y una privada) sobre el servidor de
acceso remoto y DirectAccess no soportaba NAT. En lo sucesivo, es posible publicar un
servidor de acceso DirectAccess que posea una única tarjeta de red y que se encuentre
detrás de un firewall.

• Requisitos previos: ya ha instalado el rol Acceso remoto siguiendo el método

descrito anteriormente en este capítulo (VPN no se ha configurado mediante el
asistente para Administrar el acceso remoto, véase la sección Administración de la
seguridad de los accesos).
• El dominio interno se llama MiEmpresa.Priv y el servidor DirectAccess (llamado
DC2012) está integrado en el dominio.
• Dispone de un firewall cuya dirección IP interna es 172.16.0.254 y publica el puerto
TCP 443 hacia la dirección 172.16.0.1.
• El servidor DirectAccess posee una interfaz privada con la dirección IP
172.16.0.1/24.
• Se ha instalado un certificado de tipo Web sobre el servidor DirectAccess con un
nombre descriptivo: IP-HTTPS.
• Se ha creado un grupo DA_Clientes en el dominio y la máquina cliente
DirectAccess en es miembro del mismo. Este grupo servirá para definir las
máquinas autorizadas a conectarse mediante DirectAccess.

He aquí las etapas que debe seguir para instalar DirectAccess:

En la consola Administrador del servidor, haga clic en Herramientas y, a continuación,

seleccione Administración de acceso remoto.

En el panel de navegación, en Configuración, haga clic en DirectAccess y VPN.

En la parte central, haga clic en Ejecutar el Asistente para introducción.

Haga clic en Implementar solo DirectAccess.

En la etapa Topología de red, seleccione la opción Tras un dispositivo perimetral (con

un solo adaptador de red).

Escriba el nombre público o la dirección IPv4 que utilizan los clientes para conectarse al
servidor DirectAccess.
Haga clic en Siguiente.

Haga clic en Finalizar para aplicar la configuración.

Dado que esta plataforma no dispone de una infraestructura de clave pública (PKI) el
asistente generará automáticamente un certificado autofirmado para HTTPS y habilitará el
proxy Kerberos. También habilitará los protocolos de traducción NAT64 y DNS64 en el
entorno. Preste atención, este certificado se instalará sobre las máquinas cliente para que
DirectAccess funcione.

DirectAccess está, ahora, instalado. Basta con definir los equipos autorizados para
conectarse a este servicio.

Una vez aplicada la configuración, haga clic en Cerrar.

En la parte central, en la sección Paso 1 - Clientes remotos, haga clic en Editar.

Seleccione la opción Implementar DirectAccess completo para acceso de clientes y

administración remota y, a continuación, haga clic en Siguiente.

Elimine el grupo Equipos del dominio (MIEMPRESA\Equipos del dominio) y agregue

el grupo DA_Clientes que ha creado en Active Directory como requisito previo a este
ejemplo.

Desmarque la opción Habilitar DirectAccess solo para equipos móviles (en un ámbito
profesional, y fuera del perímetro de esta maqueta, es preferible dejar esta opción marcada).

Haga clic en Siguiente.

 Escriba la dirección de correo electrónico del equipo de soporte técnico y defina un
nombre de conexión DirectAccess.

Marque la opción Permitir que los clientes de DirectAccess usen la resolución local de
nombres y, a continuación, haga clic en Finalizar.

Esta opción permite al usuario utilizar los servidores DNS locales y, por tanto, que no todas
las consultas DNS se envíen a los servidores DNS internos de la red de la empresa.

En la sección básica de la parte central, haga clic en Finalizar para aplicar la

configuración.

Verifique los parámetros y haga clic en Aplicar.

Una vez aplicada la configuración, haga clic en Cerrar.

En el panel izquierdo de la consola de administración del acceso remoto, seleccione

Estado de las operaciones y espere a que el estado cambie a: funciona correctamente.
Sólo queda probar desde un puesto cliente accediendo a un servidor Web interno o incluso
a la carpeta SYSVOL del dominio (\\miempresa.priv\sysvol).

Para verificar que se puede conectar mediante DirectAccess o, simplemente, que ha

configurado correctamente DirectAccess desde la red local, siga las etapas siguientes desde
un equipo con Windows 8:

En el área de notificación de Windows, haga clic en el símbolo de red .

Aparece la siguiente información:

Existe una guía de depuración (disponible únicamente en inglés en el momento de escribir

estas líneas) en el sitio Web de Microsoft en la siguiente dirección:
http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx

Preste atención, si desea trabajar con esta maqueta sobre un servidor Hyper-V, tendrá que
configurar las tarjetas de red del servidor DirectAccess como tarjeta heredada (o Legacy) si
encuentra problemas de flujo.

5. Supervisión de las conexiones

Todas las soluciones de acceso remoto deben permitir saber qué usuario se conecta y qué
acciones realiza mientras está conectado. Si bien las herramientas DirectAccess de
Windows Server 2012 no permiten tener un nivel de información tan detallado como el que
ofrece un servidor Forefront TMG, sí permiten supervisar mejor la actividad y el uso que
las versiones anteriores de Windows Server.

Windows Server 2012 incluye una nueva consola de supervisión que proporciona
información útil acerca de los usuarios que se conectan de manera remota. La siguiente lista
presenta la información que puede obtenerse en esta consola (información que proviene, de
hecho, de los contadores de rendimiento de Windows Server).

Esta información está accesible desde la Consola de administración de acceso remoto. A

continuación, en el panel izquierdo, haciendo clic en Panel accede al siguiente informe:

• Total de clientes activos: incluye a los clientes de DirectAccess y VPN. Permite

conocer cuántas conexiones simultáneas están en curso a través de VPN o
DirectAccess.
• Total de clientes de DirectAccess activos: permite conocer cuántas conexiones
simultáneas están en curso a través de DirectAccess.
• Total de clientes de VPN activos: permite conocer cuántas conexiones simultáneas
están en curso a través de VPN.
• Total de conexiones acumuladas: permite conocer el número de conexiones
remotas que se han realizado desde el último reinicio del servidor.
• Total de datos transferidos: permite conocer el volumen total de datos que han
transitado por el servidor de acceso remoto desde su último reinicio.
• Máximo de conexiones de cliente: permite conocer el número máximo de
conexiones simultáneas que han tenido lugar después del último reinicio del
servidor de acceso remoto.

También puede encontrar información individual detallada acerca de los clientes en el

menú Estado de cliente remoto, siempre en la Consola de administración de
acceso remoto.

Entre la información disponible, encontrará, por ejemplo:

• Nombre de usuario.
• Nombre de host.
• Dirección del ISP.
• Protocolo/Túnel.
• Duración de la conexión.
Conclusión
Acaba de ver en este capítulo que, para proporcionar un acceso remoto a sus usuarios,
tendrá que configurar un servidor de acceso remoto. Cuando sus usuarios se encuentren
fuera de la empresa podrán acceder a los recursos internos utilizando bien una conexión de
tipo Dial-up, una conexión VPN, o bien DirectAccess.

Windows Server 2012 R2 sabe cómo gestionar las tres soluciones. Permite, además,
agrupar los servidores de VPN y DirectAccess sobre el mismo servidor, lo cual presentaba
problemas en ediciones anteriores de Windows Server.

Incluye toda una serie de mejoras en el servicio de enrutamiento y en el acceso remoto que
hace el despliegue de DirectAccess lo más sencillo posible y fácil de integrar con una
solución VPN clásica.

Windows Server 2012 R2 también le permite, gracias a las nuevas directivas de acceso,
definir de forma muy precisa quién se conecta, cuándo y de qué manera.

Si desea centralizar la seguridad de las conexiones de sus equipos, Windows Server 2012 le
proporciona el rol de concentrador gracias a sus funciones RADIUS.

Trabajando junto a la última versión del OS cliente de Microsoft (Windows 8.1),

aprovechará también nuevas funcionalidades:

• Auto-triggered (inicio automático): permite a las aplicaciones predefinidas

conectarse automáticamente a redes de empresa iniciando una conexión VPN.
• Configuración avanzada de clientes VPN en PowerShell: permite utilizar un juego
único de comandos PowerShell para configurar las conexinoes VPN (mediante el
comando Add-VpnConnection).

Implementar un servidor Intranet/Internet

En este capítulo aprenderá a instalar y configurar un servidor Web gracias al rol de servidor
IIS (Internet Information Services).

1. Presentación de IIS 8
a. Presentación general

IIS 8 (Internet Information Services) es la última versión del servidor Web de Microsoft. Se
incluye de forma completa con Windows Server 2012, y proporciona una plataforma segura
y fácil de administrar para albergar servicios Web y aplicaciones Web enriquecidas. Con
Windows Server 2012 R2, se proporciona la versión 8.5 de la aplicación. IIS 8 es una
plataforma Web unificada que integra IIS, ASP.NET, PHP, servicios FTP y Windows
Communication Foundation (WCF: el modelo de programación de WCF es una capa de
abstracción que unifica y simplifica el mecanismo de integración de los servicios Web,
.NET Remoting, Microsoft Transaction Server y Microsoft Message Queuing).

La compatibilidad hacia atrás de IIS 8.5 permite migrar con facilidad los sitios Web
hospedados en versiones anteriores de IIS sin encontrar problema alguno.

Como con IIS 6, IIS 7 e IIS 7.5, puede instalarse en el sistema operativo cliente (Windows
8) en su versión ligera. Windows 8 y Windows Server 2012 comparten el mismo núcleo,
por lo que es sencillo desplegar aplicaciones desde su puesto de trabajo para, a
continuación, hospedarlas en un servidor.

Observe que Windows Server 2012 y Windows Server 2012 R2 no tienen una edición Web,
puesto que la experiencia previa con los clientes de Microsoft indicaba que preferían
utilizar una versión estándar antes que verse limitados en términos de funcionalidades.

IIS 8.5 puede, también, instalarse en la versión mínima (Core) de Windows Server 2012 R2
(Windows Server 2012 ya permitía instalar IIS 8 en modo Core). Como con Windows
Server 2008 R2 y a diferencia de Windows Server 2008, Windows Server 2012 y Windows
Server 2012 R2 permiten instalar .NET Framework en modo core.

b. Arquitectura heredada

La arquitectura de IIS se ha repensado en IIS 7 para facilitar la implementación de las

funcionalidades y también la extensión de las posibilidades del servidor. En IIS 6, la
estructura estaba compuesta por un único bloque que obligaba a instalar todo para utilizar el
servidor Web. Con IIS 7 / 7.5, las funcionalidades se han desacoplado de forma que es
posible cargar los módulos correspondientes a sus necesidades.

Estos módulos están desacoplados en cinco categorías para la parte Servidor Web.

• Funcionalidades HTTP comunes (contenido estático, documentos por defecto, etc.).

• Desarrollo de aplicaciones (lenguajes incluidos: ASP.NET, ASP, CGI, etc.).
• Integridad y diagnósticos (registro, visor de peticiones, seguimiento, etc.).
 • Seguridad (autenticación básica, autenticación Windows, autorización Digest, etc.).
• Rendimiento (compresión del contenido estático o dinámico).

Para la parte de Herramientas de administración, encontramos:

• La consola de administración de IIS.

• Los scripts y herramientas de administración de IIS.
• El servicio de administración.
• La administración de la compatibilidad con IIS 6.

El servicio FTP (File Transfer Protocol) está separado de la parte servidor Web puesto que
se trata, en lo sucesivo, de un servicio de rol aparte. Los módulos Servidor FTP y Consola
de administración FTP están asociados a él.

c. Administración

IIS 7 y 8 difieren de las versiones anteriores por la implementación de una nueva

administración. La nueva consola de administración que centraliza la administración del
conjunto de módulos del servidor ya no es un simple módulo. En efecto, se trata de una
consola completa que se conecta sobre el servicio de administración

La configuración también ha cambiado. En IIS 6, estaba almacenada en una metabase con

formato XML. IIS 7 / 7.5 facilitan la implementación y sobretodo el mantenimiento de los
servidores, desagregando esta configuración en varios archivos XML:

• applicationhost.config: contiene la configuración global (lista de sitios, pools de

aplicaciones, parámetros por defecto, etc.).
• redirection.config: contiene la información de redirección (utilizada por ejemplo
cuando el contenido del sitio se encuentra en otro servidor o incluso cuando parte
del sitio no debe estar disponible en caso de mantenimiento, etc.).
• web.config: contiene la configuración global ASP.NET del servidor (es posible
crear un archivo individual por cada sitio que necesite una configuración específica;
esto es útil cuando debe especificar parámetros diferentes a los de la configuración
global del servidor). Esto permite realizar una administración más precisa de los
parámetros de los sitios Web.
• machine.config: contiene las propiedades requeridas por las funcionalidades del
Framework.

applicationHost.config y redirection.config se ubican en la ruta %windir%\system32\

inetsrv\config. Los archivos web.config y machine.config se encuentran en la carpeta
%windir%\Microsoft.NET\Framework\version_framework\CONFIG.

Existe una jerarquía entre los distintos archivos de configuración. Define una herencia de
parámetros como pasaría con los permisos de seguridad NTFS. Esta jerarquía comienza por
el archivo machine.config y sigue el orden siguiente: web.config (de primer nivel),
applicationHost.config y por último un archivo web.config opcional situado en la ruta del
sitio o de la carpeta virtual. De este modo, se heredan las propiedades desde el archivo
machine.config hasta el último archivo web.config del árbol.

El almacenamiento de la configuración de sitios en archivos XML distintos (también

llamada configuración distribuida) permite facilitar el despliegue o la copia de aplicaciones.
Podrá copiar aplicaciones entre dos servidores frontales mediante un simple xcopy evitando
cualquier error debido a una replicación o a cualquier sincronización.

En lo sucesivo es posible automatizar las tareas administrativas gracias, principalmente, a

PowerShell, a un nuevo proveedor WMI, a una nueva API.NET y sobre todo gracias a la
herramienta AppCMD. AppCMD.exe permite realizar la mayoría de las tareas
administrativas con ayuda de una sintaxis muy simple.

La administración también puede delegarse. Puede especificar cuales son las

funcionalidades que los usuarios no administradores deben gestionar. Esto permite por
ejemplo configurar los parámetros ASP.NET de un sitio sin tener que usar privilegios de
administrador.

d. Novedades aportadas por IIS 8 en Windows Server 2012

Como hemos visto antes, Windows Server 2012 y Windows Server 2012 R2 proporcionan,
respectivamente, las versiones 8 y 8.5 de IIS. Esta versión aporta un número de mejoras
esperadas respecto a la versión anterior, pero también algunas novedades.

• Evolución de la configuración: los archivos de configuración de IIS voluminosos

pueden, en lo sucesivo, gestionarse fácilmente. Se han aportado un gran número de
mejoras para optimizar el rendimiento de los servidores y las granjas de servidores
que hospedan una gran cantidad de sitios.
• Evolución SSL: en las versiones anteriores de IIS, soportar un gran número de
sitios web seguros mediante un certificado requería una dirección IP para cada sitio.
Además, cuanto mayor era el número de sitios, más memoria se necesitaba. Antes,
tras la primera visita, todos los certificados quedaban cargados. En lo sucesivo, los
certificados se cargan únicamente cuando se accede al sitio y, a continuación, se
eliminan de la memoria tras un periodo de inactividad.
• Centralización de certificados: provee un almacenamiento único para los
certificados SSL de una granja y simplifica la gestión de enlaces SSL.
• Server Name Indication (SNI): el nombre de dominio virtual se incluye, en
adelante, en la negociación SSL de forma que ya no es necesario disponer de una
pareja dirección IP - puerto 443 para hospedar un sitio SSL y tener que dedicar una
dirección IP para dotar de seguridad a un sitio.
• Restricción de direcciones IP dinámicas: esta funcionalidad que permite bloquear
el acceso a los sitios desde ciertas direcciones IP ya existía en IIS 7 y las versiones
anteriores, aunque obligaba a los administradores a introducirlas de forma manual.
Con IIS 8, es posible bloquear estas direcciones IP en función de un número
 máximo de consultas. En adelante, es posible configurar el servidor de modo que
bloquee la conexión de un usuario en lugar de mostrarle una página de tipo 403.6:
Acceso denegado: dirección IP rechazada.
• Restricciones de intentos de conexión FTP: permite configurar el número de
intentos fallidos de realizar una conexión FTP antes de bloquear el acceso.
• Inicialización de aplicaciones: permite a los administradores configurar páginas
temporales hasta que una aplicación haya terminado de iniciarse y se proporcione el
acceso al "verdadero" sitio.
• Compatibilidad con dispositivos NUMA (Non Uniform Memory Access): esto
permite evitar una degradación del rendimiento con la multiplicación de los núcleos
del procesador y cuando no se ha optimizado la pareja núcleos/RAM del servidor.
• CPU Throttling: limita la CPU, la memoria y el ancho de banda que utiliza un pool
de aplicaciones en un entorno. IIS 8 incluye ocho opciones adicionales.
• Soporte Mixto ASP.NET 3.5 y 4.5: IIS 8 para Windows Server 2012 permite
ejecutar aplicaciones sobre todas las versiones del .NET Framework soportadas por
Windows Server 2012.

La consola MMC IIS resulta obsoleta con Windows Server 2012. Se eliminará en las
sucesivas versiones de Windows Server.

e. Novedades aportadas por IIS 8.5 en Windows Server 2012 R2

Tras su aparición, Windows Server 2012 incluye numerosas mejoras en términos de

seguridad, mientras que Windows Server 2012 R2 se centra en la evolución y la
supervisión con las siguientes funcionalidades:

• Registro global avanzado: muchos campos pueden seleccionarse para registrarse

gracias a los campos personalizados. Puede, de este modo, crear sus propios
criterios de registro gracias a los orígenes de encabezado de la consulta, de
encabezado de la respuesta o incluso de variables de servidor (por ejemplo:
HTTP_ACCEPT ; LOGON_USER ; etc.).
• Registro en el registro de eventos Windows ETW (Event Tracing for
Windows): enviar los eventos de registro hacia el registro ETW permite, al
administrador, utilizar herramientas estándar de consulta o incluso distribuir vistas
personalizadas para seguir, en tiempo real, el registro en ETW. Puede, a
continuación, consultar los eventos en el registro Microsoft-Windows-IIS-Logging.
• Activación dinámica de sitios Web: con IIS 8.5, cuando el número de sitios
configurados es importante (el valor por defecto es de 100), IIS no activa ningún
sitio para no consumir recursos inútilmente. Cada sitio se inicia tras la primera
consulta. Esto permite reducir, de manera significativa, la cantidad de recursos de
sistema necesarios para su funcionamiento.
• Pausa de los procesos inactivos: con IIS 8.5, el administrador tiene la posibilidad
de suspender un proceso de trabajo (worker process) inactivo en lugar de detenerlo.
Un proceso de trabajo suspendido sigue vivo, paginado en disco, lo cual reduce los
 recursos de sistema que consume. Cuando algún usuario acceda de nuevo al sitio, el
proceso de trabajo volverá a memoria y estará, rápidamente, disponible de nuevo.

2. Instalación del rol Servidor Web (IIS) en modo Windows Server mínimo
a. Instalación por defecto

Para realizar una instalación por defecto en un servidor Windows Server 2012 R2 en modo
Core, utilice el comando PowerShell siguiente:

Install-WindowsFeature Web-Server

b. Instalación completa

Para realizar una instalación completa de IIS 8.5 (con todas las funcionalidades) sobre un
servidor Core Windows Server 2012 R2, utilice el siguiente comando PowerShell:

Install-WindowsFeature -Name Web-Server -IncludeAllSubFeatures

Puede verificar que el rol está bien instalado utilizando el comando Get-WindowsFeature.
Si lo ejecuta verá la lista de roles de servidor disponibles. Para cada uno de ellos verá una
indicación Installed o Available. Para los servidores de rol instalados, se representa un sub-
árbol con el estado de la instalación de cada servicio de rol.
3. Instalación del rol Servidor Web (IIS) en modo gráfico

A continuación se muestran las distintas etapas a seguir para instalar el rol Servidor Web
(IIS) en modo gráfico:

En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y

características.

Seleccione la opción Instalación basada en roles o características y, a continuación,

haga clic en Siguiente.

Seleccione su servidor en la lista (aquí DC2012) y, a continuación, haga clic en Siguiente.

Marque la opción Servidor web (IIS) como se muestra y, a continuación, haga clic en
Siguiente.
 En el cuadro de diálogo Agregar características requeridas para Servidor Web (IIS),
haga clic en Agregar características.
Haga clic en Siguiente.

En la pantalla Características, haga clic en Siguiente.

Lea la descripción del rol de Servidor Web y, a continuación, haga clic en Siguiente.

En el ejemplo en curso, solamente utilizará las funciones básicas de IIS. Deje marcadas las
opciones por defecto y, a continuación, haga clic en Siguiente.
Verifique las opciones marcadas y, a continuación, haga clic en Instalar.
 Verifique que la instalación se ha desarrollado correctamente y, a continuación, haga clic
en Cerrar.

Para verificar que IIS 8.5 está operativo, abra Internet Explorer y, a continuación, en la
barra de direcciones escriba la URL: http://localhost.

Debería aparecer la ventana siguiente:

Crear un sitio Web
Ahora que ha instalado su rol de Servidor Web (IIS), veremos cómo crear nuevos sitios y
administrarlos fácilmente. En este capítulo configurará un sitio para su empresa (el
contenido del sitio será mínimo, pues el objetivo de este libro no es formarle en los
lenguajes de desarrollo Web).

1. Creación y configuración de un sitio

En la consola Administrador del servidor, haga clic en Herramientas - Administrador

de Internet Information Services (IIS).

Por defecto la consola de administración de IIS se conecta al servidor local. Esto le permite
cambiar la configuración y los parámetros del servidor.

En el panel izquierdo, haga clic en el nombre de su servidor (aquí DC2012) para mostrar la
lista de funcionalidades disponibles.
La primera vez que se conecte, se abre un asistente que le permite instalar Microsoft Web
Platform. Microsoft Web Platform Installer es una herramienta gratuita que permite instalar
componentes, aplicaciones web o gestores de contenidos de manera gratuita y con un solo
clic. Puede hacer clic en Sí en la maqueta aunque no vayamos a utilizar esta funcionalidad
en las siguientes etapas.

Por defecto, la página muestra las funcionalidades agrupadas por Área. Puede cambiar esta
representación mediante la lista desplegable ubicada en la sección superior del panel
central. De este modo, es posible agrupar por Área (por defecto), por Categoría o incluso
sin agrupar.

He aquí las distintas etapas para crear un nuevo sitio:

Requisitos previos: debe haber creado una carpeta Empresa en la carpeta

C:\inetpub\wwwroot.

Desde la consola Administrador de Internet Information Services (IIS), haga clic con
el botón derecho del ratón sobre el nombre de su servidor y, a continuación, seleccione la
opción Agregar sitio Web (es posible realizar esta misma operación desde otros lugares.
Por ejemplo, directamente desde el árbol de Sitios).

Indique los datos como se muestra a continuación:

El nombre del sitio es meramente informativo, los espacios en blanco no suponen ningún
problema.

En este ejemplo, no informe el nombre del host y deje los parámetros del enlace por
defecto. Estos parámetros de enlace sirven para definir sobre qué puerto y/o con qué
nombre va a acceder al sitio (encontrará más detalles en la sección Uso de los
encabezados host de este capítulo).

Una vez haya completado los campos, haga clic en Aceptar. Aparece el siguiente mensaje:
La razón por la que aparece este mensaje es porque IIS ya hospeda un sitio que utiliza el
puerto 80 en la misma dirección IP. Se trata del sitio Web por defecto. No es posible, para
una única dirección IP y un mismo puerto, tener varios sitios Web (salvo que utilicemos
encabezados HTTP; este punto se aborda en la sección Uso de los encabezados host de este
capítulo).

Si trata de levantar el sitio Web obtendrá un mensaje de error. Para confirmarlo, siga los
siguientes pasos:

Haga clic en Sí en la ventana que presenta la advertencia del enlace duplicado.

En el panel central, seleccione su sitio Web y, a continuación, en el panel derecho, haga

clic en Iniciar. Aparecerá el siguiente mensaje.

En este ejemplo, cambiará el puerto sobre el que escucha el sitio Web.

En el panel izquierdo, extienda el árbol Sitios para mostrar el sitio que acaba de crear y, a
continuación, selecciónelo.

En el panel derecho, en la sección Acciones, haga clic en Enlaces.

Seleccione el enlace HTTP y, a continuación, haga clic en Modificar.

Escriba 8080 en el campo Puerto y, a continuación, haga clic en Aceptar para validar. A
continuación, haga clic en Cerrar.

Este puerto se define de forma arbitraria puesto que no está siendo utilizado por los
servidores que sirven como ejemplo. Generalmente se utiliza para servidores de tipo proxy
como puerto estándar.

En el panel de acciones, haga clic en Iniciar.

Tendrá que mostrar algún documento en su sitio web. Para crearlo, abra el Bloc de notas y,
a continuación, escriba el código siguiente:
<HTML>
<head>
<Title>Sitio web de mi Empresa</Title>
</head>

<body>
He aquí mi primer sitio Web en IIS 8.5
</body>
</HTML>

Guárdelo como archivo en la ubicación: C:\inetpub\wwwroot\Empresa\default.htm

Para comprobar su funcionamiento, abra Internet Explorer y, a continuación, escriba la

dirección: http://localhost:8080

2. Uso de los encabezados host

Si bien es posible utilizar puertos de escucha distintos para cada sitio Web, en la
práctica esto no resulta una solución viable cuando varios sitios Web están hospedados
sobre el mismo servidor. Este problema se presenta, en particular, para los sitios Web
públicos. Los internautas no saben en qué puerto está configurado el servicio de su sitio
Web y, por lo tanto, no es factible demandarles que indiquen el puerto concreto al que
quieren conectarse para acceder a un sitio Web en Internet.

Una de las soluciones que permiten resolver este problema de puertos consiste en
configurar varias direcciones IP sobre su servidor Web. Cada IP se asocia, a continuación,
con un sitio único. Si bien esta solución puede sacarnos del apuro en un uso interno, se
convierte en una solución muy costosa para un uso público (las direcciones IP fijas en
Internet representan una inversión y se proporcionan de forma limitada).

Para poder administrar de forma óptima la ubicación de varios sitios Web, tendrá que
utilizar los encabezados host. Estos encabezados permiten utilizar varios nombres de host
para una única dirección IP. IIS escuchará las solicitudes entrantes y revisará la
información enviada por el navegador. En función del nombre de host recibido, redirigirá la
consulta del navegador hacia el sitio Web correspondiente.
En el siguiente ejemplo va a configurar el sitio creado en la etapa anterior para que escuche
en la dirección www.miempresa.es.

Requisitos previos: disponer de un servidor DNS funcional que hospede la zona

MiEmpresa.es. En esta zona debe existir un registro de tipo A llamado www que apunte a
la dirección IP 172.16.0.1 (dirección IP de su servidor Web).

Consulte el capítulo Implementar los servicios de red de la empresa - Implementar los

sistemas de resolución de nombres para obtener más información acerca de la
configuración DNS.

En la consola Administrador del servidor, haga clic en Herramientas - Administrador

de Internet Information Services (IIS).

Despliegue el árbol Sitios para mostrar el sitio creado en la etapa anterior de este capítulo
(sitio Web de mi empresa).

Seleccione su sitio y, a continuación, en el panel derecho, haga clic en Enlaces.

En la ventana Enlaces de sitios, haga clic en Agregar.

Complete la información de los campos tal y como se muestra a continuación:

Valide haciendo clic en Aceptar y, a continuación, en Cerrar.

También puede modificar el enlace existente para especificar estos parámetros. No
obstante, gracias a este ejemplo, comprobará que es posible asociar puertos distintos a un
mismo sitio incluso con nombres de host distintos.

Pruebe, a continuación, la modificación abriendo Internet Explorer y escribiendo la

dirección http://www.miempresa.es en la barra de direcciones.

Cada nombre de host que quiera utilizar en IIS debe existir. En un sitio Intranet, basta con
agregar registros en su zona DNS de dominio. Para un uso público, tendrá que gestionar la
zona DNS pública. O bien tiene acceso a una interfaz de administración que se lo permite, o
bien solicita al administrador de su zona DNS crear los registros de acuerdo a las reglas.

3. Implementar una DMZ

Una DMZ (Demilitarized Zone) o Zona desmilitarizada es una zona de la red en la que los
usuarios de Internet pueden acceder a los servidores sin poner en peligro la seguridad de su
red local. El objetivo de esta zona es limitar la superficie de exposición de sus redes.
Organizando los servidores de modo que aquellos que albergan aplicaciones públicas estén
en la red perimétrica, no permitirá el acceso a su red local desde Internet. De este modo,
reforzará la seguridad de su red local impidiendo la comunicación con la misma.

Existen dos implementaciones típicas de DMZ. La primera utiliza un firewall con tres
interfaces de red o más (firewall multidominio).
La segunda utiliza dos firewalls. En el caso ideal, y para dotar de una máxima seguridad a
la infraestructura, es recomendable utilizar dos modelos de firewall distintos. En efecto, si
una persona malintencionada encuentra un fallo en el primero, ya tiene el trabajo
prácticamente hecho para llegar a abrir el segundo, si son idénticos.

A continuación, sólo le queda gestionar los flujos entre Internet y la DMZ, y entre la DMZ
y la LAN. En efecto, si sus servidores Web llaman a recursos de red, necesitarán un acceso
a la misma. Basta con autorizar a los servidores de la DMZ para comunicarse con la LAN
con los protocolos requeridos. A continuación, podrá restringir el acceso para mejorar la
seguridad tanto en la DMZ como en su red local.
Del lado del servidor, Windows Server 2012 configura automáticamente las excepciones de
su firewall. Habiendo agregado el rol de servidor IIS, ya ha autorizado automáticamente los
flujos http y HTTPS. Sólo le falta gestionar los puertos abiertos en los equipos del firewall.

4. Implementación del CPU Throttling

En un entorno multi-tenant (multicliente) es importante crear una maqueta ("sandbox" que

podríamos considerar como un espacio dedicado) para cada cliente. Sin esta maqueta, un
cliente podría, de forma intencionada o no, impactar en los demás clientes de forma
negativa accediendo al contenido de los demás clientes o monopolizando recursos del
servidor como, por ejemplo, la memoria, la CPU o incluso el ancho de banda.

Desde IIS 8 para Windows Server 2012, esta maqueta se crea por pool de aplicaciones.
Ofrece, al mismo tiempo, un límite a nivel de procesos Windows haciendo que cada cliente
se ejecute en entidades distintas y estableciendo un límite en el uso de recursos para cada
proceso.

La funcionalidad de CPU Throttling no consiste en una reserva de recursos de CPU sino en

un límite de uso máximo.

Para configurarlo en su sitio Web, creado en las etapas anteriores, siga los siguientes pasos:

En la consola Administrador del servidor, haga clic en Herramientas - Administrador

de Internet Information Services (IIS).

En la sección Conexiones, despliegue su servidor (DC2012) y, a continuación, seleccione

Grupos de aplicaciones.

En el panel central, seleccione su pool de aplicaciones (Sitio Web de mi Empresa).

En el panel Acciones, haga clic en Configuración avanzada....

Vaya a los parámetros de CPU:

 • Afinidad del procesador habilitada: permite especificar si los procesos de trabajo
que utiliza este pool de aplicaciones deben ejecutarse sobre procesos específicos.
Esta opción permite utilizar eficazmente las cachés de los procesadores en
servidores multiprocesadores.
• Límite (1/1000 de %): indica que el uso máximo de CPU (este valor se define
como 1/1000 de un %: en resumen, para definir un uso máximo del 10 %, habrá que
escribir 10000 para que tenga en cuenta el 1/1000 de 10000, o bien el valor 10) para
este pool de aplicaciones. SI hay varios procesos asociados a este pool, el límite se
aplica a la suma total de los procesos.
• Acción de límite: indica la acción que se quiere realizar si se supera este límite:

• NoAction: no realiza ninguna acción.

• KillW3wp: IIS se detendrá.
• Throttle: esta opción reduce el uso de CPU al valor definido como límite.
• ThrottleUnderLoad: esta opción reduce el uso de CPU al valor definido como
límite aunque únicamente cuando se alcanza la carga de CPU máxima. El pool de
aplicaciones podrá utilizar más recursos siempre que el procesador esté inactivo.

Ejemplo de configuración de CPU Throttling

Escriba 30000 en el campo Límite (1/1000 de %) para obtener un 30 % como umbral.

Seleccione el valor Throttle para la opción Acción de límite.

Simule una carga o utilice una herramienta como WCAT

(http://www.iis.net/downloads/community/2007/05/wcat-63-%28x64%29) para hacerlo.

Instalar un sitio FTP con aislamiento de

usuarios
Para proporcionar un espacio de almacenamiento en Internet a sus usuarios, o incluso a los
clientes para los que hospeda sitios Web, seguramente necesitará proporcionarles un acceso
FTP.

Para restringir su campo de acción y asegurar que no ven las carpetas de otras personas,
tendrá que configurar el aislamiento de usuarios.
Requisitos previos: disponer de una instalación básica de IIS; haber creado las cuentas
usuario1 y usuario2 en Active Directory.

1. Instalación del rol Servidor FTP

En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y

características.

Haga clic en Siguiente.

Seleccione la opción Instalación basada en un rol o una funcionalidad y, a

continuación, haga clic en Siguiente.

Seleccione su servidor y, a continuación, haga clic en Siguiente.

Despliegue el árbol Servidor Web (IIS).

Marque la opción Servidor FTP y, a continuación, haga clic en Siguiente.

Haga clic en Siguiente.

En la página que permite seleccionar las funcionalidades, haga clic en Siguiente.

Verifique las opciones de selección y, a continuación, haga clic en Instalar.

Una vez terminada la instalación, haga clic en Cerrar.

2. Configuración del aislamiento de usuarios

Antes de pasar a la configuración del servicio FTP, va a crear datos que permitirán
visualizar la correcta implementación del aislamiento de usuarios.

Abra una ventana de comandos y escriba el siguiente comando:

CACLS "C:\inetpub\ftproot" /G IUSR:R /T /E

Este comando permite dar permisos de lectura a la cuenta anónima IIS sobre la carpeta
ftproot.
 Cree una carpeta LocalUser en la carpeta ftproot y, en esta nueva carpeta, cree la carpeta
Public. Esta carpeta servirá para almacenar el contenido que se provee a los usuarios
anónimos.

Cree un archivo de texto llamado archivopublico.txt en la carpeta Public.

Cree una carpeta MIEMPRESA (nombre NetBIOS de su dominio) en la carpeta ftproot.

Preste atención, es importante que nombre esta carpeta con el nombre de su dominio. Si
no respeta esta condición, el aislamiento de usuarios no funcionará correctamente y serán
incapaces de encontrar su carpeta raíz.

Cree las carpetas usuario1 y usuario2 en la carpeta MIEMPRESA.

Cree un archivo de texto llamado archivousuario1.txt en la carpeta usuario1 y haga lo

mismo con un archivo llamado archivousuario2.txt en la carpeta usuario2.

En la consola Administrador del servidor, haga clic en Herramientas - Administrador

de Internet Information Services (IIS).

En el panel Conexiones, haga clic con el botón derecho sobre el nombre de su servidor y, a
continuación, seleccione Agregar sitio FTP....

Rellene la información tal y como se describe más abajo y, a continuación, haga clic en
Siguiente.
Seleccione Sin SSL en la sección SSL y, a continuación, haga clic en Siguiente.

En este ejemplo, configurará el servidor FTP para que no exija el protocolo SSL. En la
práctica, como utiliza una cuenta de dominio, convendrá dotar de seguridad a la
autenticación. De este modo, tendrá que adquirir un certificado SSL (o entregarlo mediante
una entidad emisora de certificados) y exigir SSL de forma que la información esté cifrada
y evitar, de este modo, cualquier intercepción de las credenciales.
Marque la opción Anónima, en la lista Autorización seleccione Usuarios anónimos y
marque la opción Leer.

Haga clic en Finalizar.

En la consola Administrador de Internet Information Services (IIS), en el panel

Conexiones, despliegue el árbol DC2012 - Sitios - Mi Sitio FTP.

En el panel central, haga doble clic en Autenticación FTP.

En el panel central, haga clic con el botón derecho en Autenticación básica y, a

continuación, seleccione Habilitar.

Vuelva a su sitio FTP y, a continuación, haga doble clic en Reglas de autorización de

FTP en el panel central.

En la sección Acciones, haga clic en Agregar regla de permiso....

Las reglas de autorización permiten autorizar o denegar el acceso a los usuarios. Es posible
precisar si un usuario tiene permisos de escritura o, simplemente, de lectura.
Seleccione Todos los usuarios y marque las opciones Leer y Escribir y, a continuación,
valide haciendo clic en Aceptar.

Vuelva a su sitio FTP y, a continuación, haga doble clic en Aislamiento de usuarios FTP.

Seleccione Directorio de nombres de usuario (deshabilitar los directorios virtuales

globales).
Esta opción permite restringir el acceso de los usuarios a la carpeta física o virtual del FTP
que tiene el mismo nombre que su cuenta FTP. No podrán subir en la arborescencia FTP.
Las carpetas virtuales globales raíz se ignoran (una carpeta virtual global sirve como acceso
directo hacia una carpeta física definida; esto permite dar acceso a una carpeta con un
nombre diferente o simplificando la ruta de acceso; esto permite también definir
autorizaciones de acceso distintas), los usuarios sólo podrán acceder a las que estén
definidas explícitamente en su arborescencia.

Las otras posibilidades son:

Directorio físico de nombres de usuario (habilitar los directorios virtuales globales):

esta opción aísla a los usuarios en la carpeta física que lleva el mismo nombre que su
cuenta FTP. Las carpetas virtuales globales están accesibles en la medida en que el usuario
tenga las autorizaciones asociadas.

Directorio particular de FTP configurado en Active Directory: los usuarios están

aislados en una carpeta base definida en las propiedades de su cuenta Active Directory.

En el panel de acciones haga clic en Aplicar.

Es momento de verificar el aislamiento de usuarios.

Abra el navegador Internet Explorer.

Escriba, en la barra de direcciones: ftp://dc2012.

Debería obtener el siguiente resultado:

Se trata del resultado esperado puesto que está habilitado el acceso anónimo y no ha
especificado credenciales algunas.

Abra el explorador de Windows y escriba la dirección ftp://usuario1@dc2012 en la barra

de direcciones. A continuación, valide.

Obtiene una ventana de identificación, escriba el nombre de usuario usuario1 y su

contraseña asociada. A continuación, haga clic en Iniciar sesión.

Comprobará que solamente ve el contenido de la carpeta individual de usuario1.

En este ejemplo, ha utilizado un dominio y, por tanto, creado una carpeta correspondiente
al nombre de dominio en ftproot. En el caso de que se utilice un servidor ftp autónomo,
utilice el nombre de la carpeta LocalUser para crear carpetas de usuario.

3. Configuración de la restricción de intentos de conexión

Una posible vulnerabilidad en un servidor consiste en un ataque del tipo "fuerza bruta" (un
ataque por fuerza bruta consiste en un método utilizado para encontrar una contraseña o una
clave. Se trata de probar, una a una, todas las combinaciones posibles. Este método de
búsqueda exhaustiva tiene éxito en aquellas ocasiones en que la contraseña que se busca
está formada por pocos caracteres) mediante los servicios FTP. Partiendo del principio de
que las cuentas que utiliza FTP son, a menudo, cuentas de usuario físicas del sistema
operativo resulta, teóricamente, posible adivinar la cuenta de administrador una vez conoce
la versión del servidor FTP (por ejemplo: Administrador para un servidor Windows y root
para un servidor Linux).

Con IIS 8 y Windows Server 2012, Microsoft incluye la funcionalidad de dotar de

seguridad integrada con el objetivo de prevenir ataques de tipo "fuerza bruta" sobre el
servidor FTP. Observe que esta funcionalidad no se activa en el sitio FTP sino a nivel de
servidor.

Para implementarla, siga los pasos siguientes:

En la consola Administrador del servidor, haga clic en Herramientas - Administrador

de Internet Information Services (IIS).

En el panel izquierdo, seleccione su servidor (DC2012).

En el panel de funcionalidades, sección FTP, haga doble clic en Restricciones de intento

de inicio de sesión de FTP.

Marque la opción Habilitar restricciones de intento de (opción que no ha sido del todo
bien traducida al castellano).

Defina el número máximo de intentos de conexión fallidos así como el periodo de tiempo
entre cada intento.

Deje marcada la opción Denegar direcciones IP basándose en el número de intentos

fallidos de inicio de sesión.
Haga clic en Aplicar en el panel Acciones.

Conclusión
Acaba de ver en este capítulo que para administrar sitios Internet y/o Intranet debe utilizar
el rol Servidor Web (IIS).

IIS 8 e IIS 8.5 conservan la arquitectura de su predecesor, así como las mejoras que se han
aportado en términos de seguridad y de modularidad. Aportan, no obstante, varias mejoras
dedicadas a hospedar sitios Web y a la gestión multicliente.

La seguridad sigue siendo el núcleo principal de mejora. En particular, las restricciones

dinámicas de direcciones IP así como las restricciones de intentos de conexión FTP.

Se ha evolucionado también la gestión de SSL y, en particular, el hecho de que el dominio

virtual forme parte, en adelante, de la negociación SSL. La gestión centralizada de
certificados permite, en sí misma, simplificar la renovación de los certificados; el nombre
DNS de los certificados se lee y asocia directamente al sitio correspondiente gracias a su
encabezado de host. Es, también, posible almacenar los archivos de certificados en un
recurso compartido de archivos en la red, en lugar de hacerlo de manera local sobre cada
servidor web para simplificar la administración de certificados.
La diferencia entre IIS 8 e IIS 8.5 se pone de manifiesto principalmente en la optimización
del funcionamiento, aportando importantes mejoras, principalmente en lo relativo a
proveedores de soluciones Cloud.

Introducción
Este capítulo está dedicado a la securización de Windows Server 2012 R2. La seguridad se
encuentra en el núcleo de este sistema operativo, cuya implantación más evidente es la
instalación llamada "mínima", de ahí el nombre inglés "Core" para nombrarla. En este
capítulo descubrirá cómo administrar esta versión tan particular y tan útil en un entorno
hostil.

Principios del servidor Core

Esta sección presenta las principales características del servidor Core, los dominios para los
que ha sido previsto su uso, así como aquellos para los que no es posible utilizarlo.

1. Restricciones ligadas a una instalación mínima

Con la opción de instalación mínima, la interfaz estándar de usuario (a saber, el intérprete

de comandos gráfico de servidor) no está instalado. Por ello, las tareas de gestión del
servidor se realizan mediante herramientas de interfaz de usuario remotas (RSAT),
Windows PowerShell o, si tiene lugar, de forma local por línea de comandos (o Windows
PowerShell).

Por analogía, esta instalación mínima sigue llamándose Core, como en Windows 2008
Server y 2008 R2 Server, por parte de los usuarios.

El interés de una instalación Core consiste en reducir la superficie de ataque, lo cual tiene
un impacto en los roles que pueden instalarse en el servidor. La aplicación de las
actualizaciones también se ha visto reducida, lo que facilita el ciclo de vida del servidor.
Desde Windows Server 2008 R2, se incluye el Framework .NET en la edición Core, lo cual
abre nuevos usos (PowerShell, sitios IIS...).

Es posible instalar los siguientes roles en un servidor Windows Server 2012 R2:

• Controlador de dominio (típicamente un RODC).

• Servicios de Certificados de Active Directory.
• Servicios AD LDS (Active Directory Lightweight Directory Services).
• Servidor DHCP y DNS.
• Servidor de archivos (y Administrador de recursos del servidor de archivos).
• Hyper-V (una de sus especialidades).
• Acceso remoto.
• Servicios de impresión y de digitalización de documentos.
 • Servidor Web IIS (parte de ASP.NET):

• BranchCache (retransmisión).
• Servidor multimedia.
• Servicios WSUS (Windows Server Update Services).

2. Instalación mínima

La instalación Core es sucinta, ¡lo cual se pone de manifiesto desde la instalación! Sólo se
necesitan 5 minutos, aproximadamente, desde que se inserta el DVD de instalación hasta
que aparece el prompt de autenticación, incluso sin haber automatizado la instalación

En esta etapa, nada indica que se trata de una instalación mínima. Es una vez autenticados
cuando la diferencia se hace patente.

No se trata de una captura de pantalla parcial, sino de la pantalla completa. No hemos

ocultado Explorer en ningún sitio, ¡su archivo ejecutable está completamente ausente en el
disco duro! El objetivo consiste en reducir al máximo los componentes y recursos, para
adecuarlos en términos de seguridad y para las máquinas virtuales.
Desde el punto de vista de la seguridad, cuantos menos elementos instalados, ejecutándose
o accesibles haya, mayor será el nivel de seguridad. Por ejemplo, y puesto que no es posible
disponer de Explorer.exe, cualquier fallo de seguridad que afecte a este componente no
tendrá el más mínimo efecto en un servidor Core. Más allá del hecho de que el fallo no sea
explotable, no es necesario instalar cualquier hotfix que lo corrija más adelante. Si bien ya
existía una versión Core de Windows Server 2000, se ha reducido en torno al 60% el
número de actualizaciones a instalar, y en torno al 40% respecto a Windows Server 2003.
El impacto del sistema operativo se ha reducido considerablemente:

• Tras el arranque, con una única sesión abierta, se utilizan 300 MB de memoria
frente a los más de 500 MB en una instalación completa.
• Se necesitan 6,3 GB de espacio en disco, frente a los casi 11 GB para una
instalación completa. Windows Server 2012 R2 incluye, sistemáticamente, una
partición de unos 350 MB.

Observe también que, con Windows Server 2012 R2, Windows Defender se instala
automáticamente con la versión Core.

Configurar de manera local un servidor

Core
La ausencia de consolas de administración no incita a administrar de forma local un
servidor Core, lo cual forma parte del objetivo. Una vez se ha realizado la configuración
mínima, basta con conectarse desde un host de remoto que posea consolas de
administración que permitan superar estas restricciones. Esta sección cubre la
configuración inicial para autorizar una administración descentralizada.

Con Windows Server 2012 R2, también es posible utilizar la consola Administrador del
servidor para administrar un servidor Core (habilitando winrm en el servidor Core
previamente).

En el modo Core, cuando se abre una sesión, se utiliza la línea de comandos como interfaz,
y ésta se abre de forma automática. Para que PowerShell sea la línea de comandos por
defecto en Windows Server 2012 R2, ejecute el siguiente comando en una ventana
PowerShell:

$RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\
SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon"

Set-ItemProperty -Confirm -Path $RegPath -Name Shell -Value

’PowerShell.exe -noExit -Command "$psversiontable’

Restart-Computer
1. Sconfig

Para simplificar la configuración inicial de un Servidor Core, a partir de Windows Server

2008 R2 se incluye una nueva herramienta: sconfig. Esta consola permite configurar los
siguientes elementos desde su menú interactivo:

• Unirse a un dominio o grupo de trabajo.

• Cambiar el nombre del equipo.
• Agregar un administrador local.
• Configurar la administración remota.
• Conectarse a Windows Update.
• Definir la configuración de red.
• Configurar la fecha y hora.

Abrir esta herramienta es tan sencillo como escribir su nombre en una ventana de
comandos: sconfig.

Habrá comprendido, si tiene la suerte de poseer Windows Server 2012 R2, que no será
necesario realizar la mayor parte de las configuraciones que siguen. No obstante, siempre
es interesante conocer los distintos métodos que se ofrecen.

2. Configurar la fecha y la hora

Ciertas acciones, evidentes sobre un servidor clásico, pueden resultar desconcertantes en

esta versión depurada. Una de las primeras a realizar sobre un servidor consiste en
configurar la fecha y la hora. Incluso si se va a unir a un dominio, debe tener, por defecto,
un desfase menor a 5 minutos respecto a la fecha y hora del dominio para que Kerberos
funcione correctamente y permita su unión al dominio.
Existen varias soluciones (los comandos time y date siguen existiendo), aunque a
continuación se presenta cómo abrir la interfaz gráfica en un servidor Core:

Desde una línea de comandos, ejecute controltimedate.cpl:

3. Parámetros regionales

Si desea modificar los parámetros regionales, puede utilizar el comando control intl.cpl.

4. Resolución de pantalla

Para cambiar la resolución de la pantalla ya no es preciso, como en la versión anterior,

utilizar la base de registro. Microsoft ha incorporado el comando Set-DisplayResolution.

Utilice, por tanto, el siguiente comando:

Set-DisplayResolution [-Width] <valorEnPixels> [-Height]

<valorEnPixels>
5. Salvapantallas

También es posible modificar el salvapantallas por línea de comandos. Para ello, abra el
editor regedit desde la línea de comandos abierta en pantalla.

Navegue, en la arborescencia, hasta la ruta: HKEY_CURRENT_USER\Control

Panel\Desktop

Existen cuatro claves que le permiten administrar el nombre del salvapantallas, el

bloqueo automático de la sesión tras el inicio del salvapantallas y el tiempo de espera antes
de su ejecución:

• ScreenSaveActive: permite habilitar o deshabilitar el salvapantallas de forma

global. Puede tomar los valores 1 (activo) o 0 (deshabilitado).
• SCRNSAVE.EXE: indica la ruta del salvapantallas que se quiere utilizar. El
parámetro por defecto es C:\Windows\system32\logon.scr. El salvapantallas
scrnsave.scr está disponible en el servidor y evita un consumo del procesador
inútil, especialmente en un entorno virtual.
• ScreenSaverIsSecure: permite habilitar o no el bloqueo de la sesión tras la
ejecución del salvapantallas. Su valor por defecto es 1, que habilita esta protección.
• ScreenSaveTimeOut: número de segundos antes de que se ejecute el
salvapantallas. Por defecto, el valor está fijado a 600 segundos.

Con la instalación sólo está disponible la clave ScreenSaveActive. Las otras tres se crean
manualmente como "valores cadena" (REG_SZ).

En el marco de un dominio Active Directory, estos parámetros se administran mediante las

directivas de grupo de forma centralizada.

6. Nombre del servidor

Por defecto, al servidor se le asigna un nombre de máquina aleatorio, siempre con el prefijo
WIN-.

• Para conocer el nombre actual, ejecute el siguiente comando desde la línea de

comandos: hostname
• Para cambiar el nombre del servidor, ejecute el comando siguiente desde la línea de
comandos:

netdom renamecomputer <nombredesuservidor> /NewName:DC2012

• Es preciso reiniciarlo para que se tenga en cuenta el cambio:

Por línea de comandos:

shutdown /r /t 0 /C "renombrado del servidor"

Mediante PowerShell:

Restart-Computer

7. Administración de controladores

Es posible administrar los controladores por línea de comandos gracias a la herramienta

pnputil.

Puede enumerar los controladores instalados y que se están ejecutando mediante el

comando:

Pnputil -e

Para agregar e instalar controladores suplementarios, hay que utilizar los parámetros -a y -i
y precisar la carpeta donde se encuentran:

Pnputil -a -i c:\miscontroladores\*.inf

Para obtener la lista de controladores habilitados, utilice el siguiente comando (no olvide el
espacio tras el signo =):

-sc query type= driver

8. Configuración de red

El servidor utiliza, por defecto, un direccionamiento DHCP sobre todas las interfaces. Para
cambiar a un direccionamiento por IP estática, tiene que utilizar el comando PowerShell
Set-NetIPAddress. Cada tarjeta de red posee un número atribuido que se utiliza en el
comando Get-NetIPInterface para determinar la tarjeta de red a la que se desea aplicar los
cambios. Para enumerar las tarjetas de red y ver los identificadores atribuidos por
Windows, ejecute el siguiente comando desde la línea de comandos PowerShell:

Get-NetIPInterface

Por ejemplo, si desea configurar la tarjeta de red con un identificador 12 con un

direccionamiento por IP estática, ejecute:

Set-NetIPAddress -InterfaceIndex 12 -IPAddress 172.16.0.1

-PrefixLength 16

Donde:

• InterfaceIndex es el valor de la columna IfIndex detallada en la etapa 2 (en este

ejemplo, 12).
• IPAddress es la dirección IP estática que se quiere definir (en este ejemplo,
172.16.0.1).
• PrefixLength es la longitud del prefijo (otra forma de máscara de subred) de la
dirección IP que ha definido (en este ejemplo, 16).

Para configurar la dirección 172.16.0.2 como servidor DNS primario, ejecute el siguiente
comando:

Set-DNSClientServerAddress -InterfaceIndex 12 -ServerAdresses 172.16.0.2

Debería obtener un resultado equivalente al siguiente:

Para configurar el sufijo DNS por defecto, hay que modificar la base de registro. Para ello,
ejecute desde la línea de comandos:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v "NV

Domain" /d "MiEmpresa.Priv" /f

9. Activación de Windows

La activación de la licencia de Windows puede administrarse por línea de comandos. El

script slmgr.vbs se instala con Windows en la ruta %systemroot%\System32 para ello.
Recuerde que, a diferencia de las versiones anteriores de Windows, la activación es
obligatoria, incluso con una licencia por volumen. Este script funciona, también, con KMS
(Key Management Service).

Para verificar el estado de activación actual, ejecute el comando:

cscript %systemroot%\System32\slmgr.vbs /dlv

En este ejemplo, la licencia expira en 180 días. Se trata de una versión de evaluación de
Windows no registrada.

Si simplemente quiere conocer la fecha en la que expira la licencia, ejecute el script con el
parámetro /xpr.

cscript %systemroot%\System32\slmgr.vbs/xpr

Por defecto, el servicio KMS se encuentra automáticamente en su dominio Active

Directory con la consulta DNS siguiente: _vlmcs._tcp.miempresa.local.

Si existe esta entrada DNS, el servidor intentará conectase al puerto TCP 1688. Puede, de
este modo, indicar manualmente el nombre del servidor KMS con el parámetro -skms.

Para iniciar manualmente la activación de Windows, ejecute el comando:

cscript %systemroot%\System32\slmgr.vbs /ato

10. Gestión del informe de errores

El servicio de informe de errores puede configurarse por línea de comandos.

Para verificar la configuración actual, ejecute el comando: serverWerOptin /query

Para activar el informe de errores simple: serverWerOptin /summary

Para activar el informe de errores detallado: serverWerOptin /detailed

Para desactivar el informe de errores: serverWerOptin /disable

11. Configurar el archivo de paginación

El archivo de paginación (PageFile) se gestiona, automáticamente, por defecto. Para

conocer la configuración actual, puede utilizar el comando: wmic pagefile list /format:list
Antes de configurar manualmente el PageFile, es preciso deshabilitar la administración
automática:

wmic computersystem where name="%computername%" set

AutomaticManagedPagefile=False

Para forzar un tamaño de PageFile de 2 GB:

wmic pagefileset where name="C:\\pagefile.sys" set InitialSize=2048,

MaximumSize=2048

Es necesario reiniciar el servidor para que el cambio tenga efecto.

12. Unirse a un dominio

El comando netdom permite unirse a un dominio Active Directory existente. Ejecute, desde
la línea de comandos:

netdom join <nombredemiservidor> /domain:<miDominioAD>

/userd:<CuentaConPermisos> /password:*

El símbolo * indica que debe solicitarse la contraseña, evitando tener que escribirla en claro
en la consola.

El mismo comando permite sacar un equipo de un dominio Active Directory: netdom

remove

Igual que con Windows Server 2008 R2 y Windows Server 2012, es posible unirse a un
dominio sin estar conectado a la red del dominio en ese preciso momento. El capítulo
Despliegue de servidores y puestos de trabajo cubre con detalle esta operativa (sección
Unirse al dominio sin red).

13. Administrar el registro de eventos

Si bien la consola Visor de eventos permite visualizar los registros de un servidor remoto,
puede gestionarlos de forma local desde el servidor Core. Es posible mostrar la lista de los
registros de eventos en la consola mediante el comando: wevtutil el

La ventana Línea de comando, sin ser ideal para una visualización masiva, ni muy rápida,
puede filtrar los resultados de salida especificando el número de eventos que se quiere
mostrar. Por ejemplo, para mostrar únicamente los cinco últimos eventos: wevtutil qe
System /c:5 /f:Text

También es posible visualizar solamente los cinco últimos errores agregando el parámetro
"/q:*[System[(Level=1 or Level=2)]]".
 • El nivel 1 se corresponde con los eventos "críticos".
• El nivel 2 se corresponde con los eventos de "error".
• El nivel 3 se corresponde con los eventos de "advertencia".
• El nivel 4 se corresponde con los eventos de "información".

El siguiente comando permite guardar el registro abierto en un archivo y comenzar así un

nuevo registro:

wevtutil cl system /bu:c:\MisDocumentos\syslog.evtx

Administración remota
1. Activación del Escritorio remoto

Como con la versión completa de Windows Server 2012, el acceso remoto no está activado
por defecto. Puede verificar el estado de su activación con el siguiente comando:

cscript.exe c:\windows\system32\scregedit.wsf /AR /v

Como se explica en el capítulo Servicios de Escritorio remoto, la clave fDeny-

TSConnections deshabilita el control remoto cuando su valor es 1, como es el caso por
defecto. El mismo script permite cambiar la clave a cero y autorizar las conexiones:

cscript.exe c:\windows\system32\scregedit.wsf /AR 0

En este estado, sólo los clientes que ejecuten al menos Windows Vista o Windows Server
2008 podrán conectarse. Para autorizar la conexión de clientes de versiones anteriores:

cscript.exe c:\windows\system32\scregedit.wsf /cs 0

La siguiente captura de pantalla muestra los comandos descritos anteriormente y permite,

mediante el comando netstat y su filtro sobre el valor 3389 (puerto TCP de los servicios de
Escritorio remoto) darse cuenta de que el servicio Escritorio remoto no estaba habilitado
antes de ejecutar estos comandos.
2. Activación de WinRM

WinRM es la implementación de Microsoft del protocolo WS-Management. El objetivo

consiste en poder comunicar dos sistemas del sistema de información, pudiendo atravesar
correctamente los firewalls. Para instalar WinRM, ejecute el siguiente comando desde la
línea de comandos: WinRM quickconfig.

Para verificar que WinRM está activo y escuchando ejecute el comando:

winrm enumerate winrm/config/listener

Quickconfig se encarga de agregar la excepción sobre el firewall para que el servicio esté
accesible a través de la red.
Por defecto, WinRM utiliza el protocolo HTTP. Es posible utilizar HTTPS, con la
condición de tener instalado un certificado válido (que no haya expirado, y que no sea auto-
firmado). Para ello, basta con especificar el transporte HTTPS: WinRM quickconfig -
transport:https

Si desea utilizar WinRM para acceder a un servidor que no esté en su dominio Active
Directory, debe utilizar un certificado SSL, o bien utilizar la lista de equipos aprobados.
Esta lista está situada del lado del cliente, y puede administrarla potencialmente mediante
una directiva de grupo, facilitando así las altas y las bajas de servidores en esta lista.

Si desea administrar localmente esta lista, puede utilizar el comando siguiente para agregar
servidores:

winrm set winrm/config/client @{TrustedHosts="<miLista>"}

Será preciso reemplazar miLista por uno o varios elementos separados por comas. Es
posible utilizar direcciones IP y nombres DNS.

Para obtener la lista actual de hosts aprobados:

winrm get winrm/config/client

Si sus servidores pertenecen a un dominio Active Directory, puede administrar WinRM

desde las directivas de grupo:
Sería una pena mostrar este protocolo sin hablar, por ejemplo, de sus capacidades. He aquí
algunas posibilidades que ofrece WinRM.

• Mostrar el resultado del comando ipconfig /all de un servidor remoto:

winrs -r:NombreDelServidor ipconfig /all

• Especificar una cuenta de usuario y una contraseña (la contraseña se solicita a

continuación):

winrs -r:NombreDelServidor -u miotracuenta ipconfig /all

• Ejecutar una consulta WMI:

winrm get wmicimv2/win32_service?name=W32Time -r :NombreDelServidor

WinRM está, también, disponible en las versiones anteriores de Windows (XP, 2003) como
componente suplementario. Puede acceder a él descargándolo de la siguiente
dirección: http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=8
45289ca-16cc-4c73-8934-dd46b5ed1d33

Dotar de seguridad al servidor Core

1. Administración del firewall

Como en la versión completa, el firewall de Windows está habilitado por defecto en la

edición mínima. Esto resulta bien visible pues el servidor no responde al comando ping,
mientras que la dirección MAC correspondiente a la IP está visible con el comando arp -a.
La gestión de las reglas de firewall puede volverse compleja, por lo que resulta útil poder
administrarlas a distancia. Esto puede realizarse mediante las directivas de grupo, pero
también utilizando la consola adecuada de forma remota. Antes de ello, es necesario haber
autorizado la administración de las reglas de firewall a distancia sobre el servidor,
ejecutando el siguiente comando:

netsh advfirewall set currentprofile settings remotemanagement enable

La consola Firewall de Windows con seguridad avanzada no permite seleccionar

directamente un equipo remoto. Para ello, es necesario ejecutar el administrador de consola
mmc y, a continuación, agregar la consola Firewall de Windows con seguridad
avanzada y, a continuación, tendrá la posibilidad de seleccionar el equipo concreto.
Encontrará más información acerca de la configuración del firewall en modo gráfico en el
capítulo Securizar su arquitectura.

Las demás consolas mmc pueden estar autorizadas sobre el firewall para poder utilizarse de
forma remota. He aquí una lista de los elementos que se pueden visualizar con los nombres
correspondientes en las reglas:

• Servicios: Administración remota de los servicios.

• Programador de tareas: Administración remota de las tareas programadas.
• Visor de eventos: Administración remota de los visores de eventos.
• Monitor de confiabilidad y rendimiento: Registro de alertas de rendimiento.
• Administración de almacenamiento y recursos compartidos: Compartición de
archivos e impresoras.

Netsh advfirewall firewall set rule group="nombre_de_las_reglas"

new enable=yes

Para administrar IPsec de manera remota, es necesario habilitar, en primer lugar, su

administración remota:

cscript \windows\System32\scregedit.wsf /im 1

Para que la administración remota de volúmenes funcione, es necesario iniciar,

previamente, el servicio de disco virtual: net start vds

2. Administración automática de las actualizaciones

La activación o desactivación de actualizaciones automáticas puede administrarse de forma

local. Si el servidor forma parte de un dominio Active Directory, debería administrar
preferentemente esta configuración mediante las directivas de grupo.

• Para saber si están habilitadas las actualizaciones:

cscript C:\Windows\System32\Scregedit.wsf /au /v

• Para habilitar las actualizaciones:

cscript C:\Windows\System32\Scregedit.wsf /au 4

Si obtiene el siguiente mensaje de error: Scregedit.wsf(777, 3) (null): 0x80240037, elimine

la siguiente clave de registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

• Para deshabilitar las actualizaciones :

cscript C:\Windows\System32\Scregedit.wsf /au 1

Puede forzar la verificación inmediata de las actualizaciones ejecutando el comando:

wuauclt /detectnow

Puede forzar la instalación inmediata de las actualizaciones ejecutando el comando:

wuauclt /install

A pesar de estos comandos, el servicio de actualizaciones almacena la fecha y hora de la

última verificación. También, después de la petición inicial, se impone un tiempo de espera.
Para acelerar el proceso puede suprimir la clave del registro que contiene la fecha y hora de
la última y de la próxima verificación:

net stop wuauserv

reg delete
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
WindowsUpdate\ Auto Update" /f
net start wuauserv
wuauclt /detectnow

Sigue existiendo un retardo de varios minutos.

Para consultar la lista de actualizaciones instaladas, utilice el comando siguiente:

wmic qfe list

3. Hacer una copia de seguridad del servidor

La instalación Core se utiliza a menudo en un entorno hostil, de modo que es útil poder
realizar al menos copias de seguridad locales del sistema. La administración de las copias
de seguridad se realiza instalando la funcionalidad Windows Server Backup mediante
PowerShell:

Add-WindowsFeature Windows-Server-Backup

Para iniciar manualmente una copia de seguridad, es preciso utilizar el comando wbadmin.
En nuestro ejemplo, vamos a realizar una copia de seguridad del lector C:\ en la carpeta
compartida \\otroservidor\carpetascompartidas\copiasdeseguridad:

wbadmin start backup

-backuptarget :\\otroservidor\carpetascompartidas\copiasdeseguridad
-include:c: -allcritical -vssfull -quiet

Las rutas UNC pueden utilizarse directamente como destinos de la copia de seguridad. Se
creará una carpeta llamada "WindowsImageBackup". A continuación se creará
automáticamente una carpeta con el nombre del servidor. Cualquier copia de seguridad
anterior se borrará de forma automática. La restauración completa puede hacerse utilizando
el DVD de instalación (opción restauración).

Para obtener más información acerca del uso de Windows Server Backup, consulte el
capítulo El ciclo de vida de su infraestructura.

Implementar un servidor Core y sus

aplicaciones asociadas
1. Instalación de roles y características

Los comandos oclist y ocsetup presentes en Windows Server 2008/2008 R2 han dado paso,
en lo sucesivo, a los comandos PowerShell Get-WindowsFeature y Add-WindowsFeature
desde Windows Server 2012. El primero enumera los roles instalados o no, y el segundo
permite instalarlos. Para eliminar un rol o una característica, será preciso utilizar el cmdlet
PowerShell Remove-WindowsFeature.

Un ejemplo de salida por pantalla del comando Get-WindowsFeature es:

a. Roles de red

La instalación de roles de red se limita a un simple comando. He aquí los comandos que
permiten realizar la instalación de los distintos roles de red disponibles. Estos roles
consumen pocos recursos de sistema pero son necesarios permanentemente. Utilizar una
instalación mínima permite dotarlos de seguridad y limitar los cortes de servicio gracias a la
reducción del número de actualizaciones de seguridad a instalar.

Instalar el rol DHCP Server

Para instalar el rol DHCP Server, utilice los siguientes comandos:

Add-WindowsFeature DHCP

Para autorizar el servidor DHCP, ejecute:

Add-DhcpServerInDC -DnsName dc2012.MiEmpresa.Priv

Si el servidor se convierte, a continuación, en controlador de dominio habrá que autorizarlo

de nuevo.

Para crear un ámbito sobre el servidor DHCP que incluye el rango de direcciones
172.16.0.100 a 172.16.0.250:

Add-DhcpServerv4Scope -Name "Ámbito de mi empresa" -StartRange

172.16.0.100 -EndRange 172.16.0.250 -SubnetMask 255.255.255.0

Para definir un rango de exclusión:

Add-DHCPServerV4ExclusionRange -ScopeId 172.16.0.0 -StartRange

172.16.0.100 -EndRange 172.16.0.120

Para proveer una dirección IP de la puerta de enlace por defecto y los servidores DNS en
los contratos DHCP:

Set-DhcpServerv4OptionDefinition -OptionId 3 -DefaultValue 172.16.0.254

Set-DhcpServerv4OptionDefinition -OptionId 6 -DefaultValue 172.16.0.1

Para proveer el sufijo DNS en el contrato DHCP:

Set-DhcpServerv4OptionDefinition -OptionId 15 -DefaultValue

MiEmpresa.Priv

Para habilitar el ámbito:

Set-DhcpServerv4Scope -ScopeId 172.16.0 -Name "Ámbito de mi empresa"

-State Active

El comando netsh sigue existiendo, si no quiere utilizar PowerShell. Puede consultar la lista
de argumentos utilizando el comando netsh dhcp /?. A continuación, puede obtener la
misma sintaxis para obtener ayuda sobre un argumento. Por ejemplo: para obtener ayuda
sobre la forma de agregar un ámbito: netsh dhcp server add /?

Instalar el rol DNS server

Para instalar el rol DNS Server, utilice el comando siguiente:

Add-WindowsFeature DNS

Para agregar una zona DNS primaria local sobre el servidor:

Add-DnsPrimaryZone -Name MiEmpresa.Priv -Filezone MiEmpresa.Priv.dns

Es muy sencillo agregar entradas de forma manual. Por ejemplo, para declarar un segundo
servidor DNS para la zona:

Add-DnsServerResourceRecord -ZoneName MiEmpresa.Priv

-Name NombreDelServidor -A -IPV4Address 172.16.0.2
Add-DnsServerResourceRecord -ZoneName MiEmpresa.Priv -NS
-Name MiEmpresa.Priv -NameServer NombreDelServidor.MiEmpresa.Priv

La zona no acepta, por defecto, actualizaciones dinámicas. Para autorizarlas, es necesario

utilizar el comando:

Set-DnsServerPrimaryZone -Name MiEmpresa.Priv -DynamicUpdate

NonSecureAndSecure

Puede ver todas las entradas de una zona por línea de comandos:

Get-DnsServerResourceRecord -Name MiEmpresa.Priv

Para enumerar todas las zonas declaradas en el servidor:

Get-DnsServerZone

Windows Server 2008 R2 incluye la securización del DNS (DNSSEC), lo que permite
verificar que la fuente es digna de confianza para la resolución y la transferencia de zonas.
Una infraestructura de tipo PKI permitirá proteger las entradas DNS.

b. El rol servidor de archivos

A diferencia de los roles de red, se proporcionan varios roles en función de sus necesidades.
Puede seleccionar instalar o no FRS, RFRS, DFS, SIS e incluso NFS. El capítulo
Arquitectura distribuida de acceso a los recursos de este libro cubre con detalle la
administración distribuida de recursos mediante DFS, por lo que aquí nos interesaremos por
las especificidades ligadas a la instalación Core. Este tipo de instalación es adecuado para
este rol, pues la disponibilidad es vital para la mayoría de usuarios. Podrá utilizarse una
mayor cantidad de memoria gracias al bajo perfil de consumo del sistema operativo, y la
reducción del número de actualizaciones reduce los cortes del servicio.

• Instalación del servicio de compartición de archivos con PowerShell:

Add-WindowsFeature FS-FileServer

• Instalación del servicio DFS:

Add-WindowsFeature FS-DFS-Namespace

• Instalación del servicio Replicación DFS:

Add-WindowsFeature FS-DFS-Replication

• Instalación del servicio NFS:

Add-WindowsFeature FS-NFS-Service

Windows Server 2012 incluye el servicio FSRM (File Server Resource Manager) en su
edición Core. Esto permite administrar el almacenamiento burocrático (gestión de cuota,
bloqueo de archivos por extensión e informes sobre el consumo de espacio en disco) así
como tener en cuenta el control de acceso dinámico, que se aborda en el capítulo Securizar
su arquitectura.

Para instalar FSRM:

Add-WindowsFeature FS-Resource-Manager

La consola Administrador de recursos del servidor de archivos debe estar instalada en el

equipo utilizado para administrar FSRM:

Import-module servermanager
Add-WindowsFeature RSAT-FSRM-Mgmt

Basta, a continuación, con agregar las excepciones sobre el firewall para administrar de
manera remota los recursos compartidos (sobre el servidor Core en entrada y sobre el
equipo que ejecuta el administrador del servidor):

netsh advfirewall firewall set rule group="Administración remota de

recursos
del servidor de archivos" new enable="yes"
netsh advfirewall firewall set rule group="Administración remota
de volúmenes"
new enable="yes"

c. El rol servidor de impresión

El rol de servidor de impresión se instala por línea de comandos PowerShell:

Add-WindowsFeature Print-Services
Agregar una impresora al servidor:

Desde un equipo Windows 8 u otro Windows Server 2012 R2 que no sea la edición Core,
abra la consola administración de impresión. Si no se encuentra en un servidor Windows
Server 2012 R2, puede agregarla independientemente utilizando el comando:

Add-WindowsFeature RSAT-Print-Services

A continuación, basta con administrar el rol igual que en la edición completa.

2. Servicio de directorio (AD)

El despliegue y la configuración de los servicios de directorio se han simplificado con

Windows Server 2012, y esta simplificación también se encuentra en la edición mínima. En
efecto, si antes era necesario proporcionar los archivos de respuesta para el despliegue, en
lo sucesivo tiene a su disposición un conjunto de comandos PowerShell para realizar el
despliegue. Para empezar, hay que instalar el servicio de rol Active Directory (AD DS):

Add-WindowsFeature AD-Domain-Services

A continuación, es necesario desplegar un nuevo bosque:

Install-ADDSForest -DomainName "MiEmpresa.Priv" -DomainNetBIOSName

MIEMPRESA

El rol servidor DNS se instala de manera automática y, una vez finalizada la instalación y la
creación del bosque, el servidor reinicia.

La instalación de un nuevo dominio hijo o dominio en la arborescencia se realiza mediante

Windows PowerShell:
Install-ADDSDomain -NewDomainName hijo -ParentDomainName MiEmpresa.Priv

La instalación de un controlador de dominio suplementario (réplica) mediante Windows

PowerShell se realiza mediante el siguiente comando:

Install-ADDSDomainController -DomainName miempresa.priv

3. Ejecutar aplicaciones de 32 bits

Windows Server 2012 es un sistema operativo que existe, únicamente, en 64 bits. No

obstante, las aplicaciones de 32 bits pueden ejecutarse gracias a una emulación (Wow64
por Windows On Windows). Siendo el objetivo principal de un servidor Core reducir la
superficie de ataque y, en particular, evitar que los virus de 32 bits puedan funcionar, se le
aconseja desactivar la emulación WoW64 si no tiene aplicaciones que la necesiten. Para
ello, basta con eliminar el paquete ServerCore-WOW64 mediante PowerShell:

Remove-WindowsFeature Wow64-Support

Flexibilidad de la administración con el

modo Core
La instalación mínima es la opción por defecto desde Windows Server 2012. Windows
Server 2012 R2 ofrece la posibilidad de modificar ambas opciones en cualquier momento
una vez realizada la instalación. En consecuencia, puede seleccionar, inicialmente, una
opción de instalación completa para poder configurar el servidor mediante las herramientas
gráficas y, más adelante, pasar a una opción de instalación mínima. La interfaz gráfica ya
no está vinculada al modo de instalación, aunque se considera una funcionalidad completa
del sistema operativo.

Es, también, interesante saber que existe un modo intermedio llamado Servidor con
Interfaz básica. Este modo se sitúa entre los dos anteriores por el motivo siguiente: el
intérprete gráfico de comandos es, en lo sucesivo, una característica. Si bien la interfaz de
administración gráfica habitual (explorador de Windows, barra de herramientas, etc.) se
elimina y nos deriva a un modo Core, sí tiene, en cualquier momento, la posibilidad de
abrir herramientas de gestión gráfica tales como una consola MMC.

Para cambiar a este modo intermedio puede utilizar el siguiente comando PowerShell:
Uninstall-WindowsFeature Server-Gui-Shell -Restart, o bien utilizar la consola
Administrador del servidor y eliminar la característica ”Interfaz gráfica del servidor”.
1. Paso del modo GUI al modo Core

Si la idea de utilizar una línea de comandos para instalar las funcionalidades de Windows
no le agrada, o simplemente por sus aspectos prácticos prefiere instalar inicialmente su
servidor en modo gráfico, configurar los distintos servicios de rol y, a continuación, pasar a
un modo de servidor mínimo para dotarlo de seguridad, puede pasar del modo GUI al modo
Core ejecutando el siguiente comando desde una línea de comandos Windows PowerShell
con privilegios de administrador:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart

Esta misma operación puede realizarse desde la consola Administrador del servidor:

Haga clic en Administrar - Eliminar roles o características.

Haga clic en Siguiente.

Seleccione su servidor y, a continuación, haga clic en Siguiente.

En la etapa Roles del servidor haga clic en Siguiente.

En la lista de características, desmarque Infraestructura e interfaces de usuario.

En el cuadro de diálogo, haga clic en Quitar características.

Haga clic en Siguiente.

Haga clic en Eliminar para confirmar su elección.

Una vez realizada la modificación, haga clic en Cerrar.

Reinicie su servidor para que se tengan en cuenta los cambios.

2. Paso del modo Core al modo GUI

En ciertas situaciones, puede necesitar utilizar las interfaces de usuario gráficas que están
disponibles en los servidores en modo gráfico. Puede pasar de un servidor en instalación
mínima a un servidor en modo gráfico realizando las siguientes etapas (debe reiniciar el
equipo).

Para pasar de un servidor en modo de instalación mínima al modo gráfico cuando el

servidor se ha instalado, originalmente, en modo de instalación mínima, los archivos
binarios correspondientes a la funcionalidad de consola gráfica no están presentes. Puede
utilizar los archivos fuentes de instalación para realizar este cambio. Es necesario, para esta
operación, crear un punto de montaje siguiendo los pasos que se describen a continuación:

Cree una carpeta de montaje mediante el comando:

mkdir MountDir

Introduzca el DVD de instalación de Windows Server 2012 (x: se corresponde con su

lector de DVD).

Las opciones de instalación (mínima, gráfica, Datacenter, Standard) poseen un índice

asociado. Determine el índice asociado a una imagen de servidor en modo gráfico (por
ejemplo, SERVERDATACENTER, y no SERVERDATACENTERCORE) gracias al
comando.

Get-WindowsImage -ImagePath x:\sources\install.wim

Anote el número de índice correspondiente a esta versión (4 en este ejemplo).

Ejecute:

Dism /mount-wim /WimFile:X:\sources\install.wim /Index:4 /MountDir:

c:\mountdir /readonly

Ejecute:

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell
-Restart -Source c:\mountdir\windows\winsxs

O, si prefiere utilizar Windows Update como origen, en lugar del archivo WIM, ejecute el
siguiente comando Windows PowerShell:

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell
-Restart

Una vez terminadas las tareas de administración, puede volver al modo de instalación
mínima si lo necesita (debe reiniciar el equipo) utilizando el siguiente comando Windows
PowerShell:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -restart

3. Uso de funcionalidades bajo demanda

En las versiones anteriores de Windows, cuando un rol o una característica del servidor no
estaba habilitado, los archivos binarios correspondientes se conservaban en disco, lo cual
consumía un espacio de disco innecesario. En Windows Server 2012 R2, cuando
deshabilita un rol o una característica, tiene la posibilidad de eliminar completamente los
archivos correspondientes, lo que se corresponde con el estado "eliminado" (removed) en el
Administrador del servidor o "deshabilitado con eliminación de la carga" en Dism.exe.

• Para eliminar completamente un rol o una característica, ejecute, en Windows

PowerShell, el cmdlet Uninstall-WindowsFeature con el parámetro -Remove.

Por ejemplo, para eliminar completamente el Explorador de Windows, Internet

Explorer y los componentes relacionados, ejecute el siguiente comando Windows
PowerShell:

Uninstall-WindowsFeature Server-Gui-Shell -remove

Para reinstalar un rol o una característica que haya sido completamente eliminado, debe
utilizar los archivos fuente de instalación.

• Para instalar un rol o una característica habiéndolo eliminado completamente,

utilice el comando Install-WindowsFeature con el parámetro -Source. La opción -
Source define una ruta de acceso a una imagen WIM y el número de índice de la
imagen. Si no indica la opción-Source, Windows utiliza Windows Update por
defecto.
• Para instalar un rol o una característica que se ha eliminado mediante una imagen
WIM, utilice el procedimiento y los comandos Windows PowerShell siguientes:
• Get-WindowsImage -imagepath <ruta de acceso a wim>\install.wim
 y, a continuación, indique el índice de la imagen de instalación en modo gráfico de
Windows Server 2012.

Install-WindowsFeature <nombre_característica> -Source

wim:<ruta>:<índice>

donde:

o nombre_característica se corresponde con el nombre del rol o de la

característica objeto de Get-WindowsFeature.
o ruta es la ruta de acceso al punto de montaje WIM.
o índice es el índice de la imagen de servidor que figura en la etapa en que ha
utilizado el comando Get-WindowsImage.

Por ejemplo, si la imagen de instalación en modo gráfico se encuentra en

D:\sources:

Install-WindowsFeature <nombre_característica> -Source

wim:d:\sources\
install.wim:4

• Puede, a su vez, especificar una fuente para los servidores que son miembros del
dominio mediante una directiva de grupo. Acceda a Configuración del equipo -
Plantillas administrativas - Sistema - Especificar parámetros para desinstalar
componentes opcionales y reparar componentes.

4. Novedades aportadas a PowerShell

Ya lo conoce, a menos que no utilice las herramientas de gestión remota del servidor
(RSAT: Remote Server Administration Tools), pero puede utilizar PowerShell para
administrar su servidor de manera local. Windows PowerShell 4.0 se incluye con Windows
Server 2012 R2 y aporta un gran número de funcionalidades que extienden su uso,
mejorando su experiencia y permitiendo gestionar de forma mucho más sencilla y eficaz los
entornos Windows. Entre las novedades, encontrará:

• Windows PowerShell Desired State Configuration (DSC): se trata de un nuevo

sistema de gestión que permite desplegar y gestionar las configuraciones que se
aplican a los entornos. Por ejemplo, DSC permite instalar o eliminar roles y
características en los servidores, gestionar bases de registro, archivos y carpetas e
incluso grupos y usuarios locales. Encontrará más detalles acerca de sus
características y cómo crear una configuración en el blog technet siguiente:
http://blogs.technet.com/b/privatecloud/archive/2013/08/30/introducing-powershell-
desired-state-configuration-dsc.aspx
• La directiva por defecto para ejecutar scripts está, ahora, fijada como
RemoteSigned (antes el valor por defecto era Restricted, impidiendo así la
ejecución de scripts no firmados).
 • Se han aportado mejoras, también, a PowerShell Web Access, PowerShell Web
Services, PowerShell Workflow y PowerShell ISE. Encontrará la descripción del
conjunto de actualizaciones en la siguiente dirección:
http://technet.microsoft.com/en-us/library/hh857339.aspx

Conclusión
Gracias a todas las etapas de configuración seguidas anteriormente, usted dispone, ahora,
de un servidor Core completamente funcional en su entorno. Se han presentado algunos de
sus uso principales, y otros, como Hyper-V, se han descrito en el capítulo Consolidar sus
servidores.

La opción de instalación mínima requiere menos espacio en disco, disminuye la superficie

expuesta a los atacantes y facilita considerablemente las operaciones de mantenimiento y de
reinicio del servidor. Por todos estos motivos, se recomienda escoger una instalación
mínima siempre que no necesite utilizar los elementos de la interfaz de usuarios y las
herramientas de administración gráfica suplementarias en la opción Servidor con una GUI
y si los roles y/o características que faltan en esta versión no le son imprescindibles.

Esta edición se ha visto reforzada con, por ejemplo, la posibilidad de instalar SQL 2012
sobre un servidor Core: http://msdn.microsoft.com/en-us/library/hh231669.aspx

Las ventajas de esta instalación mínima son reales, y la principal dificultad consiste en
acostumbrarse a su administración cotidiana. ¿Supone el Server Core el final de la división
entre la interfaz Windows y el shell de Unix?

Introducción
Este capítulo está dedicado a la solución de virtualización de Microsoft, Hyper-V. A
diferencia de los productos anteriores de Microsoft sobre la materia, como Virtual Server,
la virtualización se ha pensado desde el diseño de un sistema operativo. Este verdadero
hipervisor está disponible de forma gratuita (sin compra de licencia Windows Server 2012
R2) con el nombre Microsoft Hyper-V Server 2012 R2 y puede descargarse del sitio de
Microsoft (http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx). En
este capítulo, descubrirá cómo rentabilizar la infraestructura existente y volverla más
flexible de cara a los cambios.

¿Por qué consolidar?

La virtualización está cada vez más extendida en las empresas. Aun así, no debería
implementarse como algo sistemático. Antes de iniciar un proyecto de virtualización,
debería medir bien todas las consecuencias, así como las potenciales ventajas. Como ocurre
con muchas otras cosas, se recomienda pensar a lo grande pero comenzar dando pequeños
pasos.

1. Virtual frente a Físico

En un primer enfoque, virtualizar permite superar ciertas restricciones relativas al

hardware, permitiendo obtener un mejor rendimiento. El enfoque de uso de servidores
físicos es más sencillo para comenzar, aunque se complica con el número de servidores.
Además del mantenimiento de los sistemas operativos y sus aplicaciones es necesario
gestionar el ciclo de vida del material:

• Fallos de hardware.
• Actualizaciones de la BIOS, firmwares, controladores.
• Ciclos de amortización.

En efecto, las soluciones a estos problemas son conocidas y pueden gestionarse sin
problemas en base a la metodología de trabajo actual. No obstante, siempre existe el riesgo
de que aparezca un nuevo modelo de servidor que reemplace al anterior para el que su
imagen de instalación de Windows no contenga el controlador adecuado. La virtualización
le proporciona los medios para enmascarar esta administración y así poder dedicarse
plenamente a tareas de mayor valor añadido.

a. Optimización de los costes

Uno de los objetivos de la virtualización es la reducción de costes en infraestructura. Para

ello, uno de los grandes ejes es la optimización de los recursos disponibles. La capacidad de
los servidores sigue creciendo de forma exponencial, aunque las necesidades de las
aplicaciones no siempre siguen la misma progresión. Incluso el servidor más barato
disponible en los fabricantes de hardware tiene como mínimo un procesador con dos o
cuatro núcleos, algunos gigabytes de memoria RAM y almacenamiento SAS acorde. Si
algún servidor alberga una o incluso varias aplicaciones, seguramente no utilizará más que
un modesto porcentaje de los recursos. La mayoría de fabricantes de software siguen, por
otro lado, solicitando un servidor dedicado para asegurar el soporte para sus programas.
Como resultado se tienen salas de servidores con muchos equipos, aunque ninguno de ellos
esté utilizado por encima del 10% de su capacidad. La virtualización permite mantener una
división lógica, en un sistema operativo dedicado, consolidando la infraestructura de
hardware. Esta consolidación física ya tiene un impacto importante sobre los costes:

• Reducción del conjunto de los costes vinculados con la sala de servidores: eléctrico,
climatización, cableado, alquiler del suelo...
• Reducción de costes de mantenimiento, proporcional al número de servidores
físicos que se ahorren.

La virtualización también reduce los costes ligados a la inclusión de un nodo en la

infraestructura. La generación de una máquina virtual no supone ningún coste de cableado
informático, de puesta en rack... Este ahorro cobra todo el sentido en un entorno donde el
número de peticiones sea importante, como por ejemplo en entornos de desarrollo o de
pruebas. La solución SCVMM (System Center Virtual Machine Manager) permite incluso
implementar un portal de autoservicio para la creación de máquinas virtuales a la carta.

Un uso menos convencional consiste en utilizar la virtualización para mantener en

funcionamiento los sistemas obsoletos, donde el material ya no esté en mantenimiento o
pueda mantenerse. La mayoría de Sistemas de Información poseen algunos equipos
obsoletos, con aplicaciones para las que ya no existe documentación ni fuentes. Migrarlas a
máquinas virtuales permite mantenerlas en el Sistema de Información evitando problemas
de hardware.

b. Límites de la virtualización

No todos los equipos son buenos candidatos para la virtualización. La solución Hyper-V no
soporta, por ejemplo, el conjunto de sistemas operativos Microsoft. En el momento de
escribir este libro, se soportan las versiones siguientes:

Tipo servidor:

• Windows Server 2012 R2, Windows Server 2012.

• Windows Server 2008 (en 32 y 64 bits) SP2, 2008 R2 SP1.
• Windows 2003 SP2, 2003 R2 SP2 en 32 y 64 bits.
• Windows Home Server 2011, Windows Small Business 2011.
• CentOS 5.7 a 6.4.
• Red Hat Enterprise Linux 5.7 a 6.4.
• SUSE Linux Enterprise Server 11 SP 2 y SP3, en 32 y 64 bits.
• OpenSUSE 12.1.
• Ubuntu Server 12.04 LTS, 12.10, 13.04 y 13.10.
• Debian 7.0
• FreeBSD 8.2, 8.3 et 9.0.
• Oracle Linux 6.4 (solo un kernel compatible con Red Hat).

Tipo cliente:

• Windows 7, Windows 8 y Windows 8.1 en 32 y 64 bits.

• Windows XP SP3, XP x64 SP2, Vista SP2.
• CentOS 5.7 a 6.4.
• Red Hat Enterprise Linux 5.7 a 6.4.
• OpenSUSE 12.1.
• Ubuntu 12.04, 12.10, 13.04 y 13.10.
• Oracle Linux 6.4 (solo con un kernel compatible con Red Hat).

Como cualquier sistema operativo instalado sobre un servidor físico, donde es necesario
instalar controladores para reconocer el hardware, los sistemas operativos instalados en las
máquinas virtuales necesitan, a su vez, controladores que les permitan reconocer el
hardware. Todo hipervisor posee controladores virtuales. Con Microsoft Hyper-V se llaman
Servicios de integración.

En VMware ESX, son las VMware Tools.

Salvo para Windows Server 2012 R2 y Windows 8.1, todos los demás sistemas operativos
necesitan que se instalen (o actualicen) los servicios de integración. Para sistemas
operativos como SUSE Linux, OpenSUSE, Ubuntu y Oracle Linux, no se requieren estos
servicios puesto que ya están integrados en estos sistemas, como con Windows Server 2012
R2 y Windows 8.1. Para CentOS (distinto a 5.9 y 6.4) y Red Hat (distinto a 5.9 y 6.4),
tendrá que descargar e instalar los servicios de integración 3.4:
http://www.microsoft.com/en-us/download/details.aspx?id=34603

Encontrará en el sitio Web Windows Server Catalog la lista de dispositivos y aplicaciones

homologados para Hyper-V, en la siguiente dirección:
http://www.windowsservercatalog.com/svvp.aspx

Incluso aunque no estén oficialmente soportados, algunos otros sistemas operativos

funcionan sin problema sobre Hyper-V, tales como MS-DOS, Windows NT4, Windows
2000 Server, algunas distribuciones de Linux o incluso Sun Solaris 10, por ejemplo.

Ciertos elementos de la arquitectura no deben coexistir en la misma infraestructura, a

efectos de disponibilidad. Por ejemplo, no deberían existir dos servidores DNS o DHCP en
el mismo servidor Hyper-V. En caso contrario, si se produce un fallo en el servidor, ambos
servicios quedarán indisponibles al mismo tiempo aunque estén disponibles dos veces en la
misma red para prestar alta disponibilidad. Servicios diferentes que tengan una fuerte
actividad al mismo tiempo deberían estar situados sobre servidores Hyper-V distintos, con
el objetivo de no cargar negativamente la infraestructura virtual. Debería, por tanto, definir
reglas de afinidad y anti-afinidad. Por último, las soluciones que necesiten tarjetas hardware
especiales (tarjetas digitales, acceso primario…) o las soluciones que utilizan dispositivos
físicos son difíciles de migrar a un entorno virtual. Los puertos COM del servidor físico no
están accesibles desde las máquinas virtuales, así como el lector de disquetes.

2. Nuevas problemáticas

Sería ilusorio pensar que la virtualización sólo aporta ventajas y ningún inconveniente.
Como cualquier solución técnica, lo importante es dominarla para sacarle partido. Existen
dos cuestiones que precisan una atención particular: los impactos de la consolidación y la
copia de seguridad.

a. Entorno consolidado

La consolidación es un eje clásico de rentabilización, aunque se vuelve mucho más sensible

con la virtualización, pues la lleva al extremo. Parte de la base de que la mayoría de
sistemas sólo consumen una parte de los recursos de hardware que están disponibles y los
consolidan para rentabilizarlos. Aun así raramente podemos predecir la carga que van a
generar los usuarios sobre el conjunto de sistemas virtuales en un momento dado. Puede
ocurrir que varias VM quieran consumir repentinamente lo máximo disponible,
perturbando así a las demás VM. El rendimiento puede convertirse rápidamente en un freno
a la virtualización si no está administrada correctamente.

Lo más típico es que los usuarios experimenten un mal rendimiento, que asocian
inmediatamente al hecho de que se trata de una máquina virtual. Se vuelven así reacios a su
uso, pensando que es la única causa de este mal rendimiento.

Este tipo de problema puede aparecer incluso de forma insidiosa con el tiempo. Esta
lentitud en el uso también aparece cuando, al contrario, el resultado es bueno y el éxito de
la solución incita a instalar todavía más máquinas virtuales de las que el dimensionamiento
de la infraestructura prevé.

Todo proyecto de virtualización debería tener un plan de capacidad, actualizado

permanentemente. Si el sistema que se quiere virtualizar ya está en uso, obtenga un registro
previo del uso de los recursos. Esto permitirá predecir su impacto en la infraestructura
Hyper-V así como los recursos necesarios. Hyper-V permite limitar el consumo de cada
máquina virtual, con el objetivo de garantizar una cantidad de recursos en cada instante. La
reserva de recursos tiene el inconveniente de bloquearlos, incluso si la máquina virtual no
se utiliza. El límite permite restringir una máquina virtual que no sea crítica, como una
máquina de pruebas, o una máquina que consuma todos los recursos disponibles, como un
servidor de procesamientos masivos.

También puede asignar un peso a cada máquina virtual, permitiendo así priorizar el acceso
a los recursos disponibles que no están reservados. Si por ejemplo dos máquinas virtuales
piden más recursos de procesador al mismo tiempo, la que tiene un peso mayor será
prioritaria. Puede asignar de 1 a 64 procesadores virtuales a cada máquina virtual
(dependiendo del sistema operativo hospedado), siempre que disponga de los núcleos
físicos correspondientes. En un servidor físico de cuatro núcleos, cada VM puede tener
como máximo cuatro procesadores lógicos. Los servidores actuales tienen por lo general al
menos dos o cuatro núcleos, lo cual resulta muy rentable en términos de virtualización. Si
asigna a cada VM dos procesadores lógicos, esto permite mantener un tiempo de respuesta
correcto en una VM, incluso si un procesador lógico está consumido por completo por un
programa o un proceso. Si sólo asigna un procesador lógico y un thread consume todos los
ciclos en bucle, le será complicado incluso acceder al sistema para parar este proceso. Este
fenómeno también es cierto sobre una máquina física con un único núcleo, pero la
virtualización acentúa este efecto que no está presente en la mente de los usuarios que
tienen por lo general dos núcleos en sus equipos (Hyper Threading o dual core).

La pérdida de un servidor físico Hyper-V tiene consecuencias mucho más graves que si se
trata de un servidor sin virtualización. En efecto, este tipo de servidores alberga
potencialmente varias VM (¿una decena, quizás?), y quedarán todas ellas indisponibles al
mismo tiempo. Es preciso prepararse para este escenario, para poder tomar las decisiones
correctas, como el orden en el que se va a volver a poner en servicio estas VM. Se
recomienda desplegar al menos dos servidores Hyper-V, con el objetivo de tener un plan de
recuperación rápido en caso de que ocurra un fallo grave en uno de los dos servidores.
b. Copia de seguridad

La copia de seguridad de una infraestructura virtual es una cuestión que merece una
atención particular. Existen varias implementaciones posibles, y debería encontrar la que le
aporte mayor flexibilidad, limitando las restricciones y los costes asociados. Su objetivo
debería ser poder responder a sus necesidades de una forma lo más adaptada posible al
contexto, respetando los compromisos de servicio con sus clientes.

Existen tres grandes ejes de copia de seguridad:

• Considerar las máquinas virtuales como si se tratara de servidores estándar,

instalando el agente de copia de seguridad tradicional en cada máquina virtual..
• Implementar una copia de seguridad utilizando las posibilidades ofrecidas por la
infraestructura virtual.
• Realizar una copia de seguridad de los discos virtuales de las VM en frío, es decir
con las VM paradas.

La primera solución tiene la ventaja de ser muy clásica, aunque también es seguramente la
más costosa, pues no aporta ningún ahorro ligado a la virtualización. Ciertos fabricantes de
software de copia de seguridad proporcionan no obstante un precio por agente inferior
cuando se trata de máquinas virtuales.

Nos ceñiremos a las soluciones de copia de seguridad que tengan en cuenta las
funcionalidades ofrecidas por la virtualización. Una máquina virtual puede tener varios
estados:

• Encendida o Apagada.
• En pausa.
• Con uno o varios puntos de control (antes llamados "instantáneas").

Los puntos de control (antes llamados "instantáneas") permiten tomar una "foto" de la VM
en un momento dado. Para ello, Hyper-V crea un nuevo disco virtual (*.avhd) que
contendrá todas las diferencias generadas tras este punto de control. Esto no constituye en
sí mismo un mecanismo de copia de seguridad. El archivo maestro es indispensable para su
funcionamiento, y no puede estar fuera de la VM. Esta funcionalidad no está disponible
para los discos físicos ligados directamente a la VM (pass-through). Para ciertos roles,
como el controlador de dominio, esta funcionalidad no está soportada por Microsoft. En
cambio, esta funcionalidad es un verdadero "must" para realizar el mantenimiento, pues
permite instalar una nueva aplicación o las actualizaciones del sistema y poder hacer la
marcha atrás si algo no funciona. Si todo funciona correctamente, sólo tendrá que eliminar
el punto de control, que se fusionará automáticamente con el archivo .VHD o .VHDX de su
máquina virtual. El número máximo de puntos de control es de 50 por máquina virtual.

Las copias de seguridad en frío son la solución más sencilla, aunque implican un periodo de
parada que no siempre es posible. Un reinicio del sistema operativo puede generar pérdidas
de rendimiento si se utiliza una caché en memoria (SQL Server...).
Es posible que su solución de copia de seguridad proporcione un agente para Hyper-V. Este
mecanismo utiliza la tecnología VSS (Volume Shadowcopy Service). De este modo
obtendrá copias autónomas de las máquinas virtuales, que podrá copiar y conservar en una
cinta magnética. La solución de copia de seguridad Microsoft SCDPM (System Center
Data Protection Manager) así como la solución de copia de seguridad nativa de Windows
Server 20012 R2 son compatibles con este tipo de copia de seguridad. Para que este tipo de
solución funcione, es necesario cumplir ciertos requisitos previos:

• Las herramientas Servicios de sistemas invitados virtuales deben estar instaladas,

y el servicio Backup integration debe estar activo.
• Todos los volúmenes utilizados por la VM deben estar en modo básico y con
formato NTFS.
• El servicio Windows VSS debe estar habilitado en todos los volúmenes y cada
volumen debe disponer de su propio almacenamiento VSS.

Si no puede realizarse una copia de seguridad en línea, entonces se realizará una copia de
seguridad en frío del equipo. Para ello, su estado será en copia y, una vez terminada la
copia de seguridad, la VM se situará en el estado inmediatamente anterior a la copia de
seguridad. Este tipo de copia de seguridad permite restaurar por completo una máquina
virtual, aunque no parte de la misma (como por ejemplo un archivo del disco C:\ en este
equipo). No es apropiado ejecutar una copia de seguridad o su restauración a la vez sobre
una máquina virtual y sobre la partición raíz. Puede generar conflictos si cada instancia
intenta bloquear el registro VSS.

He aquí un comando útil para realizar la copia de seguridad integral de un servidor Hyper-
V así como el conjunto de sus máquinas virtuales en caliente:

wbadmin start backup -backuptarget:\\

otroservidor\compartidos\copiasdeseguridad -include:c:,d:
-allcritical -vssfull -quiet

3. Preparar el despliegue
a. Requisitos previos

Para poder tener el rol Hyper-V, un servidor físico debe tener las funcionalidades de
virtualización (Intel-VT o AMD-V), funcionalidades de prevención de ejecución de datos
(DEP) y de seguridad (Intel XD o AMD NX), todas ellas habilitadas. Esto como
complemento a las instrucciones de 64 bits, imprescindibles en Windows Server 2012 R2 y
para Hyper-V en términos generales. Hyper-V soporta hasta 320 procesadores sobre el
servidor físico (y no 16 como era el caso con Windows Server 2008), que provengan de
núcleos físicos o lógicos gracias a la tecnología Hyper Threading.

Windows Server 2012 R2 también es capaz de sacar partido de las funcionalidades de

parada de núcleo (Core Parking) y de un segundo nivel de traducción, Extended Page
Tables (EPT) para Intel, Nested Page Tables (NPT) para AMD. El primero permite reducir
el consumo eléctrico parando los núcleos que no estén utilizándose. El segundo permite
ahorrar en torno al 2% del tiempo de procesador y 1 MB por máquina virtual.

Se recomienda realizar una instalación mínima (Core). El capítulo Reducir la superficie de

ataque de este libro cubre este tipo de instalación.

Windows Server 2012 R2, edición Estándar y Datacenter, así como Hyper-V Server 2012
R2 permiten utilizar como máximo 4 TB de memoria en el servidor host, es decir el
servidor físico (también llamada partición raíz) y hasta 1 TB de memoria en cada máquina
virtual.

El tamaño máximo para un disco duro virtual depende de su tipo, y será de 2040 GB para
un disco .VHD (antes esta limitación era de 127 GB para Windows Server 2012) y de 64
TB para un disco .VHDX, formato de disco duro virtual aparecido con Windows Server
2012.

Se recomienda disponer de al menos dos tarjetas de red físicas en el host físico (véase más
adelante la sección Respetar las buenas prácticas). Cada máquina virtual de primera
generación puede tener hasta 12 tarjetas de red virtuales (8 reales (tarjetas de red virtuales
que requieren la instalación de servicios de integración) + 4 emuladas), hasta 8 tarjetas de
red virtuales para máquinas de segunda generación (pues las tarjetas de red heredadas no
están soportadas), cada una con una dirección MAC estática o dinámica. Para las máquinas
de primera generación, las tarjetas de red reales están disponibles una vez instalados los
servicios de invitado virtual y los controladores adecuados. Esto significa que no pueden
hacer boot en la red. Las tarjetas de red emuladas tienen peores rendimientos, 100 Mb/s
frente a 10 Gb/s para las tarjetas reales. Utilizan un controlador estándar que no necesita
controladores Hyper-V, aunque permiten el boot PXE. Esto acentúa la importancia de
instalar únicamente sistemas operativos soportados por Hyper-V para tener una red virtual
con un buen rendimiento.

La tecnología VLAN está soportada por las tarjetas de red virtuales.

Un lector de DVD virtual puede utilizar imágenes ISO o el lector físico del servidor en el
caso de una máquina virtual de primera generación. Sin embargo, sólo una máquina virtual
puede acceder al lector físico al mismo tiempo. Se recomienda convertir los CD y DVD
necesarios en imágenes ISO. Además, el uso de imágenes ISO mejora el rendimiento de
uso; en efecto, las imágenes ISO, que se almacenan en el disco duro, aprovechan una tasa
de transferencia de lectura superior. Una máquina virtual de segunda generación utiliza,
exclusivamente, imágenes ISO.

b. Metodología de trabajo

La metodología es un aspecto fundamental en un proyecto de virtualización. Ciertas

cuestiones, tales como la copia de seguridad, deben tratarse cuidadosamente antes del paso
a producción. Es posible aplicar las fases clásicas de un proyecto de infraestructura con
algunas especificidades:
 • Determinar el alcance (entornos, sistemas operativos...).
• Comenzar la búsqueda de los mejores candidatos para la virtualización
implementando herramientas de medida (véase la sección siguiente).
• Determinar el nivel de servicio que se desea proporcionar en el perímetro (SLA).
• Montar una maqueta/POC (Proof Of Concept).
• Utilizar la infraestructura de almacenamiento presente (interna, SAN, iSCSI,
compartición de archivos...).
• Medir la integración en la arquitectura de red existente (VLAN, filtrado por
dirección MAC, protección en los conmutadores).
• Implementar, al menos, un ejemplo de cada tipo de VM en el alcance (una VM de
cada OS y cada aplicación).
• Asegurar la capacidad para realizar la copia de seguridad y restaurar cada una de las
VM.
• Generar la misma carga que en producción con las mismas restricciones
(procesamientos, ventanas de copia de seguridad...).
• Implementar una solución de supervisión teniendo en cuenta la virtualización
(medir el uso de los procesadores disponibles en Hyper-V así como el consumo por
VM...).
• Evaluar el interés de SCVMM en su contexto de trabajo.
• Medir el impacto en la gestión de las actualizaciones de Windows (uso de Offline
Virtual Machine Servicing Tool como se explica en la sección Configurar el
almacenamiento).
• Medir el impacto en los procedimientos de explotación (procedimientos de
parada/arranque...).
• Evaluar el impacto en el coste.
• Implementar un piloto, que supondrá la puesta en producción de una muestra del
perímetro, para verificar las hipótesis.
• Extender el piloto al conjunto de manera progresiva.

La prueba de concepto es decisiva, pues permite evaluar las nuevas funcionalidades, en

ocasiones importantes, de esta versión y verificar que la arquitectura actual soportará la
carga. Menospreciar esta fase conlleva el riesgo de fracasar una vez en producción. La
duración de esta fase debería permitir evaluar los impactos de la virtualización, así como
las optimizaciones que es necesario realizar, bien en Hyper-V, en las máquinas virtuales o
en los demás bloques del sistema de información. Con la prueba de concepto, todos los
participantes podrán tener una visión clara de las ventajas y los inconvenientes de la
virtualización para poder hacer una evaluación completa. El piloto debe confirmar sin
reservas esta evaluación antes de generalizar el despliegue.
c. Determinar los servidores y las aplicaciones adecuados para la virtualización

Microsoft proporciona de forma gratuita una herramienta que le permite preparar y acelerar
su proyecto de virtualización: Microsoft Assessment and Planning Toolkit. Está disponible
para su descarga en la siguiente dirección: http://www.microsoft.com/en-
us/download/details.aspx?id=7826

De este modo podrá, fácilmente:

• Realizar un inventario de los servidores.

• Recoger datos sobre el consumo de recursos sobre estos servidores.
• Generar informes Office con recomendaciones basadas en los datos recogidos.

Debe instalarse preferentemente en un puesto de trabajo, pues necesita Microsoft Office

(2003 o 2007), y una instancia de SQL Server o SQL Express (2008, 2008 R2 o 2012). La
instalación de esta última puede evitarse si ya está presente, creando preferentemente una
instancia llamada "MAPS".
Una vez instalada la aplicación, deberá:

• Crear una base de datos para el proyecto haciendo clic en Select a database.
• Crear manualmente un archivo de texto que contenga la lista de los servidores que
quiera examinar para su proyecto de virtualización (candidatos potenciales). Por
ejemplo, el siguiente script PowerShell exporta el nombre DNS de todos los
servidores de Active Directory en el archivo miextraccion.txt:

$buscar = New-Object
DirectoryServices.DirectorySearcher("[ADSI]")
$buscar.SizeLimit = 10000
$buscar.PropertiesToLoad.Add("dNSHostName")
$buscar.Filter =
"(&(objectClass=Computer)(operatingSystem=*Serve*r*))"
$buscar.FindAll() | foreach-object
{$objet=$_.GetDirectoryEntry();$objet.dNSHostName;} >>
miextraccion.txt

En el panel de navegación, haga clic en Server Virtualization y, a continuación, haga clic

en Collect performance data.

Indique el archivo de texto creado anteriormente.

Especifique una o varias cuentas con permisos de administrador local sobre los servidores
de destino.

Indique una fecha de fin para la recogida de datos. La estación que realiza la recogida de
datos debe permanecer encendida todo el tiempo de la colecta.
A continuación, puede generar los informes.

d. Respetar las buenas prácticas

He aquí algunas reglas consideradas como buenas prácticas que deberían respetarse por
defecto, salvo en casos muy concretos.

De forma general, en Hyper-V:

• Prevea al menos dos tarjetas de red físicas sobre el servidor, aunque lo

conveniente es:

• una para la administración del hipervisor,

• una o varias dedicadas a las máquinas virtuales,
• una o varias para el iSCSI, si lo implementa,
• una para las migraciones rápidas (live migration), si las implementa.

• Conecte la tarjeta de red dedicada a la gestión del hipervisor a su red de

administración.
• Exponga únicamente las máquinas virtuales a la red Internet.
• Incluya una excepción en el antivirus para los archivos *.vhdx, *.avhdx, *.vhd y
*.avhd.
• El lector de DVD no puede estar compartido por varias máquinas virtuales. Dé
prioridad a las imágenes ISO en su lugar.

De manera general, sobre las máquinas virtuales:

• Instale, siempre que sea posible, las herramientas de administración Servicios de

sistemas invitados virtuales.
• Deshabilite el salvapantallas.
• Defragmente siempre el disco físico antes de crear un disco duro virtual.
• Si migra las máquinas virtuales utilizando otras soluciones de virtualización, como
Virtual PC, Virtual Server, VMware, desinstale las VMadditions o las VMware
Tools. Elimine los puntos de control y comprima el disco duro virtual antes de
desplazarlo al Hyper-V.
• Asegúrese de que la visualización está optimizada para un buen rendimiento, y así
aprovechar la aceleración de hardware.
• Utilice, preferentemente, el nuevo formato de disco virtual de tipo *.vhdx de
tamaño dinámico. El rendimiento es superior al de los discos *.vhd de tamaño fijo.
• Si utiliza discos dinámicos *.vhd, conviértalos en discos virtuales de tamaño fijo, el
sistema estará menos fragmentado, la gestión del espacio será mucho más sencilla y
el rendimiento mejor respecto a los discos de tamaño dinámico.
• Cree discos virtuales de tamaño fijo. El rendimiento es superior, el sistema de
archivos estará menos fragmentado, y la administración del espacio será más
sencilla.
 • Si crea una VM Windows Server 2003, asígnele dos procesadores virtuales para
tener un HAL multiprocesador.
• Utilice, en la medida de lo posible, controladores reales una vez instalados los
servicios de sistemas invitados virtuales, para mejorar el rendimiento.

Puede instalar un controlador de dominio Active Directory en el interior de una máquina

virtual Hyper-V. No obstante, se recomienda observar las siguientes reglas:

• Las buenas prácticas de Active Directory indican que es necesario disponer, como
mínimo, de dos controladores de dominio. Ambos controladores deberían residir en
hosts distintos.
• Seleccione cómo sincronizar el tiempo. Es crucial que el conjunto del dominio
utilice la misma hora. Por defecto, Kerberos no soporta un desfase superior a los 5
minutos. Puede o bien sincronizarlos en base al reloj del hardware del servidor a
través de los servicios de sistemas invitados virtuales, o bien sincronizarlos a través
de la red del dominio.
• Si su único controlador de dominio es una máquina virtual en Hyper-V, la partición
raíz (hipervisor) no debe unirse a este dominio. Cuando reinicie el servidor, la
partición raíz buscará un controlador de dominio que no podrá encontrar pues la
máquina no estará todavía levantada.

Windows Server 2012 R2 conserva la funcionalidad que permite clonar controladores de

dominio virtualizados, introducida con Hyper-V 3 para Windows Server 2012. Esta
funcionalidad se explica con detalle en el capítulo Dominio Active Directory.

Puede implementar SQL Server en una máquina virtual. El almacenamiento es un elemento

crítico en una base de datos, y la virtualización no cambia nada. El almacenamiento sobre
el que residirán los datos y los registros debe proporcionar un rendimiento adecuado. Para
no disminuir este rendimiento con la virtualización, debería utilizar únicamente discos
virtuales de tamaño fijo, utilizando un controlador SCSI virtual. La otra alternativa es
utilizar volúmenes directamente en modo pass-through.

Puede implementar Exchange Server 2010 o Exchange Server 2013 en una máquina virtual.
En este caso, debe observar las siguientes recomendaciones:

• Para que la configuración esté soportada por Microsoft, instale el Service Pack 1
para Exchange 2010, Exchange 2013 RTM o superior.
• El uso de discos virtuales de tamaño dinámico está soportado únicamente con
VHDX, aunque se recomienda utilizar discos virtuales de tamaño fijo.
• El uso de funciones de puntos de control y diferenciales sobre los discos virtuales
no está soportado.

En lo relativo a la seguridad, jamás debería proporcionar permisos sobre la partición raíz a

los administradores de las máquinas virtuales. Para respetar el célebre principio de otorgar
siempre el menor nivel de privilegios posible, debería darles acceso a lo estrictamente
necesario. Administrar esta seguridad puede convertirse en una tarea compleja, para la que
también puede utilizar la noción de roles para clasificar los accesos.
Desplegar Hyper-V
1. Instalación
a. Instalación del rol Hyper-V

La instalación es tan sencilla como agregar el rol en el servidor mediante el Administrador

del servidor, a partir de su interfaz gráfica. Si está trabajando con una instalación Core,
ejecute el siguiente comando PowerShell:

Install-WindowsFeature Hyper-V

Será necesario reiniciar para que se apliquen los cambios y poder utilizar este rol.

b. Configuración del rol

La configuración del rol cubre diferentes aspectos:

• creación y configuración de las redes virtuales;

• preparación de las imágenes ISO para las distintas instalaciones.

La consola permite administrar los servidores Hyper-V así como las máquinas virtuales que
las albergan. Abra la consola Administrador de Hyper-V disponible en la pantalla de
inicio de Windows, Herramientas administrativas y, a continuación, Administrador de
Hyper-V.
c. Configuración de las redes virtuales

En Hyper-V, la administración de las redes se realiza mediante el Administrador de Hyper-

V o mediante PowerShell. Existen tres tipos de redes, también llamadas switchs virtuales:

• El switch virtual externo: vinculado con una tarjeta de red real sobre el host, este
tipo de switch virtual permite a las VM conectadas a él acceder a la red externa y,
por lo tanto, dialogar con el exterior. Es posible crear y asociar una tarjeta de red
virtual con un host vinculado a este tipo de switch virtual.
• El switch virtual interno: este tipo de switch virtual permite realizar una
comunicación entre las VM vinculadas a este switch, así como al host que posee,
automáticamente, una tarjeta de red virtual sobre este mismo switch.
• El switch virtual privado: las VM conectadas a este switch sólo pueden
comunicarse entre ellas.

Windows Server 2012 R2 soporta las tecnologías de red siguientes:

• La tecnología PVLAN (Private Virtual Local Area Network), que permite aislar las
máquinas virtuales sobre una misma red local privada virtual aunque se hospeden en
hosts diferentes. Resulta muy práctica para servidores hospedados en Datacenters.
 • La tecnología SR-IOV, que permite a la tarjeta de red enviar directamente los
paquetes de red en el espacio de memoria de la VM, sin pasar por la partición raíz.
Es necesario que la tarjeta de red del servidor físico gestione esta funcionalidad y es
posible que haga falta instalar controladores suplementarios en la máquina virtual.
Observe que el soporte de SR-IOV para el switch virtual se define durante la
creación de dicho switch virtual, no será posible modificar este parámetro tras una
ruptura (salvo creando otro switch virtual).
• El NIC Teaming, o agregación de varias tarjetas de red, que se gestiona de forma
nativa en los sistemas operativos. Un switch virtual puede vincularse a un equipo
para aumentar las tasa de transferencia y la tolerancia a fallos.
• Los switchs virtuales extensibles (Extensible vSwitch), que permiten agregar
extensiones al switch virtual. Algunos fabricantes de switch ya han anunciado
extensiones que permitirán soportar su tecnología en los switchs virtuales.
• Las tarjetas de red inalámbricas están soportadas, y es posible vincularlas con un
switch virtual externo. Resultan muy útiles en la versión de Hyper-V para Windows
8/8.1.
• La tecnología Jumbo Frames para las máquinas virtuales. Esta tecnología permite
aumentar la MTU (Maximum Transmission Unit) de 1500 (Ethernet) a 9014. La
misma cantidad de datos puede, de este modo, transmitirse con seis veces menos
intercambios de paquetes. Esto implica que todos los equipos de red soporten las
Jumbo Frames.
• La tecnología VMQ (Virtual Machine Queue), que permite a la tarjeta de red alojar,
en su propia memoria interna, un espacio dedicado a cada VM. Los datos se envían,
a continuación, directamente sobre el puerto conectado al VMBus del switch virtual
que permiten alcanzar la VM. Una especie de pre-enrutamiento interno en la tarjeta
de red. Esto evita, también, tener que verificar el enrutamiento en los switch
virtuales mediante los VMQ Queue ID. El objetivo es una mejora en el rendimiento
reduciendo el número de operaciones en las comunicaciones de red. Es necesario,
no obstante, que la tarjeta de red del host gestione esta funcionalidad.
• El TCP Offload permite descargar la gestión del tráfico TCP/IP de las máquinas
virtuales sobre una tarjeta física del servidor. Esta descarga aumenta el rendimiento
y reduce el consumo de procesador del servidor físico. La migración en caliente de
VM puede aprovechar esta funcionalidad.

d. Configuración del almacenamiento

Con la virtualización, el almacenamiento es el centro de la cuestión. Esto es todavía más

cierto si los servicios ofrecidos por las máquinas virtuales consumen muchos recursos de
entrada/salida de disco. Para poder reducir costes, es interesante utilizar almacenamiento
"low cost", aunque existe el riesgo de sufrir un mal rendimiento en las máquinas virtuales.
Será preciso encontrar el justo equilibrio entre una solución SAN y una carpeta compartida
de red.

Hyper-V soporta una gran variedad de soluciones para el almacenamiento de las máquinas
virtuales:
 • Almacenamiento local del servidor (IDE/SATA/ESATA/USB/Firewire/SAS/SCSI).
• Almacenamiento en una SAN (con almacenamiento en clúster en modo Cluster
Shared Volumes).
• Almacenamiento mediante iSCSI o FCoE.
• Almacenamiento sobre una carpeta compartida de archivos.
• Almacenamiento en modo pass-through.

Puede incluso almacenar las VM en una llave USB, a condición de que tenga formato en
NTFS. Por defecto, debería utilizar discos virtuales. Existen no obstante ciertos casos
donde debería utilizar un almacenamiento en modo pass-through. Este método proporciona
a la VM acceso directo a una zona de almacenamiento, como si fuera una máquina física.
Una de las ventajas es que se obtiene un mejor rendimiento, ligado a la ausencia de la capa
de virtualización. He aquí algunas consideraciones a propósito del modo pass-through:

• Los volúmenes en modo pass-through no se incluyen en la copia de seguridad por

los mecanismos de Hyper-V. Necesitará realizar estas copias de seguridad
utilizando algún otro medio.
• El mecanismo de puntos de control no está disponible en este tipo de volumen

Si elige almacenar las VM en una carpeta compartida de archivos o un almacenamiento

compartido con formato SMB 3.0, se recomienda configurar este recurso compartido con
alta disponibilidad.

El almacenamiento mediante ISCSI puede realizarse de dos maneras, desde la partición

raíz, o desde la máquina virtual. Esta elección tiene varias consecuencias:

• Si al almacenamiento ISCSI se accede desde la partición raíz, el rendimiento es

mejor que desde la VM, y la copia de seguridad a través del registro VSS está
soportado.
• Las máquinas virtuales no pueden iniciarse desde un almacenamiento ISCSI
(administrado desde las VM en lugar de la partición raíz). El almacenamiento ISCSI
que se accede desde las VM no puede incluirse en las copias de seguridad a través
de VSS Hyper-V.

Otra decisión que hay que tomar atañe a la naturaleza de los controladores virtuales para las
máquinas virtuales. Pueden ser IDE o SCSI. El rendimiento no juega, de momento, un
papel importante cuando se instalan los servicios de sistemas invitados virtuales. Las
diferencias se centran en la volumetría, el número de discos virtuales asociados a la VM y
las funcionalidades propuestas (como el Shared VHDX).

El controlador SCSI permite tener hasta 256 dispositivos de almacenamiento (4

controladores * 64 dispositivos). No obstante, permite arrancar únicamente en una máquina
virtual de segunda generación. Los volúmenes ligados al controlador IDE pueden ser 4
como máximo (contando el lector CD/DVD virtual), tienen un tamaño máximo de 2040
gigabytes, aunque están disponibles únicamente en una máquina virtual de primera
generación.
El almacenamiento sobre una infraestructura SAN es generalmente la solución competente,
y también la más costosa. La tecnología NPIV está disponible en las tarjetas HBA, lo que
permite respetar las buenas prácticas en lo que respecta al almacenamiento SAN (zoning...).
Para ello debería activar las WWN (World Wide Names) virtuales para las máquinas
virtuales. He aquí algunas consideraciones para el almacenamiento sobre una SAN:

• Es necesario tener un controlador MPIO (multipuerto), incluso con una única HBA.
• Deshabilite el montaje automático de volúmenes.
• Deje los discos en modo básico y no dinámico.
• Todos los archivos de VM deben estar en un único volumen.
• Agregue las LUN como recursos de disco al clúster antes de crear las VM.
Windows Server 2012 R2 incluye los Cluster Shared Volumes, que permiten tener
varias VM por LUN, teniendo estas VM en hosts diferentes.

Si las VM están almacenadas en modo pass-through sobre la SAN, se necesitan dos LUN,
una para el disco de inicio y otra para la configuración.

2. Máquinas virtuales de nueva generación

Windows Server 2012 R2 incluye un nuevo formato de máquina virtual, hablamos de

máquina virtual de generación 2. Las máquinas virtuales de primera generación siguen
estando soportadas, y ambas generaciones de máquina virtual pueden convivir en el mismo
servidor host. La generación de la máquina virtual determina el tipo de componentes de
hardware y algunas funcionalidades de la máquina virtual.

Las máquinas virtuales de generación 2 incluyen un modelo de hardware simplificado, pues

cierto número de componentes se han suprimido, como los controladores IDE y los
periféricos emulados (disquetera, tarjeta de red heredada). Además, esta nueva
generación de máquinas virtuales soporta, también, UEFI (Unified Extensible Firmware
Interface) en comparación con el anterior tipo de BIOS.

En el momento de escribir estas líneas, sólo Windows Server 2012 / 2012 R2 así como las
versiones de 64 bits de Windows 8/8.1 están soportadas como sistema operativo invitado.

He aquí una tabla con las diferencias de hardware entre ambas generaciones de máquina
virtual.

Generación 1 Generación 2
BIOS
Tipo Hyper-V BIOS-Based Hyper-V UEFI
Arranque sobre IDE CD, IDE HD, tarjeta de Tarjeta de red, SCSI HD,
red heredada y disquetera SCSI CD
Memoria RAM
Máximo 1 TB 1 TB
 Memoria dinámica Windows Server 2012/ 2012 Windows Server 2012/
R2, Windows 8/8.1, y algunas 2012 R2, Windows 8/8.1
distribuciones de Linux
Procesador
Número máximo 64 64
Controlador IDE Sí No
Bootable Sí
Número máximo de 2
controladores IDE
Número máximo de 2
periféricos por
controlador
Tipo de disco VHD, VHDX, Pass-Through
soportado
Número máximo de 4 (si no tiene CD)
discos
Tamaño máximo por 2040 GB
disco
Tipo de CD ISO, Lector host
Número máximo de 4 (aunque 3, pues hace falta 1
CD HD para poder arrancar…)
Controlador SCSI Sí Sí
Bootable No Sí
Número máximo de 4 4
controladores SCSI
Número máximo de 64 64
dispositivos por
controlador
Tipo de disco VHD, VHDX, Pass-Through VHDX, Pass-Through
soportado
Número máximo de 256 256 (si no tiene CD)
discos
Tamaño máximo por 2040 GB en VHD o 64 TB en 64 TB
disco VHDX
Tipo de CD No soportado ISO
Número máximo de 256 (aunque 255, pues
CD hace falta 1 HD para
poder arrancar…)
Tarjeta de red sintética Sí Sí
 Número máximo 8 8
Bootable No Sí
Tarjeta de red heredada Sí No
Número máximo 4 0
Bootable Sí
Adaptador Fibre
Channel
Número máximo 4 4
Tarjeta de vídeo 3D
RemoteFX
Número máximo 1 0
Puerto Com
Número máximo 2 0 (1 mediante cmdlets
PowerShell)
Disquetera Sí No
Número máximo 1 0

Observe que Remote FX no está soportado en las máquinas virtuales de generación 2,

mientras que sí lo está con las de generación 1.

Puede vincular discos virtuales VHDX de generación 1 a una máquina virtual de

generación 2, y a la inversa. Si el disco virtual de generación 1 es un VHD, tendrá que
convertirlo al formato VHDX; en efecto, las máquinas virtuales de generación 2
soportan únicamente discos con formato VHDX. Es posible realizar esta acción mediante la
consola de Hyper-V, con el asistente Editar disco… que se encuentra en el panel de
Acciones, o mediante el cmdlet PowerShell Convert-VHD. Observe que el cmdlet
PowerShell Convert-VHD permite convertir un VHD en VHDX, y a la inversa.

No es posible convertir el disco virtual bootable de una máquina virtual de generación 1 a

uno de generación 2, es obligatorio partir de una nueva instalación. Igual que un disco
bootable con formato VHDX instalado desde una generación 2 no permitirá arrancar una
máquina virtual de generación 1.

En una infraestructura virtual de alta disponibilidad (clúster de servidores Hyper-V, Live

Migration…), las máquinas virtuales de generación 2 están soportadas únicamente en
Windows Server 2012 R2 y Microsoft Hyper-V 2012 R2, y no podrán migrarse a hosts
Windows Server 2012 R2 o Microsoft Hyper-V 2012 R2.

Puede conocer la generación de una máquina virtual de varias maneras. La primera consiste
en utilizar, sencillamente, el Administrador de Hyper-V y consultar el valor del campo
Generación presente en el panel de información de una máquina virtual.
Una segunda forma de verificar la generación de una máquina virtual consiste en editar sus
propiedades. En efecto, si observa la presencia de controladores IDE, se trata de una
máquina virtual de generación 1. La ausencia de controladores IDE pone de manifiesto una
máquina virtual de generación 2 .Otra forma de conocer la generación de una máquina
virtual consiste en utilizar el cmdlet de PowerShell Get-VM con una visualización de tipo
lista:

Get-VM -Name VM-Gen2 | fl

3. Creación y configuración de una máquina virtual

La creación de una máquina virtual se realiza mediante el Administrador de Hyper-V, en

el panel acción, mediante el menú Nueva y seleccionando Máquina virtual.... Le bastará
con seguir el asistente Nueva máquina virtual que le solicitará la generación de la
máquina virtual que desea crear, así como alguna información básica (el nombre, la
cantidad de memoria, la conexión de red de la primera tarjeta de red y el disco duro
virtual).

También puede utilizar PowerShell:

New-VM -Name MaquinaVirtual01

Este comando creará, simplemente, una máquina virtual de primera generación con el
mínimo imprescindible: 1 procesador y 512 MB de memoria RAM, sin ningún disco duro y
con una tarjeta de red real no conectada.

New-VM -Name MaquinaVirtual02 -Generation 2

Este comando creará una máquina virtual de generación 2 con el mínimo vital, 1
procesador, 512 MB de memoria, aunque sin disco y una tarjeta de red sintética no
conectada.

Observe que no podrá cambiar la generación de la máquina virtual una vez creada.
Para acceder a la configuración de la máquina virtual, en el Administrador de Hyper-V,
basta con hacer clic con el botón derecho sobre la máquina virtual y seleccionar
Configuración en el menú contextual.

En esta ventana, puede administrar la configuración del hardware de la máquina virtual, y

también las interacciones de los servicios de integración con la máquina virtual, así como
las acciones que quiere llevar a cabo si debe detener el host. Todos estos parámetros están
accesibles, también, mediante PowerShell, aunque la lista de comandos es muy extensa.

a. Dynamic Memory

Incluida con Windows Server 2008 R2 SP1, la administración de la memoria dinámica

(Dynamic Memory) sigue estando presente. Esta tecnología permite, al servidor Hyper-V,
alojar dinámicamente la memoria RAM de las máquinas virtuales según las necesidades de
éstas en función de los parámetros que defina.
Con Hyper-V para Windows Server 2012 R2 y Microsoft Hyper-V Server 2012 R2, es
posible definir la cantidad de memoria de arranque, además de la memoria mínima y
máxima. Esta memoria de arranque se utilizará en la máquina virtual durante sus
arranques, reinicios, o vuelta a la actividad tras una suspensión.

Si una máquina virtual ejecuta un procesamiento específico que utiliza más memoria de la
que se le había asignado en un principio, Hyper-V podrá aumentar, momentáneamente, la
cantidad de memoria RAM asignada a esta máquina virtual bien directamente a partir de la
memoria libre del servidor Hyper-V o bien a partir de la memoria inutilizada en las demás
máquinas virtuales presentes en el mismo servidor.

Una vez finalice el proceso intensivo en memoria, ésta se libera si alguna otra máquina
virtual la solicita o tiene necesidad de ella.
La memoria se considera, de este modo, como un recurso compartido entre las máquinas
virtuales. Su asignación ya no requiere una parada de la máquina virtual para que se tenga
en cuenta la nueva capacidad de memoria.

Los sistemas operativos de Microsoft que soportan la memoria dinámica son:

• Windows Server 2012/2012 R2.

• Windows Server 2008 SP2 (32 y 64 bits) / 2008 R2 SP1.
• Windows Server 2003 SP2 (32 y 64 bits) / 2003 R2 SP2 (32 y 64 bits).
• Windows 8/8.1 (32 y 64 bits).
• Windows 7 SP1 (32 y 64 bits).
• Windows Vista SP2 (32 y 64 bits).
• Distribuciones de Linux recientes, con los últimos servicios de integración.

b. Resource Metering

Windows Server 2012 incluye la posibilidad de recuperar distintas estadísticas de cada

máquina virtual iniciada sobre un host con el rol Hyper-V instalado. Estas estadísticas
podrán utilizarse para gestionar una solución de alta disponibilidad mediante SCOM 2012 o
SCVMM 2012, o simplemente para realizar una refacturación de servicios en el caso de un
proveedor de infraestructura.

Las estadísticas que pueden recuperarse son:

• Media de uso del procesador: en mega hertzios, durante un periodo de tiempo

determinado.
• Media de uso de la memoria física: en megabytes.
• Picos mínimo / máximo de memoria física utilizada: en megabytes.
• Espacio de disco asignado a la máquina virtual.
• Tráfico total de red entrante: en megabytes.
• Tráfico total de red saliente: en megabytes.

La configuración y la recuperación de las estadísticas se realizan mediante PowerShell. He

aquí algunos ejemplos de cmdlets PowerShell útiles:

• Para habilitar el Resource Metering en una máquina virtual:

Enable-VMResourceMetering -VMName NombreDeLaMaquinaVirtual

• Para habilitar el Resource Metering en todas las máquinas virtuales de un host:

Get-VM -ComputerName NombreDelServidorHost | Enable-VMResourceMetering

• Para configurar la frecuencia de muestreo, los valores admisibles están

comprendidos entre 1 hora y 24 horas. El valor por defecto es de 1 hora. Por
ejemplo, para una muestra cada 2 horas:
Set-VMHost -ComputerName NombreDelServidorHost
-ResourceMeteringSaveInterval 02:00:00

• Para ver las estadísticas de una máquina virtual en particular:

Measure-VM -Name NombreDeLaMaquinaVirtual

# O para obtener información más detallada

Measure-VM -Name NombreDeLaMaquinaVirtual | fl

• Para ver las estadísticas de todas las máquinas virtuales:

Get-VM -ComputerName NombreDelServidorHost | Measure-VM

• Para reiniciar las estadísticas de una máquina en concreto:

Reset-VMResourceMetering -VMName NombreDeLaMaquinaVirtual

 • Para deshabilitar Resource Metering en una máquina virtual:

Disable-VMResourceMetering -VMName NombreDeLaMaquinaVirtual

c. Redimensionamiento del disco duro virtual en caliente

Windows Server 2012 R2 le permite, ahora, redimensionar sus discos duros virtuales en
caliente, lo que permite evitar tener que reiniciar la máquina virtual para realizar este tipo
de mantenimiento en el servidor.

El único requisito previo es que sus discos duros virtuales tengan el formato VHDX, que
estén conectados a un controlador SCSI, y que el sistema operativo alojado lo soporte.

Le bastará con utilizar el Asistente para editar discos duros virtuales, mediante el
Administrador de Hyper-V, para extender el disco duro virtual. Es, también, posible
realizar esta acción mediante el cmdlet PowerShell Resize-VHD.

Para terminar, bastará con utilizar el espacio que acaba de configurar, mediante el
Administrador de discos en su máquina virtual, siempre que la manipulación haya
consistido en extender el disco y no en reducirlo.

Puede llegar a ocurrir, en algunos sistemas operativos, que no se analicen bien los discos
disponibles y se muestren las modificaciones, como ocurre con algunas distribuciones de
Linux, por ejemplo.

d. Gestión de la QoS en el almacenamiento de una máquina virtual

Windows Server 2012 R2 incluye la posibilidad de gestionar la calidad de servicio acerca

del uso de discos duros virtuales (Storage QoS). Esta funcionalidad permite limitar, o
contener, las entradas y salidas por segundo (E/S) en los discos duros de las máquinas
virtuales.

Por ejemplo, en el caso de una mutualización de los recursos, como con un servidor host,
puede resultar práctico limitar los recursos de uso de disco. Otro ejemplo, si tiene una
aplicación que requiere una gran tasa de lectura/escritura en disco (como una base de datos
SQL), puede querer asignar un mínimo de E/S sobre el disco donde se almacenan los datos.
De este modo, la aplicación tendrá, en cualquier caso, una tasa de acceso a disco
garantizada.

Para configurar la calidad de servicio para un disco virtual, acceda a las Propieades de la
máquina virtual y, a continuación, en el disco duro afectado, haga clic en el sigo "+" y en
Características avanzadas.

Marque la opción Habilitar la administración de calidad de servicio, e indique el valor

deseado, que debe estar comprendido entre 0 y 1000000000 (mil millones). Sólo queda
aplicar las modificaciones.
También puede modificar estos parámetros mediante PowerShell:

# Para configurar el Storage QoS en el disco IDE 0 del controlador

# IDE 0 de una máquina virtual.
Set-VMHardDiskDrive -VMName VM-Gen1 -ControllerType IDE
-ControllerNumber 0 -ControllerLocation 0 -MinimumIOPS 8
-MaximumIOPS 1000

Observe que no es posible utilizar la calidad de servicio sobre el almacenamiento con

discos virtuales compartidos.

e. Activación automática de máquinas virtuales

Windows Server 2012 R2 edición Datacenter incluye una funcionalidad de activación

automática de máquina virtual (AVMA, Automatic Virtual Machine Activation), que
resulta muy útil en una infraestructura virtual, con la condición de que esté compuesta por
varios servidors host Hyper-V, instalados con esta edición. En efecto, no debe olvidar que
la edición Windows Server 2012 R2 Datacenter le permite ejecutar un número ilimitado de
máquinas virtuales Windows, que están cubiertas con la licencia de esta edición Datacenter.
La única limitación verdadera es la que imponga el hardware, en términos de rendimiento.

Hasta Windows Server 2012, en este tipo de casos, tenía que activar sus máquinas virtuales
mediante la clave de licencia del host "Datacenter", dentro de sus máquinas virtuales, para
activarlas. ¿Qué ocurría con Live Migration? ¿Cómo era posible gestionar varias máquinas
virtuales alojadas en otro host? Además, la activación del sistema operativo invitado tenía
que realizarse bien manualmente (por Internet o por teléfono), o bien gracias a un servidor
KMS, o incluso, desde Windows Server 2012, mediante la funcionalidad de activación
basada en Active Directory (ADBA, Active Directory-Based Activation).

Con Windows Server 2012 R2 Datacenter, si el servidor host está activado, las máquinas
virtuales que contiene se activarán automáticamente gracias al hipervisor, mediante el
VMBus, incluso aunque no formen parte del dominio o no tengan ninguna conexión a
Internet.

Para implementar esta funcionalidad, basta con que el host sea un servidor Windows Server
2012 R2 "activado" (mediante una clave KMS o ADBA, Open Licence u OEM), y que el
sistema operativo de la máquina virtual sea Windows Server 2012 R2 (Datacenter,
Standard o incluso Essentials) con una clave AVMA. Las claves AVMA son públicas y
están disponibles en la dirección: http://technet.microsoft.com/en-us/library/dn303421.aspx

Una vez posea la clave correspondiente a su edición, conviene inscribirla en la máquina

virtual. Para ello, en la máquina virtual, abra una línea de comandos (con elevación de
privilegios de Administrador) e introduzca el siguiente comando:

slmgr /ipk <Clave_AVMA_DeSuEdicion>

slmgr /ato

La máquina virtual se activará automáticamente por una duración de 7 días, tras los que la
máquina virtual validará automáticamente su activación por otros 7 días. Ocurrirá de este
modo mientras la máquina virtual resida sobre un host Windows Server 2012 R2
DataCenter.

Observe que es posible utilizar una clave AVMA en un archivo de respuesta de instalación
de Windows o en las plantillas de máquinas virtuales con SCVMM o SCCM.

f. Exportación de máquinas virtuales en caliente

Windows Server 2012 R2 incluye la posibilidad de exportar una máquina virtual, o uno de
sus puntos de control, en caliente sin tener que detener la máquina virtual. Esto permite
duplicar la máquina virtual para realizar pruebas, sin tener que detener el servidor de
producción, o incluso probar la migración de máquinas virtuales entre la Cloud privada y la
Cloud interna, siempre sin detener los servidores de máquinas virtuales de producción.
Además, cualquier exportación de una máquina virtual que esté en funcionamiento
exportará su estado de memoria.

Puede realizar una exportación de la máquina virtual mediante la consola de

Administración de Hyper-V o mediante PowerShell con el siguiente comando:

# Para exportar una máquina virtual llamada VM-Gen1 a la carpeta

# D:\ExportVM.
Export-VM -Name VM-Gen1 -Path D:\ExportVM

# Para exportar todas las máquinas virtuales a la carpeta

# D:\ExportVM.
Get-VM | Export-VM -Path D:\ExportVM

# Para exportar un punto de control, llamado VM-Gen1-chk1 de una máquina

# virtual llamada VM-Gen1, bajo la forma de una nueva máquina
# virtual, a la carpeta D:\ExportVM.
Export-VMSnapshot -Name VM-Gen1-chk -VMName VM-Gen1 -Path D:\ExportVM

g. Mejora de VM Connect (RDP over VMbus)

Con las versiones anteriores de Windows Server e Hyper-V Server (versiones 2008 a
2012), VM Connect utilizaba una redirección básica de pantalla, teclado y ratón cuando se
conectaba a una máquina virtual.

Para disponer de funcionalidades avanzadas (tales como la compartición de datos entre el

cliente y la máquina virtual), es preciso disponer una conectividad de red entre la máquina
virtual y el cliente, además de utilizar el cliente de Escritorio remoto estándar (cliente
RDP).

Esto permite disponer de todas las ventajas del protocolo RDP (redirección de lectores,
impresoras…), pero obliga a la máquina virtual a tener conectividad de red. Otra
posibilidad consiste en compartir una carpeta entre el host y la máquina virtual mediante un
vswitch de tipo externo (el host y la máquina virtual pueden comunicarse mediante un
vswitch externo, pues el host posee una tarjeta de red virtual).

Con Windows Server 2012 R2 y Windows 8.1, Microsoft incluye una funcionalidad
avanzada al cliente de conexión a un equipo virtual Hyper-V (vmconnect.exe) para que
soporte, de forma nativa, el protocolo RDP sobre el VMbus de Hyper-V. Como resultado,
cuando se habilita esta funcionalidad (lo cual se aborda más adelante), se tiene una
conexión de tipo RDP con la máquina virtual. Esta conexión permite obtener las mismas
ventajas que una conexión RDP:

• Configuración avanzada de la visualización (soporte multi-pantlalla y pantalla

multi-touch).
• Soporte del cortapapeles entre el cliente y la máquina virtual.
• Redirección del lector de tarjetas smartcard (con posibilidad de autenticación).
• Redirección del audio.
• Redirección de impresoras.
 • Redirección de lectores.
• Redirección de dispositivos USB.
• Soporte de dispositivos Plug-and-Play.

Resulta muy sencillo compartir datos entre el cliente y la máquina virtual, incluso sin una
conexión de red. Observe, no obstante, que sólo los hosts Windows Server 2012 R2,
Hyper-V Server 2012 R2 y Windows 8.1 soportan esta mejora. En el momento de escribir
estas líneas, los únicos sistemas operativos invitados que soportan esta funcionalidad son
Windows Server 2012 R2 (todas las versiones) y Windows 8.1 (también todas las
versiones). Además, deben disponer del servicio Servicios de Escritorio remoto iniciado y
la cuenta de usuario que se utiliza para conectarse a la máquina virtual debe formar parte
del grupo Usuarios de Escritorio remoto o Administradores locales en la máquina
virtual.

Para terminar, sepa que no necesita comprar una licencia de acceso a los Servicios de
Escritorio remoto (RDS CAL, Remote Desktop Services Client Access License). En efecto,
Microsoft incluye este tipo de conexiones directamente en el contrato de licencia de
Windows Server 2012 R2 y Windows 8.1, con una única conexión por máquina virtual.

He aquí los pasos a seguir para activar esta funcionalidad en el servidor host:

En el host Windows Server 2012 R2, abra el Administrador de Hyper-V y, a

continuación, en el panel Acciones, haga clic en Configuración de Hyper-V….

En la ventana de Configuración de Hyper-V, vaya a la sección Directiva de modo de

sesión mejorada, y habilite la opción Permitir modo de sesión mejorada.
Aplique los parámetros y cierre la ventana de configuración de Hyper-V.

Es todo. Simple, ¿no?

Mediante PowerShell:

Set-VMHost -Name rdvh1.miempresa.priv -EnableEnhancedSessionMode $true

Sólo queda conectarse a una máquina virtual, con un sistema operativo Windows
Server 2012 R2 o Windows 8.1, mediante el Administrador de Hyper-V de Windows
Server 2012 R2 o el cliente Hyper-V de Windows 8.1 (o mediante el comando
vmconnect.exe de estas mismas versiones de sistemas operativos). Se abrirá una nueva
ventana de conexión que le proporcionará la opción de ajustar la resolución de pantalla, así
como la posibilidad de utilizar todas las pantallas disponibles.
Haciendo clic en Mostrar (opciones avanzadas) en la esquina inferior izquierda, accede a
las opciones de redirección de recursos, similares a las del protocolo RDP.

En la sección Recursos locales, observará que la impresora principal del equipo cliente se
ha redirigido hacia la máquina virtual, así como el recurso compartido del portapapeles.
Haciendo clic en el botón Más…. tendrá la posibilidad de redirigir las unidades locales así
como los dispositivos USB y Plug-and-Play. En este ejemplo, hemos optado por hacer
disponible el lector E:\ de nuestro equipo cliente en la máquina virtual.
Una vez conectado a la máquina virtual, encontrará el lector presente en el explorador de
Windows.

Para terminar, volviendo a la primera pestaña Mostrar de la conexión, verá una

opción para Guardar mi configuración para conexiones futuras en esta máquina
virtual.
Esta opción guardará los parámetros de la conexión (desde el equipo cliente hacia esta
máquina virtual únicamente) en la carpeta %AppData%\Roaming\Windows\Hyper-
V\Client\1.0\ de su perfil de usuario en el equipo cliente.
4. Gestión de la alta disponibilidad con Hyper-V
a. Live Migration

La migración en caliente (Live Migration) permite desplazar una máquina virtual de un

servidor a otro sin pérdida en el servicio (pérdida de la conexión de red).

Es posible utilizar la migración en caliente de tres formas:

• Sin un almacenamiento común, los archivos de la VM se almacenan en discos

internos del servidor host. En este caso, la migración en caliente será mucho más
lenta debido al tiempo de copia de los archivos de disco duro virtuales (archivos
VHD y VHDX).
• Con un recurso compartido SMB 3.0, en este caso, sólo se migrarán los archivos de
memoria virtual a través de la red. Los archivos con los discos duros siguen
almacenados en el recurso compartido SMB.
• Con un almacenamiento basado en un array de discos, generalmente conectada en
forma de LUN. Sólo se migran los archivos correspondientes a la memoria virtual,
los archivos de disco duro virtual siguen en la LUN del array de almacenamiento.
Es la solución de migración en caliente más segura y la única que no entraña
ninguna interrupción en el servicio.

Windows Server 2012 R2 soporta Live Migration entre hosts Windows Server 2012/2012
R2 así como Microsoft Hyper-V 2012/2012 R2. Windows Server 2008/2008 R2 o
Microsoft Hyper-V Server 2008/2008 R2 no están soportados para Live Migration con
Windows Server 2012 R2. Windows Server 2012 R2 incluye una optimización de
rendimiento tras la migración de una máquina virtual optimizando el desplazamiento de la
memoria de la máquina virtual.

La primera posibilidad, TCP/IP, copiará los archivos de memoria virtual directamente sobre
la red a través de una conexión TCP/IP.

La segunda posibilidad difiere de la primera en el sentido de que los archivos de la

memoria virtual se comprimen antes de enviarse sobre la red en la que se transitan gracias a
una conexión TCP/IP.

La última posibilidad permite copiar archivos de memoria virtual sobre la red mediante una
conexión SMB 3.0. Se utiliza SMB Direct si las funcionalidades de acceso directo a la
memoria remota (RDMA, Remote Direct Access Memory) están habilitadas en las tarjetas
de red de origen y de destino. Esto permite obtener cieta mejora en la rapidez de hasta x10,
frente al x2 que se alcanza con una compresión sencilla mediante la opción SMB
Multichannel incluido en SMB 3.0.
El principio de funcionamiento de una migración requiere varias etapas:

• Creación de la VM en el destino.
• Copia de las páginas de memoria desde el origen hasta el destino. Las páginas
modificadas durante la transferencia se envían de nuevo (se marcan como "dirty"),
hasta 10 veces.
• La máquina virtual se pone en pausa en el origen.
• El acceso al almacenamiento (el disco virtual de la VM) se asigna al servidor de
destino.
• La máquina virtual se pone en funcionamiento de nuevo.

El Clustered Shared Volume (que se aborda en el capítulo dedicado a la Alta

disponibilidad) permite a varios servidores acceder a los archivos en el interior de una
LUN. Un nodo es propietario del espacio de nombres y sigue siendo el maestro a la hora de
crear/eliminar los metadatos (carpetas...). No obstante, distintos nodos pueden acceder a
distintos archivos sobre la misma LUN de manera simultánea, en particular a los archivos
VHD y VHDX. Esto permite, por lo tanto, almacenar todos los archivos VHD y VHDX en
una única LUN. Todos los nodos pueden acceder al conjunto de archivos, de modo que ya
no es necesario modificar el propietario de la LUN.

Las LUN pueden, también, cambiar su propietario sin interrupción, puesto que los
descriptores son persistentes.

Los servidores de origen y de destino deben utilizar procesadores del mismo fabricante. Si
los modelos de procesador no son estrictamente idénticos, Hyper-V puede enmascarar las
funciones que no sean comunes al conjunto de la plataforma. La opción Migrar a un
equipo físico con una versión de procesador distinta lo permite. Esta opción debe
configurarse en la configuración del procesador de la máquina virtual que se desea migrar.

b. Réplicas Hyper-V

Las Réplicas Hyper-V, incluidas con Windows Server 2012 e Hyper-V Server 2012,
permiten realizar una replicación síncrona de las máquinas virtuales entre dos servidores
host Hyper-V en el marco de un plan de recuperación de actividad. Esto permite, si
ocurriera algún incidente importante en el sitio principal, y gracias a la infraestructura
virtual replicada en el sitio secundario, retomar la carga de trabajo con una interrupción
mínima del servicio.

Las Réplicas Hyper-V son independientes del hardware. La infraestructura del servidor
físico no tiene por qué ser idéntico en el sitio secundario, aunque el espacio de
almacenamiento del sitio secundario debe ser, al menos, equivalente al del sitio principal, y
tener un ancho de banda de red adecuado para soportar el tráfico ligado a la replicación.

Un servidor host que se comporte como servidor de réplica puede sincronizar las VM que
provengan de varios sitios primarios, y puede replicar una máquina virtual recibida en un
servidor primario hacia un servidor secundario de réplica una vez terminada la replicación
inicial (Tiers Replica).

Debe realizarse una sincronización inicial. Ésta puede realizarse mediante:

• La red de replicación de réplicas Hyper-V.

• EL uso de una copia de seguridad del servidor primario.
• La exportación y la importación de la VM y su transporte mediante un disco USB
externo, por ejemplo.

La configuración de las Réplicas Hyper-V se realiza en dos etapas, aunque es muy sencilla.

La primera etapa consiste en configurar los servidores para que acepten la replicación. Para
ello, mediante el Administrador de Hyper-V, acceda a las propiedades del servidor y vaya
a la sección Configuración de la replicación. Observe que es preciso configurar todos los
servidores Hyper-V que participan en la réplica
Es posible utilizar el protocolo HTTP con autenticación Kerberos o HTTPS con
autenticación basada en certificados. El primer método, la combinación de HTTP/Kerberos,
puede utilizarse entre servidores Hyper-V del mismo dominio o de dominios relacionados.
Observe que esta combinación HTTP/Kerberos no encripta los datos, de modo que sólo
debe utilizarse en una red de área local, una red extendida dedicada y dotada de seguridad o
bien será preciso encriptarla mediante IPsec. El segundo método, la combinación de
HTTPS/Certificado para una replicación entre el servidor Hyper-V de dominio no aprobado
o en workgroup.

Si quiere utilizar HTTPS, tendrá que utilizar un certificado válido que debe tener el atributo
de uso mejorado de la clave (EKU) de autenticación de cliente y servidor con clave privada,
el nombre FQDN del servidor debe estar presente como nombre principal o nombre
alternativo. Además, el certificado de la entidad emisora de certificados debe ser conocido
y válido.

Puede autorizar la replicación a partir de todos los servidores autenticados o especificar el o

los servidores de origen. En el último caso, será posible definir carpetas de almacenamiento
diferentes para las máquinas virtuales.

Si el firewall de Windows está habilitado, tendrá que activas las reglas ”Escucha HTTP de
réplica de Hyper-V (TCP de entrada)” y/o ”Escucha HTTP de réplica de Hyper-V (TCP de
entrada)” en el firewall con opciones de seguridad avanzadas. Además, si replica las
máquinas virtuales hacia o desde el exterior de su red piense en abrir, y redirigir, el puerto
HTTPS (TCP 443) de su firewall.
La segunda etapa consiste en habilitar la replicación en las máquinas virtuales afectadas.
Desde el Administrador de Hyper-V, haga clic con el botón derecho en la máquina virtual
y seleccione la opción Habilitar replicación… en el menú contextual.

He aquí la información solicitada en el asistente Habilitar replicación:

• El nombre del servidor de destino.

• El tipo de autenticación HTTP/Kerberos o HTTPS/Certificado.
• Los discos virtuales que desea replicar.
• El número del punto de recuperación.
• El método para la replicación inicial, con posibilidad de planificación.

Una vez realizada la sincronización inicial, se realiza una replicación continua asíncrona
para replicar las modificaciones de la VM. Esta replicación tiene lugar, por defecto, cada 5
minutos y este valor puede modificarse entre tres valores: 30 segundos, 5 minutos o 15
minutos.

c. Compartición de discos virtuales (Shared VHDX)

Windows Server 2012 R2 presenta la funcionalidad de compartición de discos virtuales con

formato VHDX (Shared VHDX), que permite compartir un disco duro virtual entre varias
máquinas virtuales. Esto permite crear un clúster de disco único para el quórum con
máquinas virtuales, o incluso un clúster s SQL Server basado en máquinas virtuales, por
ejemplo.
Los requisitos previos son los siguientes:

• Disponer, al menos, de dos servidores con Windows Server 2012 R2 (o Microsoft

Hyper-V Server 2012 R2).
• Los servidores host deben estar en el mismo dominio de Active Directory.
• Los servidores host deben tener los roles Hyper-V y Failover Clustering instalados.
• Los servidores host deben poder acceder a un sistema de almacenamiento a nivel de
bloque, de tipo CSV o SoFS. Este almacenamiento puede estar alojado en zonas
ISCSI, Fibre Channel, Direct Attached (SAS) o en espacios de almacenamiento en
clúster (Clustered Storage Space).
• Las máquinas virtuales deben estar instaladas con Windows Server 2012 R2.

La funcionalidad de compartición de disco duro virtual soporta únicamente discos virtuales

en formato VHDX de tamaño fijo o dinámico. Los archivos VHDX a compartir deben
estar, obligatoriamente, almacenados en un CSV (Cluster Shared Volume) o en una
partición SoFS (Scale-Out File Server con SMB 3.0). Los discos duros virtuales
están disponibles para las máquinas virtuales de generación 1 y de generación 2, siempre
que se cumplan los requisitos previos y el disco duro virtual compartido esté asociado a un
controlador SCSI en el seno de las máquinas virtuales.

Para poder utilizar un disco virtual compartido, conviene, en primer lugar, crear un clúster
de servidores Hyper-V, con Windows Server 2012 R2 o Hyper-V Server 2012 R2, con un
almacenamiento CSV o SoFS. Para ello, consulte el capítulo que trata sobre la Alta
disponibilidad.

Una vez instalado el clúster, tendrá que crear un disco duro virtual, con formato VHDX y
almacenado en CSV o SoFS, y asociar las máquinas virtuales correspondientes. La creación
del disco duro virtual es sencilla:

Abra la consola Administrador de Hyper-V y, en el panel Acciones, haga clic en Nuevo

y Disco duro… y, a continuación, haga clic en Siguiente para pasar la primera pantalla del
asistente de creación de un disco virtual.
Los discos virtuales compartidos se soportan únicamente con formato VHDX, seleccione
VHDX y haga clic en Siguiente.
Los discos virtuales compartidos no soportan los discos de diferenciación.

Un disco duro virtual de diferenciación requiere la presencia de un disco duro virtual padre
que sirva como base, y contiene todas las diferencias que posea con su padre. Del mismo
modo que un disco AVHDX necesita un punto de control.

Seleccione el tipo de disco duro entre Tamaño fijo o Tamaño dinámico y, a

continuación, haga clic en Siguiente.
 Indique el nombre del archivo así como su ubicación. Esta puede tener el formato
"D:\SharedVD\" si se trata de un CSV, o formato UNC (en nuestro ejemplo
\\rdvh1\SharedVD\) con un SoFS. Haga clic en Siguiente para definir el tamaño del disco
virtual y, a continuación, haga clic de nuevo en Siguiente y en Finalizar.

He aquí la misma operación con PowerShell mediante el comando New-VHD:

# Para un disco virtual de 40 GB de tipo dinámico almacenado en el

# recurso compartido\\rdvh1\SharedVD\.
New-VHD -Dynamic -Path \\rdvh1\SharedVD\SharedVolume.vhdx -SizeBytes 40GB

Tan sólo queda asociar este disco virtual a las máquinas virtuales a las que está destinado, y
habilitar el recurso compartido. Para ello, mediante el Administrador de Hyper-V, edite los
parámetros de una de las máquinas virtuales y agregue el disco creado al controlador SCSI.
Haga clic en el pequeño icono "+" correspondiente al disco agregado y seleccione
Características avanzadas.
 Marque la opción Activar uso compartido de discos duros virtuales y, a continuación,
haga clic en Aplicar y Aceptar.

Puede, también, crear un disco compartido con PowerShell mediante el cmdlet ADD-
VMHardDiskDrive:

# Para vincular un disco virtual en posición (SCSI 0, Disk 1) con el

# parámetro "Compartir disco duro virtual", que se encuentra en el
# recurso compartido de tipo SoFS, a una máquina virtual
# llamada VM-Gen1.
Add-VMHardDiskDrive -VMName VM-Gen1 -ControllerType SCSI
-ControllerNumber 0 -ControllerLocation 1 -Path
\\rdvh1\SharedVD\SharedVolume.vhdx
-SupportPersistentReservations

# Observe que puede, también, utilizar el parámetro

# « -ShareVirtualDisk » que es un alias de
# « -SupportPersistentReservations ».

Sólo queda asociar, del mismo modo, su disco duro compartido a otras máquinas virtuales,
y crear un clúster compuesto de sus máquinas virtuales, por ejemplo.

5. SCVMM 2012 R2

SCVMM 2012 R2 (System Center Virtual Machine Manager) es necesario para administrar
los servidores Hyper-V con Windows Server 2012 R2. La instalación del módulo
complementario SCVMM 2012 R2 es muy sencilla y rápida de realizar. No cabe, por lo
tanto, sobrevalorar su aporte funcional en la administración de la infraestructura. No
obstante, tendrá que instalar previamente Windows ADK 8.1 (Windows Assessment and
Deployment Kit), puesto que es un requisito previo indispensable.

Las principales funcionalidades son:

• Soporte de las características de Windows Server 2012 (máquina virtual de

generación 2, redimensionamiento de disco en caliente, exportación y clonado de
máquinas virtuales en caliente, etc.).
• Centralización del despliegue y de la gestión de las máquinas virtuales para Hyper-
V, Virtual Server y VMware ESX.
• Conversión P2P y P2V rápida y fiable, sin ninguna herramienta suplementaria.
• Integración con SCOM para la supervisión.
• Optimización de los recursos y del rendimiento proporcionando desplazamientos y
una ubicación de las máquinas virtuales teniendo en cuenta las funciones de red
TCP Chimney Offload y VMQ en las propuestas de ubicación.
• Administración centralizada de una librería de componentes para las máquinas
virtuales.
• Delegación de ciertas tareas de administración.
• Integración con los clústeres.
• Automatización e industrialización mediante scripts de PowerShell. SCBMM 2012
es completamente scriptable con PowerShell 4.0 (incluido en Windows Server 2012
R2). Los scripts PowerShell 3.0 están soportados con más del 90% de los cmdlets
de PowerShell en común con PowerShell 4.0. En lo relativo a los scripts PowerShell
2.0, tendrá que instalar la funcionalidad complementaria "Motor de Windows
PowerShell 2.0". Además, sepa que dado que algunos cmdlets están restringidos en
PowerShell 2.0, es preferible utilizar scripts PowerShell 3.0 o 4.0.
• Administración de varias soluciones de virtualización Microsoft (Virtual Server,
Hyper-V 1.0/2.0/3.0) y no Microsoft (Vmware ESX 3.5/4/5 a través de Virtual
Center).
• Generación de informes acerca del estado de la infraestructura virtual.
• Soporte de las migraciones de las VM ubicadas fuera de un clúster hacia un clúster,
y viceversa. Soporte de la migración en caliente (live migration).
• Soporte del almacenamiento dinámico en las VM en caliente (Windows
Server 2008 R2 como mínimo).
 • Soporte de las redes virtuales VMware ESX y de los grupos de puertos virtuales
(Windows Server 2008 R2 como mínimo).
• Soporte del modo de mantenimiento (Windows Server 2008 R2 como mínimo). La
implementación del mantenimiento de un host hace que las VM que hospeda se
pongan en pausa, impide la creación de VM sobre el propio host, o el
desplazamiento de VM hacia el mismo.

No obstante, no es posible instalarlo sobre una edición Core. Las únicas opciones reales que
tiene durante la instalación son las relativas a la base de datos de SCVMM 2012 R2 y las
cuentas sobre las que se ejecutará el servicio SCVMM. Ya no es posible utilizar un motor
SQL Express 2008/2008 R2/2012, sino que tendrá que utilizar, obligatoriamente, un
servidor SQL 2008 R2 SP2 o 2012:

Tiene dos posibilidades para administrar su entorno virtual con SCVMM 2012 R2:

• Mediante su interfaz gráfica, la Consola Virtual Machine Manager.

• Mediante la extensión de PowerShell.

Antes de aprovisionar las máquinas virtuales, debería:

• Declarar los servidores Hyper-V que quiere administrar (al menos uno).
 • Declarar las redes virtuales.
• Crear las plantillas de los perfiles para las máquinas virtuales.
• Agregar las imágenes ISO a la biblioteca.
• Crear plantillas de discos duros virtuales.

La declaración de redes virtuales se realiza desde las propiedades del servidor virtual:

De cara a simplificar y automatizar el despliegue de nuevas máquinas virtuales, es

posible definir distintos tipos de perfil: perfil de aplicación, perfil de sistema operativo
invitado o incluso perfil SQL Server. Los perfiles de hardware permiten utilizar las
plantillas de configuración en lugar de configurar manualmente los recursos para cada VM.
Más allá de la ganancia en eficacia a la hora de crear una VM, esto permite mantener una
consistencia en la configuración entre dos máquinas virtuales, ganando, así, en calidad.
Para gestionar los perfiles de hardware, vaya a Biblioteca y, a continuación, Perfiles.

Un perfil incluye los siguientes parámetros:

Agregar imágenes ISO consiste simplemente en copiar archivos ISO en la carpeta
compartida de la biblioteca SCVMM.

Tras una actualización de la biblioteca, Virtual Machine Manager indexa los archivos
registrados en las carpetas compartidas de la biblioteca, y a continuación actualiza la vista
Biblioteca y la lista de recursos. No todos los archivos están indexados y no todos los
archivos aparecen en la vista Biblioteca. El contenido de la biblioteca se refresca
automáticamente por defecto cada hora. El tipo de contenido que se indexa es el siguiente:

• discos duros virtuales: .vhdx y .vhd (Hyper-V, Virtual Server), .vmdk (VMware).
• disquetes virtuales: .vfd (Virtual Server), .flp (VMware).
• Imágenes ISO: .ISO.
• archivos de respuesta: .ps1 (Windows PowerShell); .inf o .xml.
• plantillas VMware: .vmtx.

Los siguientes tipos de archivos de configuración también se indexan, aunque no se

agregan a la biblioteca como recursos:

• Hyper-V: .exp (formato para exportar), .vsv (estado almacenado), .bin.

• Virtual Server: .vmc (configuración de la máquina virtual), .vsv (estado
almacenado).
• VMware: .vmtx (configuración de la máquina virtual), .vmx (formato de
exportación).
 • Los discos duros virtuales, imágenes ISO y disquetes virtuales asociados a un
equipo virtual.

La administración de las máquinas virtuales puede realizarse mediante PowerShell, lo que

abre las puertas necesarias a las planificaciones, automatizaciones y procesamientos
masivos.

He aquí algunos ejemplos de comandos PowerShell:

Recuperar una cuenta de acceso:

$Credential = get-credential

Recuperar el identificador del grupo "Todos los equipos host":

$VMHostGroup = Get-VMHostGroup -VMMServer localhost | where

{$_.Path -eq "Todos los equipos host"}

Agregar el recurso Hyper-V:

Add-VMHost -VMMServer localhost -ComputerName

"hyperv.miempresa.priv" -Description "" -Credential
$Credential -RemoteConnectEnabled $true -VmPaths "E:\VMDATA"
-Reassociate $false -RunAsynchronously -RemoteConnectPort
2179 -VMHostGroup $VMHostGroup

Declarar un nuevo adaptador de red virtual:

New-VirtualNetworkAdapter -VMMServer localhost -JobGroup

e4c2dfd1-0091-4a2a-992f-3406cfe833eb -PhysicalAddressType
Dynamic -VirtualNetwork "Net_LAN" -VLanEnabled $false

Declarar un nuevo lector de DVD virtual:

New-VirtualDVDDrive -VMMServer localhost -JobGroup e4c2dfd1-

0091-4a2a-992f-3406cfe833eb -Bus 1 -LUN 0

Utilizar un tipo de procesador ya existente:

$CPUType = Get-CPUType -VMMServer localhost | where {$_.Name

-eq "3.07 GHz Xeon"}

Declarar un nuevo perfil de hardware para las VM:

New-HardwareProfile -VMMServer localhost -Owner

"MIEMPRESA\administrador" -CPUType $CPUType -Name
"Profil11d45f28-11b9-414b-aca0-ce8fbf6b9081"
-Description "Configuración de hardware para
crear una máquina virtual/plantilla" -CPUCount 2
-MemoryMB 512 -RelativeWeight 100 -HighlyAvailable $false
-NumLock $false -BootOrder "CD", "IdeHardDrive",
"PxeBoot", "Floppy" -LimitCPUFunctionality $false
-JobGroup e4c2dfd1-0091-4a2a-992f-3406cfe833eb

Recuperar un perfil de hardware existente:

$HardwareProfile = Get-HardwareProfile -VMMServer

localhost | where {$_.Name -eq "Profil11d45f28-11b9-
414b-aca0-ce8fbf6b9081"}

Declarar un nuevo disco virtual:

New-VirtualDiskDrive -VMMServer localhost -IDE -Bus 0

-LUN 0 -JobGroup e4c2dfd1-0091-4a2a-992f-3406cfe833eb
-Size 40960 -Dynamic -Filename "PRD-DOM-WEB01_disco_1"

Recuperar un sistema operativo existente:

$OperatingSystem = Get-OperatingSystem -VMMServer

localhost | where {$_.Name -eq "64-bit edition of
Windows Server 2008 Standard"}

Recuperar un servidor Hyper-V:

$VMHost = Get-VMHost -VMMServer localhost | where

{$_.Name -eq "hyperv.miempresa.priv"

Declarar una nueva máquina virtual:

New-VM -VMMServer localhost -Name "PRD-DOM-WEB01"

-Description "Servidor WEB IIS en el dominio" -Owner
"MIEMPRESA\administrador" -VMHost $VMHost -Path "E:\VMDATA"
-HardwareProfile $HardwareProfile -JobGroup e4c2dfd1-
0091-4a2a-992f-3406cfe833eb -RunAsynchronously
-OperatingSystem $OperatingSystem -RunAsSystem
-StartAction TurnOnVMIfRunningWhenVSStopped -DelayStart 0
-StopAction ShutdownGuestOS

Los comandos New-HardwareProfile y New-VM ejecutan el grupo de comandos que

poseen el mismo JobGroup. Si desea más información acerca de los JobGroups consulte la
siguiente página: http://technet.microsoft.com/es-es/library/hh875035.aspx

Si desea administrar clústeres Hyper-V con SCVMM, he aquí algunas consideraciones:

• Si agrega almacenamiento sobre un clúster e inmediatamente desea agregar

máquinas virtuales sobre este almacenamiento, asegúrese previamente de que el
clúster se ha refrescado en SCVMM para tener en cuenta este nuevo
almacenamiento.
• La creación/supresión de los clústeres no puede hacerse en SCVMM.
 • Los clústeres que no están en un dominio de confianza no pueden administrarse con
SCVMM.

La optimización de los recursos puede administrarse en función de los siguientes

parámetros:

Este conjunto de criterios se utiliza a continuación para sugerir el lugar donde almacenar y
desplazar las máquinas virtuales a través de una configuración en estrella.

SCVMM permite a su vez administrar la asignación de direcciones MAC a las máquinas

virtuales. Por defecto, se define un rango, aunque puede modificarse en caso de problema:
Esto no es sino una pequeña introducción de las posibilidades de System Center - Virtual
Machine Manager 2012, este producto necesitaría un libro entero para poder dominarlo con
destreza.

6. Actualizaciones de Windows

Con el objetivo de facilitar la instalación de las actualizaciones de Windows, Microsoft

proporciona una herramienta complementaria a SCVMM, el Offline Virtual Machine
Servicing 2012. El objetivo de esta herramienta es iniciar las máquinas virtuales sobre una
red aislada (preferentemente), iniciar las actualizaciones de Windows, y apagar la máquina
virtual, incluyéndola de nuevo en la biblioteca. Necesita por un lado SCVMM, y por otro
un servidor WSUS local (gratuito) o SCCM 2012 R2. Puede descargarse en la siguiente
dirección: http://www.microsoft.com/en-us/download/details.aspx?id=30470

Esta herramienta se proporciona para 32 y 64 bits.

Se recomienda su uso en infraestructuras virtuales consecuentes con un número importante

de máquinas virtuales detenidas, o para entornos donde la seguridad es un factor
importante. Antes de decidir utilizar o no esta herramienta, he aquí algunos puntos que
debería considerar:
 • Las VM deben estar configuradas para utilizar el servidor WSUS mediante GPO u
otro (no considerado en esta herramienta), o tener el cliente SCCM instalado y
configurado.
• WSUS o SCCM deben estar configurados previamente para que las actualizaciones
estén aprobadas en el despliegue de estas VM.
• Las VM deben estar en DHCP, o tener una configuración de red funcional en la red
de actualizaciones.
• Si se van a actualizar más de 20 máquinas virtuales con esta herramienta, se
recomienda que la infraestructura en torno a la misma sea física y no virtual
(servidor WSUS, SCVMM...).
• Funciona a la vez sobre una infraestructura Hyper-V y Virtual Server 2005.
• Todos los servidores físicos y las máquinas virtuales deben formar parte del
dominio Active Directory, con el servicio DNS instalado y configurado.

He aquí un ejemplo de arquitectura:

Conclusión
Para concluir, ahora conoce qué puede aportarle la virtualización, con la condición de tener
en cuenta sus especificidades. Si, como ocurre cada vez con más administradores, observa
una ventaja clara al virtualizar, debe realizar una prueba de concepto para validar sus
hipótesis. Según su contexto, la complejidad de este tipo de proyecto puede variar de forma
importante y debe estar preparado en consecuencia. Como se indica en la introducción,
piense a lo grande pero comience dando pequeños pasos para poder tener un aumento de
carga controlado.

Introducción
Este capítulo está dedicado al despliegue de servidores y puestos de trabajo. Contar con una
plantilla de instalación automatizada supone una ganancia importante en la productividad y
en la calidad. La instalación de servidores tiene poco valor añadido aunque debe hacerse
siempre de la misma forma, con las mismas versiones de componentes, para tener
coherencia entre todos los sistemas. Un despliegue comprende como mínimo el sistema
operativo, pero también generalmente el conjunto de controladores, herramientas del
sistema, o incluso el conjunto de aplicaciones necesarias.

La automatización de este proceso cobra mayor sentido con la virtualización, y los entornos
"a la carta". La preparación de este despliegue es un aspecto muy importante para el éxito
de su proyecto. La tecnología no supone ningún inconveniente, ¡no hay ningún motivo para
no usarla!

Preparar bien el despliegue planteando

una buena estrategia
La preparación es la fase crítica del proyecto. Para no olvidar nada y acelerar su despliegue,
Microsoft proporciona diferentes herramientas adaptadas a su contexto. Al finalizar esta
etapa, usted habrá determinado el perímetro, el tipo de licencias y ediciones de Windows, el
plan de despliegue así como la infraestructura necesaria para conseguirlo.

1. Definir el perímetro

Como en todo proyecto, el perímetro es aquí un elemento clave. Debería definir lo que es
"obligatorio" y lo que es "opcional". Para llevar a cabo esta reflexión, he aquí una lista de
elementos que pueden integrarse en su proyecto:

• ¿Sólo servidores o también puestos cliente?

 • ¿Qué versiones y ediciones de Windows se desea incluir?
• ¿Hace falta gestionar varios idiomas?
• ¿Qué nomenclatura desea adoptar para los sistemas desplegados?
• ¿Quién va a desplegar estas imágenes? ¿La implementación debería estar
completamente automatizada?
• ¿Qué hardware (y controladores) desea incluir?
• ¿Qué actualizaciones deben/pueden estar presentes tras el despliegue?
• ¿Qué herramientas o aplicaciones forman parte del núcleo común y pueden estar
presentes tras el despliegue? ¿Puede hacer una instalación genérica y automatizada
de estas aplicaciones?
• ¿Es necesario crear varias imágenes de despliegue con distintas opciones o basta
con una sola? ¿Hace falta una imagen específica para los entornos virtuales?
• ¿Todos los equipos a desplegar están sobre la red local y en el dominio? ¿Hace falta
poder instalar una imagen desde un DVD?
• ¿Ya utiliza SCCM 2012 SP1 CU3 o SCCM 2012 R2 (System Center Configuration
Manager)?
• ¿Cómo piensa administrar las licencias asociadas a los sistemas operativos? ¿Utiliza
licencias por volumen?

La respuesta a esta lista de preguntas cubre gran parte del perímetro. Las decisiones que
más impactarán al proyecto de despliegue son:

• el uso de SCCM 2012 SP1 o SCCM 2012 R2, que permiten realizar un despliegue
"zero touch";
• la integración de aplicaciones en la imagen;
• la elección del modo de transporte para el despliegue (red u otro).

El hecho de incluir más o menos tipos de hardware sólo tiene impacto en el tiempo
necesario para incluir los controladores adecuados. Se habrá dado cuenta de que se ha
empleado el término "imagen" para designar al método de despliegue. Se trata, en efecto,
de construir un modelo de servidor que se va a capturar en forma de imagen y a volver
genérico. Esto hace que la integración de las aplicaciones en el despliegue sea una tarea
muy sencilla, siempre y cuando su instalación sea genérica. Esta imagen puede desplegarse
a continuación mediante diversos medios, a través de la red o mediante un DVD.

2. Administración de las licencias

Presentado con Windows Vista y Windows Server 2008, Windows 8.1 y Windows
Server 2012 R2 pueden utilizar el servicio de administración de licencias por volumen:
KMS (Key Management Service) para la activación de Windows. Se trata de un servicio de
infraestructura que debe implantar en su red para administrar las licencias de sus servidores
y puestos de trabajo. Si no implementa este servicio, cada equipo tendrá que conectarse de
forma individual a Microsoft a través de Internet para activarse. La activación mediante del
servicio KMS permite no tener que conectarse a Microsoft para activar Windows, y esta
activación es válida por 6 meses. Pasado este periodo, el sistema tiene que activarse de
nuevo por un periodo de 180 meses más conectándose a su red. KMS puede implementarse
a partir de 25 licencias Windows 8.1 o 5 licencias Windows Server 2012 R2. El servicio
KMS puede, también, activar Microsoft Office 2010 y 2013.

La instalación de KMS es tan sencilla como introducir la clave KMS, pues el servicio de
Windows asociado ya está instalado y activo por defecto (se trata del Servicio de licencias
de software):

cscript C:\windows\system32\slmgr.vbs /ipk claveKMS

A continuación, el servidor debe validar esta clave con Microsoft. Este proceso tiene lugar
una sola vez cada vez que se agrega una clave. Si el servidor tiene acceso a Internet:

cscript C:\windows\system32\slmgr.vbs /ato

En caso contrario, podrá realizar la activación telefónicamente ejecutando el comando

slui.exe 4.

Para detectar el servidor KMS, Windows utiliza el DNS, un recurso SRV en particular. Si
las actualizaciones dinámicas de DNS están autorizadas, el servicio crea automáticamente
los registros DNS adecuados. Si su entorno no las autoriza, podrá configurar KMS para que
deje de intentar crear el registro SRV ejecutando el comando:

cscript %systemroot%\system32\slmgr.vbs /cdns

El recurso SRV puede crearse de forma manual con los siguientes parámetros:

• Servicio: _VLMCS
• Protocolo: _TCP
• Puerto: 1688
• Host que ofrece el servicio: FQDN del host

Si el servicio DNS no está disponible desde el cliente, podrá especificar de forma manual la
dirección IP del servidor KMS que desee utilizar mediante el comando:

cscript %systemroot%\system32\slmgr.vbs /skms X.X.X.X:1688

Si existe un firewall entre los equipos a activar y el servidor KMS, el puerto TCP 1688 (por
defecto) tiene que estar abierto (del lado cliente únicamente).

Si desea cambiar el puerto TCP es preciso modificar la siguiente clave tanto en el servidor
KMS como en los clientes:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL

Nombre: KeyManagementServicePort

Tipo: REG_SZ
Valor: XXXX (valor que representa el nuevo puerto de escucha TCP).

Para conocer el número de licencias que actualmente se están utilizando en su KMS, puede
ejecutar el siguiente comando:

cscript %systemroot%\system32\slmgr.vbs /dli

Si no desea utilizar KMS sino que prefiere activar de forma masiva sus sistemas Windows,
puede utilizar VAMT (Volume Activation Management Tool). Puede descargar esta
herramienta desde MDT 2012, en el nodo Componentes.

3. Seleccionar la edición y el tipo de instalación

A diferencia de Windows Server 2008/2008 R2, donde cada pareja edición/tipo de

instalación (completa o mínima) requería una nueva imagen de despliegue, Windows
Server 2012 R2 sólo necesita dos. Una para la edición Estándar y otra para la edición
Datacenter. Los servidores virtuales se instalarán, generalmente, con ediciones Estándar de
Windows Server.

El primer motivo es que la interfaz gráfica puede, ahora, instalarse o desinstalarse con total
sencillez. Se ha convertido en una característica más. Ya no hay, por lo tanto, necesidad de
tener una imagen particular para una instalación mínima.

El segundo motivo reside en el hecho de que ya no existe ninguna diferencia entre la

edición Estándar y Datacenter con Windows Server 2012 R2. Ya no es preciso tener que
recurrir a la edición Enterprise (que no existe con Windows Server 2012) o a la edición
Datacenter para aprovechar la funcionalidad de Failover Clustering, por ejemplo, como era
el caso con Windows Server 2008/2008 R2.

Existe, en resumen, una menor cantidad de imágenes que gestionar, lo cual supone una
buena noticia.

Crear y ejecutar el despliegue

Esta sección cubre la creación y el despliegue de los sistemas operativos, tanto de clientes
como de servidores. Microsoft Deployment Toolkit es la herramienta central, que enriquece
las herramientas nativas mediante una interfaz amigable y un emplazamiento único donde
alojar todos los datos necesarios para los despliegues. Proporciona dos métodos: Lite Touch
y Zero Touch

1. Microsoft Deployment Toolkit (MDT 2013)

Microsoft pone a su disposición de forma gratuita una herramienta que le permitirá acelerar
su proyecto de despliegue, MDT 2013. Éste soporta Windows 7 y Windows Server 2012
R2, gracias a WADK para Windows 8.1. MDT 2013 soporta, también, Office 2010, Office
365 y Zero-Touch Integratio (ZTI) con System Center 2012 R2. Observe que MDT 2013
no permite instalar Windows XP, Windows Vista, Windows Server 2003/2003 R2 o
incluso Windows Server 2008, para trabajar con estos sistemas operativos tendrá que
utilizar MDT 2012 SP1 CU2 con WADK para Windows 8 o WAIK para Windows 7.

MDT utiliza varios componentes, como WADK para Windows 8.1 (Windows Assessment
and Deployment Kit), que soporta desde Windows 7 SP1 y Windows Server 2008 R2 hasta
Windows 8.1 y Windows Server 2012 R2. WADK para Windows 8.1 necesita,
obligatoriamente, MDT 2013 para funcionar. Está disponible en la siguiente dirección:
http://www.microsoft.com/es-es/download/details.aspx?id=39982

WADK y WAIK son dos componentes bastante similares. Contienen un conjunto de

herramientas que permiten personalizar y desplegar Windows a gran escala. Sus verdaderas
diferencias son:

• las versiones de Windows soportadas, de Windows XP SP3 a Windows 7 para

WAIK, y de Windows 7 a Windows 8.1 para WADK.
• la versión de MDT soportada, MDT 2012 sp1 para WAIK, y MDT 2013 para
WADK.

He aquí una lista no exhaustiva de las herramientas que contienen WAIK y WADK:

• User State Migration Tool (USMT): esta herramienta permite migrar datos de un
perfil de usuario a otro.
• Application Compatibility Toolkit (ACT): aplicación que permite detectar
eventuales problemas de compatibilidad de sus aplicaciones y drivers antes de
realizar una actualización de Windows.
• Volume Activation Management Tool (VAMT): herramienta que permite
gestionar y centralizar la activación de Windows en la red.
• Herramientas de modificación de imagen: ImageX, que permite capturar y aplicar
las imágenes WIM, DISM, que permite modificar una imagen WIM...
• Windows Preinstallation Environment (Windows PE): ofrece un entorno
personalizable de instalación de Windows.

Una vez instalados MDT 2013 y WADK, la interfaz de administración se encuentra en la

pantalla de inicio de Windows, Deployment Workbench. Los componentes
complementarios pueden descargarse desde la misma consola en la pestaña Components:
Es preciso descargar, al menos, el componente Windows Assessment and Deployment
Kit para Windows 8.1 (también llamado WADK), en 32 o 64 bits dependiendo de su
entorno de trabajo. MDT está disponible únicamente en inglés, y descargará dicho
componente en inglés. Para descargar la edición española, basta con ir a la siguiente
dirección: http://www.microsoft.com/es-es/download/details.aspx?id=39982

Cuando alguno de los componentes no esté presente, no funcionará ninguna de las

funcionalidades del árbol Deployment Share. MDT controla WADK para asistirle en la
implementación y no puede funcionar sin él. Descargándolo, obtiene también Windows PE.

Una vez instalado WADK, el árbol Deployment Shares permite crear un espacio de
trabajo. Para ello, basta con hacer clic con el botón derecho, seleccionar la opción New
Deployment Share. La ubicación seleccionada debe tener suficiente espacio para contener
las fuentes y las imágenes generadas.
A continuación, podemos alimentar cada módulo de este espacio de trabajo:

• Applications: contendrá las aplicaciones incluidas en el despliegue.

• Operating Systems: contendrá los archivos fuentes de los sistemas operativos.
• Out-of-Box Drivers: contendrá los controladores suplementarios necesarios.
• Packages: contendrá las actualizaciones de Windows que desee integrar.
• Task Sequences: permite crear un escenario a partil de elementos de los módulos.
• Advanced Configuration: permite crear un medio (DVD...), guardar una traza de
los despliegues en una base de datos SQL o administrar las réplicas del punto de
distribución.

Las siguientes etapas son:

• Agregar los sistemas operativos (desde su DVD...).

• Agregar las aplicaciones (instalación silenciosa...).
• Agregar las actualizaciones de Windows.
• Agregar los controladores.
• Crear una secuencia de acciones a realizar.
• Crear una base de datos para inventariar las máquinas desplegadas.

Es muy sencillo agregar sistemas operativos. Una vez importado el CD o DVD, aparecerá
de la siguiente manera:
Observe que la lista comprende a la vez Windows Server 2012 R2 y Windows 8.1. MDT
2013 también permite desplegar Windows Server 2008 R2, Windows Server 2012 R2,
Windows 8 y Windows 7.

Agregar una aplicación mediante el nodo Applications le permitirá instalar aplicaciones

post-despliegue. Se trata de instalaciones silenciosas, de archivos MSI, etc. A continuación
podrá integrarlas en las secuencias de instalación. Están disponibles las siguientes
propiedades:
La selección Application bundle permite agrupar las aplicaciones. La agregación de
actualizaciones de Windows se realiza mediante el nodo Packages. Es tan sencillo como
indicar la carpeta que las contiene (archivos .cab y .msu). Por defecto, pertenecen al grupo
All Packages. Puede agregar grupos personalizados para filtrar las actualizaciones en las
secuencias de instalación. El apartado Out-of-Box Drivers contendrá todos sus
controladores. Basta con indicar la carpeta que los contiene (archivos .inf). Puede clasificar
los elementos de cada apartado en carpetas y subcarpetas.
El nodo Task Sequences es la pieza clave de la aplicación. Permite articular todos los
elementos para crear los escenarios de instalación. Durante la instalación de una secuencia
sólo es posible indicar las opciones básicas:

• Un identificador único, un título y una descripción.

• Una máscara de secuencia.
• Un sistema operativo de entre la lista del apartado Operating Systems.
• Indicar o no el número de serie (periodo de prueba que expira).
• El nombre y la página por defecto de Internet Explorer.
• La contraseña del Administrador local (o que se solicitará tras el primer inicio de
sesión).

Una vez creada, hay que abrir las propiedades de la secuencia, en la pestaña Task
Sequence, para descubrir toda la capacidad real de las secuencias:
Las opciones están agrupadas por temática:

• General

• Ejecutar una línea de comando.

• Ejecutar un script PowerShell.
• Asignar un valor a una variable.
• Reiniciar.
• Recoger información.
• Instalar actualizaciones tras el primer arranque.
• Validar.
• Instalar una o varias aplicaciones presentes en el nodo Applications.
• Instalar controladores.
• Ejecutar un Runbook System Center Orchestrator.

• Discos
 • Particionar y formatear un disco.
• Activar BitLocker.
• Crear discos virtuales VHD.

• Imágenes

• Instalar un sistema operativo.

• Configuración

• Aplicar una configuración de red (IP, DNS, WINS).

• Capturar la configuración de red existente.

• Roles

• Instalar y configurar roles y características. Las posibilidades varían según el

sistema operativo a instalar.
• Configurar el servidor DHCP, DNS, Active Directory, y por último autorizar a
DHCP.

Los posibles escenarios son muy amplios durante el despliegue:

• Copia de seguridad o no de los perfiles de usuarios locales sobre una partición en

red (con restauración).
• Capturar la configuración de red antes de la reinstalación, y a continuación
restaurarla.
• Instalación y configuración de roles.
• Administración de BitLocker con su configuración:

• Medio de almacenamiento (TPM, USB, ambos).

• Creación de una clave de recuperación en Active Directory.
• Esperar a que termine la encriptación antes de continuar.

• Instalación de las actualizaciones de Windows.

A continuación queda por definir un punto de despliegue en el apartado Deploy -

Deployment Points. Las posibilidades son:

• La partición local a la máquina donde se ejecuta MDT 2013.

• Una partición local o remota que contenga un único juego de configuración.
• Un medio de almacenamiento extraíble (DVD, USB).
• Una integración con SCCM 2012 R2 o versiones anteriores.

Las secuencias se almacenan en la subcarpeta Control del recurso compartido creada

anteriormente, con la siguiente arborescencia:
 • En la raíz:

• Bootstrap.ini: archivo de configuración cuando la máquina que se despliega no

puede conectarse a un punto de despliegue.
• CustomSettings.ini: archivo de configuración común a todas las secuencias.

• {Número de secuencia}

• TS.xml: contiene metadatos relacionados con la secuencia.

• Unattend.xml: contiene los valores para el sysprep.

El despliegue desde un medio portátil es el más básico, aunque es muy eficaz cuando la
conectividad de la red está limitada. En la carpeta de destino encontrará una imagen ISO de
arranque, LiteTouchPE_x86.iso o LiteTouchPE_x64.iso según su entorno.

Windows PE es el entorno de preinstalación de Windows. Se trata de un sistema Windows

muy ligero que permite ejecutar un conjunto de herramientas para desplegar un sistema
operativo Windows. La imagen WIM generada con MDT utiliza Windows PE. En este tipo
de entornos el motor vbscript está disponible. Las pantallas gráficas MDT son vbscript y
HTA (HTML Applications). Al tener los archivos en memoria, Windows PE puede
particionar y formatear todo el espacio de almacenamiento disponible, en especial la
partición de sistema. Ciertas herramientas, como USMT e ImageX, funcionan en este tipo
de entorno, lo que permite realizar una copia de seguridad de los datos del equipo antes de
su reinstalación, por ejemplo. La versión actual es la 4.1 que se corresponde con Windows
8 y Windows Server 2012 R2.

He aquí un ejemplo del entorno que proporciona MDT:

2. Lite Touch

La solución Lite Touch le permite industrializar el despliegue sin tener que disponer de la
infraestructura de gestión de Microsoft, System Center Configuration Manager 2012 R2. La
solución es sencilla de implantar pero mantiene su eficacia, pues utiliza el motor de
secuencia de esta última en versión autónoma. El despliegue debe iniciarse de forma
manual, pero se le guiará mediante pantallas gráficas para llevarlo a cabo.

Más allá del uso de una imagen ISO como se ha visto anteriormente, es posible realizar el
despliegue a través de la red utilizando WDS (cuya instalación se cubre más adelante). A
continuación, debe especificar en CustomSettings.ini la variable
DeployRoot=\\%WDSServer%\DeploymentShare$, en la sección [Default].

Tiene que reemplazar DeploymentShare$ por el nombre de su recurso compartido si no ha

dejado el nombre por defecto. A continuación tiene que actualizar el punto de distribución
haciendo clic con el botón derecho encima de él y a continuación seleccionar Update
Deployment Share. Basta con:

• Importar ambas imágenes WIM en WDS;

• arrancar una máquina mediante PXE.
También es posible utilizar el modo multicast para el despliegue:

Antes de desplegar una imagen se plantean varias preguntas a través de la interfaz gráfica.
Es posible aumentar la automatización, evitándolas. Para ello tendrá que proporcionar la
respuesta a estas preguntas en el archivo CustomSettings.ini. He aquí las etapas que
pueden evitarse si las siguientes variables se informan a YES (en mayúsculas) en el archivo
CustomSettings.ini, sección [Default]. A cada pantalla le corresponde una variable para
omitirla y una o varias variables para informar los datos solicitados por pantalla:

SkipAdminPassword: no solicitar la contraseña del administrador local.

• Automatizar mediante AdminPassword=micontraseñadeadministrador. La con-

traseña se almacenará sin encriptar en el archivo, debería, por tanto, cambiar de
contraseña posteriormente. Del mismo modo se recomienda cambiarla regularmente
en el conjunto de sus equipos.

SkipApplications: omitir la etapa que propone instalar aplicaciones.

• Automatizar mediante Applications001={GUID de la aplicación que se encuentra

en control\Applications.xml}
SkipAppsOnUpgrade: omitir la etapa de instalar aplicaciones si se trata de una
actualización.

SkipBDDWelcome: omitir la pantalla de bienvenida.

SkipBitLocker: omitir BitLocker.

SkipBitLockerDetails: omitir la configuración de BitLocker.

SkipTaskSequence: omitir la selección de la secuencia.

• Automatizar mediante TaskSequenceID={Identificador de la secuencia}

SkipCapture: omitir el uso de captura.

• Automatizar mediante DoCapture=NO|YES|PREPARE

SkipComputerBackup: omitir la copia de seguridad del equipo.

• Automatizar mediante ComputerBackupLocation=NETWORK|AUTO|NONE

• NETWORK hace una copia de seguridad en la red.

• AUTO hace una copia de seguridad local si hay suficiente espacio en disco, en caso
contrario la realiza en la red.
• NONE no hace ninguna copia de seguridad.

Si desea realizar una copia de seguridad sobre la red, es preciso utilizar estas dos variables:

• BackupShare=\\DC2012\Backup$
• BackupDir=%ComputerName%

Para que funcione la copia de seguridad, es preciso asignar los siguientes permisos en el
recurso compartido utilizado:

• Objeto equipos y usuarios de dominio con permisos de creación de carpetas y

agregación de datos.
• Propietario con permisos de control total

SkipComputerName: no solicitar el nombre de equipo.

• Automatizar mediante ComputerName=%SerialNumber% , por ejemplo.

SkipDeploymentType: no solicitar el tipo de despliegue.

• Automatizar mediante DeploymentType=NEWCOMPUTER. Puede tomar los

valores NEWCOMPUTER, REFRESH, REPLACE, UPGRADE
SkipDomainMembership: omitir la opción de unir el equipo a un dominio.

• Automatizar mediante JoinDomain=MIEMPRESA. Las variables adicionales son:

• MachineObjectOU=OU=Mis_Servidores,DC=miempresa,DC=priv
• DomainAdmin=Administrador
• DomainAdminDomain=MIEMPRESA
• DomainAdminPassword=contraseñacompleja

Dado que la contraseña se almacena sin encriptar, debería utilizar una cuenta que sólo tenga
permisos para incluir equipos en el dominio.

SkipFinalSummary: omitir la ventana final de resumen de la secuencia.

SkipLocaleSelection: omitir la elección de parámetros regionales.

• Automatizar mediante:

KeyboardLocale=es-ES (incluir también esta variable en bootstrap.ini para tener el teclado

configurado en español durante la instalación).

UserLocale=es-ES y UILanguage=es-ES

SkipPackageDisplay: omitir la opción de realizar un paquete complementario.

SkipProductKey: no solicitar el número de serie.

SkipSummary: omitir el resumen.

SkipTimeZone: no solicitar la zona horaria.

• Automatizar mediante TimeZoneName=’’TimeZoneName=Romance

StandardTime’’.

SkipUserData: omitir la opción de realizar una copia de seguridad de los perfiles de

usuario.

• Automatizar mediante UserDataLocation=NETWORK|AUTO|NONE.

• NETWORK hace una copia de seguridad en la red.

• AUTO hace una copia de seguridad local si hay suficiente espacio en disco, en caso
contrario la realiza en la red.
• NONE no hace ninguna copia de seguridad.
Si desea realizar una copia de seguridad sobre la red, es preciso utilizar estas dos variables:

• UDShare=\\DC2012\Profiles$
• UDDir=%ComputerName%

Por último, para informa la cuenta que se utilizará para acceder al recurso compartido que
contiene los recursos MDT:

USERID=Administrador
UserPassword=contraseñacompleja
UserDomain=MIEMPRESA

Su archivo CustomSettings.ini podría tener el siguiente aspecto:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipBDDWelcome= YES
SkipCapture=YES
SkipAppsOnUpgrade=YES
SkipFinalSummary=YES
SkipPackageDisplay= YES
SkipProductKey=YES
SkipSummary=YES
USERID=Administrador
UserPassword=contraseñacompleja
UserDomain=MIEMPRESA

SkipComputerBackup=YES
ComputerBackupLocation= NONE

SkipAdminPassword=YES
AdminPassword=micontraseñadeadministradorlocal

SkipApplications=YES
Applications001={73823faf-bb78-4491-a053-b47afb5553c4}

SkipTaskSequence=YES
TaskSequenceID= 001

SkipComputerName=YES
ComputerName=%SerialNumber%

SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER

SkipDomainMembership=YES
JoinDomain=MIEMPRESA
MachineObjectOU=OU=Mis_Servidores,DC=miempresa,DC=priv
DomainAdmin=Administrador
DomainAdminDomain=MIEMPRESA
DomainAdminPassword=contraseñacompleja

SkipLocaleSelection=YES
KeyboardLocale=es-ES
UserLocale=es-ES
UILanguage=es-ES

SkipTimeZone=YES
TimeZoneName=Romance Standard Time"

SkipUserData=YES
UserDataLocation=NONE
DeployRoot=\\DC2012\DeploymentShare$

La integración con WSUS está prevista en MDT.

Por defecto, la máquina intentará conectarse a los servidores Microsoft Windows Update en
Internet. Si tiene un servidor WSUS, puede indicárselo a MDT agregando la variable
WSUSServer=http://miservidor en el archivo Custom- Settings.ini. Si especifica un
servidor WSUS pero el cliente no está actualizado, MDT intentará descargarlo desde
Internet.

Sólo queda activar las dos etapas de Windows Update en la secuencia (Pre y Post), pues
están desactivadas por defecto:
Otro enfoque consiste en desplegar totalmente un equipo, configurarlo completamente
instalando por ejemplo las aplicaciones y las actualizaciones, y a continuación capturarlo
con Lite Touch. Ésta será su imagen de referencia, que le bastará para desplegar haciendo
un sysprep. Sysprep permite hacer único un equipo, en lo que respecta a su nombre y su
SID (Security IDentifier). Por este motivo no puede asociarlo a un dominio Active
Directory durante la fase de captura. La fase de sysprep se incluye automáticamente en
MDT (fase Copy sysprep files). Un aspecto que requiere especial atención durante una
captura con Lite Touch es el uso del antivirus, que puede presentar problemas.

La migración de perfiles de usuario se realiza mediante el componente USMT (User State

Migration Tool). No es necesario instalarlo en el servidor de despliegue. USMT 5.0 incluye
WADK 1.0.

MDT ofrece la posibilidad de inventariar todas las máquinas desplegadas en una base de
datos SQL Server. Si lo desea, puede utilizar una base de datos SQL Express 2012. Esta
versión de SQL Server es gratuita y basta para cubrir esta necesidad. Puede
descargarla desde la página Web de Microsoft: http://www.microsoft.com/es-
es/download/details.aspx?id=29062
3. WDS

La instalación del rol WDS es muy sencilla. Como requisito previo debe disponer de los
servicios DNS y DHCP sobre la red, así como una partición NTFS para el almacenamiento.
Para instalar el rol puede utilizar el Administrador del servidor o hacerlo directamente
mediante el cmdlet PowerShell siguiente:

Install-WindowsFeature -Name WDS -IncludeAllSubFeature

-IncludeManagementTools

Se instalan tres componentes:

• Servidor de despliegue: se trata del componente principal.

• Servidor de transporte: este componente puede instalarse solo en un entorno
restringido (sin Active Directory, DHCP, DNS...). También lo utiliza el componente
principal.
• Herramientas de los servicios de despliegue de Windows: componentes de
administración.

Una vez instalado el rol, puede gestionar WDS mediante PowerShell o mediante la interfaz
de gestión que se encuentra en el menú de inicio de Windows, Servicios de
implementación de Windows. Despliegue el árbol hasta llegar a su servidor y seleccione
Configurar el servidor. Seleccione, a continuación, una carpeta para almacenar las
imágenes (%systemdrive%\RemoteInstall, por defecto). El volumen de esta carpeta
puede llegar a ser importante, y aparece una alerta si se está utilizando la partición de
sistema. Si es necesario, es posible reducir en caliente el volumen desde el administrador de
discos, para disponer de un lector dedicado a este almacenamiento.

WDS puede restringirse para responder únicamente a clientes conocidos. Para que un
cliente sea conocido, es preciso que esté incluido en el Active Directory previamente, o que
se haya creado un objeto equipo manualmente en Active Directory con el identificador
correcto. El identificador utilizado se visualiza durante el arranque del equipo cliente, en el
momento de la búsqueda de PXE (GUID). También es posible tener un modo de
aprobación, donde el administrador visualiza las peticiones de los clientes desconocidos en
espera.
El modo multicast es el mejor adaptado para realizar un despliegue masivo. Evita el tener
que inundar la red enviando todos los bytes de forma individual a cada equipo. En su lugar,
los equipos se inscriben en la dirección multicast, y WDS envía los datos una sola vez a
esta dirección para todos los equipos. Tratándose de multicast IGMP, es necesario que sus
equipos de red soporten esta característica. Si no es el caso, el switch las procesará como
difusiones, e inundará toda la red.

Si llegan nuevos equipos durante el despliegue, comenzarán a recuperar los datos enviados
hasta el final y, a continuación, WDS enviará los datos restantes a estos equipos, que serán
capaces de recibir los datos de forma desordenada. Además del ahorro en ancho de banda,
el servidor será capaz de desplegar más máquinas a la vez puesto que sólo lee una vez los
datos de despliegue. Esto reduce de forma importante los accesos al almacenamiento en
disco. Es posible visualizar la lista de máquinas en curso de despliegue así como su
consumo de red en la consola WDS:

En Windows 2008 (y no 2008 R2), la velocidad de despliegue del conjunto de máquinas es

igual a la velocidad de despliegue de la máquina más lenta. Si, por ejemplo, todas las
máquinas son rápidas salvo una, esto impedirá a las demás desplegarse más deprisa. El
servidor transmite los paquetes de red una única vez, y por ello debe esperar a que estén
todas listas para recibir el próximo paquete. En la ventana que se muestra a continuación, la
columna Velocidad de transferencia permite determinar la velocidad de cada máquina
durante el despliegue. Si una máquina es claramente más lenta que las demás, puede
cambiar su modo de despliegue por compartición de archivo, para que no ralentice a las
demás.

Para ello, basta con hacer clic con el botón derecho en la máquina y seleccionar la
opción Ignorar multidifusión:
En cambio, Windows Server 2012 R2 permite clasificar automáticamente en dos o tres
categorías los equipos (rápido, medio, lento). El servidor tendrá, al final, que enviar 2 ó 3
veces los datos, pero esto permitirá realizar un despliegue de equipos más rápido.

La transmisión por multidifusión, creada por defecto por MDT 2013, es de tipo automático.
Es decir el despliegue comienza cuando un cliente solicita una multidifusión. WDS permite
no obstante también realizar una multidifusión planificada. Esta planificación puede
realizarse en base a dos criterios:

• el número de clientes en espera de un despliegue;

• una fecha y una hora para lanzar el despliegue.
Es posible utilizar ambos criterios al mismo tiempo. Si no está seleccionado ninguno de los
dos, será preciso iniciar la multidifusión de forma manual. Incluso si se trata de un
despliegue planificado, también es posible realizar un arranque manual.

A diferencia de la versión anterior de WDS, que necesitaba la copia completa de la imagen

WIN o VHD en el puesto cliente antes de instalarla realmente durante un despliegue, la
versión WDS de Windows Server 2012 R2 permite instalarla directamente durante la
difusión de la imagen. Esto permite, en particular, acelerar el despliegue y la instalación
limitando el espacio en disco necesario en el puesto cliente.

WDS es compatible con la multidifusión IPv4, y también con IPv6; para ello tendrá,
obligatoriamente, que configurar el servicio DHCPv6.

Con la versión WDS de Windows Server 2012 R2, las BIOS de tipo UEFI (Unified
Extensible Firmware Interface) de los puestos clientes de 32 bits se gestionan para su
arranque en red (Boot on LAN) y para el despliegue.

Además de con las arquitecturas x86 y x64, WDS es compatible, también, con las
arquitecturas ARM para Windows RT (versión de Windows 8 para tabletas con
procesadores ARM).
Con Windows Server 2012, WDS es compatible con imágenes con los formatos .WIM,
.VHD y .VHDX para el despliegue.

Fuera del marco de uso de MDT, WDS para Windows Server 2012 permite:

• Administrar controladores para imágenes Windows 7, Windows 8, Windows 8.1,

Windows Server 2008 R2, Windows Server 2012 y Windows Server 2012 R2.
• Arrancar directamente sobre imágenes VHD o VHDX.

Puede, también, gestionar WDS mediante cmdlets PowerShell. La lista de cmdlets

PowerShell para WDS está disponible en el sitio Technet en la siguiente dirección:
http://technet.microsoft.com/library/dn283416.aspx

Para ir más allá...

El despliegue de sus servidores constituye el primer bloque técnico. A continuación queda
por automatizar la instalación de sus aplicaciones, tarea que puede revelarse larga y
complicada. La virtualización crea una nueva necesidad: el despliegue a la carta de
entornos. Ya no se trata de realizar una configuración manual en este contexto.

1. Microsoft Application Compatibility Toolkit

Esta herramienta le va a permitir resolver incompatibilidades no sólo con Windows Server

2012 R2 y Windows 8.1, sino también con Windows Vista, Windows 7, Windows 8,
Windows Server 2008, Windows Server 2008 R2 y Windows Server 2012. Las
incompatibilidades se clasifican, generalmente, en:

• Elevación de privilegios (UAC).

• Intentos de escribir en %ProgramFiles%.

Para descargarla gratuitamente, visite la página: http://www.microsoft.com/en-

us/download/details.aspx?id=7352

Si no puede modificar la aplicación, siempre podrá implementar shims para modificar al

vuelo las llamadas que causen problemas durante la ejecución. La palabra shim designa una
biblioteca que convierte la llamada de una API en otra. El programa Compatibility
Administrator permite visualizar los shims utilizados por Microsoft para hacer
compatibles hasta 348 aplicaciones. Para conseguirlo, hay disponibles 118 shims.

Agregando el argumento -x al siguiente programa, existen 242 shims disponibles. Por

defecto, están ocultas, pues raramente son necesarias. También es posible "hacer creer" a la
aplicación que el sistema operativo es Windows XP, o que Internet Explorer 6 está
presente. Los desarrolladores tienen tendencia a realizar verificaciones bloqueantes para
estar seguros de que no habrá ningún problema, mientras que la mayoría de veces no existe
ninguna incompatibilidad probada. Una vez la aplicación es compatible con Windows 8.1 o
Windows Server 2012 R2, habrá que instalar la base de datos sobre las máquinas que la
utilicen.

Para facilitar el diagnóstico, el programa Standard User Analyzer Wizard le guía paso a
paso en:

• La preparación antes de la ejecución.

• La ejecución de la aplicación, realizando todas las acciones que presenten
problemas.
• El análisis y la propuesta de shims.

2. Entorno a la carta

El despliegue de máquinas virtuales puede consumir mucho tiempo, especialmente si se

trata de entornos a la carta para proyectos de desarrollo.

Podrá crear una secuencia para sus entornos virtuales con el objetivo de instalar
automáticamente las herramientas adicionales. Hyper-V, que es compatible con el arranque
PXE, le permite instalar máquinas virtuales directamente a través de la red con WDS. De
este modo tendrá un único punto central que contendrá todas las imágenes y aplicaciones
durante el despliegue, en vez de tener una imagen a parte para la generación de máquinas
virtuales.

3. ImageX

ImageX es una herramienta que funciona por línea de comandos y le permite administrar y
modificar las imágenes WIM. El formato WIM tiene en particular una propiedad
interesante: se basa en archivos y no en clústeres, como para los formatos ISO. Esto
permite en especial almacenar en la imagen un único ejemplar de cada archivo, incluso si
está presente varias veces desde el punto de vista lógico (Single Instance Storage).

Esta herramienta acepta los siguientes argumentos:

• APPEND: combina dos imágenes.

• APPLY: aplica una imagen a una carpeta.
• CAPTURE: captura una partición en una imagen wim.
• DELETE: borra un volumen en un archivo wim.
• DIR: enumera los archivos contenidos en un archivo wim.
• EXPORT: copia un volumen desde un archivo wim a otro.
• INFO: muestra la descripción XML de un archivo wim.
• SPLIT: separa un archivo wim en dos archivos wim separados.
• MOUNT: monta un archivo wim en una carpeta, en modo sólo lectura.
• MOUNTRW: monta un archivo wim en una carpeta, en modo lectura/escritura.
• UNMOUNT: desmonta un archivo wim de una carpeta.

Esta herramienta es útil si desea modificar la imagen generada por MDT.

Por ejemplo, para montar la imagen WIM Lite Touch en una carpeta, es necesario ejecutar
el comando: imagex /mount D:\images\LiteTouchPE_x64.wim 1 c:\wim_temp

El ejecutable ImageX se encuentra en distintos lugares:

• En la carpeta Deployment Tools\amd64\DISM del directorio de instalación de

Windows ADK.
• En la carpeta Tools\PeTools del directorio de instalación de Windows AIK.
• En X:\Deploy\Tools\x86 o X:\Deploy\Tools\x64 desde el entorno de inicio de
Windows PE construido con MDT.

4. DISM (Deployment Image Servicing and Management)

Esta herramienta, que se ofrece de forma estándar con Windows 8.1 y Windows 2012 R2,
aunque también con Windows PE 4.1, combina las funciones antes mencionadas:

• Montaje de archivos WIM.

• Personalización de imágenes de inicio de Windows PE.
• Inyección/supresión de controladores.
• Activación/desactivación de componentes de Windows.
• Administración de la configuración regional.
Es una herramienta complementaria a ImageX que permite configurar la imagen. Su único
punto en común es poder montar imágenes WIM.

5. Zero touch con SCCM 2012 R2

El uso de System Center Configuration Manager R2 permite automatizar por completo el

despliegue de equipos. Desde la consola SCCM, usted podrá programar directamente y
efectuar despliegues sobre equipos existentes, sin tener que desplazarse hasta la máquina
para arrancar en PXE y seleccionar la secuencia.

6. Unirse al dominio sin red

Desde Windows 7 y Windows Server 2008 R2, es posible unir una máquina a un dominio
AD sin que tenga que unirse a un controlador de dominio durante todo el procedimiento.
Esto abre nuevas perspectivas, como hemos visto en el capítulo dedicado al Dominio
Active Directory:

• Desplegar máquinas virtuales o no en gran cantidad, evitando el reinicio.

• Unir una máquina al dominio aunque no tenga red en ese momento.
• Simplificar el procedimiento cuando el controlador de dominio es de tipo RODC.
• Limitar los contratiempos y mejorar el diagnóstico cuando se produce un error o
incidente de red durante un despliegue.

El procedimiento se desarrolla en dos tiempos:

• Preparar el Active Directory inicializando el objeto equipo con el comando djoin.

El resultado es un archivo de texto que hay que conservar (testigo).
• Inyectar el archivo anterior en el equipo de destino con djoin. Es posible copiar el
archivo mientras la máquina está detenida. Durante el arranque, será miembro del
dominio sin necesidad de un reinicio posterior.

El comando que debe utilizar es djoin. Necesita, como mínimo, Windows 7 o Windows
Server 2008 R2 instalado en el equipo que prepara el Active Directory y sobre la máquina
que se va a unir al dominio sin red. El controlador de dominio puede estar configurado con
alguna versión anterior a Windows Server 2008 R2 (utilizando el argumento /downlevel de
djoin).

He aquí el comando que permite preparar el equipo SRV01:

He aquí el comando que permite unir la máquina al dominio:

7. ¿Qué hacer si ocurre algún problema?

La informática está llena de sorpresas que condimentan nuestro trabajo cotidiano. Cuando
un despliegue no se realiza según lo previsto, he aquí algunas trazas que pueden
proporcionarle ayuda:

• Si ocurre un problema uniendo el equipo al dominio:

%WINDIR%\Debug\netsetup.log
• Si ocurre un problema con algún controlador: %WINDIR%\inf\Setupapi.dev.log
• Si ocurre un problema durante la instalación: %WINDIR%\panther\Setupact.log y
Setuperr.log
• Mensaje de error "Multiple connections to a server or shared resource by the same
user":

Este mensaje aparece cuando una secuencia utiliza una cuenta para conectarse a un
recurso compartido MDT diferente del definido en customsettings.ini. El equipo de
producto de MDT provee, en su blog, las modificaciones que es necesario realizar
(ztiutility.vbs): http://blogs.technet.com/msdeployment/archive/2009/09/18/fix-for-
multiple-connections-to-a-server-or-shared-resource-by-the-same-user-using-more-
than-one-user-name-are-not-allowed-problem-with-mdt-2010.aspx
Conclusión
Ya está preparado para desplegar sus servidores y puestos de trabajo. Desde un punto de
vista técnico, nunca había sido tan sencillo y flexible, en especial con MDT 2013. ¡Seguir
haciendo instalaciones a mano sería una verdadera pérdida de tiempo y de calidad!

Introducción
Este capítulo tiene como objetivo permitir abordar la seguridad de su arquitectura de la
mejor forma. En efecto, no es raro escuchar a los profesionales de la informática expresarse
en términos algo arcaicos acerca de la seguridad. Se trata de un área que evoluciona muy
regularmente y muy rápido, y no sería razonable pensar que la arquitectura informática y
las soluciones en términos de seguridad están actualizadas. Conviene estar informado
regularmente y respetar un conjunto de buenas prácticas.

Este capítulo está dedicado a describir las buenas prácticas al respecto y le presenta las
novedades funcionales que le permitirán ponerlas en marcha.

Principio de privilegio mínimo

El principio de privilegio mínimo es, como su propio nombre indica, un principio que
consiste en ejecutar cada tarea con una cuenta de usuario que tenga exactamente los
permisos necesarios para completar dicha tarea.

En la práctica, esto no siempre es factible, aunque conviene hacer siempre todo lo posible
para estar lo más cerca posible de la necesidad reduciendo al máximo la superficie de
ataque expuesta. Si un usuario no necesita permisos específicos, ¿por qué asignárselos? Y,
¿cómo asegurarse que el usuario no tiene más derechos de los que le hacen falta?

La superficie de ataque será mucho más reducida si actualiza, de manera regular, su parque
informático tanto a nivel de sistema operativo como de aplicaciones instaladas, sin olvidar a
los equipos de red. El capítulo El ciclo de vida de su infraestructura aborda, en particular, el
uso de WSUS (Windows Server Update Services) para desplegar actualizaciones en sus
sistemas Windows.

Un parque informático actualizado regularmente, con permisos de usuario bien definidos, le

protegerá de numerosos ataques.

Es preciso dominar algunas nociones técnicas para poder realizar la mejor elección en cada
caso.
1. Los distintos tipos de cuenta

En Windows existen distintos tipos de cuentas de usuario. Cada uno de ellos define un
conjunto de permisos tales como el acceso a los archivos, las modificaciones que está
autorizado a realizar en el sistema operativo, etc. Desde un punto de vista genérico, según
el tipo de cuenta seleccionado, el usuario tendrá un nivel de acceso más o menos importante
en el sistema operativo.

Existen tres categorías principales de cuenta de usuario:

• Invitado
• Estándar
• Administrador

Cuenta de usuario invitado

Una cuenta de usuario con permisos de tipo Invitado autoriza el acceso a los recursos del
equipo sin autenticación en este último. Este tipo de cuenta se utiliza de manera muy
esporádica en la empresa, pues presenta riesgos no despreciables en términos de seguridad.
Por defecto, este tipo de cuenta está deshabilitado.

Cuenta de usuario estándar

Una cuenta de usuario estándar permite utilizar la mayor parte de las funcionalidades del
sistema operativo mientras no afecten a la seguridad del equipo o a la configuración común
a todos los usuarios.

La principal diferencia entre una cuenta de usuario estándar y una cuenta de administrador
es el nivel de acceso del usuario a los lugares definidos como protegidos en el sistema
operativo.

Cuenta de administrador

Una cuenta de usuario con permisos de Administrador (y que por lo tanto forme parte, de
forma directa o no, del grupo Builtin\Administradores del equipo) está autorizado a
administrar la totalidad del sistema operativo y, por tanto, a definir configuración común a
todos los usuarios (instalación de programas, definición de la seguridad del equipo, etc.).

En la medida en que los permisos de esta cuenta son muy extensos, se desaconseja
encarecidamente utilizarla para sus tareas corrientes. Verá más adelante, en este mismo
capítulo, cómo Microsoft responde a la necesidad de dotar de seguridad este acceso de
Administrador gracias al UAC (User Account Control).

Por ejemplo, un usuario estándar no puede, por defecto, escribir en la carpeta de sistema
(C:\windows) o en la mayor parte del registro, mientras que un administrador sí puede
hacerlo. Un administrador puede también activar/desactivar el firewall, configurar las
políticas de seguridad, instalar un servicio o un controlador para todos los usuarios, etc.

Desde Windows Vista y Windows 2008, Microsoft ha mejorado bastante las cuentas de
usuario estándar, y ahora pueden realizar tareas que necesitan permisos de administrador
tales como:

• Ver el reloj de sistema, el calendario y modificar el huso horario.

• Modificar los parámetros de visualización y las fuentes instaladas.
• Modificar las opciones de alimentación.
• Agregar impresoras y otros dispositivos.
• Agregar y configurar conexiones VPN.
• Definir una clave WEP/WPA para una red inalámbrica.

Existen tareas programadas suplementarias que permiten, en lo sucesivo, definir una tarea
de defragmentación o de copia de seguridad automática. Antes, estas funcionalidades no
podían realizarse fácilmente y necesitaban, en su mayoría, privilegios de usuario
administrador.

He aquí una lista no exhaustiva de los distintos permisos para un usuario estándar y un
administrador, que le permitirá situar un poco mejor las autorizaciones de cada tipo de
cuenta.

Usuarios estándar Administradores

Establecer una conexión de red. Instalar/desinstalar aplicaciones.
Establecer una conexión de red Instalar el controlador de un dispositivo.
inalámbrica.
Cambiar la configuración de pantalla. Instalar actualizaciones de Windows.
Defragmentar el disco duro (mediante Configurar el control parental.
un servicio).
Leer un CD/DVD. Instalar un control ActiveX (incluso si ha
evolucionado poco con la presencia del
servicio de Control ActiveX desde
Windows 7).
Grabar un CD/DVD. Configurar el firewall.
Modificar el fondo de pantalla. Modificar el tipo de cuenta de un
usuario.
Acceder a la fecha y hora del sistema y Modificar los parámetros UAC.
modificar el huso horario.
Utilizar el escritorio remoto para Configurar el acceso al escritorio remoto.
conectarse a equipos remotos.
Configurar las opciones de Crear o eliminar una cuenta de usuario.
alimentación de la batería.
Configurar las opciones de Copiar o mover archivos en las carpetas
accesibilidad. Program Files o Windows.
Restaurar los archivos de copia de Definir tareas programadas.
seguridad de usuario.
Definir una sincronización entre un Restaurar la copia de seguridad de
dispositivo portátil y el equipo archivos de sistema.
(smartphone, ordenador portátil, PDA
(Personal Digital Assistant).
Conectar y configurar un dispositivo Configurar el servicio de actualizaciones
Bluetooth. automáticas.

Existe un cuarto tipo de cuenta que se utiliza a menudo en entornos como Windows
2000/XP. Se trata de cuentas que pertenecen al grupo de Usuarios avanzados. Este grupo
está a medio camino entre Usuarios y Administradores. Permite, en efecto, realizar algunas
tareas como, por ejemplo, escribir en ciertos lugares del registro y del sistema de archivos,
sin necesidad de tener permisos de administrador. Este tipo de grupo no responde a todas
las necesidades de las aplicaciones y ya no tiene ningún permiso particular por defecto
desde Windows Vista y Windows 7. Conviene saber, no obstante, que este grupo sigue
estando disponible con el objetivo de asegurar la compatibilidad de las aplicaciones que lo
necesitan. Para ello, es necesario cargar un modelo de seguridad particular (compatws.inf)
en Windows Vista y Windows 7 para modificar los permisos sobre ciertos archivos y
ciertas claves del registro para permitir al grupo Usuarios avanzados tener acceso.

Windows Server 2012 R2 propone utilizar un nuevo grupo de dominio que permite
habilitar una protección suplementaria en aquellos equipos que utilizan Windows Server
2012 R2 o Windows 8.1. Este grupo se encuentra en los controladores de dominio de
Windows Server 2012 R2 y se llama Protected Users.

Los miembros de este grupo sólo pueden utilizar métodos de autenticación considerados
como seguros para poder autenticarse. De este modo, los miembros de este grupo están
sometidos a las siguientes condiciones:

• No pueden autenticarse utilizando NTLM, Digest o incluso CredSSP. Por otro lado,
las contraseñas de las cuentas miembros de este grupo no están almacenadas en
caché si se utilizan en un equipo Windows 8.1 miembro del dominio.
• El protocolo Kerberos es el único protocolo autorizado y no puede basarse en un
cifrado DES o RC4 (débiles) para el proceso de pre-autenticación. Sólo es posible
utilizar el protocolo AES.
• La delegación Kerberos no está permitida.
• El tiempo de vida del ticket Kerberos (TGT) se puede modificar (por defecto, 4
horas) e implica una reautenticación por parte del usuario, pasado este tiempo.

Para poder aprovechar las ventajas de este grupo, debe actualizar su esquema de
Active Directory (mediante el comando adprep /forestprep), de cara a poder soportar las
nuevas clases incluidas en Windows Server 2012 R2 y el controlador de dominio que
alberga el rol de emulador PDC debe funcionar, como mínimo, con Windows Server 2012
R2.

Existe una novedad, llamada Directiva de silos de autenticación que le permite controlar
los equipos en los que un usuario puede iniciar sesión en el dominio. Si se acopla esta
funcionalidad con el grupo de tipo Protected Users, es posible aplicar condiciones de
control del acceso para la autenticación de cuentas. Las directivas de autenticación se
fuerzan en la etapa de intercambio de información de AS y TGT de los tickets Kerberos.

Los requisitos previos son los mismos que para los Protected Users, es preciso agregar un
nivel funcional del dominio Windows Server 2012 R2.

Esta directiva puede aplicarse a las cuentas de Equipos, Usuarios y a las cuentas de servicio
administradas.

2. El control de cuentas de usuario

El control de cuentas de usuario o User Account Control (UAC) es uno de los principales
avances de la nueva gama de sistemas operativos Microsoft Windows Vista y Windows
Server 2008.

Esta funcionalidad (activada, por defecto) permite informarle de cualquier acción que
requiera permisos del sistema. Se crea un token de acceso completo, con los permisos más
importantes del usuario, y se le pasa a la aplicación. Esto se llama una elevación de
privilegios. El UAC se caracteriza por una elevación de privilegios automática, apareciendo
un mensaje de advertencia cuando se produce esta elevación, y un escritorio securizado
dedicado a este mensaje de advertencia.

De este modo, será mucho más complicado para un programa espía instalarse en el sistema
o acoplarse a un proceso sin informarle antes.

En adelante, es sencillo identificar aquellas tareas que precisarán permisos más

importantes. El icono con forma de escudo asociado a ciertas aplicaciones y asistentes de
configuración indica que estas tareas se ejecutarán con permisos de administrador del
equipo.

Para las demás aplicaciones, aparecerá un mensaje de elevación de privilegios si fuera

necesario.

Observe que la visualización de la ventana de elevación de privilegios aparece con menos

frecuencia desde Windows 7/2008 R2, en particular tareas "seguras" tales como la
instalación de actualizaciones o de controladores descargados desde Windows Update, la
visualización de la configuración de Windows o incluso las herramientas de diagnóstico de
la tarjeta de red.

Antes de que realizar la elevación de privilegios, Windows Server 2012 R2 muestra, por
defecto, la ventana de confirmación solicitando esta elevación de privilegios a un escritorio
virtual aislado (llamado también "Escritorio difuminado" desde Windows 7/2008 R2) y
securizado, de forma que el resto de aplicaciones continúe ejecutándose a nivel del
escritorio interactivo del usuario. Esto permite poder impedir a un proceso de usuario
(como, por ejemplo, una aplicación espía) interactuar con la solicitud de elevación de
privilegios y aceptar automáticamente la elevación.

La ventana de petición de elevación para el proceso en cuestión se encuentra por tanto en

un entorno hermético. De este modo, si un atacante elige crear un ejecutable que permite
reproducir con exactitud la ventana de elevación de privilegios, no la ejecutará porque su
visualización no se realizará en un escritorio virtual. Del mismo modo, el escritorio
securizado impide los ataques que consisten en trucar la posición del puntero del ratón. El
atacante puede en efecto modificar la visualización del ratón de modo que cuando el
usuario piensa que está haciendo clic en Cancelar, la acción del clic del ratón se realiza
sobre el botón Continuar permitiendo así ejecutar la aplicación peligrosa. El escritorio
virtual permite bloquear este tipo de ataque.

Por otro lado, existe un modo particular llamado Modo de aprobación de administrador
que está activo para todos los miembros del grupo de Administradores (salvo la cuenta
Administrador integrado). Este modo muestra la elevación de privilegios cuando se ejecuta
una aplicación que necesita privilegios de administración.

Desde Windows Server 2008 R2, es posible tener una granularidad más precisa del UAC
para limitar las peticiones de la contraseña. Esto se detalla más adelante.

Es posible configurar los distintos parámetros en el Panel de control o mediante una

directiva de grupo (también local o de dominio). Para ello, abra su editor de directivas, y
diríjase al nivel Configuración del equipo - Directivas - Configuración de Windows -
Configuración de seguridad - Directivas locales - Opciones de seguridad.

Las directivas relativas a la gestión del UAC son las siguientes:

Control de cuentas de usuario: modo de aprobación de administrador para la cuenta

predefinida Administrador

Descripción: permite definir si la cuenta de Administrador integrada se somete al Modo de

aprobación de administrador o no.

Valor por defecto: Deshabilitado.

Control de cuentas de usuario: cambiar al escritorio seguro cuando se pida
confirmación de elevación

Descripción: indica si la petición de elevación de privilegios debe realizarse en el escritorio

de los usuarios interactivos o en un escritorio virtual securizado.

Valor por defecto: Habilitado.

Control de cuentas de usuario: permitir que las aplicaciones UIAccess soliciten la

elevación sin usar el escritorio seguro

Descripción: los programas UIAccess como el asistente remoto pueden solicitar utilizar
esta opción.

Valor por defecto: Deshabilitado.

Control de cuentas de usuario: comportamiento de la petición de elevación para los

administradores en Modo de aprobación de administrador

Descripción: define a si un usuario conectado con una cuenta de administrador se le

muestra una ventana de elevación de privilegios durante la ejecución de aplicaciones que
requieran permisos de administrador.

Existen seis opciones posibles:

• Elevar sin preguntar: la elevación se produce automáticamente y de forma

silenciosa (sería inútil indicarle que esta opción no está recomendada).
• Pedir consentimiento: requiere una intervención del usuario para Continuar o
Anular la operación de elevación de privilegios.
• Pedir credenciales: se solicita un nombre de usuario y una contraseña durante la
petición de elevación de privilegios.

Valor por defecto: Pedir consentimiento.

• Pedir consentimiento en el escritorio seguro: requiere una intervención del

usuario en el escritorio securizado para Continuar o Anular la operación de
elevación de privilegios.
• Pedir credenciales en el escritorio seguro: se solicita un nombre de usuario y una
contraseña en el escritorio securizado durante la elevación de privilegios.
• Pedir consentimiento para ejecutables que no son de Windows: requiere una
intervención del usuario para Continuar o Anular la operación de elevación de
privilegios para una aplicación no firmada por un certificado de Microsoft.

Valor por defecto: Pedir consentimiento para ejecutables que no son de Windows.
Control de cuentas de usuario: comportamiento de la petición de elevación para los
usuarios estándar

Descripción: define si un usuario conectado con una cuenta estándar obtiene una ventana de
elevación de privilegios de ejecución de aplicaciones que requieren permisos de
administrador.

Por defecto, un usuario estándar tendrá la posibilidad de indicar la contraseña de una cuenta
de administrador. También es posible deshabilitar esta opción, aunque no impide al usuario
hacer clic con el botón derecho del ratón sobre el ejecutable y seleccionar la opción
Ejecutar como administrador.

Valor por defecto: Pedir credenciales.

Control de cuentas de usuario: detectar instalaciones de aplicaciones y pedir

confirmación de elevación

Descripción: cuando está habilitado, el usuario debe dar su consentimiento cuando

Windows detecta un programa de instalación. No se aconseja aplicar este parámetro en
entornos de empresa si el usuario no tiene permisos de administrador o si ya existe una
aplicación para la distribución remota.

Valor por defecto: Habilitado.

Control de cuentas de usuario: elevar sólo aplicaciones UIAccess instaladas en

ubicaciones seguras

Descripción: indica que sólo las aplicaciones que requieran un nivel de integridad UIAccess
(es decir especificando UIAccess=true en su manifiesto de aplicación) deben encontrarse en
un emplazamiento seguro en el sistema de archivos. Los emplazamientos seguros son:

• \Program Files\ (y subcarpetas)

• \Program Files (x86)\ (y subcarpetas)
• \Windows\System32

Valor por defecto: Habilitado.

Control de cuentas de usuario: elevar sólo los archivos ejecutables firmados y

validados

Descripción: sólo los ejecutables firmados y validados mediante un certificado tendrán la

autorización para elevar sus privilegios. La lista de aplicaciones de administración puede
controlarse por este medio.

Valor por defecto: Deshabilitado.

Control de cuentas de usuario: ejecutar todos los administradores en Modo de
aprobación de administrador

Descripción: permite activar o desactivar el control de usuario para los usuarios que son
Administradores.

Valor por defecto: Habilitado.

Control de cuentas de usuario: virtualizar los errores de archivo y escritura de

Registro por ubicaciones de usuario

Descripción: esta opción asegura la compatibilidad con las antiguas aplicaciones que se
ejecutaban como administrador y escribían sus datos de ejecución de la aplicación en
%Program Files%, %Windir%, %Windir%\System32 o HKLM\Software.

Valor por defecto: Habilitado.

Si utiliza una autenticación biométrica, sepa que Windows Server 2008 R2/2012 R2
permite simplificar la elevación de privilegios solicitada por el UAC mejorando la
experiencia de usuario.

Su dispositivo biométrico estará mejor gestionado en Windows Server 2008 R2/2012 que
en las versiones anteriores y podrá utilizar este medio de autenticación sin tener que
disponer necesariamente de una aplicación dedicada instalada a partir del momento en que
el driver descargado mediante Windows Update haya sido instalado.

Aunque es una fuente frecuente de controversia, pues modifica nuestros (¿malos?) hábitos,
UAC permite asegurar un nivel de seguridad muy superior comparado con las versiones
anteriores de Windows. Sus mejoras, evidentes deberían, en lo sucesivo, animarle a
adoptarlo rápidamente, si no lo ha hecho aún.

3. Administrar grupos con ayuda de grupos restringidos

Los grupos restringidos le permiten administrar los miembros de grupos de seguridad con
el objetivo de asegurar el contenido de estos grupos. Esta configuración es muy interesante
y permite controlar mejor las personas y permisos asignados a un conjunto de equipos y
servidores miembros.

Los grupos restringidos se configuran únicamente a nivel de directivas de dominio. No

encontrará esta configuración en el nivel de una directiva local. Se encuentra en
Configuración del Equipo - Directivas - Configuración de Windows - Configuración
de seguridad - Grupos restringidos.
La principal ventaja, como habrá comprendido, consiste en bloquear los miembros
definidos a nivel de Miembro y Miembros de... del grupo definido como grupo
restringido. De este modo, si por ejemplo se retira manualmente a un usuario de un grupo
definido como grupo restringido, se agregará automáticamente a éste tras la aplicación de la
directiva de grupo (cada 90 minutos aproximadamente).

Antes de configurar un grupo restringido, conviene comprender bien la diferencia entre el

parámetro Miembro de este grupo y Este grupo es miembro de.

Configurando, por ejemplo desde la directiva de grupo, un grupo restringido como el grupo
local de los equipos llamado BUILTIN Administradores (haciendo clic con el botón
derecho del ratón en la directiva de los grupos restringidos y, a continuación, en Agregar
un grupo - Builtin\Administradores) e indicando un grupo de dominio como, por
ejemplo, MiEmpresa\AdminLocal en Miembros de este grupo, entonces todos los
usuarios del grupo MiEmpresa AdminLocal serán Administradores de los equipos que se
encuentran en el contenedor asociado a la directiva de grupo definida.

¡Perfecto! ¿Está seguro? No tanto...

Imagine que este grupo restringido se define a nivel de los equipos de su Active Directory y
que un usuario necesita ser miembro del grupo Administradores de su equipo (no es raro
que los usuarios de equipos portátiles tengan este tipo de necesidad). Asociándolo al grupo
MiEmpresa\AdminLocal el usuario será, en efecto, miembro del grupo
BUILTIN\Administradores de su equipo, ¡pero también de todos los demás equipos!
Del mismo modo, si trata de agregar este mismo usuario de forma local al grupo
BUILTIN\Administradores de su equipo, la aplicación de la directiva de grupo tendrá como
efecto la limpieza de los miembros de los grupos locales y en consecuencia el usuario
perderá los permisos de administrador.

Como habrá comprendido, este tipo de configuración está poco adaptado a la definición de
los miembros de los grupos a nivel de puestos de trabajo, aunque puede ser muy interesante
para controlar los miembros de los grupos de servidores y controladores de dominio para
bloquear estos últimos.

Volviendo a nuestro usuario que quiere ser administrador de su equipo haciendo uso de los
grupos restringidos, y sin que impacte a la seguridad de los demás equipos, conviene definir
los grupos restringidos de forma ligeramente diferente.

En efecto hace falta definir un grupo restringido a partir del grupo de dominio seleccionado
(en nuestro ejemplo el grupo MiEmpresa\AdminLocal) y definir la configuración Este
grupo es miembro de: para agregar el grupo BUILTIN\Adminis- tradores (o
BUILTIN\Administrators dependiendo de si esta directiva de grupo se define en un equipo
en castellano o en inglés).

De este modo, el grupo MiEmpresa\AdminLocal tiene su atributo IsMemberOf

bloqueado y los usuarios que forman parte de este grupo son efectivamente miembros del
grupo Administradores de todos los equipos aunque esto impida que un usuario equis pueda
ser administrador de su equipo.

La administración de grupos representa, a día de hoy, un verdadero desafío para nuestros

Sistemas de Información y la seguridad, ambos en pleno despegue, los grupos restringidos
responden en gran medida a esta necesidad de dotar de seguridad al puesto de trabajo.

4. AppLocker o el control de las aplicaciones

Applocker es una funcionalidad que ha hecho aparición en Windows 7 (en su edición

Enterprise e Ultimate) y Windows Server 2008 R2 con el objetivo de reemplazar a las
directivas de restricción de aplicaciones de las versiones anteriores de Windows.

Como con las directivas de restricción de software, Applocker permite definir las
aplicaciones autorizadas a ejecutarse por parte de sus usuarios estándar en el seno de su
dominio desplegando sus parámetros mediante directivas de grupo.

El interés principal es limitar la instalación de malwares en los puestos de trabajo pero

también impedir la instalación de programas no conformes o que requieren una licencia que
no posee, etc.

Esta funcionalidad se aplica, principalmente, en puestos cliente con Windows 7/8/8.1

Enterprise, aunque también puede ser interesante auditar y limitar los ejecutables lanzados
en Windows Server 2008 R2 y Windows Server 2012/2012 R2.

Applocker presenta varias ventajas en comparación con las directivas de restricción de

software:

• La definición de reglas más precisas basadas en el fabricante (mediante firma

electrónica del archivo y de sus atributos extendidos tales como el fabricante, el
nombre, el nombre del producto y/o el nombre del archivo). De este modo es
posible por ejemplo autorizar únicamente un programa que provenga de un
fabricante concreto y a partir de una versión específica (como, por ejemplo,
autorizar únicamente el uso de Office 2003 (versión 11.0.0.0) o superior).
• La posibilidad de definir reglas para usuarios o grupos específicos.
• La posibilidad de importar y exportar reglas.
• La posibilidad de identificar los efectos laterales de una regla activando el modo de
auditoría.

Sepa, también, que si una directiva de grupo posee a la vez una directiva de restricción de
software y una directiva de control de aplicación (Applocker), sólo se aplicará la directiva
Applocker en el puesto.

Por lo tanto, si posee un parque informático heterogéneo compuesto de equipos clientes

Windows 7/8/8.1 y equipos clientes Windows XP, tendrá que crear dos directivas de grupo
distintas. Una directiva de restricción de aplicación para los clientes Windows XP, y una
directiva de control de aplicación (AppLocker), para los clientes con Windows 7/8/8.1.

Si todos los equipos clientes están en la misma OU, es posible utilizar filtros WMI sobre
ambas GPO para filtrar sobre qué tipo de sistema operativo se deben ejecutar.

Las buenas prácticas de seguridad recomiendan prohibir, explícitamente, la ejecución de

archivos ejecutables en carpetas conocidas y habitualmente utilizadas por virus y demás
malwares.

Si aplica las restricciones en las siguientes carpetas, disminuirá sensiblemente el riesgo de

que un virus se ejecute con éxito en sus equipos. El método, sin ser infalible, sí cubre un
espectro bastante importante de procedimientos utilizados por estos programas
malintencionados.

Seleccione las siguientes reglas de bloqueo:

Para Windows XP

Bloqueo de ejecución de archivos peligrosos en %AppData% y sub-carpetas:

• %Appdata%\*.exe
• %Appdata%\*.sys
• %Appdata%\*.dll
• %Appdata%\*\*.exe
• %Appdata%\*\*.sys
• %Appdata%\*\*.dll
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.exe
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.sys
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.dll

Bloqueo de la ejecución de archivos peligrosos en %LocalAppData% y sub-carpetas:

• %UserProfile%\Local Settings\*.exe
• %UserProfile%\Local Settings\*.sys
• %UserProfile%\Local Settings\*.dll
• %UserProfile%\Local Settings\*\*.exe
• %UserProfile%\Local Settings\*\*.sys
• %UserProfile%\Local Settings\*\*.dll

Bloqueo de la ejecución de archivos desde archivos WinRar, 7Zip, WinZip y el soporte Zip
integrado en Windows:

• %UserProfile%\Local Settings\Temp\Rar*\*.exe
• %UserProfile%\Local Settings\Temp\7z*\*.exe
• %UserProfile%\Local Settings\Temp\wz*\*.exe
 • %UserProfile%\Local Settings\Temp\*.zip\*.exe

Para Windows Vista y versiones superiores

Bloqueo de la ejecución de archivos peligrosos en %AppData% y sub-carpetas:

• %Appdata%\*.exe
• %Appdata%\*.sys
• %Appdata%\*.dll
• %Appdata%\*\*.exe
• %Appdata%\*\*.sys
• %Appdata%\*\*.dll
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.exe
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.sys
• C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.dll

Bloqueo de la ejecución de archivos peligrosos en %LocalAppData% y sub-carpetas:

• %LocalAppData%\*.exe
• %LocalAppData%\*.sys
• %LocalAppData%\*.dll
• %LocalAppData%\*\*.exe
• %LocalAppData%\*\*.sys
• %LocalAppData%\*\*.dll

Bloqueo de la ejecución de archivos desde archivos WinRar, 7Zip, WinZip y el soporte Zip
integrado en Windows:

• %LocalAppData%\Temp\Rar*\*.exe
• %LocalAppData%\Temp\7z*\*.exe
• %LocalAppData%\Temp\wz*\*.exe
• %LocalAppData%\Temp\*.zip\*.exe

Veamos cómo configurar Applocker.

Antes de comenzar es preciso saber que existen tres tipos de reglas posibles para evaluar si
una aplicación tiene autorización para ejecutarse o no.

• Ruta de acceso: esta regla permite identificar un ejecutable basándose en una ruta.
Puede, por ejemplo, definir una regla para autorizar el ejecutable C:\Windows\
calc.exe. Aunque esta solución no es la más eficaz, puesto que si un usuario
renombra un ejecutable prohibido como calc.exe en la carpeta C:\Windows será
capaz de ejecutar la aplicación. Es, por el contrario, un método interesante para
impedir la ejecución de un tipo de extensión de archivo en una carpeta conocida por
su riesgo (como, por ejemplo, la carpeta Temporal). La lista de estas carpetas
peligrosas se muestra más arriba e indica también, por ejemplo, que todos los
 ejecutables que se encuentren en la carpeta %LocalAppData%\*.exe no puedan
ejeutarse.
• Hash de archivo: esta regla permite identificar un ejecutable basándose en un valor
de hash calculado. Cada archivo posee un valor de hash único, Windows calcula el
valor de hash de un archivo y lo compara con los valores definidos en las reglas de
Applocker para saber si la regla debe o no aplicarse. El inconveniente de esta
solución es que la regla debe implantarse con cada nueva versión del archivo que
quiere autorizar.
• Publisher: esta regla permite identificar un ejecutable en función del fabricante
(como era el caso con las reglas de certificado de las antiguas restricciones de
software) aunque agregando condiciones más precisas como la versión del
producto, etc.

Antes de crear sus propias reglas personalizadas, será necesario comenzar creando las
reglas por defecto. En efecto, Applocker funciona un poco como un firewall, de modo que
todo lo que no esté expresamente autorizado se rechaza.

He aquí las principales etapas a seguir para implantar Applocker en su empresa.

• Generar las reglas por defecto: para evitar efectos laterales indeseados, es preciso
administrar las reglas por defecto autorizando a todo el mundo a ejecutar los
programas que se encuentran en las carpetas Program Files y Windows.
• Generar reglas automáticas: a continuación sólo tendrá que definir reglas para
bloquear lo que desee. Esta forma de proceder le evitará "auto-bloquearse" en
ciertas situaciones a causa de reglas mal definidas.
• Auditar siempre las reglas Applocker antes de su despliegue masivo en producción.

Generar las reglas por defecto

Para definir sus reglas por primera vez, utilice un puesto piloto (con Windows 7/8/8.1 o
2008 R2/2012/2012 R2) que sea el único puesto presente en la unidad organizativa ligada a
la directiva de grupo que va a configurar. Instale las aplicaciones homologadas o aquellas
que desee autorizar. Instale a su vez las herramientas RSAT para crear la directiva y las
reglas Applocker directamente desde este puesto (enseguida verá por qué razón).

Siempre desde este puesto piloto, diríjase al nivel Configuración del equipo - Directivas
- Configuración de Windows - Configuración de seguridad - Directivas de control de
aplicaciones - Applocker. Observe que hay tres subcategorías: Reglas ejecutables, Reglas
de Windows Installer y Reglas de scripts. Haga clic con el botón derecho del ratón sobre
cada una de estas subcategorías para crear la regla por defecto seleccionando la opción
Crear reglas predeterminadas.

Esto tiene el efecto de crear reglas por defecto autorizando a "Todos los usuarios" a
ejecutar los programas que se encuentran en la carpeta %PROGRAMFILES% y
%WINDIR%. Habrá que tenerlo en cuenta a la hora de realizar las primeras pruebas en
producción. La prohibición prevalece sobre la autorización, y podrá Rechazar el acceso a
un programa específico que se encuentre en alguna de estas carpetas.

Generar las reglas automáticas

La forma más sencilla de definir las reglas para las aplicaciones existentes consiste en
utilizar el asistente. Permite generar reglas según las especificidades de cada ejecutable que
se encuentra en la carpeta indicada. Para ello, haga clic con el botón derecho del ratón en la
categoría Reglas ejecutables y elija Generar reglas automáticamente....
Se abre un asistente que le permite indicar la carpeta a escanear, los usuarios afectados por
esta regla, así como el nombre de la regla.

La siguiente etapa le permite definir las Preferencias de reglas. Es preferible seleccionar

reglas de publicador antes que reglas de hash para una primera implantación. A
continuación puede pasar a la etapa siguiente.

Comienza, a continuación, el escaneo y se muestra el número de reglas identificadas así

como el tipo de regla asociada. Tendrá la posibilidad de examinar los archivos analizados
para suprimir todas o una parte de las reglas propuestas.
 Haga clic en Crear para crear las reglas seleccionadas. Estas se agregarán de inmediato a
la regla del ejecutable.

Auditar las reglas Applocker en los puestos de producción

El objetivo de esta etapa consiste en hacer "como si" las reglas que ha creado estuvieran
implantadas en los puestos de producción, con la diferencia de que las reglas establecidas
no bloquearán las aplicaciones. Se trata de una fase de aprendizaje esencial que permite
identificar los principales efectos colaterales. AppLocker, para Windows Server 2012 R2 y
Windows 8.1, permite escribir en el registro Seguridad información detallada acerca de los
atributos solicitados por una aplicación que intenta ejecutarse.

Para poder simular el despliegue de las reglas Applocker sin que estas últimas sean
realmente efectivas, haga clic con el botón derecho del ratón en Applocker (en
Configuración del equipo - Directivas - Configuración de Windows - Configuración de
seguridad - Directivas de control de aplicaciones - Applocker) y a continuación en
Propiedades.

Marque, a continuación, la opción Configurado en la categoría de reglas que desee (en

nuestro ejemplo Reglas de ejecutables) y seleccione Solo auditoría en la lista desplegable
correspondiente.
Valide haciendo clic en Aceptar.

Para que esta configuración pueda aplicarse en los puestos correspondientes, es preciso
modificar el tipo de inicio del servicio Identidad de aplicación. Éste se define, por
defecto, con arranque Manual y no Automático. Puede configurarlo directamente desde el
puesto cliente o incluso mediante una directiva de grupo en Configuración del equipo -
Directivas - Configuración de Windows - Configuración de seguridad - Servicios del
sistema. Seleccione, a continuación, el servicio Identidad de aplicación y modifíquelo
para un arranque automático.

Reinicie su puesto cliente o fuerce la actualización de la directiva mediante el comando

gpupdate /force para poder probar inmediatamente esta funcionalidad. A continuación,
puede identificar si las reglas Applocker definidas bloquean aplicaciones normalmente
autorizadas. En esta etapa, la aplicación no estará bloqueada. Para verificar la lista de
aplicaciones que tendrían que haber estado bloqueadas, ejecute el visor de eventos y
diríjase al registro que se encuentra en Registro de aplicaciones y servicios - Microsoft -
Windows - Applocker. Busque, a continuación, los eventos con Id 8002 (indicando una
ejecución autorizada de una DLL o de un ejecutable) o 8003 (indicando que el archivo
habría sido bloqueado si no hubiera estado activado el modo de auditoría).

Aplicar las reglas Applocker en los puestos de producción

Una vez haya definido correctamente sus reglas, puede aplicarlas editando su directiva de
grupo creado precedentemente dirigiéndose al nivel Configuración del equipo -
Directivas - Configuración de Windows - Configuración de seguridad - Directivas de
control de aplicaciones - Applocker y, a continuación, Propiedades. En la lista
desplegable correspondiente a la categoría de reglas que quiere aplicar realmente,
seleccione Aplicar reglas. Valide haciendo clic en Aceptar.

Si lo desea, puede agregar opcionalmente la dirección de un sitio Web propio cuando se le

bloquee una aplicación a algún usuario. De este modo, podrá dirigirles a una página
específica de su Intranet para proporcionar información acerca de este bloqueo. Para ello,
modifique la directiva Configuración del equipo - Directivas - Plantillas
administrativas - Componentes de Windows - Explorador de Windows - Establecer un
vínculo de página web de soporte.
Es posible administrar la solución Applocker mediante PowerShell. Encontrará los
comandos PowerShell de referencia en la siguiente dirección:
http://technet.microsoft.com/en-us/library/ee424349(WS.10).aspx

Acaba de descubrir cómo implantar una directiva Applocker. La solución técnica no es

particularmente complicada aunque habrá que prestar atención a los distintos procesos para
implantar esta solución que evoluciona al mismo tiempo que las aplicaciones de su
empresa, de modo que no penalice a los usuarios.

5. Cifrado de datos mediante BitLocker

La mayor parte del tiempo, los servidores están ubicados en un datacenter a menudo
llamado "búnker", de cara a implementar la seguridad física (cámaras, control de
acceso…). No siempre es posible alcanzar este nivel de seguridad, especialmente en sitios
remotos, que cuentan únicamente con unos pocos usuarios. Si bien el número de usuarios
es, con frecuencia, poco elevado, resulta indispensable desplegar un servidor para ofrecer
ciertos servicios de manera local, en especial un controlador de dominio o un servicio
DHCP. En el primer caso, el servidor dispone por defecto de una copia del dominio y, por
tanto, de las contraseñas de todos los usuarios. Como ha visto en el segundo capítulo del
libro, la implementación de un RODC (controlador de dominio de sólo lectura) permite
superar este problema. Pero, ¿cómo puede hacerse si se trata de un servidor de archivos o
de una base de datos?

En tal caso, será interesante cifrar los datos para impedir que el atacante pueda recuperar
los datos y las contraseñas contenidos en el equipo. El cifrado es un método que permite
reforzar la seguridad de un mensaje o un archivo codificando su contenido de manera que
sólo las personas que dispongan de la clave de cifrado apropiada para descifrarlos puedan
leerlo. Por ejemplo, si compra un producto en un sitio web, la información necesaria para
realizar la transacción (como, por ejemplo, su dirección, su número de teléfono y de tarjeta
bancaria) se cifra, por lo general, en el servidor con el objetivo de dotarlos de seguridad.

Por otro lado, el cifrado de los discos duros de los equipos portátiles resulta, también,
extremadamente interesante para las empresas, sobre todo dado que los usuarios son, cada
día, más móviles y, en consecuencia, los datos de la empresa se ven cada vez más
expuestos en caso de hurto.

Microsoft proporciona, desde Windows 2000, el uso

• BitLocker Provisioning: permite desplegar un cifrado de los discos antes, incluso,

de la instalación del sistema operativo.
• Cifrado únicamente del espacio en disco utilizado: es posible seleccionar cifrar el
disco entero o, únicamente, el espacio en disco utilizado. La idea permite cifrar de
manera más rápida el disco cifrando únicamente los bloques utilizados.
• Cambio de contraseña y del código PIN por el usuario estándar: esta
funcionalidad ofrece la posibilidad a un usuario estándar de modificar la contraseña
o el código confidencial de BitLocker en los volúmenes que albergan el sistema
 operativo y la contraseña de BitLocker en los volúmenes de datos, lo que contribuye
a reducir el número de llamadas a soporte técnico.
• Desbloqueo de red: esta funcionalidad permite a un sistema BitLocker instalado en
red desbloquear automáticamente el volumen de sistema durante el arranque (en
redes compatibles con Windows Server 2012). Esto puede resultar primordial tras la
intervención remota por parte del equipo de soporte informático.
• Compatible con discos duros cifrados de Windows: Windows 8 es compatible
con discos duros cifrados con BitLocker.

Antes de que un disco cifrado con BitLocker se desbloquee, BitLocker autentica el disco
basándose en los datos de identificación que el usuario, o el sistema operativo, proveen y
que autorizan a BitLocker a desbloquear el acceso al lector. BitLocker tiene en cuenta los
distintos métodos de bloqueo en base al conocimiento por el usuario de una contraseña, la
presencia de un componente de hardware o claves de aplicación, o una combinación de
estos tres elementos. Puede seleccionar el método de bloqueo cuando configura BitLocker.

Los métodos de bloqueo disponibles difieren entre los discos del sistema operativo y los
discos de datos fijos o extraíbles. Por ejemplo, sólo es posible proteger mediante TPM un
disco que contenga un sistema operativo. Sobre un disco que contenga un OS, puede
seleccionar utilizar uno de los métodos de bloqueo siguientes:

• Sólo TPM.
• Sólo clave de arranque.
• TPM + código PIN.
• TPM + clave de arranque.
• TPM + código PIN + clave de arranque.

En un disco de datos fijos o extraíble, puede seleccionar los tres métodos de bloqueo
siguientes:

• contraseña.
• tarjeta + código PIN.
• automático.

Para los lectores de datos, el método de bloqueo por tarjeta + código PIN ofrece la mejor
protección.

Cuando quiere bloquear los datos protegidos mediante BitLocker con una tarjeta, debe
asegurarse de que sus usuarios tienen certificados compatibles con BitLocker cargados en
una tarjeta. Para generar estos certificados, puede utilizar una entidad de certificación (CA),
crear certificados autofirmados, o configurar un certificado EFS existente para un uso con
BitLocker. Cuando utiliza tarjeta, también se recomienda disponer de una aplicación de
gestión de tarjetas. Puede, por ejemplo, utilizar la funcionalidad de gestión de tarjetas que
ofrece Microsoft Forefront Identity Manager (FIM). El siguiente vínculo ofrece
información detallada acerca del uso de certificados con
BitLocker: http://technet.microsoft.com/en-us/library/dd875548%28WS.10%29.aspx
He aquí las principales etapas a realizar para poder utilizar BitLocker en el seno de su
empresa. En este ejemplo, se trata de desplegar esta funcionalidad en los equipos portátiles
de su AD.

a. Activación de la tarjeta TPM en los equipos

La primera etapa consiste en activar la tarjeta TPM en los equipos pues, como hemos visto,
no es práctico almacenar la información en una llave USB o tener que escribirla con cada
arranque del equipo…

Esta etapa se desarrolla a nivel de BIOS del equipo y puede necesitar, según los fabricantes,
dos reinicios sucesivos del ordenador. El primero permite activar la funcionalidad de
Seguridad TPM y el segundo realiza la activación de la opción de la tarjeta TPM en la
placa base.

Defina, también, el disco duro como primer dispositivo a utilizar en el orden de

arranque del equipo, en caso contrario correrá el riesgo de encontrar problemas si
selecciona un arranque puntual desde otro dispositivo (lector de CD, llave USB, etc.).

El despliegue de esta opción puede realizarse en cada equipo modificando el proceso de

entrega del equipo, con el objetivo de agregar esta configuración, o mediante la
herramienta que permite distribuir la información BIOS a los equipos. Estas herramientas
son propias de cada fabricante y será conveniente leer su documentación para identificar la
existencia de tal solución.

b. Activación de BitLocker en los equipos

Si desea desplegar BitLocker en su infraestructura, el elemento más importante a tener en

cuenta es disponer de claves de recuperación BitLocker. De este modo, si extrae el disco
duro cifrado para conectarlo a otro equipo o si, por algún motivo, el usuario ha perdido su
clave BitLocker, la clave de recuperación permitirá recuperar los datos.

Es, también, posible configurar los equipos para que la clave de cifrado de BitLocker se
almacene como propiedad del equipo directamente en Active Directory.

Para ello, si tiene un controlador de dominio con Windows Server 2008 o superior, es
posible almacenar esta información en Active Directory. En caso contrario, instale, al
menos, un controlador de dominio con esta versión y actualice el esquema de Active
Directory para que la información BitLocker pueda tenerse en cuenta.

c. Despliegue de BitLocker en equipos del Active Directory

Cree, a continuación, una nueva directiva de grupo y edite los parámetros que se
encuentran en Configuración del equipo - Directivas - Plantillas administrativas -
Componentes de Windows - Cifrado de unidad BitLocker.
Verá varios parámetros de configuración así como tres carpetas suplementarias que
configuran la forma en que Windows procesa la información de BitLocker según se trate de
un lector de datos extraíble, de un disco fijo o de un sistema operativo.

Seleccione las siguientes opciones y repita esta operación según el tipo de información que
desea proteger:

Por ejemplo, para el sistema operativo, las opciones son:

Elegir cómo se pueden recuperar unidades del sistema operativo protegidas por
BitLocker

Habilite la opción y seleccione registrar las contraseñas de recuperación y los paquetes de

claves. Indique, a su vez, "No habilitar BitLocker hasta que la recuperación de
información esté almacenada en Active Directory", lo que le asegura que BitLocker no
cifrará los datos mientras no esté seguro de poder recuperarlos a través de Active Directory.
Puede, a continuación, repetir la configuración para los demás tipos de lector.

Vaya a Configuración del equipo - Directivas - Plantillas administrativas -

Componentes de Windows - Sistema - Servicios de Módulo de plataforma segura.

Habilite la opción Activar copia de seguridad del TPM en los Servicios de dominio de
Active Directory.
Observe que, si BitLocker ya está activo en los equipos, las claves de recuperación así
como la información TPM no se almacenará en Active Directory, puesto que se realiza en
el momento en que se activa la tarjeta TPM y, por tanto, se activa BitLocker.

Para forzar manualmente el almacenamiento de esta información en Active Directory para

estos equipos, será preciso utilizar el siguiente comando (para la recuperación de la
información para el lector C:, por ejemplo): manage-bde-protectors -get c:

Puede obtener la contraseña digital del lector y "empujarla" a Active Directory mediante el
comando manage-bde-protectors -adbackup c: -id {contraseña digital}.

Puede, a continuación, forzar la aplicación de esta directiva en sus equipos mediante el

comando gpupdate /force.

d. Visualizar las claves de recuperación de BitLocker

Para visualizar las claves de recuperación de BitLocker, tendrá que utilizar las herramientas
RSAT, o bien agregar la funcionalidad Cifrado de unidad BitLocker.

Puede, a continuación, ir a la pestaña Recuperación BitLocker, en las propiedades del

equipo. La pestaña presenta la contraseña de recuperación que debe utilizar si fuera
necesario.
Se planteará, sin duda, la cuestión… ¿Cómo es posible recuperar un disco duro cifrado sin
no se sabe el nombre del equipo que ha cifrado los datos? En este caso, tras intentar acceder
a los datos, un mensaje le indicará el Password ID. Haciendo una búsqueda en Active
Directory puede encontrar este Password ID y, de este modo, la clave de recuperación
asociada. Desde la consola ADUC (dsa.msc), aparecerá una nueva opción siempre que
estén instaladas las herramientas BitLocker; se trata de la opción Buscar contraseña de
recuperación de BitLocker.
Sepa, también, que BitLocker puede utilizarse para cifrar los periféricos extraíbles (llave
USB, disco duro externo, etc.) utilizando la funcionalidad BitLocker To Go.

El lector puede leerse automáticamente en un equipo Windows 7/8 una vez que se haya
informado la contraseña de cifrado. Las versiones anteriores de Windows, como por
ejemplo Vista y XP, pueden leer los datos cifrados en los periféricos, con la condición de
que los datos estén almacenados en FAT (y no NTFS); gracias a la herramienta BitLocker
To Go Reader almacenada sobre el dispositivo. La herramienta no permitirá, sin embargo,
leer el contenido de la clave ni escribir datos en el dispositivo. Puede descargar la
herramienta de la siguiente dirección: http://www.microsoft.com/en-
us/download/details.aspx?id=24303

En un contexto algo diferente, he aquí un ejemplo de implementación de BitLocker sobre

un servidor core que se encuentra configurado en workgroup:

En primer lugar es necesario instalar la funcionalidad mediante el siguiente comando

PowerShell:

Add-WindowsFeature BitLocker

Al finalizar la instalación, es necesario reiniciar.

Para obtener el estado del cifrado BitLocker sobre el servidor y para todos sus volúmenes,
utilice el comando PowerShell:

Get-BitLockerVolume |FL

Obtendrá un resultado similar al que se muestra a continuación:

A continuación, debe habilitar BitLocker:

%systemroot%\System32\manage-bde.exe -on C: -rp -sk E:

Esta línea de comando configura el cifrado del lector C que contiene al sistema operativo
en una máquina que no disponga de un módulo TPM.

La opción -rp se corresponde con una contraseña de recuperación; la opción -sk con la
ubicación E: (llave USB) se corresponde con la ubicación de almacenamiento de una clave,
necesaria con cada reinicio.

El resultado se muestra en la siguiente captura de pantalla:

Observe que, por defecto en Workgroup, el sistema no permite cifrar el lector que contiene
el sistema operativo en un servidor que no posea módulo TPM. Es preciso, no obstante,
configurar la directiva local para autorizar esta operación (en el editor de directivas:
Plantillas administrativas - Componentes de Windows - Cifrado de unidad BitLocker
- Unidades del sistema operativo - Requerir autenticación adicional al iniciar y marque
la opción Permitir BitLocker sin un TPM compatible.

Encontrará más información acerca de la configuración de BitLocker en la siguiente

dirección: http://technet.microsoft.com/en-us/library/jj612864.aspx

Por último, sepa que Windows 8.1 y Windows Server 2012 R2 aprovechan la aparición del
soporte del cifrado de los dispositivos. Como ejemplo, cuando un equipo se instala con
Windows 8.1, la fase de preparación para el primer uso se encarga de inicializar, también,
el cifrado del disco duro externo mediante una clave sin cifrar (equivalente al estado
suspendido de BitLocker).

A diferencia de las implementaciones anteriores de BitLocker, el cifrado está habilitado

automáticamente de manera que el dispositivo siempre está protegido por defecto.
6. Herramientas de seguridad indispensables
a. Asistente para configuración de seguridad

Siempre partiendo del principio del menor privilegio, Windows Server, desde el Service
Pack 1 de Windows Server 2003, proporciona un asistente de configuración de la seguridad
(llamado SCW por Security Configuration Wizard). Su objetivo es crear una directiva que
habilite los servicios, las reglas de firewall y los parámetros necesarios para cubrir los roles
específicos (controlador de dominio, servidor de impresión, etc.).

No se trata, por tanto, de aplicar un modelo de seguridad (archivo INF) sino más bien de
configurar el sistema operativo de manera más cercana a las verdaderas necesidades del
servidor. Esto supone deshabilitar todos aquellos servicios inútiles, agregar reglas
necesarias en el firewall de Windows, etc.

Para acceder al asistente, en Windows Server 2012 R2, vaya al Administrador del
servidor - Herramientas - Asistente para configuración de seguridad.
 La primera etapa consiste en definir la acción que se desea realizar. Puede bien crear una
directiva, modificarla, aplicarla o bien hacer una marcha atrás en alguna directiva aplicada
con anterioridad.

En este ejemplo, vamos a crear una nueva directiva. Hacemos clic en Siguiente.

Seleccione, a continuación, el servidor sobre el que desea auditar la configuración y aplicar

esta seguridad. A continuación, haga clic en Siguiente.
 Se compara la información con la información de seguridad que ofrece Microsoft y que es
visible haciendo clic en Ver la base de datos de configuración. Haga clic en Siguiente.
 El resto del asistente le permite realizar la selección de roles necesarios en el servidor para
configurar, así, los servicios de manera adecuada. Si no marca un servicio que esté
instalado, entonces el asistente lo deshabilitará y ya no se volverá a arrancar. Tome su
tiempo para analizar los resultados. Por defecto, el asistente le presenta aquellos roles que
ha identificado como instalados en su etapa de verificación anterior. Una vez realizada la
selección, haga clic en Siguiente.
 La siguiente etapa hace referencia a las Características instaladas. Aquí se enumeran los
principales servicios "cliente" utilizados en el servidor (DNS, WINS, Miembro de dominio,
etc.). Realice el mismo análisis que en la etapa anterior y, a continuación, haga clic en
Siguiente.
 La siguiente etapa indica otras opciones diversas que tendrán su impacto en ciertos
servicios, o sobre la configuración automática del firewall de Windows con seguridad
avanzada. Haga clic en Siguiente una vez realizada la selección.
 Los servicios adicionales, al no formar parte de la base de datos de configuración que se
ofrece por defecto, se enumeran aquí. Haga la selección adecuada y, a continuación, haga
clic en Siguiente.
 Pasamos a una etapa que se refiere al tratamiento de servicios sin especificar durante las
etapas anteriores. Puede seleccionar el comportamiento por defecto entre no modificar el
modo de arranque del servicio o deshabilitarlo automáticamente. La elección dependerá de
la criticidad del servidor. Haga clic en Siguiente.

La siguiente ventana resume las modificaciones que se realizarán en los servicios del
servidor en cuestión. Valide la configuración haciendo clic en Siguiente.
 La siguiente etapa se refiere a la configuración automática de las reglas para el Firewall
de Windows. Es posible ignorar esta etapa marcando la opción adecuada. Haga clic en
Siguiente para iniciar este asistente. Puede seleccionar y enumerar las reglas modificadas
por el asistente de configuración, o incluso, por ejemplo, agregar una regla específica que
no se había identificado previamente. Una vez finalizada esta etapa, haga clic en Siguiente.
 A continuación puede editar la configuración del registro. En esta aplicación, se trata, en
realidad, de configurar los protocolos autorizados para comunicar con los demás equipos
(exigir la firma SMB, exigir la firma LDAP y los métodos de autenticación entrante y
saliente). Aparece una página que le resume todas las modificaciones que se efectuarán en
el servidor. Esta configuración resulta muy interesante y permite aumentar,
significativamente, la seguridad de los intercambios entre el servidor y sus clientes. Las
modificaciones propuestas requieren, no obstante, disponer de un parque informático
relativamente moderno.

La última etapa se refiere a la configuración de la directiva de auditoría que se aplicará.

Piense en prever una volumetría suficiente para que la auditoría sea manejable.

El archivo SCWAudit.inf define una auditoría sobre el acceso de cualquier usuario al

archivo de configuración, de sistema, etc. Tenga en mente que la marcha atrás propuesta
por el asistente de configuración de la seguridad no le permitirá restaurar estos parámetros
de auditoría a su estado original. Si tiene alguna duda, desmarque la opción en cuestión.

Haga clic en Siguiente.

 Seleccione un nombre para guardar el archivo. Puede visualizar la configuración creada e
incluso integrarla en un modelo de seguridad (archivo .INF) que se aplicará durante la
selección de la configuración específica. En nuestro ejemplo, se trata de
Plantilla_ControladorDeDominio_2014.xml.
 A continuación, puede seleccionar aplicar más adelante, o inmediatamente, la directiva en
cuestión.

Lo que resulta interesante con este asistente es que puede crear un archivo de plantilla, tal y
como hemos hecho, y a continuación convertirlo en un objeto de directiva de grupo, que
será más fácil de desplegar en los equipos que elija.

Es posible convertir el archivo de directiva de seguridad en un objeto de directiva de grupo

de la siguiente manera:

Scwcmd transform /p:%windir%\security\msscw\Policies\Plantilla_

ControladorDeDominio_2013.xml /g:SecureDC

Se crea automáticamente una GPO llamada SecureDC donde se definirán los parámetros
de la plantilla. Deberá, a continuación, vincular esta GPO con la OU que desee.

Si fuera necesario, los archivos de log se encuentran en la ruta:

%windir%\security\msscw\Logs
Esto permitirá mantener una seguridad homogénea de los servidores utilizados para un
mismo rol, sin un sobrecoste en la administración.

b. La herramienta Security Compliance Manager

Microsoft pone, también, a disposición del usuario y de manera gratuita una lista de
referencias de los parámetros de seguridad para sus productos, especialmente para
Windows Server 2012. Estos parámetros se proveen a través de una herramienta
llamada Security Compliance Manager, accesible en la siguiente dirección:
http://technet.microsoft.com/en-us/library/jj898542.aspx

SCM permite evaluar y corregir la conformidad de sus políticas de seguridad mediante las
siguientes operaciones:

• Importar los parámetros de seguridad (desde el sitio Microsoft Solution

Accelerators o desde una copia de seguridad de sus GPO).
• Comparación y personalización de los parámetros respecto a las recomendaciones
de Microsoft.
• Exportación de los parámetros de seguridad (hacia una GPO, un pack de
configuración DCM para SCCM, un archivo SCAP…).
• Consulta de las últimas versiones de las guías de seguridad de Microsoft provistas
con las baselines oficiales.

c. La herramienta Microsoft Security Assessment Tool

Existe otra herramienta, muy popular entre los equipos encargados de la seguridad. Se trata
de Microsoft Security Assessment Tool (MSAT), disponible en la siguiente
dirección: http://www.microsoft.com/en-
us/download/details.aspx?displaylang=en&id=12273. Se analizan una serie de cuestiones
(más de un centenar), que le permiten evaluar la seguridad de su infraestructura según las
respuestas indicadas. Tras el formulario, se generan 3 informes, más un informe completo
que incluye una guía de procedimientos y un listado de las acciones principales.

Permite ofrecer información y recomendaciones sobre las buenas prácticas de seguridad en

el seno de una infraestructura. Se basa en una serie de preguntas globales relativas a su
parque informático (número de equipos, número de servidores, etc.) más cuestiones un
poco más técnicas (¿existe una DMZ?, etc.).

7. El control de acceso dinámico

a. Principio del control de acceso dinámico

Estos últimos años hemos organizado toda nuestra seguridad de datos (nuestros recursos)
en base a la asignación de permisos (ACL) y a usuarios según su pertenencia a tal o cual
grupo.
Si bien este método ha resultado útil, posee sus límites pues, de hecho, se trata de un acceso
que se resume en autorizado o no según la pertenencia del usuario a los grupos definidos o
a la aplicación de ciertas ACL sobre una carpeta o archivo concretos. La seguridad se
centraba, principalmente, en los usuarios que podían acceder a ciertos recursos, más que a
la criticidad de los propios recursos accedidos.

Con Windows Server 2012 R2, es posible mejorar considerablemente esta gestión de los
datos a través de una nueva noción llamada Control de acceso dinámico (o
Dynamic Access Control - DAC).

El control de acceso dinámico permite establecer autorizaciones de acceso en función de

reglas precisas. Permite complementar los permisos existentes sobre una carpeta o un
archivo, no tiene vocación de remplazar las ACL, aunque se agrega a los permisos NTFS
implementados.

Estas reglas pueden estar vinculadas a numerosos parámetros, tales como:

• El nivel de confidencialidad asociado a un archivo o carpeta.

• El cargo ocupado por un usuario, su ubicación geográfica o cualquier otro atributo
diferenciador.
• La configuración del dispositivo que se utiliza para acceder a los recursos.
• Etc.

Será, de este modo, posible permitir el acceso a un recurso en función de su clasificación.

Es posible agregar alguna condición de acceso suplementario como, por ejemplo, la
conformidad del equipo desde el que el usuario intenta acceder al recurso. Este mismo
usuario desde un equipo que no esté actualizado no podrá acceder al mismo archivo. El
cambio se realiza sobre la marcha, pues los criterios se verifican en el momento de realizar
el acceso al recurso.

La información relativa al DAC se almacena en el Active Directory dentro de

CN=Claims Configuration,CN=Services,CN=Configuration,DC=miempresa, DC=priv y se
replica en el seno del Active Directory.

b. Terminología

Antes de poder abordar el DAC, veamos los distintos términos que conviene conocer:

• Notificación (Claim): le permite implementar DAC en su infraestructura, será

preciso realizar un trabajo previo para categorizar sus datos, su criticidad, el
perímetro de seguridad autorizado (puesto conforme o no) para acceder a los
archivos, etc. Estos elementos se asocian a distintos atributos. Una notificación es
uno de estos atributos, hará referencia a un usuario (sus atributos Active Directory),
un dispositivo (atributos Active Directory del equipo) o un recurso (propiedad de
recursos definidos por los administradores).
 Esto permite definir de forma precisa los usuarios, dispositivos y recursos que se
desea integrar en DAC a nivel de toda la empresa. Cuando una notificación se basa
en una cuenta de equipo, deberá habilitarse la opción FAST (Kerberos Armoring)
por GPO sobre los controladores de dominio del dominio afectado. Es posible
agrupar una notificación de usuario y de equipo para formar una autenticación
compuesta (Compound ID), disponible únicamente en Windows 8/2012 o superior.

Las notificaciones, o propiedades, se agregan a una lista de propiedades de recursos.

• Reglas de acceso central (Central Access Rules): se trata de una expresión de reglas
de autorización que incluye una o varias condiciones. Estas condiciones afectan a
los grupos de usuarios, a las propiedades de los recursos, a las notificaciones del
usuario o del dispositivo.

• Directiva de acceso central (Central Access Policy): se trata de una directiva de

autorización que incluye expresiones condicionales, es decir, condiciones que deben
cumplirse para poder acceder al recurso (o al archivo).

La directiva de acceso central debe agregarse a una regla de acceso central. La regla
de acceso central debe, por tanto, aplicarse a todos los archivos afectados.

La directiva de acceso central se despliega, a continuación, en todos los servidores

de archivos.

• Expresión (Expression): hablamos de una expresión condicional. El acceso a los

recursos puede afinarse gracias a la definición de varias condiciones (tales como la
pertenencia de una cuenta a un grupo, el nivel de seguridad del puesto de usuario,
etc.).

Las expresiones se definen a nivel de los parámetros de seguridad avanzados del

archivo/carpeta o del editor de reglas de acceso central.

c. Formas de implementación y requisitos previos

Para utilizar DAC, existen dos enfoques posibles:

• Es posible definir reglas y directivas de acceso central a nivel de Active Directory, y

éstas se utilizarán para autorizar o no el acceso a un recurso.
• El segundo método consiste en crear e integrar las notificaciones en las listas de
control de acceso existentes (ACL). Este caso resulta particularmente útil para
archivos almacenados en un sistema de archivos ReFS puesto que no soporta, de
momento, ninguna directiva de acceso. Para obtener más información acerca ReFS,
consulte el capítulo El ciclo de vida de su infraestructura.

Los requisitos previos son:

 • El nivel funcional del bosque debe, al menos, ser Windows Server 2003.
• DAC requiere, al menos, un controlador de dominio con Windows Server 2012.
• Los servidores de archivos para los que desea una autenticación basada en
notificaciones deben, a su vez, utilizar Windows Server 2012/2012 R2. El rol File
Server Resource Manager (FSRM) debe estar instalado en estos servidores de
archivos.
• Un cliente Windows RT/8/8.1/201/2012 R2 si el acceso se basa en notificaciones y
quiere utilizar los atributos en el objeto Equipo. En los demás casos, basta con un
cliente Windows 7/2008 R2.
• Un cliente Windows RT/8/8.1/2012/2012 R2 con acceso a un controlador de
dominio en Windows Server 2012/2012 R2 para los sitios remotos.
• Si el usuario no se encuentra en el mismo bosque que el servidor de archivos, todos
los controladores de dominio del dominio raíz del servidor de archivos deben
utilizar Windows Server 2012/2012 R2.

Como podrá ver, existen varias nociones nuevas que debe aprehender, aunque la ganancia
en términos de seguridad resulta muy interesante.

d. Caso práctico y análisis de necesidades

Tomemos como ejemplo el departamento Recursos Humanos (RRHH) de una gran empresa
con varios países agrupados en el mismo dominio Active Directory. Los archivos de RRHH
de cada país no deberían poder consultarse, salvo en modo de sólo lectura, por parte del
departamento de RRHH local de cada país, respectivamente.

El departamento de RRHH central podrá, además, acceder a los archivos de RRHH de

todos los países.

Etapa 1: Comprender las necesidades y traducirlas en atributos de referencia interpretables

en DAC

Como en todo proyecto, es necesario realizar un estudio previo. Se trata de identificar los
datos sensibles y las reglas que autorizarán el acceso a los mismos.

Las reglas son, por tanto:

• Los documentos no pueden accederse salvo en modo de solo lectura desde el

departamento de RRHH.
• El departamento de RRHH sólo puede acceder a los recursos de RRHH de su país.
• Sólo los miembros del grupo Admins RRHH tienen un acceso de lectura/escritura.
• Los miembros del grupo RRHH_Excepcion tendrán acceso de sólo lectura.
• Los administradores y propietarios del documento tendrán un acceso de Control
total.

Etapa 2: Crear el tipo de notificación

Es necesario crear notificaciones sobre los atributos que se utilizarán para definir el
acceso al recurso.

En nuestro caso, nos basaremos en los atributos Department (Departamento) y Country

(País) del usuario.

La definición de la notificación se configura en la consola del Centro de administración de

Active Directory, pues se trata de información que se almacena en Active Directory.

Desde la consola Centro de administración de Active Directory (dsac.exe), vaya al menú

Control de acceso dinámico - Claim Types - Nuevo - Tipo de notificación y haga clic en
el atributo department.

Agregue, a continuación, el atributo País.

Desde la consola Centro de administración de Active Directory, Control de acceso

dinámico - Claim Types - Nuevo - Tipo de notificación y haga clic en el atributo c.

En Nombre completo, indique country.

En los valores sugeridos, haga clic en Se sugieren los valores siguientes y agregue ES (en
valor y nombre completo), JP, US, GB.
Etapa 3: Definir las propiedades de los recursos

Hay que empezar definiendo las propiedades de los recursos (Resource Properties).

Aquí se configuran las propiedades que se descargarán los servidores de archivos para
clasificar los archivos.

Observe que estas propiedades de recursos se agregarán a la lista de Propiedades de

recursos.

Los futuros accesos de control dinámico tendrán como objetivo comparar los atributos del
usuario con las propiedades de los recursos.

Se establece una lista previa de propiedades de los recursos por Microsoft, aunque es
posible crear las propias si fuera necesario. Esto es lo que hemos hecho con el atributo
Country, que no existe por defecto.

En primer lugar, habilitaremos el atributo Department...

Abra la consola Centro de administración de Active Directory y, a continuación,

seleccione Control de acceso dinámico - Resource Properties.

Seleccione Department y marque la opción Habilitar en la lista de tareas disponibles.

Para el atributo Country, al no estar definido por defecto, es necesario crear una propiedad
de recursos de referencia del siguiente modo:

Desde la consola Centro de administración de Active Directory, Control de acceso

dinámico - Resource Properties - Nuevo - Propiedades de recurso de referencia.

Seleccione el atributo country e indique el mismo nombre en Nombre completo y, a

continuación, haga clic en Aceptar.

Seleccione country en la lista de Resource Properties y haga clic en Habilitar.

Si no utiliza las notificaciones sino directamente las propiedades de los recursos, se

recomienda agregarlas a una lista de propiedades de recursos.

Etapa 4: Definir una regla de acceso central (Central Access Rule o CAR)

Es, de algún modo, el equivalente a las ACL, incluso aunque no las remplaza por completo.
Una CAR describe las condiciones que deben cumplirse para permitir el acceso a un
recurso (un archivo, por ejemplo).

Desde la consola Centro de administración de Active Directory (dsac.exe), vaya al nodo

Control de acceso dinámico, haga clic en Central Access Rules - Nuevo - Regla de
acceso central.
Defina, a continuación, las reglas que desee aplicar.

En nuestro ejemplo, para asociar una verificación al atributo "Departamento", haga lo

siguiente:

Nombre: RRHH - Reglas para los documentos RRHH.

Descripción: (opcional).

Recursos afectados: haga clic en Editar y, a continuación, en Agregar una condición y

seleccione la o las condiciones que deben cumplirse para permitir el acceso a los recursos,
del siguiente modo: Recurso - Department - Es igual a - Valor - Human Resources y
haga clic en Aceptar (Human Resources se corresponde con el valor preconfigurado por
defecto en Windows y que puede modificarse si fuera necesario a nivel de Resource
Properties).

En las autorizaciones, seleccione el valor Usar los siguientes permisos como permisos
actuales.
En las Permisos actuales, haga clic en Editar y, a continuación, agregue los Usuarios
autentificados como Principal. Es preciso crear, a continuación, las condiciones que se
refieren a las necesidades expresadas en el estudio para "Todos" los usuarios. En nuestro
ejemplo, los Usuarios autentificados responden a ciertos criterios que pueden acceder a
los archivos en modo lectura, por lo que debemos definir la siguiente regla:

Usuario - country - Cualquiera de - Recurso - country

Usuario - department - Cualquiera de - Recurso - Department

Haga clic en Aceptar.

 Agregue una autorización específica para los Administradores de RRHH (miembros del
grupo RRHH_Admin) que tendrán, en sí mismo, la posibilidad de modificar el contenido
en cuestión. Haga clic en Editar dentro de Permisos actuales y, a continuación, Agregar -
Seleccionar una entidad de seguridad. Indique el grupo RRHH_Admin en Modificar.
Haga clic en Aceptar.
 Agregue una autorización específica para los usuarios que solo tengan permisos de lectura
(miembros del grupo RRHH_Excepcion). Haga clic en Editar dentro de Permisos actuales
y, a continuación, Agregar - Seleccionar una entidad de seguridad. Indique el grupo
RRHH_Excepcion que tendrá acceso de Lectura/lectura y ejecución. Haga clic en Aceptar.

Ahora, tiene una regla de acceso central que limita el acceso a los archivos de RRHH a un
mismo país y un mismo departamento. El grupo RRHH_Admin puede editar los archivos y
el grupo RRHH_Excepcion puede leerlos.

Observe que sólo los archivos clasificados como Human Resources estarán afectados por
esta regla.

Etapa 5: Agregar reglas de acceso central a una directiva de acceso central

A continuación, es preciso asociar las reglas creadas a una directiva de acceso central que
desplegaremos mediante una GPO.

Para ello, desde el Centro de administración de Active Directory abra Central Access
Policies - Nuevo - Directiva de acceso central y asocie la regla de acceso central que
acaba de crear.
Etapa 6: Desplegar la directiva de acceso central en los servidores de archivos mediante una
GPO

La CAP puede desplegarse mediante una GPO en los servidores de archivos Windows
Server 2012 que posean el rol FSRM (este rol se agrega al servidor en Seleccionar roles de
servidor - Servidor de archivos y almacenamiento - Servicios de iSCSI y archivo y
marcando Servidor de archivos y Administrador de recursos del servidor de archivos).

Es preciso crear una nueva GPO para desplegar la directiva de acceso central (CAP) en los
servidores de archivos.

Esta directiva de grupo deja disponible la política de acceso central, aunque no forzará su
aplicación.

Desde la consola Administración de directivas de grupo (gpmc.msc), cree una GPO en la

OU que hospeda sus servidores de archivos. Navegue a Configuración del equipo -
Directivas - Configuración de Windows - Configuration de seguridad - Sistema de
archivos - Directiva de acceso central.
Haga clic con el botón derecho en Directiva de acceso central y, a continuación, en
Administrar directivas de acceso central. Seleccione la directiva que acaba de crear
CAP_RRHH y haga clic en Agregar.

Haga clic con el botón derecho en la OU correspondiente a su directiva y seleccione

Actualización de directiva de grupo. Esto tiene como efecto forzar la aplicación de la
directiva de grupo en todos los servidores de la OU (funcionalidad incluida con Windows
Server 2012 que funciona con equipos cliente con Windows Vista/2008 o versiones
superiores).

Etapa 7: Configurar los controladores de dominio y los clientes para que tengan en cuenta
las notificaciones

Para que un controlador de dominio sea apto para gestionar las notificaciones, hay que
configurarlo definiendo una GPO que se aplica a nivel de la OU ”Domain Controllers”.
La opción FAST por Flexible Authentication Secure Tunneling, también conocida con el
nombre de ”Kerberos Armoring"” (o blindaje Kerberos), debe estar habilitada en los
controladores de dominio para ser compatible con DAC. FAST provee, en particular, un
canal seguro entre el cliente y el KDC.

El blindaje Kerberos se aplica mediante GPO sobre la OU ”Domain Controllers”. Se aplica

sobre controladores de dominio con Windows Server 2008 y superiores.

Para configurarlo, siga los siguientes pasos:

Cree una GPO, en lugar de utilizar la GPO por defecto ”Default Domain Controllers
Policy”.

Vaya a Configuración del equipo - Directivas - Plantillas administrativas - Sistema -

KDC y habilite el parámetro KDC admite notificaciones, autenticación compuesta y
protección de Kerberos.

Fuerce las GPO en los controladores de dominio a través del comando gpupdate /force.

A nivel de su dominio (o de sus equipos cliente, únicamente), defina una GPO que permita
utilizar notificaciones. Esto tiene como efecto extender el ticket Kerberos gestionado por el
cliente.

Vaya a Configuración del equipo - Directivas - Plantillas administrativas - Sistema -

Kerberos y habilite el parámetro KDC admite notificaciones, autenticación compuesta y
protección de Kerberos.

Etapa 8: Clasificar los datos en el servidor de archivos y aplicar la directiva de acceso

central

Esta etapa debe realizarse desde el explorador de archivos en el servidor de archivos con el
rol FSRM.

En primer lugar, deberá clasificar los archivos del recurso compartido especificando las
propiedades de los recursos definidas anteriormente.

En las propiedades de aquellos recursos compartidos que deban protegerse, haga clic con el
botón derecho sobre él y, a continuación, en Propiedades. Vaya a la pestaña Clasificación.
Verá aparecer todas las propiedades de los recursos definidas anteriormente.

Si no fuera el caso, desde el servidor de archivos, abra una ventana de PowerShell y escriba
el comando Update-FSRMClassificationPropertyDefinition. Este comando forzará el
refresco de las propiedades de los recursos definidas.

Seleccione, a continuación, las propiedades del recurso country y Department y defina

los valores esperados. A continuación, haga clic en Aceptar.
Ahora que ha clasificado la carpeta, puede asociar la directiva de acceso central que desea
aplicarle.

En las propiedades de la carpeta, seleccione la pestaña Seguridad, haga clic en Opciones

avanzadas y seleccione la pestaña Directiva central.

Haga clic en Cambiar y seleccione, a continuación, la directiva centralizada llamada

CAP_RRHH.
 A continuación, haga clic en Aceptar para validar la configuración y, de este modo, hacer
la DAC efectiva sobre esta carpeta.

Etapa 9: Verificar los accesos efectivos

Ahora que todo está implementado, la última etapa consiste en verificar que los accesos
están bien definidos.

Para ello, no tendrá que conectarse con la cuenta de tal o cual usuario para hacer esta
verificación. La pestaña Acceso efectivo se ha actualizado en Windows Server 2012 y tiene
en cuenta las notificaciones.

En las Propiedades de la carpeta, seleccione la pestaña Seguridad, haga clic en Opciones

avanzadas y seleccione la pestaña Acceso efectivo.

Seleccione la cuenta de usuario que desee y haga clic en Ver acceso efectivo.
Aquí, si bien todos los usuarios autenticados están definidos a nivel NTFS, sólo aquellos
que respondan a los criterios definidos en la DAC están autorizados a acceder a los
recursos.

Puede, a continuación, constatar la eficacia de esta directiva visualizando las autorizaciones

efectivas sobre esta carpeta seleccionando una cuenta de usuario que tenga los atributos
informados correctamente. Puede, a su vez, indicar una notificación específica y ver los
permisos aplicados.

Puede definir atributos de usuario directamente desde la consola Centro de administración

de Active Directory. En las propiedades del usuario existe una sección Extensión, que
contiene varias pestañas, entre ellas una llamada Editores de atributos.
e. Para ir más allá...

Existen varias opciones muy interesantes que complementan la funcionalidad de control de

acceso dinámico.

Entre ellas, cabe tener en mente:

• En caso de acceso denegado, es posible definir una directiva de remedio que

permita al administrador definir un mensaje específico al usuario, e incluso avisar al
propietario del recurso mediante correo electrónico, lo que mejora
considerablemente la reactividad en caso de existir alguna configuración incorrecta
durante la etapa de implementación de la DAC. Observe que esta funcionalidad sólo
está disponible si utiliza SMB 3.0 (y, por consiguiente, para accesos a archivos que
se hayan realizado desde clientes Windows 8/8.1/2012/2012 R2 hacia un servidor
de archivos Windows Server 2012/2012 R2).

Esto se configura en los servidores de archivos, en la consola Administrador de

recursos del servidor de archivos - Administración de clasificaciones. Haga clic
con el botón derecho en Propiedades de la clasificación y Establecer propiedades
de administración de carpetas.

• Las directivas de auditoría son mucho más eficaces cuando están basadas en
expresiones que se apoyan en notificaciones (claims) de usuario, de equipo y de
recurso, permitiendo así precisar los eventos que deben notificarse.
De este modo puede, por ejemplo, auditar todos los usuarios que intentan acceder a
recursos para los que no tienen habilitado el acceso o, al revés, administradores que usen
sus permisos de forma abusiva.

Vaya a las Propiedades de la carpeta que desee auditar, en la pestaña Seguridad -

Opciones avanzadas - pestaña Auditoría - Agregar - Seleccionar una entidad de
seguridad.

Seleccione, a continuación, el grupo que desea auditar, por ejemplo el grupo habilitado
para acceder a esta carpeta.

Puede, a continuación, agregar una condición que indique, por ejemplo: Usuario - Grupo -
Miembro de cada - Valor - [Admins de Dominio] y [Administradores].

Debe haber habilitado, previamente, la auditoría del sistema de archivos en Configuración

del equipo - Directivas - Configuración de Windows - Configuración de seguridad -
Configuración de directiva de auditoría avanzada - Directivas de auditoría - Acceso a
objetos. A continuación, en el parámetro Auditar sistema de archivos y en el parámetro
Auditar almacenamiento provisional de directiva de acceso central, habilite las
opciones Correcto y Error.

• Para la clasificación de los archivos, una de las etapas más complejas, es posible
definir reglas de clasificación automática de los datos.

Puede, a continuación, buscar los archivos que contienen la cadena de caracteres

"Confidencial restringido" y, de este modo, categorizar automáticamente el archivo
como ”High”.

Para ello, es preciso crear una regla de clasificación desde la consola

Administrador de recursos del servidor de archivos, habiendo habilitado
previamente la propiedad de recursos "Impacto".
 De este modo, se ejecutará esta regla escaneando todos los archivos buscando la
cadena de caracteres en cuestión y, a continuación, atribuirá automáticamente el
valor High al atributo Impact del archivo.

Microsoft proporciona, a su vez, la herramienta Data Classification Toolkit que le

ayuda en la clasificación de los archivos en sus servidores Windows 2008 R2/2012
y 2012 R2. Está disponible en la siguiente dirección: http://www.microsoft.com/en-
us/download/details.aspx?id=27123

• Si desea acoplar DAC a RMS, esto le permitirá cifrar sus documentos sensibles En
base, por ejemplo, a su clasificación podrá mantener el control sobre los
documentos clasificados en cualquier momento.

El control de acceso dinámico supone una mejora importante en Windows Server 2012. Si
bien es necesario realizar un gran trabajo inicial, la seguridad de los datos de la empresa se
verá mejorada considerablemente.

Podrá acoplarle una directiva de auditoría basada en expresiones, tal y como se describe en
el capítulo Dominio Active Directory.
Delegación de la administración en Active
Directory
Una de las principales ventajas de un dominio Active Directory es poder tener un directorio
común para varias entidades en el seno de la misma empresa. Este directorio compartido
permite reducir costes de administración asociados al mantenimiento de la infraestructura.

1. Enfoque de la delegación de la administración

Dado que las políticas de seguridad están bien diferenciadas en las distintas divisiones de la
empresa y que los equipos IT no son los mismos, conviene encontrar una solución que
permita delegar las tareas necesarias para el trabajo de cada uno sin comprometer la
seguridad de la totalidad del dominio Active Directory.

Existen distintas maneras de delegar los permisos a los usuarios. Algunas autorizaciones
pueden asignarse, fácilmente, a través de grupos de seguridad ya existentes. Es el caso, por
ejemplo, de la delegación de la administración de un servicio como DHCP (mediante el
grupo DHCPAdmins) o DNS (mediante el grupo DNSAdmins), o incluso la posibilidad de
consultar los registros de eventos (mediante el grupo Event Log readers), etc.

Es posible realizar, también, una delegación en el seno de Active Directory mucho más
granular, directamente a nivel de los objetos.

La estructura de un dominio Active Directory está organizada por defecto de forma

jerárquica. Es posible, en efecto, delegar tareas a nivel de un bosque, de un sitio, de un
dominio o incluso de una unidad organizativa. Además, cada objeto posee atributos con
DACL (Discretionary Access Control List) asociados, de modo que también es posible
delegar las opciones de manera muy precisa (reinicializar la contraseña del usuario,
autorizar la desactivación de una cuenta de usuario, etc.). Pasaremos a la práctica un poco
más adelante en este mismo capítulo.

Antes de comenzar con la configuración de la delegación de su Active Directory, conviene

estudiar bien las necesidades actuales a las que debe responder.

La siguiente lectura (en inglés) le permitirá ver un poco más clara la delegación de la
administración de un Active DirectoryDirectory y las buenas prácticas que debe aplicar.
Está disponible en la siguiente dirección: http://www.microsoft.com/en-
us/download/details.aspx?id=21678

2. Delegación de cuentas de usuario

Pasemos, ahora, a la práctica delegando dos acciones especialmente útiles para una hotline
y equipo de soporte informático de la empresa. Estos equipos no tienen la vocación de
realizar tareas administrativas ligadas al Active Directory, sería excesivo agregarlos al
grupo "Administradores del dominio" por ejemplo.

Entre las necesidades que expresan más a menudo estos equipos para responder a las
peticiones de los usuarios, encontrará en especial la solicitud de permiso para agregar un
usuario a un dominio Active Directory y el permiso para reinicializar las contraseñas de los
usuarios.

Las delegaciones se realizan, por lo general, sobre el total o sobre una parte de los
objetos de una unidad organizativa (u OU por Organizational Unit) o de un dominio. Esto
tiene como objetivo simplificar la administración y la gestión de los permisos de su Active
Directory. Está de más recordarle que es obligatorio guardar una traza de las delegaciones
realizadas para facilitar la administración cotidiana y las operaciones de recuperación en
caso de problemas.

Tomemos como ejemplo el departamento de hotline que quiere poder reinicializar las
contraseñas de los usuarios y desbloquear sus cuentas. Todos los usuarios de la hotline
forman parte del mismo grupo llamado HotlineUsers.

Para delegar estos permisos, Microsoft pone a su disposición el asistente de delegación.

Para ello, desde la consola Centro de administración de Active Directory (dsa.msc), sitúese
en el objeto del contenedor padre desde el nivel en que quiera realizar la delegación de
permisos. En la mayoría de casos, esta delegación se realiza a nivel de una unidad
organizativa. Haga clic con el botón derecho del ratón en el objeto y seleccione Delegar
control.
 Haga clic en Siguiente en la pantalla de bienvenida. El asistente le pide a continuación
seleccionar los usuarios o grupos para los que quiere asignar los permisos delegados. Haga
clic en Agregar y, a continuación, escriba el nombre de su grupo y haga clic en
Comprobar nombres. A continuación, haga clic en Aceptar.
Una vez agregado el o los grupos, haga clic en Siguiente.

Puede seleccionar, ahora, el nivel de permisos que quiere aplicar al objeto delegado. Puede
seleccionar entre las delegaciones predefinidas para tareas corrientes o bien Crear una
tarea personalizada para delegar.

En nuestro ejemplo, podríamos escoger las tareas predefinidas aunque éstas ofrecen
demasiados permisos en comparación con lo que queremos autorizar. Elija la opción Crear
una tarea personalizada para delegar para poder realizar una delegación más granular, y
haga clic en Siguiente.
 Seleccione delegar Sólo los siguientes objetos en la carpeta, marque Objetos Usuario y,
a continuación, haga clic en Siguiente.
 Seleccione, a continuación, el o los tipos de autorización que quiere delegar a los usuarios.
En nuestro ejemplo, el atributo Restablecer contraseña (o Reset Password, en inglés) se
utiliza para reiniciar la contraseña y los atributos Leer lockoutTime (o Read lockout Time)
y Escribir lockoutTime (o Write lockout Time) se utilizan para desbloquear una cuenta de
usuario. Los dos últimos sólo están visibles marcando la opción Específico de la propiedad
pues, como su propio nombre indica, son específicos del objeto usuario.
Una vez marcadas las tres opciones, haga clic en Siguiente.

Aparece una ventana que resume las opciones seleccionadas durante el asistente de
delegación. Haciendo clic en Finalizar se modifican las ACL en el contenedor
seleccionado.
Puede enumerar y definir una autorización directamente desde la consola de Usuarios y
Equipos Active Directory. Para ello debe activar las Características avanzadas en el menú
Ver de la consola. A continuación, visualizando las Propiedades del controlador o del
objeto delegado, aparece una pestaña Seguridad que le permite visualizar y modificar la
seguridad directamente desde este lugar.
Observe, también, que desde el Centro de administración de Active Directory (DSAC.exe),
no existe ningún asistente de delegación disponible, aunque puede visualizar la seguridad
implementada en una OU específica seleccionando la opción Ver de las propiedades de la
OU en cuestión.
Una vez realizada la delegación, es habitual que se distribuya una consola MMC
personalizada a los usuarios afectados. Para ello es necesario tener instaladas las
herramientas RSAT en los puestos de administración.

La ventaja de tener una consola MMC personalizada es que estos usuarios sólo tienen
acceso a una visión limitada del Active Directory. También es posible definir de forma
exhaustiva las acciones disponibles (en nuestro ejemplo, serían las opciones de
reinicializar las contraseñas de los usuarios y desbloquear su cuenta). Encontrará más
información acerca de la forma de crear una consola MMC personalizada en la siguiente
dirección (en inglés): http://technet.microsoft.com/en-
us/library/bb742441.aspx#XSLTsection126121120120 o también
http://social.technet.microsoft.com/wiki/contents/articles/2816.how-to-create-custom-mmc-
and-add-taskpad.aspx

Aun habiendo configurado todas sus delegaciones, se dará cuenta rápidamente de que no
siempre es sencillo encontrar el documento correcto para saber "quién tiene el permiso para
hacer qué". Microsoft incluye para ello una pestaña que le permite listar las autorizaciones
efectivas de una cuenta o de un grupo de usuarios sobre el objeto que elija (opción
disponible tanto a nivel de los permisos NTFS como a nivel de directorio). Esta opción
puede resultar muy práctica para ver con mayor claridad la delegación implementada, pero
también para paliar problemas de permisos a menudo heredados desde objetos padre
difícilmente identificables. Gracias a esta herramienta, podrá identificar fácilmente los
problemas.
 Abra las Propiedades de una cuenta de usuario presente en el contenedor que desee (por
ejemplo la unidad organizativa sobre la que haya definido su delegación en el ejercicio
anterior) y a continuación haga clic en la pestaña Seguridad - Opciones avanzadas -
Permisos efectivos. Recuerde que si utiliza la consola Usuarios y equipos de Active
Directory (dsa.msc), y la pestaña Seguridad no está presente, es necesario seleccionar las
Características avanzadas dentro de las opciones de visualización). Desde la consola
Centro de administración de Active Directory (dsac.exe), tendrá que ir a la opción
Extensiones en las Propiedades de la cuenta.

Haga clic en Seleccionar e indique la cuenta de un usuario (en nuestro ejemplo se trata de
una cuenta de usuario miembro del grupo HotlineUsers).

Se muestran, a continuación, todos los permisos que posee la cuenta de usuario sobre el
objeto seleccionado. En la captura de pantalla siguiente, vemos cómo el permiso Cambiar
contraseña está habilitado.
La delegación de tareas administrativas es, como hemos visto, un elemento importante que
puede integrar en sus procesos administrativos para delimitar de la mejor forma posible el
rol de cada uno.

Securización de la red
La securización de la red de empresa es, también, una etapa primordial de la securización
general de su infraestructura. Esta sección tiene como objetivo presentar las
funcionalidades más interesantes de Windows Server 2012 que le permitirán implementarlo
de la mejor forma posible en su infraestructura de red existente.
1. Network Access Protection

Con Windows Server 2008 R2 apareció una capa suplementaria de red llamada NAP (por
Network Access Protection). Se realiza un control de conformidad sobre todos los
servidores y puestos de trabajo (que soporten esta funcionalidad) antes de realizar cualquier
conexión a la red de producción.

Debería, de este modo, definir previamente un conjunto de requisitos previos de seguridad

(antivirus actualizado, firewall activo, etc.). Será, también, capaz de garantizar que los
equipos que se conectan a su red de empresa tienen un nivel de seguridad mínimo. Si éste
no fuera el caso, estos equipos se ponen en cuarentena en una red dedicada y no enrutada
mientras no cumplan con los requisitos previos exigidos. Encontrará más información
acerca de NAP en el capítulo Implantar los servicios de red de la empresa. Observe que tras
la aparición de Windows Server 2012 R2, la funcionalidad se ha marcado como
"potencialmente a abandonar" en las próximas versiones de Windows. Este tema se aborda
con un poco más de detalle en el capítulo Implementar los servicios de red de la empresa.

2. El Firewall de Windows

Windows Server 2012 R2 ponen a su disposición un firewall capaz de analizar a la vez el

tráfico entrante y saliente gracias a su nuevo módulo de firewall con seguridad avanzada
accesible a través de la consola MMC con el mismo nombre.

Este módulo de firewall no debe confundirse con el firewall "básico", conocido en entornos
XP y accesible mediante el comando firewall.cpl. El firewall básico no permite definir
reglas para el tráfico saliente, sino únicamente excepciones para el tráfico entrante.

Desde Windows Server 2008 R2, la consola del firewall básico ha evolucionado y
permite habilitar la protección dependiendo del tipo de red a la que está conectada la tarjeta
de red, a saber: "Dominio", "Privada" o "Pública". Cada interfaz de red tendrá asignado un
perfil de-pendiendo de las características definidas por el servicio Reconocimiento de
ubicación de red.
A continuación, seleccione las aplicaciones para las que desea autorizar el tráfico entrante.
Esto presenta una ventaja en comparación a la apertura de un puerto, pues una aplicación
autorizada abre una "brecha" únicamente durante el tiempo de ejecución de la aplicación
mientras que una regla aplicada sobre un puerto deja este puerto abierto durante todo el
tiempo y nada garantiza que la aplicación que escucha en el puerto no es, en realidad, un
malware.

También es posible configurar reglas de firewall desde una consola MMC que permita
configurar, de forma muy precisa y granular, los flujos, tanto entrantes como salientes. Esto
permite adaptarse mejor a la realidad de los requisitos en producción.

Se trata de la consola MMC Firewall con seguridad avanzada (accesible en las

Herramientas administrativas, mediante el acceso directo wf.msc o bien a través de la
opción Configuración avanzada en la consola básica del firewall). El firewall también
puede configurarse por línea de comandos mediante el argumento advfirewall del comando
netsh.

Es posible definir una configuración de firewall distinta para cada uno de los tres perfiles
de red existentes en Windows Server. La elección del tipo de perfil se realiza tras la
primera conexión de la tarjeta de red y puede encontrarse en la consola Centro de redes y
recursos compartidos. Puede cambiar esta definición más tarde, desde el Administrador
del servidor - Herramientas - Directiva de seguridad local - Directivas de gestión de
listas de red (será necesario ejecutar un "gpupdate /force" para que se tengan en cuenta, de
manera inmediata, las modificaciones realizadas en el entorno).

También puede conocer el perfil activo (y para el que se aplicarán las reglas de firewall
asociadas) directamente desde la consola MMC de configuración del firewall avanzado.

Recuerde que existen tres perfiles de firewall, son los siguientes:

• Un Perfil de dominio: se activa automáticamente cuando su equipo está conectado

a un dominio Active Directory.
• Un Perfil privado: activo cuando su equipo está conectado a una red sin dominio
Active Directory (no hay ningún controlador de dominio disponible).
• Un Perfil público: activo cuando está conectado a redes que ha considerado poco
seguras como por ejemplo cibercafés, aeropuertos, y demás lugares donde la
seguridad de red no está o está poco garantizada.

Para centralizar la configuración de las reglas de firewall en sus servidores de dominio, le

será posible (¡incluso recomendable!) utilizar directivas de grupo.

Existen dos conjuntos de directivas para ello:

Configuración del equipo - Directivas - Plantillas administrativas - Red - Conexiones
de red - Firewall de Windows: permite configurar las opciones del firewall básico,
aplicándose, de este modo, al equipo Windows XP también. Es posible precisar mucho
menos que con la siguiente directiva:

Configuración del equipo - Directivas - Configuración de Windows - Firewall de

Windows con seguridad avanzada: permite configurar reglas de firewall avanzadas como
las que vamos a ver más adelante.

A continuación, configuraremos una regla de firewall para comprobar toda la extensión de

las posibilidades propuestas. Autorice, por ejemplo, la conexión desde Internet hacia el
puerto 80/TCP de su servidor que alberga, de momento, un servidor Web Apache. Hemos
escogido expresamente un servidor Web de un fabricante externo para facilitar la
comprensión de las excepciones del firewall sobre un ejecutable, comprobando que basta
con utilizar una regla predefinida creada automáticamente.

Va a configurar, aquí, las opciones de manera local en un equipo, pero sepa que podrá
realizar la misma operación editando una directiva de grupo en el almacén descrito más
arriba.

Conéctese de forma local a un servidor o desde puesto cliente con Windows 7/8 con las
RSAT y, a continuación:

Abra la consola Firewall de Windows con seguridad avanzada (wf.msc desde el menú
Inicio - Ejecutar), y haga clic con el botón derecho del ratón en Reglas de entrada y, a
continuación, Nueva regla.

Se abre un asistente que le permite elegir el tipo de regla de firewall que desea crear. Se
ofrecen cuatro opciones:

• Programa: esta opción le permite definir el ejecutable para el que la acción

definida en la etapa siguiente se va a aplicar.
• Puerto: permite especificar un puerto o una lista de puertos TCP o UDP locales de
su equipo.
• Predefinida: regla correspondiente a un servicio de Windows (útil para puertos
abiertos de manera dinámica y aleatoria, no nos obligará a abrir todo el rango de
puertos).
• Personalizada: permite personalizar la regla para, por ejemplo, limitar la
autorización únicamente a un programa concreto por un puerto definido.
En este ejemplo, seleccione crear una regla personalizada y, a continuación, haga clic en
Siguiente.

Defina, ahora, si lo desea, el ejecutable o el servicio que desea autorizar y, a continuación,

haga clic en Siguiente. En este ejemplo, indique la ruta completa del ejecutable del servidor
Web Apache (%Program-Files%(x86)\Apache Software
Foundation\Apache2.2\bin\httpd.exe). También podrá definir el servicio Apache en esta
mista etapa del asistente haciendo clic en Personalizar y seleccionando el servicio en
cuestión
 A continuación, tiene que definir el o los puertos que quiere autorizar (o bloquear) que
respondan a sus necesidades. El puerto local se corresponde con el puerto del equipo sobre
el que se aplica el perfil de firewall. El puerto remoto es el puerto situado en el equipo que
trata de comunicarse con el equipo que tendrá aplicado el perfil de firewall. En este
ejemplo, debe autorizar el puerto 80/TCP local de su servidor para autorizar una conexión
HTTP clásica.

Observe que también es posible definir una franja de puertos para abrir.
 Es posible configurar el ámbito de la regla indicando las direcciones IP origen y destino
para las que se le quieren aplicar. En este ejemplo, puede abrir un acceso completo para
Cualquier dirección IP. Haga clic en Siguiente.

A continuación, se ofrecen tres acciones. Lo que elija se aplicará al tráfico definido en la

etapa anterior:

• Permitir la conexión: dicho de otro modo esto permite, en nuestro ejemplo,

circular al tráfico entrante hacia el servidor Web Apache.
• Permitir la conexión si es segura: permite controlar la integridad y la auten-
ticación de cada paquete enviado desde su equipo basándose en el protocolo IPSec.
Veremos este punto un poco más adelante en este capítulo en la sección Cifrado
IPSec. La opción Exigir el cifrado de las conexiones permite activar IPSec para
cifrar los paquetes durante su transmisión. El destinatario de estos paquetes debe a
su vez estar configurado para poder enviar y recibir este tipo de tráfico, sin que el
diálogo entre los dos equipos sea imposible.

• Bloquear la conexión: bloquea la condición definida anteriormente en el asistente.

En nuestro ejemplo, seleccione Permitir la conexión y, a continuación, haga clic en

Siguiente.
 Indique, a continuación, los perfiles de conexión para los que quiere aplicar esta regla y
haga clic en Siguiente para dar un Nombre a esta regla de firewall.

¡Su regla de firewall se ha creado y ya es efectiva! Aparece en la parte superior de la lista

de su consola MMC.

En Windows Server 2008 R2/2012, si elige Permitir la conexión si es segura para una
regla específica, entonces es posible editar esta regla para definir los usuarios y equipos
para los que no se aplicará esta regla.
Observe que si está habilitada la auditoría de las modificaciones de las directivas (mediante
la directiva de grupo Configuración del equipo - Directivas - Configuración de
Windows - Configuración de seguridad - Directivas locales - Directivas de auditoría),
se genera un evento con el número 2004, visible desde la consola Eventvwr.msc en el
registro Firewall que se encuentra en Registros de aplicaciones y servicios - Microsoft -
Windows - Windows Firewall With Advanced Security.

Si ha definido una directiva de auditoría avanzada (detallada en el capítulo Dominio Active

Directory y disponible, si recuerda, en Configuración del equipo - Directivas -
Configuración de Windows - Configuración de seguridad - Configuración de directiva
de auditoría avanzada), los elementos interesantes relativos al firewall son los siguientes:

• Inicio/cierre de sesión (utilícela únicamente si tiene una directiva IPsec

implementada):

• Auditar modo extendido de IPsec.

• Auditar modo principal de IPsec.
 • Auditar modo extendido de IPsec.

• Acceso a objetos:

• Auditar conexión de plataforma de filtrado.

• Auditar colocación de paquetes de plataforma de filtrado.

• Cambio en directivas:

• Auditar cambio de directiva de plataforma de filtrado.

• Auditar cambio de directiva del nivel de reglas de MPSSVC.

• Sistema:

• Auditar controlador IPsec.

• Auditar otros eventos del sistema.

Con esta directiva (en particular, Auditar conexión de plataforma de filtrado y Auditar
colocación de paquetes de plataforma de filtrado habilitadas), se produce un evento
4946 presente en el registro de Seguridad cuando se cree alguna regla de firewall.
Verá que muchos de estos elementos afectan, también, a IPsec, puesto que ambos módulos
están integrados en la misma aplicación. Este tema se aborda un poco más adelante en este
capítulo.

También es interesante saber que no se crea ningún archivo de registro por defecto. Puede
resultar útil configurarlo para facilitar la detección de cualquier ataque en su servidor
(escaneo de puertos abiertos), o la depuración que permita encontrar los puertos que es
necesario autorizar para una aplicación concreta (bastará con tener una conexión y
supervisar en el archivo de registro los paquetes que no han sido autorizados).

Para configurar el archivo de registro, haga clic con el botón derecho del ratón en Firewall
de Windows con seguridad avanzada en Equipo local - Propiedades. Haga clic en
Personalizar dentro de Registro. A continuación, puede definir una ruta y un nombre para
el archivo de registro, un tamaño máximo y el tipo de eventos que desea registrar (paquetes
ignorados y/o conexiones de red).

Observe que esta manipulación puede realizarse, también, desde la directiva de grupo y, de
este modo, desplegarla al mismo tiempo que las demás reglas configuradas.

3. Securización de las transacciones de red mediante IPsec

IPSec es un estándar de seguridad que ofrece autenticación y cifrado de las conexiones.

Ambas nociones de seguridad no son indisociables e IPSec puede ofrecer la autenticación
sin el cifrado y a la inversa. IPSec funciona sobre la capa de red del modelo OSI, y es capaz
de proteger cualquier aplicación de red.

El cifrado de las conexiones mediante IPSec hace mucho más complicado atacar un sistema
orientado a la red. Si un atacante quisiera, por ejemplo, escuchar (mediante un sniffer) la
red durante la transferencia de un archivo entre dos equipos configurados para utilizar el
cifrado IPSec, ¡le será imposible descifrar los archivos intercambiados!

La segunda ventaja del protocolo IPSec consiste en proveer una autenticación de los
participantes y garantizar la integridad de los datos durante el cifrado de red. IPSec puede,
así, autenticar a un cliente de red (mediante una autenticación Kerberos o un certificado,
por ejemplo) antes de permitir inicializar la conexión de red. El ataque de tipo "Man in the
middle" consiste en que un atacante se hace pasar por el servidor a los ojos del cliente y a la
inversa para el cliente a los ojos del servidor. De este modo puede escuchar todo el tráfico
entre ambos participantes (remitiéndolo inmediatamente al verdadero destinatario) y a
continuación recuperar la contraseña del usuario en una fase de autenticación en el dominio
Active Directory por ejemplo.

La autenticación IPSec permite impedir este tipo de ataque autenticando los participantes y
asegurando que los datos no han sido modificados durante su transporte.

Esta autenticación también puede ser muy útil para definir una replicación entre los
controladores de dominio que se encuentran en sitios diferentes y así garantizar la
integridad de la transacción.

Es preciso, también, saber que el protocolo IPSec funciona según dos modos posibles. El
modo transporte o el modo túnel.

El modo transporte de IPSec permite proteger las comunicaciones entre dos hosts de una
misma red privada o entre dos hosts que no están separados por ninguna traducción de
direcciones de red (NAT). En este último caso, puede implantar IPSec Nat Traversal (NAT-
T) con la condición de que el servidor NAT y los hosts soportan NAT-T (consulte la RFC
3947).

El modo túnel de IPSec protege las comunicaciones entre un host y una red, o de red a red.
Este modo es más flexible que el modo transporte.

Windows Server 2012 R2 permiten definir reglas de aislamiento (precisando una

autenticación) o de cifrado mediante el protocolo IPSec.

Esta configuración puede realizarse de forma muy precisa en el mismo lugar que se hacía
en las versiones anteriores de Windows Server, es decir en la directiva de grupo
Configuración del equipo - Directivas - Configuración de Windows - Configuración de
seguridad - Directivas de seguridad IP. La ventaja de esta consola es que puede definir el
tipo de tráfico IP que desea autorizar.

Si, por el contrario, tiene necesidades mucho más precisas que definir (como, por ejemplo,
implementar un filtrado IPsec en su red interna entre dos puestos de distintos
departamentos, entre controladores de dominio, etc.), las reglas de seguridad de conexión
están mucho mejor adaptadas, pues son mucho más fáciles de implementar y permiten, en
particular, filtrar el flujo autorizado a través de esta conexión IPsec.
Puede configurar sus propias reglas de seguridad de conexión desde la misma consola
MMC que el firewall de Windows avanzado.

Antes de lanzarse a realizar la configuración de las directivas IPSec, asegúrese de haber

comprendido bien y configurado sus directivas IPsec pues, sin ello, corre el peligro de
bloquear completamente el acceso a la red de este servidor. Conviene, por tanto, probar las
reglas antes de aplicarlas.

A continuación, trataremos de aplicar lo que se ha explicado más arriba con un ejemplo. En

este ejemplo, va a cifrar el tráfico entre dos equipos. Para ello, siga los pasos siguientes:

Abra la consola Firewall de Windows con seguridad avanzada (wf.msc) y, a continuación,

vaya al nivel Reglas de seguridad de conexión - Acciones - Nueva regla.

Se le ofrecen varios tipos de regla. Para tener una visión completa de las posibilidades
seleccione Personalizada y, a continuación, Siguiente.

Defina, a continuación, un punto de extremo 1 y un punto de extremo 2 correspondientes a

las direcciones IP de cada uno de los equipos. En nuestro ejemplo, el extremo 1 es la
dirección IP de nuestro servidor local (192.168.0.1) y el extremo 2 es el servidor remoto
(192.168.0.2). A continuación, haga clic en Siguiente.

Desde Windows Server 2008 R2 y Windows 7, es posible realizar una administración

dinámica de los extremos. Esta funcionalidad la utiliza en particular DirectAccess para los
usuarios móviles que poseen una dirección IP dinámica. Obtendrá más información sobre
DirectAccess en el capítulo Acceso remoto.
 Seleccione, a continuación, las condiciones de autenticación requeridas. En nuestro
ejemplo, seleccione Requerir autenticación para las conexiones entrantes y salientes
(de este modo, si los dos puestos no están configurados correctamente para dialogar
mediante IPsec, no será posible realizar ningún intercambio de información, sea cual sea el
emisor de la solicitud) y haga clic en Siguiente.

El método de autenticación utilizado se basa en el método definido en los parámetros por

defecto de IPSec. Es posible realizar esta configuración en Propiedades de Firewall de
Windows con seguridad avanzada - pestaña Configuración IPSec - Personalizar. Puede
hacer esto sin tener que cerrar el asistente en curso.

Cuando esté en este apartado, aproveche para definir la obligatoriedad del cifrado de los
datos haciendo clic en Personalizar en Protección de datos (modo rápido) y marcando la
opción Requerir cifrado para todas las reglas de seguridad de conexión que usan esta
configuración. Haga clic en Aceptar tres veces para volver a su asistente.

En este ejemplo, en la etapa Método de autenticación, haga clic en Personalizar dentro de

Opciones avanzadas. Haga clic, a continuación, en Agregar en la primera autenticación y
seleccione Clave previamente compartida (este parámetro no está recomendado en una
red de producción pero es aceptable en el marco de las pruebas de implementación).
Indique, a continuación, el valor de TestAuthentification relativo a esta clave previamente
compartida. Haga clic en Aceptar dos veces y en Siguiente.

En un entorno de producción, si los equipos están en un mismo dominio Active Directory,

se recomienda usar la autenticación Kerberos puesto que no necesita ninguna configuración
particular de los ordenadores afectados. Para equipos que no formen parte del mismo
dominio, es preciso establecer una autenticación basada en un certificado.

También es posible definir desde la consola los Protocolos y puertos sobre los que se
aplicará esta regla, lo que permite definir, de una manera todavía más precisa, el túnel IPsec
creado. Esta operación puede realizarse también mediante el comando netsh.

Defina los perfiles para los que quiere aplicar esta regla. Es posible marcar los tres perfiles.

Indique un nombre para esta regla y haga clic Finalizar.

Como hemos impuesto una autenticación en las conexiones entrantes y salientes, a partir
del momento en que haga clic en Finalizar, ya no es posible mantener la conexión entre
ambos servidores. Conviene, por tanto, crear esta misma regla en el segundo servidor. Para
comprobarlo, trate de hacer ping al equipo que posee, de momento, la directiva IPsec desde
el segundo equipo, y comprobará que no hay respuesta al ping.

Debe configurar el extremo 2 de forma similar a la directiva configurada en el extremo 1. A

continuación, comprobará que el ping sí obtiene respuesta, aunque transportado en un flujo
completamente cifrado.

Puede convencerse abriendo la consola wf.msc y, a continuación, Supervisión -

Asociaciones de seguridad.

Conclusión
Como ha podido ver, Windows Server 2012 R2 posee numerosas funcionalidades de
seguridad avanzada. Éstas no tienen por qué suponer una pérdida de productividad. En
efecto, muchos de estos parámetros de seguridad son fácilmente accesibles y
pueden administrarse de forma centralizada.

Introducción
En este capítulo aprenderá a implementar soluciones para garantizar el estado de salud de
su red una vez configurada y en producción.

Administración de la copia de seguridad

Pensar que un sistema recién implantado o que ya lo lleve un tiempo no necesita ninguna
atención es incorrecto. En efecto, es imposible evitar eventos inesperados en el conjunto del
sistema de información. Caídas de servidores, pérdidas de archivos, errores en la
manipulación humana, un incendio, etc. Todos estos elementos pueden volver inestable su
sistema informático o incluso dejarlo completamente indisponible.

Existen varias soluciones proactivas a su disposición, que le permitirán plantar cara al

"incidente". Una de ellas es la copia de seguridad. Escoger una estrategia de copia de
seguridad adaptada a las necesidades de la empresa es la mejor forma de asegurarse contra
una pérdida de los datos.

Existen distintos mecanismos de copia de seguridad:

• Completa: este método transfiere al soporte de copia de seguridad una copia de

todos los datos asociados a una copia de seguridad, independientemente de la
modificación de los datos tras la ejecución de la copia de seguridad anterior.
• Diferencial: copia todos los datos que han sido modificados desde la última copia
de seguridad completa.
• Incremental: copia todos los datos que han sido modificados desde la última copia
de seguridad, bien sea completa o incremental.

Si bien a primera vista puede parecer que las copias de seguridad incremental y diferencial
son muy parecidas, en la práctica cada una tiene sus ventajas y sus inconvenientes.

Una copia de seguridad diferencial necesita menos medios para realizar una restauración.
En efecto, basta con usar la última copia de seguridad completa y la última copia de
seguridad diferencial.

Ventajas: la restauración de datos es más rápida.

Inconvenientes: el volumen de datos de copia de seguridad es mayor y las copias de

seguridad tardan más en realizarse.

La copia de seguridad incremental toma menos tiempo. Sólo almacena aquellos elementos
que se hayan visto modificados desde la última copia de seguridad (completa o
incremental). El volumen de la copia de seguridad será menor.

Ventajas: las copias de seguridad son más rápidas y necesitan menos capacidad en los
medios de almacenamiento.

Inconvenientes: la restauración es más lenta pues será necesario utilizar más medios. La
restauración requiere la última copia de seguridad completa, más todas las copias de
seguridad incrementales que le siguen hasta el punto en que sea necesario restaurar.
En cualquier caso, es necesario que preste mucha atención a sus copias de seguridad
completas. Son las que van a determinar el comportamiento de las siguientes copias de
seguridad.

1. Windows Server Backup

Windows integra, desde la versión 3.1, una herramienta de copia de seguridad llamada
NTBACKUP. Con la llegada de Windows Server 2008, se ha visto remplazada. El nombre
de su sucesor es: WSB (Windows Server Backup).

Ya no vuelva a escribir más ntbackup en el menú Ejecutar, pues en caso contrario recibirá
un mensaje de error indicando que la herramienta ya no existe

Windows Server Backup proporciona una solución que permite responder a las necesidades
de copia de seguridad y de restauración. Puede utilizarla para realizar una copia de
seguridad completa de un servidor, también para realizar una copia de seguridad de ciertos
volúmenes, ciertas aplicaciones o incluso para guardar solamente el estado del sistema.

En caso de producirse algún problema grave, podrá realizar una recuperación bare metal
(restauración partiendo de 0).

Puede utilizar Windows Server Backup para crear y administrar copias de seguridad de un
equipo local o un equipo remoto. Es posible planificar copias de seguridad para que se
ejecuten de manera automática. También es posible realizar copias de seguridad puntuales.

Windows Server Backup presenta algunos inconvenientes, entre ellos:

• Es imposible realizar una copia de seguridad de un servidor Exchange Server (salvo

para la versión Exchange Server 2007 SP2 que incluye un plug-in que habilita la
realización de copias de seguridad).
• Es imposible realizar copias de seguridad sobre lectores de banda magnética.
• Es imposible realizar copias de seguridad en memorias flash USB o llaves USB.
• Sólo puede realizarse copia de seguridad de volúmenes locales en NTFS.

La versión de Windows Server 2012 aporta varios cambios importantes y algunos

beneficios a la herramienta Windows Server Backup:

• Realizar una copia de seguridad o restaurar máquinas virtuales individuales en un

host Hyper-V. La versión de Windows Server 2012 R2 permite realizar la copia de
seguridad de máquinas virtuales en Linux desde el host.
• Mejora de la gestión de las versiones de copia de seguridad y de la retención:
realizando una copia de seguridad sobre un disco o volumen, ahora tiene la
posibilidad de especificar una política de borrado para determinar cuáles son las
copias de seguridad que quiere mantener, de cara a gestionar su espacio en disco.
• Soporte a copias de seguridad de volúmenes de almacenamiento compartidos (CSV:
Cluster Shared Volumes).
 • Externalización de la copia de seguridad sobre la plataforma Online Windows
Azure (si dispone de un abono. Puede consultar el siguiente enlace si desea más
detalles: http://www.windowsazure.com/es-es/services/backup/).

WSB no permite restaurar copias de seguridad realizadas con NTBackup. Existe no

obstante una versión disponible para su descarga de la herramienta compatible con
Windows Server 2008 R2 y dedicada a las restauraciones:
http://support.microsoft.com/kb/974674

a. Instalación de Windows Server Backup

He aquí las etapas para realizar la instalación de Windows Server Backup :

En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y

características.

Haga clic en Siguiente.

Seleccione la opción Instalación basada en roles o características y, a continuación,

haga clic en Siguiente.

Seleccione su servidor y, a continuación, haga clic en Siguiente.

En la lista Roles del servidor, haga clic en Siguiente.

En la etapa Características marque la opción Copias de seguridad de Windows Server

y, a continuación, haga clic en Siguiente.
 En la pantalla de confirmación, verifique que se han seleccionado las características
deseadas y, a continuación, haga clic en Instalar.

Una vez finalizada la instalación, haga clic en Cerrar.

Para instalar la herramienta de copia de seguridad también puede utilizar el comando

siguiente: Install-WindowsFeature Windows-Server-Backup

b. Creación de una copia de seguridad completa planificada

A continuación, configurará su primera copia de seguridad utilizando el asistente. El

objetivo consiste en realizar una copia de seguridad completa de la máquina. Esta copia de
seguridad se realizará de forma automática todas las noches a las 23h.

Requisitos previos: disponer de un segundo disco duro sobre el que realizar la copia de
seguridad.

He aquí las etapas que debe seguir:

 En la consola Administrador del servidor, haga clic en Herramientas - Copia de
seguridad de Windows Server.

En el panel izquierdo, seleccione Copia de seguridad local.

En la pantalla Copia de seguridad de Windows Server (Local), en el panel derecho, haga

clic en Programar copia de seguridad.

Haga clic en Siguiente.

En la pantalla de selección, seleccione la opción Servidor completo (recomen-dado).

Haga clic en Siguiente.

En la lista desplegable Seleccionar hora del día, seleccione 23:00 y, a continuación, haga
clic en Siguiente.
 En la pantalla que permite seleccionar un tipo de destino, haga clic en realizar copia de
seguridad En un volumen y, a continuación, haga clic en Siguiente.
Existen tres opciones:

• En un disco duro dedicado para copias de seguridad (recomendado): se trata de

un disco local que estará dedicado a la copia de seguridad y no se utilizará para
almacenar archivos de otro tipo.
• En un volumen: ofrece la posibilidad de realizar la copia de seguridad de un
servidor en uno de los volúmenes de datos. El volumen de destino se excluirá
automáticamente de la copia de seguridad, donde puede seguir almacenando datos.
• En una carpeta de red compartida: permite realizar una copia de seguridad en un
espacio de almacenamiento compartido (lo cual supone una buena opción puesto
que separa la copia de seguridad de los datos salvaguardados), aunque presenta el
inconveniente de que conserva una única copia de seguridad que se eliminará cada
vez. Puede almacenar copias de seguridad únicas o copias de seguridad
planificadas.

Haga clic en Agregar.

Seleccione su segundo volumen de datos y, a continuación, haga clic en Aceptar.

 Aparece un mensaje de advertencia que le indica que el volumen de destino se excluirá de
la copia de seguridad. Haga clic en Aceptar.

Haga clic en Siguiente.

Verifique las opciones seleccionadas y, a continuación, haga clic en Finalizar.

Una vez creada la programación de la copia de seguridad, haga clic en Cerrar.

Su copia de seguridad queda, así, operativa.

c. Creación de la copia de seguridad planificada de una (o varias) carpeta(s)

El objetivo es, aquí, realizar una copia de seguridad sólo de ciertas carpetas de la máquina
servidor. Esta copia de seguridad se realizará de forma completa todos los días a las 21h.

En la consola Administrador del servidor, haga clic en Herramientas - Copia de

seguridad de Windows Server.

En el panel izquierdo, seleccione Copia de seguridad total.

En la consola Copia de seguridad de Windows Server (Local), en el panel derecho, haga

clic en Planificación de la copia de seguridad.

Haga clic en Siguiente.

Seleccione la opción Personalizada y, a continuación, haga clic en Siguiente.

 Haga clic en Agregar elementos para seleccionar los archivos/carpetas que desea incluir
en la copia de seguridad.

En la ventana de selección, marque la carpeta Users y, a continuación, haga clic en

Aceptar.
A continuación, haga clic en Siguiente.

Deje la planificación por defecto (Una vez al día a las 21h) y, a continuación, haga clic en
Siguiente.

Seleccione la opción de hacer la copia de seguridad En un volumen y, a continuación,

haga clic en Siguiente.

Haga clic en Agregar.

Seleccione su segundo volumen y, a continuación, haga clic en Aceptar.

Haga clic en Siguiente.

Verifique las opciones marcadas y, a continuación, haga clic en Finalizar.

Una vez creada la programación de la copia de seguridad, haga clic en Cerrar.

d. Herramientas asociadas a WSB y copias de seguridad únicas

WSB ofrece, también, la posibilidad de realizar copias de seguridad no planificadas. Esto

puede ser interesante antes de cualquier operación que pueda necesitar de una vuelta atrás
(instalar un nuevo producto, eliminar un rol, etc.). Estas copias de seguridad únicas
permiten a su vez no incluir obligatoriamente el estado del sistema en la copia de seguridad.
Siguiendo el asistente Hacer copia de seguridad una vez que se encuentra en Copia de
seguridad de Windows Server, puede:

• seleccionar una ubicación de red para realizar la copia de seguridad;

• escoger entre una copia de seguridad realizada mediante VSS (Volume Shadow
Copy) o una copia de seguridad completa VSS.

La copia VSS es útil si utiliza otro sistema de copia de seguridad. En efecto, esto deja los
atributos de los archivos intactos. De este modo las copias de seguridad que se realicen con
su programa dedicado no se verán afectadas en su rotación. VSS permite a su vez
salvaguardar archivos abiertos.

La copia de seguridad completa VSS es útil cuando sólo utiliza Windows Server Backup
para realizar sus copias de seguridad. Éste, una vez terminada la ejecución, actualiza el
histórico de copia de seguridad de los archivos.

La herramienta por línea de comandos wbadmin está disponible con las versiones Core y
Completa de Windows Server 2012. Permite realizar las mismas tareas que con la interfaz
gráfica (observará que el título de la ventana de copia de seguridad Windows Server se
llama: wbadmin - Copia de seguridad de Windows Server) del asistente de copia de
seguridad o incluso más.

Algunos comandos útiles con wbadmin.exe:

• wbadmin enable backup: permite crear y administrar las copias de seguridad

programadas.
• wbadmin start systemstatebackup: permite realizar una copia de seguridad del
estado del sistema.
• wbadmin start backup: permite ejecutar una copia de seguridad una vez.
• wbadmin get versions: permite obtener los detalles de una copia de seguridad que
ya se ha realizado.
• wbadmin get items: permite ver cuáles son los elementos que contiene un archivo
de copia de seguridad.

Wbadmin tiene la ventaja de permitir incluir los comandos en procesos batch. Estos batch
pueden ejecutarse como tareas programadas. A su vez, existe la posibilidad de ejecutar
rápidamente una copia de seguridad sobre un almacenamiento en red. Por ejemplo, la
siguiente línea de comando permite realizar la copia de seguridad del volumen E en una
carpeta compartida de otro equipo:

Wbadmin start backup -backuptarget:\\OTROSERVIDOR\CarpetaCompartida -

include:E:
-User:backupadmin@MiEmpresa.Priv -Password:P@ssw0rd

Si desea obtener más información acerca de la sintaxis de wbadmin, vaya a la siguiente

dirección: http://technet.microsoft.com/en-us/library/cc754015.aspx
Desde Windows Server 2008, Microsoft ha restringido significativamente las capacidades
de su herramienta de copia de seguridad integrada en beneficio de su producto System
Center Data Protection Manager (DPM). Este producto, independiente y de pago, ofrece
muchas más funcionalidades que WSB. Para obtener más información sobre DPM:
http://technet.microsoft.com/en-us/library/hh758173.aspx

e. Las instantáneas

Como complemento a las copias de seguridad, puede utilizar las instantáneas (llamadas
comúnmente Volume Shadow Copy). Las instantáneas permiten restaurar los archivos que
se encuentran en las carpetas compartidas de red. Esta restauración se realiza de forma muy
simple y rápida.

El principio de funcionamiento es el siguiente: el servidor inicia una captura del estado de

los archivos en un momento dado y otra captura más tarde en el tiempo. El sistema va a
comparar, a continuación, las diferencias entre ambos estados. Si un archivo se ha
suprimido, modificado u otro, entonces el sistema guardará una copia. Es posible realizar
varias planificaciones para un mismo volumen en el mismo día. La restricción es que el
sistema sólo conserva 64 versiones de un archivo.

Las instantáneas están activas a nivel de los volúmenes. Para implementarlas:

En la consola Administrador del servidor, haga clic en Herramientas - Administración

de equipos.

En el panel de Navegación, despliegue Almacenamiento - Administración de discos.

Haga clic con el botón derecho en el volumen para el que quiere activar las instantáneas y,
a continuación, seleccione Propiedades.

Haga clic en la pestaña Instantáneas.

Desde esta ventana puede activar o desactivar las instantáneas. También puede crear una
instantánea de forma manual simplemente haciendo clic en el botón Crear ahora.

La configuración avanzada se puede administrar haciendo clic en Configuración... y tras

haber seleccionado un volumen. Una vez dentro puede especificar la programación de la
instantánea, su área de almacenamiento así como su tamaño máximo.

Haga clic en Configuración.

Seleccione un tamaño límite (o ilimitado) para realizar las instantáneas.

Seleccione la ubicación del almacenamiento (puede ser interesante seleccionar otro medio
de almacenamiento distinto al volumen desde el que se hacen las instantáneas para utilizar
un medio de almacenamiento de bajo coste como, por ejemplo, un disco duro USB).

Haga clic en Programación.

Por defecto, las instantáneas se realizan todos los días laborables 2 veces al día (a las 7h y a
las 12h).

Ajuste estos valores en función de sus necesidades y teniendo en mente que sólo se
conservarán 64 versiones de la instantánea.

Haga clic en Aceptar para validar la programación.

Haga clic en Aceptar para validar la configuración de la instantánea.

Puede hacer clic en el botón Crear para crear una instantánea de manera inmediata.

Si intenta ver el contenido de esta instantánea, verá que está vacía. En efecto, las
instantáneas utilizan una imagen en un instante T para realizar la copia de seguridad de los
datos que se han modificado desde la última instantánea. Un archivo que ya existiera en la
instantánea antes de implementar la copia de seguridad y que jamás se haya modificado,
nunca podrá verse en las versiones anteriores.
Para restaurar una instantánea, vaya a la pestaña Versiones anteriores en las propiedades
de una carpeta padre o, directamente, sobre el archivo deseado si todavía está presente (a
continuación se muestra una captura de pantalla que ilustra esta posibilidad).

2. Restaurar los datos

Ahora que sabe cómo realizar una copia de seguridad de sus datos, vamos a ver cómo
restaurarlos. Para restaurar información utilizando WSB, debe ser miembro del grupo
Operadores de copia de seguridad o del grupo Administradores del equipo.

a. Restaurar archivos y/o carpetas

Para restaurar una carpeta:

 En la consola Administrador del servidor, haga clic en Herramientas - Copia de
seguridad de Windows Server.

En el panel derecho, haga clic en Recuperar.

Especifique el servidor sobre el que se encuentra la copia de seguridad que se utilizará para
recuperar los datos y, a continuación, haga clic en Siguiente.

Seleccione, utilizando el calendario, la copia de seguridad que desea restaurar y, a

continuación, haga clic en Siguiente.

Seleccione el tipo de dato que desea recuperar y, a continuación, haga clic en Siguiente.

Seleccione el elemento (archivos o carpetas) que desea restaurar y, a continuación, haga

clic en Siguiente.

Seleccione los elementos que desea recuperar y, a continuación, haga clic en Siguiente.

Especifique, a continuación, el lugar donde desea restaurar la información, si desea borrar

los archivos de destino, o bien realizar una copia, o no recuperar archivos que ya existan en
el espacio de destino. Especifique, a su vez, si deben restaurarse los permisos NTFS.

Haga clic en Siguiente.

 En la pantalla de confirmación, verifique los elementos seleccionados y, a continuación,
haga clic en Recuperar.

Una vez recuperados los elementos, haga clic en Cerrar.

b. Restaurar el estado del sistema

Si ocurriera un fallo importante en el sistema, debería restaurarlo. Esta operación es similar

a una restauración completa, aunque la diferencia es que no restaura los volúmenes que
contienen datos. Sólo se restauran los volúmenes críticos.

Esta operación puede realizarse sobre la misma máquina o, en el caso de un reemplazo o

renovación de hardware, sobre una máquina diferente. Preste atención, la máquina de
reemplazo debe poseer características de hardware similares.

La restauración del sistema es la forma más práctica de reparar los roles de servidores
corruptos o incluso de restaurar Active Directory. Preste atención, no es posible realizar
una restauración parcial del estado del sistema.

La restauración del estado del sistema sobre un controlador de dominio realiza una
restauración no autoritaria de Active Directory.

He aquí las etapas que debe seguir para restaurar el estado de su sistema:

Inicie su servidor desde una imagen de instalación (DVD, llave USB, red) de Windows
Server 2012.

Seleccione los parámetros regionales y, a continuación, haga clic en Siguiente.

Haga clic en Reparar el equipo.

Haga clic en Solucionar problemas.

Haga clic en Recuperación de imagen del sistema.

Seleccione su sistema operativo.

Si no existe ninguna copia de seguridad disponible en local, aparecerá el siguiente mensaje:

Haga clic en Cancelar.

Haga clic en Siguiente para seleccionar una imagen de sistema.

Haga clic en Opciones avanzadas.

Haga clic en Buscar una imagen de sistema en la red.

Aparece la siguiente advertencia, haga clic en Sí.

Al utilizarse una imagen almacenada en la red para restaurar el sistema, es preciso disponer
de un servidor DHCP que permita obtener una dirección IP válida en la red de trabajo.

Indique la ubicación de la copia de seguridad y, a continuación, haga clic en Aceptar.

Indique la información de identificación para conectarse al recurso compartido (en este

ejemplo, el recurso compartido se encuentra en un servidor llamado DC1) y, a
continuación, haga clic en Aceptar.
Seleccione la copia de seguridad que desea restaurar y, a continuación, haga clic en
Siguiente.
 Seleccione, a continuación, las opciones facultativas (para dar formato y reparticionar los
discos, instalar controladores, etc.) y, a continuación, haga clic en Siguiente.

Haga clic en Finalizar, y, a continuación, haga clic en Sí para iniciar la restauración.

Espere a que el sistema reinicie automáticamente para que la restauración termine por
completo.

3. Almacenamiento
a. Conjunto RAID

Existe un método alternativo de asegurar los datos. Muy extendida en los entornos de
servidores y en expansión en entornos particulares, esta tecnología se llama RAID
(Redundant Array of Independent Disks).

Desde un punto de vista simplificado, esta tecnología permite almacenar la información

sobre discos duros múltiples con el objetivo de mejorar, en función del tipo de RAID
seleccionado, la tolerancia a fallos y/o el rendimiento del conjunto.

En este capítulo sólo vamos a describir los tres niveles de RAID estándar propuestos por
Windows Server 2012 R2, a saber: RAID 0, RAID1 y RAID5. En función del nivel de
RAID elegido, obtendrá:
 • Bien un sistema de reparto de carga que mejora su rendimiento (RAID 0).
• Bien un sistema de redundancia que dota al almacenamiento de datos de cierta
tolerancia a fallos de hardware (RAID 1).
• O bien ambas características a la vez (RAID 5).

El sistema RAID es capaz por tanto de gestionar el reparto de carga y la coherencia de los
datos. Este sistema de control puede ser puramente lógico, o utilizar un hardware dedicado.

En RAID lógico, el control del RAID se realiza íntegramente en la capa lógica del sistema
operativo. Esta capa se intercala entre la capa de abastecimiento de hardware (controlador)
y la capa del sistema de archivos.

En el caso de RAID por hardware, existe una tarjeta o un componente dedicado a la gestión
de las operaciones. Desde el punto de vista del sistema operativo, el controlador RAID por
hardware ofrece una virtualización completa del sistema de almacenamiento. El sistema
operativo considera cada volumen RAID como un disco que no conoce sus constituyentes
físicos.

Características de los niveles de RAID:

• El RAID0, o conjunto dividido, es el que tiene mejor rendimiento; por el contrario

es el menos fiable. Ofrece un conjunto de discos. Por ejemplo tres discos de 500 GB
en RAID0 le ofrecen un volumen de 1,5 TB. El inconveniente principal de esta
tecnología, si uno de los discos falla, es que los datos situados en los demás también
se pierden.
• El RAID1, o espejo, proporciona buenos rendimientos en la escritura asegurando
tolerancia a fallos. En el caso de dos discos en RAID1, la información se escribe de
forma idéntica en ambos. Dos discos de 500 GB en RAID1 le ofrecen un volumen
de 500 GB. El segundo disco sirve como «réplica» del primero. El rendimiento
global es algo inferior a un RAID0.
• El RAID5, o agregado de conjuntos con paridad es el que presenta mejor
rendimiento en términos de lectura. La información se reparte en los distintos discos
de modo que no se pierdan datos en caso de fallo de uno de los discos. Este nivel
RAID requiere un mínimo de tres discos. Tres discos de 500 GB configurados en
RAID5 le ofrecen un espacio de almacenamiento de 1 TB.

En Windows Server 2012, las operaciones de configuración de los volúmenes en RAID se

hacen desde la consola Administración de equipos. A continuación, hay que navegar en la
arborescencia de almacenamiento. Las opciones propuestas le permiten agregar fácilmente
un volumen en espejo o crear un conjunto agregado.

Para poder configurar volúmenes en RAID en Windows Server 2012, es preciso haber
convertido los discos como dinámicos previamente.
Windows Server 2012 y Windows Server 2012 R2, igual que sus versiones anteriores, no
permite configurar el volumen de sistema en RAID 5.

b. Espacios de almacenamiento

Los espacios de almacenamiento, aparecidos con Windows Server 2012, proveen

soluciones de almacenamiento rentables, altamente disponibles, con capacidad de
evolución y flexibles para despliegues de soluciones de almacenamiento críticas (virtuales
o físicas) en la empresa.

Esta tecnología permite agrupar discos físicos y crear discos virtuales sobre ellos. Para las
pequeñas empresas, los espacios de almacenamiento ofrecen la posibilidad de crear un
almacenamiento compartido de bajo coste.

Si bien las funcionalidades son parecidas a las de una SAN (Storage Area Network), los
espacios de almacenamiento son, no obstante, mucho más flexibles de utilizar.

Otra ventaja del uso de espacios de almacenamiento se presenta cuando necesita reconstruir
un disco físico defectuoso. En los sistemas RAID tradicionales, esto puede llevar un tiempo
considerable. Con Windows Server 2012 R2, verá estos tiempos considerablemente
reducidos gracias a una técnica de reconstrucción en paralelo. Este proceso utiliza los
discos sanos restantes para reponer los datos que estaban almacenados sobre el disco
defectuoso. Resulta extremadamente práctico, en lugar de utilizar discos hot spare, utilizar
en su lugar discos de reserva en el espacio de almacenamiento, los cuales pueden
explotarse, de este modo, mediante procesos de reconstrucción en paralelo. Esto permite no
sólo ofrecer un mejor rendimiento de entrada/salida para la actividad de almacenamiento de
la producción (a diferencia de un RAID que suele degradar sobre un sistema SAN clásico)
sino también hacer que su empresa sea menos vulnerable mientras se ejecuta un proceso de
reconstrucción (por ejemplo, durante la reconstrucción de un RAID5 degradado debido a
que un segundo disco se ha vuelto irreparable). Como demostración, Microsoft muestra, en
una sesión TechEd, la reconstrucción de un RAID compuesto por ocho discos de 3 TB en
50 minutos con una tasa de transferencia superior a 800 MB/s.

Windows Server 2012 R2 incluye otras mejoras con los espacios de almacenamiento, en
particular:

• Storage Tiers: en un entorno con un almacenamiento mixto de discos rápidos (de

tipo SSD) y discos menos rápidos (de tipo SATA), el sistema será capaz de medir,
automáticamente, la velocidad de los discos y su actividad con el fin de redirigir los
flujos de almacenamiento hacia aquellos discos que poseen un mejor rendimiento,
todo de forma transparente. Si la información almacenada resulta poco utilizada, se
desplazará hacia el almacenamiento menos rápido, y a la inversa, si se trata de
información accedida con frecuencia.
• Write-back cache: basado en el mismo principio que el Storage Tiers, cuando se
detectan picos de actividad, el sistema podrá utilizar el almacenamiento rápido
 (SSD) antes de escribir en los discos clásicos para actuar como buffer e impedir una
pérdida de información.
• Storage QoS (Storage Quality of Service): esta funcionalidad se habilita en la
capa vhdx para permitir limitar las IOPS (Input/Output Operations Per Second)
máximas en un disco duro virtual. Es, también, posible definir contadores para
enviar notificaciones cuando las IOPS mínimas para un disco no se están
respetando.

4. Nuevo sistema de archivos

a. Resilient File System (ReFS)

A pesar de las numerosas ventajas que ofrece NTFS respecto a los primeros sistemas de
archivos FAT, existe desde 1993. Muchos usuarios de productos Windows Server esperan,
desde hace ya bastante tiempo, una evolución del sistema de archivos del sistema operativo
de Microsoft.

Windows Server 2012 aporta este nuevo sistema de archivos: ReFS, o sistema de
archivos resiliente, que tiene en cuenta muchas funcionalidades de NTFS aunque abandona
algunas de ellas como, por ejemplo, la compresión de archivos, el sistema EFS (Encrypting
File System) y las cuotas de disco. A cambio, ReFS ofrece la verificación de datos y la
corrección automática.

Este nuevo sistema de archivos se ha elaborado, especialmente para gestionar cantidades

enormes de datos. Se ha diseñado para funcionar con espacios de almacenamiento lógico
reducibles/extensibles. El nuevo sistema de archivos favorece su capacidad de evolución,
teniendo en cuenta hasta 264 clústeres o lo que es lo mismo, en teoría, ¡volúmenes de hasta
1 YB (Yottabyte)!

Este nuevo sistema de archivos ReFS puede detectar automáticamente la corrupción de

datos y realizar reparaciones necesarias sin tener que desconectar el volumen. CHKDSK se
convierte, por lo tanto, en una herramienta obsoleta con este sistema de archivos, ¡se
terminaron los checkdisk interminables!

Los objetivos principales de ReFS son:

• Mantener un grado elevado de compatibilidad con un subconjunto de

funcionalidades NTFS. Las funcionalidades que se han adoptado se conservan,
eliminando aquellas que aportan un valor mínimo a cambio de una complejidad
importante en el sistema de archivos.
• Verificar y corregir automáticamente errores en los datos. Los datos pueden
corromperse debido a una serie de causas y deben poder verificarse y, si es posible,
repararse automáticamente.
• Optimizar la capacidad de evolución del almacenamiento.
• No perder, jamás, la disponibilidad del sistema de archivos. Por ejemplo, en el caso
de que ocurra algún problema de corrupción de datos, supone una ventaja aislar el
 defecto permitiendo el acceso al resto del volumen. Debe ser posible recuperar la
máxima cantidad de datos posible en cualquier momento y siempre en línea.
• Ofrecer una arquitectura de resiliencia completa, extremo a extremo, cuando se
utiliza de forma conjunta con espacios de almacenamiento.

Las funcionalidades claves de ReFS son las siguientes (observe que algunas de estas
funcionalidades se ofrecen junto con los espacios de almacenamiento):

• Integridad de los metadatos con sumas de control (checksums).

• Aportar un modelo robusto de escritura transaccional para las actualizaciones de los
discos (también conocido como copy-on-write).
• Soporte para grandes volúmenes, archivos y carpetas. ReFS está diseñado para
funcionar con juegos de datos extremadamente grandes (principalmente en cantidad,
observe que la longitud de las rutas también se ha alargado).
• Puesta en común del almacenamiento y la virtualización de espacios de
almacenamiento para facilitar la gestión del sistema de archivos.
• Entrelazado de datos para un buen rendimiento (es posible administrar el ancho de
banda) y una redundancia para la tolerancia a fallos.
• Limpieza de los discos para la protección contra los errores de discos latentes.
• Resiliencia frente a la corrupción para obtener la disponibilidad de volumen
máxima.
• Pools de almacenamiento compartidos entre las máquinas para obtener la tolerancia
a fallos y un reparto de carga suplementario.

Es posible seleccionar este formato de sistema de archivos en el momento en que formatee

un volumen.

Windows Server 2012 no permite convertir un volumen NTFS al formato ReFS.

b. Desduplicación de datos

Presentación de la desduplicación de datos

En la empresa, el volumen de datos basados en archivos aumenta relativamente rápido. Si

bien el coste del almacenamiento en disco duro ha bajado considerablemente, éstos no
evolucionan lo suficientemente rápido como para compensar dicho crecimiento.

El objetivo de la desduplicación de datos es almacenar más datos en un espacio limitado

cortando los archivos en fragmentos de tamaño variable (de 32 a 128 KB), identificando
aquellos segmentos duplicados y conservando una copia única de cada segmento. Las
copias redundantes del segmento se remplazan por una referencia de la copia única, y los
segmentos se organizan en archivos de contenedor y los contenedores se comprimen para
ofrecer una optimización del espacio ocupado.

Para aclarar el funcionamiento, tomemos el ejemplo de dos archivos de texto (Archivo 1 y

Archivo 2) en los que existe una porción idéntica. Simplificando su contenido, veamos a
qué podría corresponderse:

Cada archivo posee su propia información: nombre, atributos, permisos, etc. Pero también
su propio contenido. Si bien los archivos son, en parte, idénticos (secciones A y B), las
porciones similares se almacenan dos veces.

Con la desduplicación de datos, el sistema separa la parte de Metadatos de la parte de

Datos. Se modifican completamente los archivos y se reescriben para crear un puntero, en
cada archivo, hacia su contenido (véase la ilustración que aparece a continuación).
El sistema detectará, en primer lugar, que el contenido ya existe y está almacenado y
clasificado. No almacenará, de hecho, para el segundo archivo más que la parte que no
estuviera registrada previamente en el espacio de almacenamiento, en este caso el segmento
Z.

Funcionalidades clave de la desduplicación de datos

Windows Server 2012 R2 provee una desduplicación de datos mejorada gracias a las
siguientes funcionalidades:

• Optimización de la capacidad: la desduplicación de datos, en Windows

Server 2012, permite almacenar más datos en un espacio físico inferior. La
desduplicación de datos se basa en una segmentación de tamaño variable en sub-
archivos y en la compresión de los datos. Utilizadas de manera conjunta, ambas
tecnologías permiten dividir el almacenamiento entre dos en servidores de archivos
genéricos y entre 20 (como máximo) en datos de virtualización.
• Capacidad de evolución y rendimiento: la desduplicación de datos de Windows
Server 2012 permite una gran capacidad de evolución, siendo eficaz en términos de
uso de los recursos, y es no intrusiva. Esta funcionalidad puede ejecutarse de
manera simultánea en decenas de grandes volúmenes de datos clave sin afectar a las
demás cargas de trabajo en el servidor, aplicando límites a los recursos de la unidad
central y controlando la memoria consumida. Además, los usuarios con poder
tendrán total flexibilidad para fijar las horas de ejecución de la desduplicación de
datos, especificar los recursos disponibles a tal efecto y establecer directivas de
selección de archivos.
• Fiabilidad e integridad de los datos: cuando se aplica la desduplicación de los
datos, es vital mantener su integridad. Windows Server 2012 explota la suma de
control, la coherencia y la validación de identidad para garantizar la integridad de
los datos. En el caso de datos o metadatos que posean un gran número de
referencias, la desduplicación de datos de Windows Server 2012 asegura la
redundancia de la información conservando varias copias del archivo con el
objetivo de permitir recuperarlo en caso de que se corrompa.
 • Eficacia del ancho de banda compatible con BranchCache: cuando asocia
BrachCache a la desduplicación de datos, se aplican las mismas técnicas de
optimización a los datos que se transfieren por la red extendida a una filial. Esto
permite disfrutar de unas descargas de archivos más rápidas y una reducción de
consumo en el ancho de banda.
• Optimización de la gestión con herramientas familiares: Windows Server 2012
dispone de una funcionalidad de optimización integrada con el Administrador del
servidor y con Windows PowerShell. Los parámetros por defecto pueden
traducirse en ahorros inmediatos. Su configuración puede, incluso, mejorar estas
ganancias. Utilice fácilmente los comandos de Windows PowerShell para iniciar o
programar una tarea de optimización posterior.

Windows Server 2012 y 2012 R2 no permiten configurar la desduplicación de datos en un

volumen ReFS.

Mejoras aportadas por Windows Server 2012 R2

• Optimización de archivos abiertos (a diferencia de Windows Server 2012, que no

soporta el procesamiento de archivos abiertos y, por tanto, bloqueados).
• Mejora del rendimiento de lectura/escritura: los archivos desduplicados se abren, en
lo sucesivo, de forma más rápida.
• Mejora de los resultados obtenidos: la ganancia obtenida mediante la desduplicación
es más importante.
• Soporte de archivos VHD para VDI (Virtual Desktop Infrastructure): con Windows
Server 2012, las recomendaciones eran no habilitar la desduplicación en un servidor
Hyper-V. La filosofía es, en lo sucesivo, separar el almacenamiento de los nodos
miembros del clúster en un servidor dedicado. Es, en adelante, posible habilitar la
desduplicación de archivos de máquinas virtuales sobre este servidor de
almacenamiento.
• Soporte de volúmenes compartidos de clúster (CSV : Cluster Shared Volumes):
Windows Server 2012 no soporta la activación de la desduplicación en volúmenes
CSV. Con Windows 2012 R2 es posible, aunque conservando el principio del
almacenamiento en un servidor de archivos (como con VDI) y no asociado
directamente (fibra, iSCSI).

Limitaciones de la desduplicación de datos

Las pruebas muestran buenos resultados en lo que afecta a la desduplicación de datos (no
sólo en tecnologías Microsoft), aunque se basan, sin duda, en casos particularmente
optimistas.

Antes de su implementación, conviene tener en cuenta los siguientes elementos:

 • El rendimiento de las copias de seguridad/restauraciones de datos en volúmenes
muy grandes son, prácticamente, incalculables: los rendimientos vinculados a estas
operaciones se encuentran, no obstante, mejorados, sin contar el tiempo de
indisponibilidad propio de una restauración en caso de ocurrir algún error
importante.
• La eficacia de la desduplicación de datos en volúmenes muy grandes está muy
limitada en casos, por ejemplo, de datos estructurados como Exchange o SQL y está
mejor dirigida a estructuras de tamaño pequeño o mediano.
• Despilfarro de recursos: en el caso de que pocos datos puedan desduplicarse, el
ciclo de trabajo del proceso causará una carga de trabajo en la máquina inútil, con
pocos o ningún resultados.
• Poco o ningún control sobre el proceso: no existe, a día de hoy, la posibilidad de
afinar el comportamiento del proceso o incluso de intervenir manualmente sobre él.

Implementación de la desduplicación de datos

En un servidor de archivos Windows Server 2012, la funcionalidad de desduplicación de

datos no está disponible por defecto. Va a ser necesario, por lo tanto, instalarla siguiendo
los siguientes pasos:

En la consola Administrador del servidor haga clic en Administrar - Agregar roles y

características.

En la pantalla Antes de empezar, haga clic en Siguiente.

Seleccione Instalación basada en roles o características y, a continuación, haga clic en

Siguiente.

Seleccione su servidor en la lista y, a continuación, haga clic en Siguiente.

Despliegue el árbol Servicios de archivos y almacenamiento - Servicios de iSCSI y

archivo y, a continuación, marque la opción Desduplicación de datos.

Haga clic en Siguiente.

En la etapa de selección de características, haga clic en Siguiente.

Haga clic en Instalar.

Una vez instalada la funcionalidad, haga clic en Cerrar.

Es momento de configurar la desduplicación de datos en los volúmenes deseados. Para ello:

Se recomienda encarecidamente realizar copias de seguridad regulares de los datos
importantes durante la implementación de la desduplicación.

En la consola Administrador del servidor, en el panel de navegación, haga clic en

Servicios de archivos y almacenamiento.

Haga clic en Volúmenes.

Haga clic con el botón derecho sobre el volumen en el que desea activar la desduplicación
de datos y, a continuación, seleccione Configurar desduplicación de datos.

Cuando habilite la desduplicación de datos con Windows Server 2012, el retardo por
defecto para realizar la operación de desduplicación de los archivos era de 5 días. Los
archivos se procesan, desde su escritura en el servidor, pasado cierto tiempo, que podrá
adaptar en función de sus necesidades, recursos, y demás condiciones de trabajo.

Con Windows Server 2012 R2, el valor está fijado por defecto a 5 días, y no es posible
modificarlo. En efecto, con Windows Server 2012, los usuarios rebajaban este valor a 3
días, lo que impedía un funcionamiento correcto del proceso de desduplicación, siendo el
valor demasiado bajo (véase la conclusión de los ingenieros de Microsoft al respecto como
resultado del feedback de sus clientes).

También tiene la posibilidad de excluir archivos de este proceso. Por ejemplo, los archivos
mp3 y mp4, sobre los que ya se ha ejecutado un procesamiento previo similar mediante las
herramientas que los gestionan. No resulta, por tanto, útil configurar la desduplicación para
estas extensiones, y el proceso no permite liberar una cantidad de espacio significativa. Del
mismo modo, puede excluir carpetas completas.

Con Windows Server 2012 R2, existe una opción en la configuración de la desduplicación.
Puede, en lo sucesivo, especificar si se trata de un servidor de archivos "clásico" o un
servidor VDI (Virtual Desktop Infrastructure). En función de la opción elegida, las
extensiones de los archivos excluidas por defecto para adaptarse al tipo de servidor (de
archivos edb y jrs para un servidor de archivos; archivos bin, vsv, slp, xml, tmp, hrl y hru
para un servidor VDI).

Preste atención, la desduplicación de datos es una funcionalidad que procesará,

potencialmente, todos los datos de un volumen seleccionado. Una planificación cuidadosa
debe permitir determinar si su servidor y sus volúmenes son candidatos aptos para la
desduplicación, antes de utilizar esta funcionalidad.

Para definir la planificación, haga clic en Establecer programación de desduplicación....

Por defecto, cuando se habilita la desduplicación de datos se produce un procesamiento de
optimización como tarea de fondo. Esta optimización utiliza un perfil de trabajo reducido
con el objetivo de no perturbar a los sistemas en producción. Puede, por el contrario,
resultar útil afinar estos procesamientos asignando más recursos al proceso de
desduplicación en días y franjas horarias definidos. Estas franjas se configuran mediante las
opciones Habilitar optimización de rendimiento y Crear una segunda programación
para la optimización del rendimiento visibles en la captura de pantalla anterior.

Haga clic en Aceptar y, de nuevo, en Aceptar para validar las opciones seleccionadas y,
de este modo, habilitar la desduplicación de datos en el volumen seleccionado.
Recurrir a la desduplicación de datos sobre archivos replicados mediante replicación DFS
no supone ningún problema. Sólo se actualizarán aquellas particiones de archivos que se
hayan modificado desde la última replicación.

Administrar las actualizaciones

1. Presentación de WSUS

Se trata de otro medio de protegerse contra eventuales problemas (en particular de

seguridad) y asegurarse de que sus equipos cliente y servidores están bien actualizados. En
pequeños parques de servidores, configurar en cada puesto las actualizaciones en modo
automático es suficiente. En grandes parques informáticos, en los que la configuración de
las máquinas es estricta, es en ocasiones necesario probar un parche antes de desplegarlo de
forma centralizada en todos los puestos.

Microsoft pone a su disposición, de manera gratuita, la herramienta WSUS (Windows

Server Update Services) en versión 3.0 con SP2 (WSUS es un rol independiente en
Windows Server 2012 y puede, por lo tanto, instalarse desde la consola Administrador del
servidor sin tener que descargarlo por separado). Esta herramienta permite desplegar las
últimas actualizaciones para los productos Microsoft. Utilizándola, podrá administrar de
forma integral la distribución de las actualizaciones (hora de despliegue, qué parches se
desplegarán, etc.).

Dispone, gracias a WSUS, de una herramienta de centralización y de seguimiento de la

gestión de las actualizaciones de Windows. Le será posible de un golpe de vista saber qué
equipo no ha recibido las últimas actualizaciones necesarias y enviárselas.

Siempre puede utilizar una herramienta de terceros para gestionar las actualizaciones de
aplicaciones externas. Tenga en mente que el navegador de Internet y los plugins asociados
(Adobe Flash Player, Adobe Reader, Java, etc.) son la principal puerta de entrada para un
virus. Es, por tanto, importante actualizar de manera regular estos componentes mediante
las directivas de grupo o herramientas externas.

Según su infraestructura, WSUS puede actualizarse a través del sitio Microsoft Update o
incluso con otro servidor WSUS. Los clientes compatibles con WSUS aparecen a partir de
Windows 2000 SP4. Además de los sistemas operativos, WSUS permite gestionar las
actualizaciones de las aplicaciones de Microsoft más corrientes (SQL Server, Exchange
Server, Office, etc.).

Observe que, del lado cliente, Windows 8.1 aporta una mejora. En efecto, cuando los
usuarios de dispositivos reportan o ignoran las actualizaciones del sistema, los dispositivos
pueden no estar en conformidad con las políticas de seguridad de la empresa. En Windows
8.1, Windows Update realiza automáticamente las actualizaciones del sistema. Si es
necesario reiniciar, el usuario que está conectado al equipo se conecta, automáticamente, de
nuevo, y las aplicaciones en curso antes de realizar la actualización se reinician, con la
sesión desbloqueada (utilizando Secure Desktop).

Este reinicio automático requiere que las credenciales del usuario conectado puedan
almacenarse en caché, y que BitLocker esté habilitado y soporte este tipo de reinicio sin
intervención.

2. Instalación de WSUS

A continuación se muestran las etapas que debe realizar para instalar WSUS. Observe que
esta etapa tiene, como requisito previo, una conexión a Internet.

En la consola Administrador del servidor, haga clic en Administrar - Agregar roles y

características.

En la pantalla Antes de empezar, haga clic en Siguiente.

Seleccione Instalación basada en roles o características y, a continuación, haga clic en

Siguiente.

Seleccione su servidor en la lista y, a continuación, haga clic en Siguiente.

Marque la opción Windows Server Update Services.

En el cuadro de diálogo, haga clic en Agregar características.

Haga clic en Siguiente cinco veces hasta llegar a la pantalla Servicios de rol.

Deje marcadas las opciones WID Database y WSUS Services y, a continuación, haga clic
en Siguiente.
Aquí, WID Database significa que se va a instalar la base de datos de configuración
WSUS en la base de datos interna de Windows (WID por Windows Internal
Database). Para instalar la base de datos en un servidor SQL basta con marcar la opción
Base de datos. Obviamente, no es posible marcar al mismo tiempo las opciones WID
Database y Base de datos. Los administradores que quieran tener un mayor control sobre
la base de datos preferirán utilizar SQL Server.

Indique la ubicación del almacenamiento para las actualizaciones y, a continuación, haga

clic en Siguiente.
Verifique las opciones marcadas y, a continuación, haga clic en Instalar.

Una vez terminada la instalación, haga clic en Cerrar.

En la consola Administrador del servidor, haga clic en Herramientas - Windows

Server Update Services.

Se abre el asistente de instalación de WSUS.

Haga clic en Ejecutar.

Una vez terminadas las tareas de post-instalación, haga clic en Cerrar.

Se abre el asistente de configuración, haga clic en Siguiente.

Seleccione participar en el programa de mejora o no y, a continuación, haga clic en

Siguiente.

Seleccione la opción Sincronizar desde Microsoft Update (salvo si ya dispone de un

servidor WSUS y desea utilizarlo como referencia para el que está instalando).

Haga clic en Siguiente.

Si no utiliza un proxy, no indique nada en la opción de proxy. A continuación, haga clic en

Siguiente.

Si utiliza un proxy, esta página le permite detallar su configuración.

Haga clic en Iniciar conexión para que WSUS recupere la información disponible para la
descarga (esta etapa resulta algo larga). Una vez realizada la conexión, haga clic en
Siguiente.

Seleccione los idiomas utilizados por los distintos sistemas operativos (en nuestro ejemplo
el español) si no está hecho automáticamente y, a continuación, haga clic en Siguiente.
WSUS descargará, en lo sucesivo, las actualizaciones en todos los idiomas seleccionado.
Prevea, por lo tanto, un espacio en disco acorde al número de idiomas diferentes
seleccionados.

En la lista de selección de productos, seleccione los productos que desea actualizar y, a

continuación, haga clic en Siguiente.

Seleccione la clasificación de las actualizaciones deseadas, y, a continuación, haga clic en

Siguiente.

Seleccione su modo de sincronización (manual o automático), y, a continuación, haga clic

en Siguiente.

Marque la opción Iniciar la sincronización inicial si desea iniciar la sincronización de

inmediato y, a continuación, haga clic en Siguiente.

3. Uso de WSUS

Una vez instalado WSUS, se abre automáticamente la consola MMC de administración.

Puede controlar rápidamente el estado de las actualizaciones de su parque así como las
actualizaciones en espera de aprobación.
Puede acceder a esta consola desde la consola Administrador del servidor haciendo clic
en Herramientas - WSUS (Windows Server Update Services).

Antes que nada, es preciso configurar los clientes para utilizar el servidor WSUS recién
instalado.

Si dispone de un dominio Active Directory, cree una nueva directiva de grupo GPO a nivel
de dominio o de una OU. Si su PC no está en un dominio, utilice el comando gpedit.msc.

En el Editor de objetos de directivas de grupo, despliegue el nodo Configuración del

equipo - Directivas - Plantillas administrativas - Componentes de Windows - Windows
Update.

En el panel derecho, edite el parámetro Especificar la ubicación del servicio Windows

Update en la Intranet.

Marque la opción Habilitada y, a continuación, indique la URL de acceso a su servidor

WSUS en ambos campos.

Por ejemplo: http://dc2012.MiEmpresa.Priv:8530

Preste atención, piense en especificar el puerto que utiliza el sitio Web de actualizaciones.

Haga clic en Aplicar, y, a continuación, en Aceptar.

A continuación, edite el parámetro Configuración actualizaciones automáticas.

Marque la opción Habilitada, y, a continuación, indique la configuración de las
actualizaciones automáticas (notificar para descarar e instalar, descargar y planificar la
instalación, etc.).

Elija a continuación los días y las horas para instalar las actualizaciones.

En este caso se ha escogido la opción 3 para aplicarla a los servidores. Este parámetro
permite gestionar, de manera manual, la instalación de las actualizaciones y la hora de
reinicio posterior de los servidores. Para un equipo de usuario se optará por la opción 4, con
el objetivo de estar seguro de que las actualizaciones se instalan. El usuario tendrá, no
obstante, la posibilidad de posponer el reinicio del equipo si está conectado.

Valide haciendo clic en Aplicar, y, a continuación, en Aceptar.

Cierre, a continuación, el editor de directivas de grupo.

Puede forzar el refresco de la directiva de grupo en el puesto cliente mediante el comando
gpupdate.

Para forzar la detección por WSUS de un equipo cliente, ejecute desde el puesto el
siguiente comando: wuauclt /detectnow.

Desde la consola WSUS (Windows Server Update Services) puede, a continuación,

visualizar el estado del despliegue de las actualizaciones.

Despliegue el árbol y haga clic en Actualizaciones.

Hay disponibles vistas preconfiguradas. Estas vistas responden a las necesidades de la
mayoría de los administradores. Puede no obstante crear vistas personalizadas si necesita
información particular. Los criterios son numerosos: por producto, por clasificación, por
grupos, etc.

Seleccionando una de las vistas preconfiguradas, o una de las que ha creado, tendrá la
posibilidad de aprobar o rechazar las actualizaciones (una cada vez, o por lotes) para
permitir, a las máquinas cliente de WSUS, recuperarlas.

Puede ver, a continuación, el ejemplo de una vista personalizada seleccionando las

actualizaciones para Windows Server 2012. Aquí, las actualizaciones se clasifican por
Fecha de llegada. Tiene la posibilidad de seleccionar varias a la vez utilizando las
teclas [Ctrl] y/o [Shift].

La lista desplegable Aprobación permite ver las actualizaciones que ya han sido aprobadas
o no (en el ejemplo, lo están para un grupo de equipos: Instalar (1/25).

La lista desplegable Estado permite ver las actualizaciones que no han podido instalarse en
todas las máquinas o que presentan algún problema en su instalación

También es posible obtener informes detallados acerca de las actualizaciones. Para ello
basta con ir a la pestaña asociada y seleccionar el informe a visualizar.
Es preciso haber instalado Microsoft Report Viewer 2008 para poder consultarlos. Está
disponible en la siguiente dirección: http://www.microsoft.com/es-
es/download/details.aspx?id=577. Aparecerá un mensaje, de todas maneras, indicándole
que necesita esta herramienta si quiere visualizar un informe desde la consola de
administración WSUS.
Existen informes preconfigurados a su disposición. No tiene la posibilidad de crear nuevos.
Los modelos preexistentes se generan bajo demanda, de modo que se pueda disponer de la
información más actualizada posible.

La pestaña Opciones le permite configurar las opciones específicas a la instalación

(idiomas, clasificaciones, productos, etc.) así como otros parámetros:

• Aprobaciones automáticas: permite definir la forma en que se aplican los tipos de

actualización (seguridad, críticas) para los equipos definidos.
• Notificaciones electrónicas: permite enviar notificaciones de informes acerca de
las actualizaciones por correo electrónico.
• Asistente de limpieza del servidor: permite limpiar los equipos antiguos, las
actualizaciones antiguas y los archivos antiguos de actualización.
• Equipos: permite especificar si los grupos de equipos para la actualización se
administran desde WSUS o desde una directiva de grupo.
• Personalización: permite, en el caso de que se utilice servidores WSUS "hijos",
conocer el estado de los equipos que le están asociados.
• Paquete acumulativo de informes: permite en el caso de una arquitectura con un
WSUS frontal tener una centralización de todos los WSUS "hijos".

Conclusión
En este capítulo ha visto los elementos esenciales para dotar de seguridad a su parque
informático. En los aspectos relativos a la seguridad informática es mejor adoptar una
actitud proactiva y anticipar los problemas e incidentes a los que deberá hacer frente.
Ganará en rapidez para devolver su infraestructura a un estado productivo en caso de que
ocurra algún problema importante.

Piense bien su esquema de copia de seguridad en función de sus necesidades (volumen,

franja horaria, etc.). Las instantáneas son un complemento muy bueno a la copia de
seguridad Windows Server Backup. Tampoco dude en bascular a productos específicos
como el de Microsoft (System Center Data Protection Manager). Le ofrecerán una
granularidad suplementaria así como posibilidades extendidas de copia de seguridad de sus
aplicaciones (Exchange, SQL, SharePoint, etc.).

Prevenirse frente a amenazas como los virus, la explotación de fallos del sistema y demás
contrariedades resulta también imprescindible. Conservar sus aplicaciones siempre
actualizadas permite corregir los defectos de las mismas. WSUS es gratuito, aprovéchelo, le
facilitará en gran medida la difícil tarea de la gestión de parches de seguridad de Microsoft.
Ya no necesita acceder individualmente a cada PC para controlar el estado de las
actualizaciones, ni tampoco para forzarlas. Todo ello se puede administrar en lo sucesivo de
forma remota, centralizada y simplificada.
Más allá de Windows Server 2012 R2 y
Windows 8.1
En el momento de escribir estas líneas, existe poca información disponible sobre las
próximas versiones de Windows 8.1 y Windows Server 2012 R2.

No nos arriesgaremos a especular acerca del nombre de la futura versión de Windows

Server aunque, probablemente, Microsoft busque un cambio en la forma en que ponen a
disposición de los usuarios las nuevas versiones y sus funcionalidades claves, con el
objetivo de ofrecer actualizaciones de roles como Hyper-V y otros fuera de los ciclos
clásicos de publicación de software.

Este enfoque, mucho más modular, tiene la ventaja de que desvincula al sistema operativo
de las funcionalidades propuestas. Esto aportará una mejor reactividad y adaptación a los
cambios para las empresas que ya no estarán obligadas a estudiar el impacto ligado a una
migración de todo el OS sino, únicamente, del módulo que se desea actualizar.

Por supuesto, esta información se ofrece con todas las reservas y es posible cualquier
enfoque cuando se trata de nuevos desarrollos y una adaptación al mercado.

El calendario esperado
Microsoft pretende acortar el tiempo necesario entre la aparición de una versión mayor o
menor de Windows: 2 años entre una versión mayor (2003) y una versión menor (2003 R2,
parecida en 2005) y, a continuación, otros 3 años antes de la siguiente versión mayor
(2008), y así con periodos de 2 años.

Si se mantiene esta cadencia, permitirá evitar versiones intermedias, y evitar a los usuarios
que se habitúen a una versión específica como ocurrió con Windows XP, pero también
responder a sistemas competidores como Apple donde aparecen nuevas versiones de forma
regular.