GPO on remote stations not updating, though it says it is.

[edavid3001]

I have GPO's that are not applying at remote sites.

I have logged in as admin and done GPUPDATE /force and that completes.
When I run the GPMC tool, the station shows it has the current version
of these GPOs. I modify the GPO to give it a newer number, and run
GPUPDATE and GPMC reports the newer version. The stations has been
rebooting numerious times and days have passed since I started trying
to fix this issue.

But what GPMC is reporting is not true The old version of the GPO ran
a startup script with one name. The new version no longer runs that
script, it runs a different one. In the event logs the station
continues to try and run the old startup script.

I have set GpNetworkStartTimeoutPolicyValue on one of these stations to
200, but that doesn't help. I've have even removed from and added
back the station to the domain. You'd think that would do it, but
after adding it back it still trys to run the old GPO startup script.
Any ideas on what else to try?

 

[Dave Britt]

One of the most common group policy problems which produces hidden policies
or inconsistent results is when SYSVOL may not be replicating correctly.
Using the resource kit tool GPOTool is the best way to ensure that
replication of Group Policy is occurring

The utility will report all "Policies OK" if all Domain Controllers SYSVOLS
are up to date and current. It is worth considering scheduling this process
to occur and report early in the morning as a standard maintenance check.

SYSVOL replication or convergence can take some time in larger
organisations, however if the problem still remains after more than 24hrs
you need to start investigating the FRS service which is responsible for
replicating SYSVOL.

Start by using the sonar utility from the resource kit to see if it exposes
any errors with FRS. This tool interrogates the FRS service on all of your
Domain Controllers and reports back status and errors in a GUI tool. Then
start to investigate the error messages you find.

 

[edavid3001]

GPOTool reports everything as okay.

Some of these are GPO's that have been deleted but the stations
continue to run them. They launch scripts which were deleted along
with the GPO. These stations have been powered on, not just powered
on. These GPO's have been gone for weeks. ACL's are right. I've
manually checked all 3 servers.

I'm going to each station and doing a GPUPDATE /force which seems to be
helping. I'm tinkering with the GPO to force GPO's to be processed
every 90 minutes regardless of changes. But of course, to get that new
GPO I must first do a GPUPDATE /force.

These are WAN locations with 64Kb lines with multiple stations. Any
timeout settings I should be looking at on GPO processing?

 

[Gerry Hickman]

Hi,

One thing I didn't understand in your earlier post; you said (I think)
that "old" startup scripts were running instead of new ones, but surely
it would be easy to check the DCs (NETLOGON and SYSVOL) to see if the
scirpts were still there, and which version they were??

As I understand it, scripts are not cached on workstations, so it would
be impossible for an "old" script to run if you'd deleted it??

I assume you typed SET at the CMD prompt of the target workstations to
check the LOGON SERVER?

Can't you just set up a simple test policy (separate OU), to do
something really simple, then toggle it a few times and see if the
target workstation/user sees the changes (e.g. by phone)? Maybe start
with a user policy that changes the wallpaper, then add something for
the machine...

 

[edavid3001]

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Startup\0\0

value Script to launch
\\domain.com\sysvol\domain.com\etc......scriptname.bat

In this GPO I have modified it to run scriptname2.bat and deleted
scriptname.bat

These remote stations continue for weeks to run scriptname.bat and not
update to run scriptname2.bat. These scripts output to a file so I
can see that #2 is not running.

gpinventory.exe shows me machines that still have GPO's that have been
deleted for months. Or have versions many versions behind.

I installed the .net 1 framework on one of these machines as well as
the GPMC tool and did a local query. The local query showed that this
machine did have the correct version (2) of the GPO running the script
mentioned above. Yet the registry still had the old batch file. I
changed the GPO (something insignificant) and rebooted the PC and
waited. I saw version (3) and later (4) but still no update to the
machine registry.


gpupdate /force is giving mixed results. Sometimes it works and
sometimes it doesn't. It always says it completes fine.

Our Network guy is modifying the Cisco switches to enable Cisco Port
Fast which is also helping. Setting the gp timeout (mentioned above)
is helping some.

A number of these stations were initially created off the domain, so
they have the WMI isssue with "sharing and security model for local
accounts" which seems to apply somewhat here. I was getting access
denied running the GPO tool on some of these station. I fixed that,
but then I get a DCOM issue which I can't seem to fix.

I'd created a GPO to configure the Windows Firewall to allow our remote
control software to work many months ago. This explains why we still
can't remote into a number of stations.

 

[Gerry Hickman]

Hi edavid3001,

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Startup\0\0

value Script to launch
\\domain.com\sysvol\domain.com\etc......scriptname.bat

In this GPO I have modified it to run scriptname2.bat and deleted
scriptname.bat

These remote stations continue for weeks to run scriptname.bat

But how can the remote stations run it if you deleted it, and checked it
was deleted on the DC that logged on that specific workstation?

 

[edavid3001]

But how can the remote stations run it if you deleted it, and checked it

was deleted on the DC that logged on that specific workstation?

Exactly. That's the problem.

Here is an image of the script GPO as it currently exists.

http://static.flickr.com/65/178356192_05fda14736_o.jpg

So why are some of my remote stations still running the old script
specified in this GPO and not current script?

I've modified it to run the script from c:\ since the C:\ is up
regardless of network status, and the script is simply modifying files
on the c:\ drive thus not needing the network. This removes the Cisco
port fast issue and other Windows timing issues from the mix.