none
Troubleshooting Registry Edit via GPO

    Question

  • Our initial problem began when we were saving MS Office Documents. We would be prompted with the following error.

    Sorry, we couldn't open '\\Server\username\Documents'.

    We discovered that we can fix this error on a local machine by making two registry edits to the following locations:

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and change the Cache multi string variable from \\servername\username to %USERPROFILE%

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders and change the Cache multi string variable from \\servername\username to c:\Users\%USERNAME%

    Now we would like to push out these two registry changes to all of our lab workstations via GPO. We have already created the new GPO for Registry edits, created the update registry entries, and linked the new GPO to our domain.

    When we review the RSOP on multiple test users the policy appears to not to be applied. In one instance, we actually saw the registry entry change back to the original settings. Therefore we believe that these settings are being pulled from some other location/Policy, but we have not been able to track that down.

    When running gpresult on a user we can see our new Registry_Entry_GPO is one of the GPO's that has been applied to that user, but when we check the registry for the changes, it appears that the changes have not been applied.

    Question: how can we track down what is causing the setting to revert back to the original settings or get our new settings to stick?

    Thank you for any help that you can offer?

    Friday, September 25, 2015 6:24 PM

Answers

  • When running gpresult on a user we can see our new Registry_Entry_GPO is one of the GPO's that has been applied to that user, but when we check the registry for the changes, it appears that the changes have not been applied.

    Question: how can we track down what is causing the setting to revert back to the original settings or get our new settings to stick?

    Examine the Link Order (Precedence).
    Check for Loopback Processing.
    Use gpresult /v, or gpresult /z, to see the deep-detail of the winning GPO for that setting.
    If you are using Security Filtering or WMI Filtering or Item-Level-Targeting, check that the filter is working correctly.

    Generally, redirecting shell folders to a server, is a bad idea at any time (in my experience).


    Don


    Friday, September 25, 2015 11:40 PM

All replies

  • created the update registry entries

    Can you replace "update" with "replace" and see if it helps?

    -Umesh.S.K

    Friday, September 25, 2015 6:57 PM
  • When running gpresult on a user we can see our new Registry_Entry_GPO is one of the GPO's that has been applied to that user, but when we check the registry for the changes, it appears that the changes have not been applied.

    Question: how can we track down what is causing the setting to revert back to the original settings or get our new settings to stick?

    Examine the Link Order (Precedence).
    Check for Loopback Processing.
    Use gpresult /v, or gpresult /z, to see the deep-detail of the winning GPO for that setting.
    If you are using Security Filtering or WMI Filtering or Item-Level-Targeting, check that the filter is working correctly.

    Generally, redirecting shell folders to a server, is a bad idea at any time (in my experience).


    Don


    Friday, September 25, 2015 11:40 PM
  • We have already tried "replace" and it has the same affect as "update." It still gets overwritten.
    Saturday, September 26, 2015 4:58 AM
  • @Don - I'll try your suggestion when I get back to work on Monday. Have a great weekend, and thanks for the tips.

    Saturday, September 26, 2015 5:00 AM