none
GPP Mapped network drives issue

    Question

  • Hi,

    I have a Windows 2008 R2 domain. We have implemented a GPO in which, with user preferences, a user is mapped to several network units depending on the groups he belongs to.

    For example, if a user belongs to a group called Sales, he will have a mapped R: drive connected to \\srvfiles\sales

    If he belongs to a group called Billing, he will have a mapped Q: drive to \\srvfiles\billing.

    But once a letter is mapped to the user, it is saved in his profile, so if I remove the user from those groups, he will still have those mapped drives. 

    So we have make a change: At the top of the drive mappings, we have put a Delete all, starting from Q: rule in the GPP. We have also tried with a logoff script which removes all mapped drives. In both cases, we have the same result: When I remove the user from the groups and he logs again, the mapped drives are still there. If he logs of and logs on again, then the mapped drives has dissapeared (as it should have the first time). If I add the user to the group or both groups, and he logs in, again, he doesn't see the mapped drives the first time; he has to log off and log on again to have the mapped drives.

    Anybody knows why the user has to log in twice to have connected or disconnected the mapped drives? Is there any workaround to have those changes applied the first time the user logs in?

    Thanks

    Tuesday, August 11, 2015 8:34 AM

Answers

  • I have enabled the 'Always wait for the network at computer startup and logon policy and everything works correctly in the first logon.

    Thanks for your help.

    Tuesday, August 11, 2015 12:06 PM

All replies

  • If the user is already logged on and you apply the GPO then the user will have to make a new logon to take the GPP settings. If you apply a logoff script to wipe the drives in GPP when the user is logged on it will take two logoffs to apply the script, where the second logoff will run the script.

    Attempt to run a gpupdate /force before logging off the first time for testing.

    Tuesday, August 11, 2015 8:47 AM
  • Thanks for the answer.

    Forgetting the logoff script. We are going to use the gpp that first delete all mapped drives, and then maps the corresponding letters. I'll try to tell exactly the order of things.

    User belongs to Sales. He logs in. He gets mapped the R: letter. He logs off.

    I remove the user from Sales.

    He logs on. He still has the letter R mapped. He logs off. He logs on again. He hasn't the R letter mapped. He logs off.

    I make member of sales. He logs on. He has no letter mapped. He logs off. He logs on again. He has R letter mapped. As he is not logged when I remove or add from the group, no gpupdate /force is possible. And more than this: since I am not making changes to the GPP, but I am just making changes to membership, gpupdate /force doesn't apply. And there are not replication problems: we have just two domain controllers in the same site, and before log in I check the user's membership and is the same in both.

    More info. I have unmarked the 'reconnect' option in the network drive mapping, so is suppossed that this way, the mapping is not saved into the user profile. 

    I still need to log in twice to see the changes.

     

    Tuesday, August 11, 2015 9:12 AM
  • I have found another issue.

    When you create the mapped drive in GPP, there is a box 'Reconnect'. Microsoft stats that if you mark that box, the mapped drive makes persistent (as net use \blabla /persistent yes). And if you don't check it, it makes not persistent. Well, I have created another map drive, with that checkbox unmarked, and a wmi query tells that that network drive is persistent.

    And I have had to log twice to see the mapped drive.

    I'm completely confused.

    Tuesday, August 11, 2015 9:45 AM
  • > with that checkbox unmarked, and a wmi query tells that that network
    > drive is persistent.
     
    Persistence AFAIK is not per drive, but globally for all drives:
    "net use /p:no" or "net use /p:yes"
     
    If persistence is enabled when the drive is connected, it will persist.
    If not, then not, obviously :)
     
    HKU\S-1-5-21-1380478754-3156272429-3766653127-1001\Software\Microsoft\Windows
    NT\CurrentVersion\Network\Persistent Connections\SaveConnections: "yes"
     
    HKU\S-1-5-21-1380478754-3156272429-3766653127-1001\Software\Microsoft\Windows
    NT\CurrentVersion\Network\Persistent Connections\SaveConnections: "no"
     
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, August 11, 2015 10:52 AM
  • Thanks. Still more confused. Making more tests, I have found a more strange thing: the first time the user logs in, the windows explorer doesn't show the mapped drives, but cmd console does if I type net use. Still more confusing: from cmd i can type R: and create folders with mkdir. From Run if I type r: I get a msgbox telling R: the system cannot find the drive specified. If I type R: in the windows explorer address bar, I ger a msgbox telling "Windows can't find "r:". Check the spelling and try again.

    Surprising i I type R: in the Internet Explorer Address bar, I can navigate R drive.

    I haven't seem this in my whole life.

    Any idea about this crazy behavior?

    Tuesday, August 11, 2015 11:35 AM
  • I have enabled the 'Always wait for the network at computer startup and logon policy and everything works correctly in the first logon.

    Thanks for your help.

    Tuesday, August 11, 2015 12:06 PM
  • > I haven't seem this in my whole life.
     
    I have - in the past, we used Logon Scripts to map network drives. If
    these interfered with Explorer startup, Explorer got somewhat "crazy"
    and displayed the drives all of them or none of them or partially, some
    accessible, some not...
     
    Your GPO setting should be mandatory enabled for domain joined computers
    :) And if you buy faster machines, you might need to adjust
     
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, August 11, 2015 12:38 PM