Group Policy - move servers out from under Default Domain Policy

I'm basically new at this and taking over for the guy that's no longer here.   Single domain with about 50 desktops and 7 servers.  I have GP structure that came along as the domain moved from NT/Windows2000, etc uphill until now we're at Server 2012 on the DCs (functional level is still 2008 R2).  The GP Management left pane looks like this under "mydomain.com":

Default Domain Policy
(ou)Domain Controllers
     Default DC Policy
(ou) Domain Servers
(ou) Msft Exch Security groups
Group Policy Objects
     Default DC Policy
     Default Domain Policy
     Server Policy

Ok - basically every policy was put in the Default Domain Policy.  Right now there is a policy that deploys printers and it's being applied to my servers.  How do I make a separate policy that just includes servers, and most importantly, how do I keep the Default Domain Policy from affecting everything below it?  I tried to block inheritance at the DC ou but the DC's keep getting the printer policy.  What I'd really like is a set of policies for DC's, one for other servers, and one for everybody else.  I'm just not clear on the steps -- this is a production system and I'm reluctant to start whacking at it without some advice.  Thanks.
dvanakenAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
First, you *want* the default domain policy to affect everything below it. Trust me on this. You do. There are very rare circumstances where you wouldn't want this to occur, but only very complex environments would have such a requirement and only GP experts should try to pull it off.

The solution you want to employ is to start migrating settings from the default domain policy to new policies that only apply to the subset of machines you want impacted.

For example, I'd create a new OU and call it "workstations" and put all of your client machines in there. Now you have a unique OU that can apply policy objects *just* to workstations.

Then you can create a new group policy object, name it "shared printers" or similar. Add your printer deployment settings to the new policy object and remove it from the default domain object. Now you have a unique policy object that does *not* apply to your servers or everything in the domain.

Finally, you can link that policy to any OU you want. So link it to your workstations OU and your domain controllers and servers won't get it. If, in three months, you decide to start using remote desktop servers, you can create a new OU, add your remote desktop servers to that OU, and link the policy object to that OU as well. And then your printers get deployed to your workstations *and* RDS servers, but not your DCs or LOB servers.

This type of setup is granular, easy to manage, and if done properly, allows a third-party to quickly understand what the environment looks like and can jump in if needed. This is important when job roles change, or when contracting with a new LOB vendor, or other similar situations. Self documenting environments are *very* handy as they take less explaining.

So here is my advice.

1) Create OUs as needed. Name them clearly. Use nesting where it makes sense. Example, "client machines" OU. In there you could put a "desktops" OU and a "laptops" OU. Create OUs as needs arise (such as one has arisen now) and *always* clearly name them.

2) Create new group policy objects for new policies. Don't create a "workstations" policy and lump everything in there. Instead, create a "shared printers" policy. OR if you wanted to control a specific thing in MS Word, like a custom dictionary for your industry. Create a "custom dictionary" group policy. This allows you to add, delete, and change individual policies without adversely affecting other policies and machines on the network. Again, Clearly *name* the policies so you can, at a glance, know what its purpose was.

By being granular, with clear names, you'll make your job much easier down the road. And now you can see why stopping the default domain policy from applying to everything should be avoided. Let it apply to everything. Just don't put much (or anything) *in* that policy. That policy should only be used for something that you truly want to apply to *everything* ...such as strong password requirements.

-Cliff
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Cliff GaliherCommented:
I meant to add on final tidbit. By taking this approach, you won't be "whacking" your entire network. If you create a new OU, you can move one test machine into the new OU. You can create a new policy for the shared printer. You can disable just the shared printer setting from the default domain policy. You can see that change take effect, and verify it works.

That way you can *slowly* migrate all the settings you want out of the default domain policy, and the risk of breaking your entire network is minimal. It is an orderly, slow, controlled migration process and any problems will be spotted early, will be contained to just the OU, and easily reversed. An added bonus to using the approach I described above.
0
dvanakenAuthor Commented:
Thank you.  So I assume from your advice that I can just move things around in ADUC the way I want them?  As long as the GPOs are applied correctly?  I have been afraid to mess with that at all (you get all these scary warnings).  If that's ok I'll make the new OUs today and drop in a few test computers to check my policies on.  I'm generally ok with the idea of making a policy - is "linking" a policy to an OU the same thing as applying it?  Also, can I move a policy object itself from the default domain policy to a new place?  Or do I need to delete it and rebuild it in the right location?
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

dvanakenAuthor Commented:
I just looked in ADUC and I have a folder/container (not an OU) called "Computers".  I guess I need to make an OU and move them into it in order to apply policies? Would that be the correct approach?
0
Cliff GaliherCommented:
Yes, you can generally move things around in ADUC just fine. The warnings are legitimate, but shouldn't be scary. They are letting you know that moving an object may cause its permissions and applied policies to change, which are both true. In larger environments, it isn't uncommon for delegated management to be in place. So a finance department may have their own IT helpdesk. And the big honcho in IT has set up permissions to that the Finance IT guy can only make changes to the Finance OUs. Moving a computer out of the Finance OU to another OU would mean he couldn't work with that computer anymore. Thus a legitimate permissions change, and the reason for the warning, but not a huge risk. Just a reminder that moving objects does have consequences.

