• En este post vamos a ver como auditar los accesos a los a los objetos en nuestros equipos unidos a un dominio de Active Directory.
• Lo primero que debemos hacer es crearnos una GPO para habilitar la auditoría de objetos en nuestro Active Directory, para ello nos abrimos la consola de Administración de directivas de grupo y sobre Objetos de directivas de grupo le indicamos que queremos crearnos una nueva GPO:

• Le damos un nombre a la GPO y la editamos:

• Accedemos a Configuración del equipo > Dircetivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría y configuramos-habilitamos la directiva Auditar el acceso a objetos:

• Ahora, esta configuración es opcional, pero muy recomendable, vamos a habilitar la auditoría avanzada, para ello, accedemos a Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Configuración de directiva avanzada de auditoría > Directiva de auditoría detallada > Acceso a objetos y configuramos-habilitamos las directivas Auditar almacenamiento extraíble y Auditar sistema de archivos:

• Una vez editada, aquí tenemos la configuración para habilitar la auditoría a objetos en nuestros equipos del AD:

• Aunque la GPO activa la auditoría, nosotros necesitamos configurar en cada equipo o mediante script qué carpetas/archivos serán auditados, vamos a ver un ejemplo:
• Para hacerlo de forma manual en una carpeta de cualquiera de nuestros equipos del dominio, debemos dar clic derecho sobre la carpeta > Propiedades > Pestaña Seguridad > Opciones avanzadas > Auditoría y agregamos:
• Usuario: Todos
• Tipo: Todo
• Se aplica a: Esta carpeta, subcarpetas y archivos
• Permisos avanzados: Crear archivos/escribir datos, Crear carpetas/anexar datos, Eliminar subcarpetas y archivos, Eliminar.

• Esto puede automatizarse mediante scripts de PowerShell, hemos creado este script, llamado auditoriausuarios.ps1, que lo podemos descargar desde este enlace, dónde vamos a auditar las carpetas del escritorio, documentos y descargas de todos los usuarios:

• Nos creamos este script en .bat, para cuando configuremos la GPO, invoquemos desde este script, al script de PowerShell:

• Ahora accedemos a cualquiera de nuestros controladores de dominio y copiamos estos dos scripts en esta ruta:

• En la consola de Administración de directivas de grupo, volvemos a editar la GPO que creamos y configuramos para la auditoria de objetos:

• Accedemos a Configuración del equipo > Directivas > Configuración de Windows > Scripts (Inicio o apagado) > Inicio > Scripts > Agregar > Examinar y añadimos el script .bat, Aceptar:

• Y así nos quedaría la GPO, completamente configurada:

• Ahora esta GPO, la vamos a vincular sobre la OU Equipos, para que empiece a auditar el acceso a los objetos:

• Como podemos ver, aquí la tenemos vinculada:

• Sobre uno de nuestros equipos del dominio ejecutamos un gpupdate /force para aplicar las nuevas directivas:

• Una vez aplicada la GPO, vamos que en las carpetas han cambiado sus permisos de auditoría:

• Con todo esto ya tenemos configurado las auditorías de los acceso a objetos en los equipos de nuestro Active Directory.
• Los registros de auditoría quedan todos guardados en el Visor de eventos de los equipos de los usuarios, en los Registros de Windows > Seguridad:

• Ahora vamos a crear y eliminar algunos ficheros de uno de nuestros equipos y veremos en el visor de eventos que usuario a creado y eliminado estos ficheros.
• Creamos estos dos ficheros:

• Eliminamos estos dos ficheros:

• Con el ID de evento 4663 vemos como se crean los ficheros:

• Y con el ID de evento 4659 vemos como se eliminan los ficheros:

Saludos y espero que os resulte de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar las políticas de contraseñas granulares en nuestro Active Directory, estas políticas van a prevalecer sobre las políticas de contraseñas configuradas en las políticas de grupo (GPO) y las asignaremos a grupos de usuarios.

• Si accedemos a la consola de Administración de directivas de grupo de nuestro Active Directory, podemos ver que tenemos esta política configurada:

• Para configurar una política distinta de contraseña a un grupo de usuarios y que prevalezca sobre esta política, debemos de acceder a la consola, Centro de Adminsitración de Active Directory > Dominio > System > Password Settings Container > Nuevo > Configuración de contraseña:

• Configuramos la política de contraseña que nos interese, y le asignamos el grupo de usuarios al que le queremos aplicar esta política:

• Y aquí tenemos, nuestra política granular creada:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como deshabilitar la ejecución del símbolo de sistema a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > Impedir acceso al símbolo del sistema:

• Habilitamos la GPO, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar el símbolo del sistema:

• Si intentamos abrir un símbolo del sistema nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como deshabilitar la ejecución de PowerShell a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > No ejecutar aplicaciones de Windows especificadas:

• Habilitamos la GPO, sobre Lista de aplicaciones no permitidas damos a Mostrar y escribimos la lista que pueden ejecutar PowerShell, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar PowerShell:

• Si intentamos abrir un Powershell nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde Hyper-V a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery service > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error y la red virtual, clic sobre Aceptar:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error planeada, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, la conmutación por error planeada, se ha realizado correctamente:

• Una vez terminada la conmutación por error planeada, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

• Ahora vamos a suponer, que nuestra máquina virtual principal en el servidor on-premise de Hyper-V, no nos inicia, por el motivo que sea, vemos que esta apagada:

• Vamos a realizar entonces una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con Hyper-V a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor de Hyper-V con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-hv-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Hyper-V, en este link de este mismo blog, podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog, podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, máquinas físicas, máquinas de VMware (que lo vamos a ver en otro post), para System Center VMM, y la que nos interesa a nosotros en estos momentos que son Para sitios de Hyper-V:

• Lo primero que vamos a realizar será crearnos un Sitio de Hyper-V, donde le indicamos un nombre:

• Como vemos, ya tenemos creado el sitio:

• Lo siguiente será, agregar un host de Hyper-V, para ello nos vamos a Hosts de Hyper-V > Agregar servidor:

• Aquí se nos muestran todos los pasos para agregar el host de Hyper-V:

• Los dos primeros pasos, los cumplimos, procedemos por tanto a descargar el instalador del proveedor de Microsoft Azure Site Recovery (paso 3) y a descargar la clave de registro del almacén para registrar el host en un sitio de Hyper-V (paso 4):

• Una vez descargados, sobre nuestro servidor de Hyper-V vamos a proceder a instalar el proveedor de Microsoft Azure Site Recovery usando la clave de registro del almacén para registrar el servidor en el almacén (paso 5).
• Activamos las actualizaciones de Microsoft update:

• Damos a instalar:

• Comienza el proceso de instalación:

• Aquí vemos que ha finalizado correctamente, ahora procedemos a registrar el servidor en el almacén de recovery services de Azure, clic en Registrarse:

• Sobre Configuración del almacén, añadimos el Archivo de clave:

• Sobre Configuración de proxy, le indicamos que nos vamos a conectar directamente con Azure Site Recovery sin un servidor proxy:

• Comienza con el registro:

• Pasados unos minutos, ya tenemos nuestro servidor de Hyper-V registrado en nuestro almacén de recovery services de Azure, finalizamos:

• Para verificar que todo está correcto, nos vamos a nuestro almacén de recovery services en Azure, a la parte de Infraestructura de Site Recovery > Hosts de Hyper-V, y vemos que nos aparece como un servidor registrado y en estado Conectado:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre, el tipo de origen que será Hyper-V, el tipo de destino que será Azure, la frecuencia de copia, retención de puntos de recuperación en horas, la frecuencia de instantáneas coherentes a nivel de aplicación y la hora de inicio de la replicación inicial:

• Aquí vemos la directiva de replicación creada:

• Una vez creada, la tenemos que asociar al sitio de Hyper-V:

• Como podemos ver, ya está asociada:

• Una vez definida la infraestructura de Site Recovery para Hyper-V, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de HyperV, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas de Hyper-V a Azure:

• Sobre Entorno de origen, seleccionamos el sitio de Hyper-V que nos creamos anteriormente:

• Sobre Entorno de destino, seleccionamos la suscripción, el grupo de recursos, el modelo de implementación, el tipo de almacenamiento y la red dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error:

• Sobre el Tipo de almacenamiento debemos de hacer una aclaración, ya que vamos a usar un disco administrado (esta opción es nueva), esto no era posible usarlo antes, y teníamos que hacerlo con una cuenta de almacenamiento, de ahí que anteriormente nos creásemos esa cuenta, si usamos un discos administrados no hace falta crearnos la cuenta de almacenamiento:

• Sobre Selección de la máquina virtual, seleccionamos las máquinas que nos interesen:

• Sobre Configuración de replicación, seleccionamos el tipo de sistema operativo, el disco del sistema operativo, los discos a replicar, en este caso replicamos los dos discos que tiene la máquina virtual, le indicamos el tipo de disco administrado y la cuenta de almacenamiento en caché:

• En Directiva de replicación, seleccionamos la directiva que nos creamos anteriormente:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver que la réplica inicial está en proceso:

• Sobre el servidor de Hyper-V, y la máquina virtual a replicar > Replicación > Ver mantenimiento de la replicación, podemos ver, que la réplica se está realizando correctamente:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra esperando el primer punto de recuperación:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de Hyper-V:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con Hyper-V hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo mover las máquinas virtuales de Hyper-V, en algunas ocasiones nos vamos a encontrar en el caso de que tengamos que mover nuestras máquinas virtuales de ubicación dentro del mismo servidor de Hyper-V, ya sea en el mismo disco en otro directorio, a otro disco porque en el que está se está quedando sin espacio por ejemplo, etc…, también tendremos la opción de mover la maquina a otro servidor distinto de Hyper-V, aquí vamos a mostrar la manera correcta de mover estas máquinas virtuales.

• Como podemos ver, tenemos esta máquina virtual y la tenemos ubicada en:

• Para mover de forma correcta la máquina virtual, damos clic derecho sobre la máquina y Mover:

• Se nos abrirá este asistente, que nos va a guiar en el proceso, sobre Antes de empezar nos muestra la información del proceso, clic en Siguiente:

• Sobre Elegir tipo de movimiento vamos a seleccionar Mover la máquina virtual, clic en Siguiente:

• Sobre Especificar destino, vamos a seleccionar otro hypervisor de nuestra infraestructura, clic en Siguiente:

• Sobre Elegir opciones de movimiento, vamos a seleccionar la primera opción, Mover los datos de la máquina virtual a una sola ubicación, clic en Siguiente:

• Sobre Máquina virtual, le indicamos la ubicación en el equipo de destino, clic en Siguiente:

• Sobre Resumen, nos muestra todo lo que hemos configurado, clic en Finalizar:

• Una vez finalizado el movimiento, si accedemos al hypervisor de destino, podemos ver ya la máquina virtual:

• Aquí vemos la estructura de carpetas que nos ha creado tras el movimiento:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar Windows LAPS para la contraseña DSRM (restauración de servicios de directorio) de Active Directory, esta contraseña la asignamos cuando desplegamos el rol de Servicios de dominio de Active Directory, esta es una nueva característica del nuevo Windows LAPS.

• Lo primero que vamos a realizar es acceder a uno de nuestros controladores de dominio y nos abrimos la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre uno de ellos, y sobre la pestaña LAPS podemos ver, que es aquí dónde nos va a mostrar la contraseña de DSRM, una vez que tengamos la GPO configurada y vinculada sobre la OU Domain Controllers:

• Nos abrimos la consola Administración de directivas de grupo y nos vamos a crear una nueva GPO llamada LAPS_DSRM con la siguiente configuración:

• Luego vinculamos esta GPO sobre la OU Domain Controllers:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS01 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS01, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

• Ahora si nos abrimos un PowerShell sobre el controlador de dominio DCRGS02 y ejecutamos un gpupdate /force, vamos a forzar a que se activen estas nuevas configuraciones de directivas que hemos creado:

• Si accedemos de nuevo a la consola de Usuarios y equipos de Active Directory, nos vamos a la Unidad Organizativa (OU) Domain Controllers, damos Propiedades sobre DCRGS02, y sobre la pestaña LAPS podemos ver, que ya se ha aplicado esta nueva GPO para controlar las contraseñas de DSRM de los controladores de dominio de nuestra infraestructura:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo instalar y configurar Windows LAPS (Local Administrator Password Solution) en Windows Server 2022, LAPS determina si la contraseña de la cuenta del administrador local ha caducado, si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory dónde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.

• Los requisitos para configurar esta nueva implementación de LAPS, son los siguientes, ya que anteriormente a estas nuevas actualizaciones, LAPS había que implementarlo de forma manual, en este link os dejo como se hacía anterior a estas actualizaciones, con estas nuevas actualizaciones LAPS se implementa de forma nativa en estos sistemas:
• Windows 11 22H2 – Actualización 11 abril 2023
• Windows 11 21H2 – Actualización 11 abril 2023
• Windows 10 – Actualización 11 abril 2023
• Windows Server 2019 – Actualización 11 abril 2023
• Windows Server 2022 – Actualización 11 abril 2023
• Para implementar y configurar este laboratorio, he utilizado dos máquinas Windows Server 2022 Standard como Controladores de dominio, uno principal y otro adicional, una máquina Windows Server 2022 Standard y otra con Windows 11 Pro, que serán miembros del dominio ragasys.local implementado en los dos controladores de dominio:

• Para empezar, vamos a extender el schema de Active Directory, para que se añadan los atributos nuevos a las propiedades de los equipos de nuestra infraestructura, para ello, accedemos a nuestro controlador de dominio principal, dcrgs01, nos abrimos un PowerShell y nos importamos los módulos de LAPS con el comando Import-Module LAPS:

• Para ver los comandos disponibles en este módulo ejecutamos Get-Command -Module LAPS:

• Para extender el schema de nuestro Active Directory y soportar toda la configuración de LAPS, vamos a utilizar el comando Update-LapsADSchema, le indicamos que Si (S) uno a uno o podemos indicarle que Sí a todo (O), aquí he elegido la primera opción, para mostrar todos los atributos que se van a añadir en las propiedades de los equipos de nuestra infraestructura de dominio:

• Para verificar que los atributos se han añadido correctamente a nuestros equipos, sobre nuestro controlador de dominio principal, accedemos a Usuarios y equipos de Active Directory y abrimos las propiedades de cualquier equipo:

• Accedemos a la pestaña Editor de atributos, y como podemos ver, ya se han añadido los atributos de LAPS a los equipos:

• Ahora vamos a establecer los permisos para LAPS en las Unidades Organizativas (OU) que nos interesen, en este caso, las OUs que vamos a utilizar serán las de Equipos para las máquinas clientes y la de Servidores para las máquinas con el rol de servidor, estos permisos va a permitir a LAPS modificar los atributos de las cuentas de equipos que se encuentran en estas OUs, permitiendo así crear y modificar las contraseñas, para ello ejecutamos el comando, Set-LapsADComputerSelfPermission -Identity “DistinguisedName OU”:

• Ahora vamos a configurar las GPOs para LAPS en Active Directory, en nuestro caso, vamos a configurar dos GPOs, una para los equipos clientes llamada LAPS_Equipos y otra para los servidores llamada LAPS_Servidores, habilitamos la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la complejidad, longitud y expiración, estas serían las dos GPOs configuradas:

• Una vez que tenemos creadas las GPOs las vamos a vincular sobre las unidades organizativas que indicamos anteriormente:

• Con esto ya tendríamos implementado y configurado LAPS en nuestra infraestructura, lo primero que vamos a verificar es que la GPO se está aplicando en los equipos de cada unidad organizativa, para ello, en cualquiera de los equipos de ambas unidades organizativas ejecutamos el comando gpresult /r:

• Ahora para ver la password del administrador local de los equipos, accedemos a cualquiera de nuestros controladores de dominio, accedemos a la consola de Usuarios y equipos de Active Directory, y abrimos las propiedades de cualquier equipo:

• Accedemos a la pestaña LAPS, y desde aquí podemos ver el Nombre de la cuenta de administrador local de LAPS, la Contraseña de la cuenta de administrador local de LAPS (Copiar y Mostrar), podemos ver la Expiración actual de contraseña de LAPS, y Establecer nueva expiración de contraseña de LAPS:

• Si nos abrimos un PowerShell en cualquiera de nuestros controladores de dominio, y ejecutamos primero el comando Get-Command -Module LAPS, para ver los comandos disponibles en el módulo de LAPS:

• Ejecutando el comando Get-LapsADPassword “nombreequipo” -AsPlainText, podemos ver, la cuenta del administrador local del equipo con su contraseña:

• Sólo los usuarios Administradores del dominio tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración, en muchas ocasiones, necesitamos dar permisos a otros usuarios, por lo que vamos a crear este grupo, LAPS_HelpDesk, y dentro de este grupo añadiremos a los usuarios o grupos que nos interesen, si hacemos esto, el grupo Administradores del dominio también lo tenemos que añadir al grupo, ya que si no, no podremos visualizar las contraseñas con las cuentas de administrador:

• Ahora tenemos que volver a configurar las dos GPOs que creamos anteriormente y habilitar estas dos opciones, Habilitar cifrado de contraseña y Configurar descifradores de contraseñas autorizados que incluiremos al grupo que hemos creado anteriormente:

• Ahora asignamos los permisos para el grupo LAPS_HelpDesk.
• Con este comando asignamos los permisos de lectura sobre la OU especificada:
• Set-LapsADReadPasswordPermission -Identity “distinguisedname OU” -AllowedPrincipals “DOMINIO\GRUPO”
• Con este comando asignamos los permisos de lectura-escritura sobre la OU especificada:
• Set-LapsADResetPasswordPermission -Identity “distinguisedname OU” -AllowedPrincipals “DOMINIO\GRUPO”

• Con el siguiente cmdlet verificamos la asignación de permisos asignados a las Unidades Organizativas, Find-LapsADExtendedRights -Identity “distinguisedname OU”:

• Ahora si accedemos a cualquier equipo de nuestra infraestructura, con el usuario ubicado en el grupo LAPS_HelpDesk, podemos ver las credenciales del usuario local administrador y resetear las contraseñas:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo actualizar la versión de configuración en las máquinas virtuales de Hyper-V.

La versión de configuración de las máquinas virtuales en Hyper-V nos indica que configuraciones y funcionalidades están disponibles para nuestras máquinas virtuales, cuando Microsoft lanza actualizaciones importantes para sus sistemas operativos suele cambiar la versión de configuración, para poder aplicar estas nuevas funcionalidades.

• Como podemos ver tenemos cuatro máquinas virtuales en este servidor de Hyper-V, dos están en versión 9.0 y otras dos en versión 8.0:

• Vamos a cambiar la versión de configuración de las máquinas virtuales que están en versión 8.0 para que estén en la última versión 9.0, lo vamos a hacer de dos formas, una a través de la consola de Hyper-V y otra a través de PowerShell.
• Empezamos por cambiar la versión de configuración a través de la consola de Hyper-V, para ello, damos botón derecho sobre la máquina que queremos cambiar, y seleccionamos Actualizar versión de configuración:

• Nos indica, si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, damos a Actualizar:

• Como podemos ver, ya la tenemos cambiada a versión 9.0:

• Ahora vamos a cambiar la versión de configuración a través de PowerShell, para ello, nos abrimos un PowerShell como Administrador:

• Y ejecutamos el siguiente cmdlet, Update-VMVersion nombreMV, nos indica si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, le indicamos que Sí:

• Ahora si accedemos a la consola de Hyper-V, podemos ver, que ya la tenemos cambiada a versión 9.0:

• Si damos botón derecho sobre cualquiera de las máquinas, que están ya en versión 9.0, esta opción no está disponible en la máquina virtual, esto quiere decir que ya tiene la versión de configuración más alta compatible con el host de Hyper-V:

• Si ejecutamos el cmdlet, Get-VMHostSupportedVersion, podemos ver qué versiones de configuración de máquina virtual admite el host de Hyper-V:

Saludos y espero que os resulte de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar la interface de red de un equipo Windows a través de la consola cmd.

• Nos abrimos un terminal de cmd como administrador:

• Y ejecutamos el comando netsh interface ipv4 set address name=»LAN» source=static address=192.168.5.2 mask=255.255.255.0 gateway=192.168.5.210:

• Ahora para configurar el DNS primario ejecutamos, netsh interface ip add dnsservers «LAN» 8.8.8.8 index=1:

• Para terminar, configuramos el DNS secundario ejecutando, netsh interface ip add dnsservers «LAN» 8.8.4.4 index=2:

• Para verificar que todo se ha configurado correctamente, ejecutamos un ipconfig /all:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo cambiar la zona horaria de un equipo Windows a través de PowerShell.

• Con este cmdlet nos va a mostrar un listado de todas las zonas horarias disponibles, Get-TimeZone -ListAvailable:

• Ahora con este cmdlet Get-TimeZone nos va a mostrar la zona horaria en la que se encuentra nuestro equipo:

• Nosotros queremos cambiarla a (UTC+01:00) Brussels, Copenhagen, Madrid, Paris:

• Para ello, introducimos el cmdlet Set-TimeZone -Id «Romance Standard Time» aquí debemos introducir el Id de la zona horaria a la que queramos cambiar:

• Introduciendo de nuevo el cmdlet Get-TimeZone podemos ver como la zona horaria de nuestro equipo a cambiado:

Saludos y espero que os resulte de ayuda

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 como configurar la página de inicio en Microsoft Edge, Google Chrome y Mozilla Firefox a través de una GPO configurada en nuestro Active Directory.

• Empezaremos configurando la GPO para la página de inicio de Microsoft Edge, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Microsoft Edge, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso si lo tenemos configurado:

• Ahora sobre la consola Administración de directivas de grupo, nos creamos una nueva GPO:

• Le damos un nombre:

• Editamos la nueva GPO:

• Accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Microsoft Edge > Inicio, página principal y página de la nueva pestaña:

• Sobre Configurar la dirección URL de la página principal la habilitamos e introducimos la URL:

• Sobre Acción que se realizará al inicio la habilitamos y le indicamos Abrir una lista de direcciones URL:

• Sobre Sitios que se abrirán cuando se inicia el explorador la habilitamos y le indicamos la URL:

• Sobre Mostrar el botón de inicio en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Microsoft Edge:

• Ahora seguiremos configurando la GPO para la página de inicio de Google Chrome, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Google Chrome, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso, si lo tenemos configurado:

• Seguimos editando la GPO y accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Google > Google Chrome > Inicio, Página principal y página Nueva pestaña:

• Sobre Configurar la URL de la página principal la habilitamos e introducimos la URL:

• Sobre Acción al iniciar la habilitamos y le indicamos Abrir una lista de URLs:

• Sobre URL que se deben abrir al inicio la habilitamos y le indicamos la URL:

• Sobre Mostrar botón de página principal en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Google Chrome:

• Ahora seguiremos configurando la GPO para la página de inicio de Mozilla Firefox, para ello, lo primero que vamos a realizar será descargarnos las plantillas admx y adml para la configuración de Mozilla Firefox, desde este link las podemos descargar:

• Estas plantillas las copiamos en el GPO central store de nuestro Active Directory, si no tenemos configurado GPO central store, debemos de copiarlas en la ruta C:\Windows\PolicyDefinitions de cada controlador de dominio, en mi caso, si lo tenemos configurado:

• Seguimos editando la GPO y accedemos a la ruta Configuración del equipo > Directivas > Plantillas administrativas > Mozilla > Firefox > Página de inicio:

• Sobre URL de la página de inicio la habilitamos e introducimos la URL, no permitimos que se cambie la página de inicio:

• Sobre Mostrar botón de página principal en la barra de herramientas la habilitamos:

• Así nos quedaría la GPO para Mozilla Firefox:

• Así nos quedaría configurada nuestra GPO “Conf_Edge_Chrome_Firefox” para poner la página de inicio que nos interese a los equipos de nuestra infraestructura con estos tres navegadores, Microsoft Edge, Google Chrome y Mozilla Firefox:

• Una vez que ya tenemos la GPO “Conf_Edge_Chrome_Firefox” preparada y configurada, la vinculamos sobre las Unidades organizativas que nos interese:

• Como podemos ver ya está vinculada sobre la OU Equipos:

• Ahora en cualquiera de los equipos de nuestro dominio, iniciamos sesión y verificamos la página de inicio de los tres navegadores:

• Podemos verificar que las GPOs se están aplicando correctamente abriéndonos un PowerShell y ejecutando el comando gpresult /r:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo solucionar el error “La vinculación de un conmutador virtual a un equipo de LBFO está en desuso”, este error se produce cuando creamos un nuevo virtual switch con las interfaces de red en NIC Teaming.

• Aquí vemos el NIC Teaming realizado en el servidor, realizado con dos interfaces de red:

• Cuando intentamos crear el virtual switch con la interface de NIC Teaming, nos dará este error, indicándonos que la arquitectura LBFO está “deprecated” en desuso:

• Para solucionar este error, lo primero que debemos de hacer es eliminar el NIC Teaming:

• Como podemos ver, el NIC Teaming ya está deshabilitado, si en los ADAPTADORES E INTERFACES no nos aparece alguna interface de red, debemos de ir a las Conexiones de red y sobre las Propiedades de la interface, desmarcar el check Conmutador virtual extensible para Hyper-V:

• Una vez eliminado el NIC Teaming, para crearnos el conmutador virtual con dos interfaces y tener redundancia, nos abrimos un PowerShell con permisos de administrador y ejecutamos el comando New-VMSwitch -Name vSwitchLAN -NetAdapterName «LAN1″,»LAN2» -EnableEmbeddedTeaming $true como podemos ver, ya nos ha creado el Conmutador Virtual con dos NICs:

• Si accedemos a la consola de Hyper-V, podemos ver, que ya tenemos creado el Virtual Switch:

• Si accedemos a las conexiones de red, podemos ver, la interface virtual que se ha creado para este conmutador virtual, aquí es dónde se debe de configurar el protocolo TCP/IP:

Saludos y espero que os sea de ayuda

En este post vamos a ver como transferir los roles FSMO entre Controladores de dominio ejecutando un comando con PowerShell, en otros posts realizados, hemos visto como transferir estos roles a través de las consolas de Windows, en esta ocasión, vamos a ver cómo hacerlo con PowerShell.

• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Para ver los controladores de dominio que tenemos en nuestra infraestructura nos abrimos un PowerShell con permisos de administrador en cualquiera de nuestros controladores de dominio, y ejecutamos netdom query dc:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y cómo podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio dc01:

• Para transferir los roles fsmo del controlador de dominio dc01 al controlador de domino dc02, ejecutamos el siguiente comando, Move-ADDirectoryServerOperationMasterRole -Identity «DC02» -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator:

• Volvemos a ejecutar el comando netdom query fsmo, y como podemos ver, los roles fsmo ya los tiene asignados el dc02:

• También podemos usar este otro comando Move-ADDirectoryServerOperationMasterRole -Identity «DC01» -OperationMasterRole 0, 1, 2, 3, 4 ahora hemos transferido todos los roles del dc02 al dc01:

• Volvemos a ejecutar el comando netdom query fsmo, y como podemos ver, los roles fsmo ya los tiene asignados el dc01:

• Cada número se corresponde con los roles fsmo:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar un controlador de dominio con Windows Server 2019 a Windows Server 2022.

En este laboratorio, sólo tenemos un controlador de dominio con Windows Server 2019, el cual lo vamos a migrar a Windows Server 2022.

• Como podemos ver, tenemos un controlador de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2019 Standard:

• Los roles o funciones que tiene este servidor son los siguientes, “Servicios de dominio de Active Directory, DNS y DHCP”:

• Ahora debemos desplegar un nuevo server con el sistema operativo MS Windows Server 2022 Standard, lo actualizamos y lo configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestro controlador de dominio adicional asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP del controlador de dominio principal y como DNS secundario no configuramos nada, más tarde, le configuraremos su propia dirección IP:

• Ahora agregamos este equipo como un miembro más del dominio:

• Le proporcionamos las credenciales del Administrador del dominio y reiniciamos el equipo:

• Como podemos ver se ha agregado correctamente, reiniciamos el servidor:

• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, este equipo ya pertenece al dominio ragasys.net:

• Iniciamos sesión en DC02 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio:

• En el Administrador del servidor agregamos roles y características:

• Se nos abre el asistente típico para desplegar los roles y características, hacemos clic en siguiente:

• Sobre Tipo de instalación, elegimos la opción, Instalación basada en características o roles:

• Seleccionamos nuestro servidor dc02:

• Sobre Roles de servidor, marcamos la opción Servicios de dominio de Active Directory:

• Agregamos las características:

• Clic en siguiente:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Información sobre Active Directory :

• Sobre Confirmación, iniciamos el despliegue del rol Servicios de dominio de Active Directory, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue de los Servicios de dominio de Active Directory:

• Una vez finalizada la instalación cerramos el asistente:

• Sobre el Administrador del servidor y promovemos este servidor a controlador de dominio:

• Sobre Configuración de implementación, marcamos la opción Agregar un controlador de dominio a un dominio existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del dominio, clic en Siguiente:

• Sobre las Opciones del controlador de dominio, seleccionamos la función de DNS, ya que es un requisito imprescindible para Active Directory, también seleccionamos que sea Catálogo Global y luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Sobre Opciones de DNS, la dejamos por defecto, ya que el DNS lo tenemos configurado sobre el controlador de dominio principal, por lo que el controlador de dominio adicional se va a configurar automáticamente con la misma configuración que el principal:

• En Opciones adicionales, le indicamos que replique desde el controlador de dominio principal:

• Sobre Rutas de acceso las dejamos por defecto:

• Sobre Revisar opciones, nos muestra un resumen de las configuraciones seleccionadas, clic en Siguiente:

• Sobre Comprobación de requisitos previos, nos muestra que todas las comprobaciones se realizaron correctamente, clic a Instalar:

• Sobre Instalación, podemos ver como comienza a instalar y configurar los Servicios de dominio de Active Directory, una vez instalados, el servidor se va a reiniciar automáticamente:

• Tras el reinicio, nos abrimos la consola de Usuarios y equipos de Active Directory, y cómo podemos ver, este equipo ya está como un Domain Controller más de nuestra infraestructura:

• También podemos comprobarlo con el comando netdom query dc:

• Ahora accedemos a la configuración TCP/IPv4 de nuestro controlador de dominio recién desplegado y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Con el comando repadmin /showrepl, verificamos que nuestro nuevo controlador de dominio está replicando con el controlador de domino principal:

• Con el comando dcdiag /test:replications comprobamos la replicación y cualquier error de replicación entre los controladores de dominio:

• Con el comando dcdiag /test:connectivity comprobamos la conectividad y cualquier error de conexión entre los controladores de dominio:

• Con el comando dcdiag /test:DNS comprobamos que el DNS esté funcionando correctamente:

• Estas mismas pruebas de diagnóstico, las debemos de realizar sobre el controlador de domino principal y así nos aseguramos que nuestros controladores de dominio estén en perfecto estado.
• Una vez que tenemos agregado un controlador de dominio adicional con sistema operativo MS Windows Server 2022, y por tanto, superior a MS Windows Server 2019, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2022 quedará como principal.
• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio con Windows Server 2019 (dc01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO al controlador de dominio adicional (Windows Server 2022), convirtiéndolo así en el domain controller principal, para ello utilizaremos las siguientes herramientas.
• Para transferir los roles de PDC Emulator, RID Master e Infraestructure Master vamos a utilizar la herramienta Usuarios y equipos de Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• Primero vamos a transferir el RID Master:

• Segundo vamos transferir el PDC Emulator:

• En tercer lugar vamos a transferir el Infrastructure Master:

• En cuarto lugar, vamos a transferir el Domain Naming Master, para ello vamos a utilizar la herramienta Dominios y Confianzas Active Directory, que nos la abrimos en nuestro controlador de dominio adicional con MS Windows Server 2022:

• En quinto lugar, vamos a transferir el Schema Master, para ello vamos a utilizar la herramienta de consola Esquema de Active Directory, para poder utilizar esta herramienta tenemos que registrar la dll dll y personalizarnos una consola mmc, para ello, en nuestro controlador de dominio principal con MS Windows Server 2019 hacemos lo siguiente:

• Al intentar cambiarlo nos da el siguiente error, ya que como destino se encuentra el mismo controlador de dominio:

• Procedemos a cambiar el controlador de dominio de Active Directory:

• Como podemos ver ya tenemos como destino el controlador de dominio adicional:

• Como podemos ver, ya tenemos como Schema Master al controlador de dominio adicional (Windows server 2022):

• Una vez que hemos realizado la transferencia de los cinco roles FSMO entre los controladores de dominio, sobre cualquiera de ellos vamos a ejecutar el siguiente comando netdom query fsmo para verificar que la transferencia se ha realizado correctamente, y como podemos ver, todos los roles los tiene asignados el que estaba como controlador de dominio adicional, lo hemos convertido por tanto en el controlador de dominio principal:

• Si los cinco roles FSMO no los transferimos de forma manual, el proceso de despromoción los transferirá de forma automática a cualquier Controlador de dominio disponible, a mí personalmente prefiero hacerlo de forma manual.

• Ahora ya podemos despromocionar como controlador de dominio el servidor con MS Windows Server 2019, para ello, vamos a realizar lo siguiente:
• Nos abrimos el Administrador del servidor y pinchamos sobre la opción Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Sobre Roles de servidor, desmarcamos el check “Servicios de dominio de Active Directory” y sobre el asistente que se nos abre hacemos clic en “Quitar características”:

• Se nos abre el siguiente asistente, que nos indica que tenemos que disminuir el nivel, por lo tanto, hacemos clic sobre “Disminuir el nivel de este controlador de dominio”:

• Se nos vuelve a abrir otro asistente, dónde verificamos que las credenciales sean las correctas, esta es la opción más importante del asistente, ya que al ser un controlador de dominio adicional o secundario NO aparece la opción de marcar el check “Último controlador de dominio en el dominio”, clic sobre “siguiente”:

• Marcamos el check “Continuar con la eliminación” y clic sobre siguiente:

• En las opciones de eliminación marcamos el check para “Quitar delegación de DNS”, introducimos las credenciales y clic sobre “siguiente”:

• Introducimos la nueva contraseña para el administrador local, al eliminar el rol de controlador de dominio, la cuenta de usuario de administrador pasará a formar parte de los usuarios locales de la máquina, clic sobre “siguiente”:

• Revisamos y hacemos clic sobre “Disminuir nivel”, al finalizar la operación se reiniciará el servidor:

• Como podemos ver comienza el proceso de degradación de nuestro controlador de dominio:

• El sistema nos va a indicar que ha disminuido el nivel del controlador de dominio, y se va a reiniciar automáticamente.
• Una vez que el equipo ha reiniciado verificamos que este servidor ya no es un controlador de dominio, en el Administrador del servidor nos vuelve a indicar con una advertencia “Promover este servidor a controlador de dominio”:

• Sobre la consola de Usuarios y equipos de Active Directory del Controlador de dominio principal, podemos ver como el Controlador de dominio secundario ha pasado a formar parte del dominio como un equipo más de éste:

• Para desinstalar los binarios de los Servicios de dominio de Active Directory, lo haremos a través del Administrador del Servidor > Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Desmarcamos los checks, Servicios de dominio de Active Directory y Servidor DNS:

• Para los Servicios de dominio de Active Directory nos pide quitar las siguientes características:

• Para el Servidor DNS nos pide quitar las siguientes características:

• Una vez desmarcados estos dos checks, damos clic a “siguiente”:

• Aquí no tocamos nada, clic sobre “siguiente”:

• Nos muestra un resumen de las opciones configuradas para eliminar, le indicamos que reinicie en caso necesario y procedemos a quitar:

• Comienza con la eliminación:

• Tras el reinicio podemos ver que la eliminación ha sido correcta:

• Todo se ha eliminado correctamente, en la bandera de las advertencias, ya NO nos avisa de la promoción de este servidor a Controlador de dominio, ya que todos los binarios han sido eliminados:

• El único Controlador de dominio de nuestra infraestructura sería el servidor con MS Windows Server 2022:

• Para terminar ya sólo nos quedaría elevar los Niveles Funcionales a nivel de dominio y de bosque.
• Empezaremos elevando el Nivel Funcional del bosque, para ello, nos abrimos la herramienta Dominios y Confianzas de Active Directory:

• Como podemos observar, el Nivel Funcional del bosque se encuentra en Windows Server 2016, ya que Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• Ahora vamos a elevar el Nivel Funcional del dominio, para ello, nos abrimos la herramienta Usuarios y equipos de Active Directory:

• Automáticamente al elevar el Nivel Funcional del bosque se eleva también el del dominio, pero como ya comentamos antes, Microsoft no ha sacado niveles funcionales nuevos desde Windows Server 2016:

• Con la herramienta Centro de Administración de Active Directory tenemos opción a Elevar los Niveles Funcionales a nivel de bosque y de dominio:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como activar el servicio SNMP (Protocolo Simple de Administración de Red) en Windows 10-11 y Windows Server 2019-2022, el protocolo SNMP se utiliza para intercambiar información entre una solución de administración de red y cualquier dispositivo habilitado para SNMP, en mi caso, lo utilizo para comunicar los equipos Windows y Linux con un Centreon y poder monitorizar estos sistemas.

• Empezaremos viendo, como activar el servicio SNMP en Windows 10 y 11, para ello, nos abrimos un PowerShell con permisos de administrador, y ejecutamos este comando, Get-WindowsCapability -Online -Name «SNMP*» que como podemos ver sobre el State, el servicio no se encuentra presente:

• Para activar el servicio SNMP, introducimos el siguiente comando para descargarlo e instalarlo, Add-WindowsCapability -Online -Name «SNMP.Client~~~~0.0.1.0» como vemos aquí, comienza el proceso:

• Una vez que ha terminado el proceso, podemos ver que ha finalizado correctamente y que no necesita reinicio:

• Si volvemos a introducir el comando Get-WindowsCapability -Online -Name «SNMP*» podemos ver sobre el State, que el servicio ya se encuentra instalado:

• Una vez instalado, ya podemos acceder a nuestra consola de servicios y configurar el SNMP de nuestros equipos Windows para que se comuniquen con nuestro Centreon:

• Ahora vamos a ver como activar el servicio SNMP en Windows Server 2019 y 2022, para ello, nos vamos al Administrador del servidor > Administrar > Agregrar roles y características:

• Se nos abre el asistente típico, para agregar roles y características, vamos dando clic en Siguiente:

• Sobre Roles de servidor, no marcamos nada:

• Sobre Características, marcamos el check Servicio SNMP y Siguiente:

• Sobre Confirmación, damos clic a Instalar:

• Una vez instalado, ya podemos acceder a nuestra consola de servicios y configurar el SNMP de nuestros servidores Windows para que se comuniquen con nuestro Centreon:

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 averiguar el Service Tag de un servidor Dell con Windows Server 2019 a través de la consola de comandos, muchas veces, nos puede resultar útil, si por ejemplo, no está configurado o no tenemos acceso al iDRAC.

• Nos abrimos un símbolo de sistema con permisos de administrador:

• Ejecutamos el siguiente comando WMIC BIOS Get SerialNumber:

• Y cómo podemos ver ya tenemos el Service Tag del servidor:

• Este proceso también sería válido para mostrar el serial number de:
• HP ILO
• iRMC Fujitsu Primergy
• IPMI Supermicro

Saludos y espero que os resulte de ayuda