The Geekorium

As part of my Group Policy Rewrite I’m attempting to make use of Folder Redirection which lets you specify where common important Windows folders reside on the network.

Normally when you first log on, Windows makes a few folders under your user document folder for things such as Music, Favourites¹ , Downloads etc. On a standalone machine these are usually stored under your user profile folder (C:\Users\{username}\Downloads in Win 7 for example) but they can be moved when you’re on a network².

In Group Policy, expand User Configuration > Policies > Windows Settings > Folder Redirection. Right click on one of the folders listed and select “Properties”. Documents is a good place to start, as I’ll show you how all the others can hang off that.

If you’ve worked with group policy before I won’t insult your intelligence more by explaining everything in here, suffice to say that in our environment, I’ve chosen to use the settings as shown below:

Settings for redirecting My Documents to a shared network location.

For all the other folders I redirect, I use the same settings on the right there, and only change the Target folder location property on the left.

What this does is specify that you want all the users folders redirected to what you’ve specified in the Home folder property for the user in Active Directory (usually H: somewhere on your network). This is I suspect how most admins configure their document folders. The issue comes with the other folders later on. Lets work with the Desktop folder for example.

To redirect the Desktop, you again access the properties of that folder. This time, you’ll notice you lose the option to “Redirect to the user’s home folder”. This is fair enough, as we don’t want every folder type pointing to the same location. Unfortunately though, Microsoft don’t offer a simple way to redirect to a subfolder of the new Documents location, although they do suggest this:

The USERNAME variable may be used as part of the redirection path, > thus allowing the system to dynamically create a newly redirected > folder for each user to whom the policy object applies.

Folder Redirection feature in Windows KB Article.

What they are suggesting is using \\server\share\USERNAME\Desktop to specify the location, but what if your AD structure is more complicated than that? For instance, we have our year levels separated into folders to make it easy for teachers to locate a certain kid’s work. There just isn’t a variable to insert a specific folder into this path based on the user’s location or position in AD - ie. you can’t use \\server\share\groupfolder\username\Desktop as it just doesn’t exist.

The next logical step was to try inserting the mapped drive into this field: “H:\Desktop”. The problem here was that at the point that the logon process connects to the desktop, the H: has not yet been mapped, leaving a blank desktop and an error in the Application log. It was at this point a few years ago I gave up. Until this week.

Lucky for us!

When you view the GP report for Folder Redirection you’ll notice that MS includes the VARIABLES that it uses to fill in the user’s home folder path (as shown):

AH! Variables!

In my initial tests, I set the Target folder location to “Redirect to the following location”, and the Root Path: to “HOMESHAREHOMEPATH\Desktop”. This did NOT work. I can’t remember the error exactly, and I think it may not have even mapped at all.

My next test was to try with “HOMESHARE\Desktop” and lo-and-behold, it worked! Now when a user logs in they get a H Drive, and a desktop that routes to a folder in that drive, regardless of the path the user data is in. If they inadvertently save something to their desktop³ it will be securely tucked in their home drive where they can find it again later, or on their desktop the next time they log in.

Going through the rest of the folders in Folder Redirection I did the same (except for the Start Menu, although I suspect this will work exactly the same way). Now all my data is secure in my home drive, without using true roaming profiles (which can end up pulling a lot of data around the network in a school environment).

Some caveats

Even after multiple iterations and rewrites, Adobe software still cannot handle expanded network paths for saving application data. If you redirect AppData to “HOMESHARE\AppData” even something as new as Adobe Photoshop CS4 refuses to load. The only solution I have found for this is to use “H:\AppData” or nothing at all for that folder. This seems to work acceptably for the AppData folder, even though it doesn’t for the Desktop.

Wrong! H:\AppData has the same problem outlined above, that is, H is only mapped after folder redirection. Instead I followed the advice on this Adobe Getsatisfaction page by Ge3oR who suggested giving users permission to c:\users\USERXX\appdata\Locallow, which for some reason Adobe products need, but cannot create themselves. So in GP I added a Folder rule in GP Preferences to create a folder in C:\users\username\appdata\Locallow, and everything is working, and I have redirected AppData once more!

Also! I haven’t actually tested this extensively in a production environment (although it works day-to-day on a couple of test desktops), so test this with your apps and bits before making these changes wholesale to your network.

I’ve also found while writing this post⁴ that this information is included in part in Microsoft’s Managing Roaming User Data Deployment Guide.doc found here. As I wasn’t using roaming profiles I didn’t read it. Plus it’s unclear as to the best way to redirect and I still would have written this post to clear it up for you.

I hope this tip can help you get Folder Redirection working for you if your environment is a bit unusual. Let me know what you find!

I’ve been sorting through our group policies and rewriting them ready for a switch over to Windows 7. During my thorough investigation it turns out our current policies overlap a fair bit, and it’s no wonder we have trouble tracking down why something we’re sure we’ve set in GP turns up unset on logon¹ .

So my big project has been going through our settings one by one, and deciding which of these categories they fall into:

1. Common Computer settings - all the computers should get these as they are vital to the function of the network, or are likely to break something if they aren’t explicitly set for our staff and students.
2. Common User settings - everything else that just can’t be set in the Computer policy.
3. Staff Settings
4. Student Settings
5. Printers

The interesting trick I’ve learned about the printer GPs though is how to apply printers based on the computer’s OU without using local loopback!

The Problem

The problem with managing printers in a school environment is that unlike corporations (which GP is clearly geared towards) people move around all the time but want to be connected to both their printers in their offices on the other side of the school, but also the local printer in the classroom they’re in². Microsoft decided that without any extra tricks they would let you set a default printer for a user, but not for a room because Betty from HR will only ever use the one computer in her office.

The Old Trick

Then they told people you could get around this by enabling local loopback, which applies both computer and user policies to a user, so you could set the printer as default in a computer policy using the “user” section, then make the computer read the computer section at logon and apply the printer. The problem with this³ is that it could slow down your logins, as it increases the number of policies it has to read and evaluate to prepare the desktop.

The New Way

In my quest to eliminate unnecessary policies, I wanted to kill local-loopback too. A bit of research turned up this page on using GP Preferences to assign default printers, which I already knew and was using, but it advocated using local-loopback.

But

Further down that page was a comment by Michael Moore who had this bit of advice:

Actually, if you Item Level target a group which has a computer in it, it will still install the printer even though these preferences are under the User Configuration Section of the GPO. Try it, saved on loopback. – Michael Moore

So I followed the directions on that site (it has helpful screenshots) to create a printer policy and target specific computer OUs, but then instead of turning on local-loopback, I simply ticked Run in logged-on user’s security context (user policy option).

Now my printers deploy and are set as default based on the current computer’s OU without using local-loopback at all.