GPO not working (yes, another post)
DerekJ
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-business-server/1236786.htm
Cliff Galiher
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...@DoNotSpam.com> wrote in message
news:DerekJ...@DoNotSpam.com...
Simon Thomson
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.
Cliff Galiher
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@specterraDOTcomDOTau> wrote in message
news:p8499510rao46da7h...@4ax.com...
Ace Fekay [MCT]
news:%23Xmzxll...@TK2MSFTNGP05.phx.gbl...
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
DerekJ
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/attachment.php?attachmentid=9708|
+-------------------------------------------------------------------+
Ace Fekay [MCT]
news:DerekJ...@DoNotSpam.com...
>
>
> 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
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]" <ace...@mvps.RemoveThisPart.org> wrote in message
news:eihM8IpJ...@TK2MSFTNGP02.phx.gbl...
Ace Fekay [MCT]
> 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
Simon Thomson
<cgal...@gmail.com> wrote:
Cliff, thankyou.
I read a 500 page Microsoft PDF on Group policy, you just made things
clearer in as many words. Much appreciated.
DerekJ
Hi Guys,
Sorry for the late post but I got side-tracked onto another problem.
Thanks for the help so far......
OK, So I created another policy, linked to MyBusiness\Users\SBSUsers,
with no WMI filter set. Set to Enforced, Link Enabled & GPO Enabled
with just a single mapped drive (create) set and NO Comon options set.
Authenticated users get read access.
If (on my client PC) I issue net use... with the same path as the GPO
it sets up the share without problem but still no drive on mt client PC
when I use GPUpdate.
This is the XML from the client event log :-
Applications and services\microsoft\windows\GroupPolicy\Operational...
The client PC is MHA-LT1
The GPO is MapMHAdrives
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-GroupPolicy"
Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
<EventID>5312</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2009-08-31T18:46:58.914Z" />
<EventRecordID>82455</EventRecordID>
<Correlation ActivityID="{E66815F1-CB9F-436D-8312-E951B44EC374}" />
<Execution ProcessID="1292" ThreadID="2000" />
<Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
<Computer>MHA-LT1.mha.local</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="DescriptionString">Local Group Policy Default Domain
Policy MapMHAdrives Windows SBS CSE Policy Windows SBS User
Policy</Data>
<Data Name="GPOInfoList"><GPO ID="Local Group Policy"><Name>Local
Group
Policy</Name><Version>131074</Version><SOM>Local</SOM><FSPath>C:\Windows\System32\GroupPolicy\User</FSPath><Extensions></Extensions></GPO><GPO
ID="{31B2F340-016D-11D2-945F-00C04FB984F9}"><Name>Default Domain
Policy</Name><Version>1966110</Version><SOM>LDAP://DC=mha,DC=local</SOM><FSPath>\\mha.local\sysvol\mha.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\User</FSPath><Extensions>[{00000000-0000-0000-0000-000000000000}{A8C42CEA-CDB8-4388-97F4-5831F933DA84}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{BC75B1ED-5833-4858-9BB8-CBF0B166DF9D}{A8C42CEA-CDB8-4388-97F4-5831F933DA84}]</Extensions></GPO><GPO
ID="{97A598F2-CC3A-427B-80F1-6E4A9628A9A2}"><Name>MapMHAdrives</Name><Version>393222</Version><SOM>LDAP://OU=SBSUsers,OU=Users,OU=MyBusiness,DC=mha,DC=local</SOM><FSPath>\\mha.local\SysVol\mha.local\Policies\{97A598F2-CC3A-427B-80F1-6E4A9628A9A2}\User</FSPath><Extensions>[{00000000-0000-0000-0000-000000000000}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{5794DAFD-BE60-433F-88A2-1A31939AC01F}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}]</Extensions></GPO><GPO
ID="{A91BCAA9-F0A7-4D17-B262-EBAA4A588C5E}"><Name>Windows SBS CSE
Policy</Name><Version>458759</Version><SOM>LDAP://DC=mha,DC=local</SOM><FSPath>\\mha.local\SysVol\mha.local\Policies\{A91BCAA9-F0A7-4D17-B262-EBAA4A588C5E}\User</FSPath><Extensions>[{6490DB9D-2802-4956-BCCB-EC84EA0887BB}{6490DB9D-2802-4956-BCCB-EC84EA0887BB}]</Extensions></GPO><GPO
ID="{7F533C25-DB3B-4471-95E2-FDBB6B6841B2}"><Name>Windows SBS User
Policy</Name><Version>10223772</Version><SOM>LDAP://DC=mha,DC=local</SOM><FSPath>\\mha.local\SysVol\mha.local\Policies\{7F533C25-DB3B-4471-95E2-FDBB6B6841B2}\User</FSPath><Extensions>[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{00000000-0000-0000-0000-000000000000}{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}][{D7300225-081C-4CED-9FAD-BFCF9EC3D1D3}{D7300225-081C-4CED-9FAD-BFCF9EC3D1D3}]</Extensions></GPO></Data>
</EventData>
</Event>
<<<<<<<<<<<<<<<<<<<<<<<<
It seems to say that the policy is seen and applied!
I mst be doing something wrong, or the client PCs must have been set up
incorrectly.
FRUSTRATED!
Derek
Ace Fekay [MCT]
news:DerekJ...@DoNotSpam.com...
>
Can you post the script in the GPO?
Does it work if you manually run it from a client (domain user) account?
Ace/
Cliff Galiher
1) You say no options are applied. As I've posted before, you *SHOULD*
check the box that has the preference run in the users' context.
2) gpupdate will NOT make the drive appear. Most (if not all) preferences
are applied during logon because of the way the client-side extensions are
coded. Hopefully this will change and get extended as MS refines the
product, but for now....gotta log out and log back in.
3) Yeah, I said two things, and technically this shouldn't make a
difference, but y'never know....there is no reason to ENFORCE a GPO unless
you are trying to override a more specific GPO that would otherwise be
applied. Unless you know and understand its effects, don't use "enforced."
If you have other GPOs that are enforced, they could actually be
interfering. Go back and undo those. That certainly isn't the default
configuration.
-Cliff
"DerekJ" <DerekJ...@DoNotSpam.com> wrote in message
news:DerekJ...@DoNotSpam.com...
>