Copying Polices from One Container to Another

  • Thread starter Thread starter Kyle Stedman
  • Start date Start date
K

Kyle Stedman

Hi,

We have AD Container that we put our public-use computers in, and this
container has a complex set of Policies associated with it.

We want to break some computers out of the original container and place
them in a new container. How can we copy the policies in use on the 1st
container to the new one?

Thanks for any help,

Kyle Stedman
 
You can link the same policy to more than one OU. You don't need to copy
anything.
 
Phillip Windell said:
You can link the same policy to more than one OU. You don't need to copy
anything.

Thanks Phillip..

One last thing. Is it possible to copy it in any case? I'm thinking about
a scenario where you'd want to copy a complex policy set, so that you could
make minor modification to it without have to build it from the bottom up.

Thanks,
Kyle
 
Yes, if you install the GPMC to manage your policies, the tool gives
you the ability to backup, copy, paste, import settings into a blank
policy, use a policy as a template, etc. - among other things.

I believe the tool is limited to running only on Windows 2003 or XP,
but IIRC it can manage policies in Windows 2000 domains as well.

If you don't have the GPMC, it's at:
http://www.microsoft.com/downloads/...24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en
and well worth the time to download and install.

HTH
JeffG
 
Kyle Stedman said:
One last thing. Is it possible to copy it in any case? I'm thinking about
a scenario where you'd want to copy a complex policy set, so that you could
make minor modification to it without have to build it from the bottom up.

But that would mean you would have policies that overlap in their settings.
I would recommend multiple policies with each policy doing "less". Each
policy would do one simple specific thing. You then just apply multiple
policies to an OU to get the aggregated effect you want.

As a "preventative FYI", I also recommend you not get "carried way" with
GPOs. Group Policy is not the "Universal Monkey Wrench". It should not be
used for "everything imaginable". There are things about it that will bit
you in the rear-end if you are not careful. For example, removing or
unlinking a GPO from an OU does *not* put the settings back to the original
state on the effected machines. GPO is somewhat of a glorified registry
editor, and removing or unlinking the GPO doesn't return the settings to
Defaults anymore than closing Regedit returns the settings to Default after
you've changed something using it. Once they are changed,..they are
changed,..until they are "forced" back by another settings change.
 
But that would mean you would have policies that overlap in their settings.
I would recommend multiple policies with each policy doing "less". Each
policy would do one simple specific thing. You then just apply multiple
policies to an OU to get the aggregated effect you want.

So, what is your suggestion for policy objects across OU's (or even
individual groups) where there are slight but significant changes to
the policies for each site/group? Going through the manual creation
and testing when there's already one you know works and can use with
simple minor modifcations seems like an unecessary chore to me. And
as the OP pointed out, you just might want to change a complex policy
and test it without touching your existing policy.

I do agree with the many/separate policies point, unless that gets to
be unweildy to manage. But not using an existing resource doesn't
sound very.. ... ..resourceful to me...
As a "preventative FYI", I also recommend you not get "carried way" with
GPOs. Group Policy is not the "Universal Monkey Wrench". It should not be
used for "everything imaginable".

What?? Well what the heck IS it for then - and if it's not a
universal monkey wrench, why does it happen to fit a LOT of the
screws, pipes, nuts, and bolts that I need to turn? As a matter of
fact, it's the only tool that fits in most cases.
There are things about it that will bit
you in the rear-end if you are not careful.

Amen, but isn't that statement as applicable to life in general as it
is to group policies? At least you can test a policy before you roll
it out - there is no such testing for negative reactions in life...
For example, removing or
unlinking a GPO from an OU does *not* put the settings back to the original
state on the effected machines. GPO is somewhat of a glorified registry
editor, and removing or unlinking the GPO doesn't return the settings to
Defaults anymore than closing Regedit returns the settings to Default after
you've changed something using it. Once they are changed,..they are
changed,..until they are "forced" back by another settings change.

O absolutely. But then again, what method of control or configuration
change is there for a workstation that actually does work and then
actually does return to original settings when you're done?

