[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now


SBS 2003 Group Policy Issue

Posted on 2011-03-07
Medium Priority
Last Modified: 2012-06-27
I am working with a fresh install of SBS 2003 R2 Premium. I modified Group Policy to redirect Application Data, Desktop & Documents folders to a network share. Worked great.

Problem is I need to install a vendor software package that saves a file to the local Applicaiton Data folder, so I disabled the policies, rebooted, ran GPupdate /force, dcgpofix and scratched my head bloody, but the thing is still redirecting Applicaiton Data and Desktop. How in the world do i get it to stop redirecting these folders?

The server is still in lab, with all Service Pack & updates installed. Once the vendor software is installed, I copy the file created to the network redirect and the software runs fine. I simply forgot to install it before doing the policy. Any suggestions?
Question by:michaelm352
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
LVL 77

Expert Comment

by:Rob Williams
ID: 35065455
In the policy itself did you check "Redirect the folder back to the local user profile when the policy is removed"?
If not try that, followed by GPupdate /force.
Seems to me folder redirection requires 2 logons before applied, after GPupdate

Author Comment

ID: 35065720
I re-enabled the policy, ensured the "Redirect the folder back, etc" was checked, followed by two gpupdate /force, then a reboot. Desktop and app data once again are redirected.

After the reboot, i disabled the policy, followed by three gpupdate /force, and another reboot, but the folders are still redirecting. .... ... .. . At a loss here...
LVL 59

Expert Comment

by:Cliff Galiher
ID: 35075135
Common mistake, and common misperception.

What happens here is that when the group policy is *first* applied, if the checkbox to "redirect to original location" is checked then the original location is stored in the registry so that files can get moved back when the GP falls outside of scope. If you initially created the policy WITHOUT checking that box then that setting never got saved to the registry, files got moved, and the "original" location is lost forever. No amount of checking, gpupdate, etc after the fact can recover that info because the data was already moved and the path destroyed.  This is why even reapplying the policy and checking the box doesn't fix the issue. At this point the "original" loYou *cation *is* the server.

All is not lost, however. What you can do is enable folder redirection, and in the location path of the group policy, choose "redirect to the local userprofile location" (I also recommend *UNCHECKING* the move to original location checkbox!)

This will cause folder redirection to move files back to the default location for user profiles on that machine...which in 99% of all cases is what you want.


If you are interested in exactly what the difference is, a simple illustration:

1) You start out with a local profile.

2) Your music is in c:\users\cgaliher\music (win7 assumed here)

3) You right-click on the music folder in your local profile and change the location to a folder on your D: drive because it has more space.

4) Later, folder redirection is enabled and the original location checkbox is checked.

5) Even later, the group policy is disabled.
... because that checkbox was checked, files in the music folder will get moved from the shared path back to D:, *NOT* back to C:. The custom path for the music was preserved.

Conversely, if the checkbox was *NOT* checked and the "redirect to local userprofile location" option is used, the music files will be moved back to c:\users\cgaliher\music (the default location for music in a new profile) as an assumed default must be used now. The custom path was not preserved.


As you can see, in most cases, where custom paths were not defined on local resources before the policy was in place, the end result will actually be the same. But I wanted to illustrate the difference as, in rare cases, odd side-effects can occur, particularly with profiles that may have large amounts of redirected data that reside on local volumes too small to accomodate the new redirection back to default local paths.

As always, have a backup.


Accepted Solution

michaelm352 earned 0 total points
ID: 35076035
Thanks for the thorough explanation Cliff, I solved the issue in a simple way. As the only user on this server was Administrator, I did a search of the Registry for "Administrator" and sure enough, was able to locate and correct the errant path entries. Rebooted, and everything is back to normal.

I have since installed the vendor package, captured the propriatary file from local settings and recreated the policies with the "redirect to original location" box CHECKED!

Appreciate the responses, THANKS!

Author Closing Comment

ID: 35120726
The first response did not correct the issue. After researching and testing, the solution I did was completed before the second response was posted.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Always backup Domain, SYSVOL etc.using processes according to Microsoft Best Practices. This is meant as a disaster recovery process for small environments that did not implement backup processes and did not run a secondary domain controller that ne…
Let's recap what we learned from yesterday's Skyport Systems webinar.
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

656 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question