Files Preferences FAQ

Group Policy Files CSE allows SysAdmins to ensure file(s) exist on clients when logging into the domain. If you’ve never used it before, you can beat your head against the wall, so learn from my mistakes / tributions with setting this up.

What is it?

The Files Preferences Client Side Extension (CSE) is similar to a Group Policy, but deals with Files in a CRUD manner… Meaning you can either Create, Replace, Update or Delete files.

Typically, I’d create the file, then create the Files preference to copy that file where I want it to all the computers in my organization. This works great, when it works. My method was not working correctly, until I figured out why.

The Files CSE requires that the file(s) be accessible in the context the Preference is set, and the location to write to is writeable. For example, if you set a User Configuration policy to apply this preference, the file operation runs as the user - not as an administrator.

Sounds simple… What messed up?

One of my favourite features in Windows 7+ is being able to Shift+Right-click a file/folder, and choose Copy as path. I am constantly using this technique with many terminal windows open.

When I was helping another tech, I went through much of the troubleshooting we typically do on the client machines:

• Running gupdate.exe /force
• Ensuring the Group Policy was set on the logon server
• Ensuring the policy applied at the user level (vs Computer)
• Ensuring the user could access the file location to read
• Ensuring the user could create files in the location mentioned
• Run a gpresult.exe /h gpresult.html and viewing the report as to why it doesn’t work

So the error is right in our face! But with very little description. Errors for a few different files, all in the 0x8007xxxx range. Google didn’t have much information, other than trying to skip that, and create copying scripts during login.

Could it be a machine issue…?

So we all know that permissions can be complicated, and Group Policy helps people understand that. Computer Configurations happen with the local SYSTEM user running the command; User Configurations happen with the user it applies to.

If the user does not have access to a file location, how can a User Configuration edit a file or location? If a Computer Configuration needs to run a script from a folder it does not have access to, that causes issues too.

So let’s look at locations that are readable by all on the domain: The netlogon and SysVol folders. Could we use these folders?

The netlogon folder is not used for anything by default, but all the computers/users have read access. This seems perfect, and it replicates between my Domain Controllers.

In the NT4-style Samba domains I manage, we use netlogon for scripts and programs that all users need to be able to read at any time. With this reasoning, let’s vote on netlogon for my organization.

I make sure, as the Domain Administrator, that I do not edit the permissions on netlogon. There should be no reason to, and it could potentially break the domain. The netlogon folder is expected to be a trusted, authenticated connection, meaning I need to ensure the source stays secure and locked down.

As the Domain Administrator, I copy any files or scripts that everyone needs access to, here. I keep the folder as small as possible, so small files and scripts are all that live here.

Since I know the user logging in can copy the files, and the computer can read it, things should just copy. Again, this troubleshooting didn’t help much. It is as if the computer just doesn’t know what to do with the file… I think?

So why don’t you use scripts?

First off, changing from an NT-style domain to an Active Directory domain, I wanted to do Best Practises with my domains. I don’t have any scripts that run, only Group Policy objects.

The Files CSE is great for single files, but it would be overkill and overhead to have a script which has the sole purpose of copying one file during logon or startup.

I wanted the Files CSE to work as I expected, and I was beating my head against the wall! See if you can see the issue with my policy:

Now that I know the issue, I can fix it. For those who don’t, try reading the XML file it generates:

<?xml version="1.0" encoding="utf-8"?>
<Files clsid="{215B2E53-57CE-475c-80FE-9EEC14635851}">
  <File clsid="{50BE44C8-567A-4ed1-B1D0-9234FE1F38AF}" name="Word.officeUI" status="Word.officeUI" image="1" userContext="1" bypassErrors="1" changed="2018-12-05 00:40:22" uid="{409CA71D-88C9-483F-A469-9C1C01DE0B09}">
    <Properties action="R" fromPath="&quot;\\domain.example.com\netlogon\Word.officeUI&quot;" targetPath="C:\Users\%username%\appdata\Local\Microsoft\Office\Word.officeUI" readOnly="0" archive="1" hidden="0" suppress="1"/>
  </File>
</Files>

See the error above? There is the HTML entity for quotation marks inside the quotation marks! I removed those codes in the fromPath= variable, and it started copying the file correctly!

Where’d you find that XML file?

All Group Policy Objects are stored in the SYSVOL for your domain. Inside the SYSVOL folder is a folder called Policies, where all your Group Policies are located, in folders identified by the policy’s GUID. For example:

sysvol/
└── domain.example.com
    ├── Policies
    │   ├── {1BB27E6A-F09A-4D8B-9273-76C469CD322C}
    │   │   ├── GPT.INI
    │   │   ├── Machine
    │   │   └── User
    │   │       └── Preferences
    │   │           └── Drives
    │   │               └── Drives.xml
    │   ├── {31B2F340-016D-11D2-945F-00C04FB984F9}
    │   │   ├── GPT.INI
    │   │   ├── MACHINE
    │   │   └── USER
    │   ├── {36FBD859-558A-4647-BB68-FD3FED55C82E}
    │   │   ├── GPT.INI
    │   │   ├── Machine
    │   │   └── User
    │   │       └── Preferences
    │   │           └── Shortcuts
    │   │               └── Shortcuts.xml

(Output created with the tree command)

So each of those Client Side Extensions create .XML files that you can easily load in a text editor and read anytime you want!