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

La entrada Deshabilitar Símbolo del sistema por GPO se publicó primero en RAGASYS SISTEMAS.

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

La entrada Deshabilitar PowerShell por GPO se publicó primero en RAGASYS SISTEMAS.

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

La entrada Conmutación por error en réplicas de máquinas virtuales desde Hyper-V a Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Réplicas de máquinas virtuales desde Hyper-V a Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Mover máquinas virtuales de Hyper-V se publicó primero en RAGASYS SISTEMAS.

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

La entrada Actualizar versión de configuración en máquinas virtuales de Hyper-V se publicó primero en RAGASYS SISTEMAS.

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

La entrada Configuración interface de red Windows a través de cmd se publicó primero en RAGASYS SISTEMAS.

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

La entrada Cambiar la zona horaria con PowerShell se publicó primero en RAGASYS SISTEMAS.

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

La entrada Carpeta SYSVOL no replica entre los controladores de dominio se publicó primero en RAGASYS SISTEMAS.

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

La entrada Hyper-V Windows Server 2022 – Error al crear Virtual Switch con NICs en Teaming se publicó primero en RAGASYS SISTEMAS.

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

La entrada Transferir roles FSMO entre Controladores de dominio con PowerShell se publicó primero en RAGASYS SISTEMAS.

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

La entrada Troubleshooting NTP – Error servicio w32time Windows Server se publicó primero en RAGASYS SISTEMAS.

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

La entrada Averiguar el Service Tag de servidores Dell en Windows Server 2019 con CMD se publicó primero en RAGASYS SISTEMAS.

Desde el blog Ragasys Sistemas tenemos el placer de anunciaros que Altaro – Software de backup va a realizar un interesante Webinar sobre «Windows Server Storage»

Optimizar la configuración del almacenamiento es una forma muy eficaz de aumentar la eficiencia y la fiabilidad del lugar de trabajo, y lo mejor de todo es que no tiene que pagar nada, ya que todas las herramientas que necesita ya están integradas en Windows Server.

El almacenamiento tiende a ser una de esas cosas de «configurar y olvidarse» que los administradores a menudo no se molestan en cambiar una vez configurado. Sin embargo, en este próximo webinar de Altaro/Hornetsecurity el 11 de agosto, aprenderá a utilizar las tecnologías de almacenamiento rápidas y fiables que residen en la pila moderna de Windows Server.

Presentado por los MVP de Microsoft Andy Syrewicze y Dider Van Hoye, este evento online gratuito le explicará lo que debe hacer para modernizar su infraestructura de almacenamiento, incluyendo las innovaciones de almacenamiento con Storage Spaces Direct y Azure Stack HCI, ReFS, PMem, QUIC y SMB, y mucho más.

Como siempre ocurre con los webinars de Altaro/Hornetsecurity, este evento se presentará en directo dos veces en el mismo día (11 de agosto de 2021) para que el mayor número posible de personas tenga la oportunidad de asistir en directo y hacer sus preguntas a los chicos en directo.

Windows Server storage technologies han recorrido un largo camino desde los días de Windows Server 2008 R2 y SMBv1/v2 – ya no es el servidor de archivos de su abuelo. Es hora de subir de nivel y liberar un potencial que no sabías que existía.

Más información y reserva tu plaza

Post sponsorizado por Altaro Backup

La entrada Altaro Webinar – Windows Server Storage se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver una buena práctica en nuestro Active Directory referente a la Group Policy Object (GPO).

• Cuando desplegamos los roles de Servicios de dominio de Active Directory en un Windows Server, por defecto las GPO “Default Domain Policy” y “Default Domain Controllers Policy”, ya están creadas y vinculadas a las siguientes ubicaciones:

• Como buena práctica, es aconsejable, no editar estas dos GPOs, ya que vienen con unas configuraciones por defecto, para que nuestro Active Directory funcione correctamente, todas las configuraciones las llevaremos a cabo, creándonos nuevas GPOs y vinculándolas sobre la OUs correspondientes.
• También otra buena práctica, y a ésta es a la que vamos a hacer referencia en este artículo, es que vamos a intentar evitar vincular sobre la raíz de nuestro dominio las nuevas GPOs que nos iremos creando a lo largo del tiempo, ¿y por qué hacemos esto?, pues la explicación es básica, si nos equivocamos diseñando una GPO con configuraciones de sistemas críticas y la vinculamos sobre la raíz del dominio, en muchas ocasiones la vuelta atrás no va a ser posible y la podemos liar bien gorda sobre la infraestructura, aquí muestro un ejemplo de lo que NO debemos de hacer:

