Problema de activación de GPO
katanka
Mensajes publicados
9
Fecha de registro
Estado
Miembro
Última intervención
-
kelux Mensajes publicados 3065 Fecha de registro Estado Colaborador Última intervención -
kelux Mensajes publicados 3065 Fecha de registro Estado Colaborador Última intervención -
Hola,
En un entorno de Windows Server 2012 / estaciones de trabajo Windows 7, quiero implementar una GPO sobre varios equipos de mi dominio. He creado una OU específica que contiene estas estaciones y he creado y vinculado mi GPO a esa misma OU. El objetivo de esta GPO es la instalación en la máquina de una tarea programada cuyo resultado sea apagar el PC a una hora fija, independientemente del usuario conectado. En mi GPO he ido a la sección configuración ordenador/preferencias/... para definir la tarea programada (en modo creación) con como identificador de ejecución la cuenta administrador del dominio.
Resultado: la GPO se ejecuta en la máquina afectada, pero la creación de la tarea programada es rechazada (0x80070005 acceso denegado). Sospecho que se trata de un problema de permisos; he probado de añadir la cuenta administrador del dominio como administrador de la máquina, pero no ha cambiado nada.
Gracias por vuestra ayuda.
En un entorno de Windows Server 2012 / estaciones de trabajo Windows 7, quiero implementar una GPO sobre varios equipos de mi dominio. He creado una OU específica que contiene estas estaciones y he creado y vinculado mi GPO a esa misma OU. El objetivo de esta GPO es la instalación en la máquina de una tarea programada cuyo resultado sea apagar el PC a una hora fija, independientemente del usuario conectado. En mi GPO he ido a la sección configuración ordenador/preferencias/... para definir la tarea programada (en modo creación) con como identificador de ejecución la cuenta administrador del dominio.
Resultado: la GPO se ejecuta en la máquina afectada, pero la creación de la tarea programada es rechazada (0x80070005 acceso denegado). Sospecho que se trata de un problema de permisos; he probado de añadir la cuenta administrador del dominio como administrador de la máquina, pero no ha cambiado nada.
Gracias por vuestra ayuda.
13 respuestas
Hola, quizá no vaya a aportar una solución, pero tengo algunos comentarios.
No se usa una cuenta administrador del dominio para ejecutar tareas programadas, y menos aún en estaciones de trabajo. (y seguramente la cuenta admin del dominio, supongo que es la cuenta original, es decir, la que tiene más permisos...)
Están poniendo en peligro su infraestructura, es super peligroso:
https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati
https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/
Con las GPP almacenas la contraseña de la cuenta admin del dominio, en el sysvol, en un archivo que cualquiera puede leer, y que cualquiera puede descifrar; Microsoft ha publicado las claves para cifrar y descifrar, con un script en 20 segundos ya está solucionado...
Hay un parche que permite desactivar el almacenamiento de contraseñas a través de las GPP (no solo las tareas programadas se ven afectadas); si ese parche se aplica al controlador de dominio, ya no es posible que la contraseña se almacene para la creación de la tarea, y esto podría explicar el error. No mencionaron cómo se creó la tarea a través de la GPP. (si la contraseña efectivamente fue registrada, etc...).
Por otra parte, la máquina para apagarse no necesita derechos de administrador del dominio para hacerlo...
También añadir la cuenta admin del dominio como administrador local es innecesario, porque el grupo 'Administradores del dominio' es por defecto administrador local de cada estación/servidor.
-
En uno de mis posts ya había respondido a esta problemática.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
No se usa una cuenta administrador del dominio para ejecutar tareas programadas, y menos aún en estaciones de trabajo. (y seguramente la cuenta admin del dominio, supongo que es la cuenta original, es decir, la que tiene más permisos...)
Están poniendo en peligro su infraestructura, es super peligroso:
https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati
https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/
Con las GPP almacenas la contraseña de la cuenta admin del dominio, en el sysvol, en un archivo que cualquiera puede leer, y que cualquiera puede descifrar; Microsoft ha publicado las claves para cifrar y descifrar, con un script en 20 segundos ya está solucionado...
Hay un parche que permite desactivar el almacenamiento de contraseñas a través de las GPP (no solo las tareas programadas se ven afectadas); si ese parche se aplica al controlador de dominio, ya no es posible que la contraseña se almacene para la creación de la tarea, y esto podría explicar el error. No mencionaron cómo se creó la tarea a través de la GPP. (si la contraseña efectivamente fue registrada, etc...).
Por otra parte, la máquina para apagarse no necesita derechos de administrador del dominio para hacerlo...
También añadir la cuenta admin del dominio como administrador local es innecesario, porque el grupo 'Administradores del dominio' es por defecto administrador local de cada estación/servidor.
-
En uno de mis posts ya había respondido a esta problemática.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Avec la méthode 3, on n’utilise pas de GPP, juste une GPO qui lance un script.
Ce script lance la commande schtasks pour créer la tâche planifiée.
La tâche planifiée lancera la commande shutdown.
J’ai mis le paramètre /F dans schtasks pour écraser la création même si la tâche existe déjà. Ça permet d’être sûr que cela sera créé, et aussi si on veut mettre à jour les paramètres de la tâche, on est sûr d’écraser la tâche existante.
On créé une gpo de type "logon script", sur la partie machine. Le script sera donc exécuté à chaque démarrage de la machine.
Dans cette gpo on fait exécuter le script "create_task_shutdown.bat".
Et dans "create_task_shutdown.bat" on y mets ceci :
Il faut ensuite jouer un peu avec la commande schtasks et shutdown en fonction de ce qu’on veut faire.
Les options que j’ai données sont à titre d’exemple.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Ce script lance la commande schtasks pour créer la tâche planifiée.
La tâche planifiée lancera la commande shutdown.
J’ai mis le paramètre /F dans schtasks pour écraser la création même si la tâche existe déjà. Ça permet d’être sûr que cela sera créé, et aussi si on veut mettre à jour les paramètres de la tâche, on est sûr d’écraser la tâche existante.
On créé une gpo de type "logon script", sur la partie machine. Le script sera donc exécuté à chaque démarrage de la machine.
Dans cette gpo on fait exécuter le script "create_task_shutdown.bat".
Et dans "create_task_shutdown.bat" on y mets ceci :
:: Création de la tâche planifiée ExtinctionAuto
:: Se lance tous les jours à 20 h 30 minutes
:: et exécute la commande shutdown /s /t 0 (extinction immédiate)
:: le code suivant est sur une seule ligne
schtasks /create /ru system /rl highest /sc DAILY /tn ExtinctionAuto /st 20:30 /F /tr "shutdown /s /t 0"
Il faut ensuite jouer un peu avec la commande schtasks et shutdown en fonction de ce qu’on veut faire.
Les options que j’ai données sont à titre d’exemple.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Hola,
verifica, en los equipos con Windows 7, los permisos NTFS de este directorio
C:\ProgramData\Microsoft\Crypto\RSA. los grupos Administradores y Sistema deben tener control total.
Atentamente.
verifica, en los equipos con Windows 7, los permisos NTFS de este directorio
C:\ProgramData\Microsoft\Crypto\RSA. los grupos Administradores y Sistema deben tener control total.
Atentamente.
Hola,
Sí, es así. ¿Puedes explicarme en qué manera esta verificación puede influir en la activación de mi GPO (para mi cultura general ;) )?
Para tu información, la cuenta de usuario del dominio en la máquina en cuestión no está declarada en la sección de configuración de usuarios del panel de control. ¿Tiene alguna importancia o no definirla ahí?
Sí, es así. ¿Puedes explicarme en qué manera esta verificación puede influir en la activación de mi GPO (para mi cultura general ;) )?
Para tu información, la cuenta de usuario del dominio en la máquina en cuestión no está declarada en la sección de configuración de usuarios del panel de control. ¿Tiene alguna importancia o no definirla ahí?
Muchas gracias por estas precisiones Kelux; en este caso pensaba que la cuenta de administrador era simplemente necesaria para la creación de la tarea en la estación y por lo tanto no se almacenaría.
Acabo de leer su respuesta anterior a una pregunta similar y me gustaría recibir algunas precisiones sobre la implementación del método 3, en particular sobre la cuenta que se debe usar para crear la GGP, y el contenido del script de verificación.
Acabo de leer su respuesta anterior a una pregunta similar y me gustaría recibir algunas precisiones sobre la implementación del método 3, en particular sobre la cuenta que se debe usar para crear la GGP, y el contenido del script de verificación.
Muchas gracias por estas explicaciones detalladas, no conocía el comando schtasks.
Lo voy a revisar con más detenimiento.
Lo voy a revisar con más detenimiento.
Hola,
Acabo de hacer la prueba siguiendo sus recomendaciones.
Por lo tanto, creé una GPO que se aplica a una OU en la que solo hay una estación de trabajo.
Creé el archivo .bat que contiene el script y lo ubiqué en una subcarpeta del carpeta sysvol en el AD.
En la GPO fui a Configuración del equipo/Directiva/Configuración de Windows/Script (inicio/apagado).
Modifiqué el elemento de inicio para indicarle el archivo .bat.
Luego forcé la aplicación de la GPO haciendo clic derecho/aplicar ahora la política en la OU correspondiente.
Vi aparecer poco después una ventana de msdos en la estación de trabajo con el mensaje de aplicación de la política.
Sin embargo, a la hora de apagado prevista (13:00), ¡nada ocurrió! Ningún mensaje particular en los registros de Windows y no hay rastro de la tarea cuando ejecuto el programador de tareas.
Acabo de hacer la prueba siguiendo sus recomendaciones.
Por lo tanto, creé una GPO que se aplica a una OU en la que solo hay una estación de trabajo.
Creé el archivo .bat que contiene el script y lo ubiqué en una subcarpeta del carpeta sysvol en el AD.
En la GPO fui a Configuración del equipo/Directiva/Configuración de Windows/Script (inicio/apagado).
Modifiqué el elemento de inicio para indicarle el archivo .bat.
Luego forcé la aplicación de la GPO haciendo clic derecho/aplicar ahora la política en la OU correspondiente.
Vi aparecer poco después una ventana de msdos en la estación de trabajo con el mensaje de aplicación de la política.
Sin embargo, a la hora de apagado prevista (13:00), ¡nada ocurrió! Ningún mensaje particular en los registros de Windows y no hay rastro de la tarea cuando ejecuto el programador de tareas.
Luego forcé la aplicación de la Gpo haciendo clic derecho/actualizar la política en la OU correspondiente.
Así que esto no sirve de nada. Es una mala traducción del inglés.
En inglés está "enforced", en francés da "appliqué".
Desmarque esta casilla, no sirve para "actualizar en la OU una GPO", de hecho así no funciona, la frase no tiene sentido.
Vi aparecer una ventana de msdos en el puesto de trabajo poco después con el mensaje de aplicación de la política.
Ningún enlace, otra vez.
-
Esta GPO, aunque "vista por el equipo", sólo tendrá efecto cuando el equipo arranque. Es durante la fase de arranque cuando este tipo de Política tendrá su efecto.
Lo indiqué en mis primeros mensajes:
El script se ejecutará en cada inicio de la máquina.
Si no arrancas la máquina no verás el efecto de un script de inicio (loginscript); digamos que el nombre es ambiguo.
-
Segundo punto, no hace falta esperar 13H, basta con ver si la tarea se crea .... si se crea la tarea, el loginscript ha hecho su efecto.
Y validarás que la tarea es correcta editándola.
Si necesitas modificar o ajustar los parámetros, solo tienes que modificar el script ;)
El objetivo es ante todo tener una tarea creada a través del loginscript; después solo es ajuste.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Así que esto no sirve de nada. Es una mala traducción del inglés.
En inglés está "enforced", en francés da "appliqué".
Desmarque esta casilla, no sirve para "actualizar en la OU una GPO", de hecho así no funciona, la frase no tiene sentido.
Vi aparecer una ventana de msdos en el puesto de trabajo poco después con el mensaje de aplicación de la política.
Ningún enlace, otra vez.
-
Esta GPO, aunque "vista por el equipo", sólo tendrá efecto cuando el equipo arranque. Es durante la fase de arranque cuando este tipo de Política tendrá su efecto.
Lo indiqué en mis primeros mensajes:
El script se ejecutará en cada inicio de la máquina.
Si no arrancas la máquina no verás el efecto de un script de inicio (loginscript); digamos que el nombre es ambiguo.
-
Segundo punto, no hace falta esperar 13H, basta con ver si la tarea se crea .... si se crea la tarea, el loginscript ha hecho su efecto.
Y validarás que la tarea es correcta editándola.
Si necesitas modificar o ajustar los parámetros, solo tienes que modificar el script ;)
El objetivo es ante todo tener una tarea creada a través del loginscript; después solo es ajuste.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Me expliqué quizás mal con respecto a la aplicación de la GPO. Cuando se está en la herramienta "Administración de directivas de grupo", a la izquierda se encuentra la descripción del bosque/dominio/OUs/GPO. Si hacemos clic derecho en una OU, el menú contextual muestra una opción "Actualizar la directiva de grupo...". Esa es la opción que he utilizado.
De todos modos, la GPO se aplica correctamente, pero la tarea no se crea. schtasks /query no la lista. Copié/pegé el script en la máquina para ejecutarlo localmente, sin duda por los permisos limitados del usuario que está conectado. Cuando abro un símbolo del sistema como administrador y ejecuto el comando, la tarea se crea correctamente, es visible con schtasks /query, visible en el programador de tareas y se ejecuta a la hora indicada.
Para terminar, no aparece ninguna ventana de DOS al inicio del equipo, ya sea antes o después de la autenticación del usuario.
De todos modos, la GPO se aplica correctamente, pero la tarea no se crea. schtasks /query no la lista. Copié/pegé el script en la máquina para ejecutarlo localmente, sin duda por los permisos limitados del usuario que está conectado. Cuando abro un símbolo del sistema como administrador y ejecuto el comando, la tarea se crea correctamente, es visible con schtasks /query, visible en el programador de tareas y se ejecuta a la hora indicada.
Para terminar, no aparece ninguna ventana de DOS al inicio del equipo, ya sea antes o después de la autenticación del usuario.
Los scripts "máquinas" de inicio lanzados mediante GPO se inician como "local system", por lo que la tarea puede crearse sin problema.
Para terminar, no apareció ninguna ventana de consola durante el inicio del equipo, ya sea antes o después de la autenticación del usuario
Es normal, no se ven las ventanas de los startup scripts de máquina por defecto en win7. (bueno, a verificar, tengo dudas de todas formas).
En cuanto se pasa la autenticación de Usuario, la parte de máquina ha terminado de ejecutarse, por lo que nunca veremos los scripts de inicio de máquina después de ese instante.
-
Las pruebas no son lo bastante precisas para ver dónde falla.
Edita la línea con el comando schtask.
y añade al final esto:
schtask .................. >> C:\TEMP\testgpo.txt
Para ver el resultado ...
Si no hay nada en el archivo, sustituye la línea completa por una:
Veremos al menos si un simple echo funciona ...
Si eso aún no funciona, entonces es que la máquina no consigue ejecutar el script o bien no consigue encontrar el script en el Sysvol ...
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Para terminar, no apareció ninguna ventana de consola durante el inicio del equipo, ya sea antes o después de la autenticación del usuario
Es normal, no se ven las ventanas de los startup scripts de máquina por defecto en win7. (bueno, a verificar, tengo dudas de todas formas).
En cuanto se pasa la autenticación de Usuario, la parte de máquina ha terminado de ejecutarse, por lo que nunca veremos los scripts de inicio de máquina después de ese instante.
-
Las pruebas no son lo bastante precisas para ver dónde falla.
Edita la línea con el comando schtask.
y añade al final esto:
schtask .................. >> C:\TEMP\testgpo.txt
Para ver el resultado ...
Si no hay nada en el archivo, sustituye la línea completa por una:
echo test >> C:\TEMP\testgpo.txt
Veremos al menos si un simple echo funciona ...
Si eso aún no funciona, entonces es que la máquina no consigue ejecutar el script o bien no consigue encontrar el script en el Sysvol ...
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
¡Todo funciona!
Acabo de encontrar el origen del problema: ¡el nombre de mi archivo de script!
Lo había llamado script_coupure.bat y, al parecer, no le gusta el '_'.
Por otro lado, la redirección al archivo txt funcionó bien, salvo al principio porque no tenía una carpeta TEMP en la raíz de C:\. El archivo txt contiene "Operación exitosa: tarea programada creada".
Si he entendido bien las explicaciones anteriores, es preferible usar este método en lugar del que usa GPT, sobre todo si queremos volver a modificar el contenido de la tarea programada.
Aprovechando sus habilidades, me gustaría hacerle dos preguntas más sobre evoluciones que quiero aportar a mi infraestructura.
1) ¿Existe algún método para definir franjas horarias de conexión para mis usuarios que no sea tener que escribirlas una por una?
2) Los lectores de red de nuestros usuarios están mapeados de la forma antigua gracias a scripts netlogon definidos en cada ficha de usuario. ¿Es posible definirlos más o menos como acabas de hacer con el script de apagado programado? Si es así, ¿también es tan flexible como con el método antiguo?
En cualquier caso, gracias por ayudarme a resolver este problema.
Acabo de encontrar el origen del problema: ¡el nombre de mi archivo de script!
Lo había llamado script_coupure.bat y, al parecer, no le gusta el '_'.
Por otro lado, la redirección al archivo txt funcionó bien, salvo al principio porque no tenía una carpeta TEMP en la raíz de C:\. El archivo txt contiene "Operación exitosa: tarea programada creada".
Si he entendido bien las explicaciones anteriores, es preferible usar este método en lugar del que usa GPT, sobre todo si queremos volver a modificar el contenido de la tarea programada.
Aprovechando sus habilidades, me gustaría hacerle dos preguntas más sobre evoluciones que quiero aportar a mi infraestructura.
1) ¿Existe algún método para definir franjas horarias de conexión para mis usuarios que no sea tener que escribirlas una por una?
2) Los lectores de red de nuestros usuarios están mapeados de la forma antigua gracias a scripts netlogon definidos en cada ficha de usuario. ¿Es posible definirlos más o menos como acabas de hacer con el script de apagado programado? Si es así, ¿también es tan flexible como con el método antiguo?
En cualquier caso, gracias por ayudarme a resolver este problema.
Para el "_", es extraño, uso muy a menudo el underscore como separador en el nombre de mis scripts.
-
Para volver al método GPP:
Digamos que GPP tiene un comportamiento muy particular, sobre todo en función del contexto.
En ciertos contextos, una vez aplicado, el GPP no se volverá a aplicar, y esto incluso si se modifica el parámetro, para empujar una actualización a veces es problemático. Hay que eliminar el GPP cuando falla y volver a hacerlo.
Hay que revisar el contexto, por supuesto; cuando dije que el método sin GPP era mejor, era porque la persona también tenía Windows XP en su parque y no solo Windows 7 o 8...
GPP no se comprende de base en XP.
-
Hoy se recomienda usar GPP, eso sí, sobre todo cuando se tiene Windows 7 en puesto de cliente.
Cuidado con la utilización de la opción "Apply once and do not reapply" (Aplicar una vez y no volver a aplicar), es ahí donde cruje...
Invito de todas formas a volver a hacer lo mismo en GPP.
Usted pidió usar el método sin GPP ... así que respondí en función.
Hay algunas comparaciones hechas aquí: https://docs.microsoft.com/en-us/archive/blogs/
La noción de tatooing, por ejemplo... si quito mi parámetro, ¿el parámetro inicial se reposiciona? Con GPP, la respuesta es no ....
-
Digamos que modificar un script es bastante fácil ... sin embargo también tiene restricciones: hay que jugar con el hecho de que las máquinas lo ejecutarán al inicio (o al apagado)... y no "en vivo".
El scripting también tiene un aire de "antiguo" ... sin embargo algunos prefieren modificar una línea de código que hacer clic en 40 000 cosas.
-
1. No, hay que pegarse con cada cuenta, no se puede hacer por grupo. Pero se puede hacer selección múltiple de usuarios y configurarlos de una vez.
Por otro lado se puede escribir en PowerShell, pero no tengo tiempo para hacerlo, y nunca lo he hecho antes, pero no debería ser muy complicado.
Un señor muy amable ya lo hizo además:
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-Users-Logon-1bb4b1a2
Cuidado además, hay que configurar al lado el "forzamiento" de cierre de sesión del usuario llegada fuera de la hora.
https://www.rebeladmin.com/2014/06/use-of-group-policies-to-control-log-on-hours-to-the-network/
-
2. Euh sí y no.
Depende de las escuelas también, algunos prefieren como antes, otros no...
Se puede hacer muy bien por GPP el montaje de los lectores de red ;-)
Haz la prueba con GPP verás.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
-
Para volver al método GPP:
Digamos que GPP tiene un comportamiento muy particular, sobre todo en función del contexto.
En ciertos contextos, una vez aplicado, el GPP no se volverá a aplicar, y esto incluso si se modifica el parámetro, para empujar una actualización a veces es problemático. Hay que eliminar el GPP cuando falla y volver a hacerlo.
Hay que revisar el contexto, por supuesto; cuando dije que el método sin GPP era mejor, era porque la persona también tenía Windows XP en su parque y no solo Windows 7 o 8...
GPP no se comprende de base en XP.
-
Hoy se recomienda usar GPP, eso sí, sobre todo cuando se tiene Windows 7 en puesto de cliente.
Cuidado con la utilización de la opción "Apply once and do not reapply" (Aplicar una vez y no volver a aplicar), es ahí donde cruje...
Invito de todas formas a volver a hacer lo mismo en GPP.
Usted pidió usar el método sin GPP ... así que respondí en función.
Hay algunas comparaciones hechas aquí: https://docs.microsoft.com/en-us/archive/blogs/
La noción de tatooing, por ejemplo... si quito mi parámetro, ¿el parámetro inicial se reposiciona? Con GPP, la respuesta es no ....
-
Digamos que modificar un script es bastante fácil ... sin embargo también tiene restricciones: hay que jugar con el hecho de que las máquinas lo ejecutarán al inicio (o al apagado)... y no "en vivo".
El scripting también tiene un aire de "antiguo" ... sin embargo algunos prefieren modificar una línea de código que hacer clic en 40 000 cosas.
-
1. No, hay que pegarse con cada cuenta, no se puede hacer por grupo. Pero se puede hacer selección múltiple de usuarios y configurarlos de una vez.
Por otro lado se puede escribir en PowerShell, pero no tengo tiempo para hacerlo, y nunca lo he hecho antes, pero no debería ser muy complicado.
Un señor muy amable ya lo hizo además:
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-Users-Logon-1bb4b1a2
Cuidado además, hay que configurar al lado el "forzamiento" de cierre de sesión del usuario llegada fuera de la hora.
https://www.rebeladmin.com/2014/06/use-of-group-policies-to-control-log-on-hours-to-the-network/
-
2. Euh sí y no.
Depende de las escuelas también, algunos prefieren como antes, otros no...
Se puede hacer muy bien por GPP el montaje de los lectores de red ;-)
Haz la prueba con GPP verás.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Hola,
Con respecto al underscore, es la única cosa que cambié entre dos intentos, a menos que sea el hecho de modificar el contenido del script desde su carpeta de almacenamiento sin volver a pasar por la implementación realizada en la GPO...
Para mis próximas implementaciones, gracias por la información y los enlaces proporcionados, estoy descubriendo PowerShell y creo que va a ser un excelente caso práctico.
Una última pregunta sobre el funcionamiento de las GPO. En mi caso he creado una GPO que cambia configuraciones de la computadora. ¿Significa eso que, en la OU donde voy a aplicarla, su impacto afectará solo a las computadoras presentes en esa OU o también a los usuarios presentes?
Con respecto al underscore, es la única cosa que cambié entre dos intentos, a menos que sea el hecho de modificar el contenido del script desde su carpeta de almacenamiento sin volver a pasar por la implementación realizada en la GPO...
Para mis próximas implementaciones, gracias por la información y los enlaces proporcionados, estoy descubriendo PowerShell y creo que va a ser un excelente caso práctico.
Una última pregunta sobre el funcionamiento de las GPO. En mi caso he creado una GPO que cambia configuraciones de la computadora. ¿Significa eso que, en la OU donde voy a aplicarla, su impacto afectará solo a las computadoras presentes en esa OU o también a los usuarios presentes?
¿Significa esto que, en la OU en la que la voy a aplicar, su impacto afectará solo a los equipos presentes en esa OU o también a los usuarios presentes?
En efecto, únicamente sobre los equipos.
Cuando se configura la parte "ordenador" de una GPO, solo afectará a los ordenadores. (La misma reflexión con la parte "usuarios")
Luego se puede filtrar la aplicación de la GPO a una cierta población de ordenadores en esa misma OU, con grupos.
También se pueden usar filtros WMI para ser más finos, y que los grupos de AD no permiten.
Y por último hay un caso particular, una excepción.
Se puede efectivamente aplicar parámetros de usuario a ordenadores, se utiliza la funcionalidad llamada "loopback processing" (recirculación de bucle) - es bueno saberlo, pero cuando se empieza complica la comprensión.
Hay que tener esta noción en mente cuando llegue el momento.
-
Pequeño extra: durante el procesamiento de las directivas de grupo. Si la directiva contiene únicamente parámetros de Ordenadores (o de Usuarios), pero no ambos; se recomienda desactivar la aplicación de los parámetros que no se usarán.
Por ejemplo, tengo una GPO con solo parámetros de ordenadores, voy a desactivar la aplicación del lado de usuarios, esto se configura en la GPO en la ficha "Detalles", en "Estado de GPO" ; en este ejemplo pondré "Desactivar los parámetros de configuración de usuario".
Esto permite acelerar un poco la aplicación de las directivas, es decir, es menos lento.
Es muy explicativo en entornos muy grandes, eso sí. Pero sigue siendo una buena costumbre.
-
Otro punto: existe RSoP que permite verificar qué se aplica a una máquina/usuario. Es muy útil para depurar cuando una GPO se aplica mal, o cuando no se entiende qué está pasando.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772175(v=ws.11)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736424(v=ws.10)?redirectedfrom=MSDN
En efecto, únicamente sobre los equipos.
Cuando se configura la parte "ordenador" de una GPO, solo afectará a los ordenadores. (La misma reflexión con la parte "usuarios")
Luego se puede filtrar la aplicación de la GPO a una cierta población de ordenadores en esa misma OU, con grupos.
También se pueden usar filtros WMI para ser más finos, y que los grupos de AD no permiten.
Y por último hay un caso particular, una excepción.
Se puede efectivamente aplicar parámetros de usuario a ordenadores, se utiliza la funcionalidad llamada "loopback processing" (recirculación de bucle) - es bueno saberlo, pero cuando se empieza complica la comprensión.
Hay que tener esta noción en mente cuando llegue el momento.
-
Pequeño extra: durante el procesamiento de las directivas de grupo. Si la directiva contiene únicamente parámetros de Ordenadores (o de Usuarios), pero no ambos; se recomienda desactivar la aplicación de los parámetros que no se usarán.
Por ejemplo, tengo una GPO con solo parámetros de ordenadores, voy a desactivar la aplicación del lado de usuarios, esto se configura en la GPO en la ficha "Detalles", en "Estado de GPO" ; en este ejemplo pondré "Desactivar los parámetros de configuración de usuario".
Esto permite acelerar un poco la aplicación de las directivas, es decir, es menos lento.
Es muy explicativo en entornos muy grandes, eso sí. Pero sigue siendo una buena costumbre.
-
Otro punto: existe RSoP que permite verificar qué se aplica a una máquina/usuario. Es muy útil para depurar cuando una GPO se aplica mal, o cuando no se entiende qué está pasando.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772175(v=ws.11)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736424(v=ws.10)?redirectedfrom=MSDN
Acabo de leer vuestra respuesta anterior a una pregunta similar y me gustaría recibir algunas precisiones sobre la implementación del método 3, en particular sobre la cuenta que se debe usar para crear la GGP, y el contenido del script de verificación.