Re: Group Policy Delegation of Control

I believe that I did address those.
Perhaps you might rephrase or indicate what seems to
be not addressed. Many things can be done if different
ways, and sometimes the "best" way is determined by
specifics of the infrastructure/organization.
There are downsides to using any central control, central
deploy technique. The issue is not simply if there are issues,
but if the issues are acceptible relative to the gains. Ex. SMS
or AD software deployment. Both work, are manigable, etc.
Both cause network load at times, etc. One requires more
infrastructure, servers, licenses.

"Tariq Ziad" <TariqZiad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:24A9A796-29E6-4CF3-BAF4-D28176F23681@xxxxxxxxxxxxxxxx
ROger,
I read your main reply, and I appreciat it. I was trying to get more
details
related to RIsk specially regarding Domain Controller, so if you would
comment on part 'B', especially Point 4, then it would be appriciated:
-------------------------------------------------------------------------
B. Regarding Domain Controllers impact and risks:
1. Regarding growth in GPOs: why not to Monitor the growth of GPOs
and advise DESKTOP TEAM to do preventive maintenance of group policies,
especially if this is just assigned to only a small, well-informed group
of
people as you said?
2. Is there any impact related to replication between Domain
Controllers??
3. Is there any impact related to network traffic when desktops are
downloading the GPO contents and Domain Controllers
4. Is there any other Avtive Directoy related impact?
I mean is there in general any impact on domain controllers if group
policy
is utilized? Is it better for Domain Controllers health to avoid using
group
policy feature? Is group policy a bad feature of Active Directory, so that
it
is better to keep it unused and unutilized?
What about utilizing Group Policy for Software Installations, does this
have
any impact on active directory. Some people are saying, that if you use
group
policy for software deployment then this is wrong and has bad effects on
domain controllers, and that software deployment should be managed using
SMS!!! I know the limitations of software Installation and management
using
group policy, but I was unable to find any Microsoft document saying Group
policy should not be used for this purpose and has side effects?? So,
please
advise me as per your experience in
this.
-------------------------------------------------------------
Regards,
Tariq Ziad

"Roger Abell [MVP]" wrote:

Tariq
I attempt to address your ideas/concerns with inlined comments.
Roger

"Tariq Ziad" <TariqZiad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EA06E05B-FFF1-4558-99DB-65EAF380608F@xxxxxxxxxxxxxxxx
Thanks Roger for the reply.

All your reply was read carefully.
Regarding the idea of prototype GPO that would be created and delegated
control to DESKTOP TEAM upon their need, I'd like to ask you what if I
want
to think from segregation point of view:
1. DESKTOP TEAM is responsible of all desktops in the company, and they
have
nothing to do with servers, except some servers related to desktop
administration and management such as the WSUS that is utilized for
updating
DEKTOPS Windows OS.
2. SYSTEM TEAM is responsible of DB servers, Application servers,
Exchange
servers, and Domain Controllers.


OK, this makes sense, except perhaps for the WSUS part.
You can make the individuals have capability within the wsusadmin
interface without them being admins of or enpowered over config of
the server itself (the one hosting the WSUS install).
If they have this, then do not make your servers clients of your WSUS,
since they would be able to control approval of updates for those
servers.

If I want a small, well-informed group of people (as you said) of
DESKTOP
TEAM to handle even creation of GPO and utilize it for DESKTOPs
standardization and automated deployment without affecting SYSTEM TEAM
area
of responsibility, then as per your reply will do the following:
A. Delegate the required members of DESKTOP TEAM the control of Group
Policy creation, and stop GPOs from being applied on servers by:
1. Segregating Servers from Desktops (Separate OU for Servers)
2. Delegating control of group policy creating on Domain level,
or
OUs
A.1 is needed. A.2 does not come into play - GPOs are always created as
objects in the domain. The creation of a GPO is not relevant to where it
has effect - rather where it is linked is important. Only delegate the
ability
to link GPOs on OUs that contain machines managed by Desktop Team
3. Blocking inheritance of Domain Level Group policies for the
servers OU, so this way no any Desktop Group Policy will be inherited
to
the
Servers OU. So, servers will be segregated from desktops in group
policy
appliance
A.3 not needed. Desktop Team could not link to domain level, nor to
Domain Controllers OU or any OU except OUs where you made delegation
of ability to link GPOs.

B. Regarding Domain Controllers impact and risks:

There are none if you do delegations correctly and if you do not
give ability to alter settings in GPOs other than the ones linked
to OUs of Desktop Team

1. Regarding growth in GPOs: why not to Monitor the growth of
GPOs
and advise DESKTOP TEAM to do preventive maintenance of group policies,
especially if this is just assigned to only a small, well-informed
group
of
people as you said?
This is situational. One needs to assess alternative relative to the
characteristics of your support group / employees.
GPOs can become messy when they get defined willy-nilly for
what each of a number of people think is a good reason.

2. Is there any impact related to replication between Domain
Controllers??
only when a GPO is changed/edited

3. Is there any impact related to network traffic when desktops
are
downloading the GPO contents and Domain Controllers
sure, again the impact happens the first time or when a change
is detected

