Hi Guys,

I'm trying to get drive mappings to work in SBS 2008 via GPO Prefs.
In SBS User Poilicy\User Config\Prefs\Windows Settings, I've set the
location to \\<server>\Public, Set show this drive and show all drives,
NO common options set. However, when any user (all Vista clients) logs
on the drive is not shown.

I've used GPUpdate /force on both the server and client.
I've got UAC turned off on my PC
I'm logged on as a domain admin
Running GPResult on the client PC (seems) to show that the GPO was
applied.
I've tried the registry setting for EnableLinkedDrives without any
effect
Can't see any errors in the event logs
Event Logs show that policy was applied

Can anyone point me in the right direction?

Thanks in advance
DerekJ


--
DerekJ
------------------------------------------------------------------------
DerekJ's Profile: http://forums.techarena.in/members/128316.htm
View this thread: http://forums.techarena.in/small-bus...er/1236786.htm

http://forums.techarena.in

First off, turn ON UAC. Group policy actually uses UAC to elevate and
properly run some preferences. UAC *is your friend!* GET USED TO IT!!!
It isn't going away in Win7 and (yes it is a hot button for me) it bugs me
that people disable it assuming it is causing problems. It *rarely* does.

Annoying? Yes. Interfering with functionality? VERY VERY VERY rarely.
With all the shims it has, it usually *helps* older apps work better.

--

So, you've enabled UAC by now. Good. Next, go into the group policy
preference and check the box "run in user context." As I mentioned,
preferences run elevated by default. This causes drive mapping to not appear
in for the locally logged in user since that wasn't the context the GP was
run in. Check that box and make sure your permissions are correct on the
share and you should be right as rain...

-Cliff


"DerekJ" <DerekJ.3xha7b@newsgroup> wrote in message
newserekJ.3xha7b@newsgroup

>
> Hi Guys,
>
> I'm trying to get drive mappings to work in SBS 2008 via GPO Prefs.
> In SBS User Poilicy\User Config\Prefs\Windows Settings, I've set the
> location to \\<server>\Public, Set show this drive and show all drives,
> NO common options set. However, when any user (all Vista clients) logs
> on the drive is not shown.
>
> I've used GPUpdate /force on both the server and client.
> I've got UAC turned off on my PC
> I'm logged on as a domain admin
> Running GPResult on the client PC (seems) to show that the GPO was
> applied.
> I've tried the registry setting for EnableLinkedDrives without any
> effect
> Can't see any errors in the event logs
> Event Logs show that policy was applied
>
> Can anyone point me in the right direction?
>
> Thanks in advance
> DerekJ
>
>
> --
> DerekJ
> ------------------------------------------------------------------------
> DerekJ's Profile: http://forums.techarena.in/members/128316.htm
> View this thread:
> http://forums.techarena.in/small-bus...er/1236786.htm
>
> http://forums.techarena.in
>

I also had problems when first trying to Map Drives through group
policy

I found that if I linked the GPO to the
MyBusiness\Computers\SBSComputers OU it would not apply but if I
linked the same GPO to MyBusiness\Users\SBSUsers it worked.

I was filtering this GPO to apply to certain MACHINES only by creating
a security group and adding the machines I wanted the GPO to apply to,
then using Item Level Tageting on each preference to apply the GPO to
machines in the group only.

I still don't know why thiswould only work when linked to the SBSUsers
OU and would love to be enlightened.

On Tue, 25 Aug 2009 19:08:54 +0530, DerekJ
<DerekJ.3xha7b@newsgroup> wrote:

>
>Hi Guys,
>
>I'm trying to get drive mappings to work in SBS 2008 via GPO Prefs.
>In SBS User Poilicy\User Config\Prefs\Windows Settings, I've set the
>location to \\<server>\Public, Set show this drive and show all drives,
>NO common options set. However, when any user (all Vista clients) logs
>on the drive is not shown.
>
>I've used GPUpdate /force on both the server and client.
>I've got UAC turned off on my PC
>I'm logged on as a domain admin
>Running GPResult on the client PC (seems) to show that the GPO was
>applied.
>I've tried the registry setting for EnableLinkedDrives without any
>effect
>Can't see any errors in the event logs
>Event Logs show that policy was applied
>
>Can anyone point me in the right direction?
>
>Thanks in advance
>DerekJ

Well, the answer is actually pretty straightforward, but I don't want to
assume anything, so I'll answer the question in two parts, just in case
there was a nugget of information you weren't aware of.

For the first part of the answer, I'm going to take group policies out of
the equation for a moment and just give a brief overview of how Windows
"sees" mapped drives. When you have a hard drive, a USB drive, floppy, or
other device, that is (I know, stating the obvious) real hardware and thus
has to be associated to the machine somehow. So drive letters are a machine
setting.

A mapped drive, however, is really just a handy way to reference a network
location. When you click on the M drive you've mapped, internally Windows
"knows" that this points to a share and opens an SMB connection to
\\server\share. It isn't a "real" drive. You can see this by using a
version of windows that allows user switching. Login as UserA, map a
drive...lets say to M, and then log "switch" and log in as User B (with user
A remaining logged in.) UserB does not have an M drive. So you map the
*same* share to UserB's O drive and switch back to UserA. UserA still has
an M drive but no O drive. This is by design. These are shortcuts and,
like your desktop or start bar, shortcuts are for your convenience and
customizeable. You probably don't want the same wallpaper and shortcuts
that Bob does from accounting. He's a slob after all and has all sorts of
excel links littering his desktop and you, of course, are a neat freak.

So mapped drives are *STRICTLY* user settings. They are stored in the
user's profile and loaded on login and unloaded on logout. The system
accounts, such as LocalSystem, NetworkService, and others do NOT see those
drive letters. They'd just access the network natively. After all, they
don't have a fear of keystrokes like us humans do.

--

So, with that established (or reaffirmed as the case may be) we can move
onto the second part of the answer. Reintroducing group policies. When you
open a group policy in the GPEditor, there are two distinct sections.
Machine settings and user settings. Now I'm not just talking about
preferences here....the following applies to all group policy settings.
Lets say you expand the machine group policy settings and set a power
management setting. If that policy is linked to an OU that only has users
then that policy will *never* get applied. It is a machine setting and thus
*must* be applied to a machine. Not a machine that a user logs into, but a
machine in the domain that the DC can control.

It may seem to make sense to say "I assigned the policy to a user so that it
gets applied to any machine they log in to." But in practice, does that
actually make sense. If you later set up VPN access for a boss so he can
work from his home machine, he might be a little ticked logging into the
VPN, causes the domain controller to suddenly apply a bunch of machine
settings such as changing his screen saver, making his laptop power down
after 2 minutes, and so on. No. Machine settings are only applied to
machines that exist in AD and are in an OU that the policy is linked to.

So the reverse is also true. User settings are only applied to users, never
machines. To again use an example, you can set a user policy to force IE to
have a specific homepage. Now it won't matter which machine the user logs
into, that setting will apply because it is a user setting. If you assigned
the policy to an OU that only has machines...well...there are no users so
that user setting never gets applied. And again, you may be thinking "I
want the homepage to be http://our-finance-server/sharepoint-homepage if a
user logs into a computer in the finance OU." But again, you are thinking
about it a little wrong. The point is you want to change a *user's*
homepage so you still need to assign the policy to a user. Machines don't
have homepages (what does LocalSystem need a homepage for!)

You can get the desired effect for *both* examples above by using filters.
Group Policy filters were invented for this reason (long before preferences
existed!) You can filter by security group or write some very fancy WMI
filters to get all sorts of esoteric configurations.

But it still boils down to this single question: Does this setting affect a
machine or just a user ON the machine? And link appropriately. Of course
it is easy to answer THAT question (you don't have to guess) because the
setting you are changing is going to be hierarchically under one of those
two main groups in the GPEditor.

So...to come full circle...where is the mapped drive preference found?
Per-machine preferences have no mapped drive section...so it is under
per-user. And using my rule above, any setting under per-user must be
linked to an OU that contains users.

--

For the record, your linked policy would've been applied to any USER you
added to the SBSComputers group. An OU can hold a user, a computer, a
security group, etc etc. BUT BUT BUT, by default you should not *have* any
users in that OU because the golden rule in SBS is "use the wizards!" And
the wizard would never put a user in that particular OU. So there you have
it.

Make sense?

-Cliff


"Simon Thomson" <simon@newsgroup> wrote in message
news8499510rao46da7h34t2mu0loqbq91lli@newsgroup

> I also had problems when first trying to Map Drives through group
> policy
>
> I found that if I linked the GPO to the
> MyBusiness\Computers\SBSComputers OU it would not apply but if I
> linked the same GPO to MyBusiness\Users\SBSUsers it worked.
>
> I was filtering this GPO to apply to certain MACHINES only by creating
> a security group and adding the machines I wanted the GPO to apply to,
> then using Item Level Tageting on each preference to apply the GPO to
> machines in the group only.
>
> I still don't know why thiswould only work when linked to the SBSUsers
> OU and would love to be enlightened.
>
> On Tue, 25 Aug 2009 19:08:54 +0530, DerekJ
> <DerekJ.3xha7b@newsgroup> wrote:
>

>>
>>Hi Guys,
>>
>>I'm trying to get drive mappings to work in SBS 2008 via GPO Prefs.
>>In SBS User Poilicy\User Config\Prefs\Windows Settings, I've set the
>>location to \\<server>\Public, Set show this drive and show all drives,
>>NO common options set. However, when any user (all Vista clients) logs
>>on the drive is not shown.
>>
>>I've used GPUpdate /force on both the server and client.
>>I've got UAC turned off on my PC
>>I'm logged on as a domain admin
>>Running GPResult on the client PC (seems) to show that the GPO was
>>applied.
>>I've tried the registry setting for EnableLinkedDrives without any
>>effect
>>Can't see any errors in the event logs
>>Event Logs show that policy was applied
>>
>>Can anyone point me in the right direction?
>>
>>Thanks in advance
>>DerekJ

"Cliff Galiher" <cgaliher@newsgroup> wrote in message
news:%23XmzxllJKHA.4168@newsgroup

> Well, the answer is actually pretty straightforward, but I don't want to
> assume anything, so I'll answer the question in two parts, just in case
> there was a nugget of information you weren't aware of.
>
> For the first part of the answer, I'm going to take group policies out of
> the equation for a moment and just give a brief overview of how Windows
> "sees" mapped drives. When you have a hard drive, a USB drive, floppy, or
> other device, that is (I know, stating the obvious) real hardware and thus
> has to be associated to the machine somehow. So drive letters are a
> machine setting.
>
> A mapped drive, however, is really just a handy way to reference a network
> location. When you click on the M drive you've mapped, internally Windows
> "knows" that this points to a share and opens an SMB connection to
> \\server\share. It isn't a "real" drive. You can see this by using a
> version of windows that allows user switching. Login as UserA, map a
> drive...lets say to M, and then log "switch" and log in as User B (with
> user A remaining logged in.) UserB does not have an M drive. So you map
> the *same* share to UserB's O drive and switch back to UserA. UserA still
> has an M drive but no O drive. This is by design. These are shortcuts
> and, like your desktop or start bar, shortcuts are for your convenience
> and customizeable. You probably don't want the same wallpaper and
> shortcuts that Bob does from accounting. He's a slob after all and has
> all sorts of excel links littering his desktop and you, of course, are a
> neat freak.
>
> So mapped drives are *STRICTLY* user settings. They are stored in the
> user's profile and loaded on login and unloaded on logout. The system
> accounts, such as LocalSystem, NetworkService, and others do NOT see those
> drive letters. They'd just access the network natively. After all, they
> don't have a fear of keystrokes like us humans do.
>
> --
>
> So, with that established (or reaffirmed as the case may be) we can move
> onto the second part of the answer. Reintroducing group policies. When
> you open a group policy in the GPEditor, there are two distinct sections.
> Machine settings and user settings. Now I'm not just talking about
> preferences here....the following applies to all group policy settings.
> Lets say you expand the machine group policy settings and set a power
> management setting. If that policy is linked to an OU that only has users
> then that policy will *never* get applied. It is a machine setting and
> thus *must* be applied to a machine. Not a machine that a user logs into,
> but a machine in the domain that the DC can control.
>
> It may seem to make sense to say "I assigned the policy to a user so that
> it gets applied to any machine they log in to." But in practice, does
> that actually make sense. If you later set up VPN access for a boss so he
> can work from his home machine, he might be a little ticked logging into
> the VPN, causes the domain controller to suddenly apply a bunch of machine
> settings such as changing his screen saver, making his laptop power down
> after 2 minutes, and so on. No. Machine settings are only applied to
> machines that exist in AD and are in an OU that the policy is linked to.
>
> So the reverse is also true. User settings are only applied to users,
> never machines. To again use an example, you can set a user policy to
> force IE to have a specific homepage. Now it won't matter which machine
> the user logs into, that setting will apply because it is a user setting.
> If you assigned the policy to an OU that only has machines...well...there
> are no users so that user setting never gets applied. And again, you may
> be thinking "I want the homepage to be
> http://our-finance-server/sharepoint-homepage if a user logs into a
> computer in the finance OU." But again, you are thinking about it a
> little wrong. The point is you want to change a *user's* homepage so you
> still need to assign the policy to a user. Machines don't have homepages
> (what does LocalSystem need a homepage for!)
>
> You can get the desired effect for *both* examples above by using filters.
> Group Policy filters were invented for this reason (long before
> preferences existed!) You can filter by security group or write some very
> fancy WMI filters to get all sorts of esoteric configurations.
>
> But it still boils down to this single question: Does this setting affect
> a machine or just a user ON the machine? And link appropriately. Of
> course it is easy to answer THAT question (you don't have to guess)
> because the setting you are changing is going to be hierarchically under
> one of those two main groups in the GPEditor.
>
> So...to come full circle...where is the mapped drive preference found?
> Per-machine preferences have no mapped drive section...so it is under
> per-user. And using my rule above, any setting under per-user must be
> linked to an OU that contains users.
>
> --
>
> For the record, your linked policy would've been applied to any USER you
> added to the SBSComputers group. An OU can hold a user, a computer, a
> security group, etc etc. BUT BUT BUT, by default you should not *have*
> any users in that OU because the golden rule in SBS is "use the wizards!"
> And the wizard would never put a user in that particular OU. So there you
> have it.
>
> Make sense?
>
> -Cliff

Excellent explanation. :-)

It's something that many don't realize, that if you set a user setting on a
computer OU GPO where no users exist, it doesn't work, and they pull their
hair trying to figure out why. :-)

Ace

Hi All,

Many thanks for the answers!


Attached is (I hope) a JPG of the GPO setup. You should be able to see
that I've done this in the SBS User Policy and that the policy is
applied to the User Names, not computers.

I've tried this with WMI filtering ON and OFF with the same result.
The SBS User policy is linked and active.
In the Event Viewer of my client PC I can see the policy being
applied.

But sadly... no mapped P: drive.

I tried setting up a logon script in the same SBS User Policy and this
ran for me but not for other users.

Thanks to all for the answers
DerekJ


+-------------------------------------------------------------------+
|Filename: GPO.jpg |
|Download: http://forums.techarena.in/attachmen...chmentid=9708|
+-------------------------------------------------------------------+

--
DerekJ
------------------------------------------------------------------------
DerekJ's Profile: http://forums.techarena.in/members/128316.htm
View this thread: http://forums.techarena.in/small-bus...er/1236786.htm

http://forums.techarena.in

"DerekJ" <DerekJ.3xjirb@newsgroup> wrote in message
newserekJ.3xjirb@newsgroup

>
> Hi All,
>
> Many thanks for the answers!
>
>
> Attached is (I hope) a JPG of the GPO setup. You should be able to see
> that I've done this in the SBS User Policy and that the policy is
> applied to the User Names, not computers.
>
> I've tried this with WMI filtering ON and OFF with the same result.
> The SBS User policy is linked and active.
> In the Event Viewer of my client PC I can see the policy being
> applied.
>
> But sadly... no mapped P: drive.
>
> I tried setting up a logon script in the same SBS User Policy and this
> ran for me but not for other users.
>
> Thanks to all for the answers
> DerekJ
>

I see the GPO, but you didn't screenshot what OU the GPO is linked to.

Ace

Actually Ace, it is there. Although he blacked out the actual domain name,
you can see by the .local to the right and the "domain" icon to the left
that it is linked at the domain level (a legitimate link BTW.) So this
should be applying.

What is not present in the screenshot is the individual property settings
for the actual preference, which would be necessary to rule out problems
such as item-level-targetting or user context problems.

And, just as an FYI, for the most part I'd create a new group policy object
for new settings you create outside of the wizards. Otherwise the wizards
can overwrite settings and have undesired side-effects. If, for example.
you undo a WMI filter that the wizard set, you may cause harm to your server
as a setting is now getting applied to a server that never should be.

So, my advice:

1) Undo all your changes.
2) Create a new GPO and link it. Remember, more restrictive is better.
Don't link to the domain unless you NEED to.
3) Never use usernames in security filtering. Always use security groups.
4) Don't use WMI filters unless there is no other way to achieve the
filtering you want. They are awesome, but complicated and difficult to
troubleshoot.

Try that and see if your problem goes away.

-Cliff


"Ace Fekay [MCT]" <aceman@newsgroup> wrote in message
news:eihM8IpJKHA.1376@newsgroup

> "DerekJ" <DerekJ.3xjirb@newsgroup> wrote in message
> newserekJ.3xjirb@newsgroup

>>
>> Hi All,
>>
>> Many thanks for the answers!
>>
>>
>> Attached is (I hope) a JPG of the GPO setup. You should be able to see
>> that I've done this in the SBS User Policy and that the policy is
>> applied to the User Names, not computers.
>>
>> I've tried this with WMI filtering ON and OFF with the same result.
>> The SBS User policy is linked and active.
>> In the Event Viewer of my client PC I can see the policy being
>> applied.
>>
>> But sadly... no mapped P: drive.
>>
>> I tried setting up a logon script in the same SBS User Policy and this
>> ran for me but not for other users.
>>
>> Thanks to all for the answers
>> DerekJ
>>

>
>
> I see the GPO, but you didn't screenshot what OU the GPO is linked to.
>
> Ace

"Cliff Galiher" <cgaliher@newsgroup> wrote in message
news:uyfuCurJKHA.4232@newsgroup

> Actually Ace, it is there. Although he blacked out the actual domain
> name, you can see by the .local to the right and the "domain" icon to the
> left that it is linked at the domain level (a legitimate link BTW.) So
> this should be applying.
>
> What is not present in the screenshot is the individual property settings
> for the actual preference, which would be necessary to rule out problems
> such as item-level-targetting or user context problems.
>
> And, just as an FYI, for the most part I'd create a new group policy
> object for new settings you create outside of the wizards. Otherwise the
> wizards can overwrite settings and have undesired side-effects. If, for
> example. you undo a WMI filter that the wizard set, you may cause harm to
> your server as a setting is now getting applied to a server that never
> should be.
>
> So, my advice:
>
> 1) Undo all your changes.
> 2) Create a new GPO and link it. Remember, more restrictive is better.
> Don't link to the domain unless you NEED to.
> 3) Never use usernames in security filtering. Always use security groups.
> 4) Don't use WMI filters unless there is no other way to achieve the
> filtering you want. They are awesome, but complicated and difficult to
> troubleshoot.
>
> Try that and see if your problem goes away.
>
> -Cliff

>

Duh! I missed that. I honestly don't know what I was looking at when I
first clicked on it. Maybe I was in a hurry.

Since I work mostly with non-SBS servers, I don't completely agree with the
way SBS links all of the default GPOs at the domain level and uses filtering
to apply the objects. I would rather design my OU structure based on the
Location then Function method (or whatever is apprpriate for the
organization), then child OUs to organize objects based, and apply GPOs
appropriately. Besides strict targeting, it keeps the GPOs from applying to
the DCs, too. I know, I know, it's SBS and it does things differently, which
I usually just leave alone, knowing what's best for the system and for me
(to not mess it up), and use the wizard, if the wizard can control what I'm
trying to do.

Anyway, back to Derek. As far as Derek's setup, I agree to clean it up,
start over, and create separate GPOs for what he wants and apply it at the
OU level instead of the domain.
:-)

Ace

On Wed, 26 Aug 2009 08:28:05 -0600, "Cliff Galiher"
<cgaliher@newsgroup> wrote:

Cliff, thankyou.

I read a 500 page Microsoft PDF on Group policy, you just made things
clearer in as many words. Much appreciated.