En este post vamos a ver como publicar aplicaciones a través de GPO, para que los usuarios de nuestro dominio se puedan instalar las aplicaciones que tengamos aprobadas.

• Lo primero que vamos a realizar es copiar en un recurso compartido de nuestro servidor de ficheros con permisos de lectura para todos los usuarios del dominio, las aplicaciones con formato msi que hemos aprobado para publicarlas y que los usuarios se van a poder instalar:

• Ahora desde la consola de Administración de directivas de grupo en cualquiera de nuestros Controladores de dominio, nos vamos a crear una nueva GPO:

• Le indicamos un nombre y aceptamos:

• Como podemos ver ya la tenemos creada:

• Ahora pasamos a editarla:

• Realizaremos las configuraciones a nivel de usuarios, para ello, accedemos a Configuración de usuario > Directivas > Configuración de software > Instalación de software damos un clic derecho de ratón sobre la ventana de Instalación de software y Nuevo > Paquete:

• Accedemos a la ruta del recurso compartido del servidor de ficheros dónde tenemos las aplicaciones, las seleccionamos y abrimos:

• Como lo que queremos es publicar las aplicaciones para que los usuarios se las instalen cuando quieran, seleccionamos Publicada y aceptamos, lo tenemos que hacer dos veces ya que hemos seleccionado dos aplicaciones:

• Como podemos ver ya tenemos nuestra GPO preparada para publicar las aplicaciones:

• Ahora la vinculamos sobre la Unidad Organizativa que nos interese, en este caso, la hemos vinculado sobre la OU RAGASYS:

• Aquí la tenemos ya vinculada:

• Ahora sobre cualquier equipo que tengamos unido a nuestro dominio y con una sesión iniciada con un usuario del dominio, con el comando gpupdate /force vamos a forzar a que se actualicen las directivas de grupo:

• Con el comando gpresult /r vemos si se están aplicando correctamente:

• Si hacemos un rsop podemos ver que la GPO está funcionando correctamente:

• Para terminar, vamos a mostrar desde dónde el usuario puede ver las aplicaciones que tenemos publicadas para poder instalarlas, para ello, accedemos al Panel de control > Programas y características > Instalar un programa desde la red:

Saludos y espero que os resulte de ayuda

La entrada Publicar aplicaciones a través de GPO se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cuál es el serial key de nuestro Windows accediendo al registro del sistema.

• Sobre inicio > ejecutar tecleamos regedit:

• Se nos abre el registro de Windows, y nos situamos sobre la ruta Equipo\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform, y sobre la clave BackupProductKeyDefault tenemos el License key de nuestro sistema:

Saludos y espero que os resulte de ayuda

La entrada License Key Windows regedit se publicó primero en RAGASYS SISTEMAS.

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

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

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

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

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

Saludos y espero que os sea de ayuda

La entrada Troubleshooting – Active Directory – Warning ID Evento 2213 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo crear y configurar una GPO para habilitar un disclaimer en los equipos de nuestro Active Directory.

• Desde el Administrador del servidor nos abrimos la “Administración de directivas de grupo”:

• Nos crearemos una GPO llamada “Disclaimer” y la vincularemos sobre las OUs RAGASYS y Domain Controllers, ésta GPO nos va a permitir configurar un disclaimer que nos aparecerá cuando los equipos de nuestro dominio hagan logon en el sistema:

• Ahora cuando uno de nuestros equipos inicie sesión en el domino aparecerá este mensaje:

• Con un “gpresult /r” podemos ver que la GPO se está aplicando correctamente:

Saludos y espero que os resulte de ayuda

La entrada GPO para habilitar Disclaimer en Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como restablecer a las configuraciones por defecto las GPOs Default Domain Policy y Default Domain Controllers Policy, como buena práctica, estas dos GPOs que traen configuraciones por defecto una vez que hemos desplegado nuestro Active Directory, siempre es bueno dejarlas tal cuál vienen, y poco a poco ir creando nuestras propias políticas y dándole el orden de ejecución que nos interese y que le vengan mejor a nuestra infraestructura.

• Para restablecer estas GPOs, nos abriremos un PowerShell con permisos de Administrador:

• Si ejecutamos este comando dcgpofix /ignoreschema /target:Domain vamos a restablecer por defecto la GPO Default Domain Policy:

• Como podemos ver se ha restablecido correctamente:

• Si ejecutamos este comando dcgpofix /ignoreschema /target:DC vamos a restablecer por defecto la GPO Default Domain Controllers Policy:

• Como podemos ver se ha restablecido correctamente:

• Si ejecutamos este comando dcgpofix /ignoreschema /target:BOTH vamos a restablecer por defecto las GPOs Default Domain Policy y Default Domain Controllers Policy:

• Como podemos ver las dos GPOs se han restablecido correctamente:

Saludos y espero que os sea de ayuda

La entrada Restablecer a las configuraciones por defecto las GPOs Default Domain Policy y Default Domain Controller Policy se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar filtros WMI (Windows Management Instrumentation) para distinguir entre las distintas versiones y arquitecturas de sistemas operativos Windows y poder aplicar estos filtros a nuestras GPOs.

• Para ello, desde la consola “Administración de directivas de grupo” de nuestro Active Directory, nos iremos configurando los distintos filtros WMI según versión y arquitectura de los sistemas operativos Windows:

• Empezaremos configurando los filtros WMI para Windows 7, tanto para arquitecturas de 32 bits como de 64 bits, introducimos la siguiente consulta en el filtro, select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»1″:

• Windows 7 32 bits, select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»1″ AND NOT OSArchitecture = «64-bit»:

• Windows 7 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»1″ AND OSArchitecture = «64-bit»:

• Windows 8, tanto para arquitecturas de 32 bits como de 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.2%» AND ProductType=»1″:

• Windows 8 32 bits, select * from Win32_OperatingSystem WHERE Version like «6.2%» AND ProductType=»1″ AND NOT OSArchitecture = «64-bit»:

• Windows 8 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.2%» AND ProductType=»1″ AND OSArchitecture = «64-bit»:

• Windows 8.1, tanto para arquitecturas de 32 bits como de 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»1″:

• Windows 8.1 32 bits, select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»1″ AND NOT OSArchitecture = «64-bit»:

• Windows 8.1 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»1″ AND OSArchitecture = «64-bit»:

• Windows 10 1709, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1709 AND ProductType =»1″:

• Windows 10 1803, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1803 AND ProductType =»1″:

• Windows 10 1809, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1809 AND ProductType =»1″:

• Windows Server 2008 – DC, tanto para arquitecturas de 32 bits como de 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»2″:

• Windows Server 2008 – DC 32 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»2″ AND NOT OSArchitecture = «64-bit»:

• Windows Server 2008 – DC 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»2″ AND OSArchitecture = «64-bit»:

• Windows Server 2008 – NODC, tanto para arquitecturas de 32 bits como de 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»3″:

• Windows Server 2008 – NODC 32 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»3″ AND NOT OSArchitecture = «64-bit»:

• Windows Server 2008 – NODC 64 bits, select * from Win32_OperatingSystem WHERE Version like «6.0%» AND ProductType=»3″ AND OSArchitecture = «64-bit»:

• Windows Server 2008 R2 – DC, select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»2″:

• Windows Server 2008 R2 – NODC, select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»3″:

• Windows Server 2012 – DC, select * from Win32_OperatingSystem WHERE Version like «6.2%» AND ProductType=»2″:

• Windows Server 2012 – NODC, select * from Win32_OperatingSystem WHERE Version like «6.2%» AND ProductType=»3″:

• Windows Server 2012 R2 – DC, select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»2″:

• Windows Server 2012 R2 – NODC, select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»3″:

• Windows Server 2016 1607 – DC, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1607 AND ProductType =»2″:

• Windows Server 2016 1607 – NODC, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1607 AND ProductType =»3″:

• Windows Server 2019 1809 – DC, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1809 AND ProductType =»2″:

• Windows Server 2019 1809 – NODC, select BuildNumber, ProductType from Win32_OperatingSystem where BuildNumber <= 1809 AND ProductType =»3″:

• Windows 10 todas las ediciones, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 1:

• Windows 10 32 bits, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 1 AND OSArchitecture = «32-bit»:

• Windows 10 64 bits, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 1 AND OSArchitecture = «64-bit»:

• Windows 11, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 1 AND BuildNumber >= «22000»:

• Windows Server 2019 todas las ediciones – Servidores, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 3 AND BuildNumber = «17763»:

• Windows Server 2019 todas las ediciones – Controladores de dominio, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 2 AND BuildNumber = «17763»:

• Windows Server 2022 todas las ediciones – Servidores, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 3 AND BuildNumber = «20348»:

• Windows Server 2022 todas las ediciones – Controladores de dominio, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 2 AND BuildNumber = «20348»:

• Windows Server 2025 todas las ediciones – Servidores, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 3 AND BuildNumber = «26100»:

• Windows Server 2025 todas las ediciones – Controladores de dominio, SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «10.%» AND ProductType = 2 AND BuildNumber = «26100»:

• Como podemos ver ya tenemos nuestros filtros WMI configurados:

• Ahora, ¿Cómo aplicamos los filtros WMI?, lo vemos mejor con un ejemplo, supongamos que tenemos la siguiente GPO llamada “Instalación Antivirus”, y queremos desplegar el software antivirus en los equipos con Windows 10 versión 1809, tanto para arquitecturas de 32 bits como de 64 bits, para ello, simplemente le aplicamos el filtro WMI desde el ámbito de la GPO:

• ProductType 1 = Desktop OS
• ProductType 2 = SERVER OS – Domain Controllers
• ProductType 3 = SERVER OS – NO Domain Controllers

Fuente: Curso Instalación y Configuración Windows Sever 2016 impartido por Jair Gómez

La entrada Filtros WMI en GPOs para versiones y arquitecturas de sistemas operativos Windows se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como se aplican los filtrados de seguridad en GPOs de nuestro Active Directory, con este filtrado conseguiremos aplicar las GPOs a los grupos o usuarios que nos interesen.

• Para ello, desde el Administrador del servidor nos abrimos la “Administración de directivas de grupo”:

• Nos crearemos una GPO llamada “Calculadora” y la vincularemos sobre la OU “RAGASYS”, ésta GPO nos va a permitir iniciar la calculadora una vez que el usuario ha iniciado sesión:

• Ahora sobre la GPO “Calculadora” nos iremos a las opciones de “Ámbito > Filtrado de seguridad” y quitaremos el grupo “Usuarios autentificados” que nos lo agrega la GPO por defecto, los usuarios autentificados son los usuarios que han iniciado sesión en el dominio:

• Ahora para realizar el filtrado de seguridad correcto, tenemos que agregar el grupo o usuario y equipo o equipos a los que queremos aplicar la GPO, con las nuevas actualizaciones de Windows Server 2016 y Windows Server 2012 R2, es necesario agregar los equipos, con versiones anteriores, simplemente agregábamos el grupo o los usuarios, pero una vulnerabilidad corregida con las nuevas versiones, nos obliga a agregar los equipos, esta vulnerabilidad hacía que el usuario o los usuarios incluidos en el filtrado de seguridad de la GPO pudieran modificar esta política de grupo:

• Ahora vamos a probar con este usuario y equipo incluido en el filtrado de seguridad para ver si se aplica la GPO correctamente:

• Con un “gpresult /r” podemos ver que la GPO se está aplicando correctamente:

• Si no queremos un filtrado tan exhaustivo en nuestras GPOs, con usuario o grupo y equipo, podemos filtrar por usuario o grupo y añadir el grupo Equipos del dominio, así logramos tener un filtrado prácticamente solo por el grupo de seguridad, ya que el grupo Equipos del dominio engloba a todos los equipos de nuestro dominio de Active Directory:

• Otra forma más limpia de hacer esto mismo, funciona igual que lo anterior, es filtrar por usuario o grupo y añadir el grupo Equipos del dominio en Delegación asignándole únicamente permisos de lectura:

Saludos y espero que os resulte de ayuda

La entrada Filtrado de seguridad en GPOs de Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como crear y configurar GPOs para habilitar el Escritorio Remoto en los equipos de nuestro Active Directory.

• Lo primero que haremos será crearnos un grupo de seguridad global para el acceso por escritorio remoto, llamado “GRDSRAGASYS” e incluiremos los siguientes usuarios en este grupo:

• Ahora desde el Administrador del servidor nos abrimos la “Administración de directivas de grupo”:

• Nos crearemos una GPO llamada “Accesos RDS Equipos” y la vincularemos sobre la OU RAGASYS, ésta GPO nos va a permitir que los usuarios se conecten de forma remota a los equipos mediante los servicios de escritorio remoto:

• Ahora vamos a probar con uno de los usuarios incluidos en el grupo de seguridad “Grdsragasys” que tenemos acceso por escritorio remoto a uno de nuestros equipos del dominio:

• Con un “gpresult /r” podemos ver que la GPO se está aplicando correctamente:

• Ahora para el acceso por escritorio remoto a los servidores de nuestra infraestructura, nos hemos creado otra GPO con las siguientes configuraciones, por lo que sólo los Administradores del dominio tendrán acceso por escritorio remoto a los servidores, esta GPO la hemos vinculado a las OUs “Servidores” y “Domain Controllers”:

• Como podemos ver la GPO se está aplicando correctamente:

Saludos y espero que os sea de ayuda

La entrada GPO para habilitar Escritorio Remoto en Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como instalar Vembu ImageBackup Client en servidores físcos Windows de nuestro entorno a través del paquete msi, Recordemos la topología configurada:

• Accedemos a la consola web con las credenciales que configuramos anteriormente:

• Y lo primero que vamos a realizar será descargarnos Vembu ImageBackup Client para Windows, desde el icono de descargas de nuestra suite:

• Se nos abrirá el siguiente enlace y sobre la pestaña Vembu Image Backup client nos descargamos el paquete msi para nuestro servidor físico Windows Server:

• Como podemos ver ya lo tenemos descargado:

• Una vez descargado lo instalaremos sobre los servidores físicos Windows de nuestra infraestructura que queramos proteger, en este ejemplo, lo vamos a instalar sobre la misma máquina dónde tenemos instalado Vembu BDR Suite, ya que se trata de un servidor físico con sistema operativo MS Windows Server 2016 Standard, se nos abrirá el siguiente asistente, clic en “Next” para continuar:

• Comienza con la instalación de los prerrequisitos:

• Clic en “Next” para continuar:

• Aceptamos los términos de licencia:

• Aquí es aconsejable introducir la dirección de correo electrónico con la que nos hemos registrado en el portal de Vembu:

• Escogemos el tipo de instalación personalizada:

• El tipo de instalación será como un servicio de Windows, ya que los trabajos de backups y restore los vamos a realizar desde la consola central de Vembu BDR Suite:

• El servicio estará configurado con una cuenta de sistema local:

• Le indicamos la ruta de instalación:

• Introducimos usuario y password para el acceso a través de la consola web:

• Marcamos los checks para que nos muestre los iconos de escritorio y de acceso rápido:

• Instalamos nuestro Vembu ImageBackup Client para Windows:

• Comienza la instalación:

• Finalizamos la instalación:

• Como podemos ver nos lo ha instalado como un servicio de Windows, el cuál lo debemos configurar con una cuenta de nuestro Active Directory con permisos de administrador, ya que este cliente lo vamos a administrar desde la consola central de Vembu BDR Suite:

• Debemos iniciar el servicio:

• Al servicio VembuBDR instalado en el servidor que tiene la consola central de Vembu BDR Suite también le vamos a configurar una cuenta de nuestro Active Directory con permisos de administrador:

• Debemos iniciar el servicio:

• Una vez instalado el cliente de Vembu ImageBackup, lo primero que vamos a realizar será agregar el servidor físico Windows de nuestra infraestructura, al cuál le queremos hacer el backup, a la suite Vembu BDR, para ello nos abrimos la consola web de Vembu ImageBackup Client:

• Introducimos las credenciales que hemos configurado anteriormente en la instalación:

• Introducimos la IP que tiene configurada el servidor dónde se encuentra Vembu BDR Suite, y clic sobre “Añadir”:

Post sponsorizado por Vembu Technologies

La entrada Instalación de Vembu ImageBackup Client desde el paquete msi en Servidores físicos Windows se publicó primero en RAGASYS SISTEMAS.

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

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

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

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

Saludos y espero que os sea de ayuda

La entrada Troubleshooting – Active Directory – Error 9061 ID Evento 4012 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar la página de inicio de Mozilla Firefox a través de GPO Central Store, para ello tenemos que tener configurado la administración de las directivas de grupo por almacén central, en este link podemos ver como se configura GPO Central Store.

• Para ello, lo primero que haremos será descargarnos la plantilla admx/adml para Mozilla Firefox, Policy_Template_Firefox_v1_4, una vez descargada, la descomprimimos:

• Ahora sobre el almacén central ubicado en C:\Windows\SYSVOL\sysvol\dominioAD\Policies\PolicyDefinitions copiamos la plantilla admx/adml:

• Ahora desde la consola “Administración de directivas de grupo” nos creamos una nueva GPO llamada “Config_Firefox”:

• Editamos la nueva GPO:

• Accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas (almacén central) > Mozilla > Firefox > Página de inicio” y configuramos las opciones “Página de inicio y URL de la página de inicio”:

• Con esto ya tendríamos configurado la página de inicio de Mozilla Firefox:

• Una vez que ya tenemos la GPO “Config_Firefox” preparada y configurada, la vinculamos sobre la raíz de nuestro dominio:

• Como podemos ver ya está vinculada sobre el dominio, y el orden de vínculo, la hemos ubicado en el tercer lugar:

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

• 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

La entrada GPO para configurar página de inicio en Mozilla Firefox – Método 2 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar GPO Central Store, esto nos va a permitir leer las plantillas administrativas desde el SYSVOL.

• Por defecto, nuestros controladores de dominio guardan las plantillas administrativas para las configuraciones de las políticas de grupo de forma local en la ubicación C:\Windows\PolicyDefinitions, por lo tanto, si actualizamos las plantillas administrativas en uno de nuestros controladores de domino, lo estaremos haciendo de forma local, y tendremos que hacerlo en todos los demás controladores de dominio, y además tendremos que aplicarle los permisos NTFS necesarios:

• Si nos abrimos la consola “Administración de directivas de grupo” y editamos cualquiera de nuestras GPOs, podemos ver si las plantillas administrativas se están leyendo de forma local o desde el almacén central, si nos aparece, “recuperadas del equipo local”, se estarán leyendo de forma local:

• Ahora vamos a ver como configurar GPO Central Store, dónde las plantillas administrativas se van a leer desde el SYSVOL, y van a ser replicadas a todos los controladores de dominio, tampoco vamos a aplicar ningún tipo de permiso NTFS, para habilitar GPO Central Store, simplemente tendremos que copiar la carpeta PolicyDefinitions ubicada en C:\Windows, a la carpeta de SYSVOL dónde residen las políticas de grupo del dominio Active Directory, C:\Windows\SYSVOL\sysvol\dominioAD\Policies:

• Ahora si nos abrimos la consola “Administración de directivas de grupo” y editamos cualquiera de nuestras GPOs, podemos ver si las plantillas administrativas se están leyendo de forma local o desde el almacén central, si nos aparece, “recuperadas del almacén central”, se estarán leyendo del GPO Central Store:

• Las ventajas de tener configurado GPO Central Store es que a la hora de actualizar las plantillas administrativas, o de introducir plantillas nuevas, bastará con realizarlo en uno de nuestros controladores de dominio, ya que al estar en el SYSVOL se replicará a los demás controladores, y con respecto a los permisos NTFS no debemos tocar ni aplicar nada.

Saludos y espero que os sea de ayuda

La entrada Configurar GPO Central Store se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar la página de inicio en Internet Explorer, 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 Internet Explorer, para ello, desde el Administrador del servidor nos abrimos “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 de usuario > Directivas > Plantillas administrativas > Componentes de Windows > Internet Explorer” y configuramos la opción “Deshabilitar el cambio de configuración de la página principal”:

• Introducimos la página de inicio sobre la configuración de la GPO:

• Con esto ya tendríamos configurado la página de inicio de Internet Explorer, ahora vamos a configurar la página de inicio de Google Chrome, para ello, lo primero que haremos será descargarnos la plantilla adm para Google Chrome, Policy_Template_GChrome, una vez descargada, la descomprimimos:

• Ahora sobre la GPO que creamos anteriormente “Conf_IE_Chrome_Firefox” accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas” y agregamos la plantilla adm para Google Chrome:

• Como podemos ver ya la tenemos agregada:

• Ahora vamos a configurar las páginas de inicio para Google Chrome, para ello, accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas > Plantillas administrativas clásicas (ADM) > Google > Google Chrome > Páginas de inicio” y configuramos las políticas “Acción al iniciar y URL que se deben abrir al inicio”:

• Para la primera política “Acción al iniciar” la habilitamos y configuramos que abra una lista de URLs:

• Para la segunda política “URL que se deben abrir al inicio” la habilitamos y configuramos la página de inicio o páginas de inicio que queremos en nuestro sistema:

• Como podemos ver ya tenemos estas dos opciones de política sobre Google Chrome habilitada:

• Ahora vamos a configurar la página de inicio para Google Chrome, para ello, accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas > Plantillas administrativas clásicas (ADM) > Google > Google Chrome > Página de inicio” y configuramos las políticas “Configurar la URL de la página principal y Utilizar página nueva pestaña como página principal”:

• Para la primera política “Configurar la URL de la página principal” la habilitamos y configuramos la URL:

• Para la segunda política “Utilizar página nueva pestaña como página principal” la deshabilitamos:

• Como podemos ver ya tenemos estas dos opciones de política sobre Google Chrome configuradas:

• Con esto ya tendríamos configurado la página de inicio de Google Chrome, ahora vamos a configurar la página de inicio de Mozilla Firefox, para ello, lo primero que haremos será descargarnos la plantilla adm para Mozilla Firefox, Policy_Template_Firefox, una vez descargada, la descomprimimos:

• Ahora sobre la GPO que creamos anteriormente “Conf_IE_Chrome_Firefox” accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas” y agregamos las plantillas adm para Mozilla Firefox:

• Como podemos ver ya las tenemos agregadas:

• Ahora vamos a configurar la página de inicio para Mozilla Firefox, para ello, accedemos a la ruta “Configuración del equipo > Directivas > Plantillas administrativas > Plantillas administrativas clásicas (ADM) > Mozilla Firefox > General” y configuramos la opción “Homepage”:

• La habilitamos y configuramos la página de inicio:

• Como podemos ver ya la tenemos habilitada:

• Ahora vamos a configurar la página de inicio para Mozilla Firefox, para ello, accedemos a la ruta “Configuración de usuario > Directivas > Plantillas administrativas > Plantillas administrativas clásicas (ADM) > Mozilla Firefox Default Settings” y configuramos la política “General Settings”:

• La habilitamos y configuramos la página de inicio:

• Como podemos ver ya la tenemos habilitada:

• Ahora vamos a introducir en la GPO el script de inicio de seseión “firefox_login.vbs” que se encuentra en el archivo que nos hemos descargado anteriormente:

• Para ello accedemos a la ruta “Configuración de usuario > Directivas > Configuración de Windows > Scripts” y editamos “Iniciar sesión”:

• Si clicamos sobre “Mostrar archivos…” se nos abrirá la ruta dónde se encuentran los scripts que tiene configurados esta GPO (Config_IE_Chrome_Firefox), pues aquí copiamos el script “firefox_login.vbs”:

• Ahora lo agregamos como script de inicio de sesión:

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

• Una vez que ya tenemos la GPO “Conf_IE_Chrome_Firefox” preparada y configurada, la vinculamos sobre la raíz de nuestro dominio:

• Como podemos ver ya está vinculada sobre el dominio, y el orden de vínculo, la hemos ubicado en el tercer lugar:

• 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 sea de ayuda

La entrada GPO para configurar página de inicio en Internet Explorer, Google Chrome y Mozilla Firefox se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo realizar un sysprep a los sistemas Windows.

Sysprep es una herramienta para preparar despliegues de máquinas Windows y que tiene bastante uso en entornos virtualizados, dónde preparamos una plantilla del sistema a partir de la cuál desplegaremos nuestras máquinas virtuales Windows, también tiene bastante uso en su despliegue para máquinas de escritorio, dónde preparamos una imagen maestra a partir de la cuál se instalaran todos los equipos de los usuarios.

¿Porqué es una buena práctica realizar un sysprep a nuestras plantillas para máquinas virtuales y a las imágenes de los equipos de escritorio?

La principal razón para realizar este sysprep es, porque a cada nueva máquina desplegada a partir de una plantilla o imagen con sysprep se le va a asignar un nuevo SID (Secure Identifier), este SID es asignado al equipo durante el proceso de instalación del sistema operativo y debe ser un identificador único para cada equipo, este SID es muy importante sobre todo en entornos de Active Directory, ya que si clonamos todas las máquinas a partir de una plantilla o máquina sin el sysprep realizado, nuestro Active Directory no va a distinguir entre las distintas máquinas ya que el SID es el mismo para todos los equipos, podemos tener problemas por ejemplo, al añadir un equipo al dominio, ya que el sistema nos va a indicar que ese equipo ya se ha unido, podemos tener problemas si tenemos implementado un servidor WSUS en nuestra infraestructura, ya que en la consola de administración de WSUS sólo va a reconocer un equipo, es decir, de todos los que tengan el mismo SID, sólo va a mostrar el último equipo que haya solicitado descargar actualizaciones, estos son algunos de los casos que yo me he encontrado, pero seguramente que con el paso del tiempo podemos ver cosas raras en nuestros sistemas si no realizamos un sysprep como es debido.

Estos son los cambios que nos realiza un sysprep con el check de “Generalizar” marcado:

• Cambio del nombre del equipo
• Eliminación de los puntos de restauración
• Eliminación de los registros del visor de eventos
• Eliminación de la licencia y activación de Windows
• Eliminación de las configuraciones TCP/IP de la Interface de red

– Fuente: Libro Win10IT del gran Xavier Genestós, muy recomendada su lectura

Muchas gracias Xavier por tus magníficos libros, que tanto nos ayudan en nuestro día a día.

Ahora vamos a ver dos casos para aplicar sysprep:

• En el primer caso, vamos a suponer que hemos clonado una máquina virtual a partir de otra máquina, con lo cuál, estas dos máquinas van a tener el mismo SID, en este caso, sobre la máquina clonada nos abrimos un sysprep desde la ubicación “C:\Windows\System32\Sysprep” y ejecutamos un “sysprep.exe” con el check “Generalizar” marcado:

• Como podemos ver comienza a realizar el sysprep:

• Nuestra máquina se reinicia:

• Una vez reiniciada podemos ver que se ha aplicado el sysprep, ya que el sistema nos hará una serie de preguntas sobre las configuraciones:

• Iniciamos sesión con las credenciales que hemos configurado:

• Y ya tendremos un sistema completamente limpio con un SID nuevo y único para esta máquina.

• En el segundo caso, vamos a suponer que queremos utilizar una plantilla maestra para desplegar nuestras máquinas virtuales Windows, para ello, sobre la máquina virtual que posteriormente vamos a convertir en plantilla vamos a ejecutar el siguiente comando cmd, primero nos ubicamos sobre el path “C:\Windows\System32\Sysprep” y ejecutamos “sysprep /generalize /oobe /mode:vm /shutdown”, vamos a explicar un poco el comando:
• sysprep, para lanzar el ejecutable de la preparación del sistema.
• /generalize, para realizar un reset del SID.
• /oobe, para iniciar la configuración rápida del sistema.
• /mode:vm, este parámetro sólo lo vamos a utilizar si se trata de máquinas virtuales ya que el proceso de sysprep no va a eliminar la información de hardware, siendo el proceso más rápido, este parámetro lo podemos utilizar tanto en hipervisores Hyper-V como en VMware.
• /shutdown, para apagar la máquina virtual y poder así entonces convertirla a plantilla.

• Como podemos ver comienza a realizar el sysprep:

• Nuestra máquina virtual se va a apagar:

• Una vez apagada ya la podemos convertir a plantilla en nuestro entorno de virtualización.
• Ahora todas las máquinas que despleguemos a partir de esta plantilla van a tener un sysprep realizado como es debido y como se debe hacer en toda infraestructura que quiera ser profesional.

Saludos y espero que os sea de ayuda

La entrada Sysprep en Sistemas MS Windows se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como migrar un controlador de dominio con Windows Server 2012 R2 a Windows Server 2016.

• Supongamos que tenemos un controlador de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2012 R2 Standard:

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

• Nos instalamos un nuevo server con el sistema operativo MS Windows Server 2016 Standard, lo actualizamos y 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 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 DC01 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio (Una buena práctica es cambiar el nombre del Administrador del dominio, nosotros lo dejaremos como Administrador, ya que para temas de laboratorios no implementaremos este tipo de seguridad):

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

• Hacemos clic en siguiente:

• Elegimos la opción, instalación basada en características o roles:

• Seleccionamos nuestro servidor dc01:

• Ahora agregamos 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 :

• Iniciamos el despliegue de la función, Servicios de dominio de Active Directory:

• Comienza el despliegue del Active Directory:

• Una vez finalizada la instalación cerramos y reiniciamos nuestro controlador de dominio:

• Tras el reinicio vamos al Administrador del servidor y promovemos este servidor a controlador de dominio:

• Agregamos un controlador de dominio a un dominio ya existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del 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 (introducimos la misma contraseña que pusimos en el controlador de dominio principal):

• Esta opción 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 las opciones de replicación le decimos que replique desde el controlador de dominio principal:

• Las rutas de acceso las dejamos por defecto:

• Comienza a preparar el bosque y dominio:

• Revisamos las opciones e instalamos:

• 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 vamos a la consola de Usuarios y equipos de Active Directory en DC01, y podemos ver que este equipo ya está como un Domain Controller más de nuestra infraestructura:

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

• Una vez que tenemos agregado un controlador de dominio adicional con sistema operativo MS Windows Server 2016 y por lo tanto superior a MS Windows Server 2012 R2, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2016 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 2012 R2 (oficala):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO al controlador de dominio adicional (Windows Server 2016), 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 2016:

• Primero vamos a transferir el RID Master:

• Segundo vamos transferir el PDC Emulator:

• En tercer lugar vamos a transferir el Infraestructure 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 2016:

• 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 schmmgmt.dll y personalizarnos una consola mmc, para ello, en nuestro controlador de dominio principal con MS Windows Server 2012 R2 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 2016):

• 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:

• Ahora ya podemos despromocionar como controlador de dominio el servidor con MS Windows Server 2012 R2, para ello vamos a seguir los pasos indicados en un post de este mismo blog, Eliminar controladores de dominios sobre MS Windows Server 2012 R2.

• 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.

• Como podemos ver ya tenemos despromocionado como controlador de dominio el server con MS Windows Server 2012 R2, ahora se quedaría como un equipo más miembro del dominio ragasys.net:

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

• 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 2012 R2, ya que el controlador de dominio anterior trabajaba sobre este sistema operativo, procedemos a elevarlo a 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:

• 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:

• Con esto ya tendríamos migrado nuestro controlador de dominio de MS Windows Server 2012 R2 a MS Windows Server 2016.

Espero que os sea de ayuda

La entrada Migrar controlador de dominio con Windows Server 2012 R2 a Windows Server 2016 se publicó primero en RAGASYS SISTEMAS.

Anteriormente vimos como instalar y configurar el backup con Veeam Agent 2.2 for Microsoft Windows en un equipo con Windows Server, en este procedimiento veremos cómo restaurar el equipo completo en caso de desastre.

• Vamos a suponer que el sistema operativo de nuestra máquina física ha quedado completamente corrupto y no podemos iniciar nuestro servidor, entonces, lo primero que tenemos que hacer es configurar en la BIOS del equipo que arranque desde CDROM, e introducir en la unidad de CD la Imagen ISO Veeam_Recovery_Media perteneciente a esta máquina, esta imagen ISO la creamos en los procesos de configuración de los agentes de Veeam:

• Una vez que tenemos la ISO preparada, iniciamos el servidor que queremos recuperar desde la unidad dónde tengamos el Veeam Recovery Media y nos aparece este menú de opciones, nosotros vamos a elegir “Bare Metal Recovery”:

• Se nos abrirá el siguiente asistente, y en esta primera opción de “Backup Location” elegiremos una ubicación de red:

• Nos pregunta si queremos configurar una conexión a red, le indicamos que SI:

• Instalamos el driver de la controladora Ethernet:

• Como podemos ver el driver se ha instalado correctamente, clic sobre “Aceptar”:

• Damos clic a “OK”:

• En la opción de “Properties” podemos elegir entre una configuración de red estática o dinámica, como nosotros tenemos configurado un servidor DHCP en nuestra red, elegimos una configuración dinámica:

• En “Network Storage” seleccionamos “Shared folder”, ya que el backup lo tenemos en un recurso compartido:

• En “Shared Folder” especificamos la ruta de la carpeta compartida compartida en Windows (SMB) y el usuario con su password:

• En “Backup” nos aparecen los trabajos de backups que tenemos en esta ubicación de red, nosotros vamos a elegir el que necesitemos:

• Elegimos el punto de restauración que más nos interese, en este caso, sólo tenemos uno:

• En el “Restore Mode”, elegimos la opción de “Entire computer”, es decir, el restaurar el servidor completo:

• Nos muestra un resumen de lo que hará el restore, si estamos conforme, pulsamos “Restore” para comenzar:

• Como podemos ver, el proceso ha comenzado y está corriendo sin problemas:

• Como podemos ver el proceso ha finalizado correctamente, pulsamos “Finish” para terminar:

• Nos indica que el restore ha sido completado, clic sobre “Yes” para reiniciar, antes de reiniciar debemos sacar la ISO de la unidad de CD:

• Como podemos ver el Servidor Windows, está completamente restaurado y operativo:

Saludos y espero que os sea de ayuda

La entrada Veeam Agent 2.2 for Microsoft Windows – Restore completo del servidor se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como restaurar los ficheros de un servidor físico Windows con la opción “File Level Recovery”, utilizando Vembu BDR Suite 3.9.1 U1 y los backups que ya hicimos en posts anteriores.

Recordemos la topología configurada:

• Accedemos a la consola web de nuestro servidor Vembu:

• Sobre la opción de Recovery, nos muestra una lista con los backups realizados, y sobre la opción de Restore hacemos clic en el servidor físico Windows del que queremos restaurar los ficheros, en este caso, vamos a restaurar los ficheros del servidor llamado vemburgs:

• Se nos abre el siguiente asistente, y en esta primera opción, nos da a elegir el tipo de restauración, en nuestro caso, vamos a elegir la opción “File Level Recovery”:

• En esta segunda opción, nos va a mostrar las versiones por fechas de los backups que tenemos realizados, dónde podemos elegir el que nos interese, en este caso sólo tenemos una versión o un backup realizado, por tanto, sólo podemos elegir esa versión, también escogemos que ficheros queremos restaurar, en este caso, es un paquete msi de VembuImageBackup para una instalación en Windows:

• Sobre esta tercera opción de “Restore Options”, elegimos la ruta dónde restaurar los ficheros:

• Aquí nos muestra un resumen de las opciones que hemos elegido para restaurar los ficheros del servidor físico, damos clic sobre “Restore Now”:

• Clic en “OK” para confirmar el restore:

• Aquí podemos ver el proceso de la restauración:

• Sobre los reportes podemos verificar que el restore se ha realizado correctamente:

• Como podemos ver aquí tenemos el fichero restaurado, en la ruta que le indicamos:

Post sponsorizado por Vembu Technologies

La entrada Restauración de Servidores físicos Windows con Vembu BDR Suite 3.9.1 Update1 modo “File Level Recovery” se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como restaurar un servidor físico Windows a máquina virtual con la opción “Quick VM Recovery”, utilizando Vembu BDR Suite 3.9.1 U1 y los backups que ya hicimos en posts anterior.

Recordemos la topología configurada:

• Accedemos a la consola web de nuestro servidor Vembu:

• Sobre la opción de Recovery, nos muestra una lista con los backups realizados, y sobre la opción de Restore hacemos clic en el servidor físico Windows que queremos restaurar, en este caso vamos a restaurar el servidor llamado vemburgs:

• Se nos abre el siguiente asistente, y en esta primera opción, nos da a elegir el tipo de restauración, en nuestro caso, vamos a elegir la opción “Quick VM Recovery”:

• En esta segunda opción, nos va a mostrar las versiones por fechas de los backups que tenemos realizados, dónde podemos elegir el que nos interese, en este caso sólo tenemos una versión o un backup realizado, por tanto, sólo podemos elegir esa versión:

• Sobre esta tercera opción de “Restore Options”, elegimos el servidor vCenter dónde restaurar la máquina virtual, seleccionamos el host ESXi dónde restaurar (host1), el datastore dónde se ubicará la máquina virtual a restaurar y le damos un nombre a la máquina, en este caso “VEMBURGS_RESTORE”:

• Aquí nos muestra un resumen de las opciones que hemos elegido para restaurar el servidor físico a máquina virtual, damos clic sobre “Restore Now”:

• Clic en “OK” para confirmar el restore:

• Aquí podemos ver el proceso de la restauración:

• Como vemos la máquina se ha restaurado en nuestro vCenter:

Post sponsorizado por Vembu Technologies

Saludos y espero que os sea de ayuda

La entrada Restauración de Servidores físicos Windows con Vembu BDR Suite 3.9.1 Update1 modo “Quick VM Recovery” se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como configurar backups con Vembu BDR Suite 3.9.1 Update 1 en servidores físcos Windows de nuestra infraestructura, a través de la aplicación Vembu ImageBackup Client.

Recordemos la topología configurada:

• Lo primero que vamos a realizar será configurar el servicio VembuBDR instalado en el servidor que tiene la consola central de Vembu BDR Suite con una cuenta de usuario de nuestro Active Directory con permisos de administrador, ya que para desplegar los clientes de Vembu ImageBackup es un requisito indispensable:

• Como podemos ver ya lo tenemos en ejecución con esta cuenta de usuario:

• Ahora accedemos a la consola web con las credenciales que configuramos para la suite Vembu BDR:

• Añadimos el servidor físico Windows que queremos proteger con nuestra suite de Vembu BDR:

• Introducimos los datos del servidor físico Windows y guardamos los cambios:

• Comienza a instalar el agente de Vembu ImageBackup:

• Como podemos ver el servidor físico Windows se ha agregado correctamente:

• Esto es lo que instala en nuestro servidor físico Windows Server:

• También hemos añadido el propio servidor de Vembu BDR Suite como localhost, ya que este servidor es un servidor físico con Windows Server 2016 Standard:

• Ahora vamos a programar un trabajo de backup para uno de estos servidores físicos, concretamente para el propio servidor de Vembu BDR Suite (localhost), para ello damos clic sobre “Backup”:

• Se nos abre el siguiente asistente y lo primero que vamos a instalar será el driver de Vembu ImageBackup:

• El sistema nos indica que el driver de Vembu ImageBackup requiere un reinicio de la máquina:

• Una vez que la máquina ha reiniciado proseguimos con la configuración del trabajo de backup, y en primer lugar escogemos los discos que queremos respaldar, en este caso será el disco de sistema:

• Clic sobre OK, para habilitar un punto de montaje sobre la partición que no tiene asignada ninguna letra o punto de montaje:

• Seleccionamos el disco de sistema con sus dos partciones:

• Esta opción la dejamos por defecto:

• Sobre esta opción programamos la tarea de backup, aquí ya lo programamos según nuestros horarios, infraestructuras, etc…, como buena práctica se realizan los backups cuando los usuarios clientes no están trabajando sobre el sistema, y en un caso que siempre estén trabajando (por ejemplo a turnos), realizar los backups cuando menos carga de trabajo haya, también podemos ver que nos permite realizar un backup completo adicional en los meses que creamos conveniente y almacenar el número máximo que queramos de estos backups, esto viene muy bien para tener un buen histórico:

• En esta opción, primero configuramos que el último viernes de cada mes fusione todas las copias incrementales realizadas y segundo elegimos el repositorio dónde se van a guardar los backups, también nos da la opción de encriptar los backups con un password:

• Para terminar, le asignamos un nombre al trabajo de backup, y como vemos nos muestra un resumen de todas las opciones configuradas anteriormente, si queremos podemos marcar el check para que realice el trabajo inmediatamente después de guardarlo:

• Confirmamos el trabajo:

• En la lista de trabajos de backup, podemos ver el que acabamos de crear:

• Ejecutamos el trabajo de backup:

• Aquí podemos ver el progreso:

• Como vemos, el backup se ha realizado correctamente:

Post sponsorizado por Vembu Technologies

Saludos y espero que os sea de ayuda

La entrada Configuración de backups con Vembu BDR Suite 3.9.1 Update 1 en servidores físicos Windows se publicó primero en RAGASYS SISTEMAS.

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

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

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

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

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

• Le asignamos un nombre:

• La editamos:

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

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

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

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

• Y probamos a conectar por escritorio remoto al servidor:

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

Saludos y espero que os resulte de ayuda

La entrada Actualizaciones de CredSSP para CVE-2018-0886 se publicó primero en RAGASYS SISTEMAS.