Gpupdate /force

09/01/2008 - 18:25 por CSL | Informe spam
Hola

Os cuento de forma resumida. Tengo dos OUs: OU1 y OU2 y dos políticas de
grupo enlazadas: GP1 y GP2 respectivamente. Para simplificar GP1 oculta el
comando Ejecutar en el menú inicio y GP2 lo muestra.

Tengo un equipo, E1, en la GP1 y, por tanto, no muestra el comando ejecutar.
Muevo E1 a GP2 y en E1 ejecuto gpupdate /force para actualizar las políticas
y ue me muestre el menú Ejecutar. No funciona. Compruebo con gpresult y con
GPMC que la política que se aplica a E1 es la GP1.

Es como gpedit / force no fuera capaz de actualizar las políticas. Al rato,
y por si solo, E1 muestra el menú Ejecutar (supongo que en el intervalo por
defecto de refresco de políticas).

Qué puedo mirar para saber qué problema hay con gpupdate /force ?

Nota: lo que hacen las políticas tienen que ver con la seguridad, había
leido que en ese aspecto el comportamiento es diferente.

Gracias y un saludo

Carmelo

Preguntas similare

Leer las respuestas

#6 CSL
10/01/2008 - 18:18 | Informe spam
Sí que funciona porque la directiva Default Domain Policy se bloquea. El
usuario que quiero dar de alta es un usuario local, no de AD. Si no bloqueo,
las cuentas locales que se crean nuevas también han de cumplir los
requisitos de la política de dominio. Al bloquearlo me lo salto. Está claro
que si fueran usuarios de AD esto no me serviría.

Gracias.

"Guilermo Delprato [MS-MVP]"
escribió en el mensaje news:
Vamos por partes, el tema de la directiva de contraseña no va a funcionar
como propones. Todo lo que sea Account Policies hay *una sola* en todo el
dominio, y es la que se fija en la Default Domain Policy. No te va a
servir cortar la herencia tampoco, porque las cuentas están en el dominio,
no en la máquina.
Si enlazas una GPO a una OU, donde defines Account Policies entonces esas
configuraciones se aplicarán a las *cuentas locales* del equipo afectado.
Quizás por ahí tengas un principio de solución, siempre y cuando los
usuarios puedan inicar sesión con una cuenta local, no del dominio.

El tema del cacheo de la ubicación de la cuenta de máquina entiendo se
hace sólo durante el inicio de sesión *del equipo*, no del usuario. Por
eso la sugerencia de reiniciar el equipo.
Aunque por otro lado hay que tener en cuenta que un XP, por omisión,
utiliza siempre que pueda "cached-credentials", con lo cual puede ser que
requiera dos reinicios inclusive.

No tengo idea si es un parámetro modificable :-(


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no rights.
You assume all risk for your use.



"CSL" wrote in message
news:

Gracias Guillermo

Sé que no están pensadas las GPO para lo que quiero hacer. El tema es que
necesito añadir un usuario con contraseña no compleja en un equipo que
pertenece a un dominio en el que está implementada una política de
contraseñas complejas. Para ello se me ocurrió pasar el equipo a una OU
con la herencia bloqueada. La primera vez que lo intenté me salió bien a
la primera, seguramente porque coincidió el refresco de la caché. Ayer ya
no me funcionó y lo que quería evitar era reiniciar el equipo, por las
razones que ya comenté.

También puedo bloquear temporalmente la herencia de GPOs en la OU
original. Eso es más rápido pero tiene el efecto de reinicializar. Por
ejemplo, los ordenadores vuelven a aparecer como "Equipos sin asignar" en
la consola de WSUS.

Ahora ya por curiosidad ¿En qué momento se cachea el nombre distintivo?
Al iniciar la máquina, y después ? Es posible forzarlo de alguna forma
(por ejemplo reparando la red en el caso de los XP) ? El caso es que
llega un momento en que se refresca pero para lo que queríamos hacer el
intérvalo era demasiado grande como para que nos resultara práctico.

Gracias por la información.

csl



"Guilermo Delprato [MS-MVP]"
escribió en el mensaje
news:%
Lo de "la máquina "cachea"" está justamente relacionado con "nombres
distinguidos" que en realidad sería mejor "nombres distintivos"

Si escribo un nombre distintivo, creo que aclarará mejor el tema.
Suponiendo que la máquina se llama E1, y están en una OU qie se llama
Equipos, en un dominio test.net, entonces el nombre distintivo es:
cná,ou=Equipos,dc=test,dc=net

Fíjate que es justamente el nombre del objeto, y da su posición dentro
del dominio. Es como si fuera el PATH de un archivo, sólo que acá se
hace en sentido inverso

Por el artículo que haz encontrado, evidente MS ofrece un parche, por lo
que no está disponible en las actualizaciones, sino que tienes que
solicitarlo. Esto lo hace cuando todavía no está totalmente probado (el
parche). En el mismo artículo te da como conseguirlo. Normalmente mandas
un mail y te dan las instrucciones de descarga, todo en forma gratuita.

Lo que me parece a mí :-) es que estás queriendo usar las GPOs para algo
para lo que no fueron diseñadas: que una configuración esté de un modo u
otro en determinados momentos sin que el usuario reinicie sesión :-)
Lo cual no significa que no se pueda hacer.
Pero por lo que veo, la única opción va a ser solicitar el parche
correspondiente


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights. You assume all risk for your use.



