En este post vamos a ver cómo solucionar el problema de la replicación de la carpeta SYSVOL entre los controladores de dominio.

• Si accedemos al visor de eventos en cualquiera de nuestros controladores de dominio, y nos encontramos con estos dos ID de eventos 4612 y 5002, tenemos un problema en la replicación DFSR de la carpeta SYSVOL:

• Para solucionar este problema, lo primero que vamos a realizar será parar el servicio Replicación DFS en todos los controladores de dominio:

• En la herramienta ADSIEDIT.MSC, modificamos el siguiente DN y dos atributos en el controlador de dominio que deseamos convertir en autoritativo (preferiblemente el emulador PDC, que suele ser el más actualizado para contenidos de replicación sysvol):

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

msDFSR-options=1

• Modificamos el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

• Ahora forzamos la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Iniciamos el servicio DFSR en el controlador de dominio que se configuró como autorizado, es decir, DC01:

• Ahora veremos el ID de evento 4114 en el registro de eventos de DFSR, lo que indica que la replicación de sysvol ya no se está replicando:

• En la herramienta ADSIEDIT.MSC, volvemos a modificar el siguiente DN y este atributo en el controlador de dominio que convertimos en autoritativo, en nuestro caso DC01:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora volvemos a forzar la replicación de Active Directory en todo el dominio y validamos que es correcto en todos los DC con repadmin /syncall dc01 /APed:

• Volvemos a modificar el siguiente DN y atributo único en todos los demás controladores de dominio en ese dominio:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

• Ahora paramos el servicio de Replicación DFS con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Stop-Service DFSR} y volvemos a iniciarlo con Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {Start-Service DFSR}:

• Ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en el mismo servidor que configuramos como autorizado, DC01:

• Ahora veremos el ID de evento 4602 en el registro de eventos de DFSR, lo que indica que se ha inicializado la replicación de sysvol, ese controlador de dominio ahora ha realizado una replicación D4 de sysvol:

• Para terminar, ejecutamos el siguiente comando DFSRDIAG POLLAD desde un símbolo del sistema con permisos de administrador en todos los controladores de dominio no autoritativos, DC02:

• En el DC02, veremos el ID de evento 4604 en el registro de eventos de DFSR, indicando que la carpeta SYSVOL se ha replicado correctamente:

• Para verificar que la carpeta SYSVOL se está replicando correctamente accedemos a \\Controladordominio\netlogon y en el dc01 creamos un fichero llamado testdc01 que se debe de replicar en dc02, y en el dc02 creamos un fichero llamado testdc02 que se debe de replicar en dc01:

NOTA: Nos podemos encontrar con este error al ejecutar el comando DFSRDIAG POLLAD:

• Para solucionarlo nos abrimos un PowerShell como administrador y ejecutamos Install-WindowsFeature RSAT-DFS-Mgmt-Con:

• Una vez instaladas las herramientas remotas RSAT para DFS, volvemos a ejecutar DFSRDIAG POLLAD y veremos que se ejecuta correctamente:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo solucionar el error del servicio w32time cuando no es capaz de iniciar.

• Como podemos ver, al intentar iniciar el servicio w32time nos muestra el siguiente error, y el servicio no es capaz de iniciarse:

• Para solucionarlo, y forzar a Windows a sincronizar la hora, nos abrimos un PoweShell como Administrador:

• Y ejecutamos los siguientes comandos:
• net stop w32time Paramos el servicio
• w32tm /unregister Desregistramos w32tm
• w32tm /register Volvemos a registrar w32tm
• net start w32time Iniciamos el servicio
• w32tm /resync Sincronizamos el servicio de hora de nuevo

• Para verificar que todo está correcto, ejecutamos el comando w32tm /dumpreg /subkey:parameters, y cómo podemos ver, el servidor NTP que nos está sirviendo la fecha y hora es windows.com:

Saludos y espero que os sea de ayuda

En este post vamos a ver como solucionar este problema que normalmente nos lo empieza a dar el sistema después de unir el equipo a nuestro dominio de Active Directory, incluso con cuentas que tienen permisos administrativos.

• Si intentamos acceder por ejemplo a “Configuración de iconos de escritorio”, podemos ver el error:

• Para solucionarlo, ejecutamos msc para abrir las políticas locales:

• Accedemos a la ruta Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad > Control de cuentas de usuario: Modo de aprobación de administrador para la cuenta predefinida Administrador:

• Habilitamos esta política y aceptamos los cambios:

• Una vez habilitada ya podemos acceder sin problemas.

Saludos y espero que os resulte de ayuda