Linking vs applying is rather a matter of semantics. A policy can be linked to one or more OUs, and objects (computers, users) in that OU will get the policy applied at next boot or login. So from a technical standpoint, linking a policy doesn't "force" an immediate apply. But linking *does* mean the policy will be applied at the next opportunity as long as other factors don't prevent/block the policy from applying. Security groups and WMI filters are examples of other factors that can cause a policy to apply or not apply. But linking is, in effect, the usual first step. The others (security groups and WMI filters) will usually allow the policy to apply if they are left in their default state.

-Cliff
0
Cliff GaliherCommented:
Yes, I do recommend creating an OU if you want to organize machines by the type of work they do. And yes, moving machines from the computers container into an OU is perfectly normal and a legitimate thing to do.
0
dvanakenAuthor Commented:
Thanks.  I'll give this a try today or tomorrow morning and let you know how it goes.  

Oh also - what about my question:

  Also, can I move a policy object itself from the default domain policy to a new place?  Or do I need to delete it and rebuild it in the right location?

I don't have a sense of how flexible the editing or assigning is on these objects...
0
Cliff GaliherCommented:
Ohh, sorry. I misunderstood what you meant by that last question so I thought I had covered it. Matter of terminology:

A group policy "object" is an actual object in Active Directory. The "default domain policy" is a group policy object. As is any new GPO you create and link.

The individual items you can set in an object are policies. To the password policy is just one policy. And a GPO has thousands of individual policies; most are unset. A policy is *not* an object.

So you can't move an "object" from the "default domain policy" because it is not an object to be moved. This answer is both one of using the proper terminology for things, but is also the practical technical answer as well. Because a policy is not an object, it cannot be moved. You have to unset the policy in the GPO you don't want applying it, such as the default domain policy (you aren't technically deleting it, you are making it so it no longer is set), and then you have to enable that same policy setting in the new GPO you have created...basically rebuilding it.

So no, can't move. Must unset in the old and set in the new. There is a more convoluted process of exporting and importing, but honestly, unless you have a *ton* of settings, I wouldn't go that route. That process is more for moving massive amounts of policies that are already organized, such as two companies merging. They don't want to reorganize their policies, they just need to batch import all the GPOs from an old domain into a new one "as-is."  So....you may find references to moving policies in that way. But it really wouldn't be applicable to your situation.
0
dvanakenAuthor Commented:
Cliff this is immensely helpful.   I am moving things around now.   Is it safe to assume that regardless of the ou/folder structure in ADUC, everything still gets the Default Domain Policies?  In other words just because I am moving things (within the domain) I don't have to worry about them losing policies (until I manually unset the policies later). Correct?
0
Cliff GaliherCommented:
Precisely correct. Which is why, like I said, this is actually a low risk way to slowly move to a more organized environment and why you *don't* want to try and force the default domain policy to not apply to certain machines. Let it continue to apply to everything and you can move things around under it without much worry.
0
dvanakenAuthor Commented:
I will report back tomorrow.  Thank you very much for such clearly written responses. --Dale
0
ThinkPaperIT ConsultantCommented:
>>I just looked in ADUC and I have a folder/container (not an OU) called "Computers".  I guess I need to make an OU and move them into it in order to apply policies? Would that be the correct approach?

FYI - concerning the "Computers" container, this is a default container that Microsoft has created. Any machines left in that "Computers" container do NOT recieve group policy.

And two bits of advice:
1) DON'T delete any GPOs. You can "unlink" them (so that they are inactive) You want to make sure you have a good backup of all your GPOs before you start playing around with them. Best thing you can do is create a copy of the current GPO you want to play with (rename as necessary) and modify that one. That way, you have the OLD gpo and a NEW gpo in the case you need to revert back.
2) General rule of thumb is to AVOID using "block inheritance" as much as possible. Remember that setting group policy precedence is key - take a look at the order the GPOs are applied.
0
Cliff GaliherCommented:
"FYI - concerning the "Computers" container, this is a default container that Microsoft has created. Any machines left in that "Computers" container do NOT recieve group policy."

The last sentence is *ABSOLUTELY* incorrect. GPOs cannot be *linked* to the container. But any GPO linked at the domain level will still apply to any computers left in the container. So they absolutely *DO* receive group policies.

This is documented by Microsoft here, as a reference.

http://technet.microsoft.com/en-us/library/cc782866(v=WS.10).aspx
0
dvanakenAuthor Commented:
Looking good so far, I created a Shared Printers Policy and linked it to the new Desktops OU.  Once I removed it from the default policy printers disappeared from the servers (main goal met).   I read a little about the order in which policies are applied - I guess I don't fully understand but I'm not sure it matters in my small environment.  One thing was weird - even after I removed the shared printers from the default policy, they kept showing up in the "settings" report tab.  I checked them several times and finally just went with the conclusion that the printers were gone after a gpupdate...  must be working.
0
dvanakenAuthor Commented:
All is well!  Cliff - thank you!
0
Cliff GaliherCommented:
Anytime. Glad it worked out.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.