Usando "Features on Demand" para desinstalar archivos binarios de Windows 2012

Cuando agregábamos un rol (o mejor dicho un servicio) en Windows 2003, en la mayor parte de los casos necesitábamos insertar el DVD de instalación o contar con una carpeta que incluya los archivos binarios correspondientes.

A partir de Windows 2008 cuando agregamos roles o características los archivos necesarios están incluidos en la instalación básica del sistema operativo (para ser más concretos se encuentran en la carpeta %Windir%\WinSxS)

 

En una instalación Core de Windows Server no todos los binarios se encuentran instalados, con lo cual para instalar ciertos roles necesitaremos acceder a esos archivos.

En el post Convertir una instalación Core en GUI usamos la línea de comandos DISM para montar la imagen de instalación de Windows (install.wim) y disponer de ese modo de los archivos necesarios. Otra solución sería usar un recurso compartido que contenga estos archivos.

Desinstalar un rol y los binarios asociados:

En una instalación gráfica de Windows 2012 los roles y características que no están instalados permanecen en un estado deshabilitado, no están instalados pero están ocupando espacio en el disco (en %Windir%\WinSxS).

La característica Features on Demand de Windows 2012 permite quitar los archivos binarios (payload) cuando sea necesario.

De este modo se optimiza el uso de espacio en disco en el servidor y por seguridad se mantienen solamente los archivos necesarios para los roles instalados.

En nuestro escenario, el servidor está en una instalación Minimal Server Interface.

 

En la pantalla siguiente puede verse que está instalada la característica “Graphical

Management Tools and Infrastructure”

 

 

 

 

 

 

 

 

 

 

 

 

 

A continuación desinstalaremos esta característica para transformar al servidor en una instalación puramente Core.

Se puede hacer directamente desde Server Manager o mediante PowerShell

En la pantalla siguiente, mediante el comando Get-WindowsFeature, vemos el nombre exacto de la característica a desinstalar.

 

 

 

 

Usando el cmdlet Remove-WindowsFeature desinstalamos la característica “Graphical Management Tools and Infrastructure” (Server-Gui-Mgmt-Infra)

Luego de la desinstalación comprobamos el espacio disponible en disco.

 

 

 

 

 

 

 

 

 

Mediante una consulta usando Get-WindowsFeature veremos qué características han sido quitadas definitivamente de Windows (incluyendo el payload). Para ello filtramos por Estado de Instalación igual a "Removed"

En el listado obtenido no figura la característica recientemente desinstalada.

La explicación es que la característica se eliminó de la instalación de Windows pero no se eliminaron los archivos binarios correspondientes

 

Eliminar los archivos binarios

A continuación aplicaremos el concepto de Features on Demand para eliminar definitivamente los archivos relacionados con el rol desinstalado.

 

Mediante el Cmdlet Uninstall-WindowsFeature con la opción Remove quitamos completamente todos los archivos binarios de la característica y de sus características asociadas.

En las dos pantallas siguiente repetimos la consulta y vemos muchas más características en estado Remove respecto de la consulta anterior (se eliminaron los archivos binarios de Server-Gui-Mgmt-Infra y de todas las sub features asociadas)

Podemos ver resaltada la característica eliminada.

Volvemos a revisar el espacio libre del disco, vemos una importante diferencia respecto de la consulta anterior

 

Asumir roles FSMO

Transferir un rol FSMO (transfer) significa pasar un rol de un Domain Controller a otro. Puede hacerse siempre que el propietario del rol originario esté disponible y funcione correctamente.

 

La transferencia de roles se trató en el post Transferencia de los roles FSMO

Asumir (seize) un rol es una operación de último recurso y se basa en tomar por la fuerza el rol debido a que el propietario del mismo no está disponible.

Es recomendable agotar todos los medios para recuperar el DC original y hacer una transferencia segura.

En los casos que no se pueda hacer, no tendremos otra opción que asumir los roles que este DC tenía.

Asumir trae aparejado riesgos, menores o mayores dependiendo del rol. Por ejemplo el RID Master es riesgoso de asumir porque podría darse que el resto de los DCs no tengan información completamente actualizada del Active Directory. En ese caso el DC que asume el rol de RID Master tendría como siguiente RID a asignar un valor que ya fue usado. Si esto sucede corremos el riesgo de tener objetos de Active Directory con SIDs duplicados.

Escenario del ejemplo:

En el dominio WindowsMCT.com tenemos dos domain controllers.

SVR01: Está en línea y es el propietario de todos los roles a excepción del Schema Master

DC01: Está fuera de línea y es el actual propietario del rol Schema Master

Como DC01 no puede recuperarse, procederemos a asumir el rol de Schema Master en SVR01

El procedimiento se hace con Ntdsutil y es similar al que vimos para transferir los roles, en este caso en lugar del comando Transfer se ejecuta el comando Seize.

 Luego damos la confirmación para asumir

 

Siempre que usemos el comando Seize, Active Directory intentará primero hacer una transferencia segura (como si hubiéramos ejecutado transfer). Finalmente al no poder contactarse con el DC originario aplicará el Seize.

En la pantalla siguiente vemos la leyenda "The current FSMO holder could not be contacted" (no puede ser contactado el propietario actual del rol FSMO) y más adelante dice "Proceeding with seizure" (procediendo a asumir por la fuerza).

 

 

Luego de completado el proceso, mediante netdom query fsmo verificamos que el Schema Master es el domain controller SVR01
 

 

Eliminar el Domain Controller offline del Active Directory
 

Cuando se asume un rol, la mejor práctica es no volver a iniciar el propietario original del rol si es que hemos recuperado el servidor. Lo más frecuente es que si asumimos, el propietario original del rol permanecerá offline.

Cualquiera sea el caso, una vez asumido el rol debemos eliminar el DC offline de la base de datos de Active Directory.

Este procedimiento puede hacerse por GUI o mediante comandos.

Eliminar el Domain Controller mediante consola gráfica:

Desde la consola de Active Directory Users and Computers, sobre la cuenta de equipo del DC offline seleccionamos Delete
 

 

NOTA: este procedimiento también puede hacerse desde la consola Active Directory Sites and Services.

Seguidamente aceptamos la confirmación

 

En la pantalla siguiente nos advierte que un Domain Controller debe ser eliminado mediante un proceso normal de degradación (demotion). Es decir quitando el rol AD DS y ejecutando el Wizard de desinstalación posterior. En este caso no podemos seguir ese procedimiento porque nuestro DC originario no está disponible.

Para eliminarlo definitivamente debemos marcar el check box “Delete this Domain Controller Anyway¨

 

En nuestro ejemplo cancelamos este procedimiento y lo haremos mediante comandos (algunos administradores consideran que es más seguro).

Eliminar el Domain Controller mediante comandos:

Se usa el comando Ntdsutil, con el contexto Metadata Cleanup.

El procedimiento consiste en la ejecución de una serie de comandos hasta llegar a listar los domain controllers presentes en la base de datos de AD.

Luego se selecciona el DC que está offline (DC01 en nuestro caso) y finalmente se ejecuta el comando Remove Selected Server. En la pantalla siguiente se puede ver todo el proceso
 

 

Aceptamos la confirmación para eliminar el DC
 

La pantalla siguiente indica que el servidor DC01 fue eliminado con éxito (CN=DC01,CN=Servers,...etc. removed from server "svr1.windowsmct.com").

Luego verificamos que el procedimiento anterior eliminó la cuenta de equipo del DC01 del Active Directory

 

Transferencia de roles FSMO

Nos referimos a transferencia de un rol FSMO cuando pasamos dicho rol de un Domain Controller a otro. La operación de transferencia es completamente segura, no conlleva riesgos para la integridad del Active Directory.

En ocasiones la transferencia de roles se hace para balancear los roles entre diferentes controladores de dominio, ya sea por razones de equilibrio de carga o para evitar que la desconexión de un solo DC provoque la indisponibilidad de todos los roles.

Otras veces, el motivo de la transferencia es el reemplazo del DC propietario por un nuevo servidor. En este último caso antes de degradar el domain controller debemos transferir los roles al nuevo.

Para transferir roles hay que tener los derechos administrativos necesarios. A continuación se menciona el rol, seguido del grupo que tiene privilegios suficientes para transferirlo.

• Domain Naming Master – Enterprise Administrator
• Schema Master – Schema Administrator
• PDC, RID e Infrastructure – Domain Administrator

Para transferir roles pueden usarse herramientas gráficas o comandos. A continuación vemos los dos métodos.

1- Transferencia mediante Consolas (GUI)

En el post Identificar los propietarios de los roles FSMO, vimos qué consolas usar para ver qué DC alojaba cada uno de los roles.

Escenario: En este escenario de prueba hay dos domain controllers

DC01: Propietario de los cinco roles

SVR01: Servidor al cual  se le transferirán los roles

En la consola Active Directory Users and Computers nos ubicamos sobre el dominio y seleccionamos la opción para conectarnos al domain controller destino (SVR01)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Seleccionamos el SVR01 que será el nuevo destinatario de los roles

 A continuación hacemos clic en Operations Masters

 

Para el RID Master (pestaña actualmente seleccionada) podemos ver que el SVR01 figura en el cuadro inferior (se lo conoce como DC "en espera")

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Para transferir el rol simplemente hacemos clic en el botón Change y en la pantalla subsiguiente de confirmación hacemos clic en Yes

Luego se ve la confirmación que el rol fue transferido exitosamente

 

 

 

 

 

 

 

 

 

 

A través del comando Netdom verificamos que el SVR01 es propietario del rol RID Master (RID Pool Manager)

Así debemos repetir la operación para los otros dos roles (PDC e Infrastructure)

Para los roles de nivel forest, la operación es idéntica aunque debemos usar las siguientes consolas:

• Active Directory Domains and Trusts para el Domain Naming Master
• Active Directory Schema para el Schema Master

2- Transferencia mediante comandos:

Algunos administradores preferimos la línea de comandos Ntdsutil para transferir los roles porque puede hacerse la operación para los cinco roles, sin necesidad de cambiar de consolas.

Para comenzar, ejecutamos Ntdsutil en un CMD o PowerShell elevado.

 

Luego escribimos Activate Instance NTDS para indicar que estamos trabajando con Active Directory y no con otra instancia de LDAP

A continuación escribimos Roles y se abrirá el prompt Fsmo maintenance

Finalmente, mediante ? solicitamos la ayuda del contexto

Dentro de FSMO Maintenance debemos abrir el contexto Connections para conectarnos con el DC destino (en nuestro ejemplo SVR01.windowsmct.com)

Volvemos a usar ? para ver la ayuda

Al no especificar credenciales de conexión toma las actuales (como es la del Administrador del Dominio raíz del forest son aptas para transferir todos los roles)

 

 

 

 

 

 

 

 

Hay que salir del menú Connections para volver a Fsmo maintenance.

Lo hacemos  mediante el comando quit

Estando en el prompt de Fsmo maintenance ejecutamos el comando transfer para cada uno de los roles:

Transfer Infrastructure Master

Transfer PDC

Transfer RID Master

Transfer Naming Master

Transfer Schema Master

En el ejemplo se muestra la transferencia del Domain Naming Master (se ve la ejecución del comando Transfer naming master)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Luego de dar la confirmación, la pantalla final nos muestra la operación realizada, donde resaltamos la línea que indica que SVR01 es el Domain Naming Master

 

 

En el siguiente post Asumir roles FSMO se muestra el procedimiento para asumir un rol por la fuerza en el caso que el DC propietario no pueda recuperarse

 

 

 

Identificar los propietarios de los roles FSMO

La finalidad de este post es mostrar cómo se identifican a los controladores de dominio propietarios de los roles. Aunque damos una explicación básica de su alcance no describimos las funciones que abarca cada rol.

Los roles de Maestros de Operaciones, también conocidos como FSMO (Flexible Single Master Operation) son funciones propias de los controladores de dominio de escritura. Un RODC (Read Only Domain Controller) no puede ser propietario de un rol.

Roles de nivel Forest:

Los dos roles siguientes son únicos en todo el forest y están ubicados en el Forest Root (primer dominio que se crea en el forest).

 

• Schema Master
• Domain Naming Master

 

Es decir que hay un solo Schema Master y un solo Domain Naming Master en todo el forest (independientemente de la cantidad de árboles y dominios que contenga). Habitualmente estos dos roles coexisten en el mismo servidor, aunque algunos administradores prefieren separarlos para ofrecer mejor disponibilidad.

NOTA: si bien el propósito de este post es solamente identificar a los propietarios de los roles, aclaramos que una desconexión temporal de estos dos roles no impide el normal funcionamiento del Active Directory, por ende no es una decisión peligrosa mantenerlos en el mismo Domain Controller.

Roles de nivel Dominio:

Los otros tres roles son únicos en cada dominio. Eso significa que cada dominio del forest (incluyendo el forest root) debe tener estos tres roles:

• PDC Emulator
• RID Master
• Infrastructure Master

El primer controlador de dominio que se crea en el forest, será el propietario de los 5 roles.

El escenario del ejemplo consiste en un forest compuesto por un único dominio.

 

Identificación de los roles:

1- Mediante línea de comandos

Usando el comando Netdom es muy sencillo averiguar quiénes son los propietarios de los roles

 

 

 

 

 

 

 

 

 

En nuestro ejemplo puede verse que el DC01 es el propietario de los 5 roles.

2 – Mediante consolas

Roles de dominio:

Desde la consola de Active Directory Users and Computers puede saberse rápidamente los propietarios de los tres roles de dominio

Sobre el Dominio (WindowsMCT.com) hacemos clic derecho y en el menú contextual y seleccionamos Operations Masters.

 



 

 

 

En la siguiente pantalla podemos elegir entre las tres pestañas y verificar qué DC cumple los roles de PDC, RID e Infrastructure.

 

Roles de forest:

Para averiguar quién posee el rol de Domain Naming Master usamos la consola Active Directory Domains and Trusts

En la raíz de esta consola, clic derecho, en el menú contextual seleccionamos Operations Master

 

 

 

 

 

 

 

 

 

 

 

 

 

 

La pantalla resultante muestra que el DC con el rol de Naming Master es el DC01

Para averiguar qué DC es el Schema Master, usamos la consola Active Directory Schema.

Para poder cargar esta consola, debemos registrar previamente el archivo dll correspondiente (schmmgmt.dll). Para ello usamos el comando regsvr32.exe

 

 

 

 

 

 

 

 

 

  

 

A continuación abrimos una nueva consola de administración. Para ello desde CMD o PowerShell ejecutamos mmc.exe

En la nueva consola, desde el menú File, seleccionamos Add/Remove Snap-in



En el panel resultante seleccionamos el complemento (snap-in) Active Directory Schema y lo agregamos al panel derecho mediante el botón Add.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

En esta consola, en forma similar a lo que hicimos en las anteriores, debemos seleccionar Operation Masters para ver qué DC es el Schema Master.

 

 

 

 

 

 

 

 

 

 

 

 

  

 

En un post posterior veremos cómo transferir estos roles de un DC a otro.