Applying folder redirection policies on a per-machine basis

Today I decided to change the way that my folder redirection policy was applied to my workstations.

Previously, it was the stock-standard folder redirection policy that was targeted to the OU containing my user accounts, however I wanted to have the ability to exclude some machines from this (I build a lot of virtual machines and don’t want folder redirection applying to these).

In order to achieve this, you’ll need to use loopback policy processing so you can apply the user configuration based on computer rather than user.

The two main ways of achieving this are by employing multiple OU’s (my least favourite) or by using security groups. I prefer security groups, because it means you can have one group that contains all of the machines to which folder redirection should be applied, without needing to create a seperate OU in every location/office/branch you may have.

The OU method

1. Generally, you’d want to create a sub-OU under the OU that contains your computer accounts. You might want to call this something like “Folder Redirection Enabled Computers” or whatever makes you happy.

2. Create a policy, and configure your folder redirection settings to your liking, and then under Computer\Administrative Templates\System\Group Policy, enable the setting “User Group Policy loopback processing mode” and set it to “Merge”

3. Now add the machines that you want to apply the folder redirection to, to the OU you created with the policy linked

The security group filtering method

1. Create a security group called something like “Folder Redirection Enabled Computers” and add all of your required machines to this group

2. Create a new policy, and remove Authenticated Users under the Security Filtering tab, then add Domain Users and the group you created in the above step

3. Edit the policy configuring your folder redirection settings to your liking, and then under Computer\Administrative Templates\System\Group Policy, enable the setting “User Group Policy loopback processing mode” and set it to “Merge”

4. Link the policy to the OU that contains your computer accounts

As I mentioned, I prefer the use of security group filtering for this purpose, because I find it more scalable – You just link the policy to the OU(s) that contain your computer accounts, and add the computers to actually apply folder redirection settings to your custom group.

Note that you do need to ensure that the user account can read the policy as well, even though with loopback policy processing, it will be applied based on the computer account. This is because the policy passes through the user security filter to, so if you don’t have Domain Users added to the security filter (or at least a group that will contain the user(s) logging on to your desired machines) then the policy won’t apply.

In Windows 7, there is a fair level of detail in both the Application event log, as well as the dedicated Folder Redirection event log, so I recommend watching these logs remotely during a logon to make sure everything is behaving the way you expect it to.

The “Open File – Security Warning” message box when running some SCCM advertisements

This is just a quick post for an issue I encountered quite a while ago (this article has been in my drafts since September last year, so I hope I am recalling the details correctly).

Basically, I had a stock-standard advertisement targeted to my machine for testing. The advertisement program pointed to an installer, which when it ran, throws up an “Open File – Security Warning” message box. Obviously you’d typically see this for non-trusted sources, such as network locations and downloaded files, however this was sitting on a trusted UNC path where all programs are targeted, and this issue had never occurred before.

After some brief digging, I found that the message would only appear if the FQDN was used to call the program, but the NetBIOS name was fine. Unfortunately, SCCM uses the FQDN for it’s advertisements, and therefore I had to work out what was going on.

In short, after a bit of Process Monitor use, it appeared that the issue was actually with the .exe making a call to another setup program, which was the actually setup program to install the application. When I found this, I didn’t bother digging any further to find out exactly what was going on, because updating the program to point to the setup program that the original .exe was calling fixed the problem.

So if you have this issue, maybe see if the .exe you’re targeting is just a stub for another setup program, and just target that directly.