"CSL" wrote in message
news:
Hola Guillermo

Efectivamente, si reinicio se aplica al momento. El caso es que no
puedo reiniciar porque se trata de máquinas que capturan video de forma
continua. A las malas lo haría pero sería la última opción.

No acabo de entender qué significa eso de que la "máquina cachea la
ubicación que tiene en el AD por un tiempo". Desde luego es más de
media hora. Es posible cambiar ese valor ? O hay alguna manera de
forzar a que lo comprueba de forma manual ?

También he leido, en relación a lo que dices, que hay un parche para XP
y W2003 en este artículo

http://support.microsoft.com/kb/891630/en-us

También habla de la caché de nombres distinguidos no está actualizada
pero no acabo de entender ni que es ni como afecta en este caso.
Además, entiendo que si el sistema operativo está al día de
actualizaciones (y estos lo están) el parche no debería ser necesario.
Otra cosa es que el comportamiento es el mismo en todos los equipos y
también pasa con los Windows 2000. He intentado conseguir el parche
pero espero que no vengan por aquí los tiros.

Gracias Guillermo



"Guilermo Delprato [MS-MVP]"
escribió en el mensaje
news:%
No es un problema de actualización de GPOs, sino que la máquina
"cachea" la ubicacion que tiene en el AD por un tiempo. Si no recuerdo
mal ;-) revisa cada 30 minutos si fue cambiada de OU. Esto es lo que
te está afectando.

Supongo que si reinicias se aplicará en el momento.


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna
clase,y no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights. You assume all risk for your use.



"CSL" wrote in message
news:
Hola

Os cuento de forma resumida. Tengo dos OUs: OU1 y OU2 y dos políticas
de grupo enlazadas: GP1 y GP2 respectivamente. Para simplificar GP1
oculta el comando Ejecutar en el menú inicio y GP2 lo muestra.

Tengo un equipo, E1, en la GP1 y, por tanto, no muestra el comando
ejecutar. Muevo E1 a GP2 y en E1 ejecuto gpupdate /force para
actualizar las políticas y ue me muestre el menú Ejecutar. No
funciona. Compruebo con gpresult y con GPMC que la política que se
aplica a E1 es la GP1.

Es como gpedit / force no fuera capaz de actualizar las políticas. Al
rato, y por si solo, E1 muestra el menú Ejecutar (supongo que en el
intervalo por defecto de refresco de políticas).

Qué puedo mirar para saber qué problema hay con gpupdate /force ?

Nota: lo que hacen las políticas tienen que ver con la seguridad,
había leido que en ese aspecto el comportamiento es diferente.

Gracias y un saludo

Carmelo





















Respuesta Responder a este mensaje
#7 Guilermo Delprato [MS-MVP]
10/01/2008 - 19:04 | Informe spam
Eso mismo, las account policies aplicadas a la OU se aplican sólo a cuentas
locales

Lo que no es de imaginar es que teniendo dominio se usen cuentas locales de
usuarios ;-)


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y no
otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no rights.
You assume all risk for your use.



"CSL" wrote in message
news:

Sí que funciona porque la directiva Default Domain Policy se bloquea. El
usuario que quiero dar de alta es un usuario local, no de AD. Si no
bloqueo, las cuentas locales que se crean nuevas también han de cumplir
los requisitos de la política de dominio. Al bloquearlo me lo salto. Está
claro que si fueran usuarios de AD esto no me serviría.

Gracias.

"Guilermo Delprato [MS-MVP]"
escribió en el mensaje news:
Vamos por partes, el tema de la directiva de contraseña no va a funcionar
como propones. Todo lo que sea Account Policies hay *una sola* en todo el
dominio, y es la que se fija en la Default Domain Policy. No te va a
servir cortar la herencia tampoco, porque las cuentas están en el
dominio, no en la máquina.
Si enlazas una GPO a una OU, donde defines Account Policies entonces esas
configuraciones se aplicarán a las *cuentas locales* del equipo afectado.
Quizás por ahí tengas un principio de solución, siempre y cuando los
usuarios puedan inicar sesión con una cuenta local, no del dominio.

El tema del cacheo de la ubicación de la cuenta de máquina entiendo se
hace sólo durante el inicio de sesión *del equipo*, no del usuario. Por
eso la sugerencia de reiniciar el equipo.
Aunque por otro lado hay que tener en cuenta que un XP, por omisión,
utiliza siempre que pueda "cached-credentials", con lo cual puede ser que
requiera dos reinicios inclusive.