If you think we're screwing up, tell us why - after you've gotten the
pertinent details. If you don't understand why we'd want to do
something that we request help with, ask until you understand, and if
you understand and *still* determine that it's stupid, then tell us
what you would do in our place.

I don't usually argue with anyone with that many letters after their
name, but I don't think discouraging the OP's efforts to understand,
implement and work with group policies is good advice.

Don't take it for granted that we're morons just because we asked.
JeffG (no letters)
 
JeffG said:
So, what is your suggestion for policy objects across OU's (or even
individual groups) where there are slight but significant changes to
I do agree with the many/separate policies point, unless that gets to
be unweildy to manage. But not using an existing resource doesn't
sound very.. ... ..resourceful to me...

I'm creating "absolutes" here. You have to put enough thought into it to
come to a good "balance".
If you think we're screwing up, tell us why - after you've gotten the

What "we" and "us"? I'm not claiming anybody is "screwing up".
Don't take it for granted that we're morons just because we asked.
JeffG (no letters)

You need to take a break, Jeff.
 
My understanding of the design of the Group Policy infrastructure and my
experience is that, for "true policies", if the object (i.e. user or
computer account) gets removed from the scope of a GPO, settings made via
GPO are removed and settings from other GPOs that are still in scope or
local settings will apply. For some computer settings, a restart may be
required.

For example:
1. create a GPO that enables the Windows XP SP2 Firewall and configures the
Domain Profile and Standard Profile to prevent local exceptions
2. apply this GPO to an OU that has the account for a Windows XP SP2
computer
3. verify that the firewall is enabled and local exceptions can not be
configured
4. move the computer account to an OU that is outside the scope of the GPO
5. wait for the change to get replicated to all of the domain controllers
6. restart the computer
7. observe that the XP SP2 Firewall have reverted to the locally specified
configuration and that exceptions can be added or changed

Here's a quote (in the section called "Windows NT 4.0 and Windows 2000
Policy Setting Comparison" on page 84) from the Group Policy Infrastructure
document at
http://www.microsoft.com/downloads/...bc-d445-4e8f-aa4e-b9c27061f7ca&displaylang=en

"The Windows NT 4.0 effect of persistent registry settings can be
problematic when a user’s group membership is changed. An advantage of
Windows 2000Group Policy is that this does not occur. When a GPO no longer
applies, registry settings written to the following secure registry
locations are removed:

HKLM\Software\Policies

HKLM\Software\MS\Windows\CurrentVersion\Policies

HKCU\Software\Policies

HKCU\Software\MS\Windows\CurrentVersion\Policies"

Although this quote specifically mentions users, it also applies to computer
policies whose settings are stored in the HKLM locations identified in the
qoute (for example, the firewall settings I mentioned above). Almost all of
the settings supplied by Microsoft are of the "true policy" type, although
there are some exceptions (for example, Folder Redirection - removing this
setting does not necessarily remove the folder redirection).
 
Bruce Sanderson said:
My understanding of the design of the Group Policy infrastructure and my
experience is that, for "true policies", if the object (i.e. user or
computer account) gets removed from the scope of a GPO, settings made via
GPO are removed and settings from other GPOs that are still in scope or
local settings will apply. For some computer settings, a restart may be
required.

Some parts of GPO work that way, but others don't. The software Installation
part works that way and can be toggle on and off. I used that when
experimenting with XP-SP2 before full deployment so that if I had problems I
could move the machine(s) out of the OU and it would remove the SP2.

For example:
1. create a GPO that enables the Windows XP SP2 Firewall and configures the
Domain Profile and Standard Profile to prevent local exceptions

The Firewall GPO is a "special" one because of the double profile
(Domain/Standard), but not all GPOs have those as options. I also use that
one here with our laptops so that the Firewall is off while on the Domain
and on when off the Domain. But there is nothing being "removed" or being
returned to Defaults here,..it is just responding to one of two possible
settings based on the environment at the moment.
Here's a quote (in the section called "Windows NT 4.0 and Windows 2000
Policy Setting Comparison" on page 84) from the Group Policy Infrastructure
document at
http://www.microsoft.com/downloads/...bc-d445-4e8f-aa4e-b9c27061f7ca&displaylang=en

