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

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

Deshabilitar actualizaciones de Java en Windows Server

En entornos multiusuario Citrix o Remote App, la ejecución de «pequeños» programas con las sesiones de usuarios pueden llegar a causar sobreutiliziación de recursos de manera innecesaria.

Una de las habituales si el servidor requiere algún tipo de complemento de Java, es el comprobador automático de actualizaciones. Para evitar tenerlo activo en múltiples sesiones, deberemos modificar el registro, para la versión de 64 bits en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy

Y para la versión de 32 bits en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy

«Recuperar» claves privadas de certificados SSL en IIS

En ocasiones es posible tener alguna que otra dificultad a la hora de crear peticiones (CSR) o renovar si no se realizan los pasos con cuidado en IIS. Debemos tener en cuenta que a la hora de crear una petición de certificado, la clave privada se almacena en el equipo que la realiza y solo en este es posible recuperarla.

Pese a ello en ocasiones se producen errores en el proceso, llegados a este extremo podemos intentar dos opciones:

  1. Desde la linea de comandos podemos intentar reparar el almacen de certificados:
    certutil -repairstore my "ThumbprintDelCertificadoConoSinEspacios"

    Si el comando encuentra las claves privadas asociadas al certificado indicado con el thumprint las asocia, en otros casos es posible que muestre errores del tipo «Insertar tarjeta inteligente» ya que busca en todos los medios y proveedores criptográficos existentes, en tal caso no podrá acabar.

    NOTA: este comando también se puede utilizar para asociar las claves privadas con la renovación de un certificado CER de manera rápida dentro del mismo equipo, es decir, certificado completo del año 2010 (PFX) y renovación de 2011 (CER) en el mismo almacén de certificados.

  2. Si hemos solicitado el certificado a una autoridad online, es posible que tenga almacenadas las claves privadas en la solicitud web, en este caso podremos unirlas con el certificado de respuesta para obtener el PFX resultante mediante OpenSSL, puedes probar online pero nunca en producción
    openssl pkcs12 -export -inkey clave.pem -in pki.crt -out certificadoCompleto.pfx

 

Eliminación de catálogo global (GC) no accesible

En entornos con varios servidores actuando conjuntamente con funciones de directorio activo, bien como lectura, replicado… o cualquier escenario posible, recuperación de backups, virtualizaciones fallidas, virus… podemos llegar a querer eliminar cualquier registro del servidor ya no disponible.

Echaremos un vistazo a las referencias que pueda quedar en los DNS, sobre todo en el caso de estar integrados con el directorio.

Con los sitios y servicios debemos hacer lo mismo:

Si intentamos crear un usuario con uno de los servidores no disponible para el sitio, con el mismo nivel como catálogo global replicado, aparecerá un error del tipo:

El servicio de directorio no puede asignar un identificador relativo.

Si estamos seguros que el servidor no va a poder ser restaurado y queremos eliminar todo rastro, deberemos acudir a la linea de comandos.

Conectaremos con el servidor que tenemos activo, consultando y seleccionando el dominio/sitio/servidor que queremos limpiar de nuestra infraestructura.

ntdsutil 
metadata cleanup 
connections
connect to server SERVIDORBUENO
q
select operation target 
list domains
select domain 0
list sites 
select site 0
list servers in site
select server 5 // OJO servidor que queremos eliminar
q
remove selected server 

Debemos tener en cuenta que cualquiera de estas acciones no es reversible y puede suponer el fallo de servicios si no se realiza con cuidado.