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

 


Exportación de certificado X.509 codificado en PEM

La digitalización en la administración pública no lleva precisamente un ritmo rápido... y tampoco lo ponen fácil a usuarios finales...

Veremos como para dar de alta un proveedor en FACe, o gestionar su renovación, nos solicitan certificado en formato PEM. Por simplificar, tal como en un fichero de texto Word o una hoja de Excel tenemos diferentes formatos y versiones con los que podemos trabajar, con el certificado nos pasa lo mismo.

En este caso PEM se codifica en Base64 encerrado entre la cabecera "-----BEGIN CERTIFICATE-----" y el fin de contenido con "-----END CERTIFICATE-----".

Sin entrar en detalles técnicos, por ilustrar con un ejemplo, el texto "Este frase sería codificada" en base 64 contendría: "RXN0ZSBmcmFzZSBzZXLDrWEgY29kaWZpY2FkYQ=="

Este tipo de certificados se basan en el estándar "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" siguiendo la normativa RFC 5280. Gracias a ello podemos identificar el propietario, emisor (Autoridad de Certificación), fecha de caducidad, fecha de misión... basándonos en infraestructura de clave pública (PKI - Public Key Infraestructure)

Por tanto lo que nos están pidiendo es un "certificado X.509 codificado en formato PEM".
En un escenario habitual en un entorno Windows donde tenemos almacenado el certificado accedemos ejecutando el comando "mmc.exe" (existen otras opciones de visualización pero esta funciona en todas las versiones de Windows hasta ahora)

Nos aparecerá una ventana de consola, y bajo la opción del menú "Archivo" la opción: "Agregar o quitar complemento"

A continuación seleccionamos "Certificado" entre los complementos disponibles y pulsamos en agregar: 

Seleccionamos "Mi cuenta de usuario" teniendo en cuenta que los certificados mostrados son los del usuario que ha iniciado sesión en el equipo:

Dentro de "Personal" / "Certificados" nos mostrará todos los disponibles del usuario actual. El icono del listado, muestra una pequeña llave en aquellos certificados de los que disponemos la parte privada:

Haciendo clic con el botón derecho sobre el certificado pulsamos en "Todas las tareas" y "Exportar". Debemos seleccionar el formato de codificación X.509, no debemos exportar la clave privada en este caso:

Indicamos una ruta de nuestro ordenador para guardar el certificado, pulsando con el botón derecho sobre el certificado "Abrir con..." y seleccionamos el editor de texto Bloc de notas nos mostrará:

Con este contenido ya podemos copiar y pegar en la página de FACe de proveedores.

 

Instalación manual de agente DPM - System Center Data Protection Manager

No en todas las ocasiones es posible desplegar de forma automátizada los agentes en servidores; desde los mismos medios de instalación de DPM, podemos iniciar la instalación del agente o bien desde el propio directorio "Agents\DPMAgentInstaller_x64.exe"

Si ejecutamos el agente sin ningún parámetro necesitaremos indicar el nombre del servidor DPM con el que necesitará comunicar, en el directorio de instalación ejecutamos el comando "SetDpmServer.exe -Add -dpmServerName nombreServidor.dominio.com"

De este modo se añaden las excepciones necesarias para poder comunicar.

En el servidor DPM principal ya podemos "Adjuntar agentes", deberemos indicar credenciales con permisos.

Si todo ha sido correcto, podemos "Actualizar" nuestros nuevo servidor y realizar tareas de respaldo sobre el equipo añadido.

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 - Migración FRS a DFSR

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