none
Mapped Drives issue

    Question

  • Hello All,

    I have mapped drives set through domain GPO and it works wonderfully. However, I recently added a group to one of the drives under item level targeting using the 'OR' operator and the contingent of users that should be affected are not. In an effort to troubleshoot, I made sure that specific security group that I added to the item level target was and is on the actual share that I'm trying to map, I ran a 'klist purge' and several gpupdate /force & reboots to no avail. Any ideas?

    Thanks!

    Monday, June 10, 2013 4:31 PM

Answers

  • I actually JUST figured it out. It was something I thought of last week, that I didn't bother messing with, because it's part of default domain policy and I didn't want to tinker with that while my boss was in Europe. He put his drive mapping script from 1976 (I'm being facetious) in default domain pol, so of course, despite blocking inheritance, it's going to take whatever that thing's got... I opened the .vbs up and part of the script - where you map the drives to certain groups - shows what to map what to. Since the security group I made wasn't part of that script, since it was made 39 years ago (being facetious again) and since we need to keep that script for now until we completely move over to my drive maps through GPO pol, I granted myself access, so to speak, by adding another "K:" (the letter to the network share giving me issues) with the security group I created, replaced the login script on sysvol, and all of a sudden, problem solved. This makes sense and made sense as I was testing it, because replication was working, permissions were fine, and no matter what I did: creating a new pol, making new drive maps, etc, nothing worked except for associating users with that specific security group, so it made me think to check this script, and since default domain pol takes precedence ( I believe ) over all else.......................... yeah, so it works now! Thank you, Martin and Alan for your input and guidance! All of this helped lead me to this point!
    • Marked as answer by Sentri7 Wednesday, June 19, 2013 8:30 PM
    Wednesday, June 19, 2013 8:30 PM

