Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

GPO for dummies 1

Status
Not open for further replies.

Hagfish

MIS
Jan 20, 2005
88
0
0
US
I am the sys admin for a small office with about 30-40 users. We have a domain running on windows server 2003. I've set up a beta WUS server for patch management and I'm wanting to test it with group policies. I set up a gpo in the "group policy manager" and called it "wustest". I then went in to the group policy object editor, and configured the client settings for automatic updates in the administrative templates section.. All was going well, and I was feeling good especially since this is my first attempt in messing around with GPO's.. Here's where everything went wrong and what I don't quite understand yet I guess. As soon as the policy was enabled, all the machines on the domain inherited the policy and began connecting to the WUS server! I wanted it to be a test only, and only have certain users that were part of a certain group or OU to be able to connect to the WUS server until I test it more.. where did I go wrong? TIA

--hag
 
When you setup a policy by default every policy is set to be applied to "Authenticated Users" Make sure you remove that group and add your test group instead.

Do do this..:

In the GPMC (Group Policy Management Console) select your WUSTest Policy. You should see where you can change which users/groups the policy gets applied to. (I believe it is in the bottom half of the right window)

Hope that helps. Let us know.

good luck.

-Matt
 
Thanks Matt. I actually tried this even before I read your post. I removed "authenticated users" and added a user group I had created called "wususers" which only has 1 test user account in the group. It doesn't seem to be working though. When I run a test from the "group policy results" on my test machine logged in as the test user, the report comes back and the only GPO that shows up under "applied gpo's" is the default domain policy. Under "denied gpo's" is where I see my test "wustest" policy, and the reason denied shows "disabled link". Under the GPMC when I look at my test policy it says that the link is enabled though.. any other ideas? Thanks!

--hag
 
I am not able to check myself, and I can't remember, but... is the settings for a user policy or machine policy?

If it is a user policy then so far it looks like you set it up correctly.

If it is a machine policy then make sure you have the machine in the group to get the policy applied.

how many domain controllers do you have in your domain? If you have more then one, did you replicate or allow time for replication?

On the client did you log off and log back in, or did you just allow it to update while the test user was logged in?

Did you try reboot the client and log back in?

Have you tried other polices (both machine and user). Try a simple user policy such as removing RUN from the start menu, or the screen saver tab in Display Properties. Then recheck group policy results.

-Matt
 
on the permissions tab, have you enabled both 'read' and 'apply policy' rights?

and the GPO you created, sounds like you linked it to the domain... try creating an OU and just linking it to the OU.
You put the users in the OU...
OUs are also meant for this type of thing, to apply policy to just certain users/pcs...


Aftertaf

"Solutions are not the answer." - Richard Nixon
 
Matt nailed it. As soon as I added that computer to the "security filtering" window it kicked in and applied the policy.. So, does this mean when making a GPO that has "computer configuration" rather than "user configuration" you can only apply it computer names and not to user names? Thanks for all the help fellas.
 
A gpo is split on purpose into two, one part covers the computer configuration and one the user. As far as I can gather and as usual MS documentation is flimsy at best the user config bits relate to the user profile so user bits will carry from computer to computer if the OU it is linked and applied to contains users. So user a gets the same desktop and start menu on all PCs. While the Computer bits only apply to computers so the OU has to contain these computers.

The fun and games start when you want different user configs for a laptop than on an desktop, having two computer GPOs covers many aspects but not all. I for example want a different start menu for teachers when they log into the desktop PCs than when they log into their laptops because the apps are not all the same, and I want to centrally control the start menu on the desktops and nail them down while on the laptops I want the same users to have more control and none of the centrally supplied and server dependent apps.

So far I have found no reliable way of doing it, but with a bit more time soon I will nail this sucker. I just wish someone wrote something about GPOs 'under the bonnet (or hood for those over the pond)' the MCSE texts tell you no more than you can find out on Technet and MSDN and I know that is not all there is to it.
 
Hag,
I am glad that worked for you. You are right. You can only apply computer policies to computers (the HKLM - HKEY_LOCAL_MACHINE part of the registry) and user policies to users (the HKCU - HKEY_CURRENT_USER part of the registry).
However, see below. (gets kinda funky, so keep it simple until you really understand)


TIM,
In response to you wanting different policies applied based on which computer logs in then you need to do some research on the loopback policy. We had a similar situation. I wanted one policy for when users logged into their desktop and another for when they log into the terminal server.

The loopback policy allows you to apply USER policys to a MACHINE. With loopback enabled, when the user logs in their normal user policies will be stripped away and replaced by the ones applied to the machine. (you can also tell them to merge instead of replace)

So as an example. You have 3 OUs: desktops, laptops, teachers. Lets say they normally log into their desktops. So you configure your group policies for the teachers and desktops OU accordingly. But when logging into the laptops you need something completely different to happen for the USER. So in the laptops OU you set your machine policies as normal, also set the LOOPBACK policy. Then you can configure your USER policies in the SAME GPO. Now when a teacher logs into a laptop their "teacher GPO" will be replaced or merged with the laptop GPO.

Google loopback policy, you will get tons of info!

Good luck everybody!

-Matt
 
Thanks for the tips. I think I'm starting to get the hang of it now. One more question though. One of the machines in my test environment is another Win 2003 server. Not a second domain or anything like that, just a regular server that's a member of the current domain. I've added it to the list of computers to receive updates, but it's not taking the policy. Do GPO's only work with workstations, not servers?

--hag
 
nevermind, I guess I was just being impatient. It kicked in after about 30 mins after doing a GPUpdate. Thanks again!

--hag
 
I have tried all the settings for loopback policy, the laptops GPO did not kick in until I did, but it is inconsistent some had no access to apps some had all the apps laptop or desktop it is a mess. I created a dummy user and tried that, same effect. I keep wondering if I should change the functional level of AD to native but I may not just be dealing with XP machines next year, then again nothing anywhere tells me whether this will help.

RSOP and policy modelling have been of no use everything is as it should be on paper, only in reality it is not.

Has anyone else any suggestions?
 
Hag,

As you found out servers can get policies just as workstations. You never answered my question about how many domain controllers you have.
If you have more then one DC group policies may take longer to propigate. So for example if you are logged in and authenticated with DC1, but you made changes on DC2, then group policies has to replicate to the other DC. Then propigate to you desktop/server.

So for best results you can force a replication between your DC's, you can then use GPUpdate but if it is a computer policy you will need to reboot in order for it to take full effect. If it is a user policy it is still best to log off and log back in.


Tim,
I am sorry that loopback didn't help you. We have been running it in our situation with no issues. We are doing dynamic start menu creation and redirection. I wish I could be of more help. Good luck.



-Matt
 
Thanks Matt. There is only one DC so I'm not sure why it took so long, but I'm happy with it now. I created a user group and instead of adding users to it, I'm adding computer names and it's working great. Someone had mentioned creating a new OU, but I don't know if that's entirely necessary since I can just create a user group and add the computers and users to the group. Any significant advantages to using a new OU over a user group?

 
Do not confuse OUs and groups. They are actually very different. An OU is a logical container that holds objects (computers, users, groups, printers, shares, etc)

So in the GPMC you can see your OU's. If you expand an OU you will see the GPO's that are in that OU.

I would highly suggest creating OUs. It makes administration sooo much easier when you can see items together. Now, with that in mind you still will have groups. Group Policies will work the same the way you are setting them up now. (hence the name). Before you start getting into creating multiple policies for all different groups I would suggest going to an OU model.

Example:
Where I work we have an OU for Users (not called users, in this example we will call it usersOU), one for laptops, one for desktops, and one for groups.

So I put all my user GPOs in the usersOU, but.... I still only apply the policy based on group membership. So in the bottom right window if I want the policy to apply to "testgroup" then will add that group.



There are many OU models to follow: departmental, physical location, etc. I understand you are a small company but you should really get off on the right foot.
So not only will it organize the objects in your active directory but it will help you organize your group policies.

In a large company of course this is essential. It also allows for delegation of control and what not.

I have a feeling my example might be confusing. I am a bit tired, but I think you are really getting a good understanding of it. Let us know if you have any more questions.

-Matt
 
gotcha.. I went ahead and made a new OU called "desktops" and added a group to it called "wusmachines", and from their I started adding the computers I needed in there. I can see how this will be easier to manage. Thanks again for all the advice.

--hag
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top