4. Is there any other Avtive Directoy related impact?
I mean is there in general any impact on domain controllers if group
policy
is utilized? Is it better for Domain Controllers health to avoid using
group
policy feature? Is group policy a bad feature of Active Directory, so
that
it
is better to keep it unused and unutilized? What about utilizing Group
Policy
for Software Installations, does this have any impact on active
directory.
Some people are saying, that if you use group policy for software
deployment
then this is wrong and has bad effects on domain controllers, and that
software deployment should be managed using SMS!!! I know the
limitations
of
software Installation and management using group policy, but I was
unable
to
find any Microsoft document saying Group policy should not be used for
this
purpose and has side effects?? So, please advise me as per your
experience
in
this.
That is a boat-load of questions.
In general, the advantages from using group policy far outweigh
issues due to overheads. Now, mind you, all good things can be
abused, but when used as intended and advised as good practices
(in MS docs and elsewhere) you should be OK.



C. Impact on Desktops is to be left to DESKTOP TEAM, since they are
responsible of desktops. They are already having the change control
workflow.
Planning, and Testing are required before approval from DESKTOP TEAM
Leader
to implement any new group policy. So, should SYSTEM TEAM have a role
in
this
change control process? Is notification to this team and other IT teams
required?
Situational. A lot has to do with skillset in your workforce and
dynamics in your support organization. However, consider having
some OU structure for them to test, with enough GPOs for them to
be able to determine what they want and see it play out. I personally
tend to believe that if each group is autonomous as far as possible
things are better. There is however a point at which one must make
sure some things are without doubt in a certain way. There are also
some things that you cannot prevent and yet still enable them to use
GPO without intervention (ex. if they can change settings in GPOs
linked to OUs of the desktop machines, then they can make sure
that Domain Admins have no rights on those machines - and you
cannot do anything about that in any workable way).

And regarding RSoP, what realm of control would be for other teams if
this
DESKTOP TEAM is responsible for all administration tasks related to
desktops,
even network connection configuration??
I do not understand the question.
What I was indicating is that there is a delegation that allows the
receivers of the delegation the ability to use the RSoP capability,
and having this would be essential for the Desktop Team.


What is your opinion regarding these 3 points. Are they covering all
risks

One thing you missed or understated is the the recommendation of
using a prototype is because some of the things that you want to give
to desktop team is carried in the ACL (i.e. security) on each GPO.
If copy of prototype is not done, then each new GPO needs to have
its security adjusted so that Desktop Team can change settings.
Giving out create to too many risks this essential part of things
being overlooked. Also, the creator of object (like GPO) is the
owner, and of course, owner has ultimate control over the object.
Having a process whereby request is made for new GPO allows
system team to retain ownership and also avoid potential problems
due to forgotten procedures needed to get the GPO right.


and impact on servers, domain controllers, and desktops?? Are they
covering
all impacts and risks in a way that will insure that SYSTEM TEAM area
of
responsibility is not impacted, and domain controllers' health is
maintained?

Your reply would be appreciated.

Regards,
Tariq Ziad


"Roger Abell [MVP]" wrote:

Tariq

There are, perhaps, three aspects of this.
Creation of GPOs, Linking/Unlinking of GPOs, Changing settings in
GPOs.
In general delegation can be at an OU level for most things that are
not
intrinsically domainwide. GPOs are domain-level objects, so their
creation
is all or none. The permissions on the GPOs once they exist determine
what
accounts can edit their settings. Delegations on OUs can determine
what
accounts may link/unlink GPOs there.
In general one may want to limit uncontrolled growth in GPOs, which
means not giving out the ability to define GPOs, or at least granting
that
to only a small, well-informed group of people.
Perhaps you should look at having a simple process for the Desktop
group to request a new GPO. When this is done, use GPMO to make
a copy of a prototype GPO that already has its permissions adjusted
to grant Desktop, or subset thereof, the ablility to edit the settings
in
that GPO. You might prelink this where needed, or leave it to them
based on the OUs where they have been delegated the ability to link.

Use of GPO over large client base obviously may have broad impact.
As such, design and use a well thought out process for change control
in order to limit accidental impacts and to provide for simple
reversal
of mistakes. For example, have a GPO over the OU(s) of client systems
the is enforced to guarantee that essential settings are not
reversed/changed
by the less-informed of those to whom there are grants/delegations.

Also, you would probably want to delegate the ability to run resultant
set of policy and to make sure that all of those with the new
capabilities
have read (not necessarily apply) for all GPOs that might impact their
realm of control.

If nothing is given in permissions of GPOs at domain or domain
controller
OU levels, and there are no delegations at those levels, then there
will
be
no impacts from their actions on the domain controllers. Similarly
for
servers not in OUs where they have been given capabilities.

Roger

"Tariq Ziad" <TariqZiad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B7F6D401-F4EE-4AB9-AE10-7D03BCAAFD23@xxxxxxxxxxxxxxxx
Dear All,

I'd like to ask that in our IT department (that is responsible of
providing
IT services to all other departments in the company) we have a team
responsible for active Directory and servers (SYTEM TEAM). Also, we
have a
team (lets call it DESKTOP SUPPORT TEAM) responsible of computer
related
tasks: installing the OS, installing software, configuring OS and
applications settings for the user and/or computer.
This team is handling these tasks manually.
If we want to delegate control of group policy to SUPPORT TEAM to
have
managed software installations and standardize computer and user
settings,
would there be any risk on Active Directory and Servers? Is there
any
impact
to care of other that excluding servers from having Group Policy
Objects
applied on them?? Is there any impact of using group policy on
domain
controllers??
I mean is it possible to delegate control of Group Policy to DESKTOP
SUPPORT
TEAM to utilize it for desktop environment standardization, without
any
impact on servers and Domain Controllers?
Finally, is there any document from Microsoft related to this
Subject?

Regards,
Tariq Ziad








.