"The Windows NT 4.0 effect of persistent registry settings can be
problematic when a user's group membership is changed. An advantage of
Windows 2000Group Policy is that this does not occur. When a GPO no longer
applies, registry settings written to the following secure registry
locations are removed:
...........<snip>...................
Although this quote specifically mentions users, it also applies to computer
policies whose settings are stored in the HKLM locations identified in the
qoute (for example, the firewall settings I mentioned above). Almost all of
the settings supplied by Microsoft are of the "true policy" type, although
there are some exceptions (for example, Folder Redirection - removing this
setting does not necessarily remove the folder redirection).

Yes, but it is the ones that aren't the "true policy" type that I worry
about. I used to assume they would all "roll back" when un-applied, but
after several hours at the MVP Mini-Summit in November with an MVP more
knowledgable than I explaining that not everything will not "roll back" I
take the position that I do now. I'm a little reluctant to do another "180"
again,...I don't want tossed back and forth everytime I run across someone
with a different opinion.

But like I tried to tell Jeff, ..although I mistyped it the first
time,...I'm not trying to create somekind of "absolute laws" here,...I am
just cautioning the OP to not get overzelous with GPO. I see a lot of people
in the different groups that do just that,...treat GPO as the Universal
Monkey Wrench as I said earlier,...have it tie their shoes for them, warm
their coffey and tell them what color shirt thier worse user is wearing, and
turn their domain into such a twisted can of worms that they can never get
out of it. I think some of it is a little bit of "Admin lazyness" where no
one wants to actualy get up out of their chair and walk somewhere once in a
while.
 
Oh, and, sorry, I meant to say thanks for the link. That looks like some
good material to keep handy. I'm sure I will do more with GPO in the future
than I do now,..but I will always approach it cautiously and conservatively.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Bruce Sanderson said:
Here's a quote (in the section called "Windows NT 4.0 and Windows 2000
Policy Setting Comparison" on page 84) from the Group Policy Infrastructure
document at
http://www.microsoft.com/downloads/...bc-d445-4e8f-aa4e-b9c27061f7ca&displaylang=en
 
Phillip. I took a break as you suggested, and guess what? I'm still
not off my soapbox, because I still think your post was an insult
(whether intentional or not) to the OP.
out of it. I think some of it is a little bit of "Admin lazyness" where no
one wants to actualy get up out of their chair and walk somewhere once in a
while.

Lazy, yes that probably does fit me - and I'll use any tool at my
disposal to make my job easier so that I can concentrate on the "big
picture" and not continuosly be putting out fires that I could
extinguish with my Monkey Wrench :)

However, in my environment and in many others, it takes MUCH more than
a "walk somewhere" to actually lay hands on all of the machines I am
responsible for.

Here's the reason for my original dissertation:

I understand that you were trying to help inform the OP about pitfalls
over overacheiving policy admins. But generally when you are asked a
direct question, you answer the question first if you have enough
details - I think the OP had enough details for a direct answer.

Then AFTER the answer, proceed to tell the questioner why you think
they might be charting off course. That information is always
appreciated when given in conjunction with the answer to his question.
When the question is not answered at all, it tends to get "US" (below)
confused and frustrated.
What "we" and "us"? I'm not claiming anybody is "screwing up".

We/Us being those of us who are here to learn - and I definitely
include myself in that group. I could see myself as the OP and
reading your first answer and thinking "Yeah, that's great - but can I
copy my policies from one container to another?"

And to your second post - "Yeah, that's great - but can I copy my
policies from one container to another?"
You need to take a break, Jeff.

Definitely!

I really meant no offense, but at the same time I hate to see someone
come here for help and get so discouraged by the answers (or not
answers) that they won't ask for public help again - or worse, won't
contribute when they become proficient themselves.

And NOW, I'm off my soapbox.
J
 
Back
Top