• ¿Qué hacemos entonces?, en mi caso, lo que siempre hago, es crearme una Unidad Organizativa (OU) con el nombre de la empresa, podemos decir, que esta es la OU principal y dentro de ella voy anidando otras OUs:

• Ahora, todas las nuevas GPOs que nos vayamos creando a lo largo del tiempo, las iremos vinculando sobre las Unidades Organizativas que nos interesen, y no sobre la raíz del dominio:

Saludos y espero que os resulte de ayuda

La entrada Active Directory – Buena Práctica GPOs se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como iniciar la conmutación por error en las réplicas de nuestras máquinas virtuales en caso de fallo crítico en uno de nuestros hypervisores de Hyper-V.

• Tenemos dos hipervisores de Hyper-V con la replicación habilitada en ambos sentidos:

• Vamos a suponer que nos falla el Servidor Principal, por ejemplo, por un fallo de RAM o CPU y no podemos levantar la máquina virtual, entonces nos debemos de ir al Servidor de Réplicas y habilitar la Conmutación por error:

• Le indicamos el punto de restauración que vamos a utilizar y pulsamos sobre Conmutación por error:

• Una vez aplicada la conmutación por error, podemos ver que la máquina se inicia sin problemas, crea un punto de control que eliminará cuando invirtamos la replicación y el estado de la replicación nos muestra que ha completado la conmutación por error:

• Ahora se supone que estamos trabajando sobre el Servidor principal para solucionar nuestros problemas con el hardware y una vez solucionado iniciamos nuestro hypervisor y nos encontramos la máquina en el siguiente estado, la máquina apagada y con errores en el estado de la replicación:

• Lo que vamos a realizar ahora será irnos al Servidor de réplicas e invertir la replicación, lo que conseguimos con este proceso es que todos los cambios que se han realizado en la máquina virtual durante la conmutación por error, se le van a pasar a la máquina que se encuentra en el servidor principal y una vez terminado el proceso los hypervisores van a intercambiar sus roles, es decir, el que era servidor de réplicas se va a convertir en el servidor principal y el principal pasará ahora a ser el de réplicas:

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

• Seleccionamos el servidor que va a pasar a ser el servidor de réplicas:

• Especificamos los parámetros de conexión, en este caso, los dos servidores de réplicas autentican por Kerberos ya que estas dos máquinas pertenecen al mismo dominio de Active Directory, si estuviésemos en un grupo de trabajo utilizando certificados, entonces seleccionamos la opción basada en certificados:

• Configuramos la frecuencia de la replicación:

• Le indicamos los puntos de control que queremos mantener:

• Sobre el método de replicación inicial, seleccionamos la opción que Use una máquina virtual existente en el servidor de réplicas como copia inicial:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, comienza a enviar la réplica inicial y los servidores han intercambiado los roles:

• Una vez finalizada la replicación inicial, podemos ver que todo está correcto:

• Ahora si queremos dejar todo como estaba al principio, es decir, el servidor Hyperv03 como principal y el servidor Hyperv04 como réplicas, lo primero que tenemos que hacer es Apagar la máquina virtual en el servidor principal, en este caso, HyperV04:

• Y volvemos a repetir todo el proceso ya explicado de conmutación por error:

• Una vez finalizado, podemos ver que ya está todo como lo teníamos al principio:

Saludos y espero que os sea de ayuda

La entrada Hyper-V Réplicas – Conmutación por error se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como instalar y configurar Azure AD Connect, esta herramienta nos va a permitir sincronizar nuestros usuarios del Active Directory en un entorno de dominio Windows Server con Azure Active Directory.

Nos ofrece las siguientes características:

• Sincronización de hash de contraseñas, un método de inicio de sesión que sincroniza el hash de la contraseña de un usuario de AD local con Azure AD.
• Autenticación de paso a través, un método de inicio de sesión que permite a los usuarios usar la misma contraseña de forma local y en la nube, pero que no requiere la infraestructura adicional de un entorno federado.
• Integración de federación, la federación es una parte opcional de Azure AD Connect y puede utilizarse para configurar un entorno híbrido mediante una infraestructura local de AD FS. También proporciona funcionalidades de administración de AD FS, como la renovación de certificados e implementaciones de servidor de AD FS adicionales.
• Sincronización, responsable de la creación de usuarios, grupos y otros objetos. También de asegurar que la información de identidad de los usuarios y los grupos de su entorno local coincide con la de la nube. Esta sincronización también incluye los códigos hash de contraseña.
• Seguimiento de estado, Azure AD Connect Health puede proporcionar una sólida supervisión y una ubicación central en Azure Portal donde se puede ver esta actividad.

