GPO Preferences drives not mapping

[swpmre]

Hello all again,

 

I'm trying to set up some mapped drives using Group Policies in Active Directory on Windows SErver 2008.

 

I've created some logon scripts to map drives for particular user groups and these work fine.

 

However I want to use Preferences to map some more drives for particular user groups and groups of computers.

 

None of the drives I map like this work. I've run a RSOP and the output shows that while other things (such as security changes) in the GPO run, the drive maps don't.

 

The way it is setup is that I have created a GPO for a particular Organisation Unit, which has a number of computers in it. I want to map drives to different locations dependent on each site (i.e. each different OU). Ideally, the drive will map for all users on a particular computer at a particular site.

 

Despite following the technet guide, the mappings don't work.

 

I can access the particular drive fine from the individual PCs and I can map the drives manually using exactly the same setup from the PC.

 

Am I missing something obvious?

[jamesreedersmith]

What OS is on the client - if its XP have you installed the Client Side Extensions?

[swpmre]

Sorry, its Windows XP on the client and yes, Client Side Extensions are installed.

[ZeroHour]

Double check the clients event log for entries as RSOP can miss some.

[swpmre]

Further investigation has got some more info, which might be relevant.

 

If I map a drive using preferences and apply it direct to an OU that is (say) a user group, the drive maps properly.

 

It seems to not work if its applied to a OU that is a computer group. Is it possible that this is related?

 

I'll investigate more.

[ZeroHour]

Further investigation has got some more info, which might be relevant.

 

If I map a drive using preferences and apply it direct to an OU that is (say) a user group, the drive maps properly.

 

It seems to not work if its applied to a OU that is a computer group. Is it possible that this is related?

 

I'll investigate more.

 

If the map is under User Preferences/Config then yes it wont work when applied to a computer OU as only the computer part of the GP is applied.

The trick you can use is something called Loop-back policies but test this carefully, I have used it myself a lot to allocate user printers based on room but you should test and ensure nothing gets enabled as a result.

Without that basically each GP section (user/computer) only applies to the objects in that OU of that type.

 

EDIT: Another option would be to use filters on the map drives section to check for computer name (with % being a wildcard) which was then applied to the users OU and that would not require loopback to be turned on.

[swpmre]

Ah. Ok. That seems remarkably obvious now you point it out.

 

Having looked at the "targeting" option on the mapping, I see that there is an option to do this on IP range.

 

For our setup this might be better, any reasons why this might cause problems?

[ZeroHour]

Ah. Ok. That seems remarkably obvious now you point it out.

 

Having looked at the "targeting" option on the mapping, I see that there is an option to do this on IP range.

 

For our setup this might be better, any reasons why this might cause problems?

 

No but generally I would use client name if possible (I dont have GPP to hand right now) as ip can change. In theory if you have a lot of complex drive mappings it could slow down logons a little but generally it shouldnt be a problem.

The filters that GPP provide are excellent at locking down parts to users/groups as well.

[Trapper]

Try the loopback option.

 

That was messing mine up - couldn't figure out what was doing it until I saw that had been enabled years ago by someone.

 

All works fine now.

[Avalon]

sorry for hijacking this thread but it looks as though your question has been answered and I am having a very similar problem.

 

I am struggling to get group policy preferences to apply when a user logs on. I have mapped a drive and added a printer but they do not appear. We are running 2008 R2 and are trying this on a Windows 7 client. We have one test OU called Curriculum where the computer resides (user settings disabled) and one OU called Students where the student account resides (computer settings disabled). There is a GPO linked to Curriculum and a GPO linked to Students. All user settings are being correctly applied to the user apart from preferences.

 

Any ideas?

[chazzy2501]

from an admin command run gpresult /h fileplaceandname.html. That'll produce the full results for you.

 

EDIT: Poop sorry this wont work for xp just run gpresult /v

 

EDIT EDIT: oh you've windows 7 so try the first one.

Edited July 11, 2011 by chazzy2501

[Avalon]

thanks for that. I was running gpresult /r but missed the vital piece of information I should have picked up on. It seems the GPO applied to the Students OU is not getting applied.

 

the scope includes authenticated users, computer configuration settings disabled and under delegation authenticated users have read and apply GPO permissions.

 

I have ran gpupdate /force but when logging on again the mapped drive and printer still do not appear

[chazzy2501]

are you mapping it under the student security context? I find that breaks it. Also the GPOP printer adding requires the GPO setting to allow normal users to install drivers. (can't remember the gpo something about allow drivers from a given server) I was never able to fix this bug so I used the old way of deploying printers for a while then used GPOP deploy in the future.

[Jamo]

are you mapping it under the student security context? I find that breaks it. Also the GPOP printer adding requires the GPO setting to allow normal users to install drivers. (can't remember the gpo something about allow drivers from a given server) I was never able to fix this bug so I used the old way of deploying printers for a while then used GPOP deploy in the future.

 

This is the point and print restrictions on 2008 I think you are referring to. Basically allows a client to trust the print server without authentication (which a non admin user cannot provide)