En este post vamos a ver un problema que nos podemos encontrar al cambiar la zona horaria en Windows Server 2019, incluso con el usuario administrador local de la propia máquina.

• Accedemos a la configuración de nuestro Windows Server 2019, en Hora e Idioma:

• Si intentamos cambiar la zona horaria en Fecha y hora aparentemente nos la va a cambiar, pero si navegamos a otro de los menús y volvemos a la configuración dela zona horaria, veremos que no la ha cambiado y nos la deja con la que le habíamos configurado en la instalación:

• Si accedemos al Panel de control > Reloj, Idioma y Región > Configurar la hora y fecha e intentamos Cambiar la Zona horaria, nos va a dar este error, indicándonos que no tenemos permisos como administrador:

• La solución es abrirnos un PowerShell con permisos de Administrador:

• Y ejecutar el comando timedate.cpl se nos abrirá la configuración de fecha y hora, y ahora SI nos va a permitir cambiar la zona horaria:

Saludos y espero que os sea de ayuda

En este post vamos a ver como solucionar el warning que tiene como ID de evento 2213, este Warning se produce ya que la carpeta SYSVOL no se está replicando en el controlador de dominio que muestra el Warning, suele ser producido por un apagado inesperado del servidor, ya sea por algún cuelgue que nos obligó a darle un botonazo, por falta de suministro eléctrico, etc…, lo que está pasando es que la replicación DFSR en el controlador de domino afectado se ha quedado en pausa:

• En el visor de eventos del controlador de dominio que tiene el Warning, sobre “Registro de aplicaciones y servicios > Replicación DFS” veremos este Warning, y sobre el mismo evento nos da la solución para quitar la pausa de la replicación DFSR:

• Para solucionar este Warning nos abrimos un cmd con permisos de administrador en el controlador de dominio afectado e introducimos el siguiente comando wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=»79D93885-2932-11E4-93E8-806E6F6E6963″ call ResumeReplication:

• A partir de la aplicación del comando, la carpeta SYSVOL empezará a replicar en el controlador de domino que estaba dando el Warning y que tenía la replicación en pausa, veremos entonces el ID de evento 2214 que se ha registrado en el controlador de domino, indicando que la replicación DFS se ha restablecido correctamente:

• Una vez solucionado este warning, nos podemos encontrar con este error, ID evento 4012, si el controlador de domino ha estado más de 60 días sin replicar con los otros controladores del dominio, para solucionarlo, podemos seguir este link, ya que en su día ya lo explicamos en este mismo blog:

Saludos y espero que os sea de ayuda

En este post vamos a ver como realizar un sysprep a un Windows 10, ya que al intentar realizarlo, en algunas ocasiones nos puede dar este error, que solucionaremos con algunos comandos de PowerShell.

• Para realizar el sysprep, nos ubicaremos sobre el path “C:\Windows\System32\Sysprep” y ejecutamos sysprep /generalize /oobe /mode:vm /shutdown, y como podemos ver este es el error:

• Este error se produce por las aplicaciones integradas que trae embebida Windows 10, para poder realizarle un Sysprep a nuestro sistema, antes debemos desinstalar estas aplicaciones, que lo haremos con los siguientes comandos de PowerShell.
• Debemos importar estos dos módulos, Import-Module appx e Import-Module dism:

• Ahora introducimos el siguiente comando para desinstalar las aplicaciones integradas que trae embebida nuestro Windows 10, Get-AppxPackage | Remove-AppxPackage:

• Como podemos ver comienza con el proceso de eliminación:

• Ahora reiniciamos nuestro Windows 10 y una vez que hemos iniciado ya podemos hacerle el sysprep ejecutando el comando sysprep /generalize /oobe /mode:vm /shutdown

Saludos y espero que os sea de ayuda

En este post vamos a ver como recuperar el montaje de imágenes ISO en Windows 10, ya que en alguna ocasión seguro que nos hemos encontrado con este problema, seguramente por haber asignado la apertura de imágenes ISO a programas como 7Zip, Winrar …

• Como podemos ver en nuestro sistema no podemos montar las imágenes ISO:

• Para solucionar este problema debemos de aplicar el siguiente fichero .reg, que aquí os dejo para su descarga:

• Damos doble clic sobre el fichero restoreisow10.reg y le indicamos que Sí queremos agregar la información al registro:

• Como podemos ver las claves del registro se han agregado correctamente:

• Reiniciamos el equipo.
• Una vez reiniciado el equipo, asociamos el tipo de archivo .iso al “Explorador de Windows”:

• Y como podemos ver ya podemos montar las imágenes ISO en nuestro equipo con Windows 10:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo solucionar un error típico cuando realizamos la conversión de un disco duro virtual de VMware (.vmdk) a un disco de Hyper-V (.vhdx), este post va relacionado con otro que ya hicimos hace un tiempo, Convertir OVA a VHDX para infraestructuras de Hyper-V, el proceso normal debe ser este, pero en algunos casos al ejecutar el script de PowerShell, nos podemos encontrar con el error The entry 1 is not a supported disk database entry for the descriptor, que vamos a ver cómo solucionarlo:

• Lo primero que vamos a realizar será descargarnos un conjunto de herramientas dsfok, para actualizar la información del descriptor en el archivo vmdk, esta actualización hará que se entiendan la herramienta Microsoft VM Converter con el fichero .vmdk, como podemos ver ya la tenemos descargada y descomprimida en el directorio raíz:

• Nos situamos sobre el directorio dónde nos hemos descomprimido las herramientas dsfok y ejecutamos el siguiente comando dsfo.exe «C:\UBUNTUTESTOVA\UBUNTUTESTOVA-1.vmdk» 512 1024 descriptor1.txt:

• Una vez que se ha ejecutado correctamente el comando, editamos el fichero txt que se ha creado y comentamos la línea #ddb.toolsInstallType = «1»:

• Ahora nos situamos sobre el directorio dónde nos hemos descomprimido las herramientas dsfok y ejecutamos el siguiente comando dsfi.exe «C:\UBUNTUTESTOVA\UBUNTUTESTOVA-1.vmdk» 512 1024 descriptor1.txt:

• Para terminar, volvemos a ejecutar el script de PowerShell, y como podemos ver la conversión se realiza correctamente:

• Aquí tenemos el disco virtual para Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como eliminar el Warning, “The number of vSphere HA heartbeat datastore for host is “0 ó 1”, which is less than required : 2” , esta advertencia es debido a que no tenemos redundancia en nuestro almacenamiento compartido y sólo disponemos de 1 datastore o de ninguno:

• Para eliminar esta advertencia, tendremos que editar la configuración HA de nuestro cluster VMware vSphere:

• Se nos abrirá un editor de configuración, y sobre las Opciones avanzadas, damos clic sobre Agregar:

• Introducimos la siguiente opción das.ignoreInsufficientHbDatastore con el valor true y aceptamos:

• Para aplicar los cambios sobre uno de los host ESXi, volvemos a configurar para vSphere HA:

• Como podemos ver las advertencias “The number of vSphere HA heartbeat datastore for host is “0 ó 1”, which is less than required : 2” han desaparecido de los hosts ESXi pertenecientes al cluster:

Saludos y espero que os sea de ayuda

En este post vamos a ver como solucionar el error 9061 que tiene como ID de evento 4012, este error se produce ya que la carpeta SYSVOL, no se está replicando entre los controladores de dominio de la infraestructura, debido a que han pasado más de 60 días desde la última vez que esta carpeta de SYSVOL se replicó entre los controladores.

• En el visor de eventos de los controladores de dominio, sobre “Registro de aplicaciones y servicios > Replicación DFS” veremos este error:

• Para solucionar este error nos abrimos un cmd con permisos de administrador en cada controlador de domino de nuestra infraestructura e introducimos el siguiente comando “wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=365”, con este comando se ponen los contadores a cero y aumentamos a 365 días el tiempo que pueden estar sin conexión los controladores de domino:

• A partir de la aplicación del comando, la carpeta SYSVOL empezará a replicar entre los controladores de dominio, como bien podemos ver aquí, en el visor de eventos:

Saludos y espero que os sea de ayuda

En estos días al realizar el upgrade de los ESXi de la versión 5.5 a la 6.5 sobre servidores Fujitsu Primergy, me estoy encontrando con el error “CONFLICTING_VIBS_ERROR:…”, y no nos deja proseguir con el upgrade de versión, este es el error:

• Aquí mostraremos como solucionar este error para poder proseguir con el upgrade.

• Pulsamos sobre F11 para reiniciar y una vez que nuestro host este reiniciado y operativo, accedemos por SSH:

• Ejecutamos el siguiente comando para listar los paquetes VIBs y buscar el que nos está dando el conflicto, “esxcli software vib list”:

• Ejecutamos el siguiente comando para eliminar el paquete VIBs que nos está dando el conflicto, “esxcli software vib remove -n scsi-qla2xxx” y como podemos ver lo ha eliminado correctamente:

• Una vez eliminado el paquete vib, procedemos a reiniciar nuestro host ESXi, y ya nos dejará realizar el upgrade de la versión 5.5 a la 6.5.

Saludos y espero que os sea de ayuda

En este post vamos a ver un error que nos encontramos al actualizar nuestros equipos clientes Windows e intentamos acceder a los servidores por escritorio remoto, se trata de la actualización “CredSSP para CVE-2018-0886” (KB4093120) – Seguridad de credenciales, en esta URL podemos ver que es lo que hace esta actualización en nuestros sistemas, y el problema que nos encontramos es que si la actualización NO está instalada en los servidores y SI en los equipos clientes, estos no pueden acceder por escritorio remoto a los servers, aquí simularé el error, y os mostraré una forma para poder solucionarlo, Microsoft nos aconseja que instalemos este KB en los servidores y en los equipos clientes, pero hay infraestructuras en dónde no es posible actualizar los servidores, ya sea porque no tienen o no deben tener conexión a Internet, la infraestructura sea muy grande y tengamos que darle una solución rápida mientras vamos actualizando los servers, etc…. Cada infraestructura es un mundo

• Tenemos un servidor llamado “adcs” que NO tiene parcheada la actualización y un equipo con Windows 10 llamado “ca-itlabw10” perteneciente al mismo dominio que el servidor que SI tiene la actualización instalada:

• Intentamos acceder por escritorio remoto al servidor introduciendo las credenciales, y este es el error que nos muestra:

• Para solucionar el error tenemos dos opciones:
• 1) Si lo que queremos es acceder al servidor únicamente desde un equipo, por ejemplo, desde este equipo con Windows 10, entonces actualizamos las directivas locales con gpedit.msc y configuramos esta directiva:

• 2) Si lo que queremos es acceder desde cualquiera de los equipos pertenecientes al dominio, entonces debemos habilitar una política de grupo (GPO) en el dominio y vincularla sobre la Unidad Organizativa de equipos:
• No creamos la GPO:

• Le asignamos un nombre:

• La editamos:

• Sobre Configuración de equipo > Directivas > Plantillas administrativas >Sistema > Delegación de credenciales, damos doble clic sobre “Encryption Oracle Remediation”:

• Y la configuramos de la siguiente manera, “Habilitada y Vulnerable”:

• Como podemos ver ya está configurada y vinculada sobre la Unidad organizativa correspondiente:

• Ahora forzamos las GPO sobre el equipo cliente con Windows 10:

• Y probamos a conectar por escritorio remoto al servidor:

• Como podemos ver, una vez hemos aplicado la GPO, ya podemos conectar por RDP sin problemas:

Saludos y espero que os resulte de ayuda

Últimamente en algunas instalaciones de MS Windows 10 y sobre todo al realizar el upgrade de Windows 7 a Windows 10 me he encontrado con el problema de que la unidad de DVD no la reconoce el sistema operativo, la BIOS del equipo la reconoce perfectamente (si en BIOS no se detecta estaríamos hablando de otro problema y por tanto de otra solución), una vez aclarado cuál es el problema os muestro la solución del mismo.

• Lo primero que vamos a realizar y como buena práctica, será un backup del registro de Windows, ya que si lo modificamos incorrectamente podemos tener graves problemas con nuestro sistema operativo, para ello nos abrimos una ventana de “Ejecutar” con las teclas Windows+R o clic derecho icono Windows y “Ejecutar”:

• Tecleamos “regedit”:

• Nos situamos sobre “Equipo” para realizar el backup del registro completo, y vamos a Archivo > Exportar:

• Le indicamos la ubicación, le asignamos un nombre y guardamos:

• Como vemos ya tenemos el backup de nuestro registro:

• Comprobamos que nuestro Windows 10 no reconoce la unidad de DVD:

• Para hacer que el sistema operativo vuelva a detectar la unidad de DVD, volvemos al regedit y en el panel de exploración buscamos la siguiente subclave del registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi

• Clic derecho en “atapi” > Nuevo > Clave:

• Le damos el nombre “Controller0” y presionamos enter:

• Clic derecho en “Controller0” > Nuevo > Valor de DWORD (32 bits):

• Le damos el nombre “EnumDevice1” y presionamos enter:

• Clic derecho en “EnumDevice1” y modificamos:

• En “Información del valor” le damos el valor 1 y aceptamos:

• Salimos del registro y reiniciamos el equipo.
• Como podemos ver nuestro Windows 10 ya reconoce la unidad de DVD:

Saludos y espero que os sea de ayuda