Habilitar Administración Remota mediante Política de Grupo (GPO - WinRM)

Para permitir la administración remota a equipos dentro del dominio podemos definir una Política de Grupo:

Configuración del Equipo - Directivas - Plantillas administrativas - Componentes de Windows - Administración remota de Windows (WinRM) - Servicio WinRM

 

Configuración del equipo - Directivas - Plantillas administrativas - Red - Conexiones de red - Firewall de Windows - Perfil de dominio

Habilitamos "Firewall de Windows: Permitir excepción de administración remota entrante" e indicamos la IP desde la que se puede gestionar o asterisco "*" para cualquiera

Por último añadimos una regla en el firewall: Configuración del equipo - Configuración de Windows - Configuración de seguridad - Firewall de Windows con Seguridad Avanzada - Reglas de entrada

Añadimos una nueva predefinida: "Administración remota de windows"

Configuración de equipo - Preferencias - Configuración del Panel de control - Servicios

Nos aseguramos que "WinRM" se inicie con el sistema:


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 - 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

Actualización fallida Windows 10 / Windows Server 2019: 0xC1900101 - 0x30018

Aunque la solución parece enfocada en Windows 10, también es aplicable a Windows Server 2019. Después de un par de reinicios en el proceso de actualización aparece el error:

0xC1900101 - 0x30018
Error de instalación en la fase FIRST_BOOT con un error durante la operación SYSPREP

Por suerte el proceso ha mejorado notablemente y el equipo se restaura al estado anterior a la instalación, antiguamente requería volver el sistema al estado actual desde las copias de seguridad, reinstalar, puntos de recuperación...

Googleando indican que el error esta asociado a un driver, ahora bien ¿cual? Si bien en sistemas operativo cliente Windows 10, puede ser probable algún habitual: gráfica, wifi, red, dispositivos USB... es necesario revisar los registros de instalación para comprobar cual es el que provoca el problema exactamente.

Podemos extraer de los directorios de instalación de un equipo remoto o ejecutar el programa desde el equipo que no se ha podido actualizar:

\$Windows.~bt\sources\panther
\$Windows.~bt\Sources\Rollback
\Windows\Panther
\Windows\Panther\NewOS

Microsoft dispone de la aplicación SetupDiag.exe que buscará en estos directorios para mostrar un resumen del driver causante del error en la actualización y por tanto del pantallazo azul.

Una vez ejecutado, se muestra en línea de comando el proceso, en el mismo directorio encontraremos un archivo ZIP con registros y un fichero log. Si ejecutamos varias veces, el fichero log se modifica y añade la nueva información y los archivos ZIP se crean con numeración adicional.

Para este ejemplo, en una actualización de Windows Server 2012 R2 a 2019 aparece un driver conflictivo con una controladora de fibra HBA: QLogic Fibre Channel Adapter 2560

Warning: Found a compliance block.

Error: Found a device installation failure during device install phase.
Device Installation failure detected!
Device Description: QLogic Fibre Channel Adapter
HardwareId: PCI\VEN_1077&DEV_2532&SUBSYS_015C1077
Inf Name: ql2x00.inf
Driver Version: 9.2.9.20

Será necesario buscar en el fabricante QLogic información de últimas versiones de los drivers... ley de murphy, no habría mejor forma para ilustrar este tipo de casos... de la versión instalada 9.2.9.20 a la 9.2.9.23 solo se registra en el histórico de cambios una corrección:

 * ER144923  : WS2019 BSOD when executing SAN boot (during rebbot test), 
   Scope     : All Adapters
   Resolution: Noncachedextension memory has stale value, zero this memory before using

 

NOTA: en caso de reiniciar el proceso de actualización y volver a mostrar el mismo mensaje una vez actualizados los drivers, es recomendable actualizar BIOS y firmwares de HBA, equipo...

ACTUALIZACION: con fecha 29/08/2019 Qlogic ha actualizado el miniport driver para Windows Server 2016/2019 a la versión 9.3.3.20