All replies

  • Try rebooting as this will update the group membership for the users token locally... then run GPRESULT /h %userprofile%\desktop\gp.html and see what it says under the drive mapping section? is the policy denied? Just a few things to check...

    Hope it helps


    Alan Burchill (MVP)
    http://www.grouppolicy.biz

    @alanburchill

    Tuesday, June 11, 2013 12:16 AM
  • Hi Alan! Thanks for the response! I did run a gpresult /h, but there was nothing in there that suggested that the policy isn't taking. All of the other drive mappings from this policy are taking except these two, for these two users. Yesterday, I wound up deleting the problematic drive from my policy and recreated it. The only thing I can really think of at this point is that since I added a second group of users to that drive, GPO didn't seem to take to it for some reason. I'm going to check in with the user once she gets in-- will report back in a few...
    Tuesday, June 11, 2013 12:48 PM
  • Still no dice. Maybe it's just the 'OR' operator isn't working? I'm going to create another drive and just add one group to it, so I will wind up in GPO with 2 of the same drive mappings, but for different groups of users, eliminating the 'OR' operator from the equation for now. Fingers crossed.
    Tuesday, June 11, 2013 1:32 PM
  • Still nothing. I don't know if this would matter, but one of the groups I'm using for this drive - the same one I'm having issues with - is also the group I'm using to map another drive through gpo. I don't know if there's somehow confusion caused by referencing the same security group SID in different drive maps, but I am now using a different group that has the same users in it, to see if that will make a difference. This is weird..
    Tuesday, June 11, 2013 5:47 PM
  • Nada. I did have a user in one of the other groups associated with that drive letter log in and she receives her drive. It doesn't seem to like the other 2 security groups that I tried for the other contingent of users, for whatever reason.

    I just added the users individually to the drive mapping to see if that takes...

    • Edited by Sentri7 Tuesday, June 11, 2013 6:14 PM
    Tuesday, June 11, 2013 6:09 PM
  • Nothing works. We have been doing stuff to the network here as of late, and repadmin works with /syncall, but not explicitly from one DC to another, so maybe that's the problem. I've tried everything I could think of, and this part of the policy doesn't apply ONLY to the group of users that I recently added into this drive mapping late last week (when the networking stuff here started). I'll give it some time to marinate and see what happens.
    Tuesday, June 11, 2013 8:44 PM
  • Am 11.06.2013 22:44, schrieb Sentri7:
    > Nothing works. We have been doing stuff to the network here as of
    > late, and repadmin works with /syncall, but not explicitly from one DC
    > to another, so maybe that's the problem. I've tried everything I could
    > think of, and this part of the policy doesn't apply ONLY to the group
    > of users that I recently added into this drive mapping late last week
    > (when the networking stuff here started). I'll give it some time to
    > marinate and see what happens.
     
    There's an issue with the OR operator - the first item has an hidden AND
    operator. Swap order, then you can change this hidden AND to OR, and it
    will work. AFAIK.
     
    regards, Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Tuesday, June 11, 2013 9:06 PM
  • Another really OUT THERE idea is that the users might be a member of to many groups... with the GPRESULT report you had how many groups were listed as the user being a member of? if it is more than a few 100 then you might have AD token bloat.

    Alan Burchill (MVP)
    http://www.grouppolicy.biz

    @alanburchill

    Wednesday, June 12, 2013 2:27 AM
  • Thanks for the response guys!

    Martin, I initially thought there may be an issue with 'OR' because everything works except for when I add another sec group in, using 'OR.' I just tried the swap and - like you said - the 'OR' switched to 'AND' so I switched it back to 'OR' lol. We shall see what happens! Why is this part of drive maps in GPO so quirky?

    Wednesday, June 12, 2013 2:35 PM
  • Am 12.06.2013 16:35, schrieb Sentri7:
    > the 'OR' switched to 'AND' so I switched it back to 'OR' lol. We shall
    > see what happens
     
    Please post the result back... I recently tried to verify this again,
    and it worked as expected, but I used GPP folders instead of GPP drive
    maps. Maybe it really is only drive maps, but that sounds odd - why
    shouldn't they use the same ILT functions all over GPP? Anyway...
     
    And please tell me the exact version of %systemroot%\system32\gpprefcl.dll.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wednesday, June 12, 2013 2:46 PM
  • Argh. For some reason, this didn't work. I really thought this would've done it this time-- when I flip both groups back and forth, the conditional operator sticks with 'OR' which is obviously what I want, but I don't get the desired result.

    The version of the gpprefcl.dll is 6.1.7601.17514

    What I also just did was place the security group that I'm referencing in GPP, on the actual network share as well. Currently, the network share just had each user account permissioned on it, rather than the group. This in conjunction with the 'OR' finagling I hope does the trick. Stay tuned.....

    I made the network share addition and still to no avail.


    • Edited by Sentri7 Wednesday, June 12, 2013 6:28 PM
    Wednesday, June 12, 2013 3:35 PM
  • Alan, we are a small shop, so the user doesn't have anywhere close to 100 + memberships-- I wish she did, so I could feel like I'm on to something!
    Wednesday, June 12, 2013 5:42 PM
  • Could it be for some strange reason that even though these users have rights to this share, but not all of the directories in the share, that the drive won't map? The other group of users that has rights to this share, has access to every directory and the drive comes down for them.

    This is definitely a funky permissions thing. I'm not sure how the guy before me set this up, but this share - when it comes to certain users that aren't a part of a specific group - have limited access to this share, and my guess is that this limited access is what's somehow hindering GPO from mapping a drive. I can add these users to the group that has full access and it should be fine, based on my testing, but ideally, I need to get to the bottom of why this is occurring and make changes accordingly.

    The deeper and deeper I test this, the more it seems like I'm exploiting a shortcoming with GPP Drive Maps. I mirrored the share under a different name, reset all permissions, & still to no avail. Up to this point, the conclusion I'm beginning to draw is: unless you're issuing a network share to a user or group of users that have access to every directory on that share, GPP drive maps won't lay down a drive.

    Though, at this point, I now have permissioned ALL of the user groups with full permissions on the drive and still nothing. Removing the 'OR' statements to see if it will take for just 1 security group...

    Nothing works at this point; I'm wondering if it's the security groups I'm creating. I'll be back at it tomorrow..

    • Edited by Sentri7 Thursday, June 13, 2013 9:07 PM
    Thursday, June 13, 2013 2:01 PM
  •  
    > I might have found the issue: replication. See below...
    >
     
    Yes, that will - for sure - prevent the GPO from applying...
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Friday, June 14, 2013 10:09 PM
  • Martin, I found out there was an outage last night-- replication is fine now, and my problem still exists. I even made a powershell login script (that I tested), and that's not working either for some reason. Regardless of that, I'd really like to be able to use GPP for this all. I may just set this drive to be configured - the way I had it - and check back in a week; unsure why GPO is behaving so oddly when it just comes to this particular share!
    Saturday, June 15, 2013 7:48 AM
  •  
    > Martin, I found out there was an outage last night-- replication is
    > fine now, and my problem still exists. I even made a powershell login
    > script (that I tested), and that's not working either for some reason.
    > Regardless of that, I'd really like to be able to use GPP for this
    > all. I may just set this drive to be configured - the way I had it -
    > and check back in a week; unsure why GPO is behaving so oddly when it
    > just comes to this particular share!
     
    Ok, seems we're going for
     
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Sunday, June 16, 2013 8:07 PM
  • Yeah, I thought about doing this as well, so last night I enabled logging and tracing, but I cannot find a log file in "c:\programdata\group policy\etc....

    Tomorrow, I will be attemping to add new mapped drives through GPO, so I will be able to test further if it's something specific to this share, or a networking problem of some kind-- which it may be because we've been having issues as of late.


    As of today, other drives that I created are replicating between DC's, but do not come down either. The network here has definitely been screwy, considering that we're reconfiguring the IP space, so, for now, I'm going to attribute it for that. More to come later...
    • Edited by Sentri7 Tuesday, June 18, 2013 9:04 PM
    Monday, June 17, 2013 8:08 PM
  • I tried something a little different today.. I was wondering if maybe I just have way too much stuff packed into one policy ( I literally have everything from every service configured in here, to Firewall settings, to numerous other things), and maybe I've just hit some sort of threshold, and now I'm at policy overload. I created a new policy, only with the drive mappings that haven't been taking and I will test them with this approach. Report back by the end of the day...
    Wednesday, June 19, 2013 5:07 PM
  • I actually JUST figured it out. It was something I thought of last week, that I didn't bother messing with, because it's part of default domain policy and I didn't want to tinker with that while my boss was in Europe. He put his drive mapping script from 1976 (I'm being facetious) in default domain pol, so of course, despite blocking inheritance, it's going to take whatever that thing's got... I opened the .vbs up and part of the script - where you map the drives to certain groups - shows what to map what to. Since the security group I made wasn't part of that script, since it was made 39 years ago (being facetious again) and since we need to keep that script for now until we completely move over to my drive maps through GPO pol, I granted myself access, so to speak, by adding another "K:" (the letter to the network share giving me issues) with the security group I created, replaced the login script on sysvol, and all of a sudden, problem solved. This makes sense and made sense as I was testing it, because replication was working, permissions were fine, and no matter what I did: creating a new pol, making new drive maps, etc, nothing worked except for associating users with that specific security group, so it made me think to check this script, and since default domain pol takes precedence ( I believe ) over all else.......................... yeah, so it works now! Thank you, Martin and Alan for your input and guidance! All of this helped lead me to this point!
    • Marked as answer by Sentri7 Wednesday, June 19, 2013 8:30 PM
    Wednesday, June 19, 2013 8:30 PM