Does the "File Extension" in the Group Policy Preferences even work??

[jbeverid]

I've been trying to use Group Policy to simply replace one text file with another. So I created a policy under "Computer Configuration", then "Preferences", "Windows Settings", and finally "Files". I point to a test text file on the root of the C drive of the Domain Controller as the source file, I then give it a path on the destination workstation where I've also created a text file (also on the root of the C drive of the worksation). And I set the action to "Replace". By the way this is all virtualized and none of these are production machines!

The result is that NOTHING happens. I have OTHER group policies applying to this workstation with no problem, even within the same policy. So I know it isn't a matter of permissions to the policy or a problem with the scope. In the event log I get an error that says that:

The computer 'myfile.txt' preference item in the 'Replace file {7CC62DC3-6A5E-407C-9B6F-10F6D47A0D6A}' Group Policy object did not apply because it failed with error code '0x80070005 Access is denied.' This error was suppressed.

"Myfile.txt" is the name of both the source file (on the domain controller) and the name of the destination file. At first I thought I had figured out the source of the problem in that a Microsoft article says that the source file should be listed how the CLIENT workstation would refer to it. So instead of listing the source file as "c:\myfile.txt" I changed it to "\\dcname\sharename\myfile.txt". And I KNOW that the workstation can open this with this UNC path because I can manually do it. However still no dice...It still gives the same error message.

Has ANYONE ever gotten this "File Replace" preference to work? Am I doing anything that is obviously wrong? Thanks!

[scottzaiss]

Is this set in the User or Computer config? If it is in Computer, the only way I was able to get it to work was to put the file in the GPO folder itself on SysVol (did not like doing that but it works). The problem with a file on a server has something to do with the system account being used not having rights to network resources and the account isn't changable. If the local users have rights to change the file locally (mine didn't), then it may be easier to put the setting in the User Config area. Be sure to check 'Run in logged-on users security context'.

I hope this helps.
Scott

[jbeverid]

Thanks for responding scottzaiss. I WAS using the "Computer Configuration". I took your suggestion and tried using the "User Configuration" and checked "'Run in logged-on users security context". It still doesn't work and gives me the same error message (I've rebooted and ran a gpupdate /force several times). The user account I am logging in with definitely has rights to the text file on the server (I can open it directly by typing in the UNC path). And this user account also is included in the scope of the policy.

I will try putting the file in the "sysvol" share and see if I can get that to work.

Not to rant but this is what keeps a lot of sys admins from using Group Policy. Microsoft make it look SO EASY, but it never is. There seem to always be ten caveats to getting a policy to work the way it is intended!

[jbeverid]

In my virtualized environment I tried putting the replacement file in the "SysVol" and the policy still failed to replace the file, however no error message in the event viewer this time. So just to rule out a problem with my virtualized domain I tested the policy outside of my virtual environment and put my actual workstation on a test OU with this policy. I used the "User Configuration" policy like scottzaiss suggested and checked the box for "Run in logged-on users security context". And to my surprise it WORKED!

I can't imagine why it won't work in my virtualized environment (I'm using VMWare Player and have a Win 2008 R2 Server domain controller and a Win 7 Workstation set up). At this point though I'm just glad I got it to work in ANY environment! Anyway I want to thank "scottzaiss" for his help. I wouldn't have thought of his point about running the policy in "Computer Configuration" causing a problem of accessing a server where the file was located because the account was running in the workstation's system context.