Folder redirection.... isn't! <- now resolved

[TheCrust]

I know a lot has been written about this (emotive!) subject, and XP SP3 made it all the more fun to deal with, but I'm wondering if anybody can give some advice here, or pointers to where the problem might lie.

 

I'll try to give as much info as possible having read some of the other folder redirection threads, so this will be quite long. Bear with me!

 

 

One of our feeder schools has a Windows XP network - mainly SP2 machines - controlled by a pair of Server 2003 boxes. Folder redirection is used for staff and students to give a consistent set of desktop and start menu icons.

 

 

This is achieved through a single GPO that uses the "advanced" redirection settings to shift the start menu and desktop folders based on group membership:

 

Pupils desktop redirects to \\DUMBLEDORE\profiles\redirection\pupil\desktop

Pupils start menu redirects to \\DUMBLEDORE\profiles\redirection\pupil\startmenu

 

Staff desktop redirects to \\DUMBLEDORE\profiles\redirection\staff\desktop

and their start menu goes to \\DUMBLEDORE\profiles\redirection\staff\startmenu

 

The GPO is configured so that the computer configuration side is disabled, and all other settings apart from the folder redirection are left as "not configured" so interference with other GPOs should be minimal.

 

 

Recently, it came to our attention that "on occasion" it wasn't working. According to the school staff anyway - when I looked at it today, it seemed to me like it wasn't working at all!

 

Further investigation showed that the pupils can log in fine but they receive a blank desktop and start menu. There are two application event log errors generated: one for Folder redirection ("Access denied") and the other for Userenv stating that the folder redirection policy was unable to be applied.

 

Staff using the same GPO linked against their OU can log in fine, and get their redirected desktop and start menu - albeit very sluggishly but I think this is more to do with Symantec carrying out a boot-time scan and me not being patient enough with the workstations than with the network.

 

The access denied message initially suggested a permissions issue on the source directory the redirected folders are stored in - but when checked, they are identical for pupils and staff: Domain Admin and SYSTEM user contexts have full control, pupils and staff groups have "read only" - both at file and share level.

 

Users are correctly assigned to either group and to rule out a local permissions issue on the workstation, I added my test pupil user to the local administrators group to see what it did. There was no change - folder redirection did not work.

 

I discovered while I was experimenting with permissions that adding the pupil users group to the BUILTIN\Administrators group then allowed the folders to be redirected correctly.

 

I know this is "a touch insecure" so it's not been left like that but it does suggest a permissions issue - however I can't for the life of me find where the trouble may be. I've checked the permissions on the GPO itself to confirm the user groups can read and apply it, the share and file permissions on the directories where I want the redirections to go. I've even checked the ownership of the bloody folders in case that had some bearing on it!

 

But no luck so far. I even went as far as applying SP3 to a workstation and then re-imaging it completely using a fresh WDS image with SP3 slipstreamed in to avoid any SP2->3 upgrade issues - but this did not cure the problem.

 

It seems the only way I can possibly make it work is to leave the pupils user group a member of Administrators.... Noooooooooo!

 

 

Now this network has been inherited so I wouldn't be in the least bit surprised to have missed something blatently obvious but I've spent all afternoon staring at the problem and can now no longer see the wood for the trees so a fresh perspective is required.

 

 

Any thoughts?

 

Thanks in advance!

 

 

 

Jim

Edited June 9, 2009 by TheCrust
Problem solved. Ta-daaaaaa! :-)

[EduTech]

Have you check both the Share Permissions and Security Permissions on the folders?

 

i find a common mistake is people setup the security permissions but forget about the share permissions.

 

one way to test this maybe, is logon as a user and try going to the path specified via RUN

 

Just a thought

 

James.

[Michael]

I would have a good look at the profiles folder/share. If necessary, unshare and re-share it, then re-apply permissions.

 

It is unusual to name the Redirection share 'profiles' as this could get confusing with roaming profiles, which I typically would share as profiles$

 

I would also have a look at where it's being shared from. If it's within NETLOGON or SYSVOL, I would remove it from there and create a new share.

[TheCrust]

Have you check both the Share Permissions and Security Permissions on the folders?

 

i find a common mistake is people setup the security permissions but forget about the share permissions

 

 

Permissions check out - I can log on as a user and *not* get the redirected desktop or start menu, but then navigate to the redirection target fine.

 

 

It is unusual to name the Redirection share 'profiles' as this could get confusing with roaming profiles, which I typically would share as profiles$

 

I would also have a look at where it's being shared from. If it's within NETLOGON or SYSVOL, I would remove it from there and create a new share.

 

 

When we came to it, yes, it was a folder stored within NETLOGON and with it's own share. I removed the share, moved the folder, and re-shared it with the same name.

 

We chose to leave it as \\DUMBLEDORE\profiles rather than anything else because as well as playing host to the redirected folders, it will also host a few mandatory and non-mandatory roaming profiles when we eventually set them up. Because it's all (loosely) related to profiles, I lumped all the various folders into one share.

 

I hear what you're saying though and when I get this FR problem sorted, I plan on hiding the share anyway.

Edited June 8, 2009 by TheCrust

[TheCrust]

As an update to this issue, I have now resolved it.

 

A bit more careful examination of the application event log showed it wasn't the GPO responsible for the folder redirection erroring - it was another GPO that locked down the student desktop and that had previously had folder redirection settings applied in it that was causing the problem.

 

Temporarily removing the "lock down" GPO and leaving the redirection GPO in place confirmed this - students could log on and get their redirected settings fine without needing to be members of the administrators group.

 

After poking around in SYSVOL, it seems the permissions on Policies\{Student lockdown GPO GUID}\User\Documents & Settings\fdeploy.ini had become corrupt to the point that only the administrator could read them. Even though this file was not responsible for the desired redirection settings, it caused the whole thing to go bandy.

 

If the user had admin rights, they could read and process the file - and got redirection from the other GPO fine.

If they didn't, because they couldn't read this file it caused the whole redirection process to stop with an "access denied" message.

 

Simply resetting the permissions on the fdeploy.ini file to inherit from parent again resolved the issue.

 

Live and learn on that one I guess.

 

Thanks for the suggestions anyway - much appreciated.