1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How long does your GPO take?

Discussion in 'Windows Server 2003 / 2008 / 2012 Exams' started by Jellyman_4eva, Aug 16, 2007.

  1. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Hi all,

    This is yet another odd one...

    The scenario is this, two OU's at the same level (i.e. not one nested inside the other) each with different policies set on them. If I move a computer from one OU to the other and then run gpupdate (Even with /force), it does not pick the new policies it should get from the new OU it is in. If I run gpresult it gives the new correct location of the computer object but then lists applied policies as the policies from the old OU!!

    If I wait a while (20-30 mins) and run gpupdate again it sorts itself out.. just wondering if others experience this delay?
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  2. g.vangemerden

    g.vangemerden Bit Poster

    33
    1
    17
    As far as I know, this is normal behaviour.

    Actually, i Don't know if it's normal, but is the same behaviour as I experience in almost every situation :D. Never found out why though...
     
    Certifications: See signature..
    WIP: MCITP:DBA - MCITP:SA - MCIPT:EA
  3. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Hi,

    Thanks for the reply... I am not sure if its normal or not to be honest, I have never really noticed it because any policies I have had to apply in the past have never really been time dependent, but I had one today which had to be done there and then, and whilst I made the change to the GPO, it did not actually get on the box until a fair while later...

    It should be noted that my question was really aimed at computer policies but I would be interested if anyone could test it with their networks to see whether it is normal. To be honest I expected gpupdate /force to make it pull down the correct policies straight away...
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  4. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    19,136
    462
    374
    Perhaps the computer move from one OU to the other takes a while to replicate amongst your DCs...
     
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!
  5. Sparky
    Highly Decorated Member Award

    Sparky Zettabyte Poster Moderator

    10,191
    299
    319
    Do you reboot the PC after you move it to another OU? Remember the computer part of the policy is picked up when the PC starts up.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) Security+ Network+ A+
    WIP: Exchange 2007\2010
  6. wagnerk
    Highly Decorated Member Award

    wagnerk aka kitkatninja Moderator

    10,831
    357
    341
    Don't know if this will help/explain your situation:
    Periodic Refresh Processing

    By default, Group Policy is processed every 90 minutes with a randomized delay of up to 30 minutes — for a total maximum refresh interval of up to 120 minutes.
    Group Policy can be configured on a per-extension basis so that a particular extension is always processed during processing of policy even if the GPOs haven't changed. Policy settings for each extension are located in Computer Configuration\Administrative Templates\System\Group Policy

    See here for the MS Page.

    -Ken
     
    Certifications: CITP, PGCert, BSc, HNC, LCGI, PTLLS, MCT, MCITP, MCTS, MCSE, MCSA:M, MCSA, MCDST, MCP, MTA, MCAS, MOS (Master), A+, N+, S+, ACA, VCA, etc... & 2nd Degree Black Belt
    WIP: PGDip
  7. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    I am not too sure about this one..

    Replication is something I have already looked at, and even if I force replication it still seems to take a while (DC's also have no replication errors).

    I was under the impression that a GPUPDATE /FORCE would push all policies onto the PC, both Computer and User based.

    The reason I find this all odd is that the PC immediately realizes it has been moved but takes a while to pick its new polcies from being moved...

    Can anyone test this for me at their workplace?
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  8. g.vangemerden

    g.vangemerden Bit Poster

    33
    1
    17
    Unfortunately not true

    From the MSPress 'Windows Group Policy Guide' (ISBN:0-7356-2217-5), page 80: "...some group policies are applied only when a user logs on or when a computer starts up."

    From the GPUPDATE-helpfile (GPUPDATE /?): '...An example is computeroriented software-installations."

    Thinking about how policies are processed, I might explain this behaviour:

    When a computer starts up or a user logs on, the computer checks whether the policies have changed since the last time it started up or the user logged on, or not. If not, there's nothing to do and the computer continues logging on, but if there are changes ALL the settings are evaluated again. Not just the changed policysettings.

    When you run GPUPDATE (without /FORCE) the computer checks if there are changed policysettings and if so, they are processed and applied.

    If you run GPUPDATE /FORCE the computer processes and applies all the policysettings associated wtih this computer.

    I don't know if its true, but what if the GPUPDATE command does not check if the computer is still in the same OU? Then it will only evaluate the previous settings form the previous OU and not the new settings from the new OU.

    I found this hard to believe, but it might explain it. When the policy refresh interval has passed, the computer checks if its still in the same OU, if not, it processes and applies all the new settings...

    Anyone wishes to shoot on this explanation?

    Guido
     
    Certifications: See signature..
    WIP: MCITP:DBA - MCITP:SA - MCIPT:EA
  9. drum_dude

    drum_dude Gigabyte Poster

    1,547
    46
    113
    Sparky asked whether you had rebooted/logged off....have you? Being an MCSE you should already know that Windows is loosely consistent. They maybe a replication issue - can you provide us all with more info? How many DCs you're running, is your workstation authenticating to the DC where the GP is being altered (type "set" at the command line to find out the logon server).

    I cannot test this in my work environment as it would most likely piss a few people off, but have tested it on my practice network. GPs apply as soon as I log off/on.
     
    Certifications: MCSA , N+, A+ ,ITIL V2, MCTS
    WIP: MCITP 2008 Ent Admin, Server Admin, Exchange 2010, Lync 2010, CCNA & VCP5
  10. Sparky
    Highly Decorated Member Award

    Sparky Zettabyte Poster Moderator

    10,191
    299
    319
    The user policy is applied when a user logs on and a computer policy is applied when the PC boots up.

    Move the PC into the OU with the GPO, *reboot* the PC, after you have logged on type gpresult at the command line and hopefully the policy will be listed.

    Also from what drum_dude has posted there may be other factors to consider depending on your network topology.
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) Security+ Network+ A+
    WIP: Exchange 2007\2010
  11. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    OK here is the scenario...

    3 DC's all linked in the same site running server 2003.

    No replication problems have been found in event viewer or replmon.

    None of the policies applied to the computer are software installation or any other kind that are known to be applied only at system startup.

    Workstation is authenticating to the server where the changes are being made.

    Let me just tweak a few bits and come back
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  12. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Hi all,

    Please please please forgive me. I have some seriously crap engineers here with me right now.

    For some reason they have not updated any of the DC's. Consequently none of them have any service packs applied. The only reason I checked this was because I found this little nugget:

    http://support.microsoft.com/default.aspx/kb/891630

    The workaround to this problem is to either reboot or wait 30 minutes (Which explains why they do get the policy eventually). I have just contacted Microsoft support to download the hotfix for XP and now lo and behold the moment you move a computer from one OU to another, run a GPUPDATE /FORCE all the policies are correctly sorted and applied....

    Now I shall roll some heads to find out exactly why they have not updated their servers. (And consequently update them)

    Sorry for the confusion and I hope someone uses this info!
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  13. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    19,136
    462
    374
    There are actually occasions where you *don't* want to update a server's OS... business-critical apps are awfully particular about the OS they're running on. Remember the huge problem many companies had when patching their XP installation with SP2? It's the same with server patches. So don't go beating up your co-workers unnecessarily... they might just have the right idea.
     
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!
  14. Sparky
    Highly Decorated Member Award

    Sparky Zettabyte Poster Moderator

    10,191
    299
    319
    The hotfix was included with SP1! :eek:

    You should kick their heads in mate :biggrin
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) Security+ Network+ A+
    WIP: Exchange 2007\2010
  15. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Unfortunately I am in agreement with Sparky in this instance. As the DC's host nothing but AD.

    Their heads shall duly be kicked in...

    If I do not reply for a few months I will probably have been arrested for server related GBH...
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  16. Sparky
    Highly Decorated Member Award

    Sparky Zettabyte Poster Moderator

    10,191
    299
    319
    Yup, I agree that service packs have to be tested before being rolled out. I still support a network running XP SP1 as they have some in-house training software that has not been upgraded to support SP2 :ohmy
     
    Certifications: MSc MCSE MCSA:M MCSA:S MCITP:EA MCTS(x5) Security+ Network+ A+
    WIP: Exchange 2007\2010

Share This Page

Loading...