Fuente: Microsoft Docs

• Como buena práctica, vamos a instalar Azure AD Connect en un servidor miembro de nuestro dominio y con conexión a Internet, y NO en un controlador de dominio, lo podemos hacer, pero lo recomendable es NO hacerlo, lo instalaremos en este servidor entonces, este servidor es el que utilizamos como Windows Admin Center:

• Ahora nos vamos a nuestro portal de Azure, y accedemos a Azure Active Directory > Nombre de dominio personalizado > Nuestro domino empresarial:

• Una vez que hemos accedido a nuestro dominio, vamos a Descargar Azure AD Connect:

• Como podemos ver ya lo tenemos descargado:

• Procedemos entonces a su instalación, aceptamos el EULA y Continuar:

• Aquí nos muestra las configuraciones que se van a realizar con Azure AD Connect y las sincronizaciones entre nuestro Active Directory local y nuestro Azure Active Directory, seleccionamos Usar la configuración rápida:

• Para conectar con Azure AD, introducimos las credenciales de una cuenta con el rol de Administrador global:

• Aquí podemos ver que este usuario tiene el rol de Administrador global en Azure:

• Para conectar con nuestro Active Directory local introducimos las credenciales de un Administrador de empresa de Active Directory Domain Services:

• Como podemos ver, este usuario pertenece al grupo Administradores de empresa de nuestro Active Directory local:

• Para el Inicio de sesión de Azure, podemos ver que nuestro dominio empresarial está comprobado, marcamos el check Continuar sin relacionar todos los sufijos UPN con los dominios verificados, clic en Siguiente:

• Sobre Configurar nos muestra los pasos y los procesos que se van a realizar durante la instalación, desmarcamos el check Inicie el proceso de sincronización cuando se complete la configuración, ya que la sincronización la vamos a configurar más adelante, clic sobre Instalar:

• Comienza con la instalación:

• Como podemos ver se ha instalado correctamente:

• Una vez instalado, abrimos la aplicación Azure AD Connect, para configurar las opciones que nos interesen:

• Damos clic a Configurar:

• Vamos a Personalizar las opciones de sincronización, ya que ahora mismo, estamos sincronizando nuestro Active Directory local al completo, clic en Siguiente:

• Volvemos a Conectar con Azure AD, para ello, introducimos las credenciales de una cuenta con el rol de Administrador global, clic en Siguiente:

• Sobre Conectar directorios podemos ver que ya tenemos conectado nuestro Active Directory local, clic en Siguiente:

• Sobre Filtrado de dominios y unidades organizativas, vamos a sincronizar solamente las unidades organizativas que nos interesen, en este caso, hemos elegido la OU AzureAD, clic en Siguiente:

• Sobre las Características opcionales vamos a dejar todo lo que viene por defecto y vamos a marcar el check de Reescritura de contraseñas para que los cambios de contraseñas que se originen en Azure AD se reescriban en el Active Directory local, clic en siguiente:

• Comienza el proceso de configuración:

• En Configurar, nos muestra las opciones que van a implementar, marcamos el check Inicie el proceso de sincronización cuando se complete la configuración, clic sobre Configurar:

• Como podemos ver todo se ha configurado correctamente, clic en Salir:

• Ahora si accedemos a nuestro portal de Azure, sobre Azure Active Directory > Usuarios, podemos ver que los usuarios de la Unidad Organizativa que hemos configurado para sincronizar con AzureAD ya los tenemos en el portal:

• Si nos fijamos en la columna Origen, podemos ver el origen de los usuarios y los que sincronizan con nuestro Active Directory local los marca como Windows Server AD:

• Ahora para comprobar la sincronización, sobre el servidor dónde hemos instalado Azure AD Connect, nos abrimos la herramienta Synchronization Service:

• Esta herramienta nos muestra todas las tareas de sincronización que se han realizado entre Windows Server AD y Azure AD, incluyendo toda la información, como las cuentas que se han creado, eliminado, etc…:

• Con esta herramienta también vamos a poder forzar la sincronización entre Windows Server AD y Azure AD, para ello, sobre Connectors seleccionamos el conector que queremos sincronizar y sobre Run o Ctrl+F5 lo ejecutamos:

• Con este comando de PowerShell también vamos a poder sincronizar nuestro Windows Server AD con Azure AD, Start-ADSyncSyncCycle -PolicyType Delta
• Vamos a ver un ejemplo, hemos creado este nuevo usuario en Windows Server AD:

• Ahora nos vamos a nuestro servidor Azure AD Connect, nos abrimos un PowerShell con permisos de administrador y ejecutamos el comando para forzar la sincronización, que como vemos ha sido correcto:

• Si nos vamos a la herramienta Synchronization Service Manager, podemos ver, como este nuevo usuario se ha sincronizado correctamente con nuestro Azure AD:

• Aquí vemos ya el nuevo usuario en Azure AD:

Saludos y espero que os sea de ayuda

La entrada Microsoft Azure – Instalación y configuración de Azure AD Connect se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo cambiar el sufijo UPN (User Principal Name) a nuestros usuarios del Active Directory local para sincronizarlos con Azure Active Directory, vamos a ver dos formas de hacerlo, una de ellas manual sobre la misma configuración de la cuenta de usuario y otra con un script de PowerShell que nos va a automatizar esta tarea.

• Vamos a ver primero la primera opción que es la manual, directamente sobre la configuración de la cuenta de usuario, para ello, desde la consola de Usuarios y equipos de Active Directory nos abrimos las propiedades del usuario que queremos modificar:

• Sobre la pestaña Cuenta cambiamos el sufijo UPN principal del usuario y seleccionamos el que hemos configurado en nuestro Azure Active Directory, guardamos los cambios:

• Este usuario ya estaría listo para ser sincronizado con nuestro Azure Active Directory a través de Azure AD Connect, para los demás usuarios que queramos sincronizar debemos de realizar la misma operación.

• Nos creamos el grupo de seguridad global AzureAD y añadimos como miembros a todos los usuarios a los que le hemos cambiado el sufijo UPN por el configurado en Azure, ya que Azure AD Connect lo vamos a configurar para sincronizarlo con una Unidad Organizativa y además que sólo sincronice los usuarios que pertenezcan a este grupo:

• Ahora imaginemos que tenemos que cambiarle el sufijo UPN a miles de usuarios, esto sería una tarea bastante tediosa, aburrida y que nos llevaría bastante tiempo, pues para eso tenemos PowerShell, para automatizar este tipo de tareas.

• En nuestro caso, vamos a cambiar el sufijo UPN, de todos los usuarios que se encuentran en la Unidad Organizativa AzureAD, que como podemos ver tiene el UPN local:

• Para ello, vamos a utilizar este script realizado por Jair Gómez, que nos explica cómo utilizarlo en su curso, Implementación de soluciones en Microsoft Azure el cuál recomiendo que hagan si están empezando con la plataforma Cloud de Microsoft, desde aquí pueden descargarlo:

• Ejecutamos el script:

• Y cómo podemos ver, el sufijo UPN de todos los usuarios de esta Unidad Organizativa ha cambiado del local al que hemos configurado en Azure Active Directory:

Saludos y espero que os resulte de ayuda

La entrada Microsoft Azure – Azure Active Directory – Cambiar sufijo UPN a Usuarios de una Unidad Organizativa de Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar un dominio personalizado (utilizaremos nuestro dominio empresarial), en Azure Active Directory, y una vez que tengamos este dominio operativo, vamos a configurar el sufijo UPN (User Principal Name) en nuestro Active Directory de Windows Server, esto lo vamos a realizar ya que en un post posterior vamos a sincronizar nuestro Active Directory local con AzureAD, utilizando la herramienta Azure AD Connect.

• Para configurar nuestro dominio personalizado, desde Azure Active Directory, accedemos a Nombres de domino personalizados:

• Como podemos ver, nos muestra el dominio inicial que configuramos cuando desplegamos un nuevo inquilino (nombredenuestrempresa.onmicrosoft.com), para añadir un dominio personalizado, nos vamos a Agregar un dominio personalizado:

• Introducimos el nombre de nuestro dominio empresarial y que tenemos comprado a un proveedor de dominios en Internet, y agregamos el dominio:

• Una vez agregado nuestro dominio, nos va a mostrar, el tipo de registro TXT que tenemos que crear en nuestro DNS público (el que hemos comprado al proveedor de dominios en Internet), una vez que lo hemos registrado, damos a clic a Comprobar, así verifica Azure que este dominio pertenece a nosotros:

• Aquí vemos cómo se añade el registro TXT en nuestro DNS público:

• Una vez comprobado, podemos ver que ya tenemos nuestro dominio empresarial personalizado configurado y listo para usarlo:

• Ahora sobre Información general > Cambiar inquilino vamos a convertirlo en el inquilino predeterminado:

• Vamos a realizar una prueba creando un usuario nuevo, así vamos a ver como ya nos asigna el sufijo DNS de nuestro dominio personalizado, para ello, accedemos a Usuarios > Nuevo usuario:

• Configuramos los datos de la identidad y la contraseña, creamos el usuario:

• Aquí vemos el usuario creado con nuestro dominio personalizado:

• Con esto ya tendríamos nuestro dominio personalizado, configurado en Azure Active Directory, ahora este dominio lo vamos a agregar como sufijo UPN (User Principal Name) en nuestro Active Directory local (el de Windows Server de toda la vida), para ello, vamos a acceder a cualquiera de nuestros controladores de dominio y nos abrimos la consola de Dominios y confianzas de Active Directory:

• Sobre Dominios y confianzas de Active Directory nos abrimos las Propiedades:

• Y agregamos el sufijo UPN alternativo, que en este caso va a ser el dominio personalizado que hemos configurado en Azure Active Directory:

• Una vez agregado, guardamos los cambios:

• Ahora si nos abrimos la consola de Usuarios y equipos de Active Directory y accedemos a las propiedades de cualquiera de nuestros usuarios, podemos ver que podemos configurar el sufijo UPN local y el sufijo UPN alternativo para utilizarlo con Azure Active Directory, para que las cuentas de los usuarios se sincronicen con Azure Active Directory a través de Azure AD Connect (que lo vamos a ver más adelante) debemos de tener configurado como UPN principal en la cuenta del usuario, el dominio personalizado de Azure:

Saludos y espero que os sea de ayuda

La entrada Microsoft Azure – Azure Active Directory – Nombre de dominio personalizado en Azure Active Directory y sufijo UPN (User Principal Name) en Active Directory Windows Server se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver las Extensiones de Windows Admin Center.

Windows Admin Center se ha creado como una plataforma extensible en que cada herramienta y tipo de conexión es una extensión que se puede instalar, desinstalar y actualizar de forma individual. Puedes buscar nuevas extensiones publicadas por Microsoft y otros desarrolladores, así como instalarlas y actualizarlas de forma individual sin tener que actualizar toda la instalación de Windows Admin Center. También puedes configurar un recurso compartido de archivos o fuente de NuGet independiente y distribuir extensiones para usarlas internamente en tu organización.

Fuente: Microsoft Docs

• Para empezar, accedemos a nuestra plataforma de Windows Admin Center, y nos vamos a Configuración:

• Nos situamos sobre Extensiones y la primera opción que tenemos son las Extensiones disponibles, desde aquí nos podemos instalar las extensiones que nos interesen, así vamos añadiendo funcionalidades para los accesos a nuestros servidores o equipos:

• Para instalar Extensiones, seleccionamos las que nos interesen, por ejemplo, Containers, y clicamos sobre Instalar:

• También podemos indicarle que las Extensiones se actualicen automáticamente:

• Una vez que tenemos instaladas las Extensiones que nos interesen, accedemos a las Extensiones instaladas, y podemos ver todas las funcionalidades de acceso vía web que hemos incorporado a nuestros servidores, por ejemplo, la Extensión de Active Dirtectory, si accedemos a nuestro Controlador de dominio, podemos ver la consola del Active Directory y administrar los usuarios, para la Extensión de DNS podemos administrar nuestro servidor DNS, para la Extensión DHCP lo mismo y así para todas las que hemos instalado:

• Vamos a acceder, por ejemplo, a uno de nuestros Controladores de domino y así lo veremos más claro:

• Aquí vemos la Extensión de Active Directory, desde dónde vamos a poder administrar las cuentas de usuarios:

• Aquí vemos la Extensión del DNS, desde la que vamos a poder administrar nuestro servicio del DNS:

• Aquí vemos la Extensión del DHCP, desde la que vamos a poder administrar nuestro servicio del DHCP:

• Y así lo tendríamos para las distintas extensiones que hemos instalado en nuestro Windows Admin Center.
• Para terminar y volviendo a la configuración de Extensiones, en la opción de Fuentes podemos agregar distintas fuentes para la descarga de Extensiones y poder ir añadiendo funcionalidades a nuestro Windows Admin Center, así cuando administremos los servidores y equipos de nuestra infraestructura a través de este centro de administración, tendremos estas funcionalidades disponibles:

Saludos y espero que os resulte de ayuda

La entrada Windows Admin Center – Extensiones se publicó primero en RAGASYS SISTEMAS.