No tengo idea si es un parámetro modificable :-(


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights. You assume all risk for your use.



"CSL" wrote in message
news:

Gracias Guillermo

Sé que no están pensadas las GPO para lo que quiero hacer. El tema es
que necesito añadir un usuario con contraseña no compleja en un equipo
que pertenece a un dominio en el que está implementada una política de
contraseñas complejas. Para ello se me ocurrió pasar el equipo a una OU
con la herencia bloqueada. La primera vez que lo intenté me salió bien a
la primera, seguramente porque coincidió el refresco de la caché. Ayer
ya no me funcionó y lo que quería evitar era reiniciar el equipo, por
las razones que ya comenté.

También puedo bloquear temporalmente la herencia de GPOs en la OU
original. Eso es más rápido pero tiene el efecto de reinicializar. Por
ejemplo, los ordenadores vuelven a aparecer como "Equipos sin asignar"
en la consola de WSUS.

Ahora ya por curiosidad ¿En qué momento se cachea el nombre distintivo?
Al iniciar la máquina, y después ? Es posible forzarlo de alguna forma
(por ejemplo reparando la red en el caso de los XP) ? El caso es que
llega un momento en que se refresca pero para lo que queríamos hacer el
intérvalo era demasiado grande como para que nos resultara práctico.

Gracias por la información.

csl



"Guilermo Delprato [MS-MVP]"
escribió en el mensaje
news:%
Lo de "la máquina "cachea"" está justamente relacionado con "nombres
distinguidos" que en realidad sería mejor "nombres distintivos"

Si escribo un nombre distintivo, creo que aclarará mejor el tema.
Suponiendo que la máquina se llama E1, y están en una OU qie se llama
Equipos, en un dominio test.net, entonces el nombre distintivo es:
cná,ou=Equipos,dc=test,dc=net

Fíjate que es justamente el nombre del objeto, y da su posición dentro
del dominio. Es como si fuera el PATH de un archivo, sólo que acá se
hace en sentido inverso

Por el artículo que haz encontrado, evidente MS ofrece un parche, por
lo que no está disponible en las actualizaciones, sino que tienes que
solicitarlo. Esto lo hace cuando todavía no está totalmente probado (el
parche). En el mismo artículo te da como conseguirlo. Normalmente
mandas un mail y te dan las instrucciones de descarga, todo en forma
gratuita.

Lo que me parece a mí :-) es que estás queriendo usar las GPOs para
algo para lo que no fueron diseñadas: que una configuración esté de un
modo u otro en determinados momentos sin que el usuario reinicie sesión
:-)
Lo cual no significa que no se pueda hacer.
Pero por lo que veo, la única opción va a ser solicitar el parche
correspondiente


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna
clase,y no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights. You assume all risk for your use.



"CSL" wrote in message
news:
Hola Guillermo

Efectivamente, si reinicio se aplica al momento. El caso es que no
puedo reiniciar porque se trata de máquinas que capturan video de
forma continua. A las malas lo haría pero sería la última opción.

No acabo de entender qué significa eso de que la "máquina cachea la
ubicación que tiene en el AD por un tiempo". Desde luego es más de
media hora. Es posible cambiar ese valor ? O hay alguna manera de
forzar a que lo comprueba de forma manual ?

También he leido, en relación a lo que dices, que hay un parche para
XP y W2003 en este artículo

http://support.microsoft.com/kb/891630/en-us

También habla de la caché de nombres distinguidos no está actualizada
pero no acabo de entender ni que es ni como afecta en este caso.
Además, entiendo que si el sistema operativo está al día de
actualizaciones (y estos lo están) el parche no debería ser necesario.
Otra cosa es que el comportamiento es el mismo en todos los equipos y
también pasa con los Windows 2000. He intentado conseguir el parche
pero espero que no vengan por aquí los tiros.

Gracias Guillermo



"Guilermo Delprato [MS-MVP]"
escribió en el mensaje
news:%
No es un problema de actualización de GPOs, sino que la máquina
"cachea" la ubicacion que tiene en el AD por un tiempo. Si no
recuerdo mal ;-) revisa cada 30 minutos si fue cambiada de OU. Esto
es lo que te está afectando.

Supongo que si reinicias se aplicará en el momento.


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna
clase,y no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights. You assume all risk for your use.



"CSL" wrote in message
news:
Hola

Os cuento de forma resumida. Tengo dos OUs: OU1 y OU2 y dos
políticas de grupo enlazadas: GP1 y GP2 respectivamente. Para
simplificar GP1 oculta el comando Ejecutar en el menú inicio y GP2
lo muestra.

Tengo un equipo, E1, en la GP1 y, por tanto, no muestra el comando
ejecutar. Muevo E1 a GP2 y en E1 ejecuto gpupdate /force para
actualizar las políticas y ue me muestre el menú Ejecutar. No
funciona. Compruebo con gpresult y con GPMC que la política que se
aplica a E1 es la GP1.

Es como gpedit / force no fuera capaz de actualizar las políticas.
Al rato, y por si solo, E1 muestra el menú Ejecutar (supongo que en
el intervalo por defecto de refresco de políticas).

Qué puedo mirar para saber qué problema hay con gpupdate /force ?

Nota: lo que hacen las políticas tienen que ver con la seguridad,
había leido que en ese aspecto el comportamiento es diferente.

Gracias y un saludo

Carmelo

























email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida