GPO Delay

[vttech]

How do I force a group policy that I added to my domain to implement right away? Their seems to be some delay in the implementation of a group policy that I added to one of my organizational units in active directory.

In this example I added a group policy to my Windows 2000 Domain Controller Server that runs a startup script (.vbs) when the computers boot.

Any ideas how to activate the group policy right away??

 

[Seaspray0]

To update a policy, you must refresh the policy on every computer you wish to have updated.

secedit.exe /refreshpolicy machine_policy /enforce
secedit.exe /refreshpolicy user_policy /enforce

Otherwise, the policy will be installed when the PC boots and the user logs on and also on a timed interval which you can set in group policy (default 45 min).

Start, Help. You'll be surprised what's there. A+/MCP/MCSE/MCDBA

 

[vttech]

OK, I tried that method but policy did not activate on the client and I even rebooted the PC with no luck. I know the script works because if I run it from one of the workstations in run perfect and I wait a day then the script works when the machine boot up

 

[Seaspray0]

Is the policy a machine or user policy?
Is the policy applied to an OU that has machines or an OU that has users?

Start, Help. You'll be surprised what's there. A+/MCP/MCSE/MCDBA

 

[ncotton]

i assume you mean as soon as you make a change to any of the settings.

Policies are affective on the client as soon as they run a policy update. By default a client waits 90 minutes, then an additional amount of time, which is randomly chosen between 0 and 30 minutes....that means that within a maximum of 2 hours, and changes should be in affect.

I don't have a station with me, but there are settings in the group policy under the Policies category, that lets you define a new standard for refresh cycles.

Login scripts wont help you, as the login it's self, envokes a policy refresh.

I don't really see why you have a need to (on a working network), have this functionality, you shouldn't really be changing the settings so offten that a 2 hour delay is affecting it. Again, this is only AFTER you have changed settings,

If you DO wish to force a policy, if you are at a terminal, Start > Run > gpupdate /force > ok. if you have changed machine configs, you will be asked to reboot, however, unless you have changed settings that run real time, i.e hardware config, your settings should be applied next time they are referenced.

If you wish to force a remote refersh of the policy, our friend, Sensei Mar-Elia of GPOGuy.com has this little tool for you.
Remote GP Update


Hope you found this post helpful

Neil J Cotton
njc Information Systems
Systems Consultant

 

[vttech]

Is the policy a machine or user policy?
It is a machine policy

Is the policy applied to an OU that has machines or an OU that has users?

Yes the Policy is applied to an OU that has machines in it.

 

[ncotton]

what are the policy settings you are looking to apply.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[vttech]

I am trying the script below that uninstalls windows default games that are installed on windows 2000 and XP workstations on the network..

Under

Group Policy --> Computer Configuration --> Windows Settings --> Scripts --> Startup

Set Shell = Wscript.CreateObject("WScript.Shell")
Set File = CreateObject("Scripting.FileSystemObject")

'---
'Returns the system root
Function root(sysroot)
     Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
     Set colOperatingSystems = objWMIService.ExecQuery ("Select * from Win32_OperatingSystem")
     For Each objOperatingSystem in colOperatingSystems
         sysroot = objOperatingSystem.WindowsDirectory
     Next
End Function

'---
'Remove games and MSN explorer
Function removeJunk()
         root(sysroot)
         Set objComponents = File.CreateTextFile("c:\components.txt",True)
         objComponents.WriteLine "[Components]"
         objComponents.WriteLine "freecell=off"
         objComponents.WriteLine "hearts=off"
         objComponents.WriteLine "minesweeper=off"
         objComponents.WriteLine "msnexplr=off"
         objComponents.WriteLine "pinball=off"
         objComponents.WriteLine "solitaire=off"
         objComponents.WriteLine "spider=off"
         objComponents.WriteLine "games=off"
         objComponents.Close
         shell.run "sysocmgr /i:" & sysroot & "\inf\sysoc.inf /u:c:\components.txt /x /q"
end function 

removejunk

 

[ncotton]

try it in a logon script, rather than start up...there is no delay...it just isn't working.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[netwalker1]

ncotton :
He said " I run it from one of the workstations in run perfect "

this means that it's working ..

try to use these commands from the server and client :
[red]secedit.exe /refreshpolicy machine_policy /enforce
secedit.exe /refreshpolicy user_policy /enforce
[/red]

Mohamed Farid
[green]Know Me No Pain , No Me Know Pain !!![/green]

 

[ncotton]

I know the script works, im talking about it is not working as a STARTUP Script. It's not a delay issue. A startup script will execute immediately (to some degree) it isn't something that needs to be refreshed as it is run remotely from the server at which the Policy points. A startup script is processed in the windows boot environment, before the user logs on, so you have no issues with delay. However, Im not gonna dive into the script, but if the script was to action something like removing items for a source location registered to a particular user, this will not work, as the the user that processes the Startup script is the System Account. Is there not a actual group policy setting for removing the games.

I'll have a look, if not, should be pretty easy to write a ADM extention for it.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[jwalker107]

The script may work fine, and your group policy object may be fine, but have you verified the COMPUTER can run the script based on the script's network location?

1) For computer startup scripts (and user script, for that matter) when building the GPO be sure to use a UNC path to the script, not a mapped drive letter. I.E. when building the policy object, use \\servername\sharename\script.vbs, not z:\script.vbs.

2) Ensure the computer account has appropriate permissions to read the \\servername\sharename\script.vbs file. A quick test is to try running under the computer account. You can do this using the AT command, assuming the "Scheduled Tasks" service is running. Open a command prompt, and issue the following command:
at 12:00 /interactive cmd /k
Replace "12:00" with a time within the next couple of minutes. When the time arrives, a new command window will open - this should be running under the context of the machine account ('echo %USERNAME%' should NOT give your name). In this command window, see if you can run
dir \\servername\sharename\script.vbs

3) If you can not get a directory listing, ensure that the share and NTFS permissions include "Everyone" or "Authenticated Users" ; for better security, you should use "Domain Computers" and "Domain Controllers" to specifically grant permissions only to the computer accounts. Repeat step 2 until you can get a directory listing including the script.

4) Once "dir" works correctly, try executing the script from your command window and ensure it runs correctly. In the case of VBScripts running from machine startup policies, I'm not sure whether it runs with "wscript" or "cscript" - you'll need to determine whether it makes a difference to you.