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

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.

En este post vamos a ver que equipo de nuestra infraestructura de red está bloqueando una cuenta de usuario de Active Directory (AD), seguramente nos hemos encontrado alguna vez que uno de nuestros usuarios nos está avisando continuamente de que su cuenta está bloqueada, sin motivo aparente alguno, es decir, que está cumpliendo las GPO correspondientes a las cuentas de usuario (mínimo número de caracteres, algún carácter especial, mayúsculas, minúsculas, que al tercer inicio de sesión errónea se le bloquee la cuenta, etc…), estos bloqueos continuos de contraseñas se están produciendo porque hay varios intentos fallidos de logon que pueden estar sucediendo por muchos motivos, como por ejemplo, ese usuario está asociado a algún servicio, hay alguna unidad de red mapeada con ese usuario y la contraseña no es la correcta, alguna aplicación tiene asociada ésta cuenta, etc…, pues bien, en este post vamos a explicar que equipo de nuestra red está bloqueando ésta cuenta de usuario.

• Lo primero que vamos a realizar será un logon al sistema con la cuenta de usuario bloqueada:

• Como podemos ver en nuestro Controlador de Dominio, la cuenta de usuario está bloqueada:

• Pues bien, ahora lo que queremos saber, es que equipo está bloqueando ésta cuenta, para ello nos abrimos el “Visor de eventos” en nuestro Domain Controller:

• Aplicamos un filtro a los registros de seguridad de Windows:

• Lo filtramos por el id. de evento 4740:

• Una vez filtrado, ya podemos ver más fácilmente, que equipo de nuestra red está bloqueando la cuenta de usuario:

• Una vez que sabemos el equipo que está produciendo los bloqueos, el siguiente paso sería ir a ese equipo y ver que provoca tantos intentos fallidos de inicios de sesión, que como hemos comentado anteriormente puede ser que ese usuario está asociado a algún servicio, hay alguna unidad de red mapeada con ese usuario y la contraseña no es la correcta, alguna aplicación tiene asociada ésta cuenta, etc…

Saludos y espero que os sea de ayuda

La entrada Saber desde que equipo se bloquea una cuenta de usuario de Active Directory se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como migrar directorios, ficheros y permisos NTFS de los recursos compartidos entre servidores de archivos Windows con el método robocopy, seguramente en más de una ocasión nos hemos encontrado con este problema cuando hemos instalado un nuevo servidor de ficheros y queremos migrar los recursos compartidos con todos sus permisos NTFS entre el antiguo file server y el nuevo.

• Como podemos ver en el servidor de ficheros Oficala tenemos estos tres recursos compartidos:

• Estos tres recursos compartidos están ubicados en la Unidad D:

• Los permisos de recurso compartido para “Usuarios” son los siguientes:

• Los permisos NTFS para “Usuarios” son los siguientes:

• Los permisos de recurso compartido para “Grupos” son los siguientes:

• Los permisos NTFS para “Grupos” son los siguientes:

• Los permisos de recurso compartido para “Publico” son los siguientes:

• Los permisos NTFS para “Publico” son los siguientes:

• Ahora iniciamos sesión en el servidor de ficheros nuevo (FSRGS) con una cuenta de Administrador del dominio y ejecutamos el siguiente comando para copiar los recursos compartidos con todos sus directorios, ficheros y permisos NTFS, “robocopy origen destino /S /E /Z /R:2 /W:10 /COPYALL /SECFIX”
• Significado de los modificadores:
• /S Directorio actual y subdirectorios
• /E Directorio actual y subdirectorios aunque estén vacíos
• /Z En caso de copia por red, reconecta si se pierde la conexión
• /R:2 Número de reintentos en copias con errores
• /W:10 Tiempo de espera entre reintentos
• Si configuramos /R:0 /W:0 no se efectuarán reintentos
• /COPYALL Copia permisos y propietario del origen al destino y copia ficheros ocultos y de sistema
• /SECFIX Elimina todos los unresolvable SID (Secure indentifier huérfanos que no pertenecen a ninguna cuenta de usuario)

• Como podemos ver la operación se ha realizado correctamente:

• Ahora nos vamos a la unidad D del nuevo servidor de ficheros y cómo podemos comprobar a copiado todos los recursos compartidos con sus directorios, ficheros y permisos NTFS, lo que NO hace este comando “robocopy” es copiar la compartición NI los permisos de recurso compartido, veremos como ejemplo sobre “Grupos” de que todo está correcto:

• Dentro de “Grupos” tenemos varios directorios con sus permisos NTFS y que a su vez contienen ficheros, vamos a comprobar sobre el directorio “Administracion” que los permisos NTFS se han copiado correctamente:

• Los ficheros ubicados dentro del directorio “Administracion” podemos comprobar que los permisos NTFS se han copiado correctamente:

• Una vez que hemos verificado que todo está correcto procedemos a descompartir los recursos compartidos sobre el file server antiguo “oficala”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ahora procedemos a compartir y asignar los permisos de recursos compartidos sobre el nuevo file server “fsrgs”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ya tenemos nuestros tres recursos compartidos, operativos en nuestro nuevo file server tal y como estaban originalmente:

Saludos y espero que os resulte de ayuda

La entrada Migrar directorios, ficheros y permisos NTFS de recursos compartidos entre servidores de archivos Windows – Método III robocopy se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como migrar directorios, ficheros y permisos NTFS de los recursos compartidos entre servidores de archivos Windows con el método icacls, seguramente en más de una ocasión nos hemos encontrado con este problema cuando hemos instalado un nuevo servidor de ficheros y queremos migrar los recursos compartidos con todos sus permisos NTFS entre el antiguo file server y el nuevo.

• Como podemos ver en el servidor de ficheros Oficala tenemos estos tres recursos compartidos:

• Estos tres recursos compartidos están ubicados en la Unidad D:

• Los permisos de recurso compartido para “Usuarios” son los siguientes:

• Los permisos NTFS para “Usuarios” son los siguientes:

• Los permisos de recurso compartido para “Grupos” son los siguientes:

• Los permisos NTFS para “Grupos” son los siguientes:

• Los permisos de recurso compartido para “Publico” son los siguientes:

• Los permisos NTFS para “Publico” son los siguientes:

• Ahora con el comando icacls vamos a exportar los permisos NTFS de una carpeta y sus subcarpetas.
• Empezaremos exportando los permisos NTFS del recurso compartido “Usuarios”, para ello utilizaremos el siguiente comando:

• El fichero txt generado sería el siguiente y estaría ubicado en la raíz de la carpeta Usuarios:

• Seguiremos exportando los permisos NTFS del recurso compartido “Grupos”, para ello utilizaremos el siguiente comando:

• El fichero txt generado sería el siguiente y estaría ubicado en la raíz de la carpeta Grupos:

• Por último exportamos los permisos NTFS del recurso compartido “Publico”, para ello utilizaremos el siguiente comando:

• El fichero txt generado sería el siguiente y estaría ubicado en la raíz de la carpeta Publico:

• Ahora iniciamos sesión en el servidor de ficheros nuevo (FSRGS) con una cuenta de Administrador del dominio y mapeamos como unidad de red con el comando “net use” la unidad local donde se encuentran los recursos compartidos del servidor antiguo (OFICALA), al iniciar sesión con una cuenta de Administrador del dominio no nos pide que introduzcamos credenciales:

• Como podemos ver ya tenemos la unidad de red mapeada y por lo tanto acceso a los directorios de recursos compartidos en el servidor antiguo (oficala):

• Copiamos los tres directorios de recursos compartidos del antiguo servidor (oficala) al nuevo servidor (FSRGS), en la unidad local de datos dedicada para ello:

• Una vez que tenemos copiadas las carpetas de recursos compartidos al nuevo servidor, procedemos a importar todos los permisos, empezaremos importando los permisos NTFS de la carpeta Usuarios, para ello introducimos el siguiente comando:

• Seguimos importando los permisos NTFS de la carpeta Grupos, para ello introducimos el siguiente comando:

• Por último importamos los permisos NTFS de la carpeta Publico, para ello introducimos el siguiente comando:

• Con esto ya tendríamos exportados todos los permisos NTFS de los recursos compartidos al nuevo servidor.
• Una vez que hemos verificado que todo está correcto procedemos a descompartir los recursos compartidos sobre el file server antiguo “oficala”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ahora procedemos a compartir y asignar los permisos de recursos compartidos sobre el nuevo file server “fsrgs”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ya tenemos nuestros tres recursos compartidos, operativos en nuestro nuevo file server tal y como estaban originalmente:

Saludos y espero que os sea de ayuda

La entrada Migrar directorios, ficheros y permisos NTFS de recursos compartidos entre servidores de archivos Windows – Método II icacls se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como migrar directorios, ficheros y permisos NTFS de los recursos compartidos entre servidores de archivos Windows con el método xcopy, seguramente en más de una ocasión nos hemos encontrado con este problema cuando hemos instalado un nuevo servidor de ficheros y queremos migrar los recursos compartidos con todos sus permisos NTFS entre el antiguo file server y el nuevo.

• Como podemos ver en el servidor de ficheros Oficala tenemos estos tres recursos compartidos:

• Estos tres recursos compartidos están ubicados en la Unidad D:

• Los permisos de recurso compartido para “Usuarios” son los siguientes:

• Los permisos NTFS para “Usuarios” son los siguientes:

• Los permisos de recurso compartido para “Grupos” son los siguientes:

• Los permisos NTFS para “Grupos” son los siguientes:

• Los permisos de recurso compartido para “Publico” son los siguientes:

• Los permisos NTFS para “Publico” son los siguientes:

• Ahora iniciamos sesión en el servidor de ficheros nuevo (FSRGS) con una cuenta de Administrador del dominio y ejecutamos el siguiente comando para copiar los recursos compartidos con todos sus directorios, ficheros y permisos NTFS, “ xcopy origen destino /S /E /V /O /H /C /Y”
• Significado de los modificadores:
• /S Directorio actual y subdirectorios
• /E Directorio actual y subdirectorios aunque estén vacíos
• /V Verifica cada fichero copiado, por lo tanto el proceso será más lento
• /O Copia permisos y propietario del origen al destino
• /H Copia ficheros ocultos y de sistema
• /C Continúa copiando aunque se produzcan errores
• /Z En caso de copia por red, reconecta si se pierde la conexión
• /Y Responde “Sí” a todas las preguntas

• Como podemos ver la operación se ha realizado correctamente:

• Ahora nos vamos a la unidad D del nuevo servidor de ficheros y cómo podemos comprobar a copiado todos los recursos compartidos con sus directorios, ficheros y permisos NTFS, lo que NO hace este comando “xcopy” es copiar la compartición NI los permisos de recurso compartido, veremos como ejemplo sobre “Grupos” de que todo está correcto:

• Dentro de “Grupos” tenemos varios directorios con sus permisos NTFS y que a su vez contienen ficheros, vamos a comprobar sobre el directorio “Administracion” que los permisos NTFS se han copiado correctamente:

• Los ficheros ubicados dentro del directorio “Administracion” podemos comprobar que los permisos NTFS se han copiado correctamente:

• Una vez que hemos verificado que todo está correcto procedemos a descompartir los recursos compartidos sobre el file server antiguo “oficala”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ahora procedemos a compartir y asignar los permisos de recursos compartidos sobre el nuevo file server “fsrgs”, mostraremos el ejemplo sobre “Grupos”, para los demás será el mismo proceso:

• Ya tenemos nuestros tres recursos compartidos, operativos en nuestro nuevo file server tal y como estaban originalmente:

Saludos y espero que os resulte de ayuda

La entrada Migrar directorios, ficheros y permisos NTFS de recursos compartidos entre servidores de archivos Windows – Método I xcopy se publicó primero en RAGASYS SISTEMAS.