none
Group Policy User Drive Mapping is set to UPDATE. How to disconnect while keeping Update setting

    Question

  • Hi,

    We have an issue more prominent to Windows 10 wherein File Explorer closes randomly when a folder from a network drive map is open.  The solution is to change the Group Policy Drive Map from REPLACE to UPDATE.  However it  presents a new issue. 

    If a user moves to another division, for example same drive letter but different folder destination, it does not update the new mapping.  Obviously because UPDATE does not disconnect existing drive mapping and REPLACE with new mapping.  The result is that user has a disconnected G drive showing the old associated drive.

    What is the best way to handle it so it resolves both issue (File Explorer and moving of users from one drive map to another drive map but same letter) while using GPP?

    Thanks!


    Friday, March 9, 2018 6:39 PM

Answers

  • Thank you! This is what worked for me...

    - I put back our original setting to REPLACE.  

    - I created a new Computer GPO and add only the computers that are affected

    - GPupdate couple of times and it seems to work without changing the mapping to UPDATE or Item Level Targetting!

    Credit to this person who posted this solution! https://rcmtech.wordpress.com/2016/11/03/group-policy-preference-drive-maps-closing/

    Computer Configuration/Administrative Templates/System/Group Policy/Configure Drive Maps preference extension policy processing
    Enabled:
    Allow processing across a slow network connection: Enabled
    Process even if the Group Policy objects have not changed: Disabled
    Background priority: Idle

    • Edited by DoBongSoon Thursday, March 15, 2018 8:52 PM
    • Marked as answer by DoBongSoon Thursday, March 15, 2018 8:53 PM
    Thursday, March 15, 2018 8:52 PM

All replies

  • Hi,

    According to your description, I recommend you can try add a "delete all" action in the first order of the drive maps GPP. In this case, mapped drives will be deleted and then re-created when users log in. The following screenshot for your reference:


    If you need further help, please feel free to let us know.

    Best Regards,
    Albert

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, March 12, 2018 6:16 AM
  • Thanks Albert!

    My follow up question is... do you know if this also run and checks only upon log in? The reason I asked is because if this checks/runs in the background, then we may end up again with the "REPLACE" situation where in, REPLACE checks in the background and closes File Explorer on Windows 10.  Initially, I thought REPLACE or any of this group preferences only runs upon log in.  But I guess it does run in the background also based on our experience with "REPLACE" causing the interruption on the File Explorer in Windows 10. Thanks again!

    Monday, March 12, 2018 3:24 PM
  • > What is the best way to handle it so it resolves both issue (File Explorer and moving of users from one drive map to another drive map but same letter) while using GPP?

    Stick with "Replace", but add Item Level Targeting for GP Processing Mode IS NOT background or manual.

    Monday, March 12, 2018 4:09 PM
  • Hi Martin,

    Thanks for the reply.  Currently, our REPLACE setting is already set to Item Level Targeting.  With that setting, our Windows 10 users experience an issue wherein if they leave a folder open from a network drive via File Explorer, it randomly closes.  Similar to this issue https://social.technet.microsoft.com/Forums/windows/en-US/a1eb2924-499f-41c8-8630-7950e38b8f84/windows-10-1511-explorer-windows-close-randomly?forum=win10itprogeneral and many other reports online with similar problems.

    Monday, March 12, 2018 4:19 PM
  • Hi,

    I agree with Martin. Based on the test in my lab, adding Item-level Targeting can prevent Group Policy Background Processing. Please have a try with the following example settings (Uncheck Background):


    If you need further help, please feel free to let us know.

    Best Regards,
    Albert

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, March 13, 2018 7:26 AM
  • Hi Albert,

    If I add the Item Level Processing mode, my G drive (the drive letter affected) disappears.  But if I remove it, it comes back as it should be... 

    Tuesday, March 13, 2018 5:46 PM
  • > If I add the Item Level Processing mode, my G drive (the drive letter affected) disappears.  But if I remove it, it comes back as it should be...

    You need to "invert" the ILT - what you did doesn't work :-) I never dug into the root cause, because ILT filters have no usable log output, but it seems to require the proper combination of check boxes in the list, too.

    What easily works: Change element options to "NOT" and check "Background" only.

    Wednesday, March 14, 2018 11:43 AM
  • Thank you! I will look into this and update this post.
    Thursday, March 15, 2018 12:29 AM
  • Hi,

    If you have any updates or questions, please feel free to contact us.

    Best Regards,
    Albert

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 15, 2018 9:14 AM
  • Thank you! This is what worked for me...

    - I put back our original setting to REPLACE.  

    - I created a new Computer GPO and add only the computers that are affected

    - GPupdate couple of times and it seems to work without changing the mapping to UPDATE or Item Level Targetting!

    Credit to this person who posted this solution! https://rcmtech.wordpress.com/2016/11/03/group-policy-preference-drive-maps-closing/

    Computer Configuration/Administrative Templates/System/Group Policy/Configure Drive Maps preference extension policy processing
    Enabled:
    Allow processing across a slow network connection: Enabled
    Process even if the Group Policy objects have not changed: Disabled
    Background priority: Idle

    • Edited by DoBongSoon Thursday, March 15, 2018 8:52 PM
    • Marked as answer by DoBongSoon Thursday, March 15, 2018 8:53 PM
    Thursday, March 15, 2018 8:52 PM
  • Hi,

    Good to hear that you have solved this issue by yourself. In addition, thanks for sharing your solution in the forum as it would be helpful to anyone who encounters similar issues.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,
    Albert

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, March 16, 2018 2:23 AM
  • > Process even if the Group Policy objects have not changed: Disabled

    Be aware that this will completely fail if you use Item Level Targeting based on group membership, and the user's groups change. Your GPO will not reapply since it didn't change...

    Friday, March 16, 2018 10:03 AM
  • Thanks Martin! So I understand it better are you saying that if I change something on Users Group Policy here and out (after this setting this up), it won't take effect because this is on?


    Monday, March 19, 2018 3:29 PM
  • > Thanks Martin! So I understand it better are you saying that if I change something on Users Group Policy here and out (after this setting this up), it won't take effect because this is on?

    No. If you change something in the GPO, its version number will increase and the client (or user) will process the new version once.

    But imagine the following:

    Mapping 1: Q: -> \\server\dept_q, Item Level Targeting "User is a Member of security group dept_q"
    Mapping 2: Q: -> delete, Item Level Targeting "User is NOT a Member of security group dept_q"

    If you remove a user from the dept_q group, he will not have his Q: removed because the GPO did not change and will not be processed again. Vice versa - if you add a user to the dept_q group, he will not receive the new mapping because the GPO did not change.

    Monday, March 19, 2018 3:53 PM
  • Thanks Martin! Got it.
    Monday, March 19, 2018 4:21 PM
  • Unfortunately, NEITHER proposed solution is an answer to this issue.

    Let me repeat the stated goal at the beginning of this thread:
    1) Prevent drives from disconnecting periodically if using REPLACE
    2) Remove mapped network drives when the GPO no longer applies to the user

    As already pointed out, turning off "Process even if the group policy objects have not changed," completely defeats the ability to use Item Level Targeting to control who receives the drive map - defeating requirement #2.

    Second, using Item Level Targeting based on the foreground/background group policy processing also does not work. This option causes the GPO to "no longer apply" and removes the drive map whenever the group policy does a background refresh. This behavior changes if you disable the option to "Remove this item when it is no longer applied." But, then the drive map is not removed when the policy no longer applies, similar to the UPDATE method - defeating requirement #2 again.

    As neither solution actually answers this question, I would like to see solutions that do work. This has been a long standing question for me. I will continue to try to resolve this issue.

    Utilizing the "Do not reconnect" option, or the "Delete All" first option also does not meet the needs of this question. Group policy sometimes takes minutes to process. The user cannot sit without a drive connection for several minutes after logging in.
    Monday, June 11, 2018 5:58 PM
  • > As neither solution actually answers this question, I would like to see solutions that do work. This has been a long standing question for me. I will continue to try to resolve this issue.

    The only viable solution is: Create 2 items for each mapping. One "update", one "delete". Use the same ILT for both, but in the "delete", put the whole filter in a collection and invert the collection. Set and done... :-)

    Tuesday, June 12, 2018 11:11 AM
  • I've spent the last couple of days iterating through various solutions to this problem. It doesn't seem that there is any solution that is perfect.

    Long story short, the most effective, straight forward method to fix this issue is to revert the behavior of GPP Drive Maps back to it's pre-Windows 8.1 days. In order to do that, set the computer policy: (See the drawback below)

    SYSTEM\Group Policy\Configure Drive Maps preference extension policy processing

    Enable the option:

    Do not apply during periodic background processing.

    I came across several posts saying that this particular option was desired but missing in the group policy I mentioned above. I can tell you that the option exists on our network, but we keep our policy definitions up to date with the latest OSes. If you don't have the option, you can also change this behavior with the following registry key: 

    HKLM\SOFTWARE\Microsoft\Windows NT\CurrenVersion\Winlogon\GPExtensions\{5794DAFD-BE60-433f-88A2-1A31939AC01F}\NoBackgroundPolicy = 1

    Long story:

    Although I can't find any documentation on this, the root of the problem is a change in behavior of how Group Policy Drive Maps are applied since Windows 8.1. In essence, prior to Windows 8.1 the drive maps required foreground, synchronous processing to connect. This meant that they only connected at the time the user logged on to the computer. Since Windows 8.1, the default behavior changed, and Group Policy Drive Maps now process during a periodic background group policy refresh also.

    Group policy drive maps have had the capability to run during background refresh for a long time. The behavior is ultimately controlled with the above mentioned NoBackgroundPolicy key. Pre-Windows 8.1 defaulted to no background processing and the key was set to a value of 1. Post Windows-8.1 the registry key was removed and defaulted to background processing enabled.

    Running group policy drive maps during background refreshes actually goes against Microsoft's own documented recommendations (although I'm having trouble finding that reference again). Why? Well, because of it's huge propensity to cause data loss and other problems during policy refreshes. So, one has to wonder WHY they changed this behavior to begin with.

    I approached this problem wanting any solution to meet the following requirements:

    1. The drive is available immediately at logon
    2. The drive reconnects if manually disconnected
    3. The drive disconnects when the GPO no longer applies
    4. The drive does not periodically disconnect during background policy refreshes
    5. The policy will replace any existing drive map
    6. The policy will apply during any background refresh

    The change in default behavior of background refreshes satisfies requirement #6, but introduces huge issues with requirements 3, 4, and 5 that are related to using the REPLACE action.

    By reverting back to pre-Windows 8.1 behavior, we satisfy requirements 1 through 5 if we use the following drive map options:

    • Common\Remove this item when it is no longer applied
    • General\Reconnect
    • General\Action: Replace

    It is true that a complex combination of REPLACE, UPDATE and DELETE actions, possibly across multiple GPOs could accomplish all 6 requirements. But the complexity makes it ridiculously impractical.

    Drawback:

    The drawback to disabling background policy refresh is one that every admin should already be familiar with. You will have to ask your users to logoff and back on for changes to take affect. It can also take up to two logons before the policy applies, because it requires a foreground, synchronous processing of group policy. This "2-logon" behavior is resolved with the "Always wait for network" group policy at the expense of startup and logon delays.

    In my personal opinion, this small drawback (and return to the behavior we have known for years), is not really much problem at all. Almost all drive maps are connected, removed, or changed based on OU and Security Group membership changes which require a user to logoff and back on to take affect anyways. It is also not something that typically changes often, if ever, for a user. Any admin who has been around for a while is accustomed to asking users to logoff and logon for policy and script changes to take affect.


    • Edited by Appleoddity Wednesday, June 13, 2018 3:07 PM
    • Proposed as answer by Marc.Sam Wednesday, October 10, 2018 9:34 AM
    Wednesday, June 13, 2018 3:07 PM
  • I can understand your logic on this and it makes sense. It works better if the only determining factor for application is an item-level target.

    But, it does not address a few concerns:

    • The drive map being removed when the GPO is removed (user changes OU).
    • Replacing existing mappings that are not correct (mapped by logon script).
    • Possible conflicts causing an overloaded drive map to be deleted by one policy while created by another.

    Thanks

    Wednesday, June 13, 2018 3:50 PM
  • > But, it does not address a few concerns:

    That's one of the reasons we never deployed GPP to map drives, but use some AD attributes to store them and scripts to assign/remove them.

    Thursday, June 14, 2018 11:55 AM
  • I'm about up to here with gpp map drives being somewhat unreliable, and am just about ready to go back to logon scripts, they worked fine for like 20 years.  creating 50 ou's and then policies for each one is just a sad workaround for 6 lines of code.    thanks  for your post.
    Friday, August 31, 2018 3:55 PM