Ok... so my boss charged me with shrinking down our roaming profiles to make logins quicker. We're talking about getting rid of roaming profiles completely, but thats a different monster (they've been in place since before he or I started at this company). So, the obvious choice is to set up folder redirection. Our GP setup... well... it leaves a lot to be desired. Anyway... one of the former admins set up folder redirection for the My Documents folder successfully and that works great. Well, I noticed that the largest part of the profiles currently is Application Data and I want to set up folder redirection to get application data out of the roaming profiles and onto a share on the server. I've set everything up the way Microsoft outlined it, in the same GP object that the My Documents redirection is set up in... but it's just not working. No errors... nothing funny... just not using the folder specified (still using the one under the roaming profile).

Heres what I have set up:

I have a test group created and I have my account and a test account set up as members.

I have the Folder Redirection set up for advanced, with the test group set as the group and a map to the shared folder on the server using \%username% so that it will create folders.

I've tried manually creating the user folders on the share. Still nothing. I tried maping to \%username%\Application Data\ and manually configured that folder. Still nothing.

Any ideas what might be preventing this from working?

Are you sure you've applied the policy in Active Directory? It seems like the policy isn't having any effect towards the groups you specified. You could try mapping home folders to see if that helps at all.

Are the machines XP? If so you can do this to check if they are being applied:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/verifypolicy.mspx

Also, you can force updating of the policy by using Group Policy Update:

For XP: gpupdate (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/refrgp.mspx)

For 2000: secedit (http://support.microsoft.com/kb/q227448/)

I dealt with an issue kinda like this some time ago. I dont know if you use a logon script or not but I have mind set to do a gpupdate /force upon long on. As long as your policy is set correctly then running this command upon logon should resove that issue. If you want to have a little fun with it you can scrpit a gpupdate /sync. You will have to automate it to throw a "y" for a restart request and also set some type of time variable so that it will go out and see when the last time the policy was refreshed so that its just just constantly re-booting computers everytime on logon.

The way my script is written is first is goes out and checks the policy and sees when the last time it was refreshed was. If it was less than 48 hrs ago it forces a gpupdate /sync and restarts the computer. That might be a little much for some people so you should adjust it for however often you want it done. If you need some help writing it let me know. I wrote mine in vbs and used a "runas" vbs script to make the call as well to be sure it was ran with the correct permissions.

Well... we're on 2k Server (going 2k3 next year) and 2k clients. I don't think 2k has GPUpdate, so the gpupdate /sync thing probably won't work. I've tried secedit /refreshpolicy on my system and my test system and still nothing. It almost seems like the changes I made in the GPO are not going into effect at all. The GPO is set on a container specifically for this location. I also tried setting it up on the primary domain GPO, but still nothing.

I'm not all that familiar with scripting, but I know that we do currently have a login script in place... I think I'll take a look at that and see if it has anything of consiquence.

I would recommend going into the GPO in question and setting something simple first, such as enabling screen-saver, or something similarily inconsequential. It is readily tested and you can then see if the Policy is being applied correctly.

Group Policy inheritance is a nightmare on all Windows platforms but less so on their 2003 boxes. My guess is you are running into a policy that is overriding the one you are trying to enforce.

Also, when you run secedit on the server, make sure you reboot the client, not merely log off.