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

iLO5 Intelligent Provisioning 3.X deja de responder

Las conexiones remotas a servidores HPE mediante iLO permiten administrar equipos independientemente del sistema operativo, añadiendo una capa adicional de gestión. Si bien han evolucionado considerablemente, desde las últimas versiones es posible acceder mediante navegador web y realizar KVM (con licencia adicional en algunos casos) con HTML5 sin necesidad de plugins, en ocasiones tambien pueden producirse problemas. Pasados los minutos el sistema no supera el mensaje "Attempt firmware Update"

Si tenemos habilitado el acceso SSH a la tarjeta iLO:

Podemos iniciar una sessión para resetear el estado de la API, ejecutando los comandos:

</>hpiLO-> oemhp_clearRESTAPIstate
</>hpiLO-> cd /map1
</>hpiLO-> reset

Es aplicable a las diferentes versiones de Intelligent Provisioning, actualmente 3.31.

Una vez instalado el sistema operativo, no olvidar instalar los drivers específicos, para Windows Server:

O utilizando la última versión de Service Pack Proliant (SPP)

 

 

Forzar desinstalación de Office

Algunas versiones de Office pueden no ser sencillas de eliminar por completo, sin dejar rastro ni ficheros; otras veces teniendo instaladas varias versiones de la suite ofimática en el mismo ordenador acaba siendo una pesadilla.

El proceso en las nuevas versiónes Office 365, Click-to-run... se ha simplificado considerablemente mediante la utilidad "Microsoft Office Fix", pero con las versiones previas: Office 2013, Office 2010, Office 2007... el proceso manual es largo.

Existen aplicaciones de terceros y otras no tan fiables, pero la propia Microsoft tiene automatizada la desinstalación según versiones y Sistema operativo:

 

Instalación de claves de licencia IBM / Lenovo con DSA

Las licencias asociadas a servidores y componentes del fabricante se deben activar desde el portal de "Features On Demand"; se asocia un código de activación válido al número de serie del equipo, que permite a su vez descargar el fichero con extensión KEY.

NOTA: es posible acceder al número de serie desde comandos de windows "wmic bios get serialnumber"

La forma recomendada por IBM es realizarlo desde el arranque IBM Dynamic System Analysis (DSA) en BIOS, pulsando "F2 Diagnostics" en el arranque, desde el menú superior permite acceder al DSA:

Accediendo desde el modo GUI:

Permite el acceso a las opciones "Activation Key Managment" con las que asociar, desde un dispositivo externo con la clave o con conexión a internet la nueva licencia.

La otra opción es utilizar la herramienta DSA portable desde el propio sistema operativo, permitiendo las operaciones en remoto y local. Una vez descargado, es posible ejecutar el comando para instalar la nueva clave, en el caso de activar claves para servidores System X el dispositivo destino es IMM:

ibm_utl_dsa_dsyte1g-9.62_portable_windows_x86-64.exe fod install_fod_key --keyfile c:\datos\LICENCIA_DESCARGADA_anyos_noarch.key --device IMM

NOTA: si se ejecuta el portable directamente sin comandos, se realiza un proceso de diagnosis completo: configuración del servidor, aplicaciones instaladas, drivers, redes, rendimiento, inventario de hardware, firmwares, RAID, eventos del procesador... que se almacena en el directorio "C:\IBM_Support". En esta misma ubicación se guardan los registros de instalación de claves.

Si todo ha ido correctamente, aparecerá el mensaje de confirmación:

Dependiendo del tipo de nueva funcionalidad será necesario un reinicio del servidor.