Directorio activo hybrido en Azure

Ambos nombres son equivalentes, describen un atributo que no cambia durante la vida de un objecto. Se trata de identificar de forma única en un entorno local y en Azure AD.

Por defecto se calcula codificando en Base 64 la propiedad objectGUID del servidor local, por ejemplo:

$Usuario = Get-ADuser nombreDeUsuario -Properties * -server localhost
$ImmutableID = [system.convert]::ToBase64String(([GUID]($Usuario.ObjectGUID)).tobytearray())

Realmente no debería cambiarse, pero en ocasiones nos encontramos en la necesidad de hacerlo, bien por una migración de directorio, eliminación de usuarios, replicación con errores… Si en lugar de utilizar el objectGUID utilizariamos un atributo personalizado no tendríamos este problema pero conllevaría la gestión y administración del mismo, si dentro de la empresa cada uno tiene un identificador único personal podría utilizarse para calcular el sourceAnchor.

Esta propiedad se establece durante la instalación inicial, solo si se desinstala correctamente se puede volver a establecer con un valor personalizado, desde la versión 1.1.524.0 se facilita el atributo ms-DS-ConsistencyGuidcomo atributo de los usuarios a utilizar como sourceAnchor.

Podemos visualizar la propiedad actual desde PowerShell:

Import-Module AzureAD
$O365Cred = Get-Credential
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-AzureAD -Credential $O365Cred
Get-AzureADUser -ObjectId nombreUsuario@midominio.com | Select objectID, UserPrincipalName, ImmutableID

Si bien, en la documentación aparece, la posibilidad de establecer el valor en nulo para desvincular las cuentas creadas localmente de la nube mediante powershell:

Set-AzureADUser -ObjectId nombreUsuario@midominio.com -ImmutableID $null

No genera ningún resultado ni modificación del objeto, por lo menos a fecha de hoy.

Como alternativa, podemos crear un usuario temporal en nuestro directorio, sincronizar e intercambiar sourceAnchor, asignando otro incorrecto al usuario a eliminar posteriormente.

 

 

Modern Backup Storage, DPM, NTFS y ReFS

A partir de System Center Data Protection Manager (DPM) 2016 se introdujo este nuevo sistema de «almacenamiento moderno de copias de seguridad» en su traducción literal, con el objetivo de simplificar, optimizar y gestionar de forma más rápida copias de seguridad locales consumiendo menos espacio.

En la práctica y de manera sencilla, se utiliza un volumen formateado en ReFS y ficheros/discos VHDX que se provisionan para la copia. La combinación de ambas permite sacar mayor rendimiento en el sistema de ficheros:

  • Clonación de bloques (Block cloning) permite transformar la copia de ficheros en copia de metadatos, es decir, si tenemos un Fichero A dividido en nuestro disco en 100 partes y lo copiamos en un Fichero B, este último hará referencia a las 100 partes iguales de su origen, enlaza el contenido. Si se produce una modificación de una parte del fichero, en ese momento se realiza una copia de la parte afectada (se desenlaza de A y se enlaza el nuevo bloque a B)
  • VDL disperso (Sparse Valid Data Length) agiliza la escritura de ceros en ficheros grandes, permite eliminar ficheros, y crear archivos de tamaño fijo VHDX de manera rápida.
  • Paridad acelerada por reflejos (Mirror accelerated Parity) se realiza la escritura de entrada espejada para después calcular la paridad y almacenarse en su ubicación final.

En el momento de «Agregar almacenamiento en disco» se formatea automáticamente el contenido de la unidad en ReFS.

Si bien este sistema de ficheros no sustituye todavía a NTFS, permite grandes ventajas en entornos de almacenamiento y virtualización.

Ahora bien, en el momento que intentamos localmente «Agregar DPM Externo» de Azure nos encontramos:

Error 100070: El destino de recuperación seleccionado para recuperar una o más archivos no es válido.
Acción recomendad: Asegúrese de que el destino de recuperación se encuentra en un volumen NTFS montado localmente

Durante la configuración no se advierte ni comprueba. En el momento de intentar agregarlo si ¿Por qué este requisito? ¿No se puede restaurar ficheros desde Azure sobre un destino ReFS?

 

Referencia de errores: Codigo de error de Data Protection Manager
Versión: Azure Backup Server v3 13.0.415.0

 

Almacén central de políticas de grupo

Los controladores de Directorio activo de forma prederminada no replican el contenido de la carpeta de definición de políticas de grupo para Windows c:\Windows\PolicyDefinitions Esta carpeta contine los ficheros necesarios para crear políticas de grupo de acuerdo al nivel funcional del dominio.

Si queremos ampliar estas características con más plantillas o actualizaciones de las mismas, por ejemplo administrar una nueva característica de Windows 10 desde un directorio con nivel funcional Windows Server 2012, debemos mantener actualizada esta carpeta en todos los servidores.

Debemos copiar (importante COPIAR, no mover) desde el directorio predeterminado del servidor a la carpeta SYVOL disponible y sincronizada

Copiamos la carpeta C:\Windows\PolicyDefinitions al nuevo destino: C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions

De tal manera que seguiremos disponiendo de los plantillas actuales, a las que podremos añadir nuevas ADMX para gestionar software nuevo o actualizado:

Con los ficheros ADMX de Office 2016 dentro de nuestra carpeta compartida nos aparecerían las nuevas opciones de administración:

Con los ficheros ADMX para Google Chrome:

Windows Server 1709 ya no admite FRS

A partir de la actualización 1709 no es posible seguir utilizando la replicación FRS de la carpeta SYSVOL con lo que debemos adaptar nuestro directorio activo para utilizar DFSR, si bien ya fue depreciado su utilización en versiones anteriores, pasa a ser de obligatorio cumplimiento.

Debemos tener claro los diferentes estados por lo que pasará el proceso:

  • 0.- Start / Inicio: FRS replica la carpeta SYSVOL en todos los posibles controladores de dominio. No olvides hacer una copia por si acaso.
  • 1.- Prepared / Preparado: FRS continua replicando la carpeta SYSVOL en una nueva carpeta SYSVOL_DFRS, en el mismo directorio que la anterior.
  • 2.- Redirected / Redirigir: La copia recien realizada en la carpeta SYSVOL_DFRS empieza a responder a peticiones de servicio sin interferir en la replicación activa en SYSVOL
  • 3.- Eliminated / Eliminado: Se continua la replicación y se atienden peticiones de servicio. Se eliminará la carpeta original SYSVOL y se detiene FRS

En el controlador de dominio ejecutamos «net share» para asegurarnos que la carpeta SYSVOL esta compartida y tenemos espacio en disco suficiente, lo habitual será que este accesible sin mayor problema. Para comprobar el estado de todos los DCs ejecuta: «dcdiag /e /test:sysvolcheck /test:advertising»

Dependiendo de la complejidad del directorio ejecutamos «repadmin /ReplSum» para asegurarnos que las replicaciones no tienen errores.

Comprobamos en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters que SysvolReady es 1 y que el servicio DFSR esta iniciado y en modo automático.

NOTA: el nivel funcional mínimo del dominio debe ser Windows Server 2008

Con todo preparado, realizaremos una copia de la carpeta SYSVOL, imagen de la máquina virtual, «Wbadmin start systemstatebackup»… o lo que mejor nos parezca, pero por lo menos una de ellas.

A continuación iremos pasando por los diferentes estados del proceso:

  1. Pasar a estado Preparado
    PS C:\> dfsrmig /setglobalstate 1
    
    Estado global actual de DFSR: 'Inicio'
    Nuevo estado global de DFSR: 'Preparado'
    
    La migración pasará al estado 'Preparado'. El servicio DFSR
    copiará el contenido de SYSVOL a la carpeta SYSVOL_DFSR.
    
    Si algún controlador de dominio no puede iniciar la migración, intente realizar un sondeo manual.
    O bien, ejecútelo con la opción /CreateGlobalObjects.
    La migración puede iniciarse en un período comprendido entre 15 minutos y 1 hora.
    Se completó correctamente.
  2. Comprobar estado:
    PS C:\> dfsrmig /getglobalstate
    
    Estado global actual de DFSR: 'Preparado'
    Se completó correctamente.
  3. Comprobar migración:
    PS C:\> dfsrmig /getmigrationstate
    
    Los siguientes controladores de dominio no alcanzaron el estado global ('Preparado'):
    
    Controlador de dominio (estado de migración local): tipo de DC
    ==============================================================
    
    SERVIDOR01 ('Inicio') - Primary DC
    SERVIDOR02 ('Esperando sincronización inicial') - Writable DC
    
    La migración todavía no ha alcanzado un estado coherente en todos los controladores de dominio.
    Es posible que la información de estado esté obsoleta por la latencia de Servicios de dominio de Active Directory.

    El proceso se lanza cíclicamente, si se producen errores es necesario revisar el Visor de eventos del directorio. Se puede forzar a reintentar con el comando «dfsrdiag pollad», de otro modo el tiempo predeterminado es de 5 minutos.

    En caso de aparecer «Error: 367» revisar posible solución aqui, si el error se produce con todos los DC con Windows Server 2019 no será posible aplicar esta solución, como alternativa es posible instalar Server 2012 o 2008 en una máquina virtual para hacer el proceso de migración y posteriormente eliminarla.

    IMPORTANTE: hasta que todos los servidores no estén en estado ‘Preparado’ no se debe continuar. Revisa cuidadosamente los registros DNS para evitar errores de replicación.

    – Inicia una sincronización completa entre los DCs: repadmin /syncall /AdeP
    – Comprueba el estado de la replicación y la estimación de tiempo: repadmin /replsum
    – Comprueba la configuración completa del dominio: dcdiag /e /c /q
    – Comprueba la configuración de las carpetas SYSVOL: dcdiag /e /test:sysvolcheck /test:advertising

    Cuando TODO este correcto el estado cambiará a preparado.

    PS C:\> dfsrmig /GetMigrationState
    
    Todos los controladores de dominio se migraron correctamente al estado global ('Preparado').
    La migración alcanzó un estado coherente en todos los controladores de dominio.
    Se completó correctamente.
  4. Pasar a estado ‘Redirigir’
    PS C:\> dfsrmig /SetGlobalState 2
    
    Estado global actual de DFSR: 'Preparado'
    Nuevo estado global de DFSR: 'Redirigido'
    
    La migración pasará al estado 'Redirigido'. El recurso compartido SYSVOL
    cambiará a la carpeta SYSVOL_DFSR, que se replica mediante DFSR.
    
    Se completó correctamente.

    Volver a comprobar que todos los DCs han llegado al mismo estado.

    PS C:\> dfsrmig /GetMigrationState
    
    Todos los controladores de dominio se migraron correctamente al estado global ('Redirigido').
    La migración alcanzó un estado coherente en todos los controladores de dominio.
    Se completó correctamente.
  5. Una vez se ejecuta el siguiente comando, ya no es reversible, se pasa a estado ‘Eliminado’
    PS C:\> dfsrmig /SetGlobalState 3
    
    Estado global actual de DFSR: 'Redirigido'
    Nuevo estado global de DFSR: 'Eliminado'
    
    La migración pasará al estado 'Eliminado'. Este paso no se puede revertir.
    
    Si algún controlador de dominio de solo lectura se encuentra bloqueado en el estado 'Eliminando' durante demasiado
     tiempo, ejecútelo con la opción /DeleteRoNtfrsMembers.
    Se completó correctamente.

    Volver a comprobar que todos los DCs han llegado al mismo estado.

Relacionado: Anuncio original de Microsoft

Actualizar esquema directorio activo: Windows Server 2019

Una de las tareas previas a la actualización in-place para servidores, físico y virtuales, con rol de Directorio Activo es la actualización/preparación del esquema AD. En este ejemplo se utiliza desde Server 2012 R2 a Server 2019, con el CD accesible desde la máquina en la ruta: D:\sources\adprep\adprep /forestprep ejecutamos el comando y esperamos a que finalice.

Dependiendo de la complejidad, y número de servidores, en el bosque comprobaremos que los cambios se han aplicado. Podemos realizarlo con los comandos dsquery:

dsquery * cn=schema,cn=configuration,dc=nombredominio,dc=local -scope base -attr objectVersion

Mediante powershell:

Get-ADObject "cn=schema,cn=configuration,dc=nombredominio,dc=local" -properties objectversion

Mediante la herramienta visual ADSIEdit.msc, comprobamos la revisión:

Y la versión del esquema:

Dependiendo de la versión del sistema operativo, objectVersion tendrá el valor correspondiente:

Ya podremos seguir con la actualización, comprobando el nivel funcional actual del directorio activo y replicando dede el maestro de operaciones:

D:\support\adprep>adprep /domainprep /gpprep
Adprep actualizó correctamente la información de todo el dominio.
Adprep va a actualizar la información de objeto de directiva de grupo (GPO) en el FSMO del maestro de infraestructura miservidor.dominio.local.
La operación gpprep 2 se realizó correctamente.
La operación gpprep 3 se realizó correctamente.
Adprep actualizó correctamente la información de objeto de directiva de